[WONTFIX] Auto-HDR after failed Auto-ETTR

[Marsu42]

Auto-ETTR is so nice I'm getting too lazy for proper manual or even semi-automatic exposure :->, and here's the way to get even lazier (and save some shutter cycles which are burned by auto ettr):

When Auto-ETTR fails, i.e. the scene has too much dynamic range, ml should give the user the option to do proper bracketing right away, capturing *only* the frames that aren't already taken (more or less). Otherwise doing a manual ml bracket afterwards takes time to initiate and it's likely the camera takes the *same* (more or less) frames again that auto-ettr already has.

The drawback is that the auto-ettr frames aren't "properly" spaced as real bracketing would, but personally I wouldn't care since +-1ev can easily be done in post before merging and tonemapping. It would just be nice if ml could add some frames with the spacing set in the ml bracket options, certainly better than simply failing auto-ettr.

Btw. adding a 2nd overexposed bracketing frame also makes sense when the result of auto-ettr is that there's much data in the deep shadows which might be affected by noise after postprocessing.

[Audionut]

A bracketing to fill in the brackets that AutoETTR missed?

I can sort of see how this could be useful.  But how many times would it really be used?
AutoETTR failed, hey let's HDR it!

I also don't understand why you would use AutoETTR with the intention of doing a HDR, only to have AutoETTR do a half arsed job (it's not meant to do that) at capturing some initial brackets, and use another function to fill in the poor job AutoETTR did.

Why not just bracket the scene from the start?

[Marsu42]

I can sort of see how this could be useful.  But how many times would it really be used?

Well, *I* would certainly use it a lot, well, but since it won't be done I have to be more careful if there's bright sky and shadows in the scene.

Why not just bracket the scene from the start?

Because I don't know from the start if the scene will be outside of the sensor's dynamic range by using the vf, i.e. it's possible to capture just one frame after measuring for ettr.

[a1ex]

When ETTR fails, it's because convergence is not achieved in 3-4 steps. Not related to dynamic range.

For this, you can look at the underexposure zebras / histogram and judge it.

This would be quite difficult to implement (the biggest issue being very tight coupling between ETTR and bracketing, which I want to avoid).

[Audionut]

Because I don't know from the start if the scene will be outside of the sensor's dynamic range by using the vf, i.e. it's possible to capture just one frame after measuring for ettr.

As a1ex mentions, you can use zebras and the histogram.

Set raw histogram hint to dynamic range.  The area of the histogram shaded in brown is outside of the cameras dynamic range.

Since it's obviously a static scene, this will allow you to use LV to determine if the scene requires bracketing.  Without using Auto ETTR and wasting shutter actuation.

[a1ex]

Correction: you can't use LV to check dynamic range, because ISO in LV is usually very different from ISO in photo mode. Plus, different sampling modes will result in different noise patterns, so I've disabled this indicator in photo LV.

The indication from movie LV is a better estimation, but I think it's still off. For checking underexposure, just take a test shot.

Noise analysis is done on the fly, for each shot.

[Audionut]

That would effect zebras in LV too?

[a1ex]

Yes, underexposure zebras are random now, need disabling...

[Audionut]

I wish I understood this stuff better.

The white point in LV (any mode) isn't accurate, because ISO results vary?
So that rules out going back to the pre-set dynamic range results from DXO also!

