[WONTFIX] Auto ETTR with FEC when using flash

[LebedevRI]

The most obvious example of the use:
Camera is in M mode, flash mounted in Hot-Shoe and powered on.
The camera shutter speed, aperture and iso are manually set not to "auto" value.
To reach proper exposure, flash output is changing.
Flash Exposure Compensation is flash analog of camera's standart EC (in non-M modes), so by changing FEC we can do ETTR.

I think that ETTR computation of FEC is possible only by shot, not in Live View.

Would it be possible to have such a modification of ETTR?

[a1ex]

Well... the biggest problem here is that variation in image brightness is not going to be proportional to flash output IMO.

So, to solve this, you have to compare an image with and without flash (or two images with flash at two different levels) and figure out from there the contribution of the flash on each part of image. That's quite similar to a depth map (3D reconstruction of the scene).

There may be big complications if the scene is not static.

I have no idea how Canon does it, but a proper implementation requires very complex math. I doubt a naive implementation will find the solution after say 3-4 test shots (though I didn't try).

[Marsu42]

So, to solve this, you have to compare an image with and without flash (or two images with flash at two different levels) and figure out from there the contribution of the flash on each part of image.

Afaik that's how Canon ettl works, they measure the raw scene / preflash difference - that's the way they are able to separate ambient (ec) & flash exposure (fec) in auto modes. And I guess it's a very complicated calculation.

Flash Exposure Compensation is flash analog of camera's standart EC (in non-M modes), so by changing FEC we can do ETTR.

... but you will only ettr the parts lit by the flash, not the background with the ambient light (you need to change shutter or iso for that), so you will get proper exposure using your ettr idea, but of a different shot :-p

[a1ex]

You can experiment with the ETTR indicator (manual adjustments), but I doubt it will be exact (though better than nothing).

[LebedevRI]

... but you will only ettr the parts lit by the flash, not the background with the ambient light (you need to change shutter or iso for that), so you will get proper exposure using your ettr idea, but of a different shot :-p

Yes, that was my point.

You can experiment with the ETTR indicator (manual adjustments), but I doubt it will be exact (though better than nothing).

Well, yes, i can manually experiment with that.
This is why i'm asking is it possible to implement such a behaviour in ETTR module?
Or, more correctly, is there any hope to see this implemented in nearest future?

[Marsu42]

Yes, that was my point.

In this case surely it's possible, but with a lot of more trial&error with fec then vanilla ettr because flash output indeed isn't that predictable - so the bottom line is you might be better off using flash bracketing on the flash and look at the raw zebras in img review for overexposure.

[Audionut]

Dial in your ambient settings, set the flash to 1/8th power (manual), take a test shot and go from there.

I don't see how ML could ever ETTR with flash.  FEC is based off E-TTL (varies).  Flash power also varies (with charge time).  The ETTR routines would be in a constant state of adjustment.  Not to mention all the specular highlights.

Fill light is a ratio of ambient light and flash power.  ETTR the flash part of the exposure, will destroy that ratio which won't be recovered in post.

In fact, all flash is a ratio of ambient exposure vs flash power.  Flash is a creative choice of light and shadow, not a, blast the scene with flash at the best ETTR.

[Marsu42]

Flash power also varies (with charge time).

You could circumvent this with waiting a little since ettr isn't about speed anyway, I do it all the time when doing focus stacks with flash.

But I agree that apart from implementation issues I also wouldn't want to flash the subject as strong is possible - unless you have 100% flash exposure and 0% ambient which I never do, but the op may very well want that for specific shots and I try to never tell other people what they really want :-p

[Audionut]

and I try to never tell other people what they really want :-p

Explaining fundamental flaws in technique is not, "telling them what they really want"!

In my experience, no ambient - blast it with flash, the camera exposes TTR automatically.

[Marsu42]

Explaining fundamental flaws in technique is not, "telling them what they really want"!

Actually I didn't think of you, it was rather me because I nearly started to lecture about flash usage because I do 2/3rd of my shots with flash. But imho the op hasn't indicated any lack of technique knowledge either, unfortunately he didn't tell us what the actual usage case was (I can imagine very creative multi-flash setups w/o ambient).

In my experience, no ambient - blast it with flash, the camera exposes TTR automatically.

Yes, but as usual for only jpeg - thus an automatic exposure correction like ml ettr for raw would make sense, it just seems it's tricky to do a reliable implementation.

[Audionut]

Yes, but as usual for only jpeg

Huh?  The camera meters the same regardless of file quality setting.

It takes 2 seconds to adjust the FEC in this situation (all flash - no ambient) as the lighting remains constant.  It's going to lead to more consistent results by doing it with the current methods.

The biggest issues I see with doing it ML AutoETTR.
It needs a flash mode (easy).
It will never compensate for E-TTL metering.  It's going to hunt a lot, and the devs will end up with a ton of bug reports!
You could use manual flash.  Needs control of the flash.  Is this even possible yet?
It will require the user to give the flash sufficient charge time.  More bug reports!
There isn't sufficient specular highlight control (IMO) in the AutoETTR for flash.  Underexposed images, more bug reports!

I've discussed my ideas for better specular highlight control with a1ex.  He mentioned the increase in complexity and I was happy with his answer.

edit:

(I can imagine very creative multi-flash setups w/o ambient).

If you're going to the trouble of multiple flashes, you should be going to the trouble of manually ensuring correct exposure.  Multiple flashes means multiple light source ratios.  Where does ML step in and make adjustments?  Which of the multiple flashes does it adjust?  All of them?  The key light?  Way, way to advanced for any sort of automatic mode IMO.

[Marsu42]

Huh?  The camera meters the same regardless of file quality setting.

You lost me there - isn't the whole point of raw ettr that Canon auto-exposes only for jpeg white clipping while ettr can use the whole available dynamic range? The same of course goes for (e)ttl metering.

It takes 2 seconds to adjust the FEC in this situation (all flash - no ambient) as the lighting remains constant.

Which of the multiple flashes does it adjust?  All of them?

Yes, all of them, as you said anything else wouldn't make sense - and auto-raising/lowering the flash power until no clipping is there wouldn't hurt (but It wouldn't help me personally either).

and the devs will end up with a ton of bug reports!

You're raising an intersting point - should ml abandon or not do features that are feasible to implement because more complexity generates more (perceived) bugs and the devs fear invalid bug reports? Imho no, because ml is a power user fw and at some point you have to figure out for yourself what works when - not each and every bug reports requires an elaborate answer or attention.

The biggest issues I see with doing it ML AutoETTR.
It needs a flash mode (easy).
It will never compensate for E-TTL metering.

Agreed, I also thought about that more than once but never posted a flash-related feature request (except for auto-switching to hss) because ml isn't tested or designed at all for flash photography, the current features relate to one pop-up Rebel flash.

On the implementation side research is also stalling, one problems is that the flash prop afaik isn't completely researched yet and most of all it isn't available all the time :-( ... see http://www.magiclantern.fm/forum/index.php?topic=3920.0

It will require the user to give the flash sufficient charge time.

Well, at least this is solvable - when shooting often with your flash you have a pretty good idea how long it takes to charge, and you can set this delay like I always do in focus stacking.

[Audionut]

You lost me there - isn't the whole point of raw ettr that Canon auto-exposes only for jpeg white clipping while ettr can use the whole available dynamic range? The same of course goes for (e)ttl metering.

The meter in cameras, expose for 18% (middle grey).  It's got nothing to do with quality settings (raw vs JPG).
In a nutshell, in evaluative metering mode, the camera takes a look at all the of the information from the sensor.  It determines where middle grey should be in that information and exposes to make that middle grey, be middle grey. 

As I mentioned in this post.

It all boils down to how much dynamic range the scene contains, and where 18% (middle grey) (or 12% or 13%, take your pick) of the overall luminance level of the shot is.  With a large dynamic range scene, 0EV on the Canon meter is going to be accurate, because it's got lots of detail (data) to determine precisely where the correct (18%) exposure is. 

On scenes with limited dynamic range, there often might not be enough detail (data)/(information) for the camera to determine where a correct exposure is.  And it will tend to underexpose, or, more precisely, not push the exposure to the right hand side of the histogram where the sensor is performing at it's best.  In this case, ETTR will net you a much better (cleaner, and more accurate color rendition) shot of the scene.

In other words, when you ETTR, you are saying to the camera.  I don't want you to meter for middle grey, I want to meter to ensure that as much of the data as possible, is captured to the right hand side of the histogram (where signal to noise ratio and color rendition is best).

Again, it's got nothing to do with JPG vs raw.  Having raw data available to ML simply means that the histogram and zebras and spotmeter are accurate, and not influenced by the JPG preview that the camera generates for the pretty picture on the LCD.

Yes, all of them, as you said anything else wouldn't make sense - and auto-raising/lowering the flash power until no clipping is there wouldn't hurt (but It wouldn't help me personally either).

And what happens if your hair light (or fill light, or key light, or background light) is already at maximum output!  You will destroy the ratio balance of your lights.  One of your other lights with be ETTR, but big deal!  How your lights are interacting and producing the shadows is of much greater importance then one of them being ETTR.

You're raising an intersting point - should ml abandon or not do features that are feasible to implement because more complexity generates more (perceived) bugs and the devs fear invalid bug reports? Imho no, because ml is a power user fw and at some point you have to figure out for yourself what works when - not each and every bug reports requires an elaborate answer or attention.

ML should develop useful features.  Period!  This is clearly not a useful feature.  This is a feature designed to help someone who doesn't know any better, produce shitty flash exposures.  But hey, it would be ETTR!
Also, just to clarify, developing a feature that would basically be useless in E-TTL mode (the default flash exposure mode), and will lead to unexpected results, is not smart!  That's why there would be bug reports.  Nothing to do with stopping developing features, all to do with not developing silly features that would break otherwise perfectly fine operation!

Please don't pick apart my posts.

[Marsu42]

And what happens if your hair light (or fill light, or key light, or background light) is already at maximum output!

Yes, of course you're correct, though when shooting w/o ambient you don't need to push flash power that much and the flashes will also recycle faster.

ML should develop useful features.  Period!  This is clearly not a useful feature.  This is a feature designed to help someone who doesn't know any better!

Well, but this is the reason for these feature reqest topics, isn't it? Now that it has been established that this feature is only seems useful to the op because he doesn't know and better, he will be content and strive to learn to do better in the future - and ml can focus on other features that are acknowledged as useful.

Please don't pick apart my posts.

Hugh? I admit I don't understand that - you don't want me to quote individual parts of your post? That is common practice in forums, and you just also did it yourself, so I thought it'd be ok to adopt the technique.

[Audionut]

Yes, of course you're correct, though when shooting w/o ambient you don't need to push flash power that much and the flashes will also recycle faster.

What's needed to shot a scene, and what people do to shot a scene are 2 totally different things.

Hugh? I admit I don't understand that - you don't want me to quote individual parts of your post? That is common practice in forums, and you just also did it yourself, so I thought it'd be ok to adopt the technique.

There is a clear difference between quoting parts of a post, and nitpicking a couple of words here and there to suit your agenda.

Take the bug report discussion for example.

I listed reasons as to why this feature would not work.  I then used an increase in bug reports as one of the results from implementing this feature.

You picked my example of increased bug reports without any regard for the entire post.

should ml abandon or not do features that are feasible to implement because more complexity generates more (perceived) bugs and the devs fear invalid bug reports?

I then went on to clarify that the bug reports in this example would be as a direct result of breaking an otherwise perfectly functional existing feature.

"Also, just to clarify, developing a feature that would basically be useless in E-TTL mode (the default flash exposure mode), and will lead to unexpected results, is not smart!  That's why there would be bug reports.  Nothing to do with stopping developing features, all to do with not developing silly features that would break otherwise perfectly fine operation!"

And again, instead of taking the entire response of mine into consideration, you picked just the section of words that suited your needs to continue discussion.  Let me try once more to convey my thoughts in a manner that you will understand.

Bug reports are good!
Developing features is good!
Developing features that will break existing (perfectly fine) functionality is not good!  Not only will you have developed a feature that has no real merit, you have broken an existing feature.  Apart from the obvious problems with doing that, you will also cause an increase in bug reports that otherwise would not have been generated, if you had not broken existing functionality in the first place.

because ml is a power user fw and at some point you have to figure out for yourself what works when - not each and every bug reports requires an elaborate answer or attention.

There is a clear difference between genuine bug reports, bug reports created due to lack of knowledge on how things work, and bug reports created via poor development choices.

ML doesn't have a closed development loop.  Code delivered to the unified source tree is available in an instant to all users.  And with the recent raw recording developments (and hence the increased availability of compiled builds for people who otherwise wouldn't have access to the new code), some increased care must be taken when committing new code, IMO.  Code can no longer be committed with minimal testing on the expectation that the source is somewhat of a closed beta scenario.

And in my honest opinion, all bug reports require attention.  Whether that's marking them correctly for the benefit of other users.  Acknowledging them as genuine bug reports for debugging.  Explaining correct functionality, or otherwise just acknowledging users and there issues.  This takes time, time otherwise useful for further developing.  And IMHO, the ML development team should consider some choices moving forward.  Either further dedicated moderators to deal with the resulting increase in discussion (including false bug reports), or a closed beta loop where fresh code is only available to a closed testing group, who have a great understanding of existing functionality so as to minimize time wasted in debugging.  But I'm sure I'm getting off-topic here

And this is all in my opinion only!

[Marsu42]

Bug reports are good!
Developing features is good!
There is a clear difference between genuine bug reports, bug reports created due to lack of knowledge on how things work, and bug reports created via poor development choices.

Thanks for explaining, we do agree on the principle, though of course it's difficult to put bug reports 100% into either category - as far as I understand it you placed the flash ettr feature into both lack of knowledge and poor development choice.

And only now I understand what you meant with "taking apart" and I can assure you I have absolutely no intention of "nitpicking" you posts, why would I? While we sometimes seem to have different choices and/or perception of words (no surprise since English isn't my native language) I quote you messages as I understand them with no ill intent - and I'm always happy to stand corrected if I got it wrong, that's why I sometimes paraphrase some issue and not to twist anybody's words - please do give me the benefit of the doubt.

I would like to see more flash-related features in ml, and the "flash didn't reccycle" or "flash output maxed" problems will be always there, though imho the main problem might be that ettl metering and x-sync conflicts with a ml-changed shutter/aperture.