[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Yes, exactly. But these are things that do not use the "normal" wayland 
> protocols but are initiated by the compositor.

I'm not sure what you mean by that. Why should the compositor launch
applications ? The user should launch applications they want to
use in the normal fashion they launch applications!

> In practice this will mean that a compositor will use LCMS / ArgyllCMS / ... 
> and the corresponding tools to accomplish these goals. The compositor might 
> use them as libraries, or maybe have a private D-Bus interface for them.
> But it will be the compositor that initiates any action.

Not going to happen. They are not libraries, they are full blown,
complex applications. And they can't use D-Bus, because Wayland
doesn't use D-Bus. Think of (a future) remote Wayland as a test case.
How does a the remote user calibrate, profile and install the
a profile at a remote display they are sitting at ?
To work anywhere a Wayland application works, they
need to be Wayland applications, using the Wayland protocol.
(And the user will rightfully want to be able to choose
 which color management tools they use, not be locked into
 whatever the compositor provides - if it provides anything
 at all that is, something I rather doubt.)

> Developers of compositors and CMS can (and probably should) standardize such 
> an interface

And that is exactly what I want to happen.

>  (for example a library API or a D-Bus interface).

Using different mechanisms for communication raises
a host of issues about support and coordination of
Wayland and color management actions.

> But this is out of scope for the wayland protocol.

Why is that so, given that compositor at the end of the Wayland
protocol has the job of managing graphics hardware ?

>>> - You DO NOT know which parts of a surface are shown on which screen.
>>
>> So that needs to be fixed for color aware applications to be able to provide
>> display colorspace values.
> 
> That will be rather difficult in general.

I simply don't understand why. Wayland already has some of that
information available, in a less precise way :- it has
enter and leave events when a surface starts overlapping
or ceases to overlap a scanout region of an output.
All that is needed is the region information to
go along with those events.

> I understand that you cannot satisfy all requirements by having ONLY a simple 
> color conversion to output color space in the compositor.
> 
> But are there transformations from input to output color space that cannot be 
> expressed as a (complex) transformation from input to intermediate space (by 
> the application) and then another transformation from intermediate to output 
> color space? At least as long as the intermediate color space does not clip 
> any color values.
> I really do not know the answer to that and I will trust you on this.

Yes. The ICC PCS mix-and-match model has some notable limitations -
in fact it verges on conceptually broken, because it's not possible
to do real gamut mapping because the source gamut is divorced from
the destination gamut when the transformations are created.
The PRMG approach is sort of a fudgy workaround, but can't solve
the problem. See
<http://www.argyllcms.com/doc/iccgamutmapping.html> for a discussion
that touches on this.

So if an application is content to use pre-computed ICC A2B and B2A
transforms, and put up with the limitations of mix-and-match
intent selection and operation (perhaps it is satisfied by
colorimetric with profile default clipping, or generalized
gamut compression), then this is perfectly fine, and covers
a lot of ground. But I don't think a color management
solution should prevent an application doing better than
this if it wishes to go to the trouble, nor do I think
that Wayland should have limitations that preceding systems
don't have. Doing better than this means constructing overall
device to device transforms (source space to display space) where it
can use real gamut mappings, and can compute
higher precision transforms by inverting the A2B table
of the output profile rather than using the lower precision
pre-computed B2A table, etc. Or maybe some detail of the
compositor CMM doesn't work properly (CMM's have differences
and bugs), so an ability to implement its own CMM
is highly desirable. On top of that, calibration and
profiling applications need to be able to set display
values to do their job. So all this adds up to some means
of passing color values unchanged (or perhaps with an application
determined device to device conversion, which could be set to null)
from the application to the display.

>> I sketched out two extensions. Please critique and/or refine and/or contrast
>> them with other alternatives
> 
> Apart from one thing you already have your core profile as far as the wayland 
> protocol is concerned.

You mean the display ICC profile ? How is that set though ?

> The one thing missing from a wayland protocol perspective is that you do not 
> know which parts of the surface cover which screen. This is a design decision 
> and I do not expect that this will change. One reason is that the answer is 
> often not that simple (a region can be displayed on multiple screens) or that 
> the compositor might not even know in advance.

Yet that information exists.

> What MIGHT be possible is that an application provides the complete surface in 
> all color spaces of all outputs so that the compositor can use the parts it 
> needs.

Yes, that's an interesting thought. Another thought that avoids
the application having to know the exact surface to output mapping
would be for the application to provide a device link for
each output (I'm currently thinking through the implications
of such an approach.) Both ideas have similar issues -
you really want the per output pixels or device links to
be provided by the application on demand - i.e. when a surface
first overlaps an output, so that it doesn't have to pre-compute
pixels or device links for all possible outputs, even if they
never get used. This has interactivity implications. I think
there are probably pragmatic answers to these types of problems,
it just comes down to whether they are acceptable or whether
there are better alternatives.

Graeme Gill.