I recently looked at some footage on the apertus pages. The city intersection footage struck me with its very visible blocks. Are there examples of just how good footage from the 353 can look? I'm a little nervous of using this as a basis for my hardware platform if the final image isn't up to par with other commercially available images at a similar price point.

I'm not a coder, so for this aspect, I'm definitely reliant on experts in this area. I'll lend my skills in physical integration and ergonomics (I have a rapid prototyping facility at my disposal).

If you want to browse some high quality footage from 353 go to Google Maps with Street View (http://maps.google.com/help/maps/streetview/)

Cinema relevant we have some here:
Images | Apertus Open Source Cinema (http://cinema.elphel.com/still-images)

What is the "city intersection" footage?

Elphel Raw Test Footage on Vimeo

Visible macroblocks in the street. Is this the only example of 353 output?

i also noticed blocks when play with Sebastian Pichelhofers macro raw shots. first of all current 353 camera hardware cannot transfer 2k@24fps with decent compression quality, i think its just compression issue. also there can be issue in post with debayering method of raw image or it can be issue of jp4 algorithm itself.

Elphel Raw Test Footage on Vimeo

Visible macroblocks in the street. Is this the only example of 353 output?
Images and videos examples - ElphelWiki (http://wiki.elphel.com/index.php?title=Images_and_videos_examples)

Elphel Raw Test Footage on Vimeo (http://vimeo.com/1896684)

Visible macroblocks in the street. Is this the only example of 353 output?

Thats a compressed flash video on vimeo, I would not use that for judging compression....

i also noticed blocks when play with Sebastian Pichelhofers macro raw shots. first of all current 353 camera hardware cannot transfer 2k@24fps with decent compression quality, i think its just compression issue. also there can be issue in post with debayering method of raw image or it can be issue of jp4 algorithm itself.

Thanks Dmytry for bringing that up again, we looked into the matter sparked by your comment and narrowed the problem down to this:

The DNGs posted on the Apertus website are uncompressed so these artefacts can not be the result of compression.
When recording in JPEG mode balancing of green pixel values of the bayer pattery is done in the camera by default.

When recording in JP4 mode you get raw data though - all that balancing is un-applied, you get what sensor provides. The sensor problem is that some photoelectrons from red pixels get into green ones. And the crosstalk is different vertical and horizontal. So amount of red light changes local balance between G1 and G2. Not much, but detectable.
This then creates the maze-like effects you see when demosaicing the DNG with a debayer algorithm that strongly relies on edge detection (AHD most likely which Adobe uses in Camera Raw).

So the solution is to get the green pixel values into balance again ( maybe during the conversion from JP4 to DNG). We will start working on a fix.

just to be sure that we all speak about same thing here is a 200% zoomed part of image with visible straight grid of square blocks on light/shadow gradient.
http://i54.tinypic.com/2zfmmbp.png

this seems re-scale issues, have those shots been re-scaled somewhat?

To get rid of the maze effect I just awarded a new feature bounty: DNG Conversion Image Quality | Apertus Open Source Cinema (http://cinema.elphel.com/node/54)

Lets see what the image looks like after this task has been completed then we can focus on any remaining block artefact issues.