Premultiplied alpha?

[adroitwhiz]

A cursory search doesn't reveal anything in the way of specifying whether alpha values are to be stored premultiplied or not.

Earlier this year, I wrote up (then abandoned for a while) a proposal for getting premultiplied alpha values read into ImageData. In doing so, it attempted to more clearly specify the way that partially-transparent colors are represented in the canvas' backing store: it mandated that implementations store canvas data as premultiplied and defined what that meant within the spec itself.

At the time, I had no idea this proposal also existed, and I think mine would integrate into it quite well. Both proposals add a settings dictionary to ImageData-related functions, though there are some differences, which is the sort of thing I'm hoping coordination will prevent: mine is ImageDataOptions and this one is ImageDataSettings, and I added premultipliedAlpha directly onto the ImageData object while this one adds a getter function for the entire settings dictionary.

I actually first discovered this proposal when trying to add support for my own to Chromium, to find that the function overloads I wanted already existed, and was quite surprised to find that premultiplied alpha was already mentioned as a "future plan". Is this being discussed anywhere else?

[svgeesus]

I agree that

a) this should really be specified, one way or the other
b) it makes a big difference to the rendered result - it can't be implemented one way in one implementation, the other way in a different implementation, and have interoperability
c) The correct rendering in a linear-light colorspace is alpha-premultiplied, which is straightforward for RGB spaces and fairly easy to specify for XYZ, Lab. and LCH.

[kdashg]

This is all specified IIRC (de facto where not de jure), but it's a bit of a mish-mash of decisions unfortunately, since we all picked what makes the most sense at each decision point, without much holistic coordination.

Wherever it's not strictly specified, we should fix that to match the de facto agreement, but we should avoid risking overreach by starting discussions on how to make things more flexible at the same time. (or at least we should avoid blocking one on the other as much as we can)

Is there an issue against Canvas/HTML for this (these?) underspecification(s?)?

[adroitwhiz]

Is there an issue against Canvas/HTML for this (these?) underspecification(s?)?

I'm assuming you're referring to the specification of alpha format (e.g. specifying that canvas' backing stores are premultiplied, which is the case in all? current browsers but not currently specified)?

I can't find anything like that in whatwg/html--my original proposal is the only canvas-related premultiplication mention I've found. My draft PR does also clarify the spec's handling of premultiplied alpha. I could definitely detangle those clarifications from the proposed spec changes also in that PR.

[kdashg]

If you could disentangle those, it would help us quickly push through that specification fix!

[adroitwhiz]

The spec fix has gone through, and specifies that canvas' backing stores use a premultiplied representation.