4 ms·

Another feature that is very interesting to me is bit-exact lossless conversation between jpeg and jpeg-xl, in both directions that is. This essentially allows

Another feature that is very interesting to me is bit-exact lossless conversation between jpeg and jpeg-xl, in both directions that is. This essentially allows to take a jpeg, run the vastly improved lossless compression stages of jpeg-xl over the the original lossy compressed jpeg data (jpeg "coefficients"), preserve metadata, and get a jpeg-xl result that the jpeg-xl implementations understand, and which you can losslessly convert back to an ordinary jpeg that is a bit-exact reproduction of the original jpeg, if need be. The compression ratio will not be as good as full jpeg-xl (having skipped the lossy stages), but you still get something in the range of 20% smaller file sizes without any additional quality loss whatsoever. This is something WEBP/AVIF/HEIC does not offer. When using those codecs, you will either have to accept additional lossy compression artifacts on top of the artifacts of the original jpeg codec, or convert in lossless mode with worse compression ratio.

LinAGKar 4y ago
I wonder how the compression ratio of JXL-ified JPEG compares to WEBP/AVIF/HEIC.
- rndgermandude 4y ago
  Comparing compression ratios is tricky. What you usually want is "file size at same visual quality" or "visual quality as same file size" for comparisons. The problem here is that "visual quality" is in the eye of the beholder, Different base images will have different results. There are some attempts at such comparisons, e.g. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... (cloudinary might be biased, as they are a major driver behind jpeg-xl) My overall impression is that it's roughly on par or a little behind with AVIF, somewhat ahead of HEIC and very ahead of WEBP (and jpeg of course) in quality-per-byte. As for encode and decode speed, it's a bit slower than WEBP but beats AVIF and HEIC by a margin (unless these codecs are back by hardware encoders). However, all three codecs are relatively new and there may be a lot of future speed optimizations possible. Especially jpeg-xl, which isn't "backed" by general AV1 (AVIF), vpx (WEBP) or HEVC (HEIC) research, may have a particularly large yet to be tapped potential for (hardware-specific) optimizations. As far as I know, jpeg-xl is also "simpler" than those other codecs (which basically used the iframes of their complex sibling video codecs as a base), so it might be more feasible to have more competing implementations. But time will tell, and it will of course also largely depend on the adoption and thus network effects of these formats who much "love" each format receives from open source and proprietary software vendors.
  - jonsneyers 4y ago
    Generally speaking the results I've seen so far indicate that at low bitrates (e.g. below 0.5 bpp), the video codecs (AVIF, HEIC, VVC) perform best, while at medium to high bitrates, JPEG XL performs best. This makes sense considering that video codecs aim at lower bitrates than still image codecs. Basically video codecs have more coding tools to "hide artifacts" at low bitrates (e.g. strong smoothing filters), while JPEG XL has more coding tools to "preserve detail" at high bitrates (e.g. strong entropy coding, more subtle filters).
bob1029 4y ago
This is of intense interest to me - I had no idea you could do this with an existing jpeg. 20% would be a world-changing difference for an application I am working on right now, assuming the added encoding/decoding stages do not add substantial latency to the process. Is there some variant of libjpeg-turbo that works for XL?
- joshcryer 4y ago
  Unfortunately as far as I can find there is no optimized encoder or decoder for JXL yet. Everything uses the spec encoder, which works fine on modern hardware, but for an example on my 20 year old laptop it takes several seconds to decode an image. Encoding an image with "tortoise" mode takes 10+ minutes. One nice feature though is that JPEG->JPEG XL lossless encoding was a priority, and it's as easy as doing "cjxl my.jpg my.jxl". The result is a lossless encode with EXIF data kept for a full bit perfect JPEG if you do "djxl my.jxl my.jpg." It's also pretty fast even on my old laptop.
  - bob1029 4y ago
    > 10+ minutes Ouch. I'll stick to regular jpeg for now... I can crank out a 1080p encode in under 10 milliseconds using libjpeg-turbo on my target platform.
    - rndgermandude 4y ago
      The 10+ minutes that OP observed where in tortoise (=9) mode tho. That's the slowest mode, comparable to "placebo" mode in x264, and meant as a "test" mode, not as a daily driver. The libjxl default is "squirrel" (=7), and you can go as low as lightning (=1), so you have a choice to trade compression efficiency for compression speed. Additionally, there are different decoder modes (in the encoder), allowing you to make tradeoffs between efficiency/density vs speed. But yeah, libjxl will remain slower than libjpeg-turbo, especially on encodes.

