Please note that the changed setting will not take effect until you restart darktable. Also, note that the scene-referred workflow defaults are only applied to new edits and when you discard the history stack on an existing edit.
Discarding the history indeed works, opening an unedited pic not. But that’s a great workaround - thanks!
To be clear when I say ‘new edit’ I mean an image that has never been opened in the darkroom. As soon as you open an image in the darkroom, darktable auto-applies some settings and this is considered part of the ‘edit’.
OK, I started again from scratch, new database, no .xmp, now it works fine.
Time to donate.
3 Likes
Would you give a link to the parallel thread, please?
Thanks, especially for the quick response. 
Since that message, I have come across some data that seems to support the +1 EV.
First, some background: ISO 12232:2019 defines various ways to compute an ISO value. Out of those, CIPA mandates the use of either SOS (Standard Output Sensitivity) or REI (Recommended Exposure Index), which are computed as \frac{10\,\text{lx}\cdot\text{s}}{H} where H, for an average scene, is a mid-tone exposure. More specifically, for SOS on a camera that produces 8-bit output, H is the exposure required to produce an image signal level of 118 (so middle gray in sRGB), and for REI, H is the arithmetic mean exposure recommended by the camera provider.
Now, there is another, saturation-based method, which DxOMark happily applies to RAW files (even though ISO values are not supposed to be reported for RAW files) and then calls “measured ISO”. While highly misleading and very frequently misinterpreted, it is still useful information. Saturation-based ISO speed is computed as \frac{78\,\text{lx}\cdot\text{s}}{H} where H is the exposure that saturates the output. (Processed output according to the standard, RAW output in the case of DxOMark.) That value of 78 was chosen so that, for a camera where saturation-based ISO speed coincides with an exposure index (SOS or REI), there is approximately 41% (½ EV) of headroom above 100% reflectance. (We can indeed verify that 1.41 \cdot \frac{100}{18} \cdot 10\,\text{lx}\cdot\text{s} \simeq 78\,\text{lx}\cdot\text{s}.)
Now, cameras tend to deviate from this coincidence, generally in the direction of having more highlight headroom (except for a few Panasonic cameras as I mentioned previously). An analysis of DxOMark’s data by Bill Claff suggests that at least as of 2014, the deviation was heavily centered around 0.33 EV of additional headroom relative to the ISO setting (on top of the ½ EV accounted for by ISO speed), for a total of 0.83 EV of headroom above 100 %.
That means that for a shot metered by an average camera (as of 2014), to get 100 % reflectance at 100 % in the RAW and 18 % reflectance at 18 %, we need to apply +0.83 EV to the RAW values.
A bit OT: At the start of the tutorial there are five pictures in lighttable. You once did a video on the top, left picture that I can no longer find online. I know it is old, but I would like to watch it again. Would you be able to give me a link to it?
just played around with the new highlights reconstrution options and I think it’s really interesting… seems to work well
I am seeing some odd blue behavior again with “luminance” preservation.
Here is one image with “preserve chrominance” set to “luminance” and “color science” set to “v3 (2019)” (first) or “v4 (2020)” (second):
v3 looks fine, but v4 is different in a few regards:
- The sky looks quite a bit darker and more saturated, to an okay extent here but it’s much more pronounced on some other images;
- v4 seems much more sensitive to noise, I really have to apply “denoise (profiled)” (even if at a low strength) for the sky not to be super noisy;
- there are white-ish halos at the edges of the sky.
This is with zero “iterations of high-quality reconstruction” and zero “add noise in highlights”.
What could explain such a difference in behavior? Having a quick look at filmicrgb.c, it doesn’t look like the method for computing luminance was changed for example, it’s just get_pixel_norm (and then dt_ioppr_get_rgb_matrix_luminance) in both cases.
I really seem to only see this with blue specifically.
I can probably upload the RAW if it helps. (I say “probably” because when uploading the images for this post, I was hitting a couple of “Permission denied” with code 422.)
Thanks.
I noticed those halos too, sometimes they can be fixed by moving around instances. I think this happens mostly when you combine filmic + contrast equalizer.
1 Like
Odd blue => don’t use luminance.
It’s simple. If there was one mode that worked consistently no matter the conditions, it would be the only one available in filmic. I don’t add modes for the pleasure of coding more, I hate programming.
9 Likes
Makes sense, thanks and sorry for insisting. 
I guess part of what made me curious was that I didn’t observe such behavior with v3. That made me wonder what could have broken it.
Out of curiosity, is v3 going to stick around in the UI, or will it suffer the same fate as the original filmic?
V3 color science is still available as an option in the filmic module.
v3 will stay at least for some time. I see no reason to remove it, except for the usual “darktable has too many options”.
4 Likes
A couple of UI changes have been merged in filmic v4 these past days.
1. The default graph has got labels
They can be toggled on/off to save space (with the “A” button)
.
I noticed that people don’t get what filmic does because they just get a shape, and not the coordinates. So, I hope this view makes clearer that the scene tab defines the bound of the x axis (input), the display tab defines the bound of the y axis (output), and the look tab defines the shape of the curve, but the scene grey (arbitrarily defined as our 0 EV reference) will be mapped to 18% display.
So filmic is a base curve that scales a look to whatever input dynamic range. On the contrary to the base curve module, the x axis bounds are not dead set to 0-100%, but user-parametric.
2. We have more views
You can cycle through them by left- or right-click over the “refresh” icon (just read the tooltips over buttons, as usual they are meant to avoid reading the manual because I know you all hate that).
Base curve view
This view shows the end product of whole module, including log mapping and final power function, in a linear/linear scale. It is the analog of the base curve, displayed only between 0-100% to be able to compare them. However, you will notice that the white point is not on the graph, but much outside, and you get its value into parentheses (870%).
This is meant only to be compared with the base curve, in the same setting, and maybe understand the difference between them by trying to make them look as close as possible. Whatever point of the curve that overlaps the identity (diagonal line) will exit filmic with the same value as it entered.
Base curve view (log)
Same as before but both axes are log-scaled by the same amount as the base curve, so you get a magnified view of the shadows and of the filmic toe.
3. We have a meaningful view…
It’s been some time that I have been raging about the classical 2D tone curve view, because it represents in 2 dimensions a process that is actually 1D and is more simple that it sounds : we remap values from one range to another. So it’s a very basic game of dispatching values from source space to destination space.
The tone curve view is ok to check if the range mapping is monotonic (because non-monotonic means contrast reversals and non-bijective therefore non-invertible transfer function), but it’s really more an engineer scope than a user-friendly one. And, again, we are looking at a 1D transform.
So here we split the ranges into zones of 1 EV width, following Ansel Adam’s zone system formalism, and we see how they get remapped from source to destination (same as the base curve view, we display the full module effect : log mapping + look + power function). Scene 0 EV (grey) is forever our reference and will get mapped directly to 18% destination. The display has 12.65 EV of dynamic range, which corresponds to an 8 bits sRGB output. Playing with the look contrast, you will see how those mapping lines will contract or dilate around grey.
What you do in exposure module is actually only sliding that input scene range (left or right) to change the 0 EV reference. Then, in filmic, this reference is not touched anymore. It has the desirable property that enabling/disabling filmic keeps the overall brightness unchanged, so you can compare easily how the extreme luminances get remapped.
Also, what if we had an HDR display instead of an SDR one ? Just input 400% in display white and see:
Black and grey haven’t moved one bit, but your “whiter than 20% reflective white” values have been decompressed (notice that darktable as a whole is not yet compatible with HDR outputs, but filmic’s logic can adapt to pretty much anything in and out — this feature is only an educational widget for now).
4. Defaults adjusted
You may have noticed that filmic v4 tends to crush blacks a bit too much. Indeed, the zone views shows that bottom 1 to 2 EV zones get all remapped to 0 % display:
This leads to gradients losses close to black. Also, because the picture will later be converted to 8 bits unsigned integers, there will be some rounding errors in the bottom EV zones. Actually, all pixels values lower than 0.015% display (=(0.5 / 255) / 12.92, assuming sRGB output) will get rounded to 0 (in the 0-255 range). That becomes nasty with HDR input:
So the default display black has been raised to 0.015% to account for that, which salvages 1 to 2 additional zones close to black, depending on settings:
This helps getting smooth gradients even close to black. That new educational view got unexpected effects, I’m stupid to not have thought about that before. Contrast default has also been adjusted to account for that change.
Hope you like these 1300 new lines of code (and in case you do… you can always support me).
17 Likes
Is the advice to consider the dynamic range of the camera when setting the relative white and black exposure still valid?
I often find myself leaving it at the default settings of +4 white and -8 black and the 12 EV are roughly the dynamic range at my cameras base ISO (according to DXO, photons to photons states only 10 EV). But sometimes I find the ‘right’ values to be much more than these 12 EV. The automatic adjustment rarely works with X-Trans sensors even with Markesteijn 3-pass, so I can’t compare.
Filmic doesn’t see the camera dynamic range since it gets massaged before in exposure module and possibly color balance. Just use what works, don’t loose too much time trying to make sense out of measurements and tabulated values you may find on the internet. Filmic input DR may or may not be the camera DR, it really depends on what processing steps (and settings) you input before.