←back to thread

A new PNG spec

(www.programmax.net)
616 points bluedel | 3 comments | 24 Jun 25 13:01 UTC | HN request time: 0.812s | 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 #
koito17 ◴[25 Jun 25 05:57 UTC] No.44374025[source]▶
> Having an extensible format and electing never to extend it seems pointless.

This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about.

For instance, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).

replies(4): >>44374437 #>>44374579 #>>44374729 #>>44374926 #
1. bayindirh ◴[25 Jun 25 07:13 UTC] No.44374437[source]▶
JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility.

Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind.

Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.

replies(1): >>44374957 #
2. cm2187 ◴[25 Jun 25 08:35 UTC] No.44374957[source]▶
Video files aren't a good analogy. Before God placed VLC and ffmpeg on earth, you had to install a galaxy of codecs on your computer to get a chance to read a video file and you could never tell exactly what codec was stored in a container, nor if you had the right codec version. Unfortunately there is no vlc and ffmpeg for images (I mean there is, the likes of imagemagick, but the vast majority of software doesn't use them).
replies(1): >>44376878 #
3. bayindirh ◴[25 Jun 25 13:07 UTC] No.44376878[source]▶
I lived through that era (first K-Lite Codec Pack, then CCCP came along), but still it holds.

Proprietary or open, any visual codec is a battleground. Even in commercial settings, I vaguely remember people saying they prefer the end result of one encoder over another, for the same video/image format, not unlike how photographers judge cameras by their colors.

So maybe, this flexibility to PNG will enable or encourage people to write better or at least unorthodox encoders which can be decoded by standard compliant ones.