[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

Hi,

>> Why is that so, given that compositor at the end of the Wayland
>> protocol has the job of managing graphics hardware ?
> 
> Because wayland does not have protocols for configuration as others have 
> pointed out. There isn't even a protocol to change the screen resolution.
> You can try to discuss this fundamental design decision but I do not expect it 
> to change.

I understand, but I then wonder where Wayland and it's
associated systems sit. Is this an architectural problem,
or is it that the required surrounding eco-systems
are too immature or non-standard ?

> Ok, I understand the problem: For high quality perceptual gamut mapping you 
> need to know the input and the output gamut and the precomputed tables might 
> assume a wrong corresponding profile.

Right. Having that capability somewhere, guarantees that there are
no artificial limits on algorithm or precision, and future proofing it.

> I can only see three solutions to that problem:
> 1) The compositor does all gamut mapping with a high quality.
> 2) The application does all the gamut mapping and provides a surface for each 
> output.
> 3) Device link profiles.

> I think 1 would fit into the wayland design and would have the additional 
> benefit that all applications (not only professional ones) benefit from it.
> The disadvantage would be that it adds complexity to the compositor and the 
> latter is responsible for good results: If a compositor has a bad CMM there is 
> not much the application can do about.

Implementing a standard ICC based CMM is pretty easy if you use lcms as
a base, and what it does is well understood and predictable.
Implementing something more than that is an open ended problem,
and I don't think any attempt should be made to codify it into a
standard system.

> Solution 2 comes with an overhead and brings some problems when there is no 
> surface for a specific output (e. g. because it was just plugged in).
> I'm not sure how easy it would be to make this work. Maybe someone else can 
> comment on this?

The reaction seems negative. I suspect it can be achieved, but
there seems little prospect of such support being accepted
at the moment.

> Maybe allowing the application to choose between 1 and 3 would be a good 
> idea...

Here's where my current thinking is in terms 3):

  * Allow each surface to have a (source) colorspace ICC profile
    set for it. This invokes standard CMM link to create a transform.

  * Allow each surface to have one device link ICC profile for each
    output set for it. This would be used in preference to the source
    device profile if it is set.

  * An application could create and set a device link when
    it notices a surface overlaps an output via the existing
    event. The compositor would re-render a surface if
    the applicable profile changes or is set.

Problems with this:

 *  Applications that wish to dictate the source to display
    conversion have to work harder in creating the device links,
    something they don't have to do on other systems.

  * It may not be reasonable to ask Wayland and the compositor
    to handle arbitrary number of color channel rasters and
    transforms. If not, then the application has to work pretty
    hard - pick an intermediate RGB colorspace to
    render the incoming images to, then create a profiles/device
    link from that working space to the output space.

  * How future proof are ICC device links as a means of
    conveying the desired transform ? What about HDR etc.
    as a test case ?

This doesn't address any of the problems of supporting
calibration, profiling or color setup, nor how display
profiles are installed or read by applications.

Cheers,

Graeme Gill.