Wayland color management protocol proposal

[Kai-Uwe Behrmann]

(taking Richard out of CC as he replied on list)

Am 19.06.2013 04:52, schrieb John Kåre Alsaker:
> Here is my current color management protocol for Wayland clients. The
> basic idea is that the compositor sends two color spaces to the
> clients. A compositing color space which the compositor prefers since
> it would require no conversions. A full-screen color space which the
> compositor can be able to scan out from. The full-screen color space
> is intended to used by games which are able to do color conversions as
> part of their post-processing. It's also possible it could be used by
> video players.

Just rewording to get all in sync about the terms.
The "compositor colour space" appears like a kind of document colour 
space, which the desktop/display is in. In the existing colour managed 
compositors that defaults to sRGB, but can of course be a different 
space like you suggest here.

The "full-screen color space" reads like the main outputs device space. 
Is that notation correct?

For various clients it would be essential to see each outputs native 
space as well. Multi monitor aware colour correction in some essential 
for artists applications as well as analysing software come to mind.

> Different rendering intents and more advanced color spaces have not
> explicitly been considered here, but I hope the use of ICC profiles
> will cover these.

 From a architecture point of view, that is not so easy. There are few 
CMS'es around to modify the rendering bits in a ICC profile. Secondly as 
the profiles are passed by file name, that would require copying before 
giving to Wayland, which sounds unfortunate and might cause confusion 
later on.

> Calibration tools will require explicit privileges in order to do
> their job. Using the full-screen color space won't be enough since
> video card gamma correction can apply to it. I also wonder if we can
> just remove the VCGT tag from the ICC profiles to indicate that the
> client doesn't have to correct for that, but I'm not sure that anyone
> would use the tag anyway.

Sending a faked "no VCGT" profile is slightly indirect, but might work 
out. That needs to be documented very well. A calibration/profiling 
program needs then to set the VCGT-less profile to the output in 
question and then displays its measurement patches on a surface without 
colour conversion.

To deprecate the VCGT tag is not so easy, as we have lots of legacy 
profiles around from windows / osx software and directly from vendors. 
Ignoring the VCGT tag is no option, modifying the profile by baking the 
VCGT tag into the ICC standard colorimetric descriptions might be a 
workaround inside a CMS.

kind regards
Kai-Uwe