> The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.
> And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
You can't represent additive pixels (i.e. glowing pixels) with non-associated alpha. That's why this is used in exactly zero image processing software, internally.
E.g. an associated pixel with the 8bit/channel RGBA value 255, 0, 0, 0 (glowing red).
Because PNG can only store associated data a reader must associate before displaying. And that will give you a value of 0, 0, 0 after (black instead of additive red).
See e.g. [1] why this matters.
Additionally the PNG spec does not specify if the alpha is linear. Some PNG readers/writer assume it is, some assume it has gone through/should go through an sRGB transfer curve instead. It mostly works until it doesn't.
The fact that the spec. doesn't specify which one it should be is another telltale sign that it was written by people unaware of the subtleties of image processing.
I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time (pre-SVG) and most image processing software (i.e. mainly Photoshop then) would not dither gradients for 8bit, this really mattered.
But it's 2025. And when 16bit PNG got introduced this should have definitely had associated (and explicitly linear) alpha.
> I understand that unassociated alpha gives you more precision in 8bit and since people wanted to e.g. store color ramps (with alpga) in PNG at the time…
They do not mention precision at all in their rationale for that: “We standardized on non-premultiplied alpha as being the lossless and more general case.”
> And when 16bit PNG got introduced...
PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
> “We standardized on non-premultiplied alpha as being the lossless and more general case.”
How is this "more general"? Unpremultiplied is actually lossy (not so as far as precision goes but critically so if you talk about meaning/information).
> PNG has supported 16-bits per component since it was first introduced (see version 1.0 of the spec or RFC 2083).
True, my bad. But there have been many updates to the spec over the years.
I btw found a mention of alpha to be assumed to be linear in [1] but in a comment in a sample code snippet.
Quote:
/*
* Compositing is necessary.
* Get floating-point alpha and its complement.
* Note: alpha is always linear; gamma does not
* affect it.
*/
On the note of alpha: [2] is a good piece to read to understand why this matters, specifically the section "PNG cannot store all clamped linear values…".
> And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.
What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://www.w3.org/TR/PNG-Rationale.html#R.Non-premultiplied...