JPEG XL vs. AVIF

[SolidComp]

Hi all – I'm curious about any comparisons between JPEG XL and AVIF. What are the advantages and disadvantages of each? Which one is expected to be supported by web browsers?

Am I correct in understanding that JEPG XL can be used as an acquisition format, in cameras? To fully replace JPEG we need an in-camera format, not just a web format like webp.

Are either of these formats suitable for graphics (replacing PNG and webp), or just for photos?

JPEG XL page.

AVIF article.

[DZgas]

I did not try JPEGXL but already know that
AVIF is good for the Internet and Users
JPEGXL is good for archiving


The AVIF came out - I started testing it to compress photos, now I use JpegXR and after my tests I don’t go to AVIF

1. speed, huf this is a real death from old age if you wanted to compress a couple of hundreds of 4k photos! On my rather weak laptop it takes 5 minutes to compress a 1280x720 photo, JpegXR can in a two seconds. I know that AV1 is very slow. I did not know that it would take half an hour to compress one 4k photo from my smartphone...of course it cannot be used for real-time encoding for cameras!
2. without a doubt AVIF is better than JpegXR But I noticed that I really did not like it - the compression of dark and very little noticeable guards is just bad, But I would never have noticed it if I had not conducted tests...
Even when an AVIF weighs more than a JpegXR , the JpegXR keeps more details in these unimportant places.

AVIF is ideal for extra strong compression!
I replaced with AVIF everything where I used WEBP.

For archiving photos I use JpegXR but
In the future, when "someone" supports JpegXL, I will use it. I think XnView, as they did support AVIF, easy to watch, thanks for this.

Below is a photo are the same size, but AVIF want a “result without compression” in the visible areas, jpegXR spent the information on less important areas, which is much more important for me in the future.
Even if later I just want to highlight the photo, strong artifacts will be in AVIF.

[Jyrki Alakuijala]

With current encoders Jpeg xl performs better at 0.4 bpp and above, avif performs better at lower bpp, likely this will even out a bit when encoders mature, but some difference like that will remain because of different filtering techniques.

Jpeg xl is always at least 8x8 progressive (cannot be stored sequential in its file format), avif is always fully sequential (cannot be stored progressive in its file format).

[Jyrki Alakuijala]

Jpeg xl is favored more on butteraugli, ssimulacra and dssim, AVIF wins very clearly on psnr and vmaf. Jpeg xl tends to be more authentic, avif tends to be smoother and less artefacty. Jpeg xl is possibly better suited for portraits than avif (with current encoders).

Jpeg xl's performance, utilization domain, or features cannot be estimated from experiences with jpeg xr.

[SolidComp]

Thanks Jyrki. Is XL going into cameras?

[Jyrki Alakuijala]

It would be a great fit for high quality photographs. Currently cameras store somewhere around 4.5 bpp, and JPEG XL can give this kind of quality in 1.5 bpp. On the other hand some cameras will want to do less computation for compression, so likely we will end up somewhere around 2 bpp.

If I were a camera manufacturer I would not be leading the change. I'd wait that there is some deployment in more software-heavy technology: mobile phones, browsers, operating systems, servers, tools etc.

[DZgas]

Of course JpegXR is not JpegXL but can definitely say that AVIF will not be used in real time on cameras, it is Slowest.

AVIF is developed by Alliance for Open Media, which includes most large corporations. AVIF is well suited for everything on the Internet, photographs of articles, video previews, stickers, and everything else.

JpegXR has supported by Microsoft. You can view in the standard Windows photo viewer.

And JpegXL?...was released...But I think - no one noticed it. There are currently no user-friendly programs for encoding and viewing JpegXL.

[Jyrki Alakuijala]

Jpeg XL is not frozen yet. (Other than the jpeg repacking part of it.) Our freezing schedule is end of August 2020. Before that it is not a good idea to integrate for other than testing use.

[SolidComp]

Jyrki, is either JPEG XL or AVIF related to PIK? What became of PIK?

And I'm confused by JPEG XT – do you know if it's related to XL?

[SolidComp]

Of course JpegXR is not JpegXL but can definitely say that AVIF will not be used in real time on cameras, it is Slowest.

AVIF is developed by Alliance for Open Media, which includes most large corporations. AVIF is well suited for everything on the Internet, photographs of articles, video previews, stickers, and everything else.

JpegXR has supported by Microsoft. You can view in the standard Windows photo viewer.

And JpegXL?...was released...But I think - no one noticed it. There are currently no user-friendly programs for encoding and viewing JpegXL.

Yes, AVIF was not intended for cameras. The encoders are still incredibly slow, as are the encoders for AV1 video (though I think Intel's SVT AV1 encoder is improving). Do you know if the decoders are reasonably fast?

[DZgas]

Do you know if the decoders are reasonably fast?

I think - Large corporations did AV1 codec for self, not for users haha.
But decoding with the standard Dav1d is normal...if fact that my laptop can't VP9 1080p and AV1 720p and on the verge can HEVC 1080p. Problems of progress - I am slow.

Obviously AV1 is slowest codec and the strongest of all.
Encoding speeds are currently killing him.
Despite the fact that it is ~ 25% better than HEVC or VP9, ​​it is 10-20 times slower, this is serious for people who do not have powerful PC/Server.
Well, almost the Internet is still using the old AVC, because it’s fast and you can decode on Watch.

[Jyrki Alakuijala]

I'm not an expert on jpeg xt. Xt is likely a HDR patch on usual jpegs. Not particularly effective at compression density.

[Jyrki Alakuijala]

Pik is a superfast simple format for photography level qualities (1.5+ bpp), and gives great quality/density there. It used dct8x8.

The requirements for JPEG XL included lower rates, down to 0.06 bpp was discussed. Variable sizes of dcts and filtering improve the performance at lower bpps, and keep it at state-of-the art down to 0.4 bpp and somewhat decent at 0.15 bpp. This was adding a lot of code and 2x decoding slowdown to cover a larger bpp range.

Further, we integrated FUIF into PIK. We are still in the process of figuring out all the possibilities it brings. FUIF seems much less psycho usually efficient, but more versatile coding. Luca and Jon developed FUIF code further after integrating it into JPEG XL.

Jon has been in general great to collaborate with and I am quite proud for having made the initial proposals of basing JPEG XL on these two codecs. Everyone in the team has grown very comfortable with the fusion of these two codecs.

[Jyrki Alakuijala]

My basic understanding is that avif decoders are roughly half the speed of jpeg xl decoders. Getting the fastest avif decoding may require turning off some features that are always on in jpeg xl, for example no yuv444, no more than 8 bit of dynamics.

It may be that hardware decoders for avif may not be able to do streaming, i.e., to display that part of the image that is already decoded. For some applications this can be a blocker.

[Hakan Abbas]

In data compression, working speed is as important as compression rate. When looking at the sector, it is clearly seen that faster products are preferred even if they are low in efficiency.

It is not preferable to spend much more energy than necessary for a small data saving. No matter who is behind the product.

In most cases, while performing the calculations, the cost (cpu, ram ...) of these transactions is taken into consideration. Whenever possible, situations requiring excessive processing load are avoided. However, as we have seen, it cannot be said that attention is paid to these points for AVIF/AV1.

[Scope]

How JPEG XL Compares to Other Image Codecs
​https://cloudinary.com/blog/how_jpeg...r_image_codecs

[Jyrki Alakuijala]

In data compression, working speed is as important as compression rate. When looking at the sector, it is clearly seen that faster products are preferred even if they are low in efficiency.

There are two separate optimization goals:
S1. what is best for users, and
S2. what is easiest for webmaster (or other deployer of compression) to run business as usual.

For S1. we need to look at the whole information system and its efficiency and cost factors. Often we can find out by using simple economic modeling that the cost of having user time and attention is 1000x more value than the cost of computer. This is understandable in the light of computers and the energy consumed being a value of $1000 and a human having a value that trumps $1000000. Users can be blocked by two different things related to compression: data transfer payload size and excessive coding resource use, decoding speed, and rarely encoding, too.

Current compression methods in general are not spending enough CPU and memory in order to fully optimize for S1. That is because people also optimize for the S2.

For S2. People often consider compression separately, outside of the larger information processing system. Then they run a profiler, and see % values. Many engineers are willing to save 20 % of cpu speed while losing 5 % of density. The %-to-% comparison seems superficially like oranges-to-oranges comparison. They may however lack the knowledge that only the density modulates the user experienced speed, and that that cost is 1000x more than the cpu cost. They are able to transfer cost from their company to their clients. Also, these engineers may not have access even to data transfer costs, so that they could even do a pure cost based optimization with disregard to users. However, ignoring the users will cost the company revenue and growth. Saving a few thousand in compression cpu use can lead to a double digit revenue drop for a big e-commerce company.

I often see that junior engineers are very keen on the profile-based optimization and try to switch to faster compression algorithms that are only a few percent worse, and the more senior engineers with a holistic system point of view stop them -- or ask them to run an experiment to show that there is no negative effect on conversions/revenue/returning users etc.

For naive positioning based on S2, we will see many webservers configured with no compression or the ineffective gzip quality 1 compression.

[DZgas]

I finally got time to cjpegXL_jxl 0.0.1-e3c58a0a and did tests with strong compression...the result is strange.
JpegXL lost to all and brother 10 years ago - JpegXR.
Maybe I'm doing something wrong, or the codec is doing something wrong, or JpegXL can’t compress in this range...

[Jyrki Alakuijala]

What happens if you compress to 32 kB, i.e., 1 BPP.

Currently Internet compression averages at 2-3 BPP and cameras at 4-5 BPP.

JPEG XL attempts to create a good result if you ask it to compress at distance 1.

[DZgas]

With this quality (1 BPP) JpegXL is indistinguishable from AVIF.

[DZgas]

JpegXL at maximum presset is so slow, same AVIF.

For me - they are both the same Quality and Speed.
But jpegXL cannot strongest compress...

[Jarek]

Chrome and Firefox are getting support for the new AVIF image format

https://www.zdnet.com/article/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format/
https://news.slashdot.org/story/20/0...f-image-format

[skal]

I finally got time to cjpegXL_jxl 0.0.1-e3c58a0a and did tests with strong compression...the result is strange.
JpegXL lost to all and brother 10 years ago - JpegXR.
Maybe I'm doing something wrong, or the codec is doing something wrong, or JpegXL can’t compress in this range...

You should try with another test image, Lena has quite some problems (starting with being a bad old scan!).
Not that i expect different results, but Lena should really be forgotten for tests...
​

[Jyrki Alakuijala]

Perhaps it is just me, but I see differences.

[DZgas]

You should try with another test image, Lena has quite some problems (starting with being a bad old scan!).
Not that i expect different results, but Lena should really be forgotten for tests...
​

Well, all codecs can.
But with a low bitrate JpegXL cannot.
I just found this problem.
Average bitrate - JpegXL compress is good, same another codec.
Low bitrates - the quality of AVIF is undeniable.

[DZgas]

Another example for you, size files is 14 kb.
Coding time
43 sec JpegXL
39 sec AVIF
JepgXL save the few things that AVIF erased if viewed from far, comparing look of the original.
But AVIF save so many forms and it looks better, JpegXL looks bad.

[Jyrki Alakuijala]

Try using cjpegxl as follows:

$ cjpegxl input.png output.jxl

Try using 'cjpegxl --distance 1.5 input.png output.jxl' for slightly worse quality

Don't worry if cjpegxl runs fast, likely about 1000x faster than what you are experiencing. If you want slightly (10 % or so) higher quality, use the --speed kitten, still 100x faster than what you use.

[Jyrki Alakuijala]

Average bitrate - JpegXL compress is good, same another codec.
Low bitrates - the quality of AVIF is undeniable.

This is known. AVIF is currently better at low image quality. JPEG XL is currently better at medium and high image qualities, including the range of image quality used in the internet and the cameras today.

It is an interesting question if low image quality or medium to high image quality will matter more in the future. It is a complex dynamic of internet/mobile speeds developing, display resolution increasing, image formats driving the cost of quality lower, HDR, impact of image quality on commerce, progressive rendering, and other user related dynamics.

[DZgas]

Well, although JpegXL loses AVIF at a very strong compression... But at medium compression and higher JpegXL is wins.

I archivate photos(I compress the photos by about 40-50% of the uncompressed size, the JepgXR at quality 95 does it good.) And I waited for JepgXL to have a user-friendly interface...
"XnView Software" about JPEGXL — "it's planned for XnView MP". Is so good for user-friendly View.
Lately XnView added AVIF.
(2015)Of the newest and most advanced formats, Except WEBP, there was only JepgXR — was good for compressing all my archival photos.
AVIF came out, but it turned out to be completely unfit for this, even when its size was more than JepgXR, it loses ALL details just to save the Forms — this is very good visible on strongest compression, it is better than any existing codec in our time for small size image But for archiving, no.
But finally I reached the function --distance = maxError in JpegXL and this is exactly what I need!
(cjpegXL_jxl_0.0.1-e9464f40)

The most important thing is that compression is evenly distributed throughout the photo.
This is especially significant in very dark photographs.

AVIF at any settings Cuts off the dark areas, because of course — they cannot be seen.

JpegXR save them at very high settings 50% of size by uncompressed PNG.

JpegXL saving everything with a size 3 times lower than JpegXR. Very good for me.

[DZgas]

JpegXL does not have it makes no sense on the Internet, I did tests and I looked JpegXL is really better for photographs But, as I have seen in practice, at sizes over 3 bpp, when every pixel is important (which is what I need for archiving) But on the Internet I have notions I don’t have why I need it, but any test at bpp is less, if look, AVIF will always be better in any situation.

JpegXL
Not for art. (Absolutely.)
Nor for most internet image.
Not for Photos in internet. (But here you can discuss because of the example 10 Kb photo.)
AVIF for this...
JpegXL is good for camera...I am waiting JpegXL for photos in smartphones.
For images of satellites and telescopes...
For archiving (in my case JpegXL is best).

I'm sure JpegXL will never be added to browsers (by Mozilla, Google, Apple) because the fact — all browser companies are members of the Alliance for Open Media and they supports own AVIF.