Comment by computerbuster
24 days ago
I expected one of these bad-faith readings, so I can address that Aperture is mentioned once and Iris-WebP is only shown in numbers, because I have access to these encoders and thus they cannot be ignored. The only encoders I heavily advertise here are the incredible open-source AV1 encoders, that I contributed to for free and I think people should use. Also, not sure where you infer that point about WebP; libwebp is a fine encoder.
AVIF does not have artifacts from tiling any more than JPEG XL has artifacts from being JPEG XL; if you read the details post at the bottom, you'd see there's a 0.5-1.0% BD-rate regression with tiles, which is effectively a rounding error.
For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time. You need to watch what I'm showing you instead of adopting the most bad-faith reading because some things are mentioned.
> For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time.
I'm not sure I agree? IMO after about 30% most images look better on JXL than on AVIF, the exceptions being the pigeon, which looks better on JXL after 43% (still less than half) and the sunflower, which looks better on 66% (but you can clearly see what's on the image a lot earlier). Also, blurry convey better the idea of loading and the AVIF version may have some weird artifacts / look weirder (although that's subjective), for example the Quechua woman's eyes are very distorted on the progressive AVIF and, on the Poke bowl, some of the seeds on top of one of the top radish pieces are kind of missing / look like a shadow (while other seeds of the same size appear). In contrast the JXL version is usually blurrier and less saturated at the beginning but is more "uniform/reliable" (distorts all of the "objects" more or less the same), and later it looks finished but actually isn't (which may be a problem on its own).
Worth mentioning: their demo only uses two passes for progressive AVIF -- it's just their choice. You can have up to two more intermediate passes, so at 30% you can have something much closer to the original image.
Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
> their demo only uses two passes for progressive AVIF -- it's just their choice
Also worth mentioning: AFAIK "their choice" here is just the default, i.e. what `avifenc --progressive` outputs, so maybe if the default is suboptimal, it could be improved?
> Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
Usable for what? As a clearly loading image / placeholder, I personally like the JXL version better (as already indicated in my previous comment). As a final image I think both of them are unusable, and if that's the intention I think it would be better to encode both aiming for very low quality, maybe also reducing the resolution, without progressive loading, then compare. My understanding is that AVIF is usually better at very low bitrates, so it would probably be better, but I don't think this example "proves" that.
4 replies →
>Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
I was taught to be skeptical of objective benchmarks; Why should we trust them when people are benchmaxxing?
https://habr.com/en/articles/700726/
3 replies →
Surprised and disappointed to hear "bad-faith reading".
I have seen AVIF tiling artifacts myself. Hand-waving them away by appealing to a metric that averages across all image pixels is not convincing.
Let's be productive:
https://pengbins.github.io/aomanalyzer.io/
This takes 10 seconds.
I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.
If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).
JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.
> Every block of a JPEG XL image is effectively a small tile,
Operative word here is "small", so it has different effect, thus doesn't imply same sensitivity trigger
1 reply →
We can agree on wanting a better internet :)
I participated in the design of those filters, so no, I do not deeply dislike the way they look.
This gaslighting is not convincing. No matter how many filters AVIF has, I distinctly remember tile artifacts being particularly disturbing. More so than individual blocks, whose size and border effects differ; tiles are a straight line through the entire image.
JPEG XL does not have this problem because the design and codestream enables parallel decoding (thanks to per-group offsets encoded in the 'TOC'), hence does not require separate tiles.