A solution for gamma-adjustment support in Wayland

[Graeme Gill]

Daniel Stone wrote:

> On 21 December 2016 at 11:31, Mattias Andrée <maandree at kth.se> wrote:
>> This is not
>> a sustainable solution, an API is necessary. It's bad
>> enough that colour management is done by the compositor.

>
> I also cannot disagree more with your assertion that 'it's bad enough
> that colour management is done by the compositor'. The compositor is
> the very thing between clients producing pixels, and the final output.
> If a compositor is unaware of how those pixels should be interpreted,
> then it is going to be destructive and do the wrong thing. If you want
> colour-accurate display, there is no good solution based on the
> premise that your display controller should have no idea about
> colours.

Hello Daniel,
	I think this betrays an lack of understanding of
the way color management operates. Almost all of the
time, it boils down to doing a conversion between two device
dependent colorspaces (i.e. sRGB to Display instance RGB,
FOGRA39 CMYK to Display instance RGB, ProPhotoRGB to Display
instance RGB, Epson P8070 instance to Display instance RGB,  etc.).

The agent for setting up this transform (CMM part 1) needs
access to 1) the source colorspace profile 2) the
destination colorspace profile and 3) the details of the
conversion intent, which encompasses white & black point
handling, neutral axis handling, gamut mapping and clipping
handling, viewing condition modifications, and possibly
abstract color modifications.

The agent for actually doing the pixel transformation (CMM part 2)
needs access to a definition of the overall transform created
by CMM part 1, the source pixel values and an assurance that the
destination pixel values be conveyed to the display in a manner
that is consistent with the way the test value pixels were
displayed when the output profile was created (generally
this equates to being relatively un-modified, or
modified in ways that further the color management task,
in order to produce the highest quality display, and
make the maximum display gamut available.)

Typically it is the application that has access to
most of this required information (multiple source profiles,
all the source pixel values, the details of the application
and user intent and how to interpret it), with the least
of it residing with the display sub-system (only the
display profile).

For color management therefore, there is no necessity for
a compositor to be interpreting color values, and many reasons
for it to be kept ignorant of it. To transfer some of
the color management tasks to the compositor is certainly
possible and for some aspects desirable, but it then takes on
the burden of a lot of things that have previously been the
purview of the application.

At a minimum there needs to be a means of transferring
source pixels to the compositor, as well as some not-future-limiting
means of transferring the overall transform to it, so
that it can implement CMM part 2.

To implement CMM part 1 as well, is an even bigger burden,
since the exact means of setting up the overall transform
is open ended, and attempting to codify it would impose
limitations on the user and future application development
that do not currently exist.

A much more tractable proposition is to allow the compositor
to perform a more limited in scope set of CMM funtions,
for the benefits of applications that are either not
color aware, or are satisfied with a more limited
set of capabilities. For instance, the compositor
may implement an "sRGB" emulation mode for such
applications.

There are other approaches possible, which attempt to
split up the color management operation into two
independent parts, but these approaches tend to be
highly imperfect in terms of performance,
quality (i.e. banding), gamut handling,
and flexibility (i.e. application capability).

Regards,
	Graeme Gill.