JPEG XL vs AVIF for net use-cases

JPEG XL has now landed in all main browsers, so I figured I’d take a better take a look at what it is good/unhealthy at in comparison with different codecs.
I’ll go into full element, with examples and benchmarks, however for these of you who do not have the time, listed here are the headlines:
For lossy photographs on the net, AVIF virtually all the time produces smaller information than JPEG XL. At default effort settings, the most effective JPEG XL model is often 15–25% bigger than the equal AVIF. At most effort settings, the hole narrows slightly, to usually 6–20%. There are outliers, the place JPEG XL is near, and even beats AVIF, so if you need the very best end result for a selected picture, it is price attempting each. See the F1 image for a typical instance, and the weasel for an outlier.
The JPEG XL encoder issues loads. jixel, a more recent JPEG XL encoder, often produces smaller information than libjxl, besides when the picture has detailed transparency. The people image is one instance.
For screenshots and illustrations, AVIF is significantly better than JPEG XL. The equal JPEG XL is 30–90% bigger at default effort settings, and 20–70% bigger at most effort settings. Lossy AVIF handles these effectively – you need not use lossless codecs until you really want bit-exact outcomes. See the screenshot and illustration examples.
For pictures with transparency, AVIF is significantly better than JPEG XL. The libjxl model is 31–44% bigger at default effort settings, and 61–70% bigger at most effort settings. jixel all the time encodes transparency losslessly, which makes its information 2–3x the dimensions of AVIF’s. See the data.
AVIF is usually sooner to encode, and makes use of much less reminiscence, whenever you consider file dimension. jixel is quicker than AVIF and makes use of much less reminiscence, however its information are usually considerably bigger, so AVIF is healthier on steadiness. See the F1 image for one instance.
AVIF is quicker to decode. JPEG XL usually takes 2–3x as lengthy to decode at medium high quality, however the hole narrows at very excessive qualities, the place Chrome can typically decode JPEG XL sooner. The people image is one instance.
Higher effort settings are price it for AVIF and jixel, however not libjxl. libjxl’s larger efforts are a lot slower, use much more reminiscence, and barely enhance the end result. Sometimes they produce bigger information than the default effort. The screenshot is an instance of this.
AVIF’s 4:2:0 mode (half color decision) should not be your default. It hardly ever reduces file dimension, and it makes larger qualities tougher to succeed in. Although, it’s faster to encode and decode. Stick with 4:4:4 if you do not have time to test each. The F1 image is one instance, and the screenshot is an exception.
Quality settings are dependable for all of the encoders. With a single high quality setting, the ensuing high quality varies a bit between pictures, however all of the encoders fluctuate in the identical route, and in ways in which appear cheap. See the data.
Progressive JPEG XL is mainly free at excessive effort. jixel lately added assist for early progressive previews, and at its slowest setting they price little or nothing, however at its default setting the information are 12% greater. Firefox and Chrome assist progressive JPEG XL. Safari nonetheless renders the ultimate picture, however does not present progressive previews. However, is this kind of progressive rendering an excellent consumer expertise? See the examples and data.
AVIF helps progressive rendering! It’s Chrome-only for now, but it surely’s in progress for Firefox. It’s extra advanced than progressive JPEG XL, but it surely offers you extra management over what the preview appears to be like like, the information are often smaller, and they are much sooner to decode. See for yourself.
For HDR, JPEG XL lacks acquire maps, which is a major limitation in comparison with AVIF. The JPEG XL format helps acquire maps, however they don’t seem to be supported by browser decoders, and the encoding story is messy/experimental. When evaluating non-gain mapped HDR content material, the 2 high quality metrics I used disagree loads, however they agree that JPEG XL produces smaller information in comparison with AVIF. See the examples.
JPEG XL could make present JPEGs 9–20% smaller, with out additional loss. It’s additionally as quick or sooner to decode, aside from small pictures. See the data.
For lossless, JPEG XL is the clear winner. Lossless WebP is 9–17% bigger for photographs, and lossless AVIF is 30–120% bigger. But lossless pictures are virtually by no means what you need on the net. If you do use them on the net (like I do on this web page), be careful for jixel’s larger efforts – it usually produces information which are too gradual to decode. See the data.
Animated picture codecs proceed to be a dumb thought. Please do not use them. Learn more, when you should.
For net use-cases, I’d at the moment default to AVIF 4:4:4, with the best effort stage I could be bothered with. If I felt AVIF was producing an unusually giant file, I’d check out JPEG XL through jixel, and see if it did higher.
Both AVIF and JPEG XL (through jixel) have seen large enhancements lately, so it is doable that this suggestion might change in future. There’s been quite a lot of misinformation round these things, and your AI will fortunately ship that misinformation to you. Instead, take a look at issues with your individual pictures.
AVIF folks suggest that JPEG XL is technically restricted in comparison with AVIF. That is perhaps true, however on this article I’m specializing in outcomes with right now’s implementations.
I ‘created’ a benchmarking script, that encodes pictures utilizing varied codecs at varied settings, and information varied particulars.
I’m utilizing the newest launched variations of the picture codecs, which at time of writing is:
- avifenc 1.4.2
- libjxl 0.12.0 (utilizing its
cjxlencoder) - jixel 0.4.2 (git
f487299), a second JPEG XL encoder - cwebp 1.6.0 (lossless WebP is used later within the article)
I selected a choice of pictures, and encoded most of them to a width of 1598 pixels – which is 2x the utmost width pictures seem on this weblog. This means they look sharp on high density displays, which most customers have. As a end result, when you’re viewing this on a small or low density display, you are not getting the complete expertise.
I ran these benchmarks on my 2024 MacBook Pro (M4 Pro).
When I first wrote about AVIF, I used an F1 automotive as the primary picture, so I figured I’d try this once more!
I encoded the picture at varied codec qualities, and selected variations that have been closest to explicit SSIMULACRA2 scores – a perceptual picture high quality metric by the oldsters behind JPEG XL. 50 is taken into account medium high quality, 70 excessive, 80 very excessive, and 90 visually lossless. Although, I’m unsure if these rankings take excessive density shows under consideration.
Throughout the article, the visible comparisons, like above, use every encoder’s most effort, besides in instances the place most effort ends in a bigger file (sure, that occurs).
For archival, I’d have a tendency in the direction of near-lossless qualities, but when I’m simply displaying an illustrative picture on my weblog, efficiency is extra necessary to me. I’m personally pleased with the 70 end result above. If you zoom in, you may see the standard loss, but when I used to be actually involved in regards to the zoom-in case, I’d use one thing just like the VisualViewport API to load in a better decision picture when that occurs, slightly than make the obtain greater for everybody.
At decrease qualities you may see the distinction in technique between the codecs. The element loss is across the similar, however AVIF tends to easy issues out in comparison with the unique, whereas JPEG XL appears to introduce rougher patterns.
Also, I really feel that, at medium high quality (50), the AVIF and libjxl look higher than the jixel model. The jixel model has quite a lot of seen noise across the BWT brand, and the Microsoft textual content on the entrance wing is manner much less legible. It makes me marvel in regards to the metric a bit.
Anyway, here is my interpretation of the outcomes:
- File dimension: AVIF wins. At default efforts, the most effective JPEG XL picture is 14–17% bigger than the AVIF picture for a similar high quality. jixel is the higher JPEG XL encoder at medium/top quality, and libjxl is barely higher at very top quality. At most efforts, the most effective JPEG XL picture (jixel ‘extraslow’) is 6–15% bigger than AVIF (s0).
- jixel at its slowest setting barely beats AVIF’s default effort, with information 1–10% smaller. The largest acquire is at very top quality.
- Encode time: AVIF wins. At default efforts, jixel is 12–36% sooner than AVIF, however its information are 14–18% bigger. To match the file dimension of AVIF’s default, jixel wants its ‘extraslow’ setting, which takes 18–27x so long as AVIF. libjxl’s default takes 1.5–2x so long as AVIF’s default, and nonetheless produces greater information.
- Encode reminiscence: AVIF wins. At default efforts, jixel makes use of round half the reminiscence of AVIF, however once more, its information are 14–18% bigger. To match the file dimension of AVIF’s default, jixel ‘extraslow’ makes use of ~10x the reminiscence. libjxl’s default makes use of 2–3x the reminiscence of AVIF, and its larger efforts use ~7x.
- Decode time: AVIF wins. JPEG XL takes 2–3x as lengthy to decode at medium high quality, narrowing to ~1.5–1.8x at very top quality. Safari’s JPEG XL decoder is the slowest.
- Higher effort is price it for AVIF. AVIF’s s5 will get you ~10% smaller information for ~3x the encode time.
- Higher effort is price it for jixel too, as much as ‘gradual’. ‘gradual’ will get you 9–13% smaller information than its default ‘quick’, for ~3.7x the encode time. ‘extraslow’ saves one other 3–8%, however takes ~8x longer than ‘gradual’ and makes use of ~9x the reminiscence. Even so, AVIF nonetheless wins when given the identical encode time: AVIF s5 takes about so long as jixel ‘gradual’, and its information are ~13% smaller.
- Higher effort is not price it for libjxl. libjxl’s most effort is barely any higher than its default, however takes ~18x longer.
- AVIF’s 4:2:0 mode does not assist a lot. It’s barely sooner to encode/decode, and makes use of much less reminiscence, however the information aren’t meaningfully smaller, and it struggles to succeed in larger qualities.
Here’s the complete information, so you can also make up your individual thoughts:
Show me the graphs!
Image quality
Ok, let’s get to our first graph, the SSIMULACRA2 scores:
File dimension
20 kB40 kB60 kB80 kB100 kB120 kB140 kB160 kB
45505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
There’s going to be quite a lot of these graphs, so here is what is going on on:
- The x-axis is visible high quality in keeping with SSIMULACRA2.
- The y-axis is file dimension. Lower is healthier, for a given visible high quality.
- The orange traces symbolize JPEG XL encoded with libjxl.
- The inexperienced traces symbolize JPEG XL encoded with jixel.
- The blue traces symbolize AVIF.
- The dashed blue traces symbolize AVIF with its shade information at half decision. Known as 4:2:0, or chroma subsampling.
- The darker traces symbolize larger effort ranges for that codec. libjxl calls this ‘effort’, so the e10 line is the highest effort. Annoyingly, avifenc calls this ‘pace’, so the s0 line is the highest effort. jixel names its ranges, from ‘quick’ (its default) to ‘extraslow’.
- Only the default and most efforts are proven initially. Click the legend to toggle the others.
Here are the standard outcomes utilizing a unique high quality metric, ColorVideoVDP:
File dimension
20 kB40 kB60 kB80 kB100 kB120 kB140 kB160 kB
9.409.509.609.709.809.9010.00
ColorationVideoVDP, JOD (10 = no seen distinction)
The result’s roughly the identical besides this metric places extra of a niche between AVIF and the JPEG XL pictures.
It additionally suggests there’s some benefit to AVIF with 4:2:0 chroma subsampling at decrease qualities, but it surely’s minor.
Encoding performance
When it comes to photographs on my weblog, I encode with most effort settings. I’m comfortable to attend a few seconds to get a picture that is sooner to load for each consumer. However, when you’re doing quite a lot of encoding on a server, encode time turns into extra of a priority.
Encode time
0 ms500 ms1 s1.5 s2 s2.5 s3 s3.5 s
45505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Another factor that is perhaps a priority when you’re encoding pictures on a server is peak reminiscence utilization:
Peak encoder reminiscence
0 MB100 MB200 MB300 MB400 MB500 MB600 MB700 MB800 MB900 MB1000 MB
45505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
It’s price contemplating decoding efficiency. If decoding is especially gradual, then it would make the file dimension profit much less beneficial, particularly when pictures are loaded from a cache.
Decode time
4 ms6 ms8 ms10 ms12 ms14 ms16 ms18 ms20 ms22 ms
45505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
JPEG XL turns into immediately sooner to decode at very top quality settings (however nonetheless slower than AVIF). I feel this is because of an edge preserving filter that does extra work at decrease high quality settings.
I’ve heard individuals say that AVIF’s tendency to easy out particulars makes it unhealthy for human faces, so I picked this picture from Unsplash.
The outcomes of the benchmark for this picture:
- File dimension: AVIF wins. At default efforts, the most effective JPEG XL picture is 17–24% bigger than the AVIF picture for a similar high quality. jixel is the higher JPEG XL encoder throughout the entire high quality vary this time. libjxl is 30–50% bigger than AVIF, which is a a lot greater hole than the F1 picture. At most efforts, the most effective JPEG XL picture (jixel ‘extraslow’) is 12–17% bigger than AVIF (s0).
- jixel at its slowest setting does not fairly match AVIF’s default effort this time. It’s a couple of p.c bigger at medium/top quality, and solely edges forward at very top quality.
- Encode time: AVIF wins. At default efforts, jixel is eighteen–33% sooner than AVIF, however its information are 17–24% bigger. Even jixel’s ‘extraslow’ setting, which takes 25–39x so long as AVIF, solely matches AVIF’s default file dimension at very top quality. libjxl’s default takes 1.5–2.2x so long as AVIF’s default, and nonetheless produces greater information.
- Encode reminiscence: AVIF wins. At default efforts, jixel makes use of round half the reminiscence of AVIF, however once more, its information are 17–24% bigger. jixel ‘extraslow’ will get closest to AVIF’s default file dimension, however makes use of ~10x the reminiscence. libjxl’s default makes use of 2–3.3x the reminiscence of AVIF, and its larger efforts use ~7x.
- Decode time: AVIF wins. JPEG XL takes 2–2.9x as lengthy to decode at medium high quality, narrowing to ~1.3–1.7x at very top quality. At the very prime of the standard vary, libjxl pictures decode as quick as AVIF in Chrome, however not within the different browsers.
- Higher effort is price it for AVIF. AVIF’s s5 will get you 5–8% smaller information for ~3x the encode time. That’s a smaller acquire than the F1 picture.
- Higher effort is price it for jixel too, as much as ‘gradual’. ‘gradual’ will get you 7–14% smaller information than its default ‘quick’, for ~3.9x the encode time. ‘extraslow’ saves one other 4–6%, however takes ~10x longer than ‘gradual’ and makes use of ~9x the reminiscence. AVIF nonetheless wins when given the identical encode time: AVIF s5 takes about so long as jixel ‘gradual’, and its information are 8–17% smaller.
- Higher effort is considerably price it for libjxl on this picture. Unlike the F1 picture, libjxl’s most effort will get you 4–11% smaller information than its default. But it takes ~10x longer, and it nonetheless produces a lot greater information than AVIF at its default effort.
- AVIF’s 4:2:0 mode does not assist a lot. Same because the F1 picture. ColorationVideoVDP offers it a small (~4%) benefit, however SSIMULACRA2 does not.
At decrease qualities, you may see the smoothing on the face, but it surely’s the identical for each AVIF and JPEG XL.
Show me the graphs!
Image quality
File dimension
20 kB40 kB60 kB80 kB100 kB120 kB140 kB160 kB180 kB200 kB220 kB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
File dimension
20 kB40 kB60 kB80 kB100 kB120 kB140 kB160 kB180 kB200 kB220 kB
9.459.509.559.609.659.709.759.809.859.909.9510.00
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms500 ms1 s1.5 s2 s2.5 s3 s3.5 s4 s
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB100 MB200 MB300 MB400 MB500 MB600 MB700 MB800 MB900 MB1000 MB1100 MB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
4 ms6 ms8 ms10 ms12 ms14 ms16 ms18 ms20 ms
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
It’s attention-grabbing that, at decrease qualities, jixel decodes a lot slower in Safari.
I threw this one in as a result of it is the default picture in Squoosh, however I assume the sharp traces of the hairs make it completely different to the earlier pictures. In truth, even at medium high quality, the distinction from the unique is far much less perceptible to my eyes in comparison with the opposite pictures.
The outcomes are a lot nearer than the earlier two:
- File dimension: AVIF wins, narrowly. At default efforts, the most effective JPEG XL picture (jixel) is barely 2–6% bigger than the AVIF picture for a similar high quality. libjxl does a lot worse, at 10–18% bigger. At most efforts, jixel ‘extraslow’ and AVIF s0 are roughly tied, with jixel as much as 5% smaller at very top quality. However, ColorationVideoVDP disagrees, and places AVIF 5–12% forward at most efforts.
- Encode time: JPEG XL (jixel) wins, in keeping with SSIMULACRA2. At default efforts, jixel is nineteen–35% sooner than AVIF, and its information are solely 2–6% bigger. Comparing larger efforts, jixel ‘gradual’ produces information the identical dimension or barely smaller than AVIF s5, in the identical time or much less. And jixel ‘extraslow’ matches or beats AVIF s0 whereas being 12–34% sooner. But, since ColorationVideoVDP offers AVIF extra of a file dimension benefit, it is not clear-cut. libjxl’s default takes 1.3–1.9x so long as AVIF’s default, and produces greater information.
- Encode reminiscence: JPEG XL (jixel) wins, at decrease efforts. At default efforts, jixel makes use of 37–48% much less reminiscence than AVIF, and its information are solely 2–6% bigger. jixel ‘gradual’ makes use of about the identical reminiscence as AVIF s5 to supply the same file dimension, however ‘extraslow’ makes use of ~9x the reminiscence of AVIF s0. libjxl’s default makes use of ~2x the reminiscence of AVIF, and its larger efforts use 6–7x.
- Decode time: AVIF wins. JPEG XL takes 2–2.4x as lengthy to decode at medium high quality. But the hole closes at very top quality, the place jixel’s information decode about as quick as AVIF in Firefox and Safari, and ~25% sooner in Chrome.
- Higher effort is much less price it for AVIF on this picture. AVIF’s s5 will get you 3–6% smaller information for 3–4x the encode time.
- Higher effort is price it for jixel, as much as ‘gradual’. ‘gradual’ will get you 6–14% smaller information than its default ‘quick’, for 3.5–4.3x the encode time. ‘extraslow’ saves one other 2–9%, however takes 9–14x longer than ‘gradual’ and makes use of ~9x the reminiscence.
- Higher effort is not price it for libjxl. libjxl’s most effort will get you 1–2% smaller information than its default, however takes ~12x longer.
- AVIF’s 4:2:0 mode does not assist. The information are the identical dimension as 4:4:4.
Show me the graphs!
Image quality
File dimension
0 kB50 kB100 kB150 kB200 kB250 kB300 kB350 kB400 kB450 kB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
File dimension
0 kB50 kB100 kB150 kB200 kB250 kB300 kB350 kB400 kB450 kB
9.309.409.509.609.709.809.9010.00
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms1 s2 s3 s4 s5 s6 s
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB200 MB400 MB600 MB800 MB1000 MB1200 MB1400 MB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
6 ms8 ms10 ms12 ms14 ms16 ms18 ms
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
I’ve performed with each codecs loads, and for photographs, what I’ve proven to this point is consultant, the place AVIF beats JPEG XL. However, every so often there’s an outlier, akin to this picture.
- File dimension: JPEG XL wins. At default efforts, the most effective JPEG XL picture is 4–11% smaller than the AVIF picture for a similar high quality. libjxl is the higher JPEG XL encoder at medium/top quality, and jixel at very top quality. At most efforts, jixel ‘extraslow’ is 12–27% smaller than AVIF s0. This time, ColorationVideoVDP agrees.
- jixel’s ‘medium’ setting is a giant step up on this picture. Its information are 11–25% smaller than AVIF’s default, and 4–18% smaller than AVIF s0, the utmost effort.
- Encode time: JPEG XL (jixel) wins. At default efforts, jixel is 28–38% sooner than AVIF, and produces information which are across the similar dimension or smaller. At larger efforts, it is much more one-sided: jixel ‘medium’ is 37–65% sooner than AVIF s5, and produces information 9–23% smaller. libjxl’s default takes 1.5–2.2x so long as AVIF’s default.
- Encode reminiscence: JPEG XL (jixel) wins. At default efforts, jixel makes use of 14–24% much less reminiscence than AVIF, and produces information which are across the similar dimension or smaller. AVIF s0 makes use of much more reminiscence (~1.55x its default), and nonetheless produces greater information than jixel ‘medium’, which makes use of 41–55% much less reminiscence than AVIF s0. libjxl’s default makes use of 2.4–3.6x the reminiscence of AVIF, and the utmost efforts of each JPEG XL encoders use 10–18x.
- Decode time: AVIF wins, besides in Chrome at larger qualities. JPEG XL takes 1.3–1.9x as lengthy to decode in Firefox and Safari. In Chrome, JPEG XL takes ~1.25x as lengthy at medium high quality, however from top quality upwards, it is 11–36% sooner than AVIF.
- Unlike the earlier pictures, jixel pictures aren’t significantly gradual to decode in Safari. In truth, they decode barely sooner than libjxl pictures.
- Higher effort is not actually price it for AVIF on this picture. AVIF’s s5 solely will get you 1–3% smaller information for 3–4.5x the encode time. s0 will get you 7–8% smaller information, however takes ~50x as lengthy.
- Higher effort is price it for jixel, as much as ‘gradual’. ‘medium’ will get you 6–14% smaller information than its default ‘quick’, for 1.9–4.1x the encode time. ‘gradual’ will get you 9–19% smaller information than ‘quick’, for 3.9–6.5x the encode time. ‘extraslow’ saves one other 5–9%, however takes 8–18x longer than ‘gradual’ and makes use of ~11x the reminiscence.
- Higher effort is not price it for libjxl. libjxl’s most effort will get you 1–6% smaller information than its default, however takes 11–14x longer.
- AVIF’s 4:2:0 mode does not assist. The information are the identical dimension as 4:4:4.
- All three encoders produce decrease SSIMULACRA2 scores for this picture. As in, with the identical encoder high quality worth, they rating decrease. It looks like the encoders are fairly comfortable smoothing out a few of the background noise, which appears high quality.
Show me the graphs!
Image quality
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB700 kB800 kB900 kB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB700 kB800 kB900 kB
9.309.409.509.609.709.809.9010.00
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms1 s2 s3 s4 s5 s6 s7 s8 s9 s
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB200 MB400 MB600 MB800 MB1000 MB1200 MB1400 MB1600 MB1800 MB2000 MB2200 MB
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
10 ms12 ms14 ms16 ms18 ms20 ms22 ms24 ms26 ms28 ms30 ms32 ms
4045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Ok, let’s strive one thing aside from a photograph:
The outcomes of the benchmark:
- File dimension: AVIF wins, by loads. At default efforts, the most effective JPEG XL picture is 73–89% bigger than the AVIF picture at medium/top quality (jixel), and 29–44% bigger at very top quality (libjxl). At most efforts, the most effective JPEG XL picture (jixel ‘extraslow’ with patches) is 23–73% bigger than AVIF (s0).
- libjxl cannot produce something between SSIMULACRA2 ~45 and ~78 at its default effort (~45 and ~75 at larger efforts). jixel does not have this drawback.
- jixel’s patches characteristic helps loads with this picture, but it surely’s off by default. With patches, jixel’s information are 10–29% smaller at its larger efforts, from SSIMULACRA2 ~65 upwards. Patches don’t have any impact at jixel’s default ‘quick’ setting.
- Encode time: AVIF wins. At default efforts, jixel is ~50% sooner than AVIF, however its information are 70–98% bigger. libjxl’s default takes 1.7–1.8x so long as AVIF’s default, and nonetheless produces a lot greater information.
- Encode reminiscence: AVIF wins. At default efforts, jixel makes use of ~40% much less reminiscence than AVIF, however once more, its information are a lot bigger. libjxl’s default makes use of 1.2–2.2x the reminiscence of AVIF. jixel ‘extraslow’ with patches will get closest to AVIF’s file sizes, however makes use of ~7.5x the reminiscence of AVIF’s default.
- Decode time: AVIF wins, by loads. Taking the sooner of the 2 JPEG XL encoders’ output, JPEG XL takes 2–3.8x as lengthy to decode, relying on browser and high quality.
- Higher effort is extra price it for AVIF on this picture. AVIF’s s5 will get you 6–13% smaller information for two.5–3x the encode time, and s0 will get you 16–23% smaller information for 30–45x the encode time.
- Higher effort is price it for jixel, so long as you allow patches. ‘medium’ with patches will get you 11–44% smaller information than its default ‘quick’, for 3–4x the encode time. ‘gradual’ with patches saves one other 7–16% for ~1.7x the time of ‘medium’. ‘extraslow’ with patches saves one other few p.c, however takes ~5x longer than ‘gradual’ and makes use of ~4.5x the reminiscence.
- Higher effort is dangerous for libjxl. At very top quality, libjxl’s most effort produces information 33–40% bigger than its default effort, and takes ~7x longer.
- AVIF’s 4:2:0 mode helps at larger qualities. At SSIMULACRA2 70 and above, it produces information 7–18% smaller than 4:4:4. At decrease qualities, it makes no distinction.
- All three encoders produce larger SSIMULACRA2 scores for this picture. Opposite to the weasel picture. But, this appears right. At SSIMULACRA2 70 the artifacts are fairly noticeable across the Firefox brand (to me, anyway), so I’d go together with 80, which is the place the codecs lean anyway.
Some builders, particularly those that’ve been round so long as I’ve, appear to assume issues like screenshots should be delivered in a lossless format. But I feel it’s because they’re used to codecs like JPEG and WebP (and seemingly JPEG XL) which deal with this type of picture badly, whereas lossy AVIF handles them very well.
Show me the graphs!
Image quality
File dimension
0 kB10 kB20 kB30 kB40 kB50 kB60 kB70 kB
2030405060708090
SSIMULACRA2 (larger is nearer to the unique)
I’m not together with the ColorationVideoVDP chart as a result of the metric does not assist alpha channels.
Encoding performance
Encode time
0 ms500 ms1 s1.5 s2 s2.5 s3 s3.5 s4 s4.5 s5 s
2030405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB100 MB200 MB300 MB400 MB500 MB600 MB700 MB800 MB
2030405060708090
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
4 ms6 ms8 ms10 ms12 ms14 ms16 ms18 ms20 ms22 ms
2030405060708090
SSIMULACRA2 (larger is nearer to the unique)
The excessive JPEG XL decoding instances listed here are possible a facet impact of it producing a lot bigger information for a given high quality.
In many instances, for largely flat-colour pictures, you’d use SVG. But typically that is not doable (it is a screenshot), or undesirable, akin to this case. This picture, also from Unsplash, remains to be 1.1 MB as a compressed and minified SVG. This is as a result of complexity of the shaded areas. As a end result, a raster format wins on file dimension and decode/draw time.
At high quality 50 within the demo above, the jixel has some fairly extreme color blocks, e.g. on the cat’s face. Again, it makes me query the metric a bit.
The outcomes of the benchmark:
- File dimension: AVIF wins, by loads. At default efforts, the most effective JPEG XL picture (jixel) is 32–65% bigger than the AVIF picture as much as SSIMULACRA2 80, and ~90% bigger past that. At most efforts, the most effective JPEG XL picture (jixel ‘extraslow’) is 22–55% bigger than AVIF (s0) as much as SSIMULACRA2 80, and extra past that. ColorationVideoVDP agrees, and places the hole at 27–58%.
- libjxl performs significantly badly with this picture. At default efforts, it is 71–106% bigger than AVIF.
- Lossy AVIF cannot attain SSIMULACRA2 90 with this picture. Even at its most high quality setting, it tops out at ~87, so the 90 instance above is not a very honest comparability. JPEG XL can attain 90, however the result’s 8–50% bigger than JPEG XL’s lossless model, so you could as effectively use lossless.
- Encode time: AVIF wins. At default efforts, jixel is 35–44% sooner than AVIF, however its information are 32–65% bigger, which is a foul commerce. jixel wants its ‘gradual’ setting to get inside 7–27% of AVIF’s default file dimension, which takes 2.4–2.6x so long as AVIF. libjxl’s default takes 1.3–2.3x so long as AVIF’s default, and produces a lot greater information.
- Encode reminiscence: AVIF wins. At default efforts, jixel makes use of ~37% much less reminiscence than AVIF, however once more, its information are a lot bigger. jixel ‘gradual’ makes use of about the identical reminiscence as AVIF, and ‘extraslow’ makes use of ~12x. libjxl’s default makes use of 1.5–3x the reminiscence of AVIF.
- Decode time: AVIF wins, by loads. JPEG XL takes 2–4.6x as lengthy to decode at medium/top quality, narrowing to 1.6–2.1x at very top quality.
- Higher effort is extra price it for AVIF on this picture. AVIF’s s5 will get you 5–8% smaller information for ~2.7x the encode time, and s0 will get you 14–21% smaller information for 35–48x the encode time.
- Higher effort is price it for jixel, as much as ‘gradual’. ‘medium’ solely will get you 4–13% smaller information than its default ‘quick’, however ‘gradual’ will get you 19–24% smaller information (as much as 36% at very top quality), for ~4x the encode time. ‘extraslow’ saves one other 2–3%, however takes 8–9x longer than ‘gradual’ and makes use of ~11x the reminiscence.
- jixel’s patches characteristic does not assist with this picture. Unlike the screenshot, the file sizes are similar with and with out it, but it surely does improve encode time and reminiscence.
- Higher effort is not price it for libjxl. libjxl’s most effort will get you 3–9% smaller information than its default, however takes 10–13x longer.
- AVIF’s 4:2:0 mode does not assist. SSIMULACRA2 charges it barely worse than 4:4:4, and ColorationVideoVDP charges it barely higher (~3–4%).
Show me the graphs!
Image quality
File dimension
0 kB50 kB100 kB150 kB200 kB250 kB300 kB350 kB400 kB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
File dimension
0 kB50 kB100 kB150 kB200 kB250 kB300 kB350 kB400 kB
9.29.39.49.59.69.79.89.910.0
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms1 s2 s3 s4 s5 s6 s7 s8 s
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB200 MB400 MB600 MB800 MB1000 MB1200 MB1400 MB1600 MB1800 MB2000 MB2200 MB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
5 ms10 ms15 ms20 ms25 ms30 ms35 ms40 ms
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
So far, all the pictures have been principally opaque. What about a picture with transparency?
There are some things that make this one completely different:
- jixel all the time encodes the alpha channel losslessly. It does not have a setting for alpha high quality. This places jixel at a giant drawback with this picture. AVIF by default compresses the alpha channel lossily, monitoring the primary high quality setting. libjxl compresses the alpha channel losslessly by default, so be careful for that. For this benchmark, I set libjxl’s alpha high quality to the identical as the primary high quality.
- SSIMULACRA2 scores fully-transparent pixels as excellent, so with plenty of transparency, the scores can be larger than they might be for an opaque picture.
The outcomes of the benchmark:
- File dimension: AVIF wins, by loads. At default efforts, the most effective JPEG XL picture (libjxl) is 31–44% bigger than the AVIF picture for a similar high quality. At most efforts, it is 61–70% bigger. Due to its lossless alpha, jixel is 1.9–3.1x the dimensions of AVIF at default efforts.
- Encode time: AVIF wins. libjxl’s default takes 1.2–1.35x so long as AVIF’s default, and produces a lot greater information. jixel’s default is ~2x sooner than AVIF, however its information are round 2–3x the dimensions.
- Encode reminiscence: AVIF wins. libjxl’s default makes use of 2.4–2.7x the reminiscence of AVIF’s default, though in absolute phrases, that is ~120 MB vs ~46 MB. jixel’s default makes use of about the identical reminiscence as AVIF, however once more, its information are a lot greater.
- Decode time: AVIF wins. libjxl’s output takes 2–3x as lengthy to decode at medium high quality, narrowing to 1.4–1.8x at very top quality. jixel’s output decodes sooner than libjxl’s, and at very top quality it is across the similar pace as AVIF. Although, it is gradual in Safari at decrease qualities, taking ~2.4x so long as AVIF.
- Higher effort is price it for AVIF. AVIF’s s5 will get you 4–7% smaller information for two.3–2.9x the encode time, and s0 will get you 10–15% smaller information for twenty-four–29x the encode time.
- Higher effort barely helps jixel on this picture. ‘extraslow’ solely will get you 5–8% smaller information than its default ‘quick’, for 21–26x the encode time.
- Higher effort is dangerous for libjxl. libjxl’s most effort produces information as much as 8% bigger than its default effort, and takes ~6.5x longer.
- AVIF’s 4:2:0 mode is dangerous. It produces information 4–27% bigger than 4:4:4, and may’t get past SSIMULACRA2 ~79.
Show me the graphs!
Image quality
File dimension
20 kB40 kB60 kB80 kB100 kB120 kB140 kB160 kB180 kB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding performance
Encode time
0 ms500 ms1 s1.5 s2 s2.5 s3 s
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB50 MB100 MB150 MB200 MB250 MB300 MB350 MB400 MB450 MB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
3 ms4 ms5 ms6 ms7 ms8 ms9 ms10 ms11 ms12 ms13 ms14 ms
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
The pictures to this point have been the same decision. Are the outcomes completely different with smaller pictures?
Not actually. The outcomes are fairly just like the full-size F1 picture:
- File dimension: AVIF wins, by about the identical margin. At default efforts, the most effective JPEG XL picture is 13–18% bigger. At most efforts, the hole is barely greater than the full-size picture, at 12–20%.
- Encode time & reminiscence: AVIF wins, though libjxl’s default is now across the similar pace as AVIF’s default. jixel’s default is ~2x sooner than AVIF, however its information are 13–18% bigger, and this time it makes use of ~30% extra reminiscence. In any case, at default efforts, every thing encodes in underneath 50ms, utilizing underneath 40 MB, so these variations do not actually matter at this dimension.
- Decode time: AVIF wins, by the same margin, however once more, every thing decodes in a couple of milliseconds.
Show me the graphs!
Image quality
File dimension
4 kB6 kB8 kB10 kB12 kB14 kB16 kB18 kB20 kB22 kB
354045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
File dimension
4 kB6 kB8 kB10 kB12 kB14 kB16 kB18 kB20 kB22 kB
9.109.209.309.409.509.609.709.809.9010.00
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms200 ms400 ms600 ms800 ms1 s1.2 s
354045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
10 MB20 MB30 MB40 MB50 MB60 MB70 MB80 MB90 MB100 MB110 MB
354045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
0.5 ms1 ms1.5 ms2 ms2.5 ms3 ms3.5 ms4 ms4.5 ms
354045505560657075808590
SSIMULACRA2 (larger is nearer to the unique)
The numbers Safari offers are rounded, so the info is de facto noisy.
What about an 18 megapixel picture?
Mostly the identical story because the common F1 picture, however with a couple of variations:
- File dimension: AVIF wins at medium/top quality, by greater than the common picture. At default efforts, the most effective JPEG XL picture is eighteen–46% bigger, and at most efforts, 28–54% bigger.
- But JPEG XL catches up at very top quality. Around SSIMULACRA2 85, libjxl’s default matches AVIF’s default, and at most efforts, jixel ‘extraslow’ is ~6% smaller than AVIF s0. jixel ‘gradual’ is 10–13% smaller than AVIF’s default from SSIMULACRA2 80 upwards.
- Encode time: AVIF wins at medium/top quality, however JPEG XL (jixel) wins at very top quality. AVIF’s default takes ~0.5 seconds, whereas libjxl’s default takes 1–2 seconds. jixel’s default is ~2x sooner than AVIF, however at medium/top quality its information are 29–57% bigger. At very top quality, that drops to six–12% bigger, which looks like an inexpensive trade-off for the pace. And jixel ‘gradual’ produces information across the similar dimension as AVIF s5, whereas being 33–41% sooner.
- Encode reminiscence: AVIF wins, and the prices at the moment are important. AVIF’s default makes use of ~560 MB. libjxl’s default makes use of ~2.5 GB at medium/top quality. jixel’s default makes use of ~35% lower than AVIF, and ‘gradual’ makes use of ~18% lower than AVIF s5. At most efforts, libjxl makes use of 5–6.4 GB, and jixel ‘extraslow’ makes use of 6.8–8.3 GB.
- Decode time: AVIF wins at medium/top quality, by the same margin to the common picture. jixel pictures take over 5x so long as AVIF to decode in Safari at these qualities. At very top quality, JPEG XL decodes sooner than AVIF in Chrome.
Show me the graphs!
Image quality
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB700 kB800 kB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB700 kB800 kB
9.29.39.49.59.69.79.89.910.0
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms5 s10 s15 s20 s25 s30 s35 s40 s
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB1000 MB2000 MB3000 MB4000 MB5000 MB6000 MB7000 MB8000 MB9000 MB
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
40 ms60 ms80 ms100 ms120 ms140 ms160 ms180 ms
30405060708090
SSIMULACRA2 (larger is nearer to the unique)
Another criticism I’ve heard levelled at AVIF is that its high quality is unreliable. As in, a single high quality setting is nice for some pictures, however no good for others, that means for routinely encoded pictures, you should choose a better high quality setting to be protected, leading to bigger file sizes than needed for some pictures.
For the pictures I’ve checked out to this point, I encoded them with avifenc -q 50, cjxl -q 70, and jixel at high quality 80, and recorded the ensuing SSIMULACRA2 scores:
| Image | AVIF | JPEG XL | JPEG XL (jixel) | |||||
|---|---|---|---|---|---|---|---|---|
| s6 4:4:4 | s0 4:4:4 | s6 4:2:0 | s0 4:2:0 | e7 | e10 | quick | extraslow | |
| F1 | 74.6 | 75.9 | 73.4 | 73.8 | 79.2 | 78.0 | 75.3 | 77.3 |
| F1 (small) | 70.9 | 73.5 | 68.4 | 69.5 | 75.6 | 73.9 | 70.6 | 72.6 |
| F1 (large) | 77.0 | 77.4 | 76.2 | 76.6 | 80.1 | 79.2 | 77.5 | 78.9 |
| People | 70.7 | 72.0 | 69.8 | 70.5 | 69.6 | 70.3 | 69.1 | 72.3 |
| Red panda | 67.5 | 68.8 | 67.0 | 67.2 | 69.5 | 68.4 | 69.2 | 72.3 |
| Weasel | 56.7 | 57.2 | 56.0 | 56.3 | 56.6 | 55.4 | 54.9 | 59.4 |
| Screenshot | 80.2 | 80.4 | 82.3 | 81.9 | 86.5 | 87.6 | 76.6 | 80.3 |
| Illustration | 78.6 | 79.7 | 76.8 | 77.9 | 80.3 | 78.5 | 75.4 | 77.7 |
| Alpha | 67.3 | 69.8 | 63.6 | 64.9 | 69.4 | 66.9 | 66.8 | 69.6 |
The behaviour of the codecs right here appears actually related. All produce a variety of SSIMULACRA2 scores, they usually all go larger or decrease for a similar pictures.
And I feel that is okay? Like, all three go for a decrease high quality for the Weasel image, which eliminated noise with out decreasing high quality of the picture topic. With the screenshot, all go for a better high quality, which appears justified to my eyes.
Obviously it is a small pattern dimension, however I have never seen something that means utilizing a single high quality setting is a threat, for any of the three codecs.
Also see Halide Compression’s deeper dive into this.
Both AVIF and JPEG XL are able to displaying one thing progressively because the picture hundreds. Chrome and Firefox assist progressive JPEG XL, whereas solely Chrome helps progressive AVIF. So, and I say this via gritted tooth, this subsequent demo is finest considered in Chrome (I’ve a Firefox patch in progress):
This is the 18 megapixel picture once more, so when you’re viewing this on a tool with a smaller display, you are not getting the complete impact.
Progressive AVIF and JPEG XL work very in a different way. With JPEG XL, you may choose into the info being saved in such a manner {that a} decoder can render low decision variations, earlier than it brings within the larger decision tiles. jixel lately (like, yesterday at time of writing) added assist for this too. It’s referred to as “progressive DC”, and it is an important sort of progressive rendering for JPEG XL.
With AVIF, progressions work extra like frames of a video. You present as much as 4 frames, in order that’s three phases earlier than the ultimate picture. Again, like a video, every body can use information from the earlier body as an optimisation. An benefit of that is you may select precisely how these frames look. In the instance above, I went with a single preview body: a 1/eighth decision model, with a little bit of blurring. But, your preview frames could be fully completely different pictures when you actually need.
There’s a scarcity of information relating to progressive pictures and consumer expertise, so these are simply my reckons:
If you are on a foul connection, information does not arrive regularly like some throttling instruments can have you consider. It tends to come back in bursts. So, there’s little profit to progressive rendering on smaller pictures, and I’m unsure that many progressive phases is especially helpful.
I feel that it is good to have a consultant preview for pictures that will take a while to load. I’ve skilled this personally, the place a web site or app has given me one thing clearly not-loaded, however with sufficient element to know what’s coming. That’s helpful to me, as I can determine issues like, if it is price ready for the entire thing. This can also be why I feel issues like BlurHash are cute, however ineffective. They’re not a consultant preview, so there’s little a consumer can do with the knowledge supplied.
The preview body I selected for the AVIF is sufficient to inform it is an open-wheel race automotive. If you already know F1, you may know what group it’s. You may even know the place the picture was taken. And it delivers that in ~11.5 kB.
The JPEG XL will get a BlurHash-like preview on display in ~2 kB, but it surely takes till ~63 kB to match the preview high quality of the AVIF. After that, it continues to enhance regularly, offering a extra detailed and better high quality picture as extra information arrives.
However, I’m not satisfied it is a good consumer expertise, because it presents the consumer with one thing they could mistake for fully-loaded, however poor high quality. For instance:
Here’s a crop of the JPEG XL, 80% loaded. It appears cheap that somebody would take a look at that, and simply assume I took the image badly, leaving elements out of focus. You might most likely persuade me that blurring the ApeCoin brand is a societal profit, but it surely nonetheless seems like a suboptimal consumer expertise.
AVIF’s system offers me extra management, but it surely’s additionally extra advanced.
Progressive overhead
I encoded the massive F1 picture with and with out progressive rendering enabled, adjusting the standard setting to maintain the SSIMULACRA2 rating round 70:
- With libjxl, progressive is mainly free. In truth, it produced information 6–10% smaller. At default effort, it was additionally sooner to encode, and used much less reminiscence. Decoding was ~10% sooner in Firefox, however 12–20% slower in Chrome and Safari.
- With jixel, it depends upon the trouble. For jixel, I used progressive DC, with the centre of the picture loading first. At jixel’s default (‘quick’), progressive made the file 12% greater. At ‘extraslow’, it made the file 10% smaller, and 11% sooner to encode, though it used 17% extra reminiscence. Decoding was barely affected, aside from being 7–9% slower in Chrome.
- But ColorationVideoVDP is much less sort to progressive jixel. It charges jixel’s progressive information barely decrease than the non-progressive variations, whereas it charges libjxl’s progressive information barely larger. Taking that under consideration, progressive jixel at ‘extraslow’ is barely ~2% smaller than non-progressive, and at ‘quick’ it is round 18% greater.
- Regular progressive AVIF has an even bigger price relating to encoding. It makes use of round twice the reminiscence, and at default effort (s6), it takes twice as lengthy to encode. At s0, encode time is barely 9% longer, however the file is 14% greater. And that is pure encode time – it does not consider the way you may generate the preview body, e.g. including some blur.
- Regular progressive AVIF is 29–44% slower to decode in Chrome, though the distinction is smaller in different browsers (6–15%). Since Chrome is the one browser that helps rendering the progressive frames, which may clarify it. Although Firefox and Safari are nonetheless having to decode the progressive body, as the primary picture builds upon it.
- With AVIF, making the ultimate body a keyframe fixes the decoding overhead, at the price of an extended encode time. At most effort, it ends in a smaller file too, solely 3–5% greater than the non-progressive model. You might name this dishonest, as there’s now no ‘development’ by way of information – it is simply two pictures in a single. But, if it is a greater consumer expertise, who cares?
- Even with the overhead, progressive AVIF wins on decoding time, and often on file dimension. The progressive AVIFs are 152–181 kB. jixel’s ‘extraslow’ progressive JPEG XL is in that vary at 166 kB, however jixel’s default produces 252 kB, and libjxl’s progressive information are 233–242 kB. The AVIFs decode 1.6–6x sooner, with the most important hole in Safari, which is especially gradual to decode jixel’s information.
Show me the info!
| Encoding | Quality | File dimension | SSIMU2 | Encode | Decode | |||
|---|---|---|---|---|---|---|---|---|
| Time | Memory | Firefox | Chrome | Safari | ||||
| AVIF s6 | 41 | 175 kB | 69.9 | 405 ms | 381 MB | 46 ms | 41 ms | 53 ms |
| AVIF s6 prog | 42 | 173 kB | 70.2 | 815 ms | 764 MB | 49 ms | 53 ms | 56 ms |
| Change | +1 | −1% | +0.3 | +101% | +101% | +7% | +29% | +6% |
AVIF s6 prog -k |
42 | 181 kB | 70.3 | 1.09 s | 740 MB | 45 ms | 35 ms | 49 ms |
| Change | +1 | +3% | +0.4 | +169% | +94% | −2% | −15% | −8% |
| AVIF s0 | 41 | 145 kB | 69.9 | 8.00 s | 450 MB | 47 ms | 41 ms | 48 ms |
| AVIF s0 prog | 42 | 165 kB | 70.5 | 8.71 s | 847 MB | 54 ms | 59 ms | 52 ms |
| Change | +1 | +14% | +0.6 | +9% | +88% | +15% | +44% | +8% |
AVIF s0 prog -k |
41 | 152 kB | 69.6 | 10.72 s | 798 MB | 47 ms | 40 ms | 46 ms |
| Change | ±0 | +5% | −0.3 | +34% | +77% | ±0% | −2% | −4% |
| JPEG XL e7 | 35.5 | 258 kB | 70.0 | 1.62 s | 2.49 GB | 131 ms | 105 ms | 162 ms |
| JPEG XL e7 prog | 25.3 | 233 kB | 70.0 | 1.40 s | 1.90 GB | 119 ms | 121 ms | 183 ms |
| Change | −10.2 | −10% | ±0.0 | −14% | −24% | −9% | +15% | +13% |
| JPEG XL e10 | 41.2 | 258 kB | 70.0 | 22.74 s | 5.67 GB | 132 ms | 107 ms | 162 ms |
| JPEG XL e10 prog | 30.2 | 242 kB | 70.0 | 25.54 s | 6.08 GB | 119 ms | 128 ms | 181 ms |
| Change | −11.0 | −6% | ±0.0 | +12% | +7% | −10% | +20% | +12% |
| jixel quick | 66.1 | 225 kB | 70.0 | 304 ms | 361 MB | 131 ms | 89 ms | 281 ms |
| jixel quick prog | 60.1 | 252 kB | 70.0 | 333 ms | 393 MB | 132 ms | 97 ms | 290 ms |
| Change | −6.0 | +12% | ±0.0 | +10% | +9% | +1% | +9% | +3% |
| jixel extraslow | 65.1 | 185 kB | 70.0 | 16.75 s | 7.61 GB | 141 ms | 92 ms | 294 ms |
| jixel extraslow prog | 55.4 | 166 kB | 70.0 | 14.90 s | 8.94 GB | 140 ms | 98 ms | 293 ms |
| Change | −9.7 | −10% | ±0.0 | −11% | +17% | −1% | +7% | ±0% |
Let’s get again to lossy compression, however this time HDR! There are a couple of methods to encode HDR pictures, and we will take a look at two.
Perceptual Quantization (PQ) tells every pixel what to be. Each worth maps to an absolute brightness, as much as 10,000 nits, with the curve formed so the info is spent the place our eyes are most delicate. If the picture asks for colors and brightnesses the show cannot present (no shopper show can hit 10,000 nits), the browser/OS has to tone-map it down, and the way effectively that is carried out varies between platforms.
Gain maps are completely different. The primary picture is an everyday SDR picture (often), and alongside it’s a ‘acquire map’, which applies a brightness and color change to every pixel to attain the HDR model.
This has two advantages:
- The similar picture will look precisely as you need on an SDR show – the acquire map is just ignored.
- If the show helps HDR, however possibly not as a lot because the picture wants (for instance, the display is at low or most brightness), the browser/OS can apply as a lot of the acquire map as it could actually deal with.
CSS and allow us to serve an SDR or PQ picture to the consumer through the dynamic-range media query, however then you definately’re counting on tone mapping in instances the place the browser indicators HDR assist, but it surely does not assist the complete vary.
Although the JPEG XL format helps acquire maps, no browser handles them, and the encoding story is messy.
AVIF helps acquire maps, and also you encode them by offering two pictures: the SDR picture and the HDR picture. It makes use of these to calculate and encode the acquire map.
Your browser/display does not assist HDR, so the PQ pictures will look unhealthy.
At medium brightnesses, on an HDR display, the acquire map and PQ pictures look the identical. At most brightnesses, on my Pixel 10 Pro and 2024 MacBook Pro, the PQ pictures get a bit blown out, and the acquire map picture appears to be like higher. At low brightness on my Pixel 10 Pro, once more the acquire map picture appears to be like higher.
This is as a result of, at excessive brightness ranges, the machine does not have the complete HDR headroom to show the picture, and acquire maps can deal with these instances higher. So, though acquire maps appear so as to add loads to the file dimension, I feel it is price it.
Maybe there is a future the place tone mapping will get significantly better, and the benefit of a acquire map turns into much less important.
Regular SSIMULACRA2 solely understands SDR, so for this picture, the scores come from an experimental HDR mode in fast-ssim2. That means these scores cannot be in comparison with the SSIMULACRA2 scores elsewhere on this article. ColorationVideoVDP handles HDR natively, and right here it is modelling a 1,500 nit HDR monitor.
The two metrics disagree loads with this picture. And they do not consider the advantages of acquire maps, so deal with these outcomes as a comparability between the PQ variants:
- File dimension: JPEG XL wins, however the metrics disagree on how a lot, and with which encoder.
- According to HDR SSIMULACRA2, jixel’s default ranges from 8% smaller to three% bigger than PQ AVIF’s default, and libjxl is 5–33% bigger. At most efforts, jixel ‘extraslow’ is as much as 15% smaller than PQ AVIF s0.
- According to ColorationVideoVDP, libjxl is the clear winner. At default efforts, it is 28–53% smaller than PQ AVIF, and 17–37% smaller than acquire map AVIF. At most efforts, it is as much as 23% smaller than the most effective AVIF, however jixel ‘extraslow’ is roughly stage with it, starting from 12% smaller to 14% bigger.
- The metrics additionally disagree about acquire maps. HDR SSIMULACRA2 says acquire map AVIF is 31–38% bigger than PQ AVIF, however ColorationVideoVDP says acquire map AVIF is 11–25% smaller than PQ AVIF.
- Encode time: JPEG XL (jixel) wins. At default efforts, jixel is ~2x sooner than PQ AVIF, and produces information across the similar dimension or smaller, relying on the metric. libjxl’s default is 5–47% slower than PQ AVIF, however given ColorationVideoVDP’s view of the file sizes, that is an inexpensive commerce. Gain map AVIF is the slowest, because it’s calculating a acquire map, then primarily encoding two pictures: ~3x slower than PQ AVIF.
- Encode reminiscence: JPEG XL (jixel) wins. At default efforts, jixel makes use of ~30% much less reminiscence than PQ AVIF. libjxl’s default makes use of ~1.9x the reminiscence of PQ AVIF, and acquire map AVIF makes use of ~1.55x. At most efforts, libjxl makes use of ~6x the reminiscence of PQ AVIF’s default, and jixel ‘extraslow’ makes use of ~10x.
- Decode time: AVIF wins. PQ and acquire map AVIF decode at across the similar pace. JPEG XL takes 1.2–1.7x as lengthy to decode in Chrome, though it is barely sooner on the prime of the standard vary. In Safari, it takes 1.6–3x as lengthy. Firefox is especially gradual with these HDR JPEG XL pictures, taking ~4x so long as AVIF in any respect qualities. We’re working on it.
- Higher effort is price it for AVIF. For acquire map AVIF, s5 will get you 9–12% smaller information for ~1.9x the encode time, and s0 will get you 14–20% smaller information for ~11x the encode time. For PQ AVIF, s0 will get you 14–19% smaller information, for 17–20x the encode time.
- Higher effort is price it for jixel, as much as ‘gradual’. ‘gradual’ will get you 7–32% smaller information than its default ‘quick’, for ~3.8x the encode time. ‘extraslow’ saves one other 1–9%, however takes ~10x longer than ‘gradual’ and makes use of ~8.5x the reminiscence. jixel solely has a couple of information factors for this picture, so these numbers are tough.
- Higher effort is not price it for libjxl. libjxl’s most effort will get you 2–7% smaller information than its default, however takes ~15x longer.
It can be attention-grabbing to see how JPEG XL handles acquire maps as soon as they’re totally supported.
By the way in which, these are indicators that indicate whether my cats are inside or outside, and the little show signifies how lengthy till their subsequent automated feed.
Show me the graphs!
Image quality
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB
0102030405060708090
SSIMULACRA2 (larger is nearer to the unique)
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB
9.009.109.209.309.409.509.609.709.809.9010.00
ColorationVideoVDP, JOD (10 = no seen distinction)
Encoding performance
Encode time
0 ms2 s4 s6 s8 s10 s12 s
0102030405060708090
SSIMULACRA2 (larger is nearer to the unique)
Encoding memory usage
Peak encoder reminiscence
0 MB200 MB400 MB600 MB800 MB1000 MB1200 MB1400 MB1600 MB1800 MB2000 MB
0102030405060708090
SSIMULACRA2 (larger is nearer to the unique)
Decoding performance
Decode time
10 ms20 ms30 ms40 ms50 ms60 ms70 ms80 ms
0102030405060708090
SSIMULACRA2 (larger is nearer to the unique)
JPEG XL means that you can convert an present JPEG to JPEG XL with out extra loss. I examined this with the F1 picture at a variety of sizes and JPEG qualities:
- The JPEG XL is 9–20% smaller than the JPEG. The saving grows with decision, from ~9% at 400 pixels vast to ~20% at 4,900 pixels vast. The saving is barely smaller at larger JPEG qualities. libjxl and jixel produce virtually similar file sizes.
- For small pictures, JPEG XL is slower to decode than JPEG, taking 1.4–2.7x as lengthy, relying on the browser. But it is only a millisecond or two.
- For bigger pictures, JPEG XL is quicker to decode in Chrome and Safari. From ~1,000 pixels vast, it matches JPEG, and on the largest sizes, it decodes in round half the time. In Firefox, it finally ends up across the similar pace as JPEG.
- jixel’s output is barely slower to decode than libjxl’s in Chrome and Firefox, by as much as ~25%. But once more, these are small numbers, at most a couple of milliseconds.
Of course, if in case you have the unique, you would be manner higher off creating a correct new lossy model with AVIF or JPEG XL, but it surely’s fairly cool that the JPEGs find yourself smaller, and typically sooner to decode. Although, I suppose that is simply pointing to a lacking optimisation in browser JPEG decoders.
Show me the graphs!
File dimension
0 kB100 kB200 kB300 kB400 kB500 kB600 kB
0246810121416
Megapixels
Decode time
0 ms10 ms20 ms30 ms40 ms50 ms60 ms
0246810121416
Megapixels
It may be very uncommon to wish lossless pictures on the net. As we have already seen, even for issues like screenshots and illustrations, lossy AVIF handles them very well. Ironically, this web page is without doubt one of the outliers, as a result of I wished to point out the compressed variations vs their lossless counterparts. Thankfully, JPEG XL is nice at lossless!
The outcomes:
- File dimension: JPEG XL wins. At default efforts, libjxl produces the smallest information for each picture besides the illustration, the place WebP matches it. WebP is 9–17% bigger for photographs, and AVIF is 33–122% bigger. At highest efforts, libjxl and jixel are inside a couple of p.c of one another, WebP is 5–44% bigger, and AVIF is 29–176% bigger.
- Encode time: JPEG XL wins. libjxl’s default takes 0.1–0.5 seconds, which is quicker than WebP’s default, and just like AVIF’s default, whereas producing smaller information than each.
- Encode reminiscence: JPEG XL wins or WebP wins, relying on the picture. WebP’s default makes use of round half the reminiscence of libjxl’s default (55–110 MB vs 110–250 MB), however libjxl’s information are smaller. For photographs, WebP cannot match libjxl’s default file dimension even at its most effort, which makes use of extra reminiscence than libjxl’s default. For the screenshot, they use across the similar reminiscence, however libjxl’s file is smaller. The illustration is the exception: WebP’s most effort produces a file 20% smaller than libjxl’s default, utilizing the identical reminiscence.
- Decode time: WebP wins or JPEG XL wins, relying on the picture. WebP decodes photographs in 17–39 ms in all browsers, and the screenshot in ~5 ms. libjxl’s output takes 1–2.2x as lengthy in Chrome, 1.4–2.7x as lengthy in Firefox, and a couple of.1–3.2x as lengthy in Safari. But for photographs, JPEG XL’s smaller information greater than make up for this on a primary load, until the connection is de facto quick. For the screenshot and illustration, WebP’s decode benefit wins. Lossless AVIF is especially gradual to decode, taking as much as 4x so long as libjxl’s output in Chrome.
- Lossless AVIF is unhealthy. It’s considerably bigger than the others, and slower to decode.
- jixel’s ‘medium’ setting is the candy spot for file dimension. It beats libjxl’s default on each picture (0.5–23% smaller), and is inside 2–3% of the most effective end result for photographs, taking 0.4–0.7 seconds. But it makes use of 470–670 MB of reminiscence, and its output is slower to decode than libjxl’s, significantly in Safari.
- jixel’s ‘gradual’ and ‘extraslow’ output may be very gradual to decode for photographs. ~200–290 ms, in comparison with 22–95 ms for libjxl’s output. That’s 2–13x slower, relying on the browser. It’s additionally gradual for the alpha picture, at 80–123 ms in comparison with 14–27 ms for libjxl’s output. This does not occur with the screenshot and illustration. This means, for my use-case on this web page, I’d keep away from it.
- libjxl’s most effort may be very gradual. It produces information 2–7% smaller than its default for photographs, and ~25% smaller for the screenshot and illustration, however takes 9–46 seconds, which is 50–180x so long as its default. jixel will get the identical ends in a few seconds.
- jixel’s default ‘quick’ setting is not nice for lossless. It’s the quickest encoder by far (40–80 ms), however its information are 16–32% bigger than libjxl’s default for photographs, and ~80% bigger for the screenshot and illustration.
- jixel’s patches characteristic helps a bit with the screenshot (4–9% smaller), however makes no distinction to the illustration.
Show me the info!
File size
| Image | Default effort | Highest effort | ||||||
|---|---|---|---|---|---|---|---|---|
| libjxl | jixel | WebP | AVIF | libjxl | jixel | WebP | AVIF | |
| F1 | 1.07 MB | +32% | +16% | +49% | 1.01 MB | −1% | +20% | +47% |
| People | 1.39 MB | +22% | +17% | +49% | 1.34 MB | −1% | +19% | +44% |
| Red panda | 1.78 MB | +17% | +9% | +40% | 1.74 MB | −1% | +11% | +31% |
| Weasel | 2.91 MB | +16% | +13% | +96% | 2.79 MB | −2% | +17% | +29% |
| Screenshot | 92 kB | +81% | +9% | +122% | 68 kB | +6% | +44% | +176% |
| Illustration | 361 kB | +78% | −1% | +100% | 273 kB | −6% | +5% | +139% |
| Alpha | 522 kB | +21% | +12% | +33% | 487 kB | −3% | +13% | +32% |
Encoding performance
File dimension
1 MB1.1 MB1.2 MB1.3 MB1.4 MB1.5 MB1.6 MB
0 ms5 s10 s15 s20 s25 s30 s
Encode time
Encoding memory usage
File dimension
1 MB1.1 MB1.2 MB1.3 MB1.4 MB1.5 MB1.6 MB
0 MB100 MB200 MB300 MB400 MB500 MB600 MB700 MB800 MB900 MB1000 MB
Peak encoder reminiscence
Decoding performance
File dimension
1 MB1.1 MB1.2 MB1.3 MB1.4 MB1.5 MB1.6 MB
0 ms20 ms40 ms60 ms80 ms100 ms120 ms140 ms160 ms180 ms200 ms220 ms240 ms
Decode time
Animated picture codecs are dumb and animated JPEG XL isn’t any exception. Video codecs are higher at video. They’re constructed for it. They’re optimised for it. Not simply by way of encoding, but in addition by way of playback.
I encoded a brief clip, and the animated AVIF was 725 kB, and the JPEG XL was 2.17 MB for a similar ColorationVideoVDP rating (9.5).
The JPEG XL is tremendous noisy in comparison with the AVIF, as a result of every body is encoded individually, and arttifacts land elsewhere per body.
AVIF is mainly the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF nonetheless, is just about only a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and again losslessly – it is only a container change. That’s why it performs so significantly better, as a result of it is constructed for movement.
However, animated AVIF performs like shit in Chrome and Safari. It’s high quality in Firefox, so that is purely an implementation drawback. But… is correct there.
The attention-grabbing element of animated AVIF is that it helps transparency, whereas AV1 video does not. But actually, that simply highlights that it’s dumb that AV1 didn’t support transparency.
No, I’m not including a demo. I do not need it on my server. Use video codecs for video.
I already gave you my conclusions firstly, so I assume I’m able to hit publish.
I’m slightly nervous about this, as a result of discourse round JPEG XL can get slightly… bizarre. I see quite a lot of conspiracy theories about Google attempting to ‘silence’ JPEG XL, though one of many leads of the undertaking labored at Google, as a part of a group that have been engaged on JPEG XL. That same leader claimed that the post-COVID layoffs would not have occurred if corporations merely used JPEG XL. I used to be lately called a racist for asking about JPEG XL use-cases. This sort of factor simply does not occur with different applied sciences and requirements I comply with. So, urm, I’m kinda bracing for influence right here.
My first model of this text was very adverse about JPEG XL, however then I heard about jixel, and truthfully, I’m actually enthusiastic about it. There’s critical competitors between AVIF and JPEG XL now, and whoever wins, we’ll all profit from higher picture compression.
