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.
2 possible reasons:
- changes in the darktable code - since there’s no issue reported this will be also in the upcoming bugfix release
- different versions of macports libraries used for the official build - without an issue report no one will investigate
How would I go about reporting the issue please?
can this issue be reproduced by someone building darktable using homebrew (and gtk 3.24.36)?
If so it seems to be an upstream issue with gtk 3.24.36 if not, the macports build instruction in #66487 (gtk3 menues broken with macos ventura - update needed) – MacPorts
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.
did a build with the old patch based on gtk 3.24.34 for x86_64: darktable-4.2.0+126~g66b8bc3ea_x86_64 (1).dmg
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.
darktable-4.3.0+488~g59ff35fcfd-i386.dmg
Can someone please test and compare the results so we can see if there are any differences between a MacPorts built and a Homebrew built.
Tested the build with 3.24.34, it’s ok.
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.
so no need to file a darktable issue but a gtk3 issue …
1 Like
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.
got feedback at gtk3: macOS: gtk3 3.24.36 changed determining system display profile over gtk3 3.24.34 (#5579) · Issues · GNOME / gtk · GitLab
so the behaviour was changed intentionally
Thanks, hope it is fixed soon!
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”.
I did the same change for myself before, see https://github.com/darktable-org/darktable/issues/11124#issuecomment-1059800809 and the ensuing discussion.
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.
and breaking color managed apps even wasn’t something to be mentioned in release notes for gtk3 3.24.36
Right, I checked on the release notes and could not find anything related to color.
gtk3 issue macOS: gtk3 3.24.36 changed determining system display profile over gtk3 3.24.34 (#5579) · Issues · GNOME / gtk · GitLab is fixed.
see current OSX Build - #619 by MStraeten for builds with patched gtk3 3.24.36
keep in mind: now you need to select ‘system display profile’ to get a proper color managed view
1 Like