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

Graeme Gill graeme2 at argyllcms.com
Thu Mar 7 04:53:01 UTC 2019

Chris Murphy wrote:

Hi Chris,

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

Right, but I don't think that's relevant to alpha blending in a per channel
linearized device space. Given that the main alternative is blending
in the non-linear device space, anything closer to linear light will
give more natural blending behavior, and if you blend any combination
of the same color with alpha values that add up to 1.0, the color
should be untouched. (i.e. I'm not proposing that the space be
used for color edits!)

> 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).

Properly ordered alpha blends should never add up to greater than 1.0,
so there is no possibility of the blended result exceeding the
space gamut. Of course it's far easier to do a per component
clip if needed in a linearised display space.


More information about the wayland-devel mailing list