[RFC wayland-protocols] Add the color-management protocol

[Daniel Stone]

Hi Graeme,

On 21 December 2016 at 01:15, Graeme Gill <graeme2 at argyllcms.com> wrote:
> Daniel Stone wrote:
>> However, another
>> client could then come along and force your client off the plane, such
>> that you land in the compositor's GPU pipeline before display: this
>> rendering may be done in a 'lowest common denominator' colourspace,
>> such that the most optimal / least lossy output from your colour-aware
>> client would then _not_ correspond to your display device's native
>> characteristics.
>
> Some details make for possible disadvantages with color
> critical applications. Is a "lowest common denominator" space
> one with a gamut smaller than any attached display, ensuring
> that every color can be displayed without loss, while not
> allowing any use of a displays full gamut, or is it
> a colorspace that has a larger gamut than any attached
> display, meaning that colors will get clipped in
> ways the application has no control over, or may
> not want ? (i.e. the particular application may
> want some other intent such as perceptual or saturation
> gamut mapping).

I mean lowest common denominator _between clients_, whilst still being
tied to the output. So the gamut would ideally be as wide as (the
specific output + highest gamut buffer being painted during this
stage), but in taking multiple clients with potentially disparate
colour source attributes and producing a single flat buffer, you may
need to unpick some properties of the client's colour attributes.

This is quite a big difference from X11, in that there is no longer a
giant single buffer for all displays. One of the benefits of the
aggressive decoupling we've done ...

Cheers,
Daniel