Quality of current offerings in image processing pipeline.

[Brandt Wilson]

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).

[Sebastian Pichelhofer]

If you want to browse some high quality footage from 353 go to Google Maps with Street View

Cinema relevant we have some here:
Images | Apertus Open Source Cinema

What is the "city intersection" footage?

[Brandt Wilson]

Elphel Raw Test Footage on Vimeo

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

[Dmytry Shijan]

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.

[Tom Sparks]

Originally Posted by Brandt Wilson

Elphel Raw Test Footage on Vimeo

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

Images and videos examples - ElphelWiki

[Sebastian Pichelhofer]

Originally Posted by Brandt Wilson

Elphel Raw Test Footage on Vimeo

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....

Originally Posted by Dmytry Shijan

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.

[Dmytry Shijan]

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.

[Biel Bestue]

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

[Sebastian Pichelhofer]

To get rid of the maze effect I just awarded a new feature bounty: DNG Conversion Image Quality | Apertus Open Source Cinema

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