Introducing the filmic module in darktable

(nosle) #51

My understanding (nil really) is that the curve can’t have the “freedom” of a normal tone curve and that it would be incredibly unintuitive to try to push it around like a normal curve. Nodes wouldn’t freely move but get stuck and move based on other nodes.

This is just me guessing by the way

(ph. weyland) #52

Unbreak doesn’t behave as filmic. When we move the middle grey on unbreak we can get back the same histogram tweaking black point accordingly (grey *2 => black - 1).

In case of filmic, the same operation doesn’t produce the same effect.
Descreasing the grey point (and adapting white and black point accordingly, dynamic range staying constant) the center of histogram concentrates to the right, the image moving to high key. Increasing the grey point does exactly the opposite.
Then comes the suggestion. Instead of changing the 3 sliders in sequence every time it would be faster to have a mode keeping automatically black and white point synchronized with the grey point (grey *2 => white/black - 1). It would become faster (and more intuitive) to balance the histogram.

I think you are right. But a kind of middle way could be achieved if it were possible to:

  1. display the calculated control points on the curve
  2. and make them alterable by the user (the program would keep them in acceptable limits).

(Aurélien Pierre) #53

of course they don’t, filmic has a log + tonecurve to remap the log output grey to your display grey. Unbreak has only the log. And the grey slider you have is the log input grey.

yes, that’s a dynamic range compression.

noooooooo :sleepy:

the grey slider is not -black / dynamic range, which is the grey value at the output of the log. It is the scene-referred grey which acts as fulcrum and a pre-amplification before the log.

Your scene-referred grey is the luminance of the grey patch of your color-chart, usually 18%. So we divide the input by this value to remap the input grey to 1. log(x) has a stiff slope for x < 1 and a flatter part for x > 1, so the shadows < 18 % get lifted more than the mid-tones and highlights.

Then, you normalize the log output to [0; 1] subtracting by the black level and dividing by the dynamic range. But now, your new grey value is between 50 and 75 % (XYZ luminance) which would be ok if your screen was logarithmic, but is not since it is gamma-corrected and expect a grey point at 18 %.

So we tune a tone-curve to drop the luminance of the grey to (output grey log / grey display)^(1/gamma), and then, add some more contrast. The last step is to apply a reverse-gamma correction y = x^gamma so that the log + contrast is linearized for the stupid screen/ICC gamma.

(Aurélien Pierre) #54

Which values ? You already have values in contrast, latitude, etc. and their graphical effect, you want me to translate that in another metric ? Which one ? I’m lost here.


See below e.g. When I move the slider, the curve changes accordingly. I think what @gadolf would like is a tiny curve for him to move back and forth using the mouse, to which the slider would follow. It is a novelty really and, in the view of non-visual types, unnecessary.


(Aurélien Pierre) #56

So that’s already what happens in the module. The curve follows the parameters.


:thinking: We’ve been there before. I am thinking he wants something for the s-curve specifically. The curve provided is the sum of all the sliders’ settings, am I correct to say so? And could we move the curve around and have the sliders move automagically? I don’t know; I haven’t used the module myself.

PS @gadolf’s request isn’t that unusual. There are modules in dt that are visual rather than just sliders. In my opinion, the filmic module’s sliders are sufficient.

(Aurélien Pierre) #58

the problem is we are building a transfert function from an interpolation of nodes, not from an analytical expression.

It could be possible to allow nodes -> parameters edition, but that would mean solving the equations the other way around with different constrains on each node and ensure consistency between parameters <-> nodes. With Python and a scientific package, that would be immediate, but that’s a hell of a job in C.

In darktable, there is no module that is visual + parametric in the same time.


Very true. That rounds the discussion nicely. Thanks for your patience. :slight_smile:


It’s Christmas every year, and so are darktable releases. Make sure to keep something for next year :wink:.

(ph. weyland) #61

Please don’t cry, I don’t think I’m saying anything different. Obviously you tell it far better than I do :slight_smile: .

Here with some screenshots to illustrate what I meant (and I think what your maths explain). I use 3 grey values 4, 8 and 16% and adjust with color picker the black and white points:

We can see:

  • dymanic range remains constant (7,65EV)
  • grey multiplied by 2 => black & white decreased by 1
  • histogram moves from one side to the other

Excellent !
But to do so, each time I change the grey I’ve to reajust the black and white.
So my suggestion is, once the module knows the black and white point in function of a grey value, a special mode (lock ?) could control the black and white point when one changes the grey value.
When the grey value is not known, or for any esthetic reasons, I think that would fasten the quest of the right grey value (EDIT: especially when black or white cannot be caught by the color picker !).

(Aurélien Pierre) #62

That’s a good idea. Too late for 2.6, but a good idea nonetheless.

(darix) #63
  1. How much work would it be to do it now?
  2. can we introduce it later without breaking things?

(Aurélien Pierre) #64
  1. less than 1 h
  2. it’s just a UI link between 3 sliders, so yes, the parameters won’t change.

(darix) #65

so do it now?

(ph. weyland) #66

Thinking more about it, no special mode is needed.

  1. When grey value is changed black and white values should always be recalculated accordingly (As a matter of fact their old values are always meaningless, because referring to the previous grey value).
  2. Black and white can be adjusted individually as of now.

(ph. weyland) #67

I’ve made the change on my local copy.
I can confirm that once black and white points are set the grey slider balances nicely the image.
EDIT: I’ve made a pull request in case you wanted to validate the change.

(ph. weyland) #68

I do not work on HDR images, but sometimes I have images where histogram is on the edges letting the middle part a bit lost somehow, even with contrast lowered to 1.
I was wondering if it could be interesting to have contrast values below 1, a kind of global tone mapping somehow…

(Aurélien Pierre) #69

Having contrast < 1 (that is, the slope of the curve) has no justification since the input has already been lifted greatly by the log. Besides, it has 90 % of chances to make the splines go crazy (overshoot and cusps).

New filmic module, doubt
darktable 2.6.0rc0 released

Finally got to try filmic. Found the shaper section to be enough for my purposes. auto tune didn’t perform well, but I think it was mentioned that it doesn’t perform under certain conditions.

I found myself using the dropper tool only for middle grey and then sliders for the white and black. Oftentimes, going to toggle the dropper would accidentally move the slider to its extreme right because the padding between the slider and dropper is negligible. Unsure if anything could be done about that.