[RFC wayland-protocols v2 0/1] Color Management Protocol (pre-multiply)

[Pekka Paalanen]

On Wed,  6 Mar 2019 18:09:27 +0100
Sebastian Wick <sebastian at sebastianwick.net> wrote:

> Sending in v2 with small fixes only. I'm using this in the hope to focus
> the previous discussion in the direction of the actual protocol and
> implementation.
> 
> It looks like we have come to at least some consensus on a few points.
> If anyone disagrees here that would be great to know.

...

> Which brings me to open issues:

Hi Sebastian,

I just recalled one more issue:

5. What to say about alpha channel pre-multiplication?

On Wayland, all pixel formats that carry an alpha channel are assumed
to be pre-multiplied. From color correctness perspective I believe that
is detrimental because it assumes blending will happen in whatever
non-linear space the pixels are given in (probably sRGB). To be able to
blend in linear space, the compositor needs to first divide by alpha,
then apply degamma as far as I understood.

Would it be desirable that when a color profile object is created or
set on a wl_surface, the pixel values in the surface's buffers must be
not pre-multiplied?

Or should pre-multiplied be a completely orthogonal property?

I suppose that pre-multiplied with non-linear-light values is
nonsensical, but if a client is providing linear-light values then
pre-multiplied could be ok.

There may be significant precision loss if pre-multiplied values need
to be divided by alpha, at least with integer formats.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190313/57f65a40/attachment.sig>