[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Niels Ole Salscheider wrote:
> > Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb Graeme Gill:
> 
> >> Looking through the current Wayland color-management protocol
> >> proposal, I think it is missing a really fundamental thing -
> >> managing the output device color calibration state and color
> >> profile. I guess the assumption is that this is being done
> >> by colord, but my understanding is that colord is specific
> >> to Gnome based systems, and certainly depends on DBus, which
> >> Wayland does not. [ Please correct me if I've got any of this wrong. ]
> 
> > It is (currently) up to the compositor to decide how to implement this. The 
> > compositor could come with its own settings for the output color profiles
> > or query some other program. This might be colord, but it could also be 
> > kolormanager, or something else.
> 
> 1) This doesn't address how this information is communicated
>    to a Wayland application.
> 
> 2) Expecting color management applications to deal with
>    configuring the compositor in a platform dependent
>    way, is expecting far too much. I for one am not
>    about to add multiple platform dependent back
>    ends (multiple flavors of Linux, BSD's, Android,
>    etc.) to my tools to do this, and no other major
>    platform expects it (i.e. none of MSWindows, OS X
>    or X11 based systems have this requirement.)
> 
> The correct approach to avoiding such issues is simply
> to make both aspects Wayland (extension) protocols, so
> that Wayland color management and color sensitive applications
> have the potential to work across all Wayland systems,
> rather than being at best balkanized, or at worst, not
> supported.

"not supported" == sRGB (gamma). render appropriately. most displays are not
capable of wide gammuts so you'll HAVE to handle this case no matter what.
either compositor will fake it and reduce your colors down to sRGB, or your
apps produce sRGB by default and have code paths for extended colorspace
support *IF* it exists AND different colorspaces are natively supported by the
display hardware.


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