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.
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:
display the calculated control points on the curve
and make them alterable by the user (the program would keep them in acceptable limits).
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.
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.
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.
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.
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.
grey multiplied by 2 => black & white decreased by 1
histogram moves from one side to the other
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 !).
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.
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…
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).
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.