> 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…".
[1] https://www.w3.org/TR/PNG-Encoders.html#E.Alpha-channel-crea...
[2] https://www.realtimerendering.com/blog/png-srgb-cutoutdecal-...