[RFC PATCH v2 0/6] Initial per-surface color management

Niels Ole Salscheider niels_ole at salscheider-online.de
Mon Oct 13 10:40:45 PDT 2014

It has been a few months since I sent the first version of the patches adding
per-surface color management
I finally got around to addressing some of the issues of the first proposal.

Color profiles are now represented by protocol objects. They can be created
by passing a file descriptor of the profile to the compositor instead of by
passing the data directly. The compositor then uses the signature of the
passed profile (md5 sum) to make sure that each profile is stored only once.
The attached profile is now double-buffered.

The support to mask the area of a surface so that its color space is not
converted has been removed. Instead, the color profile of the main output
of that surface can be attached if an application has a need to display
uncorrected colors.
This is not enough for color profiling tools but these will need another
protocol that also allows to reset the hardware LUTs.

In the last discussion, Pekka Paalanen asked if it is reasonable to expect
that each compositor that wants to provide color correction implements the
complete protocol or if it would be enough for simple compositors to only
provide the output color spaces. However, color management with such a
simplified protocol gets very difficult for the clients when there are
multiple outputs. Another point is that the client side implementation gets
much less complex when using the full protocol together with sub-surfaces so
that it becomes more likely to see widespread use of this protocol.
Finally, the required effort to support the full protocol in the compositor
is not that high. I therefore think that it is best to require to implement
support for the full protocol.

The implementation of the color conversion is still not perfect. It still
uses an LUT with 8 bit per color, for example. John Kåre Alsaker however
has some patches that would help here like the support for desktop OpenGL.

More information about the wayland-devel mailing list