Skip to content

Dual ISO preview

Alex requested to merge bitbucket/declined-pr-251 into branch/unified

Changesets for this Pull Request have not been imported, because it had been already declined on Bitbucket. Marked as closed by the import user.

From http://www.magiclantern.fm/forum/index.php?topic=8667

This is a big breakthrough regarding dual ISO usability. You can have correct previews, check critical focus, colors, highlight/shadow detail and forget the old interlaced preview (well, not quite, but almost there).

Warning: the implementation is tricky and has some destructive potential (you may lose data). This works by altering the raw image buffer right before generating the JPEG preview (used for display), and restoring it back before Canon code will compress the raw data to save it in the CR2. So, the preview will get burned in the embedded JPEG of the CR2 (no big deal), but an incomplete/incorrect port of the state object hooks may result in burning the preview image in the raw data. If this happens, the original image will be very hard to recover.

Therefore, I think this should be thoroughly tested by a knowledgeable person before going in nightly builds (in particular, make sure the CR2 data is correct and has no artifacts around the preview box or stuff like that). I suggest field testing for around one week before trusting this code and merging it into mainline.

Caveats/specs:

  • It doesn't process the full picture, but only 60%x60% (that is 35% of the visible area). Reason: speed. It's easy to change the size, but for me this seems a good balance.
  • The processed area is centered on LiveView focus box.
  • It uses a bit of RAM (around 5-10 MB) because it has to undo the changes. Since allocating from shoot_malloc may take longer (!) than the entire processing loop, I allocate this memory only once (so first picture is slower) and I only free it when you turn this off and take a picture after that. Not very efficient, but gets the job done.
  • Burst mode: if you press the shutter halfway, it will abort processing (or will not even start). Therefore, the impact on burst speed should be zero.
  • At extreme settings (100/1600 on 5D2 is extreme), you will get incorrect color because of large difference in black levels. Cr2hdr will take care of that, but in-camera processing must be really fast, so I chose not to correct this one for speed reasons.

Cameras: only 5D2 and 5D3 for now. Feel free to port it on more. You need to enable preview_working for your camera and check the hooks in state-object.c. Make sure both hooks get called in pairs (will add some internal checks for that).

6D: the hook point for photo raw buffer was changed, and the new one has different offsets. These will have to be updated.

It might be possible to optimize the code even more. No idea how fast it can go, but g3gg0's byte swap for silent pictures was like 5x faster than my C code.

Merge request reports