LinAGKar 4y ago

I wonder how the compression ratio of JXL-ified JPEG compares to WEBP/AVIF/HEIC.

rndgermandude 4y ago
Comparing compression ratios is tricky. What you usually want is "file size at same visual quality" or "visual quality as same file size" for comparisons. The problem here is that "visual quality" is in the eye of the beholder, Different base images will have different results. There are some attempts at such comparisons, e.g. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... (cloudinary might be biased, as they are a major driver behind jpeg-xl) My overall impression is that it's roughly on par or a little behind with AVIF, somewhat ahead of HEIC and very ahead of WEBP (and jpeg of course) in quality-per-byte. As for encode and decode speed, it's a bit slower than WEBP but beats AVIF and HEIC by a margin (unless these codecs are back by hardware encoders). However, all three codecs are relatively new and there may be a lot of future speed optimizations possible. Especially jpeg-xl, which isn't "backed" by general AV1 (AVIF), vpx (WEBP) or HEVC (HEIC) research, may have a particularly large yet to be tapped potential for (hardware-specific) optimizations. As far as I know, jpeg-xl is also "simpler" than those other codecs (which basically used the iframes of their complex sibling video codecs as a base), so it might be more feasible to have more competing implementations. But time will tell, and it will of course also largely depend on the adoption and thus network effects of these formats who much "love" each format receives from open source and proprietary software vendors.
- jonsneyers 4y ago
  Generally speaking the results I've seen so far indicate that at low bitrates (e.g. below 0.5 bpp), the video codecs (AVIF, HEIC, VVC) perform best, while at medium to high bitrates, JPEG XL performs best. This makes sense considering that video codecs aim at lower bitrates than still image codecs. Basically video codecs have more coding tools to "hide artifacts" at low bitrates (e.g. strong smoothing filters), while JPEG XL has more coding tools to "preserve detail" at high bitrates (e.g. strong entropy coding, more subtle filters).

bob1029 4y ago

This is of intense interest to me - I had no idea you could do this with an existing jpeg. 20% would be a world-changing difference for an application I am working on right now, assuming the added encoding/decoding stages do not add substantial latency to the process. Is there some variant of libjpeg-turbo that works for XL?

joshcryer 4y ago
Unfortunately as far as I can find there is no optimized encoder or decoder for JXL yet. Everything uses the spec encoder, which works fine on modern hardware, but for an example on my 20 year old laptop it takes several seconds to decode an image. Encoding an image with "tortoise" mode takes 10+ minutes. One nice feature though is that JPEG->JPEG XL lossless encoding was a priority, and it's as easy as doing "cjxl my.jpg my.jxl". The result is a lossless encode with EXIF data kept for a full bit perfect JPEG if you do "djxl my.jxl my.jpg." It's also pretty fast even on my old laptop.
- bob1029 4y ago
  > 10+ minutes Ouch. I'll stick to regular jpeg for now... I can crank out a 1080p encode in under 10 milliseconds using libjpeg-turbo on my target platform.
  - rndgermandude 4y ago
    The 10+ minutes that OP observed where in tortoise (=9) mode tho. That's the slowest mode, comparable to "placebo" mode in x264, and meant as a "test" mode, not as a daily driver. The libjxl default is "squirrel" (=7), and you can go as low as lightning (=1), so you have a choice to trade compression efficiency for compression speed. Additionally, there are different decoder modes (in the encoder), allowing you to make tradeoffs between efficiency/density vs speed. But yeah, libjxl will remain slower than libjpeg-turbo, especially on encodes.