12 ms·

Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy

Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc. There is just no need for a PNG update, just adopt JPEG XL.

Aachen 1y ago
> advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example
- Retr0id 1y ago
  zlib/deflate already has the same issue. It is mitigated somewhat by PNG row filters.
- adgjlsfhk1 1y ago
  the FSE layer isn't responsible for finding these sorts of patterns in an image codec. The domain modeling turns that sort of pattern into repeated data and then the FSE goes to town on the output.
- wongarsu 1y ago
  PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd
  - Aachen 1y ago
    > You can get decent improvements by just switching deflate for zstd Maybe I sounded too critical of zstd. To be clear: I use it for general-purpose compression where available, the only exception would be where eeking out the last % gain is important and slow decompression is acceptable and it has one of these patterns that Bzip2 does better in the first place That it's better than deflate (afaik aka gzip and zlib, just with different header fields) is not surprising since that was iirc the defined goal of Zstandard project
- spider-mario 1y ago
  JPEG XL is not “apply zstd to the pixel data”. What the parent comment meant is that JPEG XL, like zstd, happens to use ANS among its set of techniques. It handles gradients just fine.
illiac786 1y ago
I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?
- pmarreck 1y ago
  JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point. It also has pretty much every feature desired in an image standard. It is future-proofed. You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. It is a worthy successor (while also being vastly superior to) JPEG.
  - illiac786 1y ago
    I was referring to the new PNG, not to JPEG XL.
    - sdenton4 1y ago
      Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.
      - illiac786 1y ago
        Not sure expanding PNG capabilities is sensible, looking at the overall landscape of image formats.
        dveditz_ 1y ago
        The capabilities are already expanded in most common implementations. This update is largely blessing those features as officially "standard".
  - BobaFloutist 1y ago
bmn__ 1y ago
> just https://caniuse.com/jpegxl https://caniuse.com/jpegxl No one can afford to "just". Five years later and it's only one browser! Crazy. Browser vendors must deliver, only then it's okay to admonish an end user or Web developer to adopt the format.
- Dylan16807 1y ago
  Adopt it anyway. Add a decoder. Don't let google bully you out of such a good format.
mikae1 1y ago
> There is just no need for a PNG update, just adopt JPEG XL. Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption. [1] https://issues.chromium.org/issues/40168998#comment85 https://issues.chromium.org/issues/40168998#comment85
- rhet0rica 1y ago
  From reading that, "gave up" seems to mean "deliberately killed it so their own WebP2 wouldn't have competition." Behold the monopoly at the apex of its power.
  - account42 1y ago
    The really weird part is that both webp and jxl developments were largely funded by Google so its not Google killing a competitors format over their own but someone in one part of Google killing the format someone elsewhere in Google developed over their pet favorite.
    - rhet0rica 1y ago
      There's no form of cloak-and-dagger BS more vicious than internecine BS.
  - spauldo 1y ago
    PNG went through that when Microsoft kept throwing incomplete and buggy support for it in IE. Hopefully something will come along to buck Chrome's monopoly and JPEG-XL will have its chance.
- pezezin 1y ago
  On the other hand, more and more software are adding support for JPEG XL. Photoshop just added it in the latest patch (https://helpx.adobe.com/photoshop/using/whats-new/2025-6.html#file-format-support https://helpx.adobe.com/photoshop/using/whats-new/2025-6.htm...), Apple has included it in the iPhone 16, it is easily available on Windows (https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=US https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=U...), most major Linux distros already support it... It is only a matter of time until the Chrome team has to reverse their decision.
Dwedit 1y ago
If JPEG-XL decompressed faster, I'd use it more. For now, I'm sticking with WEBP for lossless, and AVIF for lossy. AVIF's CDEF filter (directional deringing) works wonders, and it's too bad that JPEG-XL lacks such a filter. JPEG-XL's lossy modular mode is a very unique feature which needs a lot more exposure than it has. It is well-suited to non-photographic drawings or images that aren't continuous, and have never touched any JPEG-like codecs. It has different kinds of artifacts than what you typically see in a DCT image codec. Rather than ringing, you get slight pixellation.
- stgn 1y ago
  > and it's too bad that JPEG-XL lacks such a filter JPEG XL has an edge-preserving filter ("EPF") for the purpose of reducing ringing.

Aachen 1y ago

> advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example

Retr0id 1y ago
zlib/deflate already has the same issue. It is mitigated somewhat by PNG row filters.
adgjlsfhk1 1y ago
the FSE layer isn't responsible for finding these sorts of patterns in an image codec. The domain modeling turns that sort of pattern into repeated data and then the FSE goes to town on the output.
wongarsu 1y ago
PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd
- Aachen 1y ago
  > You can get decent improvements by just switching deflate for zstd Maybe I sounded too critical of zstd. To be clear: I use it for general-purpose compression where available, the only exception would be where eeking out the last % gain is important and slow decompression is acceptable and it has one of these patterns that Bzip2 does better in the first place That it's better than deflate (afaik aka gzip and zlib, just with different header fields) is not surprising since that was iirc the defined goal of Zstandard project
spider-mario 1y ago
JPEG XL is not “apply zstd to the pixel data”. What the parent comment meant is that JPEG XL, like zstd, happens to use ANS among its set of techniques. It handles gradients just fine.

illiac786 1y ago

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

pmarreck 1y ago
JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point. It also has pretty much every feature desired in an image standard. It is future-proofed. You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. It is a worthy successor (while also being vastly superior to) JPEG.
- illiac786 1y ago
  I was referring to the new PNG, not to JPEG XL.
  - sdenton4 1y ago
    Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.
    - illiac786 1y ago
      Not sure expanding PNG capabilities is sensible, looking at the overall landscape of image formats.
      - dveditz_ 1y ago
        The capabilities are already expanded in most common implementations. This update is largely blessing those features as officially "standard".
- BobaFloutist 1y ago

bmn__ 1y ago

> just https://caniuse.com/jpegxl https://caniuse.com/jpegxl No one can afford to "just". Five years later and it's only one browser! Crazy. Browser vendors must deliver, only then it's okay to admonish an end user or Web developer to adopt the format.

Dylan16807 1y ago
Adopt it anyway. Add a decoder. Don't let google bully you out of such a good format.

mikae1 1y ago

> There is just no need for a PNG update, just adopt JPEG XL. Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption. [1] https://issues.chromium.org/issues/40168998#comment85 https://issues.chromium.org/issues/40168998#comment85

rhet0rica 1y ago
From reading that, "gave up" seems to mean "deliberately killed it so their own WebP2 wouldn't have competition." Behold the monopoly at the apex of its power.
- account42 1y ago
  The really weird part is that both webp and jxl developments were largely funded by Google so its not Google killing a competitors format over their own but someone in one part of Google killing the format someone elsewhere in Google developed over their pet favorite.
  - rhet0rica 1y ago
    There's no form of cloak-and-dagger BS more vicious than internecine BS.
- spauldo 1y ago
  PNG went through that when Microsoft kept throwing incomplete and buggy support for it in IE. Hopefully something will come along to buck Chrome's monopoly and JPEG-XL will have its chance.
pezezin 1y ago
On the other hand, more and more software are adding support for JPEG XL. Photoshop just added it in the latest patch (https://helpx.adobe.com/photoshop/using/whats-new/2025-6.html#file-format-support https://helpx.adobe.com/photoshop/using/whats-new/2025-6.htm...), Apple has included it in the iPhone 16, it is easily available on Windows (https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=US https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=U...), most major Linux distros already support it... It is only a matter of time until the Chrome team has to reverse their decision.

Dwedit 1y ago

If JPEG-XL decompressed faster, I'd use it more. For now, I'm sticking with WEBP for lossless, and AVIF for lossy. AVIF's CDEF filter (directional deringing) works wonders, and it's too bad that JPEG-XL lacks such a filter. JPEG-XL's lossy modular mode is a very unique feature which needs a lot more exposure than it has. It is well-suited to non-photographic drawings or images that aren't continuous, and have never touched any JPEG-like codecs. It has different kinds of artifacts than what you typically see in a DCT image codec. Rather than ringing, you get slight pixellation.

stgn 1y ago
> and it's too bad that JPEG-XL lacks such a filter JPEG XL has an edge-preserving filter ("EPF") for the purpose of reducing ringing.