Thanks for the helpful test image - I see exactly the same behavior with darktable 5.0 on macOS.
It seems that when selecting “system display profile”, the whole image gets clipped to sRGB, therefore the logo is not visible. Whereas when selecting the monitor profile, the image gets converted to sRGB, probably with rendering intent “perceptual” (i.e moving all of the image’s colors inward in the sRGB color space, thus making the logo visible).
At least that’s my interpretation, after measuring the screen rendering with a small desktop app called “Digital Color Meter”:
With “system display profile”, the whole image is at RGB 236/46/44, no logo visible.
With the monitor profile, the main area stays at 236/46/44 and the logo is visible at 224/43/42.
These are “native values” as displayed by the app (I would assume, the values from the graphics display buffer), in sRGB the app values read 254/2/12 for the main area and 244/0/10 for the logo.
macOS preview shows the same image at 255/0/5 (main) and 245/0/4 (logo) in native values, and both main and logo as 255/0/0 in sRGB even though the logo is visible (–> as expected, clipped).
BTW, my cairo patch from two years ago unfortunately changes nothing on the behavior, this was apparently just wishful thinking …
In fact, the functions that I patched (CairoQuartzCreateCGImage(), cairo_quartz_surface_create(), …) are not even used by darktable, as far as I can now tell.
Also, switching to cairo 1.18.0 changes nothing, despite the promising changelog entry "Quartz surfaces now use the main display ColorSpace" ( I tried with a local build of 5.0) - I am wondering where the sRGB limitation of cairo for darktable on macOS really lies?
From Apple‘s documentation, gtk’s use of CGColorSpaceCreateDeviceRGB () does not seem really appropriate for macOS and an application like darktable that crucially depends on color management …
„ Device color spaces are primarily used by iOS applications because other options are not available. In most cases, a Mac OS X application should use a generic color space instead of creating a device color space. “
Hi Alberto,
I experimented a bit with a local build of gtk3.0 in darktable: Changing this (and a 2nd location in gtkquartz.c) from the device-dependent CGColorSpaceCreateDeviceRGB () to a generic CGColorSpaceCreateWithName( kCGColorSpaceGenericRGB ) - like recommended by the macOS documentation - had no effect, the displayed colors remained exactly unchanged.
The limitation to sRGB actually seems to be here gdk/quartz/GdkQuartzView.c · gtk-3-24 · GNOME / gtk · GitLab
By replacing kCGColorSpaceSRGB with kCGColorSpaceDCIP3 there I finally get the DCI-P3 gamut in darktable, that my iMac 27" 2020 screen is capable of.
But the colors seem to be oversaturated in darktable now … need to do further checks …
Georg
Edit:
needs to be kCGColorSpaceDisplayP3 instead of kCGColorSpaceDCIP3, of course (sloppy me!) - the apparent increased saturation came from the different gamma (2.6 with DCI P3 vs. 2.2 of Display P3).
Measured a printer test image (in Prophoto RGB, and also converted to Adobe RGB, sRGB), colors in darktable are now the same as rendered by Photoshop and macOS Preview on the same display, and cover the Display P3 gamut.
It works for me now, but of course this is not a generic solution. By patching gtk this way, one can utilize wide-gamut displays, but is bound to standardized color spaces like Adobe RGB or Display P3, and it’s a static, compile-time “solution”. Disappointing that gtk seems to have no ambitions at color management at all (see the comment from one of its devs in macOS: gtk3 3.24.36 changed determining system display profile over gtk3 3.24.34 (#5579) · Issues · GNOME / gtk · GitLab “Gtk doesn’t have any color management capability and doesn’t advertise anywhere that it does.”) - I wonder how this works on Linux and Windows.
I currently only have an sRGB monitor, so I’m not yet affected by this. But I’ve been thinking about getting new screens with a wider gamut, which would make this urgent indeed…
I think there’s no issue to report in the sense of a bug.
As I understand it, the issue from 3.24.34 to 3.24.36 was an unintentional omission of colorspace information for a pixel buffer, that got fixed by statically assigning sRGB in later releases - which restored the behavior expected by darktable.
I have just circumvented that sRGB limitation by assigning (also statically) Display P3 instead of sRGB.
BTW, if anybody likes to replicate my gtk+ patch on their own machine: don’t forget to set darktable’s display profile to “Display P3”, to tell darktable that it shall render to that color space (as the default “system display profile” is fixed to sRGB on macOS).
Indeed, that assignment is the camera profile. That gives the first transform (working profile, or in my case display/export) the information about the input data to do the transform.
Well, the constant just tells macOS which of the standardized colorspaces to assume for the pixel buffer that it receives from gtk+.
My understanding is that the selected display profile (in darkroom view) tells darktable which profile to render to for display, from its internal working profile. The resulting pixel data pass through cairo/gtk+ (without color space information), but ultimately gtk+ needs to tell to macOS in which colorspace it should interpret the pixel data - and currently assigns sRGB by default through that constant. darktable by default assigns sRGB if one selects “system display profile”, so everything is consistent.
I simply exchanged sRGB by Display P3 on both sides …
I would assume that there’s also an API to hand over an ICC profile to macOS, but I did not investigate (yet). To use this, gtk+ would need to identify the display profile through some other API function from macOS. darktable has some code for this in the function dt_colorspaces_set_display_profile() in colorspaces.c, but it is #if-commented out permanently. The same functionality would need to be implemented in gtk+, as (given its ignorance of color management) there is likely no way to pass the information through darktable → cairo/gtk → macOS).
Another possibility would be a constant that tells macOS to “use whatever is currently set as monitor profile”. But such a constant is not defined according to Color Space Names | Apple Developer Documentation
Disclaimer: please don’t take my words as authoritative, I feel that I am just scratching the surface of the topic.
You can’t talk about the transform unless you consider both the input profile and the output profile, and how both get to the transform engine. The display transform, for instance happens as two steps: 1) transform of the image data from the input profile’s description to XYZ or Lab (the intermediate “connection” spaces), then from the connection space to display using the display profile’s information. That input is usually the image in working profile gamut/tone, but it could be the camera profile in, e.g., dcraw, which doesn’t use a working profile.
Edit: my use of the word “input” refers to the specific transform, not necessarily the file input.
Yes, but I was purely talking about the 2nd step - the transform from XYZ, Lab, linear Rec2020 or whatever the working space might be to the display profile. In essence, what darktable is working on to its corresponding rendering on the screen.
What should the input camera matrix have got to do with that?
I don’t think you understand the ICC transform mechanism. XYZ and Lab are not working spaces, they’re connection spaces for the transform so the input and output profiles don’t have to know about each other. So ICC transforms are a two-step transform, through the selected connection space. The movie industry ACES color management system does direct input->output tranforms, but the collection of colorspaces is small due to colorspace-compliant displays. and smaller choice of cameras.
A working profile is not necessary if the camera profile has unambiguous white and black entries. Some software makes it necessary probably to just simplify their raw processing choices. I don’t use a working profile in any of my processing, just camera → display/export at the end of the toolchain, works just fine and I’m limiting the ‘damage’ I do to the data.
I think the problem here is how to tell the operating system about the display color space. Darktable knows how to prepare data in any old color space, but GTK on MacOS currently only supports sRGB windows.
We’ll need to figure out how to ask macOS about its native display color space or ICC transform, and how to tell it that our window is using that color space. It’s about the OS interface, not the color data itself.
I think I understand the basics with connection spaces. Still I am not talking about general situations and SW, but only about how to enable a display profile other than sRGB with darktable on macOS.
darktable allows to select a working color space, and the camera matrix for sure is vital to translate to that space - not sure if darktable uses a connection space in between or not. But from that working space it is a separate transform to the display output - and this one is the same for all cameras supported by darktable, i.e. does not depend on the camera matrix.
Yep, you got it. However, since the color transform process is a chain, all subsequent transforms depend on that rather convoluted transform of the camera space to something more constrained. If you lose hues in the camera → whatever transform, you’re not going to get them back later.
Thanks to your tips I was able to implement some basic support for wide gamut monitors in ART on macOS. If anyone is interested, there are nightly builds at Release nightly · artpixls/ART · GitHub
To see the effect, you need to select the proper monitor gamut under “preferences → colour management”. This seems to work fine here, but my testing at the moment is limited to one data point so if anyone with a wide gamut screen is willing to give it a try I would be happy to get feedback.
Hi Alberto,
thanks - I installed and tried to start it, but got an error message?
dyld[1600]: Symbol not found: _iconv
Referenced from: /Applications/ART.app/Contents/Frameworks/libintl.8.dylib
Expected in: <53F687F6-88A6-3F39-92B2-8A1AE884AB0D> /Applications/ART.app/Contents/Frameworks/libiconv.2.dylib
so if anyone with a wide gamut screen is willing to give it a try I would be happy to get feedback.
what macOS version?