4 ms·

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in partic

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG XL lossless encodes 10x slower and decodes 12x slower than PNG (the libpng implementation), and decodes 30x slower than PNG (the wuffs implementation). JPEG XL does admittedly win on compression ratio (smaller files), though. https://github.com/nigeltao/qoir/blob/main/doc/full_benchmarks.txt https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...

jonsneyers 4y ago
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.
simplotek 4y ago
Thank you for putting in the effort to benchmark and quantify performance. There is nothing like verifiable numbers to drive a discussion on performance improvements and marketing.
lifthrasiir 4y ago
Your benchmark seems to lack options used. JPEG XL has two main knobs for quality and speed, as I've previously mentioned in [1], and the default effort 7 (which is, assuming that you didn't set any other options, presumably used in your benchmark) would definitely prefer compression ratio over compression speed. You will need multiple entries for JPEG XL with varying efforts for a fair compraison. [1] https://news.ycombinator.com/item?id=33401540 https://news.ycombinator.com/item?id=33401540
- nigeltao 4y ago
  IIUC, the quality knob (not the effort knob) isn't relevant for lossless encoding. Knobs are also less relevant for lossless decoding, where there's only one correct output for any given input. In any case, my code (https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapter.cpp https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapt...) copy/pastes examples/encode_oneshot.cc from the libjxl repository, plus an additional JxlEncoderSetFrameLossless call. So I'm using whatever knob values that the libjxl example uses, i.e. the default knob values. If there are better knob values for lossless, let me know.
  - pizza 4y ago
    Just want to mention that modular mode (the encoding technique for lossless mode) does have flags that let you have a bit of loss (by changing a quality flag), though by default what you said is correct, it is fully lossless.
JyrkiAlakuijala 4y ago
I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.
- nigeltao 4y ago
  I agree that compression ratio is the primary metric (but not the only important metric). I just found "[better] in all ways", explicitly calling out encode speed, incongruous with simply ignoring decode speed. As for which is more important out of encode and decode speed, I would personally rank decode speed higher. For example, app icons on your home screen were encoded once (by the graphic artist) but are decoded zillions of times (by every user every day).
  - JyrkiAlakuijala 4y ago
    Agree with decode time being more important. There we still can improve. We have ideas how to make it faster than WebP lossless, but haven't engaged with that yet -- the lossless decoding is already fast enough not to be a blocker. Also, given how efficient and quality-sure the lossy is, it will become tempting to migrate many of the PNG/GIF/WebP lossless cases to JPEG XL lossy further reducing the priority in JPEG XL lossless. This can be a 4x-5x savings whereas a better lossless is only 10-40 % savings in density.

jonsneyers 4y ago

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.

simplotek 4y ago

Thank you for putting in the effort to benchmark and quantify performance. There is nothing like verifiable numbers to drive a discussion on performance improvements and marketing.

lifthrasiir 4y ago

Your benchmark seems to lack options used. JPEG XL has two main knobs for quality and speed, as I've previously mentioned in [1], and the default effort 7 (which is, assuming that you didn't set any other options, presumably used in your benchmark) would definitely prefer compression ratio over compression speed. You will need multiple entries for JPEG XL with varying efforts for a fair compraison. [1] https://news.ycombinator.com/item?id=33401540 https://news.ycombinator.com/item?id=33401540

nigeltao 4y ago
IIUC, the quality knob (not the effort knob) isn't relevant for lossless encoding. Knobs are also less relevant for lossless decoding, where there's only one correct output for any given input. In any case, my code (https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapter.cpp https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapt...) copy/pastes examples/encode_oneshot.cc from the libjxl repository, plus an additional JxlEncoderSetFrameLossless call. So I'm using whatever knob values that the libjxl example uses, i.e. the default knob values. If there are better knob values for lossless, let me know.
- pizza 4y ago
  Just want to mention that modular mode (the encoding technique for lossless mode) does have flags that let you have a bit of loss (by changing a quality flag), though by default what you said is correct, it is fully lossless.

JyrkiAlakuijala 4y ago

I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.

nigeltao 4y ago
I agree that compression ratio is the primary metric (but not the only important metric). I just found "[better] in all ways", explicitly calling out encode speed, incongruous with simply ignoring decode speed. As for which is more important out of encode and decode speed, I would personally rank decode speed higher. For example, app icons on your home screen were encoded once (by the graphic artist) but are decoded zillions of times (by every user every day).
- JyrkiAlakuijala 4y ago
  Agree with decode time being more important. There we still can improve. We have ideas how to make it faster than WebP lossless, but haven't engaged with that yet -- the lossless decoding is already fast enough not to be a blocker. Also, given how efficient and quality-sure the lossy is, it will become tempting to migrate many of the PNG/GIF/WebP lossless cases to JPEG XL lossy further reducing the priority in JPEG XL lossless. This can be a 4x-5x savings whereas a better lossless is only 10-40 % savings in density.