> libjxl's maximum effort is very slow. It produces files 2–7% smaller than its default for photos, and ~25% smaller for the screenshot and illustration, but takes 9–46 seconds, which is 50–180x as long as its default. jixel gets the same results in a couple of seconds.
libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.
In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).
Having lived through the MP3 era and experienced the many years/decades? that it took for experts across fields to come together and figure out LAME and the bag of parameters that ultimately made it better than most audio formats around it, I would lean towards waiting this one out, and not take any announcement of a "winner" as gospel. We've yet to see the codecs mature and refine for some time.
I also remember the big claims about WebP's superiority, which ended-up in practice, at equivalent file-size, mostly trading away some of the JPEG artifacts that we all know for some unusual new ones.
I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care: image compression seems like a solved problem overall. The second best thing is to come-up with a format that can make the content producers not have to care either, i.e. be the best in class or close-enough in a variety of use-cases (lossy, lossless, fast, animated, hdr, progressive, …). My naive impression was that jxl is mostly interesting in that regard.
Regarding real-world use of WebP - what makes it much worse, in my experience, is that so many web servers are set up to do a lossy conversion to WebP from the original file, most often JPEG (to cut down on bandwidth, or just to satisfy a web speed report originating from Google and therefore pushing Google's technologies). The difference is often very noticeable, e.g. textures smoothed out of existence. Helps to remove WebP from the Accepts header to force servers to serve the original.
It means the technical differences between format, and the real-world choice of which file you want, don't match.
> Helps to remove WebP from the Accepts header to force servers to serve the original.
I have tried doing that with curl/wget but have been unsuccessful, websites still serve webp even when the original URL ends with .jpg or .png... Could you explain how you do it?
you and me are enthusiasts, we love to know about codecs, formats, and we spontaneously seek novelty in this field and engage with it (I have similar stories of amazement about opus, I even went quite deep the rabbit hole of writing a java decoder implementation for it just to study it). But most people won't get nearly that excited, unless a new format magically enables something like twice the compression performance (so people start spreading the word that they can e.g. buy their next smartphone with 128GB storage and not the 256GB version and enjoy the same capabilities). Anything less than that will be a rounding error and barely perceptible, not worthy of the attention, and definitely not of the time to re-process and massively convert prior content.
Another interesting niche is in between JPEG and RAW. RAW files are a pain to deal with, but editing JPEGs can be problematic due to bit depth and whatnot. Personally I just want to shoot pictures and not edit/convert/whatever, but sometimes I have a shot that could benefit from a bit of adjustment, and that's where even large JPEGs have an issue. Bit depth and whatever isn't suitable.
RAW can be it's own entire nasty^nasty rabbit hole. The sorts of stuff that honestly do make me wonder if certain raw formats have their own unique ways of exposing vulnerabilities in accepted ways of implementing.
Things that come to mind are;
- Compressed RAW images. Both the lossless and lossy variants, esp because every manufacturer does their own thing, well except maybe MFT[0], buuuut;
-For MFT, my understanding is that the RAW doesn't just contain some info for LR/C1/DPL[1] or any other sufficiently implemented processing tool to apply correction data (again, I could be wrong, but I think that is something that the Micro 4/3 format does.)
some of the pain of RAW is mitigated with good workflow. shoot RAW+JPEG and when culling, delete the RAWs you won’t edit. keep RAWs for any outstanding shots. that clears up a large proportion of the issues.
JPEG engines are getting better and more configurable (Fuji recipes, LUTs on Panasonic) which makes this workflow more viable.
what i’d love is a good intermediary archival format that is more space efficient than RAW while keeping more editing latitude than a JPEG. using a dynamic preserving tone curve like Log in 14 bits and compressing it losslessly. although i wonder if that would be much better than compressed DNGs.
the main thing with jpeg is adding 10bit would be a breaking change anyway, and storage space on phones gets you 30-40% more photos on the same storage if you change formats.
> For screenshots and illustrations, AVIF is much better than JPEG XL.
Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.
> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.
As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.
My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.
And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.
Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.
>now there are comparisons popping up showing how AVIF actually compresses better.
You perfectly summarise how I felt as well. The revisionist also tries to paint the story as JPEG XL was first banned due to security issues which is again not true.
But that is OK. Since JPEG XL has finally and rightfully won its place, mostly thanks for Safari. We can now hopefully wait for better encoder.
Or even better, participate in improving it. The reference encoder is, I believe, in the libjxl repository[1].
Much of the recent effort seems to be focused on the performance of the Rust version of the decoding library[2], which is quite understandable because of the fresh browser adoption.
I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents
- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) [1] (or 43kB if you need it to work with jxl-rs [2])
- The cat illustration w/ lossless JXL at 255.3kB, when with a better encoder you can get it down to 178kB (30% smaller) [3]
Oh, that explains! I tried AVIF and JXL a few years ago and one of the two took ages to encode (a minute versus <1s for jpeg) to get similar compression ratios, and the other was somewhat reasonable on cpu complexity but significantly worse quality at the same size / much bigger to achieve the same quality as good old jpeg. I ended up concluding that jpeg is still the best for the specific image I was trying to lossily compress, but that was probably just the encoder then
AVIF is fantastic format and I use it in my production applications. Spent quite a bit of time looking to the best settings (at least for up to 2k images) and for anyone interested in converting images to AVIF, here's what I've found to work the best for creating the smallest size (10x+ smaller) while still retaining good quality and even supports PNG transparency:
in my app i was using jpeg but then switched to webp two years ago, they're for generating/displaying thumbnails for images and videos. and now avif seems like a better fit? anything that you're not happy about? considering avif now, appreciate any ideas
If you're working with images that need to be lossless or are simple in color diversity, WEBP is probably still a better choice (though not by a large margin). The biggest issue you might run into with AVIF is legacy support, particularly amongst Apple devices who were slower to implement support for it.
Otherwise the massive size reduction for storage and transfer speeds makes it incredibly attractive for modern web applications.
That F1 image is, in my mind, proof of exactly what is wrong with AVIF. If you look closely the beautiful highlights on the car have been erased and replaced with something plausible. Once you see it you can't unsee it and it boggles my mind that people are still using it as an example.
Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.
I'm looking as closely as I'm able, and I don't see what you mean. (I'm not a car guy, or a photo guy.) What do you mean by highlights? What am I looking for? Reflections?
Look between the Eni and ApeCoin logos. In lossless you can see there are lines from what I assume separate pieces assembled together. Next to ApeCoin there's also a round piece in the lossless version which is missing from the AVIF. JPEG XL loses most of these as well though.
That's what I noticed anyway, not a car or photo guy either.
You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.
This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.
The lossless version is JPEG XL, hence the difference to AVIF.
In Firefox 157.0.1, the right border of the image moves by a pixel or two when I press "hold for lossless" while viewing the AVIF. I think it's the lossy AVIF that's a bit too small.
The benchmark[1] (HN discussion [2]) I read from about 2.5 years ago came to roughly the opposite conclusion. JPEG XL dominated practically all other image formats on compressed size and encoding time.
Superficially, that benchmark and this one seem to be taking similar measurements. They both measure encoded size versus encoding time versus perceptual quality metrics, although they present the data on plots with different axes. I haven't tried to reproduce the results of either, but I have no reason to doubt either benchmark.
I wonder what accounts for the difference. Maybe the libavif encoder got a lot better in the last 2.5 years. The older benchmark uses libjxl v0.10.0 and libavif v1.0.3, while the newer one uses libjxl v0.12.0 and libavif v1.4.2. Or maybe it's the set of images used. The older benchmarks aggregates results for small test sets of images, while the newer benchmark tests individual images. The newer benchmark does find an image where libjxl wins on file size (the weasel), but it still loses on encoding time, whereas in the older benchmark libjxl almost always won on both. Or maybe it's the hardware (M3 Pro vs. M4 Pro).
I've been using AVIF on my blog for a few years. My blog's image corpus is almost entirely videogame screenshots, and I keep the original PNGs so I can re-encode if better encoders release. Despite playing around with JPEGXL every year or so, AVIF images usually looked better (if only a little) at the same file size (vs JPEGXL).
After reading this article, there's something to point to prove I'm not going crazy.
>Animated image formats are dumb and animated JPEG XL is no exception. Video formats are better at video. They're built for it. They're optimised for it. Not just in terms of encoding, but also in terms of playback.
This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.
><video muted autoplay> is right there.
>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.
I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.
Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.
I also didn't know there was a Rust JXL encoder named jixel.[0]
I agree that animated images make sense as a category. But I wish I did get controls on them when opened directly. Being unable to pause a gif leads to very annoying workarounds sometimes.
On macOS, I wanted to be able to paste HDR HEIC screenshots straight into GitHub in Safari and have them get converted automatically to these HDR-capable formats. Normally, when you switch Screenshot.app to HDR, paste to GitHub stops working.
I put together this Hammerspoon spoon with a few brew libraries and some inline Swift code.
Unfortunately for the comparison-focused blog post the comparison widgets is pretty bad - you can't quickly compare 2 reference pictures (original vs AVIF or original vs JXL) at different scalings like here https://web.archive.org/web/20200915201019/https://afontenot...
(also like the BPP size metric that is picture size-independent)
Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard
(also, "hold" is a rather unergonomic action)
Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
JPEG-XL is not the best solution if you want small low-quality images, to reduce your costs for hosting some Web site. AVIF seems appropriate for that goal.
JPEG-XL seems to be the best solution for storing and distributing high-quality images. For myself, I want high-quality images, so JPEG-XL is what matters, both for new images and for compressing the old archives of JPEG images.
While I have my own Web server, it is for private use and not for commercial purposes, so I have no interest in using AVIF to achieve the smallest image sizes, but at a lower quality than I want.
For a wide variety of usecases, not for every isolated usecase. Today, AVIF is better for showing people ads^W^W^W web content delivery. This article is titled “JPEG XL vs. AVIF for web use-cases”. The other article recently discussed¹ is subtitled “Investigating JPEG XL's place as a Web image codec” and ends:
> JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web.
I think many people disliked Google's control of Chrome blocking JPEG XL rather than it being able to compete on its merits.
JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.
Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.
Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?
But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.
And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.
AVIF ( or even AV1 itself ) has had massive increase in quality improvements over the past 6 years. JPEG XL was close to release in 2020 and finalised in 2021. A lot of the sentiments hold true back then.
JPEG XL has always been targeting high quality encoding metric first before the lower end low BPP images, which AV1 excels at with or without the last 6 years of improvements.
The current top comments about MP3 and LAME is again about how encoder extract maximum potential. JPEG XL was may be the best in 2021, but has been fighting for survival since then.
There a lot of different images that JPEG XL encode better. Screenshots with text is known to be not something they have optimised for or think it could be good at. Lossless mode may be better. Edit: As one of the other comment here proved my point.
Had all of these, even just a hint of AVIF improvement be told, may be the sentiments would have been a little different. But then again I am not one who would trust the same people who sold me WebP and AOM roadmaps.
But at least AV2 is coming. And JPEG XL is finally in every browser. Hopefully we can all have something even better in the future.
Your impression is correct; when JPEG XL was first introduced, it did just as well or better than AVIF in many cases. But in short, work on JPEG XL encoders slowed down, so they fell behind, and JPEG XL now loses to AVIF in some areas.
As the article points out, this might change yet again in the future, depending on how much AVIF keeps improving and whether JPEG XL development picks up steam again and how far it’ll go.
I think that near lossless, progressive JPEG XL would work well, once compression algorithms improve. I am _so_ tired of trying to zoom in on a product picture (eg to see what buttons are on a remote or just to read fine print) on E-Stores, only to realize that I need to open in new tab and remove some query paramaters from the URL because they think that people are using 3G but with a computer with a fast CPU (to decode AVIF).
I disagree. Making things slower for everyone due to this edge case is a bad tradeoff. Web APIs exist to let you know when zooming in happens. You can swap to a higher resolution, or even tiled image in these cases if you really care about this use-case.
JPEG transcoding is one of the neatest features of JXL; there is so much existing jpeg out there. Eventually that may be unnecessary, but it's looking like this could already save a significant amount of space for photo archive backups for example.
I've found AVIF to be very effective at screenshots with lossy compression.
Text has lots of edges, hard transitions between bright and dark areas. So text requires lots of high-frequency detail, and JPEG adds a lot ringing as it bounces off all those lines and curves.
AVIF seems to follow contours, so it does a good job with line art.
Otherwise, it's hard to beat the Mozilla JPEG encoder.
JPEG XL can represent lossless images that exceed the limits of human vision. I don't expect it to replace FITS for astronomical images, but the future is weird.
(Super huge thanks to Jake Archibald for the SVGOMG web app. Which is also fantastic for line art.
The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.
Note: Author has worked on the most popular AV1 encoder, seems to be working on his own commercial AV1 encoder, and bases his suggestions on an educated guess. Presumably the authors of JPEG XL had reasons to believe otherwise when introducing JPEG XL.
Not to call into question the article’s author’s expertise, just to point out that they are a single individual and not an authoritative source (which you haven’t implied, but some people might read that way).
Every single webpage I've seen with webp / avif images also had autoplaying videos, intrusive ads, and megabytes of JS. I don't think jxl will change that... What's the point of introducing new image formats that are poorly supported and take longer to encode/decode if you're going to cancel out the space savings anyway?
In full screen mode, the "hold for lossless" version "Firefox help"/"Submit feedback" are not underlined. In inline mode they are. Both modes seem to render a scaled down version of the image, which seems to cause these problems.
I don't get the hype. AVIF is marginally better than WebP which is marginally better than JPG. AVIF is also free, and since it's literally the I-frame of an AV1 stream, it can be decoded directly on the GPU, meaning you don't have to store the decoded picture in memory.
JPEG XL can't be decoded in such a way, and tons of people still use JPG.
Browsers do not use hardware decoding with the exception of Apple for HEIC, and it's implausible any will ever do so for AVIF. Chromium tried to, and never managed for simple lossy WebPs. It'd be limited to a subset of images with a matching profile, have significant overhead for most of those "web-friendly" potato images people make pointless comparisons for, and any implementation would not come without downsides. Nobody is willingly shouldering the cost of dealing with all the broken hardware implementations out there. So it's difficult to see it as a possible advantage.
4:2:0 chroma subsampling might be useful for compatibility. So, sticking with 4:4:4 might or might not be ideal. There are codecs such as H.264, where using 4:4:4 substantially reduces compatibility. Though, there are others like JPEG where it seems fine. Perhaps there are AV1 hardware decoders that only support the AV1 main profile? For the web, there is the HTML picture element where an avif image can be automatically selected by supported browsers and images of other codecs can be used as fallbacks, but maybe it would display wrong and not fall back if avif is supported but 4:4:4 isn't?
Apologies if your comment was meant to be a parody as there's a bit of Poe's law around this stuff…
IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and back losslessly - it's just a container change. That's why it performs so much better, because it's built for motion.
So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)
No. I used to think this too, but it isn't limited to keyframes.You can convert an AV1 MP4 to AVIF and back losslessly - even if it has non-keyframes. It's just a different container. It has the full AV1 capability. Plus transparency.
I'm glad Jake's run the numbers — but do make sure you validate your own use-case rather than just following them. My personal experience has been somewhat different, but also my use-case appears to be pretty different so that's OK.
That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.
A little while ago, I chucked together a comparison game on image file formats (incl a stab at av2 images), encoders, parameters to back out preferences relative to ssimulacra2 and butteraugli: https://aadhar.sh/pixel-peeper
It does seem like AVIFs win on small images, and JXL gives you progressive rendering, easy upgradability on JPEGs, and better lossless and high bitrate images.
Impressive. How can we use AVIF from Java? I have a Java application that relies on ImageMagick, which seems to use libheif for AVIF rather than libavif (avifenc).
There is a partial read-only implementation in native Java.
I'm particularly interested in doing an ImageIO plugin using libxl or the rust version.
In my field, we work with terabytes of JPEG images for archival/preservation of books and archives. Transcoding it to JXL and reading/writing JXL from our software would be a nice improvement.
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video.
What optimizations are being added? I thought it was basically the exact same codec, but different packaging and usually some adjustment to how the encoder is tuned.
I don't have any real use cases for jxl or avif or any other modern format b/c I rarely host images but all these articles are always so interesting to me. And at the end of it, I'm left wondering, is there ever going to be a single winner here?
Jake's interest in F1 hasn't waned, which is good to see. I am presuming that picture of an Alpine/Renault at Goodwood is his 18Mb photo, but I could be wrong. Neither has his interest im image compression waned, which is also good to see. But why the move from Google to Firefox?
I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.
Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.
In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.
It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.
I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.
I am always on Team Hamilton even though I appreciate that he is a little long in the tooth and doing the classic retirement act in a 'stupid red car'.
I am obsessed with SVG and image compression/delivery, and I would like it if you could introduce the concept of an 'SVG sampler' to the world. This is very much inspired by embroidery samplers from the times when women needed to sew.
The point of the sampler is to impress, so as to get the work in, however, it is also a reference, with stitches to copy for lettering, numbers, religious iconography, sock-darning, button-holes and whatever else needs to be repeated.
With an SVG sampler the idea is to use the whole SVG toolkit, filters, masks, clip paths, symbols, views, SMIL, CSS and everything else.
Sure this can be done in Inkscape, however, the goal of the SVG sampler is to make it human drawable. For example, the search icon is a circle and a line, which can be done in a 45Kb export from Illustrator, with the circle defined as a thousand points, specified to NASA numbers.
Or it can be done in ten lines or so of SVG primitives, with the circle and the line using simple two-digit integers. The former is not something that a mere mortal could draw, whereas the latter could be.
Clearly some paths do need to be complex and imported from elsewhere.
SVGOMG will be able to mash the 45Kb Illustrator export into a tenth the size, however, it will not be as concise or as human readable as the 'haiku of the SVG sampler symbol'.
The SVG sampler does not have to be web-optimised, it can max out the CPU for the PC to go full China Syndrome and melt its way through your desk. However, it could be forked, culled of CPU-eater show-stoppers, to just have the icons needed for the next project.
Another way of seeing the SVG sampler idea is 'SVG golf', where you want to strive for maximal 'use' clones, maximal human readability, yet also an insistence on detail such as light/dark mode currentColor things, animating pretty much everything and using the primitives rather than paths, even if the code is longererer according to SVGOMG.
I think that SVG falls within an awkward gap where artworkers don't care for the code with programmers also not caring for the code, because SVG is artworker stuff, not for programmers, right?
In a typical team workflow there is no scope for this to change, the frontend developer is obligated to use the 'assets' churned out by the art worker and the backend developer certainly doesn't care.
Hence, an SVG 'sampler' competition of sorts, with some acknowledgement, could help Firefox win over some developer mindset to FF. Already MDN has the de-facto best documentation for SVG, I probably have a dozen MDN tabs open right now, maybe with all of them on some type of FEconvolve type of feature.
For the sampler, the IDE rather than the graphics program is how it works. Anything with 'sodipodi' type of extra markup can be considered not worthy of being an SVG sampler. Really it has to be a mostly text-only thing, under version control, and not needing CodePen or other. To go with the SVG there needs to be a 'sampler.html' file to show the sampler symbols in 'inline mode' as well as CSS, the favicon and as shown as an 'image' element. Scripting is allowed, but really the goal is to keep everything in the SVG file, to not need huge amounts of extra files.
Ideally comments outside of 'title' and 'description' should not be needed, the author should be able to explain their own code, hence an emphasis on 'defs', sensible id names and descriptive ids.
Since F1 is your thing, you are welcome to give the SVG sampler idea a F1 inspired ethos to it. If you think of the FW14C with the active suspension and whatnot, or the F-duct, DAS and other wonders, then applied that design rigour to SVG, think how good it could be. Added marks for everything good looking, however, there needs to be this solid human-readable underpinnings.
Please do something for SVG at Firefox, to inspire people to get into it rather than assume it is someone else's job. Maybe just have a competition, no prizes needed, with folks able to vote on awesomeness, sophistication, haiku-esque simplicity and how educational a given sampler is.
I see no reason why you can't call yourself 'uncle Bernie', to cosplay as the benevolent dictator that gives out a star prize for an SVG sampler (every time there is an F1 race, rather than monthly, as that would be tedious).
As for AI, Google suggest does offer up SVG code that never works, it gets a duff namespace declaration on line one, dooming any of its concoctions to never open. But where we are going with 'SVG samplers', we don't need no AI robots.
JPEG is fast as fuck, due to it being designed for decades old hardware.
When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.
This is exactly the kind of misunderstanding I worried about in another reply. [1]
AVIF uses the AV1 codec. For the past several years, AV1 has been enjoying a wide interest and a continuous stream of improvements as the best, open, royalty-free video codec around that pretty much everyone had agreed to support from the get go.
JPEG XL started out with a smaller group behind it and took a massive hit when Google decided not to support it in Chrome (and by extension, the entire web, because market share). That made JPEG XL’s future as the universal format very uncertain for a few years. Excitement waned, development slowed down and was further divided to develop a new encoder which Mozilla later said they wanted.
So for a good while, AVIF was steadily improving and approaching its full potential, while JPEG XL was not. The article compares the current state of the current encoders; in no way does it indicate how good the formats themselves are. The article makes note of this. [2] It’s been known for years that JPEG XL compression can still be improved by quite a bit, so I imagine the current encoders are still far from reaching the format’s full potential. (Heck, they don’t even make use of all its features from what I know!) Back when it was first proposed, JPEG XL was very competitive. With interest in the format hopefully renewed, we might see it catch back up with AVIF and overtake it again. Or we might not. We have no way of knowing for sure right now.
Plethora means an excessive amount, so I disagree.
Adding formats to the browser gives us more code to maintain, increases the binary size, and increases the attack surface area. That's why, at Firefox, we insisted on a Rust decoder.
AV1 is not necessarily a better codec for the web. It’s just that its encoders have been continuously improving while those of JPEG XL weren’t seeing much attention, so they fell behind. The format might be better overall, but we won’t know for sure until the encoders catch up.
It'd be interesting to scale this up to a lot of images - and have users blind A/B test, like the LLM Arena on Huggingface which helped filter out "benchmaxxing" vs actual intelligence & utility. Because 1) images can be so diverse* and 2) an intrinsic tradeoff might exist between general efficiency and out-of-distribution robustness.
It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).
* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.
And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.
There was a study done while I was at Google, and I fought for it to be done on high density screens, because that's what most users have. The response was "but people won't be able to see the artifacts" and my head nearly rotated 180 degrees.
But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.
But that is correct and why any proper study should first train the participants on the type of artifacts and trade-offs. Like the reference to JXL choices: think its creator mentioned that AVIF might look nicer for faces because it was "smoothing" them but it was a worse representation of the original. So the study participants would need to be conscious of that trade off and be clear in terms of what they're asked to evaluate - whether the result looks nicer or whether it represents the original better.
Maybe the first step to designing better encoders is to build an extremely accurate visuoperceptual error metric. Seems like ML's rapid progress haven't caught onto it just yet.
For me personally, AVIF is still better, for various
reasons (not solely file size compression ratio as such,
though this is my number one go-to objective; browser
support is also useful but to me is not so important as
it is).
I am keeping a close eye on JPEG-XL, but right now I am
quite settled on .avif. All my local collection is in
.avif, when before it was a mixture of .jpg, .png and
a few animated .gifs. From my findings a few years ago,
avif is superior to jpg, png and gifs on pretty much
everything it matters. On very high compression, though,
I also noticed artefacts, but we had that even more so
with jpg, and for 1:1 comparable file size, avif beats
jpg with both eyes closed.
By the way, great article. I hope he can do another review,
based on that blog entry, in, say 3 years. Would be
interesting to see how avif and jpeg-xl have improved. In
all likelihood I will still keep on using avif, but if
jpeg-xl is a real winner in some areas, I may use it.
(Lossless is one area where jpeg-xl excels, but I don't
need to store satellite data; I want to store old family
pictures in an efficient manner, and here it seems avif
is better.)
What good is a really small file size if small but significant fraction of the people who view the page see nothing at all? I loaded this page and I can read the text and see the plots but none of the example images display.
AVIF is a lifesaver for animation with separate transparency layers so the transparency can change position frame by frame. The only other alternative is WebM which has Safari limitations.
But the performance is so bad it isn't worth using. You're better off encoding a double height AV1 and mashing it together with WebGL https://jakearchibald.com/2024/video-with-transparency/. That's how bad the situation is.
Is there an advantage to this as a separate layer compared to just having an alpha channel baked into the image data itself? If not premultiplied then it would not affect the other channels either.
I think one overlooked aspect is that AVIF is container based. Meaning that once sites support, when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
The container is useless. Files based on a newer codec won't display anyway.
ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.
AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)
I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.
> I think one overlooked aspect is that AVIF is container based.
Many other image formats are. AVIF uses HEIC, the same container that HEIF does.
> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.
This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.
My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
> libjxl's maximum effort is very slow. It produces files 2–7% smaller than its default for photos, and ~25% smaller for the screenshot and illustration, but takes 9–46 seconds, which is 50–180x as long as its default. jixel gets the same results in a couple of seconds.
libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.
In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).
This is awesome. Thanks for sharing
Having lived through the MP3 era and experienced the many years/decades? that it took for experts across fields to come together and figure out LAME and the bag of parameters that ultimately made it better than most audio formats around it, I would lean towards waiting this one out, and not take any announcement of a "winner" as gospel. We've yet to see the codecs mature and refine for some time.
I also remember the big claims about WebP's superiority, which ended-up in practice, at equivalent file-size, mostly trading away some of the JPEG artifacts that we all know for some unusual new ones.
I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care: image compression seems like a solved problem overall. The second best thing is to come-up with a format that can make the content producers not have to care either, i.e. be the best in class or close-enough in a variety of use-cases (lossy, lossless, fast, animated, hdr, progressive, …). My naive impression was that jxl is mostly interesting in that regard.
Regarding real-world use of WebP - what makes it much worse, in my experience, is that so many web servers are set up to do a lossy conversion to WebP from the original file, most often JPEG (to cut down on bandwidth, or just to satisfy a web speed report originating from Google and therefore pushing Google's technologies). The difference is often very noticeable, e.g. textures smoothed out of existence. Helps to remove WebP from the Accepts header to force servers to serve the original.
It means the technical differences between format, and the real-world choice of which file you want, don't match.
Which is a big advantage jpegxl has over avif. You can convert existing jpegs to smaller jpegxls without losing any data.
> Helps to remove WebP from the Accepts header to force servers to serve the original.
I have tried doing that with curl/wget but have been unsuccessful, websites still serve webp even when the original URL ends with .jpg or .png... Could you explain how you do it?
2 replies →
> I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care
What improvement do you think is necessary for people to care?
Genuinely curious. Spoiler link with my answer to avoid any bias: https://lgms.nl/p/cau/?b64&ZVRNb9QwEL0j9T%2BMKqFtpe1Cqcq9qoT...
you and me are enthusiasts, we love to know about codecs, formats, and we spontaneously seek novelty in this field and engage with it (I have similar stories of amazement about opus, I even went quite deep the rabbit hole of writing a java decoder implementation for it just to study it). But most people won't get nearly that excited, unless a new format magically enables something like twice the compression performance (so people start spreading the word that they can e.g. buy their next smartphone with 128GB storage and not the 256GB version and enjoy the same capabilities). Anything less than that will be a rounding error and barely perceptible, not worthy of the attention, and definitely not of the time to re-process and massively convert prior content.
Another interesting niche is in between JPEG and RAW. RAW files are a pain to deal with, but editing JPEGs can be problematic due to bit depth and whatnot. Personally I just want to shoot pictures and not edit/convert/whatever, but sometimes I have a shot that could benefit from a bit of adjustment, and that's where even large JPEGs have an issue. Bit depth and whatever isn't suitable.
> RAW files are a pain to deal with,
RAW can be it's own entire nasty^nasty rabbit hole. The sorts of stuff that honestly do make me wonder if certain raw formats have their own unique ways of exposing vulnerabilities in accepted ways of implementing.
Things that come to mind are;
- Compressed RAW images. Both the lossless and lossy variants, esp because every manufacturer does their own thing, well except maybe MFT[0], buuuut;
-For MFT, my understanding is that the RAW doesn't just contain some info for LR/C1/DPL[1] or any other sufficiently implemented processing tool to apply correction data (again, I could be wrong, but I think that is something that the Micro 4/3 format does.)
[0] - Micro 4/3
[1] Light room, Capture One, DXO PhotoLab (FKA DXO OpticsPro)
1 reply →
some of the pain of RAW is mitigated with good workflow. shoot RAW+JPEG and when culling, delete the RAWs you won’t edit. keep RAWs for any outstanding shots. that clears up a large proportion of the issues.
JPEG engines are getting better and more configurable (Fuji recipes, LUTs on Panasonic) which makes this workflow more viable.
what i’d love is a good intermediary archival format that is more space efficient than RAW while keeping more editing latitude than a JPEG. using a dynamic preserving tone curve like Log in 14 bits and compressing it losslessly. although i wonder if that would be much better than compressed DNGs.
the main thing with jpeg is adding 10bit would be a breaking change anyway, and storage space on phones gets you 30-40% more photos on the same storage if you change formats.
> For screenshots and illustrations, AVIF is much better than JPEG XL.
Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.
> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.
As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.
My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.
And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.
Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.
>now there are comparisons popping up showing how AVIF actually compresses better.
You perfectly summarise how I felt as well. The revisionist also tries to paint the story as JPEG XL was first banned due to security issues which is again not true.
But that is OK. Since JPEG XL has finally and rightfully won its place, mostly thanks for Safari. We can now hopefully wait for better encoder.
> We can now hopefully wait for better encoder.
Or even better, participate in improving it. The reference encoder is, I believe, in the libjxl repository[1].
Much of the recent effort seems to be focused on the performance of the Rust version of the decoding library[2], which is quite understandable because of the fresh browser adoption.
[1] https://github.com/libjxl/libjxl
[2] https://jxl-rs-perf.lucaversari.it/?config=desktop%7Csingle&...
I think people are really forgetting that JXL's encoders are bad right now. For instance, in TFA Jake presents
- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) [1] (or 43kB if you need it to work with jxl-rs [2])
- The cat illustration w/ lossless JXL at 255.3kB, when with a better encoder you can get it down to 178kB (30% smaller) [3]
[1] https://www.linolevan.com/05-screenshot.jxl
[2] https://www.linolevan.com/05-screenshot-web.jxl
[3] https://www.linolevan.com/06-illustration.jxl
Oh, that explains! I tried AVIF and JXL a few years ago and one of the two took ages to encode (a minute versus <1s for jpeg) to get similar compression ratios, and the other was somewhat reasonable on cpu complexity but significantly worse quality at the same size / much bigger to achieve the same quality as good old jpeg. I ended up concluding that jpeg is still the best for the specific image I was trying to lossily compress, but that was probably just the encoder then
Happy to see your version of the cat illustration doesn't come with massive decoder overhead. Are you planning to open source this encoder?
It's just a side project I'm working on with some friends. May release it if it's interesting to folks.
2 replies →
> with a better encoder you can get it down to 178kB
What encoder?
Encoder I’m working on as a side project, not publicly released (but feel free to pull the included files to prove it to yourself)
Yeah, it's very cool that jixel was able to achieve such large efficiency improvements!
This is not jixel though. It was their own encoder
Thank You. I was about to post I suspect both of those images would have worked better with JXL lossless.
Curious what is the better encoder here referring to?
It's an unreleased one. There's a whole section in the article about lossless, which includes data on those images, but not this mystery unreleased encoder https://jakearchibald.com/2026/jpeg-xl-vs-avif/#lossless
AVIF is fantastic format and I use it in my production applications. Spent quite a bit of time looking to the best settings (at least for up to 2k images) and for anyone interested in converting images to AVIF, here's what I've found to work the best for creating the smallest size (10x+ smaller) while still retaining good quality and even supports PNG transparency:
Hmm, I haven't tested this, but I'm deeply sceptical. avifenc is now optimised very well for still images, and you're bypassing all of that here.
These settings have worked very well for me so far, but if you are aware of even better settings, I'd certain like to give it a try.
6 replies →
in my app i was using jpeg but then switched to webp two years ago, they're for generating/displaying thumbnails for images and videos. and now avif seems like a better fit? anything that you're not happy about? considering avif now, appreciate any ideas
If you're working with images that need to be lossless or are simple in color diversity, WEBP is probably still a better choice (though not by a large margin). The biggest issue you might run into with AVIF is legacy support, particularly amongst Apple devices who were slower to implement support for it.
Otherwise the massive size reduction for storage and transfer speeds makes it incredibly attractive for modern web applications.
1 reply →
That F1 image is, in my mind, proof of exactly what is wrong with AVIF. If you look closely the beautiful highlights on the car have been erased and replaced with something plausible. Once you see it you can't unsee it and it boggles my mind that people are still using it as an example.
Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.
Would you be able to circle these highlights? I viewed - https://jakearchibald.com/c/original-CXtAofvc.jpg - https://jakearchibald.com/c/avif-q39-e0-d8-yuv444-ssimu70.4-... at 100% magnification at peeped around for a few minutes but didn't notice anything. Maybe my eyes / monitor is bad...
Look at the fuel cap, the green part of the front wheel, or the vertical frame split behind the fuel cap. AVIF smooth the details out too much.
Oh crap, it's this image
https://jakearchibald.com/2020/avif-has-landed/demos/compare...
I was talking about. He linked another one! Guess people finally realized that one sucks and now they have a new one. I screwed up.
1 reply →
I'm looking as closely as I'm able, and I don't see what you mean. (I'm not a car guy, or a photo guy.) What do you mean by highlights? What am I looking for? Reflections?
Look between the Eni and ApeCoin logos. In lossless you can see there are lines from what I assume separate pieces assembled together. Next to ApeCoin there's also a round piece in the lossless version which is missing from the AVIF. JPEG XL loses most of these as well though.
That's what I noticed anyway, not a car or photo guy either.
3 replies →
I agree fwiw. The only one that looks bad to me is jixel at lower qualities.
OH WAIT. I KNOW WHAT'S HAPPENING HERE.
You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.
This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.
The lossless version is JPEG XL, hence the difference to AVIF.
In Firefox 157.0.1, the right border of the image moves by a pixel or two when I press "hold for lossless" while viewing the AVIF. I think it's the lossy AVIF that's a bit too small.
2 replies →
by the way, why not convert everything to png for comparisons to avoid browser support issues?
7 replies →
I also feel like sometimes the lossless image 'sticks' even after having released the button. Don't know how to reliably test that, though.
The benchmark[1] (HN discussion [2]) I read from about 2.5 years ago came to roughly the opposite conclusion. JPEG XL dominated practically all other image formats on compressed size and encoding time.
Superficially, that benchmark and this one seem to be taking similar measurements. They both measure encoded size versus encoding time versus perceptual quality metrics, although they present the data on plots with different axes. I haven't tried to reproduce the results of either, but I have no reason to doubt either benchmark.
I wonder what accounts for the difference. Maybe the libavif encoder got a lot better in the last 2.5 years. The older benchmark uses libjxl v0.10.0 and libavif v1.0.3, while the newer one uses libjxl v0.12.0 and libavif v1.4.2. Or maybe it's the set of images used. The older benchmarks aggregates results for small test sets of images, while the newer benchmark tests individual images. The newer benchmark does find an image where libjxl wins on file size (the weasel), but it still loses on encoding time, whereas in the older benchmark libjxl almost always won on both. Or maybe it's the hardware (M3 Pro vs. M4 Pro).
[1]: https://news.ycombinator.com/item?id=39559281
The Cloudinary one is written by one of the leads of the JPEG XL project.
I've been using AVIF on my blog for a few years. My blog's image corpus is almost entirely videogame screenshots, and I keep the original PNGs so I can re-encode if better encoders release. Despite playing around with JPEGXL every year or so, AVIF images usually looked better (if only a little) at the same file size (vs JPEGXL).
After reading this article, there's something to point to prove I'm not going crazy.
>Animated image formats are dumb and animated JPEG XL is no exception. Video formats are better at video. They're built for it. They're optimised for it. Not just in terms of encoding, but also in terms of playback.
This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.
><video muted autoplay> is right there.
>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.
I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.
Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.
I also didn't know there was a Rust JXL encoder named jixel.[0]
[0] https://github.com/awxkee/jixel
AVIF doesn't work that great either. Let's just switch to AV1 video. AVIF animated still really buggy compared to the video itself
I agree that animated images make sense as a category. But I wish I did get controls on them when opened directly. Being unable to pause a gif leads to very annoying workarounds sometimes.
nit: another rust ENCoder, not DE
Though given the lagging speed in decoding, is there a faster tying JXL decoder planned?
jxl-rs is rust (used in Firefox and Chrome), and already faster than libjxl (used in Safari).
Fixed that, thanks!
On macOS, I wanted to be able to paste HDR HEIC screenshots straight into GitHub in Safari and have them get converted automatically to these HDR-capable formats. Normally, when you switch Screenshot.app to HDR, paste to GitHub stops working.
I put together this Hammerspoon spoon with a few brew libraries and some inline Swift code.
You paste twice quickly to trigger it, and you can iterate formats with a keystroke. https://gist.github.com/thadk/8b178aa93dafcab92ca579825f8191...
Unfortunately for the comparison-focused blog post the comparison widgets is pretty bad - you can't quickly compare 2 reference pictures (original vs AVIF or original vs JXL) at different scalings like here https://web.archive.org/web/20200915201019/https://afontenot...
(also like the BPP size metric that is picture size-independent)
Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard (also, "hold" is a rather unergonomic action)
Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up
For a moment I was sad the original comparison page was gone. It turns out it is still online under the developer's new GitHub username: https://lmfont.github.io/image-formats-comparison/#abandoned....
Thanks! Was also sad, but it's "just" linkrot, will update bookmarks
Offering different scalings is pointless because they're designed for a single largest size.
But they won't be viewed at different sizes? But even then, the point is in making detection of artifacts easier
1 reply →
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
JPEG-XL is not the best solution if you want small low-quality images, to reduce your costs for hosting some Web site. AVIF seems appropriate for that goal.
JPEG-XL seems to be the best solution for storing and distributing high-quality images. For myself, I want high-quality images, so JPEG-XL is what matters, both for new images and for compressing the old archives of JPEG images.
While I have my own Web server, it is for private use and not for commercial purposes, so I have no interest in using AVIF to achieve the smallest image sizes, but at a lower quality than I want.
Please read the article. All of the comparisons default to "high" quality, according to JXL's own metric.
8 replies →
> for a wide variety of usecases
For a wide variety of usecases, not for every isolated usecase. Today, AVIF is better for showing people ads^W^W^W web content delivery. This article is titled “JPEG XL vs. AVIF for web use-cases”. The other article recently discussed¹ is subtitled “Investigating JPEG XL's place as a Web image codec” and ends:
> JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web.
¹ https://news.ycombinator.com/item?id=49690554
(Either way, can we agree to take webp out behind the barn?)
I think many people disliked Google's control of Chrome blocking JPEG XL rather than it being able to compete on its merits.
JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.
Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.
Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?
But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.
And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.
> AVIF images have a max size of 8192x4352
This isn't true btw. The format supports up to 64k x 64k, although browser decoders currently fail beyond 16k x 16k.
Not sure when you'd serve something like that on a web page though.
3 replies →
JPEG-XL can be a quick win since it is possible to do a transcode of all of your existing ('classic') JPEG files with zero (visual) losses in quality.
I always think of transcode and lossless as opposites. How is this achieved in this format?
1 reply →
If you're transcoding why wont you go to avif or another one? If jpeg -> jpeg-xl uniquely better?
2 replies →
Claims around JPEG XL have always been wild. E.g. this from one of the creators https://x.com/jyzg/status/1592811472073416704
That's.. horrific. How can someone be this out of touch?
1 reply →
AVIF ( or even AV1 itself ) has had massive increase in quality improvements over the past 6 years. JPEG XL was close to release in 2020 and finalised in 2021. A lot of the sentiments hold true back then.
JPEG XL has always been targeting high quality encoding metric first before the lower end low BPP images, which AV1 excels at with or without the last 6 years of improvements.
The current top comments about MP3 and LAME is again about how encoder extract maximum potential. JPEG XL was may be the best in 2021, but has been fighting for survival since then.
There a lot of different images that JPEG XL encode better. Screenshots with text is known to be not something they have optimised for or think it could be good at. Lossless mode may be better. Edit: As one of the other comment here proved my point.
Had all of these, even just a hint of AVIF improvement be told, may be the sentiments would have been a little different. But then again I am not one who would trust the same people who sold me WebP and AOM roadmaps.
But at least AV2 is coming. And JPEG XL is finally in every browser. Hopefully we can all have something even better in the future.
so you fell for jxl propaganda. everybody who work with images for a living, knows that jxl has always been shit compared to avif.
Your impression is correct; when JPEG XL was first introduced, it did just as well or better than AVIF in many cases. But in short, work on JPEG XL encoders slowed down, so they fell behind, and JPEG XL now loses to AVIF in some areas.
As the article points out, this might change yet again in the future, depending on how much AVIF keeps improving and whether JPEG XL development picks up steam again and how far it’ll go.
I think that near lossless, progressive JPEG XL would work well, once compression algorithms improve. I am _so_ tired of trying to zoom in on a product picture (eg to see what buttons are on a remote or just to read fine print) on E-Stores, only to realize that I need to open in new tab and remove some query paramaters from the URL because they think that people are using 3G but with a computer with a fast CPU (to decode AVIF).
I disagree. Making things slower for everyone due to this edge case is a bad tradeoff. Web APIs exist to let you know when zooming in happens. You can swap to a higher resolution, or even tiled image in these cases if you really care about this use-case.
JPEG transcoding is one of the neatest features of JXL; there is so much existing jpeg out there. Eventually that may be unnecessary, but it's looking like this could already save a significant amount of space for photo archive backups for example.
That's just by changing the entropy coder and retaining the DCT coefficients. The idea is similar to Dropbox's Lepton. https://dropbox.tech/infrastructure/lepton-image-compression...
The main difference being that Lepton is worse and 100x slower.
8 replies →
I've found AVIF to be very effective at screenshots with lossy compression.
Text has lots of edges, hard transitions between bright and dark areas. So text requires lots of high-frequency detail, and JPEG adds a lot ringing as it bounces off all those lines and curves.
AVIF seems to follow contours, so it does a good job with line art.
Otherwise, it's hard to beat the Mozilla JPEG encoder.
JPEG XL can represent lossless images that exceed the limits of human vision. I don't expect it to replace FITS for astronomical images, but the future is weird.
(Super huge thanks to Jake Archibald for the SVGOMG web app. Which is also fantastic for line art.
https://jakearchibald.github.io/svgomg/
Squoosh is a web app front end to various image encoders
https://squoosh.app
)
JXL encoder is just very unoptimized, so lossy screenshot is currently pretty bad
The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.
https://giannirosato.com/blog/post/case-against-jxl/ suggests JXL is fundamentally limited. We'll see. There's a race on and it's great!
Note: Author has worked on the most popular AV1 encoder, seems to be working on his own commercial AV1 encoder, and bases his suggestions on an educated guess. Presumably the authors of JPEG XL had reasons to believe otherwise when introducing JPEG XL.
Not to call into question the article’s author’s expertise, just to point out that they are a single individual and not an authoritative source (which you haven’t implied, but some people might read that way).
[flagged]
AVIF/AV1 has patent trolls targeting it, an issue JPEGXL doesn't have, yet.
Every single webpage I've seen with webp / avif images also had autoplaying videos, intrusive ads, and megabytes of JS. I don't think jxl will change that... What's the point of introducing new image formats that are poorly supported and take longer to encode/decode if you're going to cancel out the space savings anyway?
I use JXL/AVIF/WEBP images on my website and don’t have videos, ads or unnecessary JavaScript.
Ditto
https://jakearchibald.com/2026/jpeg-xl-vs-avif/#lossy---scre...
In full screen mode, the "hold for lossless" version "Firefox help"/"Submit feedback" are not underlined. In inline mode they are. Both modes seem to render a scaled down version of the image, which seems to cause these problems.
Great article!
Overall I am getting that AVIF is better on the web...unless Lossless is needed, in that case better take JPEGXL.
I don't get the hype. AVIF is marginally better than WebP which is marginally better than JPG. AVIF is also free, and since it's literally the I-frame of an AV1 stream, it can be decoded directly on the GPU, meaning you don't have to store the decoded picture in memory.
JPEG XL can't be decoded in such a way, and tons of people still use JPG.
Browsers do not use hardware decoding with the exception of Apple for HEIC, and it's implausible any will ever do so for AVIF. Chromium tried to, and never managed for simple lossy WebPs. It'd be limited to a subset of images with a matching profile, have significant overhead for most of those "web-friendly" potato images people make pointless comparisons for, and any implementation would not come without downsides. Nobody is willingly shouldering the cost of dealing with all the broken hardware implementations out there. So it's difficult to see it as a possible advantage.
4:2:0 chroma subsampling might be useful for compatibility. So, sticking with 4:4:4 might or might not be ideal. There are codecs such as H.264, where using 4:4:4 substantially reduces compatibility. Though, there are others like JPEG where it seems fine. Perhaps there are AV1 hardware decoders that only support the AV1 main profile? For the web, there is the HTML picture element where an avif image can be automatically selected by supported browsers and images of other codecs can be used as fallbacks, but maybe it would display wrong and not fall back if avif is supported but 4:4:4 isn't?
I'm not aware of any browser that cannot render AVIF 4:4:4. Given that avifenc outputs 4:4:4 by default, I don't expect that to change.
Perhaps useful:
* https://caniuse.com/?search=avif
* https://caniuse.com/?search=jpegxl
Note about caniuse: browsers dragged their feet with jpegxl while avif had the backing of the biggest browser in existence: internet explorer
Apologies if your comment was meant to be a parody as there's a bit of Poe's law around this stuff…
IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.
1 reply →
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and back losslessly - it's just a container change. That's why it performs so much better, because it's built for motion.
So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)
No. I used to think this too, but it isn't limited to keyframes.You can convert an AV1 MP4 to AVIF and back losslessly - even if it has non-keyframes. It's just a different container. It has the full AV1 capability. Plus transparency.
I'm glad Jake's run the numbers — but do make sure you validate your own use-case rather than just following them. My personal experience has been somewhat different, but also my use-case appears to be pretty different so that's OK.
That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.
A little while ago, I chucked together a comparison game on image file formats (incl a stab at av2 images), encoders, parameters to back out preferences relative to ssimulacra2 and butteraugli: https://aadhar.sh/pixel-peeper
It does seem like AVIFs win on small images, and JXL gives you progressive rendering, easy upgradability on JPEGs, and better lossless and high bitrate images.
Note that progressive rendering is now supported by avif, and the comparison in the OPs post makes is appear quite a lot better.
It does sound like the remaining areas jpegxl is better at are almost all non-web use cases.
> The interesting detail of animated AVIF is that it supports transparency, whereas AV1 video doesn't
Amazing.
Impressive. How can we use AVIF from Java? I have a Java application that relies on ImageMagick, which seems to use libheif for AVIF rather than libavif (avifenc).
There is a partial read-only implementation in native Java. I'm particularly interested in doing an ImageIO plugin using libxl or the rust version. In my field, we work with terabytes of JPEG images for archival/preservation of books and archives. Transcoding it to JXL and reading/writing JXL from our software would be a nice improvement.
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video.
What optimizations are being added? I thought it was basically the exact same codec, but different packaging and usually some adjustment to how the encoder is tuned.
tune=iq is the main bit https://aomedia.org/blog%20posts/Libavif_v1_4_0-Boasts-Major...
I don't have any real use cases for jxl or avif or any other modern format b/c I rarely host images but all these articles are always so interesting to me. And at the end of it, I'm left wondering, is there ever going to be a single winner here?
Are inline AV1 as well supported by browsers as animated AVIF?
Jake's interest in F1 hasn't waned, which is good to see. I am presuming that picture of an Alpine/Renault at Goodwood is his 18Mb photo, but I could be wrong. Neither has his interest im image compression waned, which is also good to see. But why the move from Google to Firefox?
I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.
Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.
In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.
It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.
Yep, Alpine, and yep, Goodwood! Nicely done!
I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.
Team and driver for in 2026?
I am always on Team Hamilton even though I appreciate that he is a little long in the tooth and doing the classic retirement act in a 'stupid red car'.
I am obsessed with SVG and image compression/delivery, and I would like it if you could introduce the concept of an 'SVG sampler' to the world. This is very much inspired by embroidery samplers from the times when women needed to sew.
The point of the sampler is to impress, so as to get the work in, however, it is also a reference, with stitches to copy for lettering, numbers, religious iconography, sock-darning, button-holes and whatever else needs to be repeated.
With an SVG sampler the idea is to use the whole SVG toolkit, filters, masks, clip paths, symbols, views, SMIL, CSS and everything else.
Sure this can be done in Inkscape, however, the goal of the SVG sampler is to make it human drawable. For example, the search icon is a circle and a line, which can be done in a 45Kb export from Illustrator, with the circle defined as a thousand points, specified to NASA numbers.
Or it can be done in ten lines or so of SVG primitives, with the circle and the line using simple two-digit integers. The former is not something that a mere mortal could draw, whereas the latter could be.
Clearly some paths do need to be complex and imported from elsewhere.
SVGOMG will be able to mash the 45Kb Illustrator export into a tenth the size, however, it will not be as concise or as human readable as the 'haiku of the SVG sampler symbol'.
The SVG sampler does not have to be web-optimised, it can max out the CPU for the PC to go full China Syndrome and melt its way through your desk. However, it could be forked, culled of CPU-eater show-stoppers, to just have the icons needed for the next project.
Another way of seeing the SVG sampler idea is 'SVG golf', where you want to strive for maximal 'use' clones, maximal human readability, yet also an insistence on detail such as light/dark mode currentColor things, animating pretty much everything and using the primitives rather than paths, even if the code is longererer according to SVGOMG.
I think that SVG falls within an awkward gap where artworkers don't care for the code with programmers also not caring for the code, because SVG is artworker stuff, not for programmers, right?
In a typical team workflow there is no scope for this to change, the frontend developer is obligated to use the 'assets' churned out by the art worker and the backend developer certainly doesn't care.
Hence, an SVG 'sampler' competition of sorts, with some acknowledgement, could help Firefox win over some developer mindset to FF. Already MDN has the de-facto best documentation for SVG, I probably have a dozen MDN tabs open right now, maybe with all of them on some type of FEconvolve type of feature.
For the sampler, the IDE rather than the graphics program is how it works. Anything with 'sodipodi' type of extra markup can be considered not worthy of being an SVG sampler. Really it has to be a mostly text-only thing, under version control, and not needing CodePen or other. To go with the SVG there needs to be a 'sampler.html' file to show the sampler symbols in 'inline mode' as well as CSS, the favicon and as shown as an 'image' element. Scripting is allowed, but really the goal is to keep everything in the SVG file, to not need huge amounts of extra files.
Ideally comments outside of 'title' and 'description' should not be needed, the author should be able to explain their own code, hence an emphasis on 'defs', sensible id names and descriptive ids.
Since F1 is your thing, you are welcome to give the SVG sampler idea a F1 inspired ethos to it. If you think of the FW14C with the active suspension and whatnot, or the F-duct, DAS and other wonders, then applied that design rigour to SVG, think how good it could be. Added marks for everything good looking, however, there needs to be this solid human-readable underpinnings.
Please do something for SVG at Firefox, to inspire people to get into it rather than assume it is someone else's job. Maybe just have a competition, no prizes needed, with folks able to vote on awesomeness, sophistication, haiku-esque simplicity and how educational a given sampler is.
I see no reason why you can't call yourself 'uncle Bernie', to cosplay as the benevolent dictator that gives out a star prize for an SVG sampler (every time there is an F1 race, rather than monthly, as that would be tedious).
As for AI, Google suggest does offer up SVG code that never works, it gets a duff namespace declaration on line one, dooming any of its concoctions to never open. But where we are going with 'SVG samplers', we don't need no AI robots.
1. How long does size, encode time and resize take compared to good old jpeg?
2. Is it possible to encode AVIF with hardware acceleration?
JPEG is fast as fuck, due to it being designed for decades old hardware.
When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.
To be honest it's starting to sound like Google were right and adding JPEG XL support was a mistake.
This is exactly the kind of misunderstanding I worried about in another reply. [1]
AVIF uses the AV1 codec. For the past several years, AV1 has been enjoying a wide interest and a continuous stream of improvements as the best, open, royalty-free video codec around that pretty much everyone had agreed to support from the get go.
JPEG XL started out with a smaller group behind it and took a massive hit when Google decided not to support it in Chrome (and by extension, the entire web, because market share). That made JPEG XL’s future as the universal format very uncertain for a few years. Excitement waned, development slowed down and was further divided to develop a new encoder which Mozilla later said they wanted.
So for a good while, AVIF was steadily improving and approaching its full potential, while JPEG XL was not. The article compares the current state of the current encoders; in no way does it indicate how good the formats themselves are. The article makes note of this. [2] It’s been known for years that JPEG XL compression can still be improved by quite a bit, so I imagine the current encoders are still far from reaching the format’s full potential. (Heck, they don’t even make use of all its features from what I know!) Back when it was first proposed, JPEG XL was very competitive. With interest in the format hopefully renewed, we might see it catch back up with AVIF and overtake it again. Or we might not. We have no way of knowing for sure right now.
It seems pdf chose jpegxl, so they would have shipped with a decoder regardless. But, yeah.
WHy? Browsers should have supported plethora of formats!
Plethora means an excessive amount, so I disagree.
Adding formats to the browser gives us more code to maintain, increases the binary size, and increases the attack surface area. That's why, at Firefox, we insisted on a Rust decoder.
3 replies →
I really hope that some day Firefox supports HDR AVIF images
It's not AVIF that's the issue, the blocker is supporting HDR in general.
Fair point. HDR images in Firefox just do not work at all, regardless of the format.
Ah, Chrome ships JXL when we already have a better codec for the web!
AV1 is not necessarily a better codec for the web. It’s just that its encoders have been continuously improving while those of JPEG XL weren’t seeing much attention, so they fell behind. The format might be better overall, but we won’t know for sure until the encoders catch up.
PDF standardized on JPEG XL, and Chrome ships with a PDF renderer.
It'd be interesting to scale this up to a lot of images - and have users blind A/B test, like the LLM Arena on Huggingface which helped filter out "benchmaxxing" vs actual intelligence & utility. Because 1) images can be so diverse* and 2) an intrinsic tradeoff might exist between general efficiency and out-of-distribution robustness.
It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).
* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.
And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.
There was a large scale study a while back: https://cloudinary.com/blog/contemplating-codec-comparisons
That was done before AVIF had any improvements. Arguably one could even say JPEG XL competition brought the best of AVIF out.
1 reply →
There was a study done while I was at Google, and I fought for it to be done on high density screens, because that's what most users have. The response was "but people won't be able to see the artifacts" and my head nearly rotated 180 degrees.
But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.
> but people won't be able to see the artifacts
But that is correct and why any proper study should first train the participants on the type of artifacts and trade-offs. Like the reference to JXL choices: think its creator mentioned that AVIF might look nicer for faces because it was "smoothing" them but it was a worse representation of the original. So the study participants would need to be conscious of that trade off and be clear in terms of what they're asked to evaluate - whether the result looks nicer or whether it represents the original better.
2 replies →
I feel that!
Maybe the first step to designing better encoders is to build an extremely accurate visuoperceptual error metric. Seems like ML's rapid progress haven't caught onto it just yet.
2 replies →
Some days ago we had a similar discussion here.
For me personally, AVIF is still better, for various reasons (not solely file size compression ratio as such, though this is my number one go-to objective; browser support is also useful but to me is not so important as it is).
I am keeping a close eye on JPEG-XL, but right now I am quite settled on .avif. All my local collection is in .avif, when before it was a mixture of .jpg, .png and a few animated .gifs. From my findings a few years ago, avif is superior to jpg, png and gifs on pretty much everything it matters. On very high compression, though, I also noticed artefacts, but we had that even more so with jpg, and for 1:1 comparable file size, avif beats jpg with both eyes closed.
By the way, great article. I hope he can do another review, based on that blog entry, in, say 3 years. Would be interesting to see how avif and jpeg-xl have improved. In all likelihood I will still keep on using avif, but if jpeg-xl is a real winner in some areas, I may use it. (Lossless is one area where jpeg-xl excels, but I don't need to store satellite data; I want to store old family pictures in an efficient manner, and here it seems avif is better.)
What good is a really small file size if small but significant fraction of the people who view the page see nothing at all? I loaded this page and I can read the text and see the plots but none of the example images display.
What are you viewing with?
AVIF is a lifesaver for animation with separate transparency layers so the transparency can change position frame by frame. The only other alternative is WebM which has Safari limitations.
But the performance is so bad it isn't worth using. You're better off encoding a double height AV1 and mashing it together with WebGL https://jakearchibald.com/2024/video-with-transparency/. That's how bad the situation is.
Is there an advantage to this as a separate layer compared to just having an alpha channel baked into the image data itself? If not premultiplied then it would not affect the other channels either.
Most of these images are not at 100%. Use large images and show 100% crops everywhere.
You're mistaking CSS pixels for device pixels https://jakearchibald.com/2021/serving-sharp-images-to-high-...
nop
I think one overlooked aspect is that AVIF is container based. Meaning that once sites support, when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
The container is useless. Files based on a newer codec won't display anyway.
ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.
AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)
I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.
> I think one overlooked aspect is that AVIF is container based.
Many other image formats are. AVIF uses HEIC, the same container that HEIF does.
> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.
https://github.com/AOMediaCodec/av2-isobmff
This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.
I don't think so. WebM doesn't need new content type and it can ship AV1 and VP9 all the same.
4 replies →
Can someone please explain the downvotes?
My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
3 replies →
What? Stick to simple PNG. It is simple, runtime and SDK, beyond good enough and has 16bits per color component support (which webp does not have).
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]