[muragekibicho]

I worked alongside the Google and Cloudinary teams who authored the JPEG XL spec and I'm glad their work's finally paying off.

It's really weird Google deprecated the format despite contributing engineers to help build JPEG XL. I guess it's office politics

[archerx]

They want their awful webp format to win for some reason.

[handsclean]

Honest question: what’s so awful about WEBP? Though it’s worse than the gen arriving now, it’s better than or the same as the one before it for the use cases it supports, and free and open. I get the impression people associate it with brokenness and low quality, but the brokenness is just a lack of support, and the quality a creator choice. Maybe its original sin was not trying to be suitable for original data, leading to the low quality association and making support less desirable outside of the web, but if that’s the case then AVIF is in the same boat.

[lonjil]

Lossy WebP has some crappy limitations. For example, it's limited to 4:2:0 chroma subsampling, which makes it unsuitable for high quality images. Hell, even if you restrict yourself to 420 JPEG, JPEG still comes out as having a higher quality ceiling than WebP. And yes, it does beat MozJPEG and libjpeg-turbo in file size sometimes, but newer JPEG encoders like jpegli crush WebP in size completely across the entire quality spectrum.

[archerx]

I associate it with google, and I have associated google with bad and untrustworthy. Also google's hostility towards jpeg xl makes me even more apprehensive of their format and the way they tried to push it so hard.

Also jpeg XL is just much better than webp.

https://www.youtube.com/watch?v=qc2DvJpXh-A

[JyrkiAlakuijala]

Google is not hostile to JPEG XL.

Google Research develops and maintains JPEG XL, currently main focus on improving streaming encoding -- to use much less memory during the encoding process.

Google Chrome added and then removed experimental support of JPEG XL from Chrome. This has caused discussion in the related bugs.

https://bugs.chromium.org/p/chromium/issues/detail?id=145180... https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

[ksec]

It is not really awful. It is just way over hyped, over promised and under delivered. WebP was better than standard JPEG. But JPEG also improved via many other encoders such as MozJPEG. And it wasn't obvious what the advantage were, or it was so little it really shouldn't be included as a standard feature. Mozilla made their case back then with many testing and data point.

[spider-mario]

> WebP was better than standard JPEG.

Feature-wise, maybe (transparency, animation). Compression-wise, not really (better at low qualities because the artifacts are somewhat less objectionable than JPEG’s, but worse at high qualities).

Lossless WebP (practically a separate codec) is nice though, albeit 8-bit only.

[izacus]

Transparency was a massive advantage to the point it became default compressed format for e.g. Android apps.

[Varriount]

From a technical perspective, what are the differences between the two?

[lifthrasiir]

The original lossy WebP format is more or less an intra-coded frame format from VP8. This "I-frame-as-image" approach was considered good enough for some time, for example AVIF largely follows the same structure.

The WebP lossless format (internally "VP8L") is the second codec supported by libwebp but otherwise independent. This format can be thought as an optimized PNG; it uses the main PNG algorithm but then tweaks various bits for better compression. For this reason it is very rare to see PNG files smaller than losslessly compressed WebP files when efficiently done.

JPEG XL is very different from both. There are some technical resemblances, as the author of lossless WebP also worked on JPEG XL (and Brotli), but the overall architecture is completely revamped. The lossy portion of JPEG XL is a (much larger) superset of JPEG 1, while the lossless portion is based on a learnable context modelling respresented as a binary decision tree. And then everything got sandwiched between yet another set of components.

[JyrkiAlakuijala]

It would be more correct to say that PNG uses the GIF algorithm than that WebP uses the PNG algorithm.

WebP's select predictor and some other predictors are used in JPEG XL. The same for 2d locality map in backward references.

Both are able to use delta palettes. JPEG XL goes further by having a mixed mode where some entries are deltas for smooth gradients while others are usual palette entries.

[adgjlsfhk1]

the main difference is webp is a last gen video format (vp9) adapted to support images, while jpeg-xl is an image format first. This may not sound important, but actually matters a lot because videos and images are viewed very differently and therefore have different constraints to optimize for.

1. A frame of video only is viewed for 1/30th to 1/60th of a second. Quality standards are lower than for an image which will often be looked at for several seconds. One example tradeof is webp always has chroma sub-sampling which is a fairly major quality tradeoff.

2. image sizes vary a lot more. Images sizes range from 32x32 pixels to enormous. Videos are pretty much always between 360p and 4k (webp supports 16k by 16k vs 1 billion by 1 billion for jpeg-xl)

3. videos don't care about progressive loading, but it makes sense for images (especially for users with slow connections)

4. video formats care about encode time because a videos are massive. Image formats are fine with 100x slower encode if it makes the file smaller and decode is faster 3.

[lonjil]

I think you mean AVIF.