Web developer's guide to AVIF images

by darekkay • 5 years ago

82 75 5 years ago

kactus• 5 years ago

I need AVIF converters to get faster before I start using it. I added it to a project recently built on an SSG and it added about 1-5s per image to build time - which adds up on 200 images.

darekkay3• 5 years ago

Yes, AVIF encoding is quite slow. Are you caching/storing the images? Converting 200 images will take a few minutes, but it should be a one-time process, from which other people will benefit.

vlovich123• 5 years ago

Have you tried libheif? According to https://github.com/joedrago/avif/issues/11, it's a bit faster. Probably will need CPU/GPU chips that can accelerate the codecs more efficiently before the encode times really start coming down.

TD-Linux3• 5 years ago

libavif (and the libraries that back it) have a speed parameter to control the CPU/quality tradeoff. Have you tried tweaking that and seeing if you get acceptable speed?

bscphil5• 5 years ago

Note that AVIF has no color management support at all in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1634741

In my case, because I have full color management enabled, the AVIF image in the article displays incorrectly (too much saturation on my wide-gamut screen) while the JPG and WebP display correctly.

jand• 5 years ago

note for the next person, i had to search:

Firefox AVIF experimental support is disabled by default but can be activated via "image.avif.enabled" flag.

chrismorgan• 5 years ago

And this is the exact reason that it hasn’t been stabilised yet. It was going to be released in 86 (February), and was even enabled in the 86 beta, but people pointed out that this should be considered a blocker as it would scupper the format for years by undermining all confidence in it, so it was disabled again.

jiggawatts• 5 years ago

The last time this came up I noticed and commented on the same thing. It's a bad sign that it's still unresolved...

bscphil5• 5 years ago

It gets worse, apparently the code just assumes that the data is encoded limited range YUV, so it does the expansion to full range even on files that are already full range (the default output for some encoders). https://bugzilla.mozilla.org/show_bug.cgi?id=1654461

I believe this may affect the images in the article, actually. It looks to me like the dark areas of the animal's hair are crushed pretty badly - not just the saturation issue I'm talking about.

postalrat2• 5 years ago

The colors on the side and head of the cow are pretty bad in the avif vs the jpeg and webp images. Those 4kb aren't free in this example.

jaffathecake9• 5 years ago

Are you using Firefox? The AVIF decoder in Firefox isn't ready yet (it isn't enabled by default) and has particular issues around colour.

I'm not seeing the differences you're describing in Chrome.

But, of course, those 4kb are not free, but the artifacts seem a lot more natural than other formats.

Fwiw, I looked at a few images in detail at https://jakearchibald.com/2020/avif-has-landed/.

darekkay3• 5 years ago

I've made the same experience: AVIF images sometimes look strange in Firefox (AVIF support behind a feature flag), but they look good in Chrome. I think Firefox might use the OS AVIF decoder, because the images also look strange when I open them directly on my Windows machine.

dmhmr• 5 years ago

I can see the differences in Chrome too though? I came to the comments to see if anyone else could tell that the AVIF example is inferior to alternatives.

postalrat2• 5 years ago

I was seeing the difference in chrome, but on linux.

crazygringo5• 5 years ago

You know, I don't really personally care if the successor to JPEG is AVIF (based on AV1), HEIF (based on h.265, pushed by Apple), or WebP (based on V8).

I just wish we could standardize on one. Trying to figure out which browsers support which, which way the winds are blowing, etc. keeps me sticking to JPEG.

It seems like h.265 "won" as the most widely supported new video codec with hardware acceleration. Yet confusingly, HEIF has not ridden on its coattails.

Where is this all going? And will we even have settled on a single successor before next-gen codecs like h.266 disrupt it all again?

freeone30002• 5 years ago

HEIF has the problem of being patent-encumbered. Cisco has graciously given out decoding licenses, but encoding is murkier. Luckily, hardware acceleration usually isn't required for still images, so you can encode to whatever, as browsers can decode them all just fine.

CharlesW3• 5 years ago

WebP and AV1 are patent-encumbered as well.

Google provides a royalty-free patent license, which can be revoked.

https://github.com/ImageMagick/webp/blob/main/PATENTS

AOMedia has a "royalty-free patent licensing commitment from all AOMedia members", but that doesn't mean that AV1 users won't have to pay to license patents from non-members.

http://aomedia.org/press%20releases/the-alliance-for-open-me...

pezezin• 5 years ago

I really hope that the single successor will be JPEG-XL. It's much better format for still pictures (faster encoding and decoding, higher quality, almost unlimited picture size, layers, color channels, etc), and the ability to losslessly recompress existing JPEGs is huge.

xeeeeeeeeeeenu• 5 years ago

You know, I don't really personally care if the successor to JPEG is AVIF (based on AV1), HEIF (based on h.265, pushed by Apple), or WebP (based on V8).

You should care because those formats aren't equivalent. In many important cases, WebP performs worse than the good old JPEG[1]. It's popular mainly because of Google's brand and cargo culting. HEIF is doomed because it isn't royalty-free.

In my opinion, JPEG XL is the most interesting new format. Cloudinary published many blogposts comparing JPEG XL to the other formats, for example: [2][3]. I really recommend reading them.

BTW, Chromium has recently added support for JPEG XL decoding[4]. It's currently hidden behind a feature flag.

[1] - In medium to high BPP photographic images (which, I believe, is the most common use of lossy image compression) and in generation loss tests.

[2] https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

