7 ms·

Web developer's guide to AVIF images

82 points by darekkay 6y ago

kactus 6y 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.
- darekkay 6y 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 6y ago
  Have you tried libheif? According to https://github.com/joedrago/avif/issues/11 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-Linux 6y 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?
bscphil 6y ago
Note that AVIF has no color management support at all in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1634741 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 6y 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 6y 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.
    - bscphil 6y ago
      Thanks for pointing that out. I posted my top level comment in order to alert anyone using AVIF in Firefox about why the images are likely to look wrong, as well as warn off anyone thinking of including AVIF in an HTML5 <picture> element until the situation has improved. It's worth pointing out that (as far as I know) the fact that canvas elements and videos aren't color managed in Firefox hasn't been considered a blocker for shipping either of them. There hasn't been any movement on the bug I linked in many months (other than users confusing the issue in comments), and so I hope the problem isn't eventually swept under the rug.
- jiggawatts 6y 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...
  - bscphil 6y 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 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.
    - jaffathecake 6y ago
      It will if the images were created with Squoosh, which uses full-range.
postalrat 6y 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.
- jaffathecake 6y 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/ https://jakearchibald.com/2020/avif-has-landed/.
  - darekkay 6y 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.
    - jaffathecake 6y ago
      Nah, Firefox uses a built-in decoder, it just isn't quite ready yet.
  - dmhmr 5y 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.
  - postalrat 5y ago
    I was seeing the difference in chrome, but on linux.
crazygringo 6y 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?
- freeone3000 6y 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.
  - CharlesW 6y 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 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-media-statement/ http://aomedia.org/press%20releases/the-alliance-for-open-me...
    - gruez 6y ago
      >which can be revoked. or more precisely, irrevocable except if you try to sue google for patent infringement.
      - ampdepolymerase 6y ago
        Ah, the good ole' React license trick. Where is the mob outrage? Or are web developers so fickle to not care outside of JavaScript frameworks? Video encoding standards are much lower on the stack and the potential for damage is much greater compared to a website.
zackbloom 6y 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 6y 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/ https://jpeg.org/jpegxl/
  - bscphil 6y ago
    It's not supported in many (any?) web browsers.
    - jaffathecake 6y ago
      Correct, no browsers support it right now. We have a preview of it in https://squoosh.app https://squoosh.app if you want to try it out (also WebPv2).
LeoPanthera 6y ago
As Safari doesn't support AVIF, if you use it, you have to abandon all iPhone (and some Mac) users.
- egfx 6y ago
  Same with chrome on iOS devices.
  - celsoazevedo 6y ago
    All browsers on iOS are essentially Safari with a different skin. Apple doesn't allow devs to use their own engine.
- bhhaskin 6y ago
  Or use picture tags with multiple formats. Then it will gracefully fallback.
  - LeoPanthera 6y ago
    But then you lose all the space saving advantages.
    - crazygringo 6y ago
      Isn't the cost savings usually more to do with bandwidth rather than space?
    - celsoazevedo 6y ago
      The main reason to use new formats online is to speed up page loading. Sites that do this usually have WebP (and now AVIF) and a safe format (JPG, PNG) as fallback. Often the size reduction is worth the extra disk space. Many sites also use CDNs that convert images on the fly, so they just need one file/URL and then the CDN sends WebP to browsers that support it and JPG to browsers that don't.
    - darekkay 6y ago
baggy_trough 6y ago
It’s annoying that AVIF is supported in Chrome but not MS Chromium Edge.
hivacruz 6y 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 https://github.com/rbuchberger/jekyll_picture_tag

82 points by darekkay 6y 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.

darekkay 6y 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 6y ago
Have you tried libheif? According to https://github.com/joedrago/avif/issues/11 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-Linux 6y 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?

bscphil 6y ago

Note that AVIF has no color management support at all in Firefox. https://bugzilla.mozilla.org/show_bug.cgi?id=1634741 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 6y 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 6y 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.
  - bscphil 6y ago
    Thanks for pointing that out. I posted my top level comment in order to alert anyone using AVIF in Firefox about why the images are likely to look wrong, as well as warn off anyone thinking of including AVIF in an HTML5 <picture> element until the situation has improved. It's worth pointing out that (as far as I know) the fact that canvas elements and videos aren't color managed in Firefox hasn't been considered a blocker for shipping either of them. There hasn't been any movement on the bug I linked in many months (other than users confusing the issue in comments), and so I hope the problem isn't eventually swept under the rug.
jiggawatts 6y 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...
- bscphil 6y 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 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.
  - jaffathecake 6y ago
    It will if the images were created with Squoosh, which uses full-range.

postalrat 6y 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.

jaffathecake 6y 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/ https://jakearchibald.com/2020/avif-has-landed/.
- darekkay 6y 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.
  - jaffathecake 6y ago
    Nah, Firefox uses a built-in decoder, it just isn't quite ready yet.
- dmhmr 5y 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.
- postalrat 5y ago
  I was seeing the difference in chrome, but on linux.

crazygringo 6y 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?

freeone3000 6y 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.
- CharlesW 6y 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 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-media-statement/ http://aomedia.org/press%20releases/the-alliance-for-open-me...
  - gruez 6y ago
    >which can be revoked. or more precisely, irrevocable except if you try to sue google for patent infringement.
    - ampdepolymerase 6y ago
      Ah, the good ole' React license trick. Where is the mob outrage? Or are web developers so fickle to not care outside of JavaScript frameworks? Video encoding standards are much lower on the stack and the potential for damage is much greater compared to a website.

zackbloom 6y 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 6y 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/ https://jpeg.org/jpegxl/
- bscphil 6y ago
  It's not supported in many (any?) web browsers.
  - jaffathecake 6y ago
    Correct, no browsers support it right now. We have a preview of it in https://squoosh.app https://squoosh.app if you want to try it out (also WebPv2).

LeoPanthera 6y ago

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

egfx 6y ago
Same with chrome on iOS devices.
- celsoazevedo 6y ago
  All browsers on iOS are essentially Safari with a different skin. Apple doesn't allow devs to use their own engine.
bhhaskin 6y ago
Or use picture tags with multiple formats. Then it will gracefully fallback.
- LeoPanthera 6y ago
  But then you lose all the space saving advantages.
  - crazygringo 6y ago
    Isn't the cost savings usually more to do with bandwidth rather than space?
  - celsoazevedo 6y ago
    The main reason to use new formats online is to speed up page loading. Sites that do this usually have WebP (and now AVIF) and a safe format (JPG, PNG) as fallback. Often the size reduction is worth the extra disk space. Many sites also use CDNs that convert images on the fly, so they just need one file/URL and then the CDN sends WebP to browsers that support it and JPG to browsers that don't.
  - darekkay 6y ago

baggy_trough 6y ago

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

hivacruz 6y 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 https://github.com/rbuchberger/jekyll_picture_tag