4 ms·

Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-thre

Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.

jaffathecake 12d ago
Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench/ https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?
- spider-mario 12d ago
  Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
  - jaffathecake 12d ago
    That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result. At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
    - F3nd0 12d ago
      jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
    - janwas 11d ago
      There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles. Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images. JPEG XL ensures this information is always available.

Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.

jaffathecake 12d ago

Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench/ https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?

spider-mario 12d ago
Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
- jaffathecake 12d ago
  That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result. At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
  - F3nd0 12d ago
    jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
  - janwas 11d ago
    There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles. Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images. JPEG XL ensures this information is always available.