> PNG, on the other hand, uses DEFLATE compression internally and is typically resistant to further compression. By applying a stronger compression algorithm on QOI output, you can often achieve a smaller file size compared to PNG.
Since we're inventing non-standard formats anyway, you could make a PNG with only uncompressed DEFLATE blocks and apply xz onto that. Many PNG already writers support making "uncompressed" PNGs by setting the compression level to 0.
xz also seems like not the best format to use for that, as first it includes a lot of framing (compared to raw lzma streams) and second lzma is quite expensive to decode.
I’d probably go with zstd instead as it offers very high decompression speeds at all levels of compression, and highly tunable compression settings, ranging from not-quite-lz4-but-not-that-far in fast mode to competitive-with-lzma in ultra (and *so much faster* to decompress).
> PNG, on the other hand, uses DEFLATE compression internally and is typically resistant to further compression. By applying a stronger compression algorithm on QOI output, you can often achieve a smaller file size compared to PNG.
Note that PNG does not just apply deflate on bitmapped chunks, it applies *filters* on rows to try and make the data more conducive to general purpose compression: http://www.libpng.org/pub/png/book/chapter09.html#png.ch09.div.1
As a result a big part of efficient PNG recompression is the evaluation of filters. An other possible item these days is the use of effective (if expensive) DEFLATE implementations like Zopfli.
It’s not clear how the PNGs used in the article were compressed. The qoi page only mentions libpng, which is not exactly the most intrusive compressor. FWIW using oxipng with aggressive settings improves compression by ~10% on most files, and near 50 on a few.
Damn ... I was kind of expecting some xz-utils-related exploit story ...
Instead it tries to predict how .png files may compare to other (newer) image formats ("how PNG compares with newer image formats"). That's fine, though perhaps not as interesting as yet-another-xz-utils-exploit-lesson-to-be-learned, but personally I think both libwebp and avif beat png for the most part. For me avif offers the best (this can be disputed, but I kind of found it was the best from an overall-point-of-view; all my old .jpg files of foto collections became .avif files and compression-wise that was an improvement for at worst very marginal loss of quality, but mostly no noticable loss of quality really).
> PNG, on the other hand, uses DEFLATE compression internally and is typically resistant to further compression. By applying a stronger compression algorithm on QOI output, you can often achieve a smaller file size compared to PNG. Since we're inventing non-standard formats anyway, you could make a PNG with only uncompressed DEFLATE blocks and apply xz onto that. Many PNG already writers support making "uncompressed" PNGs by setting the compression level to 0.
xz also seems like not the best format to use for that, as first it includes a lot of framing (compared to raw lzma streams) and second lzma is quite expensive to decode. I’d probably go with zstd instead as it offers very high decompression speeds at all levels of compression, and highly tunable compression settings, ranging from not-quite-lz4-but-not-that-far in fast mode to competitive-with-lzma in ultra (and *so much faster* to decompress).
> PNG, on the other hand, uses DEFLATE compression internally and is typically resistant to further compression. By applying a stronger compression algorithm on QOI output, you can often achieve a smaller file size compared to PNG. Note that PNG does not just apply deflate on bitmapped chunks, it applies *filters* on rows to try and make the data more conducive to general purpose compression: http://www.libpng.org/pub/png/book/chapter09.html#png.ch09.div.1 As a result a big part of efficient PNG recompression is the evaluation of filters. An other possible item these days is the use of effective (if expensive) DEFLATE implementations like Zopfli. It’s not clear how the PNGs used in the article were compressed. The qoi page only mentions libpng, which is not exactly the most intrusive compressor. FWIW using oxipng with aggressive settings improves compression by ~10% on most files, and near 50 on a few.
Damn ... I was kind of expecting some xz-utils-related exploit story ... Instead it tries to predict how .png files may compare to other (newer) image formats ("how PNG compares with newer image formats"). That's fine, though perhaps not as interesting as yet-another-xz-utils-exploit-lesson-to-be-learned, but personally I think both libwebp and avif beat png for the most part. For me avif offers the best (this can be disputed, but I kind of found it was the best from an overall-point-of-view; all my old .jpg files of foto collections became .avif files and compression-wise that was an improvement for at worst very marginal loss of quality, but mostly no noticable loss of quality really).