Enhanced ETTR request

[garry23]

Currently we have three great ML ways to guarantee we take a set of brackets that cover a scene's  required dynamic range capture, ie the important highlights and the important shadows.

First we can meter and calculate the required bracket set then uses ML bracketing.

Second , we can use auto bracketing in ML, but 'loose' control of the number of brackets.

Thirdly, we can use AETTR, meter for the highlights and adjust from the 18%, zone V to, say, zone VII, use this as the base exposure and invoke AETTR to capture the calculated ETTR one. You thus end up with two brackets, a user selected highlight and an ETTR. But these two brackets may be too far apart for post processing.

What I am proposing is an ETTR enhancement is to give the AETTR menu one more variable, namely the number of images to evenly take between the base exposure and the ETTR one. At the moment this is zero. In other words no intermediate brackets.

The new user variable, between 0 and 9, say, will insert that number of brackets, evenly spaced between the base and the calculated AETTR.

This enhancement of AETTR will bridge the benefits of advanced bracketing and AETTR.

Finally, I'm not a programmer but would like to know how to take a module and tweak it, ie turn of to text, tweak it and recompile it. 

Cheers

Garry

[painya]

What I am proposing is an ETTR enhancement is to give the AETTR menu one more variable, namely the number of images to evenly take between the base exposure and the ETTR one. At the moment this is zero. In other words no intermediate brackets.

The new user variable, between 0 and 9, say, will insert that number of brackets, evenly spaced between the base and the calculated AETTR.

Like HDR ETTR? With multiple exposures?

[garry23]

We mustn't get confused by using HDR terms.

What I am proposing is using the AETTR module to create a bracket set to cover the DR of the scene.

If you then wish to use this bracket set by throwing it at an HDR programme that is up to you. You can also use the brackets with a Enfusion engine or manually blend in photoshop.

[painya]

Sorry if I'm not understanding. Wouldn't having a module that covers the entire DR of a scene make the picture flat (speculation)? It seems like the only think that would need to be implemented is a calculator on the existing "advanced Bracketing" feature is a calculator that calculates the DR of a scene.

[garry23]

I'm sorry if I'm confusing you. As we know our camera sensors will max out at the extremes for a large DR.

The power of the AETTR module is that by starting with a protected highlight shot, the AETTR algorithm will give us a reasonable image at the 'other end'.

Many times the delta exposure between the highlight shot and the AETTR shot is too great, eg more than say 2EV.

By allowing the AETTR module to insert some intermediate shots, we 'fill in' between the extremes.

How the user then uses these brackets is a post processing choice.

Cheers

Garry

[painya]

Alright thank you. English isn't my native language and I appreciate you explaining it.

[Audionut]

Many times the delta exposure between the highlight shot and the AETTR shot is too great, eg more than say 2EV.

4EV spacing is what you should probably be shooting for.  There are some tests somewhere to show this, which I don't have the time to search for.
But consider this.  Do you think midtones are captured with sufficient detail?  Midtones are 4EV below FWC.

There isn't anything else to 'fill in'.

[Marsu42]

Second , we can use auto bracketing in ML, but 'loose' control of the number of brackets.

You're correct, you loose control because you don't know the dr of the scene - I understand you're suggesting combining ettr with auto-bracketing to gain more control and thus reduce the number of brackets?

Imho this is a good idea since the unexpected and excessive number of frames with auto bracketing is the reason I never use it, currently it goes on shooting until you've mostly (but not always) got two trash pictures at the ends. Finding a way to predicting the number of brackets with a given ev step and being able to set an allowed "weight" of highlight/shadow cutoff or some other measure of control would be welcome.

Edit: With ettr, auto-bracketing could also gain an "auto ev spacing" if you pre-set the fixed # of shots you're willing to take!

[a1ex]

The predictability part is a good argument, but this gets hard for night shots. Besides that, I'm not sure if doing auto bracketing from raw histogram instead of the jpeg one has significant benefits (sure, you will get pretty much the same amount of noise in shadows for each bracketing attempt; how important is this?)

A simple tweak is to use similar percentile values as in ETTR for highlights are shadows. Did anyone try the modification I've suggested here? http://www.magiclantern.fm/forum/index.php?topic=8960.msg84863#msg84863

[garry23]

All

I fully appreciate all that has been said, eg about night shooting. I am not suggesting the AETTR tweak as a replacement for other bracketing protocols.

I see the proposed tweak as a way to give the user an option to bracket within the AETTR.

Thinking about a bracketing strategy, I wonder if it would be better to try something like this. If the base exposure is more than, say,  X EV away from the AETTR calculated exposure, then insert as many extra brackets at, say, Y EV as required, where Y is user defined.

Thus if the user enabled the additional bracket feature, ie used a non zero value of Y, say, 1, 2, or 3, the AETTR  calculation would work out how nanny additional brackets to insert.

I believe this AETTR addition would extend the power of AETTR and cover the situation, for example, in a church, where you would meter the windows and adjust for the correct zone, then AETTR would take an image for the windows, calculate the AETTR and insert 'extra' brackets at Y Ev as required, ie to fill in. Using this strategy the AETTR only inserts additional brackets if the extreme brackets are far apart, say, greater than Y + X Ev.

In this mode the user is expecting brackets, if needed. This feature would be switched off if Y was zero.

Cheers

Garry