Hacker News Reader

Comment by 88j88 | Hacker News Reader

In the example given, the image looks far worse with AVIF. Given that this is an F1 car driving with motion blur- the AVIF image looks slow, because now the blur is in every direction.. the wheels appear to have grey liquid dripping from them, and areas of the car that weren't blurred due to being in focal plane, are now mushed and blurred as well!

View on HN

That's why the only acceptable way to compare codecs is to have two images of exactly the same size. At significantly different sizes, the compression artifacts will be different enough that the comparison becomes subjective, at best.

Here's a comparison that has AVIF, JPEG-XL, mozjpeg, and others: https://afontenot.github.io/image-formats-comparison/

If you need images of the same exact size for them to look the same then there is no point to having new codecs.

OP is saying you need them to be the same to make the image quality difference more obvious. If you shrunk the other codecs to the size the AVIF version is at, you’d see much worse visual artifacts. If you increased AVIF to be the same size as the others, you’d get better relative image quality.

The article is trying to demonstrate how much more compression is achieved by trying to keep relative image quality the same. That’s fine normally but when you have a broad population looking at it then it’s going to be a lot of nitpicking which isn’t helpful when you’re trying to communicate about the codec quality (and no benchmark is perfect but it’s pretty clear that AVIF is roughly 20% or better than H265 if I recall correctly - good luck being able to measure a 20% relative difference in image quality by hand).

Exactly. Many people are insensitive to blurring / smearing artifacts, and so what you very often see is a comparison between an old codec at a medium bitrate with noticeable artifacts (e.g. JPEG picking and ringing) and a new codec at a low bitrate with different artifacts that the author just didn't notice. It's no longer a 1:1 comparison. Is the modern codec still better? Probably, but unless the new codec is identical to the old one with less bitrate (hint: it rarely is), you can't prove it with differently sized comparison images.

It cuts both ways though which is what I’m trying to say. Humans can’t say “this artifact is 20% worse”. Everyone has a subjective opinion.

I disagree thought mostly about the codec characterization. H265/AV1 are definitely higher quality at the same bitrate. The test I used is to find the bitrate that artifacts started to be noticeable. H265 was 15-20% smaller bitrate consistently (across multiple people surveyed, not just me). I could definitely believe that AV1 manages a similar feat above that.

I think the artifacts from JPEG and other algorithms are distracting enough that I don't get to consider whether the image is portraying a fast moving vehicle or not. The nitpick you are making is a luxury because you aren't being distracted by the blocky hallucinations of 1992.

I prefer the graininess of JPEG to the overly noise-reduced algorithmic watercolor effect of AVIF, which reminds me of cell phone camera reconstruction algorithms and pinch zoom. Granted it's not a fair comparison because AVIF has a much larger file size.

The image was acceptable for me. What do you want for 15kb? I'd expect a higher quality for click to expand, but this is acceptable to me alongside text content.

>What do you want for 15kb?

I dont want 15KB, because difference between 15 and 70 is 5 milliseconds.

> I dont want 15KB, because difference between 15 and 70 is 5 milliseconds.

And I want it, as on travelling or mobile I'm golden if I get 1 MBit/s (= 128 KiB/s) download bandwidth, more often it's around 300-400 KBit/s (37-50 KiB/s), so:

  1 MBit/s and one image -> 546 ms vs. 117 ms
  300 KBit/s and 1 image -> 1892 ms vs. 405 ms

Most sites have more than one image, say five for some realistic example:

  1 MBit/s BW:
  AVIF 15 KiB: 0.6s
  JPEG 70 KiB: 2.7s

  300 KBit/s BW:
  AVIF 15 KiB: 2.0s
  JPEG 70 KiB: 9.5s

That's both quite the noticeable difference.

In my residence I'm lucky and get 100+ Mbit/s and even 1 GBit/s at work, but there are lots of countries in the world that don't and once one is affected by that, like I on my train travels, it gets really noticeable which sites have low-bandwidth ignorant engineers, causing not only frustration but often actually impacting life in more meaningful ways negatively.

That's a good point. There probably will never be a one size fits all solution. Luckily the img srcset provides an option for this scenario.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

How would that help me when developers will choose to "optimize" the best version to 15KB? Surely 70KB jpeg will be listed as a fallback. There is no option of defining quality/PSNR/PEVQ/SSIM, only pixel density.

For now that is down to the browser to determine which file to load. From a design perspective, it makes sense to have the HQ image load full screen on click.

Yes, I get that. The problem is there isnt much for the browser to base its heuristics on. Would you send HEAD request for all the listed assets to at least get file sizes? This will be slower and might be even more traffic than just grabbing first one.

Requiring listed size/quality for all the sources might not even be feasible without further automation on the server side, not to mention potential content mangling/"optimizing" proxies/appliances.

HEAD requests seem like the only option aside from inferring size from suggested resolution and format. Imagine trusting the author to include the resource size.

If I could add to the spec, I would put something for lofi/hifi. Then of course that is all subjective and developers will eventually use it in problematic ways.

There's already enough gaming around pagespeed scores. If such an incentive is added, the spec needs to be formulated in an ergonomic way to avoid mal-optimizations.

I agree, either compare at the same size or the same perceptual quality. I know the latter is subjective, but in this case the JPEG is significantly higher quality.

JS disabled here and all I can see imagewise is the single mugshot of the author. Apparently you need javascript to show pictures. Is this deliberate perhaps. I wonder how much the JS weighs.

"how much the JS weighs" is a question that's pretty easy to answer, take a look! It's significantly smaller than a single image.

The page is not just loading pictures, it is loading tools for detailed comparison of picture encodings.

Reply on news.ycombinator.com