[RFC wayland-protocols v2 1/1] Add the color-management protocol

[Chris Murphy]

On Wed, Mar 6, 2019 at 5:28 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 6 Mar 2019 13:44:39 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:
>
> > Blending could convert from the device space back
> > to XYZ, blend, and then convert back to device space.
> > It would use whatever intent is appropriate for blending
> > purposes, i.e. probably Relative Colorimetric.
> > But I doubt this is the best approach. (see my previous
> > post on blending.)
>
> Hi Graeme,
>
> yes, you're right. I wrote that before I understood that the
> destination space can also be used for blending, it only needs to be
> linearized.

If the destination color space is defined by an actual display profile
(actual being a profile for someone's physical display; rather than an
idealized space such as sRGB, opRGB, ROMM RGB) you have to be careful
about some things.

Real displays often are not gray balanced. Calibration should achieve
this, often it can't. What if the display is characterized and not
calibrated to force R=G=B to be a neutral. And also what is neutral?
Usually the black point xy (chromaticity, CIE xyY space) is ignored
and assumed to be the same as the white point xy, but what if it
isn't?

Also, the display profiles for displays can contain errors. In
particular the case where the xy for the primaries don't add up to the
white point xy; that is R+G+B!=white, which is a basic violation of
physics but does end up getting baked into some ICC profiles typically
because someone did adaptation incorrectly or made some wrong
assumption somewhere. Firefox has some code to disqualify such display
profiles and just use sRGB instead. I think colord can do this too but
I don't think the metrics for disqualification are the same. Ideally
I'd like to see whatever is used to set the display profile does this
kind of check and immediately disqualifies the display profile with a
user notification.

I tend to refer to sRGB, opRGB/Adobe RGB (1998), ROMM/Prophoto RGB, as
"manufactured" or "idealized" or "quasi device-independent" color
spaces because they are well behaved, you can assume equal amounts of
RGB will produce a neutral, you can assume they approximately
perceptual linear (if you're also assuming the reference medium and
reference environment their color image encodings specify, and why not
assume that since everyone else is?).

I'm not clear to me what is the advantage of blending in 32bpc XYZ
versus blending in a 32bpc "manufactured" RGB color space. I literally
can't think of anyone actually doing that. Plus aren't most blending
algorithms already RGB based? So why change that?

The potential to blend in such a space and end up with massively
chromatic colors that can only be clipped to the destination gamut
boundary when converting to displayRGB, is real. We already run into
this problem, sometimes, when the blending space is linear ProPhoto
RGB (same primaries as ROMM RGB, using gamma 1.0 function instead of
1.8).

A possibly important side topic to understand about rendering intent
transforms: it is not intelligent or dynamic.


-- 
Chris Murphy