Confusion on color profiles

Morgan_Hardwood · February 27, 2018, 9:36am

@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?

Matteo_Bertolino · February 27, 2018, 10:01am

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

Morgan_Hardwood · February 27, 2018, 10:08am

@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

houz · February 27, 2018, 10:42am

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:

github.com

darktable-org/darktable/blob/master/src/common/colorspaces.c#L1429-L1447

    
      
          
          
res->profiles = g_list_append(res->profiles,
                                        _create_profile(DT_COLORSPACE_ADOBERGB, dt_colorspaces_create_adobergb_profile(),
                                                        _("Adobe RGB (compatible)"), ++in_pos, ++out_pos, ++display_pos,
                                                        ++category_pos, ++work_pos, ++display2_pos));
          
          
res->profiles = g_list_append(
              res->profiles, _create_profile(DT_COLORSPACE_LIN_REC709, dt_colorspaces_create_linear_rec709_rgb_profile(),
                                             _("linear Rec709 RGB"), ++in_pos, ++out_pos, ++display_pos, ++category_pos,
                                             ++work_pos, ++display2_pos));
          
          
res->profiles = g_list_append(res->profiles, _create_profile(DT_COLORSPACE_REC709, dt_colorspaces_create_gamma_rec709_rgb_profile(),
                                             _("Rec709 RGB"), ++in_pos, ++out_pos, -1, -1,
                                             ++work_pos, -1));
          
          
res->profiles = g_list_append(
              res->profiles, _create_profile(DT_COLORSPACE_LIN_REC2020, dt_colorspaces_create_linear_rec2020_rgb_profile(),
                                             _("linear Rec2020 RGB"), ++in_pos, ++out_pos, ++display_pos, ++category_pos,
                                             ++work_pos, ++display2_pos));

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

Carmelo_DrRaw · February 27, 2018, 11:23am

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…

houz · February 27, 2018, 4:09pm

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.

Elle · December 14, 2018, 2:29pm

@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?

Carmelo_DrRaw · December 14, 2018, 2:37pm

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…

hatsunearu · November 16, 2020, 5:37am

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.