If I understand things correctly, on MacOS darktable does not use the system display profile, but under this setting renders to sRGB. This is due to a fixed setting in the underlying cairo framework.
MacOS then renders the sRGB-based information to the set system display profile.
The downside of this approach is, that a potential wider gamut of the display would not be utilized. But still the output jpeg should look identical to the screen rendering, so I think something else must be wrong …
Darktable_cmstest unfortunately is not available on the Mac.
Thanks for the replies. I have found a partial solution though. I have been using the current OSX Build from this thread : current OSX Build - #613 by homer3018
I rolled back to the official 4.2.0 release and everything becomes correct.
Something must have changed in the code since…
Same here. The exported jpg are the same, but using 4.2 instead of 4.2+118, darktable (both lighttable and darkroom) now matches the exported JPG with sRBG.
Setting the display profile to the real monitor profile (instead of the generic “system display profile”) seems to resolve the issue.
I think this is a hack and not supposed to work that way - if I understood it correctly, “system display profile” defaults to sRGB on Mac, and the rendering to the monitor’s profile is later done in cairo or macOS.
I have built darktable using Homebrew on my Intel Mac. This package is built right out of the box from the darktable sources by using the homebrew build scripts without an changes.
thanks for the build - was able to run it on my intel ventura system.
result: seems to be an upstream issue with gtk3 3.24.36 - since your build show the reported behaviour.
Just tried a strange experiment. I erased the library.db file and re-imported my images. It seems that the issue disappears. Trying some experiments at the moment.
OK, so it seems that in the 4.2 version (gtk 3.24.34), if I erase the data.db and library.db files and re-import, the issue disappears but not in the 4.3 build…
Not sure it was necessary to rebuild database but it wasn’t working straight away.
Seems to point towards a gtk problem.
This means, that everything would work again, if you put the actual monitor profile in ~/config/darktable/color/out and manually select that profile, instead of the generic “system display profile”.
The good news: the change supports wide-gamut displays better (but only if you are on a single monitor setup), and speeds up some operations.
The bad news: it breaks color management for all that are not aware of the issue and miss to manually switch over to the monitor profile. And for all gtk-based applications, that simply rely on macOS color management.