[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

On Monday, 19 December 2016, 13:08:13 CET, Graeme Gill wrote:
> 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.

Yes, exactly. But these are things that do not use the "normal" wayland 
protocols but are initiated by the compositor.
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.

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

Developers of compositors and CMS can (and probably should) standardize such 
an interface (for example a library API or a D-Bus interface). But this is out 
of scope for the wayland protocol.

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

> > - 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 totally agree. That's why I started this discussion.

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

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.

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

Apart from one thing you already have your core profile as far as the wayland 
protocol is concerned. Of course there is lots of work to be done in the 
compositors and how they interface CMS, but as I said these things are 
typically not part of the wayland protocol.

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.

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.

> Graeme Gill.
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel