3 ms·

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 ma

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.

TAForObvReasons 7y ago
The landing page and comparison don't explain how their solution is faster. Are they just doing fewer of those filter passes?
- randy408 7y ago
  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.
  - hiccuphippo 7y ago
    Why can't libpng implement this? Is there any cons to doing this?
bhouston 7y ago
Amazing info. > libpng compresses the image rows multiple times with different filters to optimize for size, this filtering process is not optimized. Is there a way to disable this multiple-pass approach to get a slightly larger image that is generated faster? > The choice of zlib also makes a big difference, stock zlib is very slow, zlib-ng is the closest to a fast zlib alternative. I'm looking for benchmarks but I haven't found any that make it look good. This one makes it look nearly equivalent to zlib: https://quixdb.github.io/squash-benchmark/?visible-plugins=zlib,zlib-ng https://quixdb.github.io/squash-benchmark/?visible-plugins=z...
- randy408 7y ago
  > Is there a way to disable this multiple-pass approach to get a slightly larger image that is generated faster? Use png_set_filter() with PNG_NO_FILTERS. > This one makes it look nearly equivalent to zlib I don't know how squash is set up, but decompression performance depends on which library created the DEFLATE stream (see https://github.com/zlib-ng/zlib-ng/issues/326#issuecomment-471076049 https://github.com/zlib-ng/zlib-ng/issues/326#issuecomment-4...).
  - maxst 7y ago
    There is no multiple-pass. libpng only tries to guess the right combination of filters, without doing actual compression. It's not always a good guess, but at least it's fast.
- tialaramex 7y ago
  A sibling reply to this one tell you how to tell libpng not to bother using different filters and just always use the null filter, but this will make some input images into _huge_ files (maybe similar size to uncompressed image data) so be warned. If you had software that you knew spat out images with specific properties you could choose the filter by reference to what you know about the images, e.g. imagine you always produce noise anyway, the null filter is fine, if you produce a horizontal gradient you want the SUB filter, if a vertical gradient, the UP filter. But you'd need to make custom PNG code not rely on a generic library.

TAForObvReasons 7y ago

The landing page and comparison don't explain how their solution is faster. Are they just doing fewer of those filter passes?

randy408 7y ago
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.
- hiccuphippo 7y ago
  Why can't libpng implement this? Is there any cons to doing this?

bhouston 7y ago

Amazing info. > libpng compresses the image rows multiple times with different filters to optimize for size, this filtering process is not optimized. Is there a way to disable this multiple-pass approach to get a slightly larger image that is generated faster? > The choice of zlib also makes a big difference, stock zlib is very slow, zlib-ng is the closest to a fast zlib alternative. I'm looking for benchmarks but I haven't found any that make it look good. This one makes it look nearly equivalent to zlib: https://quixdb.github.io/squash-benchmark/?visible-plugins=zlib,zlib-ng https://quixdb.github.io/squash-benchmark/?visible-plugins=z...

randy408 7y ago
> Is there a way to disable this multiple-pass approach to get a slightly larger image that is generated faster? Use png_set_filter() with PNG_NO_FILTERS. > This one makes it look nearly equivalent to zlib I don't know how squash is set up, but decompression performance depends on which library created the DEFLATE stream (see https://github.com/zlib-ng/zlib-ng/issues/326#issuecomment-471076049 https://github.com/zlib-ng/zlib-ng/issues/326#issuecomment-4...).
- maxst 7y ago
  There is no multiple-pass. libpng only tries to guess the right combination of filters, without doing actual compression. It's not always a good guess, but at least it's fast.
tialaramex 7y ago
A sibling reply to this one tell you how to tell libpng not to bother using different filters and just always use the null filter, but this will make some input images into _huge_ files (maybe similar size to uncompressed image data) so be warned. If you had software that you knew spat out images with specific properties you could choose the filter by reference to what you know about the images, e.g. imagine you always produce noise anyway, the null filter is fine, if you produce a horizontal gradient you want the SUB filter, if a vertical gradient, the UP filter. But you'd need to make custom PNG code not rely on a generic library.