The lab part of the pipeline is old. The new part is unbounded linear rgb for the most part.
I am not a Mac user and don’t have access to one…so I can’t help more that what I have contributed but coming across this article shows that there can be issues in and between apps and the OS so it can be a multifactorial issue perhaps more than just something going on in DT that Davinci handles differently…I wish you luck sorting out your issues…
The problem we discussed is a little different. Yes, I am familiar with that problem. On the blackmagick forum it was discussed many times and a solution was found, but that’s another story.
Let’s say I can see the artifacts in any program other than DT if you export the hald file to such programs. Davinci Resolve is just an example.
I was very pleased (no kidding) to see so much feedback on my question. It’s been a long time since I’ve seen people respond so vividly to a question. On other resources.
Thank you from the bottom of my heart. Honestly.
2 Likes
I am glad. This community loves to participate in discussions. I hope you continue to share and chat on various topics. 
Yeah yeah )
It might be related to the input profile of the hald reference file, compared to whatever davinci is using as it’s working profile (timeline color space ).
Might just be rounding issues between apps, i don’t know.
I applied some color changes to a hald reference lut which I set as linear rec2020. Then i ooened your tiff , and used Darktable lut3d module to apply the hald file created earlier. You have to set which profile the hald expects , and I set linear rec2020 there. The results are identical , no weird shifts or anything . So that works.
Converting that hald to a cube 3dlut and using in other programs ? 
it might be that they always expect a 3dlut to work on sRGB ? Or on the current working profile of the timeline?
I never worked with converting hald cluts to cube , apparently - i only relialize it now - i moved away from software using those files 
.
I know there is a python cli program to convert them.
About the Mac and Darktable thing: i for sure don’t want to say daekrable on Mac is bad, or their users are not helping , or anything . I know that a couple of years back I was impatiently waiting on an official build when the new version was released, and it didn’t show up for weeks. There was no active person for the mac builds at that time , and I heard here that Darktable and macos were not a real priority (i believe they didn’t even want to do windows version then , so i didn’t think anything of it . I understand, another platform to what the main devs use is a pain to maintain and support ).
That was some years ago. I have no clue what the status is these days, i believe much better because I see more questions from Mac users :).
Aan long as apple doesn’t try to make OSS development harder and harder with each release of macos , it will be fine I guess.
It is very important when exporting a hald file to create the right style for it.
The style should not include any manual or automatic retouching:
sharpening
blur
any other effects that are not compatible with 3dlut
Plus, the style should not include any input or output transformations.
And for the hald image itself, before applying the style, you need to reset the entire history, except for the auto-correction by input and output.
That is, when we save the style, we must check each item of processing modules every time.
I know the limitations of a simple rgb matrix .
By the way, in Adobe Lightroom there is a clear division into color processing and retouching (let’s call it retouching) when we save a preset there.
Another thing is that the tools there are more clumsy - to put it mildly.
Well you are welcome. I am sure you will eventually land on a solution. These are tough and complicated times in the world. I wish you well. It’s nice to have distractions. This group has been a great resource and much needed connection to something “not” Covid and not so troubling. Some days it seems like everywhere you look there are a few in power that just seem to steal the joy from their people. We all have so much in common yet some how these people work at convincing us that we are different and at odds…
That’s good to hear.
As long as we have questions about color work, we’re alive )
1 Like
Hello,
Mac OS + Darktable user here.
I am using a hardware calibrated 100% Adobe RGB Eizo monitor.
I have the same problem as the OP, for the same image, the colors in Darktable are completely different from Photoshop or other apps.
I spent days trying to figure out the cause, then I found this thread. Let me know if I can help in some way.
In your case I would suggest that your settings would be…
Calibrated camera icc profile for your camera if you have one as the input profile. If not let DT use the matrix defined for your camera, It should be equivalent to the standard Adobe one by default.
Working profile set to rec2020 to allow processing in a wide gamut
Display profile to your calibrated display icc profile
Histogram profile best set to the working profile so rec2020.
Some set it to sRGB and often the working profile to sRGB but really this is not necessary and actually would restrict proper color management.
Color management handles the mapping of the larger working space to the output space using the output profile, so from the large gamut to the smaller one.
Also you want to know if you go out of gamut while editing ie in the larger working space of rec2020. SInce the histogram profile provides the data for the gamut indicators this would show you true out of gamut if it happens while editing. Setting it to a lower gamut color space would not.
There was a but that sent the data to the display profile before the histogram profile so that in this case the data would never appear clipped but I think , I think, this has been corrected.
Returning to your output profile ( ie the one that will map gamut for the exported image) you should set it usually to sRGB or AdobeRGB depending on the output destination. Usually the former for display on the internet and the later for printing. In your case your monitor can handle Adobe so that might look okay exporting to that for you but for others not so much .
I have not found it in the manual but it was presented by Shane Milton that DT only embeds the export profile if you specify this in export setting dialogue. If you leave it at the default “image settings” it would export say an AdobeRGB image if that was what your output profile was set to but not embed the profile so some apps could assign sRGB to this file and this could mess up your colors…
I will have to check that to see if this is true but if so maybe something like this could be happening??
EDIT… I use xnview and it shows a correct icc profile no matter which way I save it so I think either that information is old or not correct…
Thank you Todd for your suggestions, but unfortunately it makes no difference. These are my settings:
- Managing display profiles using Eizo Color Navigator app, everything is working beautifully, as expected, with MacOS, Photoshop, Lightroom, PixInsight.
- Using DT default input profile
- Using rec2020 working profile
- Using Adobe RGB display profile
- Using Adobe RGB in export panel
The Darktable preview differs from what I see in MacOS, PS, LR, PI. Obviously I am opening the same TIFF/JPG file, no processing applied.
Switching the entire workflow to sRGB works as expected, Darktable preview and exported files looks the same in all apps.
You can clearly see the differences, especially in the sky color.
I found this thread: Confusion on color profiles - #91 by hatsunearu
Long story short, there is a bug in Cairo/GTK under MacOS in color management.
@Carmelo_DrRaw was working to propose a fix to Cairo devs, but no updates since 2018.
No, this is completely wrong. Set it to system display profile or select the Ezio profile.
@paperdigits, tried.
Eizo profile makes absolutely no difference compared to Adobe RGB. Using “system display profile” looks the same as sRGB, but MacOS is using Eizo Adobe RGB profile.
I know it will still not likely fix it but your MacOS is using your Eizo profile…and you are using the unbounded DT profile…what happens if you copy your Eizo profile to the DT config directory and use that…This would be for sure then using the same display profile in all apps.
Also do you have a second monitor…I see you set the preview to sRGB…if you don’t maybe set it to the Eizo or system…I do recall and it may be fixed some issues where the setting for the preview profile which is the monitor profile for a second screen some how messed things up… I just cant recall what that was…
Just some random thoughts…
I’m still thinking macos does the color management for Darktable, and darktable doesn’t know it. So selecting anything other than sRGB in your display profile (in Darktable) results in 'color management being applied twice '.
Macos just thinks the application is providing sRGB , and manages it for displaying with what is selected in the display settings.
So always let an application use sRGB , unless it can tell the os that it will be doing its own color management. And yes , this limits your gamut to sRGB.
Or, maybe as a point to prove myself wrong: how is the color management in gimp these days under macos ?
Do you have the same issue there ? If not , what is gimp using to draw it’s canvas . Pure GTK or something else ?