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!)
superfamicom 32 minutes ago [-]
Nice! Remarkably similar to my own PNG implementation. I don't think I have pushed up the encoding work I did but should. I would highly recommend anyone / everyone to write a parser for a file format, you learn a lot. I also didn't implement the interlacing support.
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.
Seems to largely rely on the pako package in npm fpr inflate/deflate. The deflate method seems faster than the zlib implementation it compares to for compression, decompression(inflate) seems slower.
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.
I had to look this week for a faster/lighter png encoder in cpp, couldn’t find any alternatives to libpng.
masklinn 4 minutes ago [-]
libsnpng is pure C.
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?
mmozeiko 1 hours ago [-]
https://github.com/veluca93/fpnge is a very fast png encoder. A bit lower compression ratio, but runs significantly faster than alternatives. Here is a presentation with benchmarks:
stb_image is a single header image encoder/decoder that is used pretty widely across game development codebases. and it supports a ton of different formats.
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!)
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.
https://github.com/uttori/uttori-image-png
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.
https://drbh.github.io/wasm-flate/
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?
https://www.lucaversari.it/FJXL_and_FPNGE.pdf
https://github.com/nothings/stb
> 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)