[RFC wayland-protocols] Color management protocol

[Carsten Haitzler (The Rasterman)]

On Wed, 14 Dec 2016 18:27:13 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill <graeme2 at argyllcms.com> said:
> 
> >> 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). 
> 
> No, not supported = native device response = not color managed.

and for most displays that is sRGB.

> > render appropriately.
> > most displays are not
> > capable of wide gammuts so you'll HAVE to handle this case no matter what.
> 
> I've no idea what you mean.

most displays have "horrible color response". they are sRGB. they cannot
display a wider part of the color spectrum. some professional monitors/displays
can do this. eg 98% of abobe RGB for example.

either way monitors tend to have slightly different color reproduction and most
are "not that good" so basically sRGB. the compositor then is effectively
saying "unmanaged == sRGB, but it may really be anything so don't be fussy".

> > 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.
> 
> No compositor is involved. If the application doesn't know
> the output display profile, then it can't do color management.

it can assume sRGB.

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