[RFC wayland-protocols] Color management protocol

[Benoit Gschwind]

Hello,

It's very difficult to contribute to this discussion, but here is my 
delta contribution.

I agree with the following proposal with comment bellow.

On 19/12/2016 09:27, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 19 Dec 2016 17:01:50 +1100 Graeme Gill <graeme2 at argyllcms.com> said:
>
> ....
>
> at this point i'm going to summarize this. this might be more helpful than
> continuing point by point rebuttals as i sense that there's something missing
> in this conversation:
>
> summary of what i think should be the case (or roughly):
>
> 1. if colorspace/profile with buffer from client matches screen compositor
> SHOULD do nothing with the pixels unless it has to (eg has to blend them with
> content below or otherwise do effects etc. designated by its layout policy).
> 2. if null colorspace then compositors generally agree to ALSO not touch pixels
> and transform them unless it has to blend them etc. like #1, but irrespective
> of the output
> 3. if colorspace/profile does NOT match the display then compositor can either
> a) transform colors to get them correct on another display or b) leave them
> along and just leave things as they are and perhaps let the user know that the
> colors for that window/surface may be wrong on that display, or limit the
> screens that display that buffer based on context.
>
> how to clients select a colorspace? compositor sends available colorspaces to
> client (maybe send per surface actually?). client picks one and renders content
> given that colorspace/profile and presents that to the compositor for display.
> compositor may update colorspaces that are available at any time.
>
> colorspaces/profiles should be nominal colorspace with a whole bunch of numbers
> detailing adjustments/mappings to do exact color correction for that
> colorspace. if i have 2 sRGB monitors i may get 2 sRGB colorspaces each with
> different transform constants/gamma lut tables etc.
>

First this proposal do not cover the calibration and profiling 
procedure. This is about 'non-calibration clients' to use already used 
vocabulary, and I agree with the proposition to treat this topic 
independently of the calibration and profiling procedure.

The color space must be defined: color space define the link between the 
pixel value and the corresponding physical light property 
(Intensity/Luminescence, the mix of wavelength, ...?)[1]

To that proposal, I would add that the compositor should advertise the 
preferred color space. The definition of 'preferred' color space is 
implementation-defined (compositor-defined)[2]. For example a compositor 
may set the preferred color space to the color space that have the most 
accurate result, or the color space the most 'hardware' efficient 
(null-transform), or simply the user preferred color space[3]. He may 
not match any monitor color space.

We should also agree that surface that do not include color space 
specification should be null-transformed or maybe sRGB or something else 
(this is an open choice).

[1] I guess most color spaces are not defined as absolute light 
intensity but with relative intensity between a given black point and 
white point.

[2] I choose compositor-defined, because in case of multi-monitor it 
would be difficult to give a definition.

[3] I choose only one preferred color space instead of per monitor, 
because per-monitor color space, imply that client must known the 
monitor he belong.