[RFC wayland-protocols v2 1/1] Add the color-management protocol

[Graeme Gill]

Kai-Uwe wrote:

Hi Kai-Uwe,

> See above. Without offloading the conversion to the compositor, that
> will be typical slower. Maybe I am wrong? But I do not see too many
> applications doing GPU color management by their own. For certain they
> do not share the color transforms in memory.

but the point is to allow an application to do its own
color management if it needs to. You can't offload every
possible color conversion to the Compositor, it's too open
ended. It would have to handle up to 15 channels, and compose
minute elements of the application sources (i.e. consider
a PDF proofing application where different elements have
different source colorspaces and intents), etc.

Suggesting that an application convert to some sort
of intermediate colorspace has problems too :-
it doesn't save on execution time - in fact it increases
it by needing a double conversions, and it wrecks any
sort of nuanced gamut mapping - if the intermediate
colorspace is smaller than the display it will unnecessarily
limit the gamut, and if it is bigger it will clip or over
expand rather than ending up with the same result as
(say) an application that creates an "intelligent" gamut
mapping.

So the suggestion is that the compositor have limited
color conversion capabilities so that it can convert
between a buffer and a secondary display when a surface
is multiply mapped, as well as provide default color management
for applications that are color unaware, or do not wish
to implement color management themselves.
The limited scope makes compositor implementation
optimizing quite tractable too.

> As a implementation detail, the compositor needs to cache the color
> transforms in memory as they are expensive on first run or cache even on
> disk. The later happens typical as device link profile. So, the
> compositor might choose to support device links anyway. In my experience
> on desktop color management and application color management, the
> implementation effort for device link versus without is similar.

Yes, caching the link or (perhaps) matrix & Luts or 3D texture is a necessary performance
optimization in the compositor implementation. But this should be invisible
to the applications.

Cheers,
	Graeme Gill.