Hacker News new | past | comments | ask | show | jobs | submit login

Seems to have been partly based on this: https://storage.googleapis.com/avif-comparison/index.html



At the bottom there's a link to a lossless comparison, which shows JPEG XL outperforming WebP, AVIF, and PNG on size (no metrics on decode speed).


Yes, and lossless JPEG doesn't matter, especially on the web.


lossless matters for lots of images on the web (like logos and other images with text). lossless jpeg recompression is also really useful because it allows CDNs to save bandwidth by replacing jpeg with jpeg-xl.


> lossless matters for lots of images on the web (like logos and other images with text)

Couldn't some make the point that SVG can be a better format for things like that, especially logos? After all, raster graphics will always have drawbacks when compared to vector graphics for things like logos and other non-photographic content.


On lower-DPI displays, which remain very widespread outside of mobile, vector graphics usually look worse than pixel graphics.


Even with losses it's better than WebP.


and AVIF


Thanks for the link. That does look quite damning, seems that the already-supported AVIF format is overall the better choice based on these metrics.


I have a moderate sized selection of mostly B&W comics. JXL is the first format that out performs JPEG 2000 on them. It cleans AVIF's clock on them, in a rather unfair comparison of JXL's default settings vs hand tuned settings for AVIF with different settings for color and B&W comics.

It also far outperforms an optipng encoded PNG for lossless. I know either my corpus or my eyeball is different from the benchmarks used by AVIF but I do want to share this outlier.


Not sure about your comparison specifically, but in general the hard edges in comics should be an ideal case for AV1's spatial prediction. JPEG-XL eschewed that in favor of being inherently progressive; its splines promised to make up some of the difference but last I checked the encoder still doesn't use them.

Categorically, this is the main reason why even the main JPEG-XL dev agrees that AVIF is currently better with non-photo content [1]

[1] https://twitter.com/jonsneyers/status/1550161314961555457


I observe that it depends on which quality you aim to. At low quality AVIF does a good job with line drawings. I suspect much of it is because of the 8-color local palette mode. When you raise the quality/size a tiny bit (to need 9+ unique colors in an area), JPEG XL does an equal job with the edges, but starts getting all the subtleties, lonely faint dots, noisy or weak textures right, whereas it can be impossible to convince an AVIF encoder to store them at any quality setting.

Cartoon/anime collectors seem to be passionate about image quality and they may have observed the same as I have. At least I have learned a lot about image quality from anime fans during my image compression career.

Web devs don't care that much about quality, they are more looking into creating monetary savings in bandwidth and sometimes trying to lower the latencies. E-commerce is yet another thing, where the image quality may turn into revenue and becomes important again.


It's the stippling and hatching that most compression formats struggle with


Keep in mind that it's from the AVIF team though. :)


Actually, the results of the AVIF team's comparison do show the value of JPEG XL, if you look a bit further than the main page and dig into the actual plots. E.g. according to this plot, JXL is about 15% better than AVIF for 'web quality' images (around 1 bpp): https://storage.googleapis.com/avif-comparison/images/subset...

Here is a detailed analysis: https://cloudinary.com/blog/contemplating-codec-comparisons


There are lots of questions about that data for example why was the testing carried out in Chrome 92?

https://mobile.twitter.com/jonsneyers/status/159877483772342...


Try to replicate it.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: