←back to thread

A new PNG spec

(www.programmax.net)
614 points bluedel | 1 comments | | HN request time: 1.356s | source
Show context
LeoPanthera ◴[] No.44373778[source]
> I know you all immediately wondered, better compression?. We're already working on that.

This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files.

It'll be like USB-C but for images.

replies(11): >>44373790 #>>44373796 #>>44373928 #>>44373937 #>>44374139 #>>44374147 #>>44374842 #>>44375132 #>>44375261 #>>44375615 #>>44380021 #
Lerc ◴[] No.44373928[source]
It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress.

The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

replies(7): >>44374018 #>>44374025 #>>44374290 #>>44374346 #>>44374473 #>>44374501 #>>44374528 #
HelloNurse ◴[] No.44374528[source]
Extensibility of PNG has been amply used, as intended, for proprietary chunks that hold application specific data (e.g. PICO-8 games) without bothering other software.
replies(1): >>44377066 #
Lerc ◴[] No.44377066[source]
Doesn't pico-8 store the data in the least significant bits of colour? Maybe it got updated to use chunks.
replies(1): >>44385138 #
1. HelloNurse ◴[] No.44385138[source]
Yes, my mistake. I assumed common sense.

https://pico-8.fandom.com/wiki/P8PNGFileFormat

Actual cases of proprietary chunks include iDOT from Apple (apparently a performance optimization for plain images)

https://www.hackerfactor.com/blog/index.php?/archives/895-Co...

and the Macromedia Fireworks save files

https://stackoverflow.com/questions/4242402/the-fireworks-pn...