[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Fri, 09 Dec 2016 14:29:14 +0100 Niels Ole Salscheider
<niels_ole at salscheider-online.de> said:

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

why not simply let the compositor decide. if a surface spans multile screens it
may have to emulate on another screen (egh one screen can do adobe arg, another
is ye-olde sRGB). this is simply a matter of letting the compositor know what
colorspace the rgb values are in so it can "do the appropriate thing". :)

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

if compositor just lists what colorspaces it can do, which happen to have
native hardware support (i.e. the display panel itself is capable of it), then
client can choose whatever works best, and compositor just "does its best" too
which may mean adjusting dislpay gammut or output transforms at the gpu level
or via side-bad protocols with the display panel itself if that were to exist.

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com