[3] https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...

[4] https://chromium.googlesource.com/chromium/src/+/043d3254221...

jaffathecake9• 5 years ago

We added a preview of the JPEG-XL encoder to https://squoosh.app (and WebPv2) so you can try it with your own images.

In my experience, AVIF tends to outperform JXL in most web use-cases. However, for cases where the image should be really high quality (where the image is core content, like Flickr or Unsplash), the winner is less clear. Also, at those kinds of sizes, JPEG-XL's progressive rendering becomes an important factor.

But seriously, there's so much hype around these image formats, the best thing to do is to test it with your own images and your own eyes.

jaffathecake9• 5 years ago

In medium to high BPP photographic images (which, I believe, is the most common use of lossy image compression)

I don't think this is true. Most web images shouldn't be "near lossless" they should be "not ugly", with the exception being images that are core content (think Flickr or Unsplash).

If a tech product is illustrated with a child laughing at some salad, or whatever, it doesn't matter if some detail is lost, as long as it doesn't look ugly-compressed. Users will be scrolling past it, not zooming in and comparing it to the original.

I did a performance analysis of a set of sites recently, and many have images that are 10x bigger than necessary https://jakearchibald.com/2021/f1-perf-part-2/#issue-large-p....

AuryGlenz• 5 years ago

As a photographer I just want a format that I can send to clients (and for my own sake) that’s better than 8 bit jpegs. Bonus points for lossless editing and re-saving. It’s ridiculous how we’ve been stuck on such an out of date format for so long when everything else in photography has gotten so advanced.

bobmaxup• 5 years ago

That precision suffices for images with a standard dynamic-range (SDR) and a limited color-gamut like sRGB

Is there evidence that most people perceive a difference outside of this on popular consumer hardware?

tootie2• 5 years ago

Not just their brand and cult. It's because they control search, they count page speed as a ranking factor, their benchmarks tell you to prefer webp for better performance.

jaffathecake9• 5 years ago

Video hardware acceleration tends to be optimised for one stream, one frame at a time. It doesn't often translate well to loading multiple images of different dimensions & settings in parallel.

zokier• 5 years ago

And will we even have settled on a single successor before next-gen codecs like h.266 disrupt it all again?

I don't think there is great risk of getting disrupted by next-gen codecs because the gen-to-gen improvements for stills will be so marginal, especially compared to the improvement from jpeg to avif/heif. So there is little motivation to iterate there, especially considering the computational costs.

I see whatever we settle on will probably last next 20 years. So taking few years to settle feels fine in my books

Goz3rr• 5 years ago

It seems like h.265 "won" as the most widely supported new video codec with hardware acceleration.

Unless I'm missing something, AV1 is supported in Chrome, Edge, and Firefox while h.265 is only supported in Safari? How is that winning?

https://caniuse.com/hevc https://caniuse.com/av1

afavour• 5 years ago

The "with hardware acceleration" part is what's missing there. Very important for mobile devices.

tootie2• 5 years ago

A general approach to content type negotiation and transcoding would be nice too.

eplanit• 5 years ago

Exactly. The sample image in TFA won't display in FF on my android phone. A new road to hoe for avif

XCSme• 5 years ago

I think that by the time we decide on the next image compression format the ML super-resolution will become so popular and easy to use that browsers and other devices will have an "upscaler" implemented in them.

zackbloom• 5 years ago

I recently moved an Eleventy static site to start generating AVIF images. It is absolutely incredible the savings. I have images which went from 260kB to 16!

I used an npm module called @11ty/eleventy-img which renders the image variants at build time and generates the appropriate HTML for the browser to select the correct variant.

All I have to do is this, and I get correctly sized variants in JPG, WebP, and AVIF:

    {% image "./src/static/images/grandma-holding-heirloom-video-book.png", "Woman holding Heirloom video book", "1152, 1896", "(min-width: 450px) 1896px, 1152px" %}

anthropodie• 5 years ago

It's baffling to me that no one has mentioned about jpeg-xl here yet.

It solves most issues mentioned in this thread https://jpeg.org/jpegxl/

bscphil5• 5 years ago

It's not supported in many (any?) web browsers.

LeoPanthera2• 5 years ago

As Safari doesn't support AVIF, if you use it, you have to abandon all iPhone (and some Mac) users.

egfx• 5 years ago

Same with chrome on iOS devices.

celsoazevedo2• 5 years ago

All browsers on iOS are essentially Safari with a different skin. Apple doesn't allow devs to use their own engine.

bhhaskin• 5 years ago

Or use picture tags with multiple formats. Then it will gracefully fallback.

LeoPanthera2• 5 years ago

But then you lose all the space saving advantages.

re• 5 years ago

It might be coming; WebKit supports it now: https://bugs.webkit.org/show_bug.cgi?id=207750

ksec3• 5 years ago

What are the chances that WebKit supports it but Apple / Safari dont. After all there are lots of other browsers / software based on WebKit.

baggy_trough• 5 years ago

It’s annoying that AVIF is supported in Chrome but not MS Chromium Edge.

hivacruz• 5 years ago

For those who use Jekyll as a static site generator, I highly recommend the plugin "jekyll_picture_tag" [1]. It takes care of generating multiple images in different formats and sizes, including AVIF.

You can also specify a list of images formats in decreasing order of preference, like:

    formats: [avif, webp, original]

[1]: https://github.com/rbuchberger/jekyll_picture_tag

Web developer's guide to AVIF images

Related Stories