Right. It’s not as if the formula went straight from the ACES.
1 doesn’t mean anything inside your pipeline, it’s just a value. It’s your display that needs mapping to [0,1] and means white when it sees. Let’s not mixup output and pipe, that’s the mistake that got us in trouble 25 years ago.
I think to understand your opinion but one misconception about aces is that is possible to do one single video grading in a scene referred space and then deliver that result for whatever hdr / sdr color space with of course the right color transform.
This is considered bad pratice.
Now, with Darktable it’s painful hard to use rgb curves without the srgb working profile (big limitation in the gamut).
At least take in consideration to modify the behaviour of the curve module so the user have a choice in which gamma the curve is applied.
I’m pretty sure everyone will love this feature and if someone doesn’t want to use curves because thery’re “obsolete” he could just not use this module
Yes, since I teased the display TRC out of my mainline processing, all works nicely.
I’ve had to really wrap my head around it, as in rawproc I can select any tool in the chain to be the displayed image, and that will get display-transformed. Needed to set my expectations such that it shouldn’t be considered unless i selected the last tool in the chain, which is usually a resize/sharpen group for the file output.
What is ?
You can work in sRGB in darktable pipeline, just go to the input colour profile module and set the working colour profile to sRGB. But that has nothing to do with gamut, I think you are lost in colour management concepts. Small RGB spaces are better for some parts of the editing (for colour control from user perspective) provided the soft doesn’t clip out-of-gamut values (and darktable doesn’t). But nothing in there will change your output gamut, and gamma/TRC/OETF is an encoding, not a gamut mapping.
I’m not surprised things don’t work well for you in scene-linear if you don’t understand basic digital colour.
I think you probably meant “tone”, not “gamut”… ??
You make a good point, color and tone are two distinct things that get rolled up into a single entity in ICC and DCP profiles. Very much need to keep their consideration distinct, even when dealing with the combined needs of displays.
Yes I know it but i don’t want to work with srgb working space, i want to work with a wide gamut working space.
I want to use curves too.
Now try to open a raw file, set the working space “rec.2020 linear” and use the RGB levels module to raise the gamma.
After this, changes the working space to “srgb”.
See how the image is different? This is because that module is dependent from the gamma used in the working space.
The rgb curve module works always using the perceptual trc used in lab color space.
I found that a pure gamma 2.2 or srgb it would be a better choice, i use a lot the curve tool in every editor but the one in darktable is pretty much useless because the Lab trc.
Edit:
I wasn’t expecting different behaviours for RGB levels and RGB curves.
But the Lab trc used in curves is bad anyway.
Gamma belongs to output. The module is independant from the output. You get to decide what input, output and pipe colour spaces you want. That’s consistent. A good pipe is a pipe that doesn’t care about the output.
What you are asking for is for the module to adapt depending on the output TRC. So you want a display-referred pipe, but still wider gamut than your display. That makes no sense at all and will trigger a full load of problems you have no idea of.
If it is what you want (and, again, trust me, you will open a can of worms), then use the unbreak colour profile module to force an artificial “gamma-like” transformation.
My friendly advice here is to embrace the scene-linear workflow, learn it, try it, and when you will see by yourself that you no longer mess colours while adjusting luma, and the other way around, , even for dramatic edits, you will understand what is so great about it.
Where did you get the external sRGB profile? Is it V2 or V4? Could you maybe share it?
why are you talking about output?
RGB level are dependent from the gamma used in the WORKING PROFILE in darktable.
I was misleading to think rgb curves share the same behaviour.
middle gray 0.18 is mapped to 0.5 in rgb curves?is this correct?
is this because the lab trc?
from here
Because there is no gamma outside of output display. Every internal data massaging relying on that is pure madness.
In the input profile module it’s possible to select rec.709 profile linear or with gamma as working profile.
Do you understand what is a working profile?
The working profile has gamma if rec.709 with gamma or srgb are selected.
However RGB curves with a Lab trc is “madness”, so please remove the Lab trc in the tone curve module and use something like srgb gamma.
What @anon41087856 means is that the original reason for a gamma construct was to make linear-recorded images look right on CRT displays, which have non-linear response. I haven’t seen it for myself yet, but I am told that LCD displays natively have linear response, but are made to approximate the behavior of CRTs for compatibility reasons. This was the essence of the painful discussions about a year ago on scene- vs. display-referred workflow.
What I have seen for myself is that working the image data in its original “energy relationship” keeps from introducing artifacts longer than if the data is “curved” in any way, then worked. Multiplication (exposure compensation) doesn’t count: while the magnitudes change, their energy relationship stays the same.
Converting to a non-linear working profile, then swinging the data around may be easier with the available tools, but it introduces artifacts and color shifts. And yes, the traditional tools are harder to work in linear space, but that doesn’t mean they can’t be re-organized to accommodate. Right now, I’ve abrogated my use of spline curves in favor of a filmic curve that I control by modifying its coefficients. It works rather well, especially in providing clarity in the darkest corners…
WRT working profiles, I’ve stopped using them for the time being, finding joy in simply working in camera space, then converting to sRGB at the time I write the file.
Yes let’s not go that route again please!
Civility is a requirement to participate here. Let’s keep it above board.
I promise… 
Certainly not directed at you, it was a general comment.
Yes, filmic curves works very well for underexposed photos and they should be used in the early stage of a raw file development.
When you use filmic curves you are just raising the exposure and then fitting the new values in the 0-1 range plus a little contrast in the shadows.
After this point there’s no reason to not use standard curves or adopting a display referred workflow.
Why and when use the cdl tool ?
“To facilitate the transfer of colour intent from the production to the post-production world”
So not really usefull.
The sigmoidal contrast used in imagemagick is probably a better choice
Ruminating on this some more, I went back and picked apart what I’m doing in rawproc to see if there is “room to maneuver” with the curve tool in linear. To the extent that I added a “copy tone curve to the clipboard” button on the tone tool, with the intent to support spreadsheet analysis, and then later to actually copy to a curve tool command. Here’s the outcome:
What you’re looking at are two overlapped instances of rawproc on my desktop, both with the same image open, same processing except for the curve at the end. The ‘behind’ one has a filmic curve, for which you can regard its parameters and plot in the parameters pane. With that processing, I copied the curve as a curve tool command and pasted it into the curve tool of the ‘forward’ one, its curve tool prominent in the parameters pane.
The images are a bit different in tone; I’m attributing that to precision error in the 0-255 integer based curve tool. If you look closely, you’ll see I selected the bottom-left control point; actually, this one is the second point, covering the anchor point at 0,0. That is where the filmic ‘toe’ is captured, and indeed, you can scooch that point around just a teeny bit and influence the darkest tones almost like messing with the B coefficient in filmic.
I selected an interval of 10 for the control point collection, which actually gives room for making minor changes along the curve. It’s easy to introduce unattractive discontinuities, but one can make beneficial changes to specific local tonality if one is careful…
Note that the histogram is not of the display output; my monitor profile is about a 2.2 gamma, so there’s the display reference. This histogram reflects the application of the filmic curve to the linear data. Oh, and at this point in the processing, I’m still working on the camera data, no conversion to a working profile.
I’m going to continue to use just a filmic curve for my tone transform, but I see room to use a curve tool, especially if the dominant transform has to be “negative”, that is, a convex curve.
Ruminations on a Saturday before the holiday break…
With the filmic curve equation is possible to recover data outside the 0-1 range and this is impossible with the standard curve tool.
If you want to roll-off the highlights with values > 1 and add contrast in the shadows, yes filmic is the faster way to go.
But in the end every filmic curves are just exposure compensation + s-curve for contrast.
I guess in darktable the tone curve module use Lab trc because backward compatibility with the old Lab curve.
The new rgb curve module use Lab trc when the “compensate” option is checked.
It would be great to add the srgb trc in this module too
I think Aurélien’s point was that using sRGB as your working profile will not restrict your gamut because darktable doesn’t clip out-of-gamut colors (those where one or two of R, G or B are negative).
You can try it out yourself with transicc from lcms2:
$ transicc -i /usr/share/argyllcms/ref/Rec2020.icm -o '*sRGB'
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]
Enter values, 'q' to quit
R? 255
G? 0
B? 0
R=318.3001 G=-410.4162 B=-59.8131
Enter values, 'q' to quit
R? q
Done.
$ transicc -i '*sRGB' -o /usr/share/argyllcms/ref/Rec2020.icm
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]
Enter values, 'q' to quit
R? 318.3
G? -410.42
B? -59.81
R=255.0000 G=0.0000 B=0.0000
Enter values, 'q' to quit
R? q
Done.
As you can see, if no clipping is performed, then even colors outside of sRGB’s gamut can be converted to it and back with no issue.
Elle wrote an article about the limitations of such an editing workflow, though.