Does LV have any sort of consistency (I guess not since you mentioned "usually", but I'm grasping at straws), that you can factor?  ie:  It's constantly -0.4EV below currently set ISO.

Is there are general error margin?  ie:  Always within 0.3EV.  If it's not that large of an error, it could be worth leaving raw zebras enabled.  They'll still be a shit load better then the old JPG based stuff.

[a1ex]

Movie LV is accurate for raw video, because you record that.

Photo LV is not accurate because ISO 100 at 1 second is done as ISO 3200 1/30 or whatever Canon chooses.

White point in movie LV is constant.

White point in photo LV is also constant, but ML changes it to make the histogram match the CR2 ones as closely as possible.

So... in photo LV, overexposure indicators are OK, but underexposure ones are random.

[Audionut]

Photo LV is not accurate because ISO 100 at 1 second is done as ISO 3200 1/30 or whatever Canon chooses.

Hmm (still grasping), is that because LV doesn't allow shutter slower then 1/30 (movie mode)?  And it's using funky code to fix it for photo LV.  And if so, does it produce consistent (accurate) results for shutter speeds faster then 1/30 that can be used, with warnings for slower shutter speeds?

Or did you just happen to pick a random example that allowed me to grasp that straw a little longer?

[a1ex]

I've just picked a random example. ExpSim does not use the exposure values you pick from menu; they use some complex algorithm to get something with equivalent brightness.

Raw exposure in ExpSim is done in full-stop increments. For smaller increments, Canon applies digital gain to the raw data, and this is the reason I had to do the same trick by faking the white level.

Otherwise, you would have histogram data and ETTR hints rounded to full stops, and overexposure warnings not working at all at certain shutter speeds.

[Marsu42]

When ETTR fails, it's because convergence is not achieved in 3-4 steps. Not related to dynamic range.

Wupps, I really misunderstood how auto ettr works then - if the failure is not due to too high dr, why would it fail at all? Because the scene changed between ettr eval shots and thus convergence cannot be done?

Correction: you can't use LV to check dynamic range, because ISO in LV is usually very different from ISO in photo mode. Plus, different sampling modes will result in different noise patterns, so I've disabled this indicator in photo LV.

Ok, and I see your reasons to keep ettr & bracketing separate - but even if lv histogram/zebras would work, I (personally) just hate switching to lv, and most importantly often the ambient is too bright to see something anyway.

So... in photo LV, overexposure indicators are OK, but underexposure ones are random.

Well, better than nothing :-> because clipped whites even after highlight recovery are the worst thing to happen, for underexposure I trust my own eyes more to judge.

[a1ex]

Well, auto ETTR is an iterative algorithm; in ideal cases it gets spot on in a single iteration, but:

a) if there's overexposure, it has no way to know how much to go back (and it tries to guess based on how big is the overexposed area); sometimes it works, sometimes not.
b) if the image is really underexposed (say -10 EV), the noise will affect the results, so it will need another iteration
c) if the scene changed, anything can happen

For a) things can be improved by looking at Canon metering indicator (problem: can't read it in M mode on all cameras), or by extrapolating the histogram in the clipped area (based on data from previous shots). If the scene is static, the second approach should be very accurate, but it needs some non-trivial math.

Just solved the underexposure warnings in LV, with the dynamic range numbers from DxO.

[Marsu42]

b) if the image is really underexposed (say -10 EV), the noise will affect the results, so it will need another iteration

Thanks for the explantion, that gives a hint on how to manually expose the first shot to minimize the number of ettr eval shots... and I though the ettr failure also would be a "too high dr" warning instead of just convergence problems.

For a) things can be improved by looking at Canon metering indicator (problem: can't read it in M mode on all cameras), or by extrapolating the histogram in the clipped area (based on data from previous shots). If the scene is static, the second approach should be very accurate, but it needs some non-trivial math.

Holy cow, that *does* sound complicated - but without putting a too fine point on it I'm stunned how you pull these things off anyway, which probably proves I'm not much of an IT scientist :->

Just solved the underexposure warnings in LV, with the dynamic range numbers from DxO.

Great, thanks, would have been a shame otherwise because the raw features are so amazing in contrast "we only do jpeg" Canon.

[a1ex]

Okay, check this one: https://bitbucket.org/hudson/magic-lantern/commits/7382b2586b14

I've just realized that I didn't have to save the entire histogram from previous shot, but just a few key values (e.g. how far the highlights are from the median). If less than half of the image is overexposed, the median would still be correct, so I'll assume the highlight position didn't change.

This is an idea. I've used 3 percentile values (not just median) for better robustness. If the scene did not change, it should be spot on (only one test shot) even if 90% of the image is overexposed.

Of course, for this to work, the algorithm needs a properly exposed shot first. So, if the first thing you do when you start the camera is to take an overexposed image, it will fall back to the old method. But in normal usage I expect it to work very well.

[Marsu42]

Okay, check this one: https://bitbucket.org/hudson/magic-lantern/commits/7382b2586b14

You're doing changes faster than I can test :-p ... but I'll keep trying tomorrow or so, I hope to find the time.