6 ms·

The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL,

by Macha 22d ago

The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF. Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.

Sammi 22d ago
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images. I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding. Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
- Implicated 22d ago
  > JpegXL will be the best of all worlds choice in a few years when software support is good. Where is the software support lacking other than the browsers at this point?
  - _bent 22d ago
    The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
  - HappMacDonald 22d ago
    File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
    - spider-mario 22d ago
      macOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...
  - socalgal2 22d ago
    I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
    - Sammi 22d ago
      This is probably going to be the longest tail of them all. I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
      - flyingjoe 22d ago
        Aren't they translating to JPG on upload automatically anyways?
        Sammi 21d ago
        That must be happening, because I haven't gotten any complaints and I know we have many users on ios.
radicality 22d ago
It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl
Dwedit 22d ago
Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.
trompetenaccoun 22d ago
There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif. There's a good visual comparison here: https://www.youtube.com/watch?v=SzsM4HMKmEI https://www.youtube.com/watch?v=SzsM4HMKmEI
- bityard 22d ago
  JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
  - spider-mario 22d ago
    Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_martians https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
  - kekdkrjfjjwfj 21d ago
    > According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably. Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.

by Macha 22d ago

Sammi 22d ago

Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images. I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding. Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.

Implicated 22d ago
> JpegXL will be the best of all worlds choice in a few years when software support is good. Where is the software support lacking other than the browsers at this point?
- _bent 22d ago
  The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
- HappMacDonald 22d ago
  File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
  - spider-mario 22d ago
    macOS and Windows’ respective file explorers and built-in image viewers both support it, as do Photoshop, GIMP, Krita and a few more. https://en.wikipedia.org/wiki/JPEG_XL#Official_software_support https://en.wikipedia.org/wiki/JPEG_XL#Official_software_supp...
- socalgal2 22d ago
  I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
  - Sammi 22d ago
    This is probably going to be the longest tail of them all. I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
    - flyingjoe 22d ago
      Aren't they translating to JPG on upload automatically anyways?
      - Sammi 21d ago
        That must be happening, because I haven't gotten any complaints and I know we have many users on ios.

radicality 22d ago

It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl

Dwedit 22d ago

Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.

trompetenaccoun 22d ago

There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif. There's a good visual comparison here: https://www.youtube.com/watch?v=SzsM4HMKmEI https://www.youtube.com/watch?v=SzsM4HMKmEI

bityard 22d ago
JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
- spider-mario 22d ago
  Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_martians https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
- kekdkrjfjjwfj 21d ago
  > According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place. Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably. Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.