AVIF has landed (2020) | Hacker News Reader

AVIF has landed (2020)

jakearchibald.com

141 pointsandrewstuart62 comments

We recently updated IKEA.com to serve AVIFs to browsers that support them where they are smaller for the same level of perceptual quality. Even without Safari support we saw an overall drop in image bandwidth of 21.4% which, considering the amount of traffic we get, is a major chunk of cash saved.

Do you know if Safari will ever support one of the newer formats?

WebKit already supports AVIF directly, but Safari disables that and relies on macOS’s image decoders, which currently don’t.[1] I imagine it’ll arrive at some point.

[1] https://bugs.webkit.org/show_bug.cgi?id=207750#c25

Hopefully. Safari is the new IE, that's for sure.

You can add Edge to that pile too, because even though Chromium supports AVIF Microsoft intentionally disable it.

That's insignificant compared to the list of things safari does differently.

And apple doesn't give ios uses any choice. You are stuck dealing with those differences.

> And apple doesn't give ios uses any choice. You are stuck dealing with those differences.

Yeah, that's by far the worst part. Imagine being stuck with IE indefinitely. :)

https://www.coywolf.news/webmaster/why-webkit-supports-avif-...

Running Epiphany (WebKit2) on Linux. But it seem like not turned ON up until now?

https://libre-software.net/avif-test/

After my experiments, I came to the conclusion, that for raster images, this is a good combination of srcsets and fallbacks to provide best image quality:

  <!-- wrapper element -->
  <picture>

    <!-- avif srcset: 1x, 2x, 3x as auto select higher quality images for higher screen resolutions -->
    <source srcset="/img/articles/iphone-3566282_235.avif 1x, /img/articles/iphone-3566282_235@2x.avif 2x, /img/articles/iphone-3566282_235@3x.avif 3x" type="image/avif">

    <!-- webp srcset -->
    <source srcset="/img/articles/iphone-3566282_235.webp 1x, /img/articles/iphone-3566282_235@2x.webp 2x, /img/articles/iphone-3566282_235@3x.webp 3x" type="image/webp">

    <!-- jpeg also as srcset to provide screen resolution based images -->
    <source srcset="/img/articles/iphone-3566282_235.jpg 1x, /img/articles/iphone-3566282_235@2x.jpg 2x, /img/articles/iphone-3566282_235@3x.jpg 3x" type="image/jpeg">

    <!-- fallback image with loading=lazy, to load images only when visible -->
    <img src="/img/articles/iphone-3566282_235.jpg" alt="Access and recover files from an iPhone on Linux" title="Access and recover files from an iPhone on Linux" loading="lazy" class="size-235 raster ext-jpg" width="235" height="129">

  </picture>

Using this on https://pilabor.com/

I'm seeing some weird behaviour with that on both Chrome 98 and Firefox 97. Chrome seems to be displaying the JPEG, and when I right-click and "Open image in new tab", I get the raw bytes of the AVIF file, not any version of the image. In Firefox, it seems to be displaying the JPEG too, and when I right-click and "Open image in new tab", I get the AVIF file (as an image). Also in Firefox, probably a CSS thing, when the window is made smaller vertically (e.g. by the developer tools at the bottom), the image is scaled down vertically but not horizontally. I'm looking at the image at the top of https://pilabor.com/blog/2021/05/remote-desktop-with-xrdp-an...

That's probably because OP's server doesn't serve a correct Content-Type header for AVIF and also disables content type sniffing.

Needs:

  AddType image/avif .avif

Makes sense for Chrome's behaviour, but that means Firefox is ignoring the "X-Content-Type-Options: nosniff" header, which it supposedly respects: https://blog.mozilla.org/security/2020/04/07/firefox-75-will...

Also, upon further investigation, I think both browsers are displaying the AVIF for me. It has quite a bit less detail than the JPEG, so it's identifiable.

Right, nosniff doesn't apply to images.

Should be fixed, thank you!

It's easier to do this on the server side based on Accept header, e.g. for Apache to serve image.jpg.webp instead of image.jpg:

  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^/?(.+?)\.(jpe?g|png)$ /$1.$2.webp [NC,T=image/webp,E=EXISTING:1,E=ADDVARY:1,L]
  
  <FilesMatch "(?i)\.(jpe?g|png)$">
     Header append "Vary" "Accept"
  </FilesMatch>

Then <img src="image.jpg"> will serve the supported format.

That's a poor quality conneg implementation, don't recommend. Apache httpd comes with mod_negotiation, use that instead to be standard compliant. <https://httpd.apache.org/docs/current/content-negotiation.ht...>

