randy408

Fixed, thanks.

There are trade-offs with every library, libspng is safe to use with arbitrary data, with stb_image that isn't clear yet and lodepng is significantly slower.

Submit a bug report on github, appveyor doesn't report any issues with VS2017.

Naming things is hard, I wanted to have 'png' in the name and still have a short prefix for the API that matches the name.

libspng doesn't support encoding images yet, the benchmarks show decode time. It is faster at decoding because it minimizes its per-pixel overhead, e.g. if a PNG image is has an RGBA 8-bit layout and it matches the requested output format it will just decompress and defilter the image rows, in this case there is no per-pixel code at all. Encoding is almost the same process backwards so it's more than likely it will be faster at encoding too, even if it would the same strategy for optimizing compressed size.

libpng compresses the image rows multiple times with different filters to optimize for size, this filtering process is not optimized. The choice of zlib also makes a big difference, stock zlib is very slow, zlib-ng is the closest to a fast zlib alternative.

That page took 15 seconds to load

They don't seem to prioritize user choice on the linux version either, there's no snap/flatpak available nor a user friendly option to not mount the FUSE filesystem.

https://github.com/keybase/client/issues/8264

https://github.com/keybase/client/issues/9191

https://github.com/keybase/client/issues/7846

It would make the source file ~6k actual lines once the encoder and other features are added, but I see your point.

If you look at that crate's issue tracker you can see open issues titled "Crash on malformed input", "4-bit grayscale image is read as 8-bit", I don't think it's safer or even tested to be correct. For spng there is continuous regression testing which verifies the decoded images against libpng and is fuzzed by OSS-Fuzz (https://github.com/google/oss-fuzz) just like libpng.