Hello everyone, this is my first time posting here!
I was wondering about how darktable handles differences in what color space consecutive modules in the pipeline output/input. If I hover over a module, I can see what input and output it expects. For example for color look up table:
input: linear or non-linear, Lab, display-referred
output: linear or non-linear, Lab, display-referred
This made me wonder what darktable does if the module immediately before it does not output exactly that? I assume it makes some automatic conversion which for converting between RGB and LAB should be somewhat straightforward. However, how would it handle a conversion between scene- and display-referred and back? In my understanding, there is no single ācorrectā way to do this conversion. The conversion allows for some artistic freedom for example in how strong the contrast should be. Making these artistic choices is exactly what the parameters of the tone mappers are for, no? I imagine the conversion back to scene-referred as even stranger as there is no module that does such a thing.
Up until recently I thought it would avoid having to do such a conversion by placing all modules that work in display-referred after the tone mapper in the default ordering. However, color look up table is placed well before the tone mapper by default.
However, it makes sense that darktable must be able to do such a thing because
a) we can export images even with no tone mapper enabled so there must be some ādefaultā tone mapping that it does.
b) we can import jpgs and still edit them with modules working scene-referred so there must also be some way darktable does that mapping.
Thanks for any explanations/pointers to further reading!
There is nothing like that. But if a display referred module is between two scene referred modules the data will be truncated to fit the display referred modules. Thatās why we encourage to use only scene referred modules or if really needed use a display referred module at the end of the pipe.
I think itās better to say it may be truncated. contrast equalizer is an example, which is Lab-based, but does not truncate. But I may well be wrong.
It says that it works in display-referred yet by default it is placed on early in the pipeline? And I did not thank that using it was discouraged. And if there is no conversion why is it said to work in display-referred?
Iām not familiar with its code, but I assume it fits some kind of curve to the samples / interpolates and extrapolates the adjustments. Still, it probably works in a space thatās designed for āscene-referredā values, and whose design assumptions may not hold up well if pushed hard, or for extreme luminance levels.
Iām not familar with the code in that module either but I think many of these modules will work in Lab and go through conversion to XYZ and then RGB for the working space and on to the next moduleā¦ Whether certain module clip or not I canāt recall which might in the older ones and which might not but where it comes into play is the UI and if it expects display range data then its controls are going to work in 0-1 display space even though data is not clipped. And for some modules a perceptual nonlinear space will have expect gray at 50% not 18% as it would be for the linear modulesā¦ Also you anchor the middle gray with exposure and can use the fulcrum and some pivots in some scene referred modules to compensate and control how they will work for contrast.
Some of the nuance of this and a better explanaiton is in the often cited notes found belowā¦and there are references to this behaviour specifically for levels and curves and some comments on several other modules but I donāt think CLUT module gets mentionedā¦
In any case it and several other modules can be used esp if done with restraint on the severity of the adjustement and they will work just fineā¦ If you get the result you need then your are away to the racesā¦
I think thereās a misunderstanding: 50% comes from the Lab L value, 18% from linear RGB encoding. In RGB, mid-grey is at RGB (0.18, 0.18, 0.18), Lab(50, 0, 0), no matter if you are before or after the tone mapper.
While you are right, so is @Priort; in a perceptual space (like sRGB, and Lab) middle gray is at RGB=(0.5,0.5,0.5), Lab=(50,0,0), i.e. in the middle of the ligthness scale. In a linear encoding, mid gray is at (0.18,0.18,0.18).
And indeed, that doesnāt depend on where you are relative to the tone mapper.
It does mean that the LUT module (in its default place in the pixel pipe) does two conversions: first from linear to Lab, then from Lab to linear. But itās not the only module that does conversions from the āglobalā working space to its internal local working space (and back on exit; iirc, color calibration does so as well).
Thatās a different definition of mid-grey. Linear 0.18, or L=50% would be 46.1% in sRGB encoding, I think. But darktable never uses encoded values in its pipeline, as far as I know (maybe the LUT 3D module does, it has an application space).
Anyway, what I meant to say is that the same luminosity is kept for mid-grey, and as long as the encouraging is the same, it does not matter whether we are before or after the tone mapper.
And now, after a coffee, I re-read Toddās answer, and I see he did make the perceptual vs linear distinction, so probably the only one who was confused was me. My new-yearās resolution should be not to read and comment before .
My new-yearās resolution should be not to read and comment before 
.