There is just no need for a PNG update, just adopt JPEG XL.
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.
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.
JPEG XL has an edge-preserving filter ("EPF") for the purpose of reducing ringing.
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 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
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
Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption.
It is only a matter of time until the Chrome team has to reverse their decision.
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.
Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.
Original JPEG -> JPEG XL -> Recreated JPEG.
Sha256(Original JPEG) == Sha256(Recreated JPEG).
That's what people meant by "backward compatible".
So backwards-compatible in the sense that the jpeg-xl algorithm spec can read jpg and store the same pixel data more efficiently as jxl if you like. You gain space and lose nothing (except perhaps encode/decode speed).
Is that gained space enough to account for the fact you now have 2 files? Sure, you can delete the original jpg on the local system, but are you going to purge your entire set of backups?
Unless serving jxl and saving bandwidth, while increasing your total storage, is worth it to you.
Also backup storage is usually cheaper than something that needs to have fast access speeds.
You'll know JPEG-XL if real when camera manufactures allow for XL acquisition instead of legacy JPEG only.
But they can recover them from the JXL files, so are they really “tossed out”? It’s not really different than any other form of lossless compression.