Upon opening RAW files in dt I often see underexposed Images due to the auto exposure compensation. And it really annoyes me. Most DT users have put some effort in their photography and thus choose their settings deliberately. So do I. I take my images using AV mode or M mode. In AV Mode I use exposure compensation all the time and I am doing it for a reason. I don’t want dt to interfere with my chosen settings. It should be up to the user’s intention to compensate for any settings, maybe as an optional function. Is it really necessary to imply this auto settings? It feels counter intuitive to me and many others as well, I’m sure. It would be a great relief to many enthusiasts using DT.
No, just set preferences → processing → auto-apply pixel workflow defaults to “none”. See darktable 4.6 user manual - processing. Or create a preset for the exposure module which fulfills your requirements.
2 Likes
Just create an automatic preset in the exposure module without that box ticked. No need to disable the workflow settings, unless you want to disable filmic as well.
2 Likes
Don’t forget that the image you see in your camera already has a base curve applied, which, in general, brightens the image. If you don’t apply a similar brightening curve, your image will look darker.
The reason darktable normally undoes your exposure compensation by default is because people often use in-camera exposure compensation to save shadows or highlights, counting on post-processing to correct exposure:
- negative exposure compensation to save highlights (at the cost if underexposing the image)
- positive, to retain more shadow detail (at the cost of overexposure).
Those are required because the camera represents the scene as bounded integers (anything less than 1 is clipped to 0, anything over the sensor’s saturation point is clipped to the maximum). Once the image is inside darktable’s pipeline, you work with floating point:
- you can have pixels between 0 and 1 (dark shadows are not clipped to black), and
- in the case of the scene-referred workflow, unbounded from above as well (so a pixel in the scene-referred part of pipeline, before applying a tone-mapping curve such as filmic, can be 3 EV or more above mid-grey, which would have been clipped by the camera).
Removing the in-camera exposure compensation will, in those cases, bring you closer to ‘proper’ exposure, and most cameras require an additional +0.5 … 1 EV (or even more) to achieve a look closer to what the base curve’s brightening effect gives you, since filmic is centred around mid-grey, and won’t brighten midtones.
6 Likes
This setting assumes that people meter on a mid-grey surface or use matrix metering on an average-mid-grey image and then compensate when that produces blown highlights. I often spot meter on the brightest part of the image and then compensate by +2-3EV, in which case the “compensate” setting in the exposure module makes my image too dark – it tries to make the white parts of my image mid-grey.
As you say, though, this setting does work with the most common way of using exposure compensation and for those with a different workflow it can be easily disabled.
9 Likes
I’m afraid your pleas will fall on deaf ears. When I brought this up, I was essentially told “Well, I personally don’t use exposure compensation as an artistic expression, therefore nobody does.”
You have two options:
- use dt’s “display-referred” workflow
or - set auto-apply pixel workflow defaults to “none” as Pehar mentioned, and create auto-applied presets for Filmic and Exposure that best match where you want to start. (This is what I do; I have Filmic just enabled, and Exposure set to +2EV with “auto-compensate” turned off.)
And you shouldn’t alter exposure for “artistic expression” if you’re shooting raw. If you’re shooting raw you want to capture as much of the scene’s dynamic range as possible, get above the noise floor as much as possible, and not clip highlights (first) and shadows (second) if possible. The lightening and darkening of the image can then be done in post and will likley be better than using exposure comp because you’ll end up with better data to work with.
I don’t view this as opinion, rather these are the mechanics of the digital medium.
11 Likes
I think we could do better than the current behavior and that the request by @Daniel_Spenner is valid. I definitely use “exposure compensation as an artistic expression” when not limited by the dynamic range of the camera as it is so much easier to see what you are doing when you can properly chimp!
This leads me to the design notion “what you see is what you get” or WYSIWYG.
Following that principle would in this particular case mean that the default exposure in darktable would be the same as in the camera preview. Or stated in mathematical terms:
Camera jpeg middle grey = darktable middle grey
I think would be a much better default behavior both for beginners and seasoned users. Technically challenging images where you have to adjust the camera exposure such that you maximize the dynamic range usage is after all quite uncommon for even oldish cameras (at least statistically taking the whole population of photographers, some only do sunset images and then that’s another story). Every picture where the result looks good in the preview will also look good with defaults in darktable.
This is not a scene-referred vs display-referred thing, it’s just a design choice and there is nothing technically stopping us from implementing WYSIWYG as the default behavior. You can for example derive it from the “camera base curve” and look for where it intersects middle grey. This value could then either be used as a per-camera-based default “boost” in the exposure module or maybe as defining the middle grey point in the first “raw input” module.
I.e. instead of defining the bounded:
[0, max_int] → [0.0, 1.0]
You map
0 → 0.0
int_middle_grey → float_middle_grey
And extrapolate the rest.
In summary:
Following what-you-see-is-what-you-get is absolutely doable in darktable’s scene-referred workflow. It would probably also be a better starting point for the average photo, i.e. likelier to be what you actually want → fewer adjustments → faster editing!
3 Likes
Since po/exposure next - exposure mapping + new collapsible section by TurboGit · Pull Request #11142 · darktable-org/darktable · GitHub we now have an option for an alternative way - adapt the overall exposure so that it matches the exposure of the embedded jpg.
So one can delegate the initial exposure to the camera manufacturer’s implementation and maybe add an option in preferences to use this by default.
3 Likes
Dt doesn’t interfere with your settings. It just shows your raw data with less processing applied than your camera does .
Well, before filmic I spent most of my editing time partially undoing the effects of the basecurve, or forcing the image within the corset of that curve (and that was after picking the one that looked best for the image, which was in general not the one corresponding to my camera).
So, for me, the in-camera jpeg was definitely not “likelier to be what you actually want”… Am I the only one in that situation?
Filmic et al. turns out to be faster, and easier, especially on images with a bit more contrast (e.g. sun+shade). Even more with a simple style with basic settings for the commonly used modules, adjusted to my situation. Of course, a few more years of experience also helps…
1 Like
This depends on the situation. There is at least one I run into all the time that does interfere and which makes using a preset a must.
The exposure module, using the scene referred workflow, does not take an image shot in M mode into account. It blindly applies any exposure compensation it finds. When shooting in manual mode this should not be the case.
I’ve mentioned this before: Compensate for exposure correction - #3 by Jade_NL
This intelligence might not be that easy to implement, though.
BTW: I do not think that needing to use a preset is a problem in this case, even though it would be nice if darktable would pick this up in the first place.
I’d like to give bring in some additional thoughts on this topic. Disclaimer: I am shooting a canon dslr, which means there is typically not much possibility to recover details from the shadows.
My typical case is bound by other factors, such that I typically do not ETTR in 95 % of the cases. The reasons for that are manifold:
- I need direct feedback for the model or the client (I often shoot for my son’s soccer team or my daughter’s kindergarten, and the children as well as their parents often want to have a look.
- The DR is so high, that I have to optimize for the subject by exposure compensation which blows the highlights but is kind of intentional.
- The scene DR does not require any DR optimization, e.g. when I shoot with flash, so I have room for artistic exposure choices (esp. in combination with 1.).
- I do not have time to fiddle with the settings, as the situation that is photographed may be over when the settings are OK. This often means to set exposure compensation regarding the in-camera jpeg as there is no possibility to automate ETTR, as especially the histogram is based on the jpeg and not on the raw data.
Often, it’s a combination of these. There are possibly more reasons. I understand that e.g. for landscape photography, the constraints are different, as there is often time to do a bracketed shot and select the one with the best DR. Therefore, a workflow choice for the user would be great.
We already have choices of different workflows.
What I object about in this thread (and others) is the “this is the best default for everyone” impression some tend to give. There is no “one size fits all” for this.
I’ve yet to be convinced that changing defaults is a good option, when there’s an easy solution to apply your private preferences when needed (and without any extra action on the user’s part once the preset is set up). The more so, since any change in default settings will break someone’s workflow.
Of course, saying that I assume that the developers have thought about their choice of defaults 
1 Like
Yes. And there are default assumptions on the typical use case for exposure compensation in camera. With workflow I meant purely the automated exposure compensation handling, not other workflow aspects.
This is what this thread revealed, I think.
The good question is which of the two options is a sane default. Maybe it would make sense to ask the users for their preference in this particular case with the first start of darktable. And probably let them confirm with every update. The same could be done for scene-referred vs display-referred.
In particular, to understand the automatic reversal of exposure compensation requires a deep knowledge of the process, and assumes that most photographers are exposing for best raw data and not for the camera jpeg. I think this assumption is wrong. And in particular, the camera manufacturers do not offer reasonable exposure modes that are supporting such a workflow, even if this would be a great thing to do technically. However, darktable does not have to care for the average user, but for the developers needs in a first place, which means that the assumption may not be wrong from a developer’s perspective. I personally can live with both, I just wanted to mention my perspective as it seems to differ a bit from others.
2 Likes
I am surprised: very emotional replies! I have chosen a preset without the tickbox checked as my favorite.
My thread wasn’t meant to question the scene-referred workflow. However I find it obvious that photographing snow or bright landscapes requires exposure compensation, If I don’t want to add exposure in Post. The same ist true for dark environments, where you need to use exposure compensation as well. There should be no need for DT to "correct"this. Or am I wrong?
Sincerely
Daniel Spenner
Thank you for your reply. I am actually surprised by some answers I have received. It seems that people have all kind of workflows favoring or complaining about this behaviour. There may be no universal solution to this.
I didn’t see a reference to the embedded JPG in that PR.
I don’t know if there was but it came to my mind as an experiment that it might be a use case…but on a couple of the images where I tried either selecting some area or the whole jpg…the result was always way too overexposed when applied to the raw…maybe I was doing something wrong but it wasn’t useful in that way for me…
because it’s not yet there, but it’s the prerequisite for FR: adapt initial exposure to embedded jpg · Issue #11346 · darktable-org/darktable · GitHub