On Wed, 14 Dec 2016 18:27:13 +1100 Graeme Gill <grae...@argyllcms.com> said:
> Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 18:18:21 +1100 Graeme Gill <grae...@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) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel