Bug #12441

Non-monotonic curve in filmic, resulting image terrible

Added by Matthieu Moy over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git master branch
hardware architecture:


Tested with the RAW file available here:

From the original image (empty history stack, not even the default modules), activating filmic and clicking "auto tune levels" results in a non-monotonic curve, and then obviously a really bad resulting image.

The image is clearly underexposed so I was more or less expecting suboptimal results, but my understanding is that at least the curve applied should be monotonic, so this looks like a bug.

If I correct the exposure before the "auto levels", I also get a disappointing results, but this is probably expected since the image is low-key hence the average is very dark. A picker stoke on the face and I get satisfactory results.

Screenshots attached.

mairi.jpg (85 KB) mairi.jpg Original Matthieu Moy, 12/04/2018 10:42 PM
mairi-filmic.jpg (86.6 KB) mairi-filmic.jpg Filmic activated, auto levels => non-monotonic curve Matthieu Moy, 12/04/2018 10:49 PM
mairi-corrected.jpg (63.8 KB) mairi-corrected.jpg Exposure corrected, white-balance on background Matthieu Moy, 12/04/2018 10:51 PM
mairi-corrected-filmic.jpg (96 KB) mairi-corrected-filmic.jpg Filmic activated, auto levels => strong overexposure (as expected?) Matthieu Moy, 12/04/2018 10:52 PM
mairi-original.jpg (12 KB) mairi-original.jpg Original (sorry, mairi.jpg was the wrong one) Matthieu Moy, 12/04/2018 10:56 PM
Capture d’écran du 2018-12-04 16-10-40.png (1.65 MB) Capture d’écran du 2018-12-04 16-10-40.png Aurélien PIERRE, 12/04/2018 11:11 PM


#2 Updated by Aurélien PIERRE over 1 year ago

Everything is normal here. To get proper results, the dynamic range should be more or less centered in 0 and > 6 EV.

As stated in the doc :

  1. fix the exposure (here : +3.33 EV)
  2. fix the white balance
  3. if you plan on using the auto-tuner, use an high-quality demosaicing with color-smoothing
  4. do the auto-setting on the face. Since the face is the brightest spot, and yet not expected to be white, allow a safety-factor of 20 % (the skin average luminance should be around 77%). Since it's studio work, the auto-setting won't work, so you need to force the grey around 18 % (it's no HDR).


#3 Updated by Matthieu Moy over 1 year ago

Again, I was not expecting miracle, but your article ( says that the curve should be monotonic, and here it's not at all. So, I don't understand what's supposed to be monotonic...

#4 Updated by Aurélien PIERRE over 1 year ago

the curve is supposed to be monotonic if the parameters are properly set. The default parameters are neutral settings that need to be tweaked. Non-monotonic curves are a sign that the parameters are off.

#5 Updated by Pascal Obry over 1 year ago

Just an idea. I had this kind of result and found a pattern. When the image is low-key or high-key the auto-tunner does not work. One really need to use the manual controls. Now I'm wondering if an analysis of the whole image to check if low-key or high-key could help the auto-tunner to find a proper solution to the final equation? What do you think Aurélien? Maybe something to consider at some point.

In my experience filmic works great with landscape with an histogram properly distributed.

#6 Updated by Aurélien PIERRE over 1 year ago

Actually, the auto-tuner is designed specifically for landscapes, e.g. cases where you have an even distribution of luminances over the picture (where median ~= average). Let us recall that the auto-tuner uses the average over the area as an estimation of the grey, the minimum as an estimation of the black and the maximum as an estimation of the white.

That means, of course, non-even luminance distributions will never work because the average luminance is off-centered, and these cases need to be handled manually. Hence the separated color-checkers.

Now, about introducing some low-key/high-key detection: it would be possible to compute the median instead of the average and solve an equation to remap it to the center of the histogram (assuming a gaussian distribution), but that would sort of neutralize the intent. Although I think the proper way to do it would be segmenting the picture and taking the average of the most significant segment (but the definition of "significant" remains to formulate : the widest ? the brightest ? some weighted combination of both ? etc.) and that begins overkill already.

But I think the problem is rather at the user level: low/high-keys are artistic choices that artists will want to tweak themselves manually, and are easy to copy/paste from one picture to another provided a controlled lighting setup has been used. So I see little interest to have it automatized. For this purpose, I feel the grey color-picker applied on the region of interest would be the best quality/cost ratio and prevent the already cluttered UI from becoming a true aircraft cockpit.

#7 Updated by Masoud M over 1 year ago

I think the "normal" behaviour of this iop is sometimes hard to understand for an average user. Another example to demonstrate it is this photo: Just try to get an acceptable result from it using filmic to see what I am saying.

#8 Updated by Aurélien PIERRE over 1 year ago

I don't know what an average user is. There are all kinds of people who use darktable, from professionals to beginners, so at some point, we build tools that solve our problems and users follow and learn, or they don't. The good news is now you have a full doc:

#9 Updated by dar ix over 1 year ago

IN reply to comment #2 and #6 are those properly documented in the manual already?

#10 Updated by Matthieu Moy over 1 year ago

Note that with, I'm not getting the non-monotonic behavior anymore on this image. I do get an "ugly" image, but it corresponds to what I expected from an automatic tool: the module tried to "properly" expose the background, i.e. make it dark grey so the low-key aspect of the image is lost, but there's no contrast inversion nor over/under-exposed parts. IOW, it's wrong artistically speaking but technically "well exposed".

#11 Updated by Aurélien PIERRE over 1 year ago

dar ix wrote:

IN reply to comment #2 and #6 are those properly documented in the manual already?

Not yet, I'm still building the full doc and the manual will be a trimmed version of it, for practical purposes.

#12 Updated by Aurélien PIERRE over 1 year ago

  • System changed from Ubuntu to all
  • % Done changed from 0 to 100
  • Target version set to 2.6.0
  • Status changed from New to Fixed

Also available in: Atom PDF

Go to top