[RFC wayland-protocols] Color management protocol

Fri Jan 13 23:20:07 UTC 2017

Hello Graeme Gill

I read many comments on this topic including yours, and I agree with you 
about some points in particular about the calibration and profiling 
procedure, but I very puzzled by your position about some points. It's 
look like you hate display managers[1] because they are not able to 
produce accurate color from a given specification/definition/encoding.

I would like to point out that colorspace with pixel values is just an 
encoding for the color you would like produce on the monitor. That mean 
the compositor is capable to perform the translation to the monitor 
accurately as good as the given client application. He can do it even 
better because he has the hardware under-control and may have a wider 
community to support this feature.

I think you should drop the idea that the compositor cannot do something 
better than a specific application, by definition the compositor is an 
application.

Some comment about the reality you describe are following inline.

On 21/12/2016 01:08, Graeme Gill wrote:
> Richard Hughes wrote:
>> On 20 December 2016 at 07:22, Graeme Gill <graeme2 at argyllcms.com> wrote:
>>> Or be prepared to re-visit Wayland's fundamental design decisions
>>> if they turn out to be based on a false premise.
>>
>> I don't think that's fair. I think Wayland is the opportunity to upset
>> the status quo with color management and do correctly what what never
>> possible with X11.
>
> I think it is fair - a lot of push back is along the lines of
> "that's impossible - Wayland doesn't work that way", which
> if taken to a logical conclusion, (maybe) implies that Wayland is
> incapable of sporting color management.
>
> Assumption: "Applications are oblivious to the output their
> pixels are rendered to"
>
> Reality: An application needs to know the output it's pixels
> land on if it is to present them in the correct output specific
> colorspace.

I disagree, an application need to know what they want show then they 
need a way to tell the compositor what they want. An application that 
want have a pixel in 40 cd.m-2 of red with wavelength 750 nm, must know 
how to tell that to compositor, it may be 240,2,4 RGB in the color space 
sRGB (totally random conversion). But once the encoding is agreed the 
compositor can do the same as any color-managed-aware software. In other 
hand I can agree that a client may want to know monitor capability to 
adapt their display, for example if the display isn't wide-gamut I just 
fallback to a normal gamut rendering, because rendering wide gamut is a 
waste of effort.

In any case please drop this reality. And help to define how the client 
should tell to the compositor which color he want to show, and what is 
useful to know for an application.

>
> Assumption: "The compositor is able to do all the transformations
> necessary to render applications pixels to the output device"
>
> Reality: It may not be practical for a compositor to have the
> color conversion machinery capable of doing the transformations
> in the manner and to the precision that an application requires.
>

This reality is correct because you used 'MAY' but just assume the 
compositor can do all the transformations necessary to render 
applications pixels to the output device as good as any 
color-managed-aware software, even better because he will have a broader 
community. And also think that kind of transformation can probably be 
included in a library, which all compositors will be able to reuse. A 
little bit like libinput is currently used by a lot of compositor out-there.

> Assumption: "Graphical system API's can be divided into
> application operational API's, and Management API's.
> Wayland need only cover the former".
>
> Reality: Some graphical functions are both operational
> for one type of application, and management for other types
> of applications.

I do not understand this assumption, and obviously the related reality.

>
> Assumption: "All management functions can be incorporated in
> the compositor"
>
> Reality: Some management functions require full blown applications,
> and can't practically be incorporated in each compositor,
> nor tailored to each compositor.
>
> So if the realities challenge the assumptions, then
> either clever means need to be invented to get things
> to work within the assumptions, or the assumptions need
> to be softened. Saying "it's impossible" doesn't progress
> things, nor help bring Wayland up to having the capabilities
> of other existing systems.
>
> [ The above of course is, as best I grasp it from preceding
>   conversations. ]

I agree with you, because I understand the context but out of context 
the assumption "All management functions can be incorporated in the 
compositor" is valid, nothing forbid any software to be included within 
a compositor, if you want a compositor with Tetris inside, it's up to 
you. That say I will explain why I agree with you: because I agree that 
it would be nice to split the software that find the calibration value 
and build profile from the compositor, and I think we should find a 
privileged protocol to enable this design. In other hand I don't think 
that the configuration must be allowed to separate software. i.e. the 
privileged software has granted privilege for the calibration and the 
profiling, once they are done, he produce configuration files that 
should be feed to compositor by his 'specific' configuration system.

>
>> Lets be honest for a moment. How many applications support color
>> management on the Linux desktop? We're asking application authors to
>> understand things like blending spaces, source and destination
>> profiles, vcgt, overlapping windows on different crtc's and horrible
>> concepts like that.
>
> Agreed. Easier to access, and default color management framework
> is desirable (and for that reason was included in my sketch). But
> this shouldn't be at the expense of applications that need more
> than that, nor at the expense of color management applications
> needed to set things up so that all this can work in the first place.
>
>> As a framework guy, _and_ an app developer I just want to tag one
>> surface with a colorspace and then let the compositor figure out all
>> the grotty details.
>
> And you should be able to. But what about applications that need
> far more than that ? (Ordinary CMM's of the type that are likely
> to be practical in a compositor, lack a lot of capabilities
> that some applications will need).
>
>> Anything more and the application author will just
>> decide it's not worth the bother. To calibrate we just ask for a
>> surface that's not going to be tampered with, but we don't want to
>> optimize for this super-uncommon case.
>
> I disagree - leave it to be an afterthought, and it will be
> done badly or left out completely, crippling the practicality
> of color management for the system.
>
> Graeme Gill.
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

Another thing that seems misleading you and the wayland community is 
that you use 'standard' protocol, when you use this words in the wayland 
mailing-list it's read as wayland 'standard' protocol, in other world a 
standard that wayland community is responsible of. But an other path 
exists, you can build your own 'standard' protocol (understant wayland 
extension, like xrandr is an extension of X11 protocol), maintain it and 
lobby the compositor developers to implement it. This how the xdg-shell 
or wayland-wall are managed.

Before closing my email, I would like that we separate discussion of how 
regular client share color data with the compositor and the topic about 
how a software can perform calibration and profiling, even if I agree 
that both are needed to have color-managed-monitors, both topic are 
mostly orthogonal, imo.

my suggestion of title: "Enable color managed clients" and "Enable color 
calibration and profiling"

I hope this e-mail is constructive and will help for further discussions.

Best Regards

[1] a generic name that include X11/Wayland or any others of that kind.

--
Benoit (blocage) Gschwind