On Wed, 6 Mar 2019 18:09:27 +0100 Sebastian Wick <[email protected]> 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
pgpkGCL1ipvdQ.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
