Live data from Hacker News

A new PNG spec

programmax.net

621–622 of 622 posts

Re: A new PNG spec

#621

Earlier quoted context omitted.

> 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. What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://…

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…

> 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).

Re: A new PNG spec

#622

Earlier quoted context omitted.

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…

> 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…

> “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-...

Post reply on HN