Consider using Zstandard and/or LZ4 instead of Deflate

[richgel999]

One of the issues we have with .PNG is slow read/write times. There are now new lossless open source codecs without patent concerns, such as Zstandard (maintained by Facebook) or LZ4:

https://facebook.github.io/zstd/ https://github.com/lz4/lz4

Zstandard is used by the new Khronos KTX2 GPU texture format specification. I propose that it be added as an option to a future version of .PNG. The possible speedups are quite significant, and for users that read and write a lot of .PNG's as part of their data processing pipelines the speedups will be high value improvements.

There are also other far simpler but even faster codecs being developed, such as .QOI's, but using this would likely require changing or not filtering the image before compression: https://news.ycombinator.com/item?id=29328750

[svgeesus]

That is an interesting possibility, but would be a significant work item as it would be completely incompatible with all existing image creation and display software.

I propose that it be added as an option to a future version of .PNG. The possible speedups are quite significant, and for users that read and write a lot of .PNG's as part of their data processing pipelines the speedups will be high value improvements.

Do you have any data on that speedup, for PNG?

[randy408]

The existing file format does allow for additional compression/filter methods and new ones could be added to a PNG 2.0 standard.

The situation would be similar to JPEG XL where jpeg-only decoders cannot read .jxl files but they can be transcoded back and forth without loss of information. Websites serve the older format if the browser is not capable of reading the new one.

There are also other far simpler but even faster codecs being developed, such as .QOI's, but using this would likely require changing or not filtering the image before compression:

There is a 'None' filter type, you're still left with an extra leading 0 byte on each row, if that's a problem a new 'null' filter method could do away with the filter byte entirely.

[vrubleg]

Brotli is also a popular choice: https://github.com/google/brotli It is used for WOFF2 fonts and already supported as Content-Encoding in modern browsers.

It is worth to consider making this extension available as a new Content-Encoding similar to jxl for JPEG. So, a browser receives a recompressed file, but for a user it looks like a standard PNG. It will be required to store a bit more information to make possible restoring original PNG back (as it is done in JPEG XL for recompressed JPEG files).

[birdie-github]

Zstandard/ZSTD looks like a better choice since it's already supported by Chrome/Firefox and it features extremely fast decompression, in fact it's faster than gzip that has been used for decades now.

[wisp3rwind]

Here's a datapoint on the potential performance benefit: https://github.com/catid/Zpng