5 ms·

Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the

Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the charts that are purportedly about JPEG XL makes this feel like a marketing piece of some fashion. Certainly, they advertise their Iris-WebP encoder throughout the post, with an implication that if you haven't paid to the author for it, you're not using WebP correctly, I guess? Moreover, there are some methodological oddities. For example, JPEG XL decoding is tested in single-threaded mode when it's optimized for multi-threaded decoding (where AVIF has artifacts from tiling). Also, the tested command is "jxl_cli --speedtest", which means that the benchmarked time includes the warm-up procedure of the "--speedtest" flag, rather than the pure decoding time. Another example of this is progressive rendering, where the comparison moment is chosen at a local maximum that favors AVIF. JPEG XL materializes a full frame much sooner than AVIF, and starting at, say, the 96,256 B mark, it looks better than AVIF until the full image is loaded.

deleted 13d ago
[deleted]
Scaevolus 13d ago
It also compares the total time for jxl-rs's benchmark mode (which does a warmup and a test decode) for 16-bit RGB against 8-bit WebP to 4:2:0 YUV.
computerbuster 13d 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.
- bilkow 13d ago
  > 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).
  - juliobbv 13d ago
    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!
    - bilkow 13d ago
      > 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.
juliobbv 13d ago
Hi there! I'm Julio (co-developer of libaom and SVT-AV1's tune IQ). Here there are some points worth mentioning, because I'm catching a whiff of bad faith with your comment that honestly needs to be called out: - The inclusion of his two proprietary encoders (Aperture and Iris) just serves to further support the argument that JXL encoder devs have work to do to perform at the frontier, while also proving you only need a person or two to do so. The two FOSS AV1 encoders in the compo (libaom and SVT-AV1) are enough to prove this. Given that blog posts often double up as a way to show-case projects, I think it's fair game to show off a bit. Also, keep in mind Gianni is just 21 and starting his career -- reporting such strong efficiency results across several image formats (AVIF, WebP, Aperture) is impressive and worthy of celebration by the community! - Tiles in AV1 go through the deblocking filter, so there won't be any seams after decoding. In fact, AVIF encoding solutions (like libavif) enable tiling by default. If there were seams, people would've noticed those artifacts and yelled at the libavif maintainers. - *Because* JXL doesn't have a deblocking filter, you could argue that JXL effectively decodes to numerous "mini-tiles" -- each one equaling the size of a coded block. And indeed, you WILL see those boundary artifacts when quality isn't high enough for EPF, Gaborish and/or LF smoothing to mitigate satisfactorily. This is what Gianni's post covers. - AVIF scales very well under multithreaded decoding scenarios, thanks to the excellent work of the dav1d devs. The main conclusion wouldn't have changed -- AVIF is significantly faster to decode than JXL. - In progressive decoding, a very valuable feature is "bytes to first usable image". That's what the comparison is focusing on -- it's not a cherry-picked point at all. By usable: you can tell the pass isn't a "blurhash", but you can actually discern each element in the picture with reasonable detail. You can play with the JXL demo yourself -- JXL roughly needs 3x as many bytes to get to where AVIF is in quality, and JXL is still a bit more blurry in general. This applies to every image in the demo, not just the poke bowl. - The folks who coded the JXL demo happened to use two passes for progressive AVIF, but you can use up to four -- including adding an even lower-quality "blurhash" pass, and/or a medium quality pass. Yes, it's desirable to control the number of passes and quality at the encode stage.

deleted 13d ago

[deleted]

Scaevolus 13d ago

It also compares the total time for jxl-rs's benchmark mode (which does a warmup and a test decode) for 16-bit RGB against 8-bit WebP to 4:2:0 YUV.

computerbuster 13d 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.

bilkow 13d ago
> 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).
- juliobbv 13d ago
  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!
  - bilkow 13d ago
    > 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.

juliobbv 13d ago

Hi there! I'm Julio (co-developer of libaom and SVT-AV1's tune IQ). Here there are some points worth mentioning, because I'm catching a whiff of bad faith with your comment that honestly needs to be called out: - The inclusion of his two proprietary encoders (Aperture and Iris) just serves to further support the argument that JXL encoder devs have work to do to perform at the frontier, while also proving you only need a person or two to do so. The two FOSS AV1 encoders in the compo (libaom and SVT-AV1) are enough to prove this. Given that blog posts often double up as a way to show-case projects, I think it's fair game to show off a bit. Also, keep in mind Gianni is just 21 and starting his career -- reporting such strong efficiency results across several image formats (AVIF, WebP, Aperture) is impressive and worthy of celebration by the community! - Tiles in AV1 go through the deblocking filter, so there won't be any seams after decoding. In fact, AVIF encoding solutions (like libavif) enable tiling by default. If there were seams, people would've noticed those artifacts and yelled at the libavif maintainers. - *Because* JXL doesn't have a deblocking filter, you could argue that JXL effectively decodes to numerous "mini-tiles" -- each one equaling the size of a coded block. And indeed, you WILL see those boundary artifacts when quality isn't high enough for EPF, Gaborish and/or LF smoothing to mitigate satisfactorily. This is what Gianni's post covers. - AVIF scales very well under multithreaded decoding scenarios, thanks to the excellent work of the dav1d devs. The main conclusion wouldn't have changed -- AVIF is significantly faster to decode than JXL. - In progressive decoding, a very valuable feature is "bytes to first usable image". That's what the comparison is focusing on -- it's not a cherry-picked point at all. By usable: you can tell the pass isn't a "blurhash", but you can actually discern each element in the picture with reasonable detail. You can play with the JXL demo yourself -- JXL roughly needs 3x as many bytes to get to where AVIF is in quality, and JXL is still a bit more blurry in general. This applies to every image in the demo, not just the poke bowl. - The folks who coded the JXL demo happened to use two passes for progressive AVIF, but you can use up to four -- including adding an even lower-quality "blurhash" pass, and/or a medium quality pass. Yes, it's desirable to control the number of passes and quality at the encode stage.