5 ms·

jpeg xl is fantastic, yet autocratic google wants to force inferior format

by kiicia 1y ago

homebrewer 1y ago
Mozilla also isn't interested in supporting it, it's not just Google. I also often see these articles that tout jpeg-xl's technical advantages, but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. It not only produces fewer artifacts on medium-to-heavily compressed images, but they're also less annoying: minor detail loss and smoothing compared to jpeg-xl's blocking and ringing (in addition to detail loss; basically the same types of artifacts as with the old jpeg). Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.
- deleted 1y ago
  [deleted]
- Retric 1y ago
  JPEG-XL is optimized for the low to zero levels of compression which isn’t as commonly used on the web, but definitely fills a need. Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.
  - formerly_proven 1y ago
    JPEG XL seems optimally suited for media and archival purposes and of course this is something you’d want to mostly do through webapps nowadays. Even relatively basic uses cases like Wiki Commons is basically stuck on JPEG for these purposes. For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.
- OneDeuxTriSeiGo 1y ago
  > Mozilla also isn't interested in supporting it Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready. https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064
  - masklinn 1y ago
    You have a really strange interpretation of the word “consider”.
    - mistercow 1y ago
      Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
      - masklinn 1y ago
        Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
        OneDeuxTriSeiGo 1y ago
        From the link > To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it. That is a perfectly clear position.
        deskamess 1y ago
        How far away is JPEG-XL rust version from Google if Chrome is not interested in it?
- demetris 1y ago
  I did some reading recently, for a benchmark I was setting up, to try and understand what the situation is. It seems things have started changing in the last year or so. Some links from my notes: https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust https://news.ycombinator.com/item?id=41443336 https://news.ycombinator.com/item?id=41443336 (discussion of the same GitHub comment as in the Phoronix site) https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (land initial jpegxl rust code pref disabled) In case anyone is curious, here is the benchmark I did my reading for: https://op111.net/posts/2025/10/png-and-modern-formats-lossless-image-compression/ https://op111.net/posts/2025/10/png-and-modern-formats-lossl...
  - idoubtit 1y ago
    No, the situation about image compression has not changed. The Grand Poster you were replying to was writing about typical web usage, that is "medium-to-heavily compressed images", while your benchmark is about lossless compression. BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
    - demetris 1y ago
      No. demetris’ benchmark of lossless image compression is not a sign that the situation may be changing. :-D That was just the context for some reading I did to understand where we are now. > BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 That is one of the links I shared in my comment (along with the bug title in parenthesis). :-)
- gcr 1y ago
  I've had exactly the opposite outcome with AVIF vs JPEG-XL. I've found that jxl outperforms AVIF quite dramatically at low bitrates.
  - miladyincontrol 1y ago
    Same in my experience testing and deploying a few sites that support both. In general the only time AVIF outperformed in file size for me was with laughably low quality settings beyond what any typical user or platform would choose. And for larger files especially the benefits of actually having progressive decoding, pushed me even more in favour of jpeg-xl. Doubly so when you can just provide variations in image size by halting the bit flow arbitrarily.
- ksec 1y ago
  >but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. What is that in terms of bpp? Because according to Google Chrome 80-85% of we deliver images with bpp of 1.0 or above. I don't think most people realise that. And in most if not all circumstances, jpeg XL performs better than AVIF at bpp 1.0 and above tested by professionals.
AlienRobot 1y ago
I wish they separated the lossless codec into "WebPNG." WebP is better than PNG, but it's too risky to use (and tell people to use) a lossless format that is lossy if you forget to use a setting.

jpeg xl is fantastic, yet autocratic google wants to force inferior format

by kiicia 1y ago

jpeg xl is fantastic, yet autocratic google wants to force inferior format

Mozilla also isn't interested in supporting it, it's not just Google. I also often see these articles that tout jpeg-xl's technical advantages, but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. It not only produces fewer artifacts on medium-to-heavily compressed images, but they're also less annoying: minor detail loss and smoothing compared to jpeg-xl's blocking and ringing (in addition to detail loss; basically the same types of artifacts as with the old jpeg). Maybe there's a reason they're not bothering with supporting xl besides misplaced priorities or laziness.

deleted 1y ago
[deleted]
Retric 1y ago
JPEG-XL is optimized for the low to zero levels of compression which isn’t as commonly used on the web, but definitely fills a need. Google citied insufficient improvements which is a rather ambiguous statement. Mozilla seems more concerned with the attack surface.
- formerly_proven 1y ago
  JPEG XL seems optimally suited for media and archival purposes and of course this is something you’d want to mostly do through webapps nowadays. Even relatively basic uses cases like Wiki Commons is basically stuck on JPEG for these purposes. For the same reason it would be good if a future revision of PDF/A would include JPEG XL, since it doesn't really have any decent codecs for low-loss (but not losless) compression (e.g. JPEG sucks at color schematics/drawings and losless is impractically big for them). It did get JP2 but support for that is quite uncommon.
OneDeuxTriSeiGo 1y ago
> Mozilla also isn't interested in supporting it Mozilla is more than willing to adopt it. They just won't adopt the C++ implementation. They've already put into writing that they're considering adopting it when the rust implementation is production ready. https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064
- masklinn 1y ago
  You have a really strange interpretation of the word “consider”.
  - mistercow 1y ago
    Seems like the normal usage to me. The post above lists other criteria that have to be satisfied, beyond just being a Rust implementation. That would be the consideration.
    - masklinn 1y ago
      Mozilla indicates that they are willing to consider it given various prerequisite. GP translates that to being “more than willing to adopt it”. That is very much not a normal interpretation.
      - OneDeuxTriSeiGo 1y ago
        From the link > To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox. If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it. That is a perfectly clear position.
        deskamess 1y ago
        How far away is JPEG-XL rust version from Google if Chrome is not interested in it?
demetris 1y ago
I did some reading recently, for a benchmark I was setting up, to try and understand what the situation is. It seems things have started changing in the last year or so. Some links from my notes: https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust https://news.ycombinator.com/item?id=41443336 https://news.ycombinator.com/item?id=41443336 (discussion of the same GitHub comment as in the Phoronix site) https://github.com/tirr-c/jxl-oxide https://github.com/tirr-c/jxl-oxide https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (land initial jpegxl rust code pref disabled) In case anyone is curious, here is the benchmark I did my reading for: https://op111.net/posts/2025/10/png-and-modern-formats-lossless-image-compression/ https://op111.net/posts/2025/10/png-and-modern-formats-lossl...
- idoubtit 1y ago
  No, the situation about image compression has not changed. The Grand Poster you were replying to was writing about typical web usage, that is "medium-to-heavily compressed images", while your benchmark is about lossless compression. BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
  - demetris 1y ago
    No. demetris’ benchmark of lossless image compression is not a sign that the situation may be changing. :-D That was just the context for some reading I did to understand where we are now. > BTW, I don't see how Mozilla's interest in a jpegxl _decoder_ (your first link) has anything to do with the performance of jpegxl encoders compared to avif's encoders. In case you're really interested in the former, Firefox now has more than intentions, but it's still not at production level: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 That is one of the links I shared in my comment (along with the bug title in parenthesis). :-)
gcr 1y ago
I've had exactly the opposite outcome with AVIF vs JPEG-XL. I've found that jxl outperforms AVIF quite dramatically at low bitrates.
- miladyincontrol 1y ago
  Same in my experience testing and deploying a few sites that support both. In general the only time AVIF outperformed in file size for me was with laughably low quality settings beyond what any typical user or platform would choose. And for larger files especially the benefits of actually having progressive decoding, pushed me even more in favour of jpeg-xl. Doubly so when you can just provide variations in image size by halting the bit flow arbitrarily.
ksec 1y ago
>but in my subjective testing with image sizes you would typically see on the web, avif wins every single time. What is that in terms of bpp? Because according to Google Chrome 80-85% of we deliver images with bpp of 1.0 or above. I don't think most people realise that. And in most if not all circumstances, jpeg XL performs better than AVIF at bpp 1.0 and above tested by professionals.

AlienRobot 1y ago

I wish they separated the lossless codec into "WebPNG." WebP is better than PNG, but it's too risky to use (and tell people to use) a lossless format that is lossy if you forget to use a setting.