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

[Daniel Stone]

Hi Kai-Uwe,

On 20 December 2016 at 19:38, Kai-Uwe <ku.b-list at gmx.de> wrote:
> 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:
>>> 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 ;-)

Yes, if you look at the request as written, it's about _retrieving_
the compositor's single blending space, not setting one. I don't think
that's adequate, and as you say, it may be a good solution for clients
to provide profiles enabling the compositor to transform for both
final display and for blending.

>>> 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.

But that means that blending (in non-linear space) will look pretty awful. :\

>> 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.

It can assume, but it really shouldn't. The client can make its
guesses and assumptions about what's going on, but the compositor is
free to do much more than what it was under X11, and what it can
express to the client. Given the diversity of what compositors do:
blending, surface transformation/displacement and cloning across
multiple outputs, cloned outputs, screenshots/streaming, etc, this
will always be a guess. And this makes me wince every time I see 'opt
out'; the intention when writing it is 'the client knows what's going
on so can get it right', but I read 'the client doesn't know what the
compositor's doing and the compositor doesn't know what the client
means, which guarantees that it's going to get it wrong at some
point'.

I'm still missing some subtlety in your point, but perhaps there's
language you could suggest for some part of Niels's strawman spec,
which would strengthen these guarantees to a point a client could be
assured the right thing was happening. I don't see any future for an
'opt out' flag ever though.

Cheers,
Daniel