Confusion on color profiles

Thanks.
I think I understood that. In fact as mentioned, at least in my case, “system profile” and “sRGB” are totally identical. Makes sense.
However, I dislike the idea of not getting the most out of my monitor, because it means falling back to sRGB. And I am sure many, many others of OSX with wide gamut display will feel exactly the same.

See you soon then.

Yes, it will be mentioned. And even then the system display profile setting should still be the right thing to use.

I’ve been using ArgyllCMS to “accomplish this” and “test that” for as long as I’ve been using Linux (since somewhere around 2007), and so far ArgyllCMS is the one and only color-management-related software that seems to me to be 100% reliable. And so I have a huge respect for anything @gwgill says about anything related to color management.

Color management on X works. I don’t mean that non-color-managed desktop widgets look good on a wide gamut display. I don’t mean that multi-monitor setups are easy to use. I don’t mean color management happens “automagically and correctly” without the user having some knowledge of what they are doing. I only mean two things:

  • When using ICC profile color-managed editing applications (GIMP/Krita/free-libre raw processors/etc), on X the images are shown with correct colors, at least on the main monitor, assuming of course the user knows how to calibrate and profile their monitor, how to load the vcgt tag if required, and how to tell the software to use the monitor profile.

  • When using a proper OCIO lut made from one’s properly made monitor profile and the profile of whatever working space one wants to use, on X the images shown by Blender and presumably other OCIO-color-managed applications have correct colors.

In case it might be useful to members of the pixls.us forum, here are links to various discussions of color management over on the Wayland development mailing list, more or less in order by time:

This page has a box for searching the wayland-devel archives:
https://lists.freedesktop.org/archives/wayland-devel/

A lot of the Wayland discussions go right over my head. But if the people developing Wayland don’t actually understand (or care about?) color management as it pertains to color-managed image editing, that’s a huge problem.

As the conversion to Lab doesn’t seem to clip colors, then of course that’s not a problem. From curiosity, does darktable use LCMS to make the conversion?

It depends. When the input/output profile is a matrix profile we use our own fast path, otherwise lcms2 is used. You can force darktable to always use lcms2 in the preferences though.

As promised, I will summarize here my findings after experimenting a bit with the color profiles in OSX.

First of all, here is some explanation of the logic being used by Cairo under OSX.
When painting pixels on the screen, Cairo uses the Quartz 2D backend. Internally, the pixel data is associated to a CGImage structure, and is transferred on screen by drawing the image into a CGContext associated with the application window.

The Quartz 2D graphics library is intrinsically color managed. The destination graphics context is associated with the display profile, and the input CGImage must also define the profile needed to interpret the pixel data. The library takes care automatically of the colorspace conversions when the image is drawn into the graphics context.

From the point of view of a photo editing application that wants to keep control of the colorspace conversions, this is of course not convenient, particularly because the Apple API does not provide any way to disable Quartz internal color management (probably they consider the software developers not smart enough to take care of color management :wink: ). The only way I could find to “bypass” the color management is to assign the current display to the CGImage structure, so that Quartz applies an identity transform (it seems that in this case Quartz does not apply any transform).

As far as I understand, the “identity transform trick” was the original goal of the Cairo developers as well, but was accomplished in a way that is not working anymore in recent OSX versions. For this, they associate to the CGImage a colorspace obtained with the CGColorSpaceCreateDeviceRGB() function. However, from my experimentation as well as from some Qt bug report it looks like DeviceRGB is treated internally as sRGB by Quartz, hence resulting is an unwanted color transform.

The best working solution I could find is to replace CGColorSpaceCreateDeviceRGB() by the following function in CairoQuartzCreateCGImage():

static CGColorSpaceRef CGColorSpaceCreateDisplayRGB()
{
  CGColorSpaceRef result = NULL;
  result = CGDisplayCopyColorSpace(CGMainDisplayID());
  if (!result) {
    result = CGColorSpaceCreateDeviceRGB();
  }
  return result;
}

The retrieved monitor profile corresponds to the “main display”. Hence, this works correctly in a single-display setup as well as if the application window is on the main display in a multi-display configuration.

In order to support displays other that the main one, one would need a mechanism for passing the display ID to the underlying Cairo library. Unfortunately, the Quartz API does not provide any interface for retrieving the color profile associated to the destination CGContext…

I am currently preparing a PhotoFlow package with this patch included, so that eventually other OSX users with wide-gamut displays can give it a try and see if they get the expected result.

2 Likes

Oh my, I actually understood this. No wonder my wife’s eyes just glaze over when I use the word ‘color’ in a sentence… :smile:

