[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Donnerstag, 8. Dezember 2016, 13:33:20 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
> 
> Hi,
> 
> > The first version of my proposal had such a flag. I removed it and
> > replaced it by the described version based on feedback from Zoxc
> > (zoxc32 at gmail.com).
> Do you have a link to the specifics ?

Most of the discussion happened on IRC back then. It should be in the logs 
but...

> > I can see advantages with both solutions. One advantage with the current
> > proposal is that you can have a surface that covers multiple screens. In
> > this case the compositor can still try its best to correct the colours
> > for all but the main screen.
> 
> 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.

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.

This might of course cause artifacts when one of the screens has a too small 
gamut but still seems better than ignoring this.

But then again most people that work with professional applications would not 
make them cover multiple screens, I guess. 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.

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

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.
This would have the advantage that the compositor does not have to do the 
conversion "application output color space -> blending color space".

> > Back then I argued that this might not be good enough if you want to
> > calibrate the monitor. But the consent was that this would require
> > another protocol to disable all colour corrections anyway and that it
> > could be developed at a later point.
> 
> I strongly disagree with this idea - disabling application-side color
> management is a fundamental step in achieving end to end color management.
> You don't have color management until you are able to profile the output
> device, so this is not something that can be left until latter!
> 
> Graeme Gill.
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel