Wayland color management protocol proposal

Graeme Gill graeme2 at argyllcms.com
Mon Jul 22 19:18:58 PDT 2013


Kai-Uwe Behrmann wrote:

> Am 19.06.2013 04:52, schrieb John Kåre Alsaker:

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

Display profiles with a VCGT tag won't reflect the display behaviour if you
disregard the VCGT, thereby making it useless.

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

Things like ArgyllCMS dispcal & dispread expect to be able to read and write the
VideoLUTs, and I'm not aware of too many other tools currently for creating color
profiles on *nix systems. VideoLUT access is both part of the expected video display
workflow, and an important mechanism for getting around frame buffer depth limitations
- many systems have an 8 bpc frame buffer but a 10 or more bpc VideoLUT entry
depth. Particularly with wide gamut displays, you need all the bit precision you can get
when dealing with the raw device values, and such extra precision has been available
for many, many years (we had it available on our X terminals circa 1990 for instance.)

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

Yes, this is a possibility. It doesn't solve the bit depth issue though.

OS X "solves" the VideoLUT sharing problem by using the installed display profile
VCGT as the system default curves, while any application can set it's own VideoLUT
values when it's running, and it's changes are undone when it terminates. (This
can be rather painful when testing and setting up though, as there are times when you
want to be able to simply load a set of persistent calibration curves.) I'm not sure
if it does uses a last set policy, or a stack so as to undo VideoLUT changes in order.

I'm wondering what consideration there are for transition and support of established
systems such as X11. ie. We should be aiming for the current set of X11 color
management tools to just work when X11 is running on top of Wayland, not have
things such as XRandR simply stop working.

Graeme Gill.



More information about the wayland-devel mailing list