Use specialized DEFLATE implementation for PNG compression

[Shnatsel]

https://github.com/image-rs/fdeflate is a DEFLATE implementation specialized for use in PNG. It is written for the png crate and improves the compression performance several times: image-rs/image-png#364

It sounds like a great fit for the compression step of zune-png.

[etemesi254]

Interesting, will definitely look at it when that time reaches

[Shnatsel]

There is also a way to very quickly decode the images encoded with this method, image-png is adopting it now so that it could very quickly decode its own images: image-rs/image-png#373

[etemesi254]

I was wondering what fintella was up to until it hit me what they're doing is that they are ignoring match finding step of deflate.

That will definitely make it fast for both encoding and decoding because of

• For encoding, there is no need to use match finders, which are quite expensive
• For decoding, there is no need for backreferences, since all distance codes are just a run of zeros, and in knowing this, and if you have your vec resized with zero, it becomes a simple number increment.

Very interesting.

But one drawback jumps out for me,

1. Effectiveness, compression is not just a speed frontier, otherwise we would all be using lz4, its a speed space frontier, what people call pareto frontier, Charles bloom, one of the authors of Oodle Kraken, a compressor used in ps5 and most games has an article about it https://cbloomrants.blogspot.com/2016/04/oodle-kraken-pareto-frontier.html
   What people get wrong when designing compressors is that they optimize for speed without thinking about space. So fdeflate may work and it may be really impressive in benchmarks i.e qoi speeds but it breaks down the minute it meets real world images.

Also note, qoi uses a set of images to for the benchmark , which image/rs is using. As mentioned in my Benches.md for png (we got interlaced support and 16 bit support sometime ago, almost done with it)

Benchmarking may not reflect real world usage.
The author has a tendency of finding one big file, and decoding it and using that as a metric for optimizations.
This means probably results may be skewed to the author's liking.

Which usually means,

1. The author started with one file and a sketch of an encoder/decoder.
2. The author learnt about characteristics of that file
3. The author optimized the compressor for that file
4. The author released 'biased' claims about how good their encoder is.

I haven't tested it yet, but it would be interesting to see how randomly internet scrapped png files work with fdeflate.

Also, the encoder/decoder are using state machines, I think if you are rolling out an optimized encoder/decoder, the first thing not to do is a state machine, I'll talk more about this in a blog once I get all materials ready

[Shnatsel]

Yes, this definitely sacrifices compression ratios. But it provides very fast writes to a commonly used image format, and the result is still somewhat compressed (roughly comparable to QOI).

There is definitely room for this kind of speed/ratio trade-off. For example, I recall the author of https://github.com/RazrFalcon/resvg complaining that writing to PNG takes the vast majority of the time spent in rendering SVG to raster with their tool.

This is used only in fast compression mode; for all other modes the png crate uses miniz_oxide.