5 ms·

Check it out with your own eyes with the most recent comparison site for WebP, AVIF and JPEG XL: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/

Check it out with your own eyes with the most recent comparison site for WebP, AVIF and JPEG XL: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#08-2011-panthera-tigris-tigris-texas-park-lanzarote-tp04&WEBP=m&JXL=m&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm... Most comparison links posted here are to older (almost a year old) versions that don't reflect the current state of encoding. Both JPEG XL and AVIF have improved tremendously.

hnbad 5y ago
The differences IMO are even more impressive at higher compression. WebP on "tiny" loses a lot of detail whereas JPEG XL retains most details while still losing overall image quality.
deleted 5y ago
[deleted]
lajamerr 5y ago
Why does JPEG XL affect the image quality even in lossless mode? I just compared the original tiger image to the lossless version for JPEG XL but there's some small changes that it makes.
- Aardwolf 5y ago
  I think this is a quirk in the tool, even if you choose Original on both sides there is some difference that looks like a scaling that's off by a few pixels
algorithm314 5y ago
For some images like https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#clovisfest*2:1&WEBP=m&JXL=m&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm... jpeg xl is really behind.
- ksec 5y ago
  JPEG XL isn't yet optimised for extremely low bpp. I thought the label for tiny, large and medium etc are sort of misleading without looking at bpp number. It is a bit like looking at bitrate for Video quality without looking at video resolution.
  - gardaani 5y ago
    When is JPEG XL ready for use? Wikipedia [1] says that Part 4 will be released in 2022? [1] https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
    - jonsneyers 5y ago
      Part 1 and 2 define the codestream and file format, respectively. They are both finalized at the technical level (the ISO process is still ongoing, but there is no more opportunity for technical changes, the JPEG committee has approved the final draft). So it is ready for use now: the bitstream has been frozen since January, free and open source reference software is available. Part 3 will describe conformance testing (how to verify that an alternative decoder implementation is in fact correct), and part 4 will just be just a snapshot of the reference software that gets archived by ISO, but for all practical purposes you should just get the most recent git version. Parts 3 and 4 are not at all needed to start using JPEG XL.
      - wingman-jr 5y ago
        I've been watching developments here since FLIF days and I wanted to say thank for you for taking the serious time, effort, and tireless communication to see things through the standards processes. That takes perseverance!
        jonsneyers 5y ago
        Thanks! Yes, it is a long and tricky process (and the hardest part is right now: adoption!).
twotwotwo 5y ago
Some notable features of JPEG XL that don't show up in side-by-sides: 1) Progressive decoding. Like the original .jpg, .jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. This can give JPEG XL the edge in perceived load speed even when the full .avif is smaller than the full .jxl. (Old demo from a JXL contributor at https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U ) 2) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss; the original .jpg file can be recovered bit-for-bit. 4) Lossless mode. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. AVIF has a lossless mode too, but JPEG XL seems ahead here. (I know the parent comment is from a JXL contributor, I'm saying this for other folks.) I think those will give JPEG XL a niche on the Web. Meanwhile I suspect e.g. Android phone cameras will save .avif someday, like iPhones save .heic now. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up--at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images). Finally, worth noting the codecs are different due to a bunch of rational choices by their devs. AVIF is the format for AV1 video keyframes. Progressive decoding doesn't help there, and doesn't jibe well with spatial prediction, which helps AV1 and other video codecs preserve sharp lines. And video codecs need hardware support to thrive anyway, so optimizing for fast software encoding probably wasn't an early priority. Otherwise the new formats have a lot of overlap in fundamentals--variable size and shape DCTs, better entropy encoding, chroma-from-luma, anti-ringing postfilters, etc. Glad to see support for both getting more widespread.
- unlord 5y ago
  Note that AVIF is not just AV1 video keyframes. The entire compliment of AV1 video coding tools (including inter prediction with motion vectors) are available. This includes spatial and temporal scaling. Note this means that animated images on the web (like GIF) are significantly smaller with AVIF than JPEG-XL which has no inter prediction.

hnbad 5y ago

The differences IMO are even more impressive at higher compression. WebP on "tiny" loses a lot of detail whereas JPEG XL retains most details while still losing overall image quality.

deleted 5y ago

[deleted]

lajamerr 5y ago

Why does JPEG XL affect the image quality even in lossless mode? I just compared the original tiger image to the lossless version for JPEG XL but there's some small changes that it makes.

Aardwolf 5y ago
I think this is a quirk in the tool, even if you choose Original on both sides there is some difference that looks like a scaling that's off by a few pixels

algorithm314 5y ago

For some images like https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_06_08/index.html#clovisfest*2:1&WEBP=m&JXL=m&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm... jpeg xl is really behind.

ksec 5y ago
JPEG XL isn't yet optimised for extremely low bpp. I thought the label for tiny, large and medium etc are sort of misleading without looking at bpp number. It is a bit like looking at bitrate for Video quality without looking at video resolution.
- gardaani 5y ago
  When is JPEG XL ready for use? Wikipedia [1] says that Part 4 will be released in 2022? [1] https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
  - jonsneyers 5y ago
    Part 1 and 2 define the codestream and file format, respectively. They are both finalized at the technical level (the ISO process is still ongoing, but there is no more opportunity for technical changes, the JPEG committee has approved the final draft). So it is ready for use now: the bitstream has been frozen since January, free and open source reference software is available. Part 3 will describe conformance testing (how to verify that an alternative decoder implementation is in fact correct), and part 4 will just be just a snapshot of the reference software that gets archived by ISO, but for all practical purposes you should just get the most recent git version. Parts 3 and 4 are not at all needed to start using JPEG XL.
    - wingman-jr 5y ago
      I've been watching developments here since FLIF days and I wanted to say thank for you for taking the serious time, effort, and tireless communication to see things through the standards processes. That takes perseverance!
      - jonsneyers 5y ago
        Thanks! Yes, it is a long and tricky process (and the hardest part is right now: adoption!).

twotwotwo 5y ago

Some notable features of JPEG XL that don't show up in side-by-sides: 1) Progressive decoding. Like the original .jpg, .jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. This can give JPEG XL the edge in perceived load speed even when the full .avif is smaller than the full .jxl. (Old demo from a JXL contributor at https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U ) 2) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss; the original .jpg file can be recovered bit-for-bit. 4) Lossless mode. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. AVIF has a lossless mode too, but JPEG XL seems ahead here. (I know the parent comment is from a JXL contributor, I'm saying this for other folks.) I think those will give JPEG XL a niche on the Web. Meanwhile I suspect e.g. Android phone cameras will save .avif someday, like iPhones save .heic now. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up--at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images). Finally, worth noting the codecs are different due to a bunch of rational choices by their devs. AVIF is the format for AV1 video keyframes. Progressive decoding doesn't help there, and doesn't jibe well with spatial prediction, which helps AV1 and other video codecs preserve sharp lines. And video codecs need hardware support to thrive anyway, so optimizing for fast software encoding probably wasn't an early priority. Otherwise the new formats have a lot of overlap in fundamentals--variable size and shape DCTs, better entropy encoding, chroma-from-luma, anti-ringing postfilters, etc. Glad to see support for both getting more widespread.

unlord 5y ago
Note that AVIF is not just AV1 video keyframes. The entire compliment of AV1 video coding tools (including inter prediction with motion vectors) are available. This includes spatial and temporal scaling. Note this means that animated images on the web (like GIF) are significantly smaller with AVIF than JPEG-XL which has no inter prediction.