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

[Kai-Uwe]

Hello Daniel,

Am 20.12.2016 um 17:44 schrieb Daniel Stone:
> On 20 December 2016 at 14:46, Kai-Uwe <ku.b-list at gmx.de> wrote:
>> Am 20.12.2016 um 15:25 schrieb Daniel Stone:
>>> On 19 November 2016 at 16:29, Niels Ole Salscheider
>>>> +    <request name="blending_colorspace">
>>>> +      <description summary="tell the client what blending space is used">
>>>> +        This request returns a zwp_colorspace_v1 object for the blending color
>>>> +        space of the compositor. All surfaces are converted by the compositor
>>>> +        to the blending color space before the blending operations. Once the
>>>> +        blending is performed, a further color conversion to the output color
>>>> +        spaces is carried out by the compositor.
>>>> +        A client should render in the blending color space returned by this
>>>> +        request if it does any color conversion on its own. This allows the
>>>> +        compositor to skip the color conversion to the blending color space.
>>>> +      </description>
>>>> +      <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
>>>> +    </request>
>>>
>>> This might be a stupid question, but is the blending colourspace
>>> constant, or could it feasibly be changed if you had, e.g., outputs
>>> with different characteristics? I understand that blending in linear
>>> space is a must, but are there other considerations in play which
>>> could suggest multiple 'blending spaces' for a single compositor? (I
>>> would expect that if the blending space was to be constant across
>>> outputs, then it should also be statically derivable by clients,
>>> making this event redundant.)
>>
>> PDF, SVG2 require handling of different blending color spaces. So the
>> interface appears to be useful.
> 
> I'm not quite sure how this response relates to my question, unless
> you are discussing a Weston compositor which targets PDF and/or SVG.

I am talking about source documents, which might be PDF or SVG. And in
these the blending space can change. So a Wayland client might draw each
PDF/SVG element to a Wayland surface and would come in need to switch
the blending space for rendering the document. Doing it all in Wayland
makes the server much more powerful.

> In Niels's strawman proposal, there is only _one_ blending colourspace
> for _every_ blending operation performed in the _entire_ compositor.

Ah ok. So take my comment as the hint for a possible use case for
multiple blending spaces ;-)

>>>> +    <request name="output_colorspace">
>>>> +      <description summary="returns the color space for the requested output">
>>>> +        This request returns a zwp_colorspace_v1 object for the requested
>>>> +        output. A client can use this when it does not want its surfaces to be
>>>> +        color-corrected. In this case it can attach the color space of its main
>>>> +        output to its surfaces.
>>>> +      </description>
>>>> +      <arg name="output" type="object" interface="wl_output" />
>>>> +      <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
>>>> +    </request>
>>>
>>> If a client doesn't want its surfaces to be colour-corrected ... won't
>>> the compositor still convert into blending space and back (not
>>> necessarily a lossless operation), if blending is required?
>>
>> Likely.
>>
>> My concern is that input == output color space => NULL conversion is
>> flacky. A explicite opt out of color correction would be much appreciated.
> 
> What does an explicit opt-out actually mean? Does it mean that the
> compositor assumes sRGB? Linear? That a NULL transform is applied when
> scanning out directly from that surface? When going through a GPU
> composition pipeline, is the inverse transform from the output
> colourspace to blending colourspace, or does 'opt out' mean that
> blending is performed directly in the target colourspace?

>From the main use case of drawing channel values unaltered to the
output, I would say the later. That is as well the current behavior,
without any color correction and changed happening only while blending.
There is no gamma conversion, no color space conversion. The conflict
might be that blending ops work currently best for gamma encoded values
and might be changed to work for linear gamma 1.0 . The transition from
a gamma image to convert to linear gamma for blending should not be
noticeable, perhaps measurable. Further there is the need to copy the
surface for blending to linear gamma. For this case, do not touch the
values, it appears appropriate.

> I'm also curious as to what you mean by it being flaky.

Flaky - the client cant not know what happens to its values as
output==output => NULL is a implicit rule. It might be optimised out or
whatever at will of the server and the client is a real looser as it is
only a weak suggestion. A Do Not Touch (or opt out) marker is pretty
clear to everyone and the client can assume to remain in control like
with a contract.

Kai-Uwe