Have you tried Google's jpegli encoder? I find that it generally matches webp for most image types. Quantized png is usually best for anything with a limited color palette though.
I have a similar tool at https://pictolab.io. I use it for tweaking the brightness and satuation of images mostly. For that you want HDR to reduce clipping, and most image formats have surprisingly bad HDR support besides AVIF (and jxl). Jpeg kinda supports it with gain maps but it's kind of tacked-on to the spec. Webp doesn't support HDR at all.
It's also surprisingly hard to support HDR input. For example, Apple uses a weird poorly documented format for the HEIC their iPhones take. I feel like HDR is just kind of a mess right now.
> Even YouTube is preparing to move beyond AV1 and begin streaming video using AV2, potentially as early as 2027. If a company handling the enormous amount of video that YouTube does sees the benefits of a more efficient format, shouldn't the rest of the internet be taking a closer look at what we can do with images and video too?
AV1 (and AV2) do save a lot of bandwidth, and Youtube already serves AV1 selectively to some users. But the biggest drawback of AV1 is that it needs more resources to even decode. This is especially apparent on old computers that don't have dedicated AV1 encoders or decoders. I discovered this when someone complained to me that PaleMoon on their old PC suddenly consumed a lot of CPU resource causing the PC to stutter - turned out that Youtube was serving AV1 encoded videos on it. Disabling AV1 support in the browser fixed it as Youtube was then forced to serve AVC / H.264 encoded videos.
not an odd argument. AVIF is based on AV1, so what they mean is that since we accept YouTube's AV1 usage as mainstream nowadays, so should be it's image part
It's a super strange backwards argument: lots of tiny efficiencies make sense when you're operating at a Google or Amazon scale that make zero sense in other contexts.
AVIF consumes around 25 times more CPU during encoding as JPEG. Take this in consideration if you pay for the power consumption. And on the user-facing side, if you upload an images it takes f.ex. 12 seconds (sic!) and not half a second.
12 seconds? It takes 7 seconds on my phone, in a wasm runtime using an older version of the encoder.
From my experience throwing random JPEGs at it, it's 3 to 4 times smaller, that's a good chunk of data saved, which in turn is a lot of energy saved on visitors' radios being active.
Unlike with jpeg, you don't need 85 or 95 percent on the quality score, 50 is more than good enough for most pictures on a website.
If you're hosting images and want a fully lossless encoding the CPU time may become a factor, but if you're hosting user generated content, I don't think it's all that bad. Plus, you can just move the encoding part to the user side of the equation and pretend it's part of the upload progress bar if you're desperate to pay the power bill.
The numbers above coming from a test run on one of my own servers serving and receiving user generated images. It is a Intel E5 56 CPU threads machine with DDR4 RAM. A single thread may be slower then your phone CPU cores, but that's what you find very often when running servers.
I see, I can imagine a decade old CPU without any kind of video acceleration taking a while indeed. Technology has come a long way since the E5-2690v4.
Still, when encoding AVIF, there are various quality options to choose from, and the encoder has gotten better over the past year. On my i3-2120 NAS (which even your E5 should beat on single core perf), encoding an image at default speed takes about 4-6 seconds (JPEG about 2s), while producing an image of comparable quality a third the size. If I pass --speed 10, converting PNG to AVIF takes only half a second.
The standard AV1 encoder has improved a lot over a short amount of time, I invite you to run another benchmark, you may be surprised.
I am trying to hit a sweet spot between affordability, usability and performance. AVIF fells not in this sweet spot as simple as that.
It is cheaper to buy some more (expensive) SSDs, because the images are 20% larger, then to buy new servers, because the encoding is 25 times slower. I am serving images to real users and the servers are in data-center rack. Got it?
The assumption is that a file is read more than it is written. If you spend less time and power compressing the file, you will spend more time and power delivering the file, and often not save anything on the decompression side.
If you want to optimize the user-facing side, you might want to pick HEIC instead to optimize for commonly available HEVC/h.265 hardware encoding capabilities, or to be selective instead and pick AVIF when AV1 capabilities are present.
AVIF is notoriously CPU-intensive to compress without acceleration, but assuming you pay for storage and/or delivery, the results are impressive. JPEG-XL and HEIC also do very well. JPEG really shouldn't be used unless you're trying to target devices that can only read JPEG.
HEIC/h.265 is not supported on Windows 11 by default. You have to pay for an additional decoder that currently costs $0.99 in the Windows Store. Although SOME OEMs provide pre-installed h.265 decoders with hardware acceleration.
Windows 11 is not an image viewer. Your applications that view images bundle the decoders they need.
For various reasons, AVIF and HEIF/HEIC support is generally bundled together in the same decoders. Both of CrabbyAVIF and libheif, for example, read both AVIF and HEIF/HEIC, so while HEIC might sometimes be supported without AVIF, it's harder to have support for AVIF with HEIF/HEIC.
Browsers are a bit weird, not sure why they haven't enabled support.
(It would be an entirely new thing for you to use hardware decoders for stills, so no reason to worry about it as something restrictive.)
Windows 11 has various image viewers that come built in, that allow you to view images that have been downloaded. There's Image Viewer. And Windows Photos, for example, File Explorer displays thumbnails. The screenshot utility. And I'm sure many others.
It is irrelevant that an image gets read more then written, if the user needs to wait 120 seconds (2 minutes) when uploading 10 images, instead of waiting 6 seconds for all of those 10 by using simple jpeg.
It is not only relevant, it is the sole justification for the existence of compression in the first place.
120 seconds is an arbitrary number to throw out there, AVIF compression time is purely dependent on how aggressive you want the file compressed. The ability to go completely nuts with computation is great for when you create the assets once for example.
Native browser support for HEIC is poor, yes. No idea why tbh, the underlying libraries generally support it. Heck, AVIF and HEIF/HEIC support is almost universally bundled together.
Take CrabbyAVIF and libheif: both provide both AVIF and HEIF/HEIC support. Android uses CrabbyAVIF as the platform AVIF/HEIF reader for reference, and considering that Google Photos natively supports HEIF/HEIC (even in browser). They're also using CrabbyAVIF in Chromium, but for some reason they disabled the HEIF/HEIC feature.
If you're making browser apps, you will ultimately care about storage and bandwidth, so AVIF or JPEG-XL are your main options. Outside browser apps you can pick entirely as you please, and if end-user encoder performance matters, HEIC ends up likely winning as hardware AV1 encoders are still less common.
You can adjust the speed of both, you don't have to use the default of whatever library versions you're using. My cjxl defaults to 2x more CPU than avifenc's default, but I can make it 30x more or 480x less; libaom certainly lets you waste a lot more CPU than libjxl, if that's what you want.
I don't know if anyone has published an encode time / quality comparison of the various encoders. It'd have to be recent to include this year's libaom image optimizations.
Abysmal encoding time, poor lossless performance, poor lossy performance at perceptually indistinguishable quality compared to JPEG XL.
So far I haven't performed a benchmark where AVIF has a decisive advantage in any real scenario; none of the scenarios I tested accept the quality loss or compute necessary.
Have you published this benchmark anywhere? It seems to contradict those publicly available, so it would be interesting to examine. To be clear: I doubt your claim and your competency to make it.
This source doesn't debunk anything, it's literally AVIF propaganda that cherry picks parameters and images. It demands JXL match AVIF size before comparing encode time at abysmal q50 factor. Would you encode anything worth showing at q50?
Who cares if AVIF is slightly smaller at some specific scenario when Mercury is in retrograde, when it takes a century to encode?
My entire point is that some 3% size gain is acceptable for shortening the encode time by 97%, which is what JPEG XL does.
Does AVIF carry the same patent risks as full/motion AV1?
(I’m not saying I support the claims or not, I have no idea about their technical and let alone legal merit, just thinking that there are attempts at enforcement against sites streaming AV1 and whether choosing AV1 puts say my site at risk)
Probably not. But if anyone ever decides to enforce patents over AV1 or AVIF, they will fight about every company in Big Tech and quite a bit of Hollywood: https://aomedia.org/about/members/
It’s actually shared patent pool with H265, most big tech companies already license it for the latter, there was some litigation with Snapchat I think regarding AV1. Royalties are for distribution, I assume, so posting AV1 video might be a no-no. I meant to ask if the ‘patented’ stuff is even used when encoding an image. (NB the codec is not patented, nobody claims that afaik, but rather it might be patent encumbered, as in it uses algorithm that might be patented as a part of its design)
So you still have to license it, and it’s not royalty free; if it’s the same patent pool as H265?
I know I had to pay like $1.99 on my synology for H265 support, and likewise for “Advanced Media Extensions” on windows 10/11, although that may have changed.
H.265 actually requires licenses from multiple patent pools, as far as I understand any modern codec is more like a pipeline of transforms than one self contained algorithm so it really matters that someone who is at least really comfortable with signal processing (I’d imagine DSP patent lawyers are very rare) to determine the applicability of that claim to single-frame AVIF.
Hard to say, but possibly less since it's a still image, not a video, so it inherently corresponds only to a part of AV1.
No need to worry about these risks for using it though. You can never say that no patent troll will surface tomorrow for literally anything. That's not a reason not to use things.
I thought it was pretty well established that JXL has a big room for improvement when it comes to encoders. There are some fundamental limitations wrt the absolute lowest bitrates, but that the room for improvement in encoders is rather substantial, especially with things like rate-distortion search heuristics.
The comparison is more about who has had the most man-hours and megadollars put into encoders quality than about the inherent limitations about the format.
With that said, I use AVIF, but I do have what can be said to be an irrational preference for JXL.
> but I do have what can be said to be an irrational preference for JXL.
Is it irrational to follow the collective "one format to rule them all" dream? Sure, the codec itself needs work, but seeing how long we've been stuck with the JPEG/PNG/GIF trio (even with better encoders like mozjpeg/jpegli or optipng/zopfli) with TIFF as a catch-all backup, getting the format right once and for all really matters.
I'm still weirded by the low amount of workforce in libjxl/jxl-rs; sure, too many cooks do ruin the broth, but too few too, in that domain.
You could make an argument that we should have AVIF everywhere on the web. But if you want a single image format to be everywhere, I think JPEG-XL is just better suited. AVIF has restrictions on resolutions and number of planes, and doesn't do lossless very well. It's competitive with AVIF on lossy image quality (even though yes, AVIF does seem like it tends to consistently have the advantage there).
Image formats goes in era, and there's no need for monoculture. But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win. Should JPEGXL2 beat it in the future then it can take over for a decade. We seem to essentially have gone through like 4 formats so far: gif, jpg, PNG and webp. On vector side, SVG has no real competition - it's solid.
> But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win.
I'm not sure this is the right conclusion to draw...
1) The author's pain point (use case) is hardware pricing - presuming that goes down (as either AI demands drops/and or production increases), this does not speak to a demand for size, instead, it is about doing more with less...
2) I'm not certain that the exabytes of demand (assuming it comes) will be from AVIF. Rather, if data is important, I think the demand will be a different format entirely (archives, for instance). Demand for more (quality) data might paradoxically call for less compression and less cpu-intensive qualities - uncompressed, raw data, for instance. If is faster and cheaper than bothering with complex algorithms, then simpler formats should be more prevalent.
Building on 1 and 2, a more capable image format, like JPEG-XL, becomes a more logical choice, not the one that can compress the best or is the smallest (in an exa-byte-as-the-norm world).
AVIF supports a higher resolution at 2^32-1 pixels per dimension, vs JPEG-XL's 2^30-1 pixels. But really it doesn't matter since something is going to impose an arbitrarily smaller limit on either before letting you try to allocate more RAM than any computer can address. Yes, plenty of comparison websites confuse AV1 limits (sometimes AV1 profile limits!) with AVIF limits.
For arbitrary planes, AVIF calls them auxiliary images. Unless you mean encoding non-RGB data to start with like how DNG uses JPEG-XL. At which point you're outside the scope of any standard interpretation of JPEG-XL data.
> Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format.
Huh?
JpegXL is the only widely supported format (once it comes to the various browser as is planned) that can store true HDR linear images in floating point (fp16 and fp32) formats.
AVIF can only do 10 bit integer ranges, sure that HDR compared to 8bit but it is not sufficient for useful extended range color spaces.
The format is widely supported, but I'd be very surprised if linear HDR becomes widely supported outside of image editors. JPEG-XR supported fp32 linear HDR way earlier anyway, and no one cared because no one cares about linear HDR after editing.
I don’t feel like the difference matters all that much. Both AVIF and jpeg xl produce reasonably sized files for your personal photo library. What you really care about is capabilities for things like HDR and expanded color spaces which both formats seem to have excellent support for.
Just about anything is better than jpeg these days.
Agree, though I do miss the clarity of if an image is lossy or lossless just by extension. (Obviously a png could be produced from a heavily compressed jpg, but it is still a handy heuristic in my image pipelines)
Aside from maybe .bmp, that never really existed (though .bmp has palletized colours, I guess?).
Just like you can assume most PNGs to be lossless (despite supporting pallettes, which pngquant uses to "compress" them) and non-animated (despite APNG being over 22 years old), you can assume most AVIF and WebP images are lossy. Same with JXL. HEIF requires a bit of special care (it's only produced by devices with HDR support so your pipeline needs to fit that) but that's pretty much it.
You may get surprised by an accidental, huge lossless AVIF/WebP/HEIF file, but most sources where you can even get these files are all lossy. Unless you recompress your photo library yourself, of course, but then you have full control over the entire process and can decide whether or not you want lossy or lossless.
> I have already switched to AVIF on every platform I use that supports it, and WebP where AVIF isn't supported.
Where AVIF isn’t supported, I reckon you’re better to fall back to JPEG. Everything supports JPEG, but there are still plenty of things that don’t support WebP. Anything that supports WebP now has indicated it’s open to supporting newer formats than the baseline JPEG/GIF/PNG and is almost certain to support AVIF within a few years.
Hosting providers don't want these formats because they're more cpu-intensive for them to decode and transform (e.g. to make a thumbnail, or when you upload a 4K selfie to be cropped into a 256x256 circle avatar, or a 16 megapixel image of a receipt).
By contrast, if you let the user upload a JPEG or even a PNG, you might pay a slightly-higher cost of the incoming bandwidth, but then you (basically for free) transform the image to the small dimensions and format you actually need, and from there the bandwidth is barely a problem.
Sidenote: End users hate WEBP because nearly any software other than web browsers still don't support even reading it, let alone outputting it (and as you pointed out, anywhere that you "upload an image" they're not welcome either).
In my incredibly shoddy testing sample of 1, my current-macOS device does open AVIFs in Preview, so that's an improvement, at least!
OK, I have to admit, they added webp support to Apple Preview in 2020, but it's been common since long before that, so I formed a memory of its uselessness before that point, and I didn't notice when support was added.
It's still a very small number of programs that support it on the desktop, but at least Preview is working now. So I stand corrected.
I am eagerly awaiting the release of Inkscape 1.5 , as 1.4 doesn't render webps (ymmv depending on OS). Windows Explorer previews of webps are janky but workable. Still I find the efficiency benefits sufficient to pick webp over png (jpeg is not an option if you need transparency).
> replaces JPEGs on the front-end of WordPress for browsers that support them.
Ouch. Pretty much every browser supports AVIF now which means everyone gets transcoded images worse than JPEGs one uploaded. For JPEG XL that process is lossless...
Note that the ability to repack a JPEG as-is in a JPEG-XL container gives you a 20% filesize reduction due to the more efficient container, but none of the encoding advancements of JPEG-XL.
Recompressing is not great, but many people might be happy with a file that is less than half the size even if they lost a bit of fidelity. Not everyone has original source material to work with after all.
Enough keyframe-based "image" formats, please! The internet and the world at large needs a real and proper modern format, not some quick hacks from bored engineers that only contribute to the endless fragmentation online and do not leverage any existing infrastructure for serving video. There's more than just crappy ultra-low-quality thumbnails around. WebP, AVIF are the webscale equivalent of serving images.
This article arguments is pretty thin and poor. I would advocate for JPEG XL. Has better compression ratios than webp and older jpegs can be converted lossless to it. Been (re-)added to both Firefox and Chrome.
Because whenever I download an image and its webp, the next thing i do is i google "webp to png/jpg" conversation because yeah service XY or Tool Z doesn't support it.
Or my Fire TV Stick :(
I configure my nginx to serve everything available though. Thats what i can do.
You can throw almost any image format with open standards into squoosh.app if you're still using software that doesn't open webp.
It's been a while since Photoshop finally got support, though, I can't recall the last time webp posed a problem for me. Then again I don't use a Firestick, no idea how that would deal with image formats, I guess it's no longer being maintained?
I’m editing them in Gimp since forever. I don’t remember when Gimp didn’t support AVIF. Photoshop, on the other hand, was always not working with it. I’m not sure about now, perhaps it does. But that’s telling volumes not about AVIF, but about Adobe quality-driven development. (Sarcasm.)
Only just started habitually using WebP...
I added AVIF support to my personal image resizing tool recently - https://tools.simonwillison.net/image-resize-quality - I mostly use that for screenshots though, and WebP works better for those.
Have you tried Google's jpegli encoder? I find that it generally matches webp for most image types. Quantized png is usually best for anything with a limited color palette though.
WEBP/JXL is best for lossless, AVIF is best for lossy. But WEBP is more widely adopted (and also decompresses faster than JXL).
Webp is much better for lossless.
I have a similar tool at https://pictolab.io. I use it for tweaking the brightness and satuation of images mostly. For that you want HDR to reduce clipping, and most image formats have surprisingly bad HDR support besides AVIF (and jxl). Jpeg kinda supports it with gain maps but it's kind of tacked-on to the spec. Webp doesn't support HDR at all.
It's also surprisingly hard to support HDR input. For example, Apple uses a weird poorly documented format for the HEIC their iPhones take. I feel like HDR is just kind of a mess right now.
Lol I went through that same webp-vs-avif thing. AVIF supports HDR, so that's a good reason to switch.
> for screenshots though, and WebP works better for those
Interesting! Better in terms of more quality preserved or smaller file size? Have you found other types of images where this applies?
[flagged]
> Even YouTube is preparing to move beyond AV1 and begin streaming video using AV2, potentially as early as 2027. If a company handling the enormous amount of video that YouTube does sees the benefits of a more efficient format, shouldn't the rest of the internet be taking a closer look at what we can do with images and video too?
Odd argument.
Image isn’t video and we are not YouTube.
AV1 (and AV2) do save a lot of bandwidth, and Youtube already serves AV1 selectively to some users. But the biggest drawback of AV1 is that it needs more resources to even decode. This is especially apparent on old computers that don't have dedicated AV1 encoders or decoders. I discovered this when someone complained to me that PaleMoon on their old PC suddenly consumed a lot of CPU resource causing the PC to stutter - turned out that Youtube was serving AV1 encoded videos on it. Disabling AV1 support in the browser fixed it as Youtube was then forced to serve AVC / H.264 encoded videos.
not an odd argument. AVIF is based on AV1, so what they mean is that since we accept YouTube's AV1 usage as mainstream nowadays, so should be it's image part
Youtube doesn't prefer AV1 at least on my M1 Mac, which can't natively decode it. I get VP9, which is hardware accelerated.
So please don't ruin my battery life just to save a few percent on your egress traffic bill.
[dead]
It's a super strange backwards argument: lots of tiny efficiencies make sense when you're operating at a Google or Amazon scale that make zero sense in other contexts.
AVIF consumes around 25 times more CPU during encoding as JPEG. Take this in consideration if you pay for the power consumption. And on the user-facing side, if you upload an images it takes f.ex. 12 seconds (sic!) and not half a second.
12 seconds? It takes 7 seconds on my phone, in a wasm runtime using an older version of the encoder.
From my experience throwing random JPEGs at it, it's 3 to 4 times smaller, that's a good chunk of data saved, which in turn is a lot of energy saved on visitors' radios being active.
Unlike with jpeg, you don't need 85 or 95 percent on the quality score, 50 is more than good enough for most pictures on a website.
If you're hosting images and want a fully lossless encoding the CPU time may become a factor, but if you're hosting user generated content, I don't think it's all that bad. Plus, you can just move the encoding part to the user side of the equation and pretend it's part of the upload progress bar if you're desperate to pay the power bill.
The numbers above coming from a test run on one of my own servers serving and receiving user generated images. It is a Intel E5 56 CPU threads machine with DDR4 RAM. A single thread may be slower then your phone CPU cores, but that's what you find very often when running servers.
I see, I can imagine a decade old CPU without any kind of video acceleration taking a while indeed. Technology has come a long way since the E5-2690v4.
Still, when encoding AVIF, there are various quality options to choose from, and the encoder has gotten better over the past year. On my i3-2120 NAS (which even your E5 should beat on single core perf), encoding an image at default speed takes about 4-6 seconds (JPEG about 2s), while producing an image of comparable quality a third the size. If I pass --speed 10, converting PNG to AVIF takes only half a second.
The standard AV1 encoder has improved a lot over a short amount of time, I invite you to run another benchmark, you may be surprised.
I am trying to hit a sweet spot between affordability, usability and performance. AVIF fells not in this sweet spot as simple as that. It is cheaper to buy some more (expensive) SSDs, because the images are 20% larger, then to buy new servers, because the encoding is 25 times slower. I am serving images to real users and the servers are in data-center rack. Got it?
The assumption is that a file is read more than it is written. If you spend less time and power compressing the file, you will spend more time and power delivering the file, and often not save anything on the decompression side.
If you want to optimize the user-facing side, you might want to pick HEIC instead to optimize for commonly available HEVC/h.265 hardware encoding capabilities, or to be selective instead and pick AVIF when AV1 capabilities are present.
AVIF is notoriously CPU-intensive to compress without acceleration, but assuming you pay for storage and/or delivery, the results are impressive. JPEG-XL and HEIC also do very well. JPEG really shouldn't be used unless you're trying to target devices that can only read JPEG.
HEIC/h.265 is not supported on Windows 11 by default. You have to pay for an additional decoder that currently costs $0.99 in the Windows Store. Although SOME OEMs provide pre-installed h.265 decoders with hardware acceleration.
So don't do that, please.
Windows 11 is not an image viewer. Your applications that view images bundle the decoders they need.
For various reasons, AVIF and HEIF/HEIC support is generally bundled together in the same decoders. Both of CrabbyAVIF and libheif, for example, read both AVIF and HEIF/HEIC, so while HEIC might sometimes be supported without AVIF, it's harder to have support for AVIF with HEIF/HEIC.
Browsers are a bit weird, not sure why they haven't enabled support.
(It would be an entirely new thing for you to use hardware decoders for stills, so no reason to worry about it as something restrictive.)
Windows 11 has various image viewers that come built in, that allow you to view images that have been downloaded. There's Image Viewer. And Windows Photos, for example, File Explorer displays thumbnails. The screenshot utility. And I'm sure many others.
It is irrelevant that an image gets read more then written, if the user needs to wait 120 seconds (2 minutes) when uploading 10 images, instead of waiting 6 seconds for all of those 10 by using simple jpeg.
Regarding HEIC, you know the browser acceptance for this, do you? https://caniuse.com/?search=heic
It is not only relevant, it is the sole justification for the existence of compression in the first place.
120 seconds is an arbitrary number to throw out there, AVIF compression time is purely dependent on how aggressive you want the file compressed. The ability to go completely nuts with computation is great for when you create the assets once for example.
Native browser support for HEIC is poor, yes. No idea why tbh, the underlying libraries generally support it. Heck, AVIF and HEIF/HEIC support is almost universally bundled together.
Take CrabbyAVIF and libheif: both provide both AVIF and HEIF/HEIC support. Android uses CrabbyAVIF as the platform AVIF/HEIF reader for reference, and considering that Google Photos natively supports HEIF/HEIC (even in browser). They're also using CrabbyAVIF in Chromium, but for some reason they disabled the HEIF/HEIC feature.
If you're making browser apps, you will ultimately care about storage and bandwidth, so AVIF or JPEG-XL are your main options. Outside browser apps you can pick entirely as you please, and if end-user encoder performance matters, HEIC ends up likely winning as hardware AV1 encoders are still less common.
This is also the reason JPEG2000 died off and became a niche format mainly for archival; it's extremely CPU-intensive.
You can adjust the speed of both, you don't have to use the default of whatever library versions you're using. My cjxl defaults to 2x more CPU than avifenc's default, but I can make it 30x more or 480x less; libaom certainly lets you waste a lot more CPU than libjxl, if that's what you want.
I don't know if anyone has published an encode time / quality comparison of the various encoders. It'd have to be recent to include this year's libaom image optimizations.
Regular JPEG can also be compressed much more than it usually is:
https://symbiogenesis.github.io/DotJpegli/
However, video would matter so much more than images, to the overall internet, that images don't even matter by comparison.
It's pretty frustrating that JPEG encoding generally got stuck with libjpeg-turbo.
Abysmal encoding time, poor lossless performance, poor lossy performance at perceptually indistinguishable quality compared to JPEG XL.
So far I haven't performed a benchmark where AVIF has a decisive advantage in any real scenario; none of the scenarios I tested accept the quality loss or compute necessary.
Have you published this benchmark anywhere? It seems to contradict those publicly available, so it would be interesting to examine. To be clear: I doubt your claim and your competency to make it.
Benchmarking code or BTFO. JXL propaganda is getting too irritating at this point.
For the rest of us, this resource debunks all stupid jxl propaganda.
https://jakearchibald.com/2026/jpeg-xl-vs-avif/
This source doesn't debunk anything, it's literally AVIF propaganda that cherry picks parameters and images. It demands JXL match AVIF size before comparing encode time at abysmal q50 factor. Would you encode anything worth showing at q50?
Who cares if AVIF is slightly smaller at some specific scenario when Mercury is in retrograde, when it takes a century to encode?
My entire point is that some 3% size gain is acceptable for shortening the encode time by 97%, which is what JPEG XL does.
Does AVIF carry the same patent risks as full/motion AV1?
(I’m not saying I support the claims or not, I have no idea about their technical and let alone legal merit, just thinking that there are attempts at enforcement against sites streaming AV1 and whether choosing AV1 puts say my site at risk)
Probably not. But if anyone ever decides to enforce patents over AV1 or AVIF, they will fight about every company in Big Tech and quite a bit of Hollywood: https://aomedia.org/about/members/
It’s actually shared patent pool with H265, most big tech companies already license it for the latter, there was some litigation with Snapchat I think regarding AV1. Royalties are for distribution, I assume, so posting AV1 video might be a no-no. I meant to ask if the ‘patented’ stuff is even used when encoding an image. (NB the codec is not patented, nobody claims that afaik, but rather it might be patent encumbered, as in it uses algorithm that might be patented as a part of its design)
So you still have to license it, and it’s not royalty free; if it’s the same patent pool as H265?
I know I had to pay like $1.99 on my synology for H265 support, and likewise for “Advanced Media Extensions” on windows 10/11, although that may have changed.
H.265 actually requires licenses from multiple patent pools, as far as I understand any modern codec is more like a pipeline of transforms than one self contained algorithm so it really matters that someone who is at least really comfortable with signal processing (I’d imagine DSP patent lawyers are very rare) to determine the applicability of that claim to single-frame AVIF.
Hard to say, but possibly less since it's a still image, not a video, so it inherently corresponds only to a part of AV1.
No need to worry about these risks for using it though. You can never say that no patent troll will surface tomorrow for literally anything. That's not a reason not to use things.
AVIF supports multiple frames. It's a good replacement for animated GIFs.
I don't think you need a replacement for them besides actual proper video.
> You can never say that no patent troll will surface tomorrow for literally anything.
Well I guess you can use 20+ year old standards when they exist.
Yeah, but that's a pretty long time for image formats, so it defeats the point.
Yes. It’s just an AV1 container. Doesn’t even need to be limited to a single frame (just like GIF and APNG).
Don't you mean JPEG XL?
JPEG XL vs. AVIF for web use-cases
https://news.ycombinator.com/item?id=50120224
I thought it was pretty well established that JXL has a big room for improvement when it comes to encoders. There are some fundamental limitations wrt the absolute lowest bitrates, but that the room for improvement in encoders is rather substantial, especially with things like rate-distortion search heuristics.
The comparison is more about who has had the most man-hours and megadollars put into encoders quality than about the inherent limitations about the format.
With that said, I use AVIF, but I do have what can be said to be an irrational preference for JXL.
> but I do have what can be said to be an irrational preference for JXL.
Is it irrational to follow the collective "one format to rule them all" dream? Sure, the codec itself needs work, but seeing how long we've been stuck with the JPEG/PNG/GIF trio (even with better encoders like mozjpeg/jpegli or optipng/zopfli) with TIFF as a catch-all backup, getting the format right once and for all really matters.
I'm still weirded by the low amount of workforce in libjxl/jxl-rs; sure, too many cooks do ruin the broth, but too few too, in that domain.
Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format. Mostly for archives where you don't want a lossy translation.
In terms of picture quality for given size, AVIF has it solidly beat.
You could make an argument that we should have AVIF everywhere on the web. But if you want a single image format to be everywhere, I think JPEG-XL is just better suited. AVIF has restrictions on resolutions and number of planes, and doesn't do lossless very well. It's competitive with AVIF on lossy image quality (even though yes, AVIF does seem like it tends to consistently have the advantage there).
Image formats goes in era, and there's no need for monoculture. But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win. Should JPEGXL2 beat it in the future then it can take over for a decade. We seem to essentially have gone through like 4 formats so far: gif, jpg, PNG and webp. On vector side, SVG has no real competition - it's solid.
The author is explicitly arguing for an AVIF monoculture. AVIF isn't an appropriate format for an image format monoculture, but JPEG-XL could be.
"We should use AVIF for most web images" is a different statement which I have no problem with.
> But given we're talking exabytes of data, for this era, the author rightly articulates why AVIF should win.
I'm not sure this is the right conclusion to draw...
1) The author's pain point (use case) is hardware pricing - presuming that goes down (as either AI demands drops/and or production increases), this does not speak to a demand for size, instead, it is about doing more with less...
2) I'm not certain that the exabytes of demand (assuming it comes) will be from AVIF. Rather, if data is important, I think the demand will be a different format entirely (archives, for instance). Demand for more (quality) data might paradoxically call for less compression and less cpu-intensive qualities - uncompressed, raw data, for instance. If is faster and cheaper than bothering with complex algorithms, then simpler formats should be more prevalent.
Building on 1 and 2, a more capable image format, like JPEG-XL, becomes a more logical choice, not the one that can compress the best or is the smallest (in an exa-byte-as-the-norm world).
AVIF supports a higher resolution at 2^32-1 pixels per dimension, vs JPEG-XL's 2^30-1 pixels. But really it doesn't matter since something is going to impose an arbitrarily smaller limit on either before letting you try to allocate more RAM than any computer can address. Yes, plenty of comparison websites confuse AV1 limits (sometimes AV1 profile limits!) with AVIF limits.
For arbitrary planes, AVIF calls them auxiliary images. Unless you mean encoding non-RGB data to start with like how DNG uses JPEG-XL. At which point you're outside the scope of any standard interpretation of JPEG-XL data.
> Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format.
Huh?
JpegXL is the only widely supported format (once it comes to the various browser as is planned) that can store true HDR linear images in floating point (fp16 and fp32) formats.
AVIF can only do 10 bit integer ranges, sure that HDR compared to 8bit but it is not sufficient for useful extended range color spaces.
The format is widely supported, but I'd be very surprised if linear HDR becomes widely supported outside of image editors. JPEG-XR supported fp32 linear HDR way earlier anyway, and no one cared because no one cares about linear HDR after editing.
Also AVIF supports up to 12 bits.
> I'd be very surprised if linear HDR becomes widely supported outside of image editors
I added support to ThreeJS last month because Chrome supports linear Jpeg XL with the experimental flag on. The other browsers are expected to follow:
https://threejs.org/examples/webgpu_loader_jpegxl
I don’t feel like the difference matters all that much. Both AVIF and jpeg xl produce reasonably sized files for your personal photo library. What you really care about is capabilities for things like HDR and expanded color spaces which both formats seem to have excellent support for.
Just about anything is better than jpeg these days.
Agree, though I do miss the clarity of if an image is lossy or lossless just by extension. (Obviously a png could be produced from a heavily compressed jpg, but it is still a handy heuristic in my image pipelines)
Aside from maybe .bmp, that never really existed (though .bmp has palletized colours, I guess?).
Just like you can assume most PNGs to be lossless (despite supporting pallettes, which pngquant uses to "compress" them) and non-animated (despite APNG being over 22 years old), you can assume most AVIF and WebP images are lossy. Same with JXL. HEIF requires a bit of special care (it's only produced by devices with HDR support so your pipeline needs to fit that) but that's pretty much it.
You may get surprised by an accidental, huge lossless AVIF/WebP/HEIF file, but most sources where you can even get these files are all lossy. Unless you recompress your photo library yourself, of course, but then you have full control over the entire process and can decide whether or not you want lossy or lossless.
I think we should come up with a convention for this
> I have already switched to AVIF on every platform I use that supports it, and WebP where AVIF isn't supported.
Where AVIF isn’t supported, I reckon you’re better to fall back to JPEG. Everything supports JPEG, but there are still plenty of things that don’t support WebP. Anything that supports WebP now has indicated it’s open to supporting newer formats than the baseline JPEG/GIF/PNG and is almost certain to support AVIF within a few years.
Hosting providers don't want these formats because they're more cpu-intensive for them to decode and transform (e.g. to make a thumbnail, or when you upload a 4K selfie to be cropped into a 256x256 circle avatar, or a 16 megapixel image of a receipt).
By contrast, if you let the user upload a JPEG or even a PNG, you might pay a slightly-higher cost of the incoming bandwidth, but then you (basically for free) transform the image to the small dimensions and format you actually need, and from there the bandwidth is barely a problem.
Sidenote: End users hate WEBP because nearly any software other than web browsers still don't support even reading it, let alone outputting it (and as you pointed out, anywhere that you "upload an image" they're not welcome either).
In my incredibly shoddy testing sample of 1, my current-macOS device does open AVIFs in Preview, so that's an improvement, at least!
I keep seeing people saying that nothing supports webp, but I've never had any issues opening it. What software do you use that cannot handle webp?
OK, I have to admit, they added webp support to Apple Preview in 2020, but it's been common since long before that, so I formed a memory of its uselessness before that point, and I didn't notice when support was added.
It's still a very small number of programs that support it on the desktop, but at least Preview is working now. So I stand corrected.
I am eagerly awaiting the release of Inkscape 1.5 , as 1.4 doesn't render webps (ymmv depending on OS). Windows Explorer previews of webps are janky but workable. Still I find the efficiency benefits sufficient to pick webp over png (jpeg is not an option if you need transparency).
Absolutely agree, for my photo portfolio website AVIF allows me to serve higher quality photos faster to potential clients.
I’ll just drop my AVIF local support for Wordpress plugin here: https://github.com/ddegner/avif-local-support
> replaces JPEGs on the front-end of WordPress for browsers that support them.
Ouch. Pretty much every browser supports AVIF now which means everyone gets transcoded images worse than JPEGs one uploaded. For JPEG XL that process is lossless...
Note that the ability to repack a JPEG as-is in a JPEG-XL container gives you a 20% filesize reduction due to the more efficient container, but none of the encoding advancements of JPEG-XL.
Recompressing is not great, but many people might be happy with a file that is less than half the size even if they lost a bit of fidelity. Not everyone has original source material to work with after all.
Enough keyframe-based "image" formats, please! The internet and the world at large needs a real and proper modern format, not some quick hacks from bored engineers that only contribute to the endless fragmentation online and do not leverage any existing infrastructure for serving video. There's more than just crappy ultra-low-quality thumbnails around. WebP, AVIF are the webscale equivalent of serving images.
Say more please, what’s up with keyframes?
> Enough keyframe-based "image" formats, please! The internet and the world at large needs a real and proper modern forma
Are you looking for jpeg XL?
> and do not leverage any existing infrastructure for serving video
How would that leveraging work?
> WebP, AVIF are the webscale equivalent of serving images.
This sounds insulting? But they are images on the Web. I have no idea what you mean here.
Do you have a technical argument, or just this bundle of emotions?
not one mention of JXL in the article?
That's how you can tell it's not taking image compression seriously.
Yes, but sites are super slow to enable it.
* https://gitlab.com/gitlab-org/gitlab/-/work_items/428012
* https://github.com/orgs/community/discussions/138164
This article arguments is pretty thin and poor. I would advocate for JPEG XL. Has better compression ratios than webp and older jpegs can be converted lossless to it. Been (re-)added to both Firefox and Chrome.
Yeah why not?
Because whenever I download an image and its webp, the next thing i do is i google "webp to png/jpg" conversation because yeah service XY or Tool Z doesn't support it.
Or my Fire TV Stick :(
I configure my nginx to serve everything available though. Thats what i can do.
You can throw almost any image format with open standards into squoosh.app if you're still using software that doesn't open webp.
It's been a while since Photoshop finally got support, though, I can't recall the last time webp posed a problem for me. Then again I don't use a Firestick, no idea how that would deal with image formats, I guess it's no longer being maintained?
No the firestick reference was for video formats.
H265 for example. Or Dolby Vision.
[dead]
Hacker News engineers on mailing lists, presumably: "I couldn't open this document in my Microsoft Word, anyone else having problems??"
I swear I saw this exact post here on HN last week
As long as we get rid of stuff like HEIC
Maybe a middle out compression is the way to go.
[dead]
Seems about time we have ANOTHER round of serious investigations into collusion in the memory industry artificially driving up prices ...
Can I edit them in gimp? If not, I'll stick to png. Same goes for webp.
I’m editing them in Gimp since forever. I don’t remember when Gimp didn’t support AVIF. Photoshop, on the other hand, was always not working with it. I’m not sure about now, perhaps it does. But that’s telling volumes not about AVIF, but about Adobe quality-driven development. (Sarcasm.)