[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> When one integrates a CMS in a compositor, you no longer need to
> expose configuration (hardware configuration, like CLUT programming)
> via any protocol. The compositor talks directly with the CMS and if the
> compositor can set e.g. CLUTs, CMS can tell it what to set.

"cLUTS" are things in the ICC profile (Color, or multi-dimensional lookup tables.)
and are typically used (as part of a conversion) to represent a device response
or an overal color transformation.

VideoLUTs are in the graphics hardware (CRTC), and involve the setup
("calibration") of the display. ICC profile handle some aspects
of the display badly - namely white point setting, which has
been (deliberately) crippled in the ICC format, so setting the hardware
per channel Lookup tables is the way to work around that,
as well as having the benefits of ensuring that even non-color
aware applications all have a consistent white point and visual
transfer curve.
Without this, mixed visual white adaptation will destroy the usefulness
of the display.

An additional subtlety is that in typical hardware, the VideoLUT entry
depth is greater than the frame buffer depth, so setting the overall
visual transfer curve and neutral axis matching using
the VideoLUT has the advantage of extra precision (typically 2 or
more extra bits, quite noticeable on 8 BPP frame buffers). Because
the VideoLUTs are global to each display, all the applications get
the benefit of this, and it makes the profile more accurate by making
the display better behaved

There is a de facto standard in ICC profiles that display
profiles may include a tag that stores the display expected
VideoLUT values ('vcgt' tag), and since the contents of
the display profile are built on the assumption of that
set of calibration curves, systems typically install
that vcgt tag contents in the VideoLUTs when a profile
is set to be the one for that display.

But, to actually create the calibration curves, a color
calibration and profiling application needs to be able
to set the VideoLUT contents to specific values. Other
useful functions are to be able to read the VideoLUT
values, to be able to verify that the calibration is as
intended.

(A little more information is here:
 <http://www.argyllcms.com/doc/calvschar.html>)

> I am assuming that the compositor can interface with a CMS by calling
> into a library offered by the CMS. If that interfacing was previously
> done over X11, then you have to write that library. It will be more
> efficient too, since you don't have to serialize and deserialize, and
> asynchronicity (problems) appear only when you want to.

In X11 the VideoLUT setting/reading is done via XF86VidModeQueryExtension (old)
or XRandR (current). Typically the system color management support
will track the currently installed display profile, and set the
VideoLUT hardware (Gnome colord), or users will invoke
an equivalent utility at system startup (dispwin, xcalib etc.).
Such utilities also typically set an X11 atom or Output property
so that applications can obtain the display profile.

Note also that there are more things that an application
may want out of the current display profile than simply
the ability to transform into that space - they may
want to determine the color gamut, they may wish
to tag a window capture with the colorspace it is in, etc.

> I'm slowly starting to suspect that CMS designers need a slight paradigm
> shift: the compositor is meant to integrate with the CMS, instead of
> the CMS given low-level access to the hardware bypassing the window
> manager. CMS is no longer something that can be bolted on externally,
> like it is in X11. Embrace the idea of integration, and I belive and
> hope that it will pay off as a much more reliable architecture and
> polished user interfaces. Some of what used to go over X11 would
> probably be much better as a library ABI, but in X11 times it was not
> possible because X11 implied separate processes.

There is scope for moving in that direction, but care needs
to be taken not to reduce functionality as a consequence.

The chicken and egg problem remains - how do color management
applications exercise the hardware to create calibration curves,
as well as help manage the display color configuration by
installing profiles, etc. ?
Without the ability to create the calibration and profile,
you don't have a color managed system.

Graeme Gill.