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.
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!
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…
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.
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
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.
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?
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 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…
Thanks. But if that feature is meant for the display-referred workflow, relying on base curves, don’t the base curves replicate the ‘camera look’? If I remember correctly, they are created by comparing the embedded JPG with the demosaiced raw.
basecurves is ‚one size fits all‘ stuff - not a per image comparison to the embedded jpg.
So setting an initial exposure based on the embedded jpg is just for those who want to use exposure compensation like in old slide photography times and expect an initial exposure like the cameras jpg processor does.
That feature is independent of display or scene referred workflow - it’s just the mindset and habits of the user who wants to use exposure compensation in a different way then the designer of the scene referred workflow recommends, maybe to get also proper jpgs out of cam. Different users, different expectations…
No, I don’t use .jpg in camera, but .DNG. It only unnerves me, that in the field I adjust exposure correction for a realistic image and then in DT I need to correct exposure once more, because the exposure Module resets the correction.
Of course I could go ahead and expose by camera lightmeter and then add exposure later in DT. However that would also create noise and that doesn’t sound like a good idea to me.
Good to hear!
I had really liked to have it for my normal, i.e. high quantity, not-so-technically-demanding pictures to increase my editing speed in darktable. Would be a really nice workflow improvement and probably also make a lot of new users less confused about what darktable does to their images.
@MStraeten the improved exposure-picking-tool seems nice but would it actually be possible to use for a what-you-see-is-what-you-get default initial exposure? You would need to always have a known grey patch in the image? The new feature matches a spot to the desired lightness value if I understand the PR correctly (note, haven’t tried it yet so could be wrong).
What I imagine is having exposure-normalization on a per camera model basis or similar. It should for example not fail even for pitch-black lens-cap-pictures or overexposed forgot-to-reset-my-iso-setting-from-last-nights-low-light-session-pictures. You can not rely on only one unknown image on those but would need to match the middle grey value externally, f.ex. similar to how the noise profiles are made.
