Color Management - Use newer cairo version for darktable 4.4

[twbaumann]

There is a well known and long standing cairo issue that affects 'only' macOS users not only producing for the web but printing to larger than sRGB gamut printers: Choosing 'system display profile' instead of 'sRGB (web-safe)' has no effect. That alone is not a big problem, but even if you put your display profile inside ~/.config/darktable/color/out/ and select it, darktable indeed converts the image to that profile but cairo up to version 1.17.8 (and the version within darktable 4.2.1 package) does not hand it over to the OS and macOS presumes sRGB.

That changed with a recent merge of https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/290 into cairo master on Feb 18. I verified the fix with wide gamut test images on a self compiled 4.2.1 version where I replaced the three libcairo*.2.dylib files with the self compiled new variants. There is no longer a difference to other apps when displaying images with embedded ICC profiles, which is great news!

In the cairo release notes it says that 1.17.8 will be the last version before 1.18 and I am afraid that won't be released before darktable 4.4. In that case, please use the cairo master branch instead for the next darktable release.

[parafin]

See https://gitlab.gnome.org/GNOME/gtk/-/issues/5579

I’m not sure how it relates to changes in cairo, but same concerns are applicable.

[twbaumann]

That gtk issue appears to be indeed related to the same change in cairo, although I found no indication of the exact cairo versions used. However, in my view it is not a bug but a feature! I understand that the original reason for the cairo fix was performance driven, but this is about its positive side effect on wide(r than sRGB) gamut color rendition on macOS.

Of course, having to put the actual display profile into ~/.config/darktable/color/out/ is not nice and should certainly be fixed in future, but the old cairo version makes correct colors for wider than sRGB gamut images and displays on the Mac impossible. Let me try to explain why:

• Today the system display profile on macOS cannot be determined by darktable or gtk, using that setting for the display profile has the same effect as choosing 'sRGB (web-safe)'.
• Darktable / cairo sends plain RGB values to macOS for display, there is no ICC profile involved except for the conversion within darktable.
• The old cairo version makes macOS assume it gets general display data based on sRGB, they are then converted to the system display profile. This leads to muted colors if the display profile color space set in darktable is larger than sRGB.
• The new cairo version makes macOS assume it gets display data based on its system display profile, so they are sent to the display without conversion. This leads to correct colors if the actual display profile is explicitly set in darktable.

The old version renders colors correctly as long as the images are confined to sRGB, which has been recommended by many, but which seems a bit antiquated if you look at current inkjet printers and displays.

I found two wider gamut test images that you can import into darktable and for comparison open with e.g. Preview or even view them in your browser:

• https://www.wide-gamut.com/assets/test/image-red-P3.jpg
• https://github.com/codelogic/wide-gamut-tests/raw/master/P3-sRGB-color-ring.jpg

They are based on Display P3 and DCI-P3 color spaces. In darkroom they render as follows:

display profile setting   old cairo version               new cairo version
--------------------------------------------------------------------------------------------------
system display profile    gamut restricted to sRGB,       colors boosted to display profile gamut,
or sRGB (web-safe)        no letter and no ring visible   no letter and no ring visible

actual display profile    letter and ring visible, but    correct display
(gamut > sRGB)            muted colors

[parafin]

"colors boosted to display profile gamut" is incorrect rendering and exactly the problem. You are saying new cairo broke the rendering of existing code. It's exactly the same problem as in linked GTK issue. It is not an improvement, but breakage of all applications. Correct fix is to actually provide a way to specify color profile.

[twbaumann]

I don't think gtk/cairo can deal with color profiles at all. But I see your view which differs from mine. You say: darktable will no longer be color correct up to sRGB out of the box. I say: finally I can use darktable in a professional color managed environment.

Ideally both use cases could be served, e.g. using a configuration item within darktable to tell gtk/cairo to either handle the image as sRGB or as display data.

[parafin]

If it would be possible to tell cairo how to handle the image data, there won’t be a need for dt setting (obviously you would go for full gamut). The problem is that this cairo change is breaking for old code and binaries, and furthermore new code will have to depend on this newest cairo release. There’s nothing “professional” about that situation, they could as well change it back in next release, how gtk did it in the linked issue. To me this screams “stay away for any professional color usage”. As you said, this patch was about performance, not having good colors.

As I said they need to add explicit color management to cairo to properly fix this. But this is just my view, and I’m no longer a macOS maintainer, so new team will have to deal with this shit.

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions]

This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.