https://github.com/mattdesl/png-tools
I’ve also added some other features like multi-threaded encoding, cancellation, encoding physical dimensions, color profiles, all of which is useful for encoding large print-ready PNGs on the client.
(No shade against fast-png, it’s a good library, but maybe not the fastest!)
Only working on grayscale 16bit images with only the lower 10bits populated I never found it reduced image size. But I was doing per scan adaptive filtering so maybe if I was only allowed one filter for the entire image that would be it?
Just wondering if you did any experiments with different filter strategies?
EDIT: Thankfully I don't see any native code in this repo, it looked like a wrapper around a native binary at first. So the attack surface is smaller, but it's still worth being careful! You might want to check whether Inflator etc are robust.
Just sloppy TBH.
Would be interested to see a comparison to a thin WASM implementation in a low level language.
-- edit:
Looks like wasm-flate is much faster... not sure on overhead though.
My goal was not to be fast however, but to just document a good reference and be able to come back to it and understand what it was doing and what I wrote.
> Almost as fast in modern JS engines as C implementation (see benchmarks).
Impressive, although "almost" is doing some heavy lifting there.
> deflate-pako x 10.22 ops/sec ±0.33% (29 runs sampled)
> deflate-zlib x 18.48 ops/sec ±0.24% (48 runs sampled)
> inflate-pako x 134 ops/sec ±0.66% (83 runs sampled)
> inflate-zlib x 402 ops/sec ±0.74% (87 runs sampled)
Edit: stb_image_write exists, I was reading it wrong
And it doesn't look like the png crate provides a C API but if your usage is not overly complex it might be easy enough to byo?