A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.
Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!
"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."
This is a good paragraph. I see people forget to apply that last sentence all the time.
Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization.
GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth).
The new formats are interesting webp, avif, JXL and so on.
Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling!
Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
Not to mention if you for some odd reason wanted to do gif-style animations, you can also do it with apng or webp. You shouldn't, real video format makes more sense, but even if you did there is still no reason to use gif.
I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG.
That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.
It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.
When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.
I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.
In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).
> People like to pretend AV1 got infinite resources
I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.
I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?
I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.
Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.
I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.
We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.
As the saying goes: Never fall in love with potential.
Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
Most people using dedicated cameras shoot in RAW, then use a program to process and export the photos afterwards. So camera manufacturer buy-in isn't super important.
I've been exporting in JXL from Lightroom for a little while now, you get slightly smaller image sizes and HDR with no real downsides. On the web I imagine this will translate to higher quality images on social media since platforms can get more out of the same file size. It will also likely be the end of HEIF which is a pain to deal with due to patents.
The second paragraph doesn’t follow from my question, because it assumes JPEG XL does become useful on the web. The author believes AVIF is too far ahead already.
I suspect the name alone will help drive adoption, especially from non-technical people. Heck, I'm reasonably technical myself (but not expert in image formats) and my first instinct on encountering AVIF was to say "AVIF? Does that stand for AVI File?" And I would have assumed that it's a video format, not an image format. Whereas JPEG XL would have everyone who has ever used a digital camera saying "Ah, it's got JPEG in the name, that means it's a photo format".
Never underestimate the power of a well-known brand name in communicating things to people who know nothing else about the subject. The name is a big part of why I suspect JPEG XL will take off in popularity. (The lossless conversion to and from classic JPEG format is the other main reason).
> If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web".
The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.
Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?
I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.
In the post, I say "I think WebP was a bit too narrowly scoped"
This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.
Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.
How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images.
For every other image encoder I used I couldn't find one setting that would make compact, high-quality images across the gamut of inputs (e.g. things like comics that have extremely visible high-frequency content would look terrible at quality settings that looked good for many photographs).
Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental.
I can accept a claim that JPEG-XL is not the best format for it, or that it is good, but not worth the complexity and extra surface area it introduces. I can not accept a claim that "lossless just isn't very useful on the web".
I think its correct to say a use case that is very niche on the web isn't super important to the web. Especially when there already exists a bunch of lossless formats. After all, the value proposition of jxl is to save some bytes. It would be different if the point was introducing images as a whole.
It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
SVT-AV1 is also more than just open source in name only; development and discussions happen in the open; with many community forks that’s now getting upstreamed/merged.
It is a true open source project; not just an open source license.
SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.
I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.
x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics.
those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?
The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.
Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.
If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"
So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.
None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.
> I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases.
Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet.
So the major web browsers will support JPEG XL later this fall.
> But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.
I'm not even personally convinced it is useful for cameras. Sally's situation isn't particularly bandwidth or feature-constrained, so JPEG or PNG work. Maybe JXL is solving problems that don't exist?
HDR is something many photography enthusiasts are interested in, and the ability to losslessly transcode from JPEG to JPEG XL (and back again if you have to) is actually IMHO the "killer app" for the format. Many people have years of irreplaceable family photos in JPEG format, and being told "you can fit 30% more photos on the same hard disk without any loss of quality" would certainly sell me on converting my photo library to JPEG XL. (The jpegxl.com site says "up to 60% smaller" so I'm going to guess that 30% is a safe average gain and it might be more).
And nearly everyone who takes photos of their family ends storage-constrained on cameras at some point. Memory cards only holding so much is less of an issue than it used to be, but in my experience the only people with laptops that have more than 1 TB of disk space are the computer professionals I know; every non-computer professional I personally know has 1 TB or less, usually 512 GB. That's room for plenty of photos, but not an infinite amount, and the photo collection (plus videos of baby's first steps and so on) is competing with a lot of other things for storage space. So being able to shrink the collection size by 30% or more with no artifacting added is definitely going to be worth it for one of the biggest selling points for cameras. (Including the cameras on smartphones).
I wouldn't say that JXL is absolutely vital and the industry should switch right now. But I would say that it's likely to be the only image format that has a chance to displace JPEG among the average camera user. Having JPEG in the name is also going to be a major selling point; don't underestimate that. (And the JPEG <-> JPEG XL conversion being lossless will complete the selling point).
Since (if I'm right) it's going to end up ubiquitous, then even if another format would be technically better, it would be wise for everyone writing software that handles images — browsers, OS file explorers, and so on — to make sure their software can support it. Just on general principles of supporting every widely-used format and every format that looks likely to be widely-used in the future.
I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:
> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.
It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.
We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?
There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included).
Source: I lead Mozilla's technical contributions to AV1.
HEIF isn't an Apple owned format, most modern cameras have it as an option alongside JPEG now. The situation is JPEG is woefully outdated, lacking in HDR support and dated compression. HEIF is technically much better but patent encumbered.
JPEG-XL offers all the benefits of HEIF and more, while not being patent encumbered.
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.
This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.
Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".
In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.
Hope this helps clarify how progressive AVIF actually works under the hood.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.
You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.
Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.
Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.
Yes, if you look at the demo, the "progressive" AVIF loads a visible image at 8.5KB, and at that point, it looks better than the progressive JXL. However, that is ALL the AVIF shows until the image has fully loaded. At around 98KB, the JXL looks significantly better, and at around 240KB already looks really close to the final image, while the AVIF still looks terrible. At 280KB when the AVIF finally loads, they look identical.
I prefer the UX of the AVIF example here. I think it's better to have a progressive phase where the image is obviously "not ready", yet you can still determine important details like the subject of the image (unlike a blurhash), rather than a phase that you could mistake for complete, but looks bad in parts.
BTW, you can configure the AVIF encoder to have another in-between pass or two so the quality jump isn't as big. The JXL folks just happened to go with only two total passes.
Thanks to AV1's inter encoding, overhead is overall minimal as each pass can refine on previous ones. Think of it as a mini-video. Because of this, in the case of images with a lot of repeated patterns, progressive AVIF encoding can actually result in more efficient images!
Looking at the demo linked in the blog post, I can make a similar quality thumbnail for a smaller size than the delta between the static and progressive AVIFs
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.
The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.
Of course it does, with one you have to render twice and store two layers which costs you both compute and storage. With the other you can just take the image mid decode at a point and display it. Single decode operation, no layer mess.
You have to render twice and have 2 different layers in both scenarios. Writing to a buffer / layer is not an atomic operation so they need to be separated.
The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image.
If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
How does progressive rendering actually that most OS GUIS are not multithreaded ?
The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.
Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
You should never transcode lossy source files because there is generation loss in quality.
There is still a lot of reason for Apple to switch from HEIC to JXL for photos going forward since HEIC is patent encumbered so it will never see widespread use.
Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.
A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.
Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!
"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."
This is a good paragraph. I see people forget to apply that last sentence all the time.
Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization.
GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth).
The new formats are interesting webp, avif, JXL and so on.
Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling!
It's magic and it puts food on my table.
Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
Not to mention if you for some odd reason wanted to do gif-style animations, you can also do it with apng or webp. You shouldn't, real video format makes more sense, but even if you did there is still no reason to use gif.
Precisely. Kind of reminds me of "Hoover" or "Kleenex". Coca cola even. It has brand equity which means it's not going away any time soon.
> PNG, the lossless format is great for diagrams and stuff with sharp edges.
But also pointless when lossless WebP exists and is supported everywhere. Lossy WebP does not make as much sense though since jpegli entered the game.
OP has made https://halide.cx/iris/ which could make WebP make sense, but it's not open source or generally available.
Jpg, does not do text well, at its regular file size.And somewhat related it has no alpha channel.
I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG.
That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
Raw isn’t an image though, it’s pre-image. And we have an open raw format already. DNF I think. With pretty decent adoption.
True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
it's even flexible enough to represent images pre de-bayering
That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.
It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.
When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.
I wonder if similar hacks apply to zlib and .png as well.
Zip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html
You can also have a zip that decompresses to itself: https://research.swtch.com/zip
I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.
In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
> It is getting its try, actively, in libjxl.
That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).
> People like to pretend AV1 got infinite resources
I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.
I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?
I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.
Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.
I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.
> It won’t be know until it’s been tried
We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.
As the saying goes: Never fall in love with potential.
Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
Lossy Modular isn't efficient enough to compete with even JPEG.
Also, look at the graphs – Iris-WebP beats JPEG XL.
If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
Most people using dedicated cameras shoot in RAW, then use a program to process and export the photos afterwards. So camera manufacturer buy-in isn't super important.
I've been exporting in JXL from Lightroom for a little while now, you get slightly smaller image sizes and HDR with no real downsides. On the web I imagine this will translate to higher quality images on social media since platforms can get more out of the same file size. It will also likely be the end of HEIF which is a pain to deal with due to patents.
The second paragraph doesn’t follow from my question, because it assumes JPEG XL does become useful on the web. The author believes AVIF is too far ahead already.
I suspect the name alone will help drive adoption, especially from non-technical people. Heck, I'm reasonably technical myself (but not expert in image formats) and my first instinct on encountering AVIF was to say "AVIF? Does that stand for AVI File?" And I would have assumed that it's a video format, not an image format. Whereas JPEG XL would have everyone who has ever used a digital camera saying "Ah, it's got JPEG in the name, that means it's a photo format".
Never underestimate the power of a well-known brand name in communicating things to people who know nothing else about the subject. The name is a big part of why I suspect JPEG XL will take off in popularity. (The lossless conversion to and from classic JPEG format is the other main reason).
> If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web".
The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.
Looking forward to a future where we can arbitrarily DoS anyone with a PDF that computes massive swaths of prime numbers.
PDFs can already do arbitrary computation. You can even play tetris in them.
Can't that future adopt basic resource / complexity limits to defuse the DOS bomb?
I’ve been shooting with semipro to pro cameras for decades across brands, and I haven’t came across a single camera that supports shooting JPEG XL.
HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.
Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?
I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.
> and narrowly scoped to the needs of the Web
> it was hard enough to get widespread WebP adoption
That's not a coincidence! And because these newer codecs are better outside the Web, it's not really "the same hill"
In the post, I say "I think WebP was a bit too narrowly scoped"
This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.
Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.
I'm the author if anyone has questions – AMA
How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images.
For every other image encoder I used I couldn't find one setting that would make compact, high-quality images across the gamut of inputs (e.g. things like comics that have extremely visible high-frequency content would look terrible at quality settings that looked good for many photographs).
Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
Lossless was discounted because lossless just isn't very useful on the Web
I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental.
I can accept a claim that JPEG-XL is not the best format for it, or that it is good, but not worth the complexity and extra surface area it introduces. I can not accept a claim that "lossless just isn't very useful on the web".
What percentage of the web is that 0.1% ? 0.01% ?
I think its correct to say a use case that is very niche on the web isn't super important to the web. Especially when there already exists a bunch of lossless formats. After all, the value proposition of jxl is to save some bytes. It would be different if the point was introducing images as a whole.
It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
We have to apply some weight to the fact that one is open, one isn't, right?
EDIT: Oh! Of course. AVIF is based on AV1. For some reason I was thinking HEIF the entire time I was reading the article. Man... withdrawn!
Really good read, btw. Very good points.
AVIF is royalty-free, & SVT-AV1 and libaom are open source.
Edit: saw you corrected. Much appreciated!
SVT-AV1 is also more than just open source in name only; development and discussions happen in the open; with many community forks that’s now getting upstreamed/merged.
It is a true open source project; not just an open source license.
SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.
Both are open I think.
What do you think the best use cases for jxl are? Where does it still have an advantage over other formats?
I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
It's a great option for 3D art texturing and compositing. I could see using it over OpenEXR, which I use a lot in Blender right now.
I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.
x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
> where higher is better
Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics.
Thanks for the article, btw!
What about the current AV1 patent issues, like Sisvel/Access Advance and Dolby vs Snap? Does that change the AVIF vs JXL comparison at all?
those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?
The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.
Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.
If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"
So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.
None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.
What are your thoughts on that argument?
> I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases.
Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet.
So the major web browsers will support JPEG XL later this fall.
[1]: "Intent to Ship: JPEG XL" - https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
> But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.
I'm not even personally convinced it is useful for cameras. Sally's situation isn't particularly bandwidth or feature-constrained, so JPEG or PNG work. Maybe JXL is solving problems that don't exist?
HDR is something many photography enthusiasts are interested in, and the ability to losslessly transcode from JPEG to JPEG XL (and back again if you have to) is actually IMHO the "killer app" for the format. Many people have years of irreplaceable family photos in JPEG format, and being told "you can fit 30% more photos on the same hard disk without any loss of quality" would certainly sell me on converting my photo library to JPEG XL. (The jpegxl.com site says "up to 60% smaller" so I'm going to guess that 30% is a safe average gain and it might be more).
And nearly everyone who takes photos of their family ends storage-constrained on cameras at some point. Memory cards only holding so much is less of an issue than it used to be, but in my experience the only people with laptops that have more than 1 TB of disk space are the computer professionals I know; every non-computer professional I personally know has 1 TB or less, usually 512 GB. That's room for plenty of photos, but not an infinite amount, and the photo collection (plus videos of baby's first steps and so on) is competing with a lot of other things for storage space. So being able to shrink the collection size by 30% or more with no artifacting added is definitely going to be worth it for one of the biggest selling points for cameras. (Including the cameras on smartphones).
I wouldn't say that JXL is absolutely vital and the industry should switch right now. But I would say that it's likely to be the only image format that has a chance to displace JPEG among the average camera user. Having JPEG in the name is also going to be a major selling point; don't underestimate that. (And the JPEG <-> JPEG XL conversion being lossless will complete the selling point).
Since (if I'm right) it's going to end up ubiquitous, then even if another format would be technically better, it would be wise for everyone writing software that handles images — browsers, OS file explorers, and so on — to make sure their software can support it. Just on general principles of supporting every widely-used format and every format that looks likely to be widely-used in the future.
I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:
> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.
It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.
We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?
There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included).
Source: I lead Mozilla's technical contributions to AV1.
> You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
What exactly is "Fruit Company's format"?
I'm guessing HEIC.
HEIF isn't an Apple owned format, most modern cameras have it as an option alongside JPEG now. The situation is JPEG is woefully outdated, lacking in HDR support and dated compression. HEIF is technically much better but patent encumbered.
JPEG-XL offers all the benefits of HEIF and more, while not being patent encumbered.
I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
I believe wholeheartedly that AVIF's approach is significantly better UX.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Perhaps it's just a bad example. I suppose avif can support multiple "scans" of progressive encoding as well.
> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.
This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.
Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".
In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.
Hope this helps clarify how progressive AVIF actually works under the hood.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.
You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.
Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.
Can a similar technique be employed in JPEG XL, or does the format not allow for it in any way?
Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.
Does the difference matter?
Yes, if you look at the demo, the "progressive" AVIF loads a visible image at 8.5KB, and at that point, it looks better than the progressive JXL. However, that is ALL the AVIF shows until the image has fully loaded. At around 98KB, the JXL looks significantly better, and at around 240KB already looks really close to the final image, while the AVIF still looks terrible. At 280KB when the AVIF finally loads, they look identical.
I prefer the UX of the AVIF example here. I think it's better to have a progressive phase where the image is obviously "not ready", yet you can still determine important details like the subject of the image (unlike a blurhash), rather than a phase that you could mistake for complete, but looks bad in parts.
BTW, you can configure the AVIF encoder to have another in-between pass or two so the quality jump isn't as big. The JXL folks just happened to go with only two total passes.
Won't that increase the total size of the image for each pass?
Thanks to AV1's inter encoding, overhead is overall minimal as each pass can refine on previous ones. Think of it as a mini-video. Because of this, in the case of images with a lot of repeated patterns, progressive AVIF encoding can actually result in more efficient images!
Looking at the demo linked in the blog post, I can make a similar quality thumbnail for a smaller size than the delta between the static and progressive AVIFs
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)
Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.
The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.
Of course it does, with one you have to render twice and store two layers which costs you both compute and storage. With the other you can just take the image mid decode at a point and display it. Single decode operation, no layer mess.
You have to render twice and have 2 different layers in both scenarios. Writing to a buffer / layer is not an atomic operation so they need to be separated.
The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image.
If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
How does progressive rendering actually that most OS GUIS are not multithreaded ?
The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.
Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
Progressive rendering is intended for the Web and it does work.
Interesting.
All my photos are HEIC. Why not just use what I have and not translate?
You should never transcode lossy source files because there is generation loss in quality.
There is still a lot of reason for Apple to switch from HEIC to JXL for photos going forward since HEIC is patent encumbered so it will never see widespread use.
Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
HEIC has a very messy patent situation around it which limits what tools work with it.
E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99
Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.
Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.