[RFC wayland-protocols] Color management protocol

Wed Dec 21 00:44:31 UTC 2016

On Tuesday, 20 December 2016, 13:38:55 CET, Graeme Gill wrote:
> 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 ?

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.

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

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.

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.

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 result of solution 3 would be similar to solution 2 but it would avoid the 
overhead. It would also be easier from a protocol perspective.

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

> 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.
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel