5 ms·

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer

by Pxtl 11mo ago

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.

F3nd0 11mo ago
If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that. The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.
- Dwedit 11mo ago
  Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.
  - lonjil 11mo ago
    Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.
  - F3nd0 11mo ago
    In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'. You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.
    - Dwedit 11mo ago
      FLIF got integrated in to JPEG-XL as the modular mode.
      - F3nd0 11mo ago
        If I recall correctly, that's FUIF, originally created by the same author as FLIF's successor of sorts.
      - JyrkiAlakuijala 10mo ago
        Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding time. Also JPEG XL forces tiled coding, making multi-threaded decoding a possibility.
  - JyrkiAlakuijala 10mo ago
    When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with ZopfliPNG ideas, those were backports from some WebP lossless ideas into gzip and PNG.
- halapro 11mo ago
  You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.
  - F3nd0 11mo ago
    Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable. [1] https://pngquant.org/ https://pngquant.org/
tempest_ 11mo ago
20% is massive for those storing those social media images though.
- Pxtl 11mo ago
  I get that there are people who are super excited by this for very good reasons, but for those of us downstream this is just going to be a hassle.
7jjjjjjj 11mo ago
I think there's a difference here. If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version. JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.
- Pxtl 11mo ago
  Let's be realistic - when most users are upset they got a .webp, they're not annoyed because of quality-loss, they're annoyed because they can't immediately use it in many other services & software.
  - _jzlw 11mo ago
    This is still a problem with AVIF, too. Image viewers that support the format often don't support animated AVIFs, and even GitHub still for some godforsaken reason treats .avif files in a repo/PR as binary files instead of images. I think Discord just recently started supporting AVIFs, so that's progress.
spider-mario 11mo ago
Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.
- Pxtl 11mo ago
  AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go. Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels. With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
  - spaceducks 11mo ago
    I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)
  - spider-mario 11mo ago
    Well, sure, but wasn’t that the use case we were discussing?
    - Pxtl 11mo ago
      Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case. Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun. So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.
BeFlatXIII 11mo ago
> For example, ask a normal social media user how they feel about .webp and expect to get an earful. I've seen enough software that gets petulant about not supporting webp to fight the Google monopoly or whatever to understand their frustration.
OneDeuxTriSeiGo 11mo ago
That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality. i.e. you can also serve downscaled & thumbnail versions directly from the original image.

by Pxtl 11mo ago

F3nd0 11mo ago

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that. The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.

Dwedit 11mo ago
Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.
- lonjil 11mo ago
  Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.
- F3nd0 11mo ago
  In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'. You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.
  - Dwedit 11mo ago
    FLIF got integrated in to JPEG-XL as the modular mode.
    - F3nd0 11mo ago
      If I recall correctly, that's FUIF, originally created by the same author as FLIF's successor of sorts.
    - JyrkiAlakuijala 10mo ago
      Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding time. Also JPEG XL forces tiled coding, making multi-threaded decoding a possibility.
- JyrkiAlakuijala 10mo ago
  When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with ZopfliPNG ideas, those were backports from some WebP lossless ideas into gzip and PNG.
halapro 11mo ago
You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.
- F3nd0 11mo ago
  Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable. [1] https://pngquant.org/ https://pngquant.org/

tempest_ 11mo ago

20% is massive for those storing those social media images though.

Pxtl 11mo ago
I get that there are people who are super excited by this for very good reasons, but for those of us downstream this is just going to be a hassle.

7jjjjjjj 11mo ago

I think there's a difference here. If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version. JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.

Pxtl 11mo ago
Let's be realistic - when most users are upset they got a .webp, they're not annoyed because of quality-loss, they're annoyed because they can't immediately use it in many other services & software.
- _jzlw 11mo ago
  This is still a problem with AVIF, too. Image viewers that support the format often don't support animated AVIFs, and even GitHub still for some godforsaken reason treats .avif files in a repo/PR as binary files instead of images. I think Discord just recently started supporting AVIFs, so that's progress.

spider-mario 11mo ago

Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.

Pxtl 11mo ago
AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go. Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels. With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
- spaceducks 11mo ago
  I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)
- spider-mario 11mo ago
  Well, sure, but wasn’t that the use case we were discussing?
  - Pxtl 11mo ago
    Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case. Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun. So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.

BeFlatXIII 11mo ago

> For example, ask a normal social media user how they feel about .webp and expect to get an earful. I've seen enough software that gets petulant about not supporting webp to fight the Google monopoly or whatever to understand their frustration.

OneDeuxTriSeiGo 11mo ago

That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality. i.e. you can also serve downscaled & thumbnail versions directly from the original image.