there was a discussion on this when the module was introduced - the decision was made as implemented …
I use LUTs for the same reason as you (film emulation). I use RawTherapee’s LUT collection, and they are in the sRGB colour space. Therefore I move my LUT module after DarkTable downgrades the working colour profile to the output colour profile (which is sRGB as well). That way I avoid unnecessary conversions between colour profiles.
There’s a working solution using styles.
you can activate the modules you frequently use an then bring the LUT module to the desired position in the pixel pipe.
Then create a style for this (in darkroom you can use the icon aside of the „compress history stack“ button or the create … button in lighttable style dropdown)
You can deselect all modules except LUt3d and keep „module order“ selected. Then this style keeps the new relative position of LUT 3D module order.
Note: this does not work for any DT version below 3.2.x
Seems to be same behaviour.
I prefer lu3d beeing between the last module dealing with colors (for me thats colorzones) and output profile - so, if i add a vignette this isnt affected by the LUT and the result of the LUT is properly pressed into the output profile.
Quick 5min edit. No LUT used. Probably skin tone needs some fiddling. Also, the shirt at the front has blue tint, I assumed that it’s natural light color. No idea what the scene’s lighting looked like…
test.ORF.xmp (7.6 KB)
@emem Good point I was just going to ask as many LUTS are colorspace specific so just throwing them on might not preserve the desired intent…so not to blame DT if not used properly.
I wanted to learn a bit more about luts and came across this…great article and one key thing is stated that most LUTS are designed for properly exposed and white balanced images and in some case over or underexposed ones but not both…it seems like your image may not be the best candidate in its current form hence the highlight issues…anyway just throwing it out there…that disscussion is about halfway throught this article and admittedly I have only scanned it so need to give it a more careful read Lutify.me | Using LUTs? Here is What You Need to Know
I got a reply from one of the developers who said that the conversion would not be a problem. Anyway, placing the LUT just before or just after the colour output module made no great difference for me. Placing the LUT AFTER Filmic or the Basecurve made a HUGE difference.
Is it recommended to use e.g. the HaldCLUT film emulation LUTs without filmic rgb at all? It would seem that they are trying to do similar things to a properly exposed image. Obviously you would give up highlight reconstruction. Is there a “minimal” set of parameters for filmic rgb that would not interfere with the work of a film emulation lookup table?
These HaldCLUT film emulation LUTs are the ones described on the Raw Therapee film simulation page? Those LUTs seem to be mapping sRGB to sRGB space, basically working in a display-referred space. These LUTs seem to be mostly more with colour mapping rather than tone mapping, so I would say that you would still need filmic or something equivalent to do the tone mapping for you, then you would need to convert into sRGB colorspace before finally applying the LUT.
I think that for film emulation the perfect workflow would be
1)enable lch highlights reconstruction
2)use exposure to anchor middle gray
3)convert to log color space from linear( PQ, slog,…in 0-1 range)
4)use the 3dlut (0-1range)
5)convert to linear
6)tonemapping (for example filmic)
Step 3,4,5 could be done with the same module.
Could the 3dlut module could be improved to support transfer and primaries from log color space too?
PQ is great but i can’t find any film emulation lut for it (and the Darktable’s version is buggy).
https://github.com/darktable-org/darktable/issues/3880
What about “commercial” log color spaces, some are well documented.
The current 3dlut module makes the conversion to the selected color space, applies the lut, and converts back to original color space, between colorin and colorout. Outside it applies the lut directly in the current color space.
I see two point about log luts.
First, if I remember well, most of them transform a specific camera log encoding (like F-log from Fuji) to another, linear or gamma, color space. This is not expected currently (same input and ouput color space).
Then the log color space must properly defined.
1 Like
Yes, they’re both defined
For example slog3 log encoding and s-gamut color space
https://pro.sony/s3/cms-static-content/uploadfile/06/1237494271406.pdf
While for example nikon-log use the standard rec.2020 gamut.
http://download.nikonimglib.com/archive3/hDCmK00m9JDI03RPruD74xpoU905/N-Log_Specification_(En)01.pdf
Some github links that could help
https://github.com/EleonoreMizo/fmtconv/blob/c3f50392c29923053dbbf74a2dca6df0c50815de/src/fmtcl/RgbSystem.cpp
https://github.com/EleonoreMizo/fmtconv/tree/394a360eace1a26d8c43c8e68a772e0018bab612/src/fmtcl
https://github.com/ampas/aces-dev
https://github.com/cameramanben/LUTCalc/blob/8bf64a382eb6a18198f373c7d9f6bd40dbc8e79e/colourspace.js
Thanks for the links. I could add the nikon one to my list.
In case of the fuji, sony, nikon log curves, the camera delivers a raw file where RGB values are log encoded instead of being linear.
In the current state, the user could apply a lut like one the following:
with lut3d module before colorin.
For example with the last one “Sony SLog2 to Rec709.cube” the user should select in “input color profile” the “input profile” called “gamma Rec709 RGB”.
I think that should work but as I have none of these camera I cannot test …