[RFC wayland-protocols] Color management protocol

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

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

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.

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