<img src="image"> without extension on the URI will pick the user-agent's best accepted format from the set of files `image.*`.

Interesting, learning a lot here ;) Thank you.

Thanks!

Any suggested resources for current best practices for srcset specifically and HTML images in general? I mean for real world use, not just the latest chrome version.

I see some conflicting advice in this thread and from what little I’ve looked into it, there isn’t a good consensus on the subject yet?

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!

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.

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.

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 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.

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.

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.

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

"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.

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.

Personally I'm trying to push for JXL (for high fidelity) and AVIF (for when lower fidelity is acceptable) adoption at work. With absolutely no success yet but as it matures I'm sure things will turn around.

Would love to see an update on this with JPEG XL. I am still not convinced AVIF is the solution. Although libaom made quite a bit of intra-frame / avif specific improvement in the past 2 years so may be worth taking another look.

The main update is that JPEG XL is still not supported out of the box by any web browser, so it's not something you can use just yet. But if you're just looking for a comparison, there's one here: https://afontenot.github.io/image-formats-comparison/

For anyone wanted to try it out, Firefox and Chromium-based browsers have flags to enable it.

Firefox: about:config, image.jxl.enabled

Chromium: about:flags, Enable JXL image format

In case anyone is curious, this is a pretty good comparison between AVIF and JPEG XL:

https://avif.io/blog/comparisons/avif-vs-jpegxl/#speed

And here is the current state for Safari:

https://jpegxl.io/tutorials/safari/

I wish math would land, so people would say "a quarter to a third the size", which is what I guess they really mean.

What would the best format to convert user-submitted images? We need to update our image pipeline soon, so I'm looking into various options.

It looks like you still have to keep jpg/png around for a few years at least. Even if you drop IE11, there's a few versions of Safari out there that don't support even WebP.

So the pipeline would be:

* png -> resize -> png/lossless webp * jpg/other -> resize -> jpg/webp

Where "other" is whatever format iPhone cameras use.

Is there anything I'm missing if I were to do this today?

Why can’t these kinds of improvements be made to jpg itself? Media format sprawl is already exhausting.

Because its a fixed format from 1992 that needs to maintain backwards compatibility.

mozjpeg greatly improved the state of art jpeg encodig, while maintaining full backwards compatibility https://github.com/mozilla/mozjpeg

but there's a limit on what can be done with the primitives that jpeg offers. for example, jpeg is stuck with the older huffman coding for the entropy encoding part, instead of the better arithmetic coding or asymetric numeral systems

There are plenty of efforts to improve JPEG compression while retaining compatibility with existing decoders. But there's only so much you can do without breaking decoder compatibility, and if you do that then that's a new format whether you call it JPEG or not. It would be super confusing to have .jpg files that wouldn't work in existing software.

JPEG XL is a new format with a new file extension jxl, but it does have backwards compatibility features that look pretty nice. Maybe that's what you want.

Closer to the original than WebP too. Thats pretty damn good.

I wonder if machine learning/deep-fake technology has created even better compression algorithms.

I understand that AV1 and AVIF are license-free and supposed to be open and available to anyone anywhere, but are there really no catches in the license agreement?

Here's the big catch: MPEG-LA can't make any money with it.

For anyone else is the brightness curve different with AVIF? Perhaps an sRGB vs linear issue? I'm on firefox 96.

So much stuff fucks with the color profile of the images, the browser, the OS, the screen. I wouldn't be surprised if only some of the test images have a color profile set correctly.

Firefox held off on AVIF for a few releases to get their image color spaces right. I'm usually blind when it comes to things like this (is this random image resized gamma correct? hell if I know), but even I could tell that AVIFs didn't look right before they fixed it. Those fixes were in well before FF 96, so there might be something else at play.

Tried on a different machine with FF 97 and the problem was gone.

Probably isn't the best idea to compare AVIF to JPEG. JPEG is better suited to high fidelity images, while AVIF is ideal for making the image look good as small as it can.

I suggest looking into JPEG XL for things like photography, scans, etc.

Where can one get a linkable library for AVIF? got it: https://github.com/AOMediaCodec/libavif

What matters are embedded encoders, since I guess that's what smartphone camera outputs.

A new format is good as long as firmwares can encode it at good speed.

consider adding (2020) to the title as this is an old news and current effort are now focused into better software encoder nowadays.

(2020), and the title is editorialised in a way that doesn’t really make sense (though one can figure out the intended meaning).

Reply on news.ycombinator.com