Return a profile in the "PickColor" API

[Jehan]

The current PickColor API returns a RGB value: https://github.com/flatpak/xdg-desktop-portal/blob/90d041a2de5add60b32b4d26b857c20beeb43c4d/data/org.freedesktop.portal.Screenshot.xml#L103-L109

While I am aware that in Wayland for instance, we don't really have proper color management yet, we should eventually. And the API should prepare for this, and also as a reminder to implementations that they should return RGB color with a profile.

The Screenshot API was already discussed and doesn't have this issue as it returns a file which can contain the profile embedded. But this is not the case for PickColor which just returns 3 numbers in [0; 1] range and that's all. So unless I miss something, we are just out of luck. In GIMP tracker, people have been complaining of wrong value so we are going to use the X11 implementation in priority (when running X11) because then we know which display the data comes from and how to get the display profile in X11, but eventually we'd prefer to stick to the portal obviously (especially for Wayland where it's the recommended choice and X11 API won't work).

Could an additional profile be documented as to be returned in the "#org.freedesktop.portal.Request::Response signal"? Thanks.

[swick]

Just adding a profile is not a good idea. For one, people already use the API and are fine with values which are approximately sRGB. If we add profiles and one of them describes a WCG then the values returned would look very wrong when interpreted as sRGB.

IMO the first step here should be documenting that values returned are in sRGB and then fix backends to return sRGB values always.

The next step is then about exposing a new API for colors whcih potentially exceed sRGB. Using an ICC profile however doesn't sound like the best idea. It adds a lot of complexity for clients (i.e. being able to work with arbitrary ICC profiles) and it doesn't work with anything but SDR right now.

Exposing colors in PQ/Rec2020 is probably a better idea and should be big enough for the foreseeable future.

[Jehan]

Sure, fixing the current API so that it returns sRGB and creating a new API looks a totally acceptable idea.

Just some comments about the new API:

It adds a lot of complexity for clients (i.e. being able to work with arbitrary ICC profiles)

Well, anyone who doesn't know how to process ICC profiles is probably doing it for an application which doesn't care, hence will use the first API anyway. The documentation will just have to be clear that this new API is for application wanting exact display colors, even out of sRGB gamut.

it doesn't work with anything but SDR right now.

I have very low experience, if any, with HDR. What do they use for color management?

Exposing colors in PQ/Rec2020 is probably a better idea and should be big enough for the foreseeable future.

If you want to go profile-less, why go this way? Just choose an absolute color space, like one of the CIE Lab color space (e.g. XYZ under a standard D50 illuminant), and done. Everybody will know how to process these and no profile to exchange (but at least here, it's the expected way to do it).

I don't really mind, we already know how to process both CIE XYZ and Rec2020, and for sure I don't follow that much hardware evolution and don't know if any hardware would ever have wider gamut than Rec2020, but just saying. :-)

[swick]

Well, anyone who doesn't know how to process ICC profiles is probably doing it for an application which doesn't care

Okay, then when will GIMP support iccMAX? Because what you're actually asking for is ICCv2 profiles and that will restrict us to SDR and really bad perceptual transforms. Even then ICCv2 includes so much that we would have to define a subset of features to be usable by clients.

I have very low experience, if any, with HDR. What do they use for color management?

HDR is a concept so any color management system could support it. In practice right now people use well-known video signals like PQ/Rec2020.

If you want to go profile-less, why go this way?

It encodes dynamic range. It also specifies a reference display and viewing environment. That should be enough information to convey what a user actually perceives.

[Jehan]

Because what you're actually asking

I'm not really asking anything, just trying to understand and discuss so that we get the best API, and I certainly don't know that much in more recent color technologies. I even had to look up what iccMax was. :-)

Because what you're actually asking for is ICCv2 profiles

I'm not sure why you say this. Because you'd want to return the smaller common denominator? Personally I was more on a logic that you return the display profile as-is, whatever it is, and let the calling software handle it (if they don't support, they don't, no big deal; as you note yourself, we have features we don't support in GIMP too and that's not a problem). Not trying to create a special lower-version/less-featured profile to return, with only a subset of features.

It encodes dynamic range. It also specifies a reference display and viewing environment. That should be enough information to convey what a user actually perceives.

Ok well, if you are sure it's for the best, I'm fine with it. Rec2020 is big enough a space that it should be good for a while.

What does the "PQ" part change in there? In babl we have support for the Rec2020 color space, but since you always prefix-it with "PQ/" I am now wondering if it's maybe a variant.

[swick]

Rec.2020 colorimetry and PQ transfer characteristics. PQ would be used to get some absolute luminance for a reference viewing environment and display. Though we probably don't want some non-linear encoding just to get the absolute luminance.

Maybe sending the xyY color as it would appear on the reference display in the reference viewing environment defined by ST 2084 is the best option?