3 Likes

@Matteo_Bertolino @Morgan_Hardwood @houz - I have prepared a new version of my PhotoFlow editor that is linked with a Cairo library patched as I suggested above. You might use it to test the visualization of wide-gamut images on your wide-gamut display, without the limitations imposed by the standard Cairo code. For this, you have to set by hand your display profile in PhotoFlow’s preferences:

The updated photoflow package is here.

The reason why I am proposing to use PhF here is simply because I have full control over the build process, and I can easily do some testing. This exercise should serve as a proof-of-principle for a possible patch to be proposed to the Cairo developers, so that the sRGB limitation under OSX might be solved for all GTK-based image editors…

Let me know what do you think.

4 Likes

Hi.
Well, first of all, many thanks for your work. That’s good news indeed.
Now, I am not sure I will be the best person to run tests with…anyway, I’ll give it a try.
First I need to install Photoflow, which I come to know the existence of today. Once installed I’ll get back here, probably for further guidance.
I’m sure the others will be able to help out a lot more.

ok. installed.
Now, which profile shall I select from the .icc folder? My own, as produced by the calibration process? Actually in that folder I only have my own created .icc profiles. No generic AdobeRGB98. I wonder where all the others have gone.

@Matteo_Bertolino - Yes, you have to select the ICC profile you created for your display. Other profiles can be found in /Library/ColorSync/Profiles and the relative sub-folders, as well as /System/Library/ColorSync/Profiles.

Thanks for checking!

@Carmelo_DrRaw great to see that there might be a solution at least for the common single-monitor setup in macOS!

However I don’t have macOS myself (I visited a company in Stockholm a few years ago to help them with their macOS color-managed setup and ran into the macOS sRGB wall) and I no longer have the Eizo, though I do profile and color-manage my (very good ASUS UX305CA) laptop screen. Would you like me to test anything or was your call for testing only for macOS users with wide-gamut screens?

Hi Morgan.

Just a question: why do you refer only to “single-monitor-set-up”?
Do things change if I have a a second monitor plugged in? In my case my main iMac monitor is broken (yet active, but useless) and I use only a second monitor (Eizo), as main monitor (calibrated via i1 Display Pro).
And, what do you mean by “ran into macOS sRGB wall”?

Many thanks.
M

@Matteo_Bertolino

So it sounds like you could expect correct colors on a multi-monitor setup provided the program’s window is on that monitor, if you use @Carmelo_DrRaw’s photoflow package and the code works.

By “the macOS sRGB wall” I mean the problem that GTK+ applications in macOS are clamped to sRGB even if you use a wide-gamut monitor profile. That is what @Carmelo_DrRaw’s code above attempts to work around. More info in this thread: Wide-gamut preview in macOS

1 Like

Thank you a lot for looking into this! I myself don’t use OSX either so I can’t test anything.

Regarding the use of multiple monitors, we have the following code in darktable from back when cairo still worked as expected:

It’s currently commented out, but maybe that can somehow help to support multi monitor setups?

I actually have this bit of code in my Cairo patch as well (but not being used at the moment), which I most likely took from DT some years ago… however, in this case one needs a mechanism for telling Cairo which monitorID to use, and ideally one would want to set this individually for each drawing context (because you might have an application with multiple windows scattered across multiple displays, and you want each window to be properly color managed). That most likely involves some API changes, while the “simple” solution, valid for the main display only, works with the current API. Maybe we should proceed step-by-step…

True, and when more than one monitor is used the user can still assign the editing monitor’s profile to all of his monitors to see correct colors where it matters.

The API required in Cairo is probably the same that we will need in Cairo and GTK+ once Wayland has added full screen color management. Provided that will ever happen.

@Carmelo_DrRaw or anyone else dealing with GTK, color management, and OSX - has there been any update/progress/happy results from the code that @Carmelo_DrRaw wrote for handling OSX color management for GTK apps?

Was I correct to say (in the last comment) that the following GIMP bug report is about the same problem as @Carmelo_DrRaw 's code is hoping to solve?

Yes, it seems you are right. I am still planning to draft and propose an appropriate patch for Cairo, which to my mind involves adding the possibility to associate a color profile to a Cairo context (instead of letting Cairo try to fetch and use the display profile, something that is clearly broken in the OSX Quartz backend).

I might start working on that after the Christmas vacations…

5 Likes

Is there any progress regarding this? It looks like using darktable on macOS just isn’t possible with this bug…

Let me know if there are any hacky workarounds too.