5 ms·

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 th

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 12d 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 12d 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 12d 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 12d ago
      > AFAIK "their choice" here is just the default Well, the default in avifenc can always be changed. Do keep in mind there's no "one size fits all" implementation, as customers desire different loading tradeoffs. You might be surprised, but during testing (outside HN), we've seen people actually prefer "2 layer" loading. I'm surprised HN likes progressive loading to be more granular, and use that to push back. I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience. Anyway, the more expressive mode in avifenc is `--layered` (yes, I know the name is weird). > Usable for what? Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here. On the other hand, JXL is just too blurry at 8kB to make sense of the image -- only the egg and carrot are recognizable, maaybe the cucumber? IMO JXL needs the pass at ~28kB to make everything salient, including sprouts and beet. Yes, I know there are subjective effects at play and I'm sure we'll disagree on exact image thresholds, but recognizing objects within an image is so important in real-life use cases.
janwas 12d ago
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.
- juliobbv 12d ago
  Let's be productive: https://pengbins.github.io/aomanalyzer.io/ https://pengbins.github.io/aomanalyzer.io/ - Upload the problematic image to the AOM analyzer - Press 'L' to show tiles view - How many tiles (yellow rectangles) do you count? - Are artifacts actually at those tile borders? This takes 10 seconds.
- computerbuster 11d ago
  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.
  - eviks 11d ago
    > 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
    - juliobbv 11d ago
      By "small", it's meant in a relative sense. JXL's coded blocks can be as big as 64x64, and block boundaries can create visible seams. Example: https://juliobbv.com/pics/photo.jxl https://juliobbv.com/pics/photo.jxl These seams are especially noticeable in the background, and align with coded block edges. You can tell the encoder is trying to conceal them as best as it can, but this cannot be properly mitigated without a proper deblocking filter. For comparison, AV1 tiles normatively go through the deblocking filter.

bilkow 12d 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 12d 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 12d 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 12d ago
    > AFAIK "their choice" here is just the default Well, the default in avifenc can always be changed. Do keep in mind there's no "one size fits all" implementation, as customers desire different loading tradeoffs. You might be surprised, but during testing (outside HN), we've seen people actually prefer "2 layer" loading. I'm surprised HN likes progressive loading to be more granular, and use that to push back. I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience. Anyway, the more expressive mode in avifenc is `--layered` (yes, I know the name is weird). > Usable for what? Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here. On the other hand, JXL is just too blurry at 8kB to make sense of the image -- only the egg and carrot are recognizable, maaybe the cucumber? IMO JXL needs the pass at ~28kB to make everything salient, including sprouts and beet. Yes, I know there are subjective effects at play and I'm sure we'll disagree on exact image thresholds, but recognizing objects within an image is so important in real-life use cases.

janwas 12d ago

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.

juliobbv 12d ago
Let's be productive: https://pengbins.github.io/aomanalyzer.io/ https://pengbins.github.io/aomanalyzer.io/ - Upload the problematic image to the AOM analyzer - Press 'L' to show tiles view - How many tiles (yellow rectangles) do you count? - Are artifacts actually at those tile borders? This takes 10 seconds.
computerbuster 11d ago
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.
- eviks 11d ago
  > 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
  - juliobbv 11d ago
    By "small", it's meant in a relative sense. JXL's coded blocks can be as big as 64x64, and block boundaries can create visible seams. Example: https://juliobbv.com/pics/photo.jxl https://juliobbv.com/pics/photo.jxl These seams are especially noticeable in the background, and align with coded block edges. You can tell the encoder is trying to conceal them as best as it can, but this cannot be properly mitigated without a proper deblocking filter. For comparison, AV1 tiles normatively go through the deblocking filter.