Hi all, had to create this account just because this is bugging me. Why? Because I finally made a nice preset that I’m content with for now, but it looking way off when exporting.
I understand the concept of color management. But wondering if this could be helped or not.
Input color profile:
Input: standard color matrix
Working profile: Adobe RGB (or sRGB, doesn’t matter)
Output is set to sRGB
Now when I export without a LUT, it looks fine. When I turn the LUT on, the export is over saturated + too much contrast. It doesn’t matter what LUT I use. Same for where I put it in the pipeline. Even if I set the working profile to sRGB it looks off after export. Thumbnail looks like the export.
Only when I put it on linear Rec2020 it looks fine after export. But the whole preset looks off and I have to change everything and try to get close to that look I’ve had, but it’s just not it, I can’t get it to look like I want to with Rec2020. So does it have to do with the fact that the LUT is too big for sRGB/Adobe RGB?
Is your display calibrated?? Some examples of what you describe will be helpful…
As noted by @paperdigits you want the wide gamut of linear rec2020 as a working profile…your output and display profile will handle the color management…On that note what are you using for a display profile…I am curious because I don’t think choosing rec2020 as a working profile should be impacting things as much as you are experiencing??
Sounds like you are perhaps applying a log video LUT to image data.
Basically LUTs are designed for different image data. Some work on SDR sRGB, some on flat HDR raw-like data, some on log video captures. Without knowing the LUT in question, we can only speculate.
I have a similar issue. I’ve been working with darktable for a while with no color issues when exporting until I started using LUTS. The luts I’m using are created for AdobeRGB and my working space is AdobeRGB. The LUT module is set after FilmicRGB in the pipeline. My export space is AdobeRGB. Everything looks how I want in Darktable. When I export and open in photoshop in AdobeRGB working space, the hue is warmer than when viewed in Darktable. If I turn off the LUT, the image in Darktable and Photoshop look the same.
The interesting thing is the thumbnail view when the LUT is on in Darktable looks like the image in Photoshop. When I open the image in Darktable it looks how I processed it.
I’ve attached the LUT of you want to experiment. Darktable seems to react with any LUT I’m using though.
Below is the image in Darktable with the photoshop window overlayed.
I just did some more experimenting. When I make the grade how I want with the color space for the LUT in Adobe RGB for which the lut was designed for. Then when I export I switch the LUT space to Linear rec.709. The colors are way off but when I bring it into Photoshop the image matches.
Below is the image when the color space is set to Linear rec.709. I exported this image and opened in Photoshop.
Now I switched the lut back to AdobeRGB in Darktable and the images now match. Not 100% but very close.
I would attache an image but I’m only allowed 4 image imbedds.
I have a suspicion that the LUT module in Darktable is not set right to read the application color space properly and defaults to rec.709.
When using 3D LUTs + filmic, there are a number of colour spaces at play:
your working space; normally, this should be a linear, wide-gamut space;
then you have filmic, which tries to massage your image so that its brightness fits within limitations of the display (HDR → SDR tone mapping), and also tries to get the colours inside what is defined by the output color profile; but, as far as I know, after filmic, the data is still encoded according to the working space;
LUT 3D takes your data and the LUT. You tell it what space to use to apply the LUT (in what colour space the LUT itself expects its input and produces its output; what space the mapping is defined on). According to the docs: Cube files are usually related to REC.709 while most others are related to sRGB. So it takes your input (in the working space), converts it to the application color space, applies the mapping, and then converts from the application space to the working space, again.
Finally, the output profile converts the data to the desired output space.
Unfortunately, I cannot tell you where it all goes wrong. :-/ We’ll need an actual developer for that, not just a talkative busybody like me. :-/
That makes sense, It seems to me that the OP is trying to match the working space to the selected input setting in the module for the LUT and not assuming the colorspace selection alone will map the working space and take that to the selected colorspace for the LUT.
It might be hard to gather that small nuance from the manual description.
application color space
A 3D LUT is defined relative to a specific color space. Choose the color space for which the selected 3D LUT file has been built. Cube files are usually related to REC.709 while most others are related to sRGB.
Also, the interpolations it mentions in the manual are cited as not that different usually but might be worth trying incase these LUTS might benefit from an alternate mapping…
Just one more thing to try: if you re-import the exported JPG (or TIFF etc.) into darkable, does it look like the one you saw when editing the raw (you can make a snapshot in the darkroom, then switch to the exported version to compare)?
If it looks (almost) the same, there may be a colour management issue outside of darktable (e.g. different display profile in darktable and in Photoshop). But then that should not really be influenced by using a LUT or not.
Yes I mean thumbnail when viewing in Light table view. I create my own LUTS using color.io that is created in the AdobeRGB color space. In any case when working with LUTS general rule of thumb is to take a scene referred space (camera) transform it into a display referred space (AdobeRGB, Rec.709 or sRGB etc) or working color space like ProPhoto and apply a lut that expects the display referred space or working space you are working in and then transform it into your output space which generally is a display referred space like Rec.709 or DCI-P3.
For example, when I work with video footage from a RED camera, it may be in scene referred REDWidegamutRGB. I’ll convert from that color space to my working space which is DaVinci Wide Gamut. I’ll apply a LUT that expects DaVinci Wide Gamut. Afterwards I’ll then transform it to a display referred space which usually is Rec.709 for output.
I’m following the same pipeline in Darktable. Again I think Darktable is somehow reading the AdobeRGB in the Darkroom but when exporting it may be expecting Rec.709 and exports with Rec.709 applied and not AdobeRGB. This would be my reasoning for why my exports are fine when grading the image with the lut set to AdobeRGB but then switch the colour space when I’m finished to Rec.709 in the lut module before exporting. This also may explain why the thumbnail view in light table looks like the image with Rec.709 LUT color space. It’s reading the LUT using Rec.709 instead of AdobeRGB when building the thumbnail.
OK, sorry, having a large image in the middle of the window confused me – I did not zoom in to see that it was, indeed, the lighttable thumbnail.
Reading the code, I don’t see a difference between using the export pipeline or not:
If I understand correctly, d is the module’s config (the params, the LUT itself, and its size), d->params.colorspace is the application space set in the module.
When I export as tiff and then reimport it, it looks the same as when brought into Photoshop. see DT Light Table below with the thumbnails. The RAW file is on the left. The Tiff is on the right. The center image is in Photoshop. When I open the Tiff in Darkroom it looks the same as the thumbnail.
I also observed a mismatch between darkroom vs lighttable/export when using LUT and changing the working profile some time ago. See the corresponding GitHub issue. If I understand correctly its the same issue as @RidgeRoadPost is describing (sorry if I missed some relevant difference).
My issue got closed due to inactivity after a while but afaik it was never resolved. So if others have that problem as well, it could probably be reopened.
