Can you preview dual-iso shots?

[elijahalcantara]

Sort of a quick question.. (sorry the dual-iso thread is tooo long)

When dual-iso is used can we still preview the image in-cam? I've seen some posts that the preview in cr2 is messed up but I don't know by how much or if it was an old issue ...

I may just bite into the eos-m deals in a day or two, I would appreciate some input on what's broken or fantastic about it so far   dual-iso and ettr will decide my purchase here

[a1ex]

The exact behavior is camera-specific, maybe somebody with EOS-M can take a picture of the camera screen (normal and zoomed). On 5D3 I find it OK for judging whether the image is over or underexposed, but colors are way off.

[elijahalcantara]

thank you, hmm if it's just colors then it's probably ok for judging sharpness I guess.

I guess it's safe to assume that shooting raw+jpeg will yield the same result? (previewing jpeg only to see the normal shot)

[a1ex]

Read the paper and the answer should be obvious.

[Marsu42]

On 5D3 I find it OK for judging whether the image is over or underexposed, but colors are way off.

Same on 6d, though you have to get used to it to the magenta/cyan color cast - Canon overexposure blinkies also help since they only blink the bright dual_iso lines, you then know everything's fine.

[a1ex]

Now I'm thinking: since the raw zebra hook is placed between Mem1toRAW and Mem1toJpeg on many cameras, it may be possible to alter the raw data in order to get good previews. Simply copying say dark lines over bright ones should be pretty fast (though you will be limited to previewing a single exposure).

[Marsu42]

Simply copying say dark lines over bright ones should be pretty fast (though you will be limited to previewing a single exposure).

Sounds great, - If you don't make it an option I'd opt to preview the bright one to check for blown highlights, the dark exposure being the "extra" of dual_iso. How about letting the user choose? First display the composite scanline preview, then per button request (like up/down) either copy dark->bright or vice versa.

[a1ex]

This preview will be forever hardcoded in the jpeg (so you can't choose it after taking the pic).

Proof of concept working on 5D2:

Code Select Expand


raw_buffer_intercept_from_stateobj():

    for (int i = 1; i < 3804-4; i += 4)
    {
        int pitch = 5792*14/8;
        int row = raw_buffer_photo + i * pitch;
        memcpy(row, row + pitch*2, pitch);
        memcpy(row + pitch, row + pitch*3, pitch);
    }


Notes:
- if this hook is not exactly between raw and jpeg developing process, you may end up overwriting the CR2 data too
- colors are even more off, probably because of black difference (here, the high ISO appears with strong magenta cast, the low ISO appears greenish with alien colors)
- it's still not sharp enough for checking critical focus

so at this point, I'm not sure whether it has any practical use. I'm also not sure if I can get a basic field blending fast enough (say 2-3 seconds).

[Marsu42]

so at this point, I'm not sure whether it has any practical use. I'm also not sure if I can get a basic field blending fast enough (say 2-3 seconds).

Even if not, if it's not too much bulk +1 for including the code - after taking a 30sec+ long time exposure with dual_iso I wouldn't worry too much about waiting a couple of more seconds, but I do worry about discovering the shot went wrong only after returning home due to a dodgy scanline preview :-p

[a1ex]

Success!

Timing is ~4 seconds on 5D2 for processing an entire CR2 (multiplying half of the lines by 8 and correcting black level in all lines). Colors are perfect and it's sharp enough to check critical focus, see hot pixels and other stuff like that.

[painya]

Success!

Timing is ~4 seconds on 5D2 for processing an entire CR2 (multiplying half of the lines by 8 and correcting black level in all lines). Colors are perfect and it's sharp enough to check critical focus, see hot pixels and other stuff like that.

You guys are incredible. I trust that this option (if it shows up on a build in the near future) will be optional?

[Marsu42]

Timing is ~4 seconds on 5D2 for processing an entire CR2

Yippee :-) ... I'm eager to try see the commit, probably it'll be even faster on a digic5-based camera like the 6d? We'll see. I consider the dual_iso feature one of the greatest successes of ml, so the work is well invested here.

[a1ex]

I have good news and bad news. Which one should I tell first?

[Danne]

Interesting. Good first?

[Marsu42]

I have good news and bad news. Which one should I tell first?

Considering how good this whole thing is working, there cannot be any bad news (unless you discovered that dual_iso bricks cameras and has to be removed just like movie mode remap). So go ahead, the auto_iso module is working fine now on both 6D & 60D, I don't think anything can affect me after a whole ml day :-p

[a1ex]

Well, the good news is that I've been able to get a really nice preview in less than 1 second. I'm only converting 70%x70% of the image => area twice as small. Also I no longer need to do black level corrections, so this cuts the processing time in half again.

The bad news is that I couldn't get it working on 5D3 (but I'm still trying). The processing paths seem different; in particular, sssCompleteMem1ToRaw and CompleteRawToLcdJpeg don't sound encouraging. Does this mean JPEG is generated from compressed RAW data? (hard to believe, but hooking into these two has no effect on the preview image). I'm sure my code runs and modifies the raw buffer (even got the timing; it runs exactly as fast as 5D2; of course, the image buffer is a little higher here).

http://a1ex.bitbucket.org/ML/states/5D3-alt/sm56.htm

[Marsu42]

Does this mean JPEG is generated from compressed RAW data? (hard to believe, but hooking into these two has no effect on the preview image).

Probably that's (part of) the reason why the 6d lasts only half as long as the 60d on one battery?

http://a1ex.bitbucket.io/ML/states/5D3-alt/sm56.htm

Looks fascinating, but beyond my current ml knowledge as discussing philosophy for my pets :->

[a1ex]

I think the full-frame sensor draws more power.

Now I've got a hook point from where I can modify the JPEG preview (right before sssCompletePrepareLcdJpeg), but the preview also gets burned in the CR2. Still, it's a progress.

[Marsu42]

Now I've got a hook point from where I can modify the JPEG preview (right before sssCompletePrepareLcdJpeg), but the preview also gets burned in the CR2. Still, it's a progress.

For my personal ml education: When are these previews used? So there is a jpeg preview right after shooting - even if the camera isn't set to write jpeg to the card - that gets displayed and then attached to the cr2?

After getting the cr2 off the camera, for me the cr2 previews are worthless anyway since they get deleted when converting cr2->dng, that's also the reason why it's much more efficient to look for focus in camera rather than Lightroom since the latter has to re-render the dng.

[a1ex]

Yes, every cr2 has an embedded jpeg, and this jpeg is used for preview in playback and QR.

Tip: dcraw -e *.CR2

[Audionut]

The preview in CR2 for dual ISO is almost useless anyway.  I'd happily take whatever preview you burn into the CR2 since it's the DNG that matters

[a1ex]

FYI, the DNG is generated from the CR2

[Audionut]

I thought you were only modifying the embedded jpg preview.

Did you mean the hook point for modifying the JPEG preview is also effecting the raw data?

[a1ex]

I modify the raw data so the jpeg preview will be non-interlaced (or at least a small part of it).

For 5D3, I think I'll have to undo my changes before saving the raw data, because it first generates the JPG, then the compressed RAW. The 5D2 first generates the compressed RAW, and then the JPG.

[Audionut]

because it first generates the JPG, then the compressed RAW.

That seems backwards to say the least.

What about hooking into the standard JPG preview after file save?.  Can you do this rather then decompressing the CR2?
Does it get piped to some buffer?