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

[Daniel Stone]

Hi Kai-Uwe,

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.

In Niels's strawman proposal, there is only _one_ blending colourspace
for _every_ blending operation performed in the _entire_ compositor.
This means that the blending colourspace must be independent of the
output devices; in this case, it is relatively easy to replace this
with a single fixed colourspace.

If there was a per-output blending colourspace (as well as final
display colourspace), that would make a great deal more sense to me.

>>> +    <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?

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

Cheers,
Daniel