4 ms·

Just tried using their latest code. Same 54MiB JPEG yielded (with cjpexl -q x) 3.8 MiB (q=70) 13 MiB (q=90) ("visually lossless (side by side). Default

Just tried using their latest code. Same 54MiB JPEG yielded (with cjpexl -q x) 3.8 MiB (q=70) 13 MiB (q=90) ("visually lossless (side by side). Default for generic input.") 19 MiB (q=95) ("visually lossless (flicker-test).") 40 MiB (q=100) ("mathematically lossless. Default for already-lossy input (JPEG/GIF)") I'm guessing q=100 is essentially (mostly, minus rounding errors) lossless non-reversible brunsli JPEG-XL. To compare, webp (cwebp -q x, also operating on a q=0...100 scale) 9.9 MiB (q=70) 18 MiB (q=90) 23 MiB (q=95) 28 MiB (q=100) 65 MiB (z=6, medium lossless preset) I didn't do exact timings but JPEG XL was noticeably faster, then again they use multithreaded (using 4 threads here) AVX2 code, which cwebp does not (used the debian provided package for webp), so I wouldn't pay too much attention to this result. Keep in mind JPEG XL isn't finished, and that neither are their defaults and recommendations.

bscphil 7y ago
That does sound very impressive. (Keep in mind, though, that there's no reason to think the q= settings give equivalent quality between JPEG XL and webp.) Also, your lossless encoding was only 40 MiB instead of 49 MiB for pure Brunsli, so presumably JPEG XL is capable of some stronger lossless compression.
- rndgermandude 7y ago
  Regarding brunsli vs JPEG XL "lossless": yes, JXL fared better there, but then again did not have the requirement of reproducing the bit-exact JPEG back on demand. So (as far as I understood) JPEG XL in q=100 will go back to the pixel data and run the the full JPEG XL coder on it (with no quantization to avoid loss), while JPEG XL in reversible "bg" mode[1]/brunsli will only decode back to the coeffs (so there is no loss at all) and then use their superior lossless (brunsli) coding to store these coeffs more efficiently along with some metadata to allow reconstructing the original file on demand. I could be wrong, I only skimmed the docs and code; when I was quite tired. [1] JXL has a "bg" mode too that is reversible to the original JPEGs, but that's currently not exposed by the cjpegxl tool. But I saw in in their benchmark tool, and there it produced essentially the same size files than plain brunsli tool did, probably because it's essentially just the brunsli tool.
  - bscphil 7y ago
    Yes, I believe that's right. JPEG XL is able to compress JPEGs in a way that is pixel for pixel identical to the output of a JPEG decoder, but can't be reversed into a bit exact copy of the original JPEG.
    - JyrkiAlakuijala 7y ago
      Just one clarification about this: As stated before in these comments, JPEG XL includes brunsli, so JPEG XL allows for byte exact transport of the original JPEG file (with -22 % in size). This can be practical for example for file system replication or for long term storage of a lot of original JPEGs. The other, non-brunsli JPEG XL modes can do pixel exact, but byte exact can be more appealing for some use cases.

bscphil 7y ago

That does sound very impressive. (Keep in mind, though, that there's no reason to think the q= settings give equivalent quality between JPEG XL and webp.) Also, your lossless encoding was only 40 MiB instead of 49 MiB for pure Brunsli, so presumably JPEG XL is capable of some stronger lossless compression.

rndgermandude 7y ago
Regarding brunsli vs JPEG XL "lossless": yes, JXL fared better there, but then again did not have the requirement of reproducing the bit-exact JPEG back on demand. So (as far as I understood) JPEG XL in q=100 will go back to the pixel data and run the the full JPEG XL coder on it (with no quantization to avoid loss), while JPEG XL in reversible "bg" mode[1]/brunsli will only decode back to the coeffs (so there is no loss at all) and then use their superior lossless (brunsli) coding to store these coeffs more efficiently along with some metadata to allow reconstructing the original file on demand. I could be wrong, I only skimmed the docs and code; when I was quite tired. [1] JXL has a "bg" mode too that is reversible to the original JPEGs, but that's currently not exposed by the cjpegxl tool. But I saw in in their benchmark tool, and there it produced essentially the same size files than plain brunsli tool did, probably because it's essentially just the brunsli tool.
- bscphil 7y ago
  Yes, I believe that's right. JPEG XL is able to compress JPEGs in a way that is pixel for pixel identical to the output of a JPEG decoder, but can't be reversed into a bit exact copy of the original JPEG.
  - JyrkiAlakuijala 7y ago
    Just one clarification about this: As stated before in these comments, JPEG XL includes brunsli, so JPEG XL allows for byte exact transport of the original JPEG file (with -22 % in size). This can be practical for example for file system replication or for long term storage of a lot of original JPEGs. The other, non-brunsli JPEG XL modes can do pixel exact, but byte exact can be more appealing for some use cases.