[RFC wayland-protocols 1/1] unstable: add color management protocol

[Chris Murphy]

On Thu, Feb 14, 2019 at 5:25 AM Sharma, Shashank via wayland-devel
<wayland-devel at lists.freedesktop.org> wrote:
>
> Well, REC2020 with HLG/PQ curves are not different color spaces, but they are the same color space with different non-linear curves. The colorspace here still remains BT2020 and its primaries are still the same, it's just that the encoding is being done using different curves.

ITU-R BT.2020 is a color image encoding, and that encapsulates color
space primaries, tone response curve (often defined as a gamma
function), white luminance, black luminance, reference viewing
conditions, and reference medium. You can't really separate all of
these things, and their interplay. If you do, you end up with a lot of
the confusion seen in desktop computing color management over the past
20+ years, which is WTF why doesn't it work? Oh, my viewing conditions
and your viewing conditions are not only not standard, but they're
also different from each other.

If BT2020 is a color space, and BT2100 is a color space, you end up
effectively saying BT2020 and BT2100 are the same just because their
primaries are the same. That's clearly wrong. So I think it's best to
not call them color spaces.

Whereas if you say BT.2020 and BT.2100 are different color image
encodings which so happen to share the same primaries, that's more
clear. The rest of those specs matter a lot.

There is a certain vagueness in what is a color space in ordinary
vernacular that even technical color people mess up all the time for
expediency; I'm willing to bet there is a canonical definition in
something like ISO TC 37, but I don't have a copy of that handy. So
anyway, what I try to do is refer to a specification or standard as a
color image encoding. And then specifically to its constituent parts
unambiguously.

I think some confusion with color space as a term comes from the
chromaticity diagram which is a 2D construction, so some people mean
color space to only refer to primaries. Where others think of color
space as a volume, because they grab an ICC profile and do a 3D plot.
So they're thinking in terms other than just primaries, they're
including cap Y (as in CIE xyY). But cap Y comes in unscaled and
scaled flavors. That matters too.

Consider two displays side by side, one with white luminance at 100
nits and another 1000 nits. The ICC profile for those displays will
say their whites are L* 100. If you do a 3D gamut plot of otherwise
identical displays using their ICC profiles, they will be identical.
So what's that about? L* is not luminance, it's lightness, it's
relative to a reference white. What is the reference white? Aha! A
display's profile always considers the display's white point and
luminance as the reference white, which is why every display profile
claims 255,255,255 RGB is L* 100. If we had an absolute luminance
mechanism where the profile could define luminance and actually cause
the brightness knob to move on everyone's displays, we'd have done
that. Maybe. OK no because we need other things like reliable viewing
condition sensors and integrated color appearance models and a new ICC
spec that makes necessary information to do these things actually
required. There's literally no requirement to put absolute luminance
in any device profile. It is optional, however. The tag exists and is
standardized, it's just not required.

OK so the mismatch between my display's white luminanance (display
reference white if you will), and the reference white for the
specification I'm using, can be expected to result in disappointment.
Which is why we try to follow standards as much as possible and where
we can't, we have to have agreement among all the people we work with
*how* we deviate from the standards. If we don't all have the same
conditions, we're going to have different rendering experiences.

And that is the long version on why 'color image encoding' as a full
encapsulating term of what's really important, is the ball to keep our
eye on, not just color spaces.


Chris Murphy