@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.
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.
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
@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
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?
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.
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”
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.
Unfortunately DT doesn’t seem to be happy with me having swapped them like that though…
> Crashed Thread: 0
>
> Exception Type: EXC_CRASH (SIGABRT)
> Exception Codes: 0x0000000000000000, 0x0000000000000000
> Exception Note: EXC_CORPSE_NOTIFY
>
> Termination Reason: Namespace DYLD, Code 1 Library missing
> Library not loaded: '@executable_path/../Resources/lib/libcairo-gobject.2.dylib'
> Referenced from: '/Applications/darktable.app/Contents/MacOS/darktable'
> Reason: tried: '' (code signature in <BED7FB84-257C-3BC7-A97F-D89C37DB5749> '' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.), '' (no such file)
> (terminated at launch; ignore backtrace)
I do not know how to directly link the post of @MStraeten. Thus, I just cut and copy his last post 4 days ago (is it does not work just use the search function):
Hmm, sounds like the libraries can only be used on the same machine they were built on … might be a security measure, related to code signing of the dylibs?
You might try to build them yourself, it‘s actually not very complicated.
They are in the Contents/Resources/lib folder of any macOS darktable release, and darktable does not work without them. They are responsible for rendering to macOS‘ graphics layer „Quartz“, see https://www.cairographics.org/
However, the „official“ versions distributed with darktable default and limit to the sRGB color space, this I learned from @parafin. That‘s why I created new ones, patched to work with the display’s currently assigned profile instead of sRGB …
.
