←back to thread

A new PNG spec

(www.programmax.net)
616 points bluedel | 1 comments | 24 Jun 25 13:01 UTC | HN request time: 0.203s | source
Show context
LeoPanthera ◴[25 Jun 25 05:06 UTC] 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 ◴[25 Jun 25 05:35 UTC] 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 #
1. chithanh ◴[25 Jun 25 07:19 UTC] No.44374473[source]▶
> Adding another compression form should be handled by existing software

In an ideal world, yes. In practice however, if some field doesn't change often, then software will start to assume that it never changes, and break when it does.

TLS has learned this the hard way when they discovered that huge numbers of existing web servers have TLS version intolerance. So now TLS 1.2 is forever enshrined in the ClientHello.