Confusion on color profiles


(Morgan Hardwood) #83

@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) #84

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) #85

@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


#86

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?


(Carmelo Dr Raw) #87

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…


#88

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 Stone) #89

@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 Dr Raw) #90

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…