[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:
> Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:

Hi,

>> I'm not quite sure what you mean. Generally an application will have
>> specific reasons for wanting to do it's own color management - for
>> instance, perhaps it is previewing a CMYKOGlclm file, and wants to
>> treat out of gamut mapping and black point mapping in a particular way, etc.
>> I don't think the Wayland compositor is going to be expected to handle
>> CMYKOGlclm etc. input rasters, never mind all the requirements of
>> specialist application color management!
> 
> This is of course something that the client application has to do. It would 
> query the main output for its surface, do the conversions to that color space 
> and then attach the output color space to the surface.

Right. So a protocol for querying the profile of each output for its surface is
a base requirement.

> The compositor now must not touch the parts of the surface on the main output 
> (where the color spaces match). But it could still try to convert from the 
> color space of the main output to that of a secondary screen if the surface 
> covers two screens with different color profiles.

Not as a base requirement. The application needs to be able to
do it's own color management, which means color managing for
every output the surface goes to. So the base requirement
has no rendering requirement for a composer - it's just
about signalling the required information to the client application.

> But then again most people that work with professional applications would not 
> make them cover multiple screens, I guess.

People using color managed applications expect color management to work as
best it can across multiple screens.

> Therefore I'm not opposed to adding 
> a flag that indicates that the application wants to disable color corrections 
> completely for that surface, independent of the output.

This is only something that becomes a question at the next
level, where there is an expectation that the composer
has some degree of color management capability.

>> Which is not to say that compositor color management doesn't have its
>> place - it is ideal for applications that just want to use "RGB", and
>> not deal with specific display behavior.
> 
> Very simple applications would just keep the attached sRGB color space and 
> maybe place images on subsurfaces with the embedded color space from the image 
> attached.

That works only in the case that the composer supports the image colorspaces.
This may well be the case for some applications (i.e. web browsers), but
I imagine it may not be desirable to insist that all composers supporting
a color management capability, support a full range of colorspaces (N - color in general).

> Applications that care a bit more about color correction (but do not have 
> professional needs) could convert all their colors to the blending color space 
> of the compositor. I'd expect this blending color space to be linear if the 
> compositor cares about good colors.

It's not clear to me that any application that is interested in good
color would trust it to blending operations.

I'd also imagine that there is a class of applications wishing to get the
compositor to deal with gross display differences (Wide gamut vs.
sRGB-like for instance) but is not interested enough in exactly what's going
on color wise to be aware of the distinctions between linear light space
compositing and other approaches.

Cheers,

Graeme Gill.