[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:
> I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
> more about color management than I do. But as Pekka already pointed out there 
> are a few constraints that originate in the design decisions of wayland and 
> are quite different to these of X11. We can't change these constraints but 
> have to find a solution that works well with them:

> - A normal application CANNOT control the hardware directly (it can't program 
> LUTs, for example).

Right, so it is not a normal application, it's a management application
that has the privileges to do so.

> - A normal application CANNOT alter global settings of the compositor (like 
> setting color profiles for the outputs). This can only be done by the 
> compositor or a few trusted applications.

Right - and therefore those trusted applications need to include
color management applications.

> The user will just have to use the 
> settings dialog provided with the compositor. Because of that it does not 
> matter if this is implementation dependent.

Hmm. I'm not sure what you mean by "settings dialog provided with the compositor".
Sounds like an application. For color management, the user often needs
specialist tools to create calibrations, profiles, and to manage the
system color configuration. That's what standardized API's are
meant to provide, a means of mixing and matching tools so that
systems don't have to be monolithic.

> - 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.

> - We aim to be pixel-perfect.

Great. But perfect means the correct color as well. So mechanisms to
provide correct color are needed if you are to achieve perfection.

> I think these constraints mean that we must let the compositor take part in 
> the color correction, at least if more than one screen is involved.

I don't think this is either desirable, adequate, or necessary. For
some levels of color management I agree it will be desirable and
adequate, which is what my "Enhanced" extension sketched out, as
a variation of your extension. But the reality is that no compositor
can have all the required mechanisms to convert colors in the way
that demanding color critical applications may require. So it
shouldn't handicap Wayland in ways that none of the alternatives
are handicapped, but provide a mechanism for applications
to do it the way they need. It's shouldn't be hard. There are only two
things asked of the compositor :- provide the application the Surface
to Output region information it already has internally, and convey
the color values to the display(s).

> If we do 
> so, we should also be able to expect that the compositor can handle a bit more 
> complicated cases (e. g. an arbitrary number of different surfaces with 
> different color profiles).

Providing source color profiles may satisfy many simple color management
requirements, but it won't satisfy all. This is only a problem if
there is no "escape" mechanism to work around such limitations.

> When I proposed this protocol my focus was on applications that may not be 
> color managed currently. I thought for example about web browsers or simple 
> image viewers where I would view (but not edit) photos.

Yes, I understand. This is an important class of color management usage.

> Your focus is obviously on professional applications. I think both use cases 
> are equally important and we should not treat one as an afterthought of the 
> other.

Right. I agree, but technically I think one builds on the other.

> I would be glad if we could come up with a solution that works for both under 
> these constraints.

I sketched out two extensions. Please critique and/or refine and/or contrast
them with other alternatives

Graeme Gill.