3 ms·

Lossless encoding can be done with various trade-offs between speed and compression density. At one extreme we have fjxl, see e.g. https://twitter.com/LucaVers

Lossless encoding can be done with various trade-offs between speed and compression density. At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?t=BFVNYj33K-sXuJY50CS5Cw&s=19 https://twitter.com/LucaVersari3/status/1485971553892323333?.... This is an extremely fast lossless jxl encoder, which is about 100 times faster than PNG encoding (libpng) and compresses about 10% better. At the other extreme, there are the slowest settings of the reference encoder libjxl, which are 1000 times slower than libpng but compresses a lot better. As for decode speed: this depends on whether you consider single-threaded or multi-threaded performance. In single-threaded decode performance, it is hard to beat PNG since it is basically just gunzip. PNG is inherently sequential though (unless you apply trickery at encode time to make parallel decode possible), while JXL is by design decodable in parallel. We are anticipating that in the future, the number of cores available on typical hardware will only grow, so this difference will naturally lead to JXL becoming faster to decode in practice. The current reference software libjxl is quite optimized for the lossy case, but still has some room for improvement for the lossless case — in particular it does not have fast paths yet for the common case where the full precision of 32-bit per sample is not required. So in conclusion, I think it is safe to say that JPEG XL beats PNG in all ways.

nigeltao 4y ago
fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster. If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways. I believe that Apple have an unofficial PNG extension that facilitates multi-threaded decoding: https://github.com/w3c/PNG-spec/issues/45 https://github.com/w3c/PNG-spec/issues/45
- jonsneyers 4y ago
  Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice. The problem with PNG extensions for multi-threading is that it only works if you control the encode side too — most existing encoders will not use such an extension. If existing deployments need to be replaced anyway, you can just as well use a new format altogether.
  - nigeltao 4y ago
    > Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded PNG versus multi-threaded $OTHER_FORMAT. At the file format level, MT PNG can be designed to be backwards compatible. Older PNG decoders simply ignore the new non-critical chunk. At the software level, you can roll out encoders that emit MT-capable PNGs without having to also roll out new decoders everywhere (or 99% everywhere, or 'on all major browsers'). You can roll out new decoders only partially, and those upgraded places enjoy the benefits, but you don't break the decoders you don't control. Also, in terms of additional code size, upgrading your PNG library from version N to version N+1 is probably smaller than adding a whole new $OTHER_FORMAT library.
    - JyrkiAlakuijala 4y ago
      PNG is ok if you don't care about the 60 % more bytes to transmit and keep around and legacy is important for you. If you care about speed or transmission cost, then you try to look elsewhere. WebP lossless already is quite a big improvement, and JPEG XL gives some more (not yet in decoding speed, though).
    - jonsneyers 4y ago
      I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns. I agree that MT PNG does have a gentler transition path than introducing a new format. The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, which can be hard given how many existing deployments of png there are. Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc. Also one disadvantage of MT PNG compared to JXL is that it splits the image in stripes, not tiles. For full-image decode, that doesn't matter much, but for region-of-interest (cropped) decode, tiles are a bit more efficient (no need to unnecessarily decode the areas to the left and right of the region of interest).

nigeltao 4y ago

fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster. If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways. I believe that Apple have an unofficial PNG extension that facilitates multi-threaded decoding: https://github.com/w3c/PNG-spec/issues/45 https://github.com/w3c/PNG-spec/issues/45

jonsneyers 4y ago
Did you compile fjxl with or without SIMD? That makes a big difference. And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice. The problem with PNG extensions for multi-threading is that it only works if you control the encode side too — most existing encoders will not use such an extension. If existing deployments need to be replaced anyway, you can just as well use a new format altogether.
- nigeltao 4y ago
  > Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded PNG versus multi-threaded $OTHER_FORMAT. At the file format level, MT PNG can be designed to be backwards compatible. Older PNG decoders simply ignore the new non-critical chunk. At the software level, you can roll out encoders that emit MT-capable PNGs without having to also roll out new decoders everywhere (or 99% everywhere, or 'on all major browsers'). You can roll out new decoders only partially, and those upgraded places enjoy the benefits, but you don't break the decoders you don't control. Also, in terms of additional code size, upgrading your PNG library from version N to version N+1 is probably smaller than adding a whole new $OTHER_FORMAT library.
  - JyrkiAlakuijala 4y ago
    PNG is ok if you don't care about the 60 % more bytes to transmit and keep around and legacy is important for you. If you care about speed or transmission cost, then you try to look elsewhere. WebP lossless already is quite a big improvement, and JPEG XL gives some more (not yet in decoding speed, though).
  - jonsneyers 4y ago
    I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns. I agree that MT PNG does have a gentler transition path than introducing a new format. The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, which can be hard given how many existing deployments of png there are. Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc. Also one disadvantage of MT PNG compared to JXL is that it splits the image in stripes, not tiles. For full-image decode, that doesn't matter much, but for region-of-interest (cropped) decode, tiles are a bit more efficient (no need to unnecessarily decode the areas to the left and right of the region of interest).