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 ?
@priort
I tried copying the Eizo ICC profile in DT, it makes no difference compared to selecting Adobe RGB.
I have only one display, I also tried using the preview window but the behavior is the same.
@jorismak I just tried The Gimp, it works bad exactly like Darktable. I also tried RawTherapee, in the color preferences it’s clearly reported that “only sRGB output is supported due to MacOS limitations”. Well, it appears that they share the same limitation, but at least RawTherapee warns you. By the way is clearly not a MacOS limitation since all the other apps works perfectly ok, I guess it’s a GTK limitation under MacOS.
I am not a novice. As I stated before, other commercial apps works perfectly ok. I tried Photoshop, Lightroom, PixInsight, CaptureOne.
As reported HERE, it’s a bug, unresolved since years.
It’s of course possible under macos , otherwise it would never had received the reputation for being good for creative work 
.
Software needs to flag / tell macos with the drawing apis that they’ll do the colour management themselves . And/or this automatically kicks in if your drawing canvas is a GPU accelerated way of drawing .
The question is if GTK (well, Cairo and gdk , the drawing library and primitives used by GTK ) exposes this setting ,and if it’s even possible .
If you say 'there is a bug’s , then apparently there is a way ? But it’s not working?
The 'srgb as default ’ is a macos thing for quite some time , it allows apps without any clue about color management to still be somewhat color managed. But it requires 'apps that know what they are doing ’ to tell the os to leave them alone.
Basically , macos interprets pixel data as ‘srgb’ by default , windows interprets it as ‘native’ by default . I guess Linux also does the 2nd thing .
@jorismak
I call it “a bug” because if other apps work as they should, I see no reason why Cairo/GTK can’t.
If it is an unsupported feature with no plans in making it work, then at least there should be a warn somewhere, like RawTherapee do.
I agree, and I patched cairo locally (crop tool: edge drag doesn't work if mouse moves too fast · Issue #11124 · darktable-org/darktable · GitHub) to use the currently attached monitor profile instead of DeviceRGB, which apparently defaults to sRGB since macOS 10.8. I am hesitating to create a PR for cairo, though, as the patch only works for single-monitor setups.
BTW, some comments in this thread seem to suggest that macOS is limited to sRGB anyway. This is not true. Most (all?) Apple displays today cover the DCI-P3 gamut, which is significantly wider than sRGB, and of course they are fully supported by the OS.
1 Like
In case my comments maybe one of those : i am absolutely NOT saying that :). I am saying that applications not doing color management are forced into color managed sRGB , which is better then no color management at all. It just sucks if you want to do the color managing yourself and the stack you’re using is working against you :).
Actually I guess the comment was in one of the referenced threads, something about a limitation of the Quartz backend … didn’t mean to offend you or anyone else 
1 Like
@geni1105, your name doesn’t lie, you are a genius my friend.
I installed Darktable via Macports, downloaded Cairo 1.17.4 and applied your patch. Compiled, installed and finally got the right color in DT. 
I had to select the Eizo profile (the same that is loaded by Eizo Color Navigator into MacOS preferences). Now the colors are coherent everywhere.
Thank you very much 
This patch should be submitted to Cairo devs…
1 Like
Yes, forgot to mention that the monitor profile also needs to be selected in darktable.
Glad that the patch works for you 
I am new to dt. I am familiar with the manual, watched a bunch of AP’s videos and processed images. I’m very impressed with the direction and advances in the pipeline and processing. I also know about color management, and a bit about ColorSync, Little CMS vs. dt native processing. I realize that dt is primarily a linux effort, but does support windows and Mac through gtk. I bought a new MacBook several months ago so that is my HW for the net few years. I also have a P3 capable monitor. I am in the process of figuring out if dt is a good fit or I am swimming up stream. I do not know the internals of dt, or the various dependencies gtk, Cairo projects but this sounds like it needs other projects/teams to make changes for macOS or I need to patch every release and build everything? (which I have not begun to look into) Thx for any clarifications.
I guess it depends on your output intentions. If you are processing primarily for web use, then the limitation of the ready-made macOS builds to sRGB will not harm you.
Else you might want to build yourself, including cairo with the patch described above.
My original motivation for the cairo patch was the apparent slow-down due to the additional color space conversion (from sRGB to monitor profile), not the gamut limitation. With darktable rendering directly to the monitor profile, certain operations like pulling on the crop rectangle became much smoother.