Web developer's guide to AVIF images
darekkay.com
darekkay.com
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?
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...
or more precisely, irrevocable except if you try to sue google for patent infringement.
Are you suggesting that the members (including many tech giants) are overlooking some patents held by others which will then be used to extract a price ruining the format they have all been pushing? This seems somewhat unlikely right?
They're definitely not overlooking it — the AOMedia statement I linked to above was a direct response to the collected patent claims by non-members, which number over 1,000 so far.
If I remember correctly, Firefox at one point refuse to include h.264 decoder even if they granted royalty free usage because the codec is considered patent encumbered.
AFAIK the thing Firefox refused to accept wound up happening anyway. Cisco released a nominally BSD-licensed H.264 decoder and agreed to pay the maximum royalty possible to MPEG-LA. If you use their specific codec binaries, then you're covered under the patent license. So Mozilla wound up writing a new plugin framework specifically to host OpenH264 so that WebRTC could have a standard codec.
I agree 100%, and am not the person arguing that patent-encumbered technology is incompatible with free software or bad in any way.
The point of my unpopular post is simply that making a decision based on whether a technology is patent-encumbered makes zero sense in this case since all of them are.
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...
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.
Matches my experience pretty well. AVIF can look quite good (for web purposes) at very low bitrates, while JXL falls apart. (JXL actually has two different modes of operation - modular mode is better at lower bitrates, but it's not considered to be JXL's main mode of operation.)
JPEG-XL seems to be designed to replace JPEG for high quality photographic images, and in my experience it's fantastic at this. I see much better results at higher bitrates (compared to AVIF), and JXL can also losslessly compress JPEGs to a smaller size.
There's a comparison between AVIF and JPEG-XL here https://afontenot.github.io/image-formats-comparison although JPEG-XL is rather fast moving target at the moment and the comparison hasn't been updated in quite a few months.
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....
I also want to point out that people can tell the difference between when something should be good quality and when it doesn't matter. Like even on Instagram, people will forgive a pixelated meme but still be disappointed by a portrait with compression artifacts.
I can't decide if Instagram falls under the like-Flickr use-case or not. I think on mobile, AVIF-style compression would still be best, but it could be different on desktop.
I keep swinging from one side to another, on one hand I want image size to be much smaller ( HEIF / AVIF or better yet, something based on VVC ) BPP 0.1+, on the other hand a 500x500 image is only 32KB at BPP 1.0 with JPEGXL.
Right now I am mostly alining to JPEGXL because I think AVIF or others Ultra Low BitRate format are sort of over optimising, not to mention JPEGXL decode faster and uses less resources. So it seems to be the most practical one.
Hard disagree here. We're talking image format, not image renderers. Whatever ends up being standardized on will eventually become the format "core content" is being stored in and transferred in. It will be the format in which my phone will save photos of my daughter, the format that her grandparents will receive those photos in (possibly twice transcoded by whatever IM they're using these days), so believe me, "not ugly" isn't gonna cut it here.
The photographers, the stock photo sites, the marketers - they'll all know how to keep images at high quality, and they have their reasons for doing so. Regular people will typically just use the defaults, so it's important to optimize the defaults for them, instead of marketing spam. If marketing spam is indeed the majority of data traffic on-line, there are other avenues to address it.
> I did a performance analysis of a set of sites recently, and many have images that are 10x bigger than necessary
Yeah, they also don't care. Why would they? Bandwidth is usually too cheap to meter for most commercial sites like these. If we try to fix their image sizes top-down by more aggressive quality reduction, some marketer will eventually notice the images "look bad", and fix it. Meanwhile, regular people will get the short end of the stick.
You shouldn't just take an image from your phone as-is, stick it on a website, and display it at 400x400 or whatever. Firstly, that won't work if you took the image with an iPhone, since it uses HEIF, which isn't supported by any browser. Secondly, it'll be orders of magnitude too big.
Sites will care about this stuff when it impacts their metrics like first-contentful-paint, which will soon begin impacting Google search ranking.
Because it's not about server bandwidth, it's about download speeds on slow connections -- mobile, bad Wi-Fi, etc.
You always want images that are no larger than they have to be for page load speeds. It's a user experience thing, not a cost thing.
Sure, there are tons of websites that don't optimize for page load speeds.
There are also tons that do -- including some of the largest, most popular websites on the planet, that perform very fine-tuned image compression for this purpose. Managers pore over analytics reporting 95th pctl client-side loading time, etc. So "rarely if ever" is just utterly false.
Why the defeatist attitude?
In that case the best compression is to omit the image.
This is not the exception. This is the common case.
Instagram/Facebook posts, Tweets (a very large % have images now), TikTok/Youtube/Twitch/Netflix thumbnails, people sending photos of their family/dog/cat/houseplant to a WhatsApp/Telegram group: all of these are transferred in compressed formats.
That's even before you get into the debate of whether photojournalists' images on news articles (FAR more common than product pics on tech sites) fall under your definition of "images users scroll past", or "core content".
It seems pretty bizarre to think 10 F1 websites are representative of the common cases.
The examples given of core content were Flickr and Unsplash. In other words, photographic perfection.
Photographic perfection-quality on the web is definitely the exception, not the rule.
Is there evidence that most people perceive a difference outside of this on popular consumer hardware?
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
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?
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.
Firefox AVIF experimental support is disabled by default but can be activated via "image.avif.enabled" flag.
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.
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.
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" %}It solves most issues mentioned in this thread https://jpeg.org/jpegxl/
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/.
You can also specify a list of images formats in decreasing order of preference, like:
formats: [avif, webp, original]
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.