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.
Hi. I started this thread last year … and it went off on a few tangents since then.
But I’m coming back to it because I’ve just downloaded Darktable 4.0.0 and was hoping that some of these issues might have been solved… but unfortunately, repeating what I describe in my first post of the thread has just the same results as before.
So… I think I am now at the same point as @Beau just above (except I am not really any expert in colour management at all). And wondering whether I too am “swimming upstream” if I try to continue using DT.
I have a couple of questions (which maybe can be answered by @geni1105 )
-
Let’s say I go for the “processing primarily for web use, then the limitation of the ready-made macOS builds will not harm you” approach. If I do this (and just accept that DT will not take advantage of my monitor’s wider-than-sRGB gamut" then what settings should I use in DT (specifically what should I set my display profile as?)
-
If I decided to try and use the patch … how difficult is this to do? My knowledge is such that I don’t know how to “apply a patch”. If that’s my starting point should I just not mess with this - or is it in fact a fairly simple procedure once I know how?
Thanks!
I may sound like an expert, but actually I am not So please use my advice with caution and doublecheck results on your side …
-
For sRGB based workflow, just install an official release and set the monitor profile to „system display profile“. My understanding here: on MacOS this is equal to sRGB (due to cairo), and MacOS takes care to render to the set OS display profile.
-
Patching steps
- First build darktable locally, this includes installing cairo libs through MacPorts, description available here https://github.com/darktable-org/darktable/blob/master/packaging/macosx/BUILD.txt. Check if it works as it should.
- Get cairo sources, and following my description in https://github.com/darktable-org/darktable/issues/11124#issuecomment-1059800809, locally modify a few lines, build and install the cairo libs.
- Rebuild darktable locally, this time it will use the patched libs.
I can check if the patched cairo libs can also be copied manually into the darktable application bundle, without any local build. If so, I can provide them in my Dropbox.
You might try to manually copy the patched cairo libs in your darktable application bundle, it seems to work: the libraries are available under Dropbox - cairo-patched - Simplify your life
- open the application bundle: right-click on the application, select “show package contents”
- navigate to Contents/Resources/lib
- put the libraries there
I do not knot if it may help, those two libraries are already present in the lib folder of darktable 4.1.0+236-g78747838c for Mac that you can find for download in this forum @MStraeten “current OSX build”. Thus, you may see with this build, if those libraries help with the issue you described.
Yes they are already present, I just changed („patched“) their functionality, with respect to color management.