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

[Graeme Gill]

Pekka Paalanen wrote:

Hi,

> another thought about a compositor implementation detail I would like
> to ask you all is about the blending space.
> 
> If the compositor blending space was CIE XYZ with direct (linear)
> encoding to IEEE754 32-bit float values in pixels, with the units of Y
> chosen to match an absolute physical luminance value (or something that
> corresponds with the HDR specifications), would that be sufficient for
> all imaginable and realistic color reproduction purposes, HDR included?

I don't think such a thing is necessary. There is no need to transform
to some other primary basis such as XYZ, unless you were attempting
to compose different colorspaces together, something that is
highly undesirable at the compositor blending stage, due to the
lack of input possible from the clients as to source colorspace
encoding and gamut mapping/intent handling.

AFAIK, blending just has to be in a linear light space in
a common set of primaries. If the surfaces that will be
composed have already been converted to the output device colorspace,
then all that is necessary for blending is that they be converted
to a linear light version of the output device colorspace
via per channel curves. Such curves do not have to be 100% accurate
to get most of the benefits of linear light composition. If the
per channel LUTs and compositing is done to sufficient
resolution, this will leave the color management fidelity
completely in tact.

> Or do I have false assumptions about HDR specifications and they do
> not define brightness in physical absolute units but somehow in
> relative units? I think I saw "nit" as the unit somewhere which is an
> absolute physical unit.

Unfortunately the HDR specifications that have been (hastily) adopted
by the video industry are specified in absolute units. I say unfortunately
because the mastering standards they are derived from have a specified
viewing conditions and brightness, something that does not occur
in typical consumer viewing situations. So the consumer needs a "brightness"
control to adapt the imagery for their actual viewing environment and
display capability. The problem is that even if the user was to specify
somehow what absolute "brightness" they wanted, the HDR specs do not
specify what level the "typical" (or as I would call it, the diffuse
white value) of the program material should be, so there is no way to
calculate the brightness multiplier.

Why is this important ? Because if you know the nominal diffuse white
(which is equivalent to the 100% white of SDR), then you can know
how to process the HDR you get from the source to the HDR capabilities
of the display. You can map 100% diffuse white to the users brightness
setting, and then compress the specular highlights/direct light source
values above this to match the displays maximum HDR brightness level.
(Of course propriety dynamic mappings are all the rage too.)

Interestingly it seems that some systems are starting to simply
assume that the HDR 48 or 100 cd/m^2 encoding level diffuse white level,
and going from there.

> It might be heavy to use, both storage wise and computationally, but I
> think Weston should start with a gold standard approach that we can
> verify to be correct, encode the behaviour into the test suite, and
> then look at possible optimizations by looking at e.g. other blending
> spaces or opportunistically skipping the blending space.

The HDR literature has a bunch of information on encoding precision
requirements, since they spend a lot of time trying to figure
out how to encode HDR efficiently. Encoded HDR typically uses
12 bits, and 16 bit half float encoding would work well if you
have hardware to handle it, but for integer encoding, I suspect
24 - 32 bits/channel might be needed.

> Meaning, that all client content gets converted according to the client
> provided ICC profiles to CIE XYZ, composited/blended, and then
> converted to output space according to the output ICC profile.

See all my previous discussions. This approach has many problems
when it comes to gamut and intent.

Cheers,
	Graeme Gill.