Results 1 to 28 of 28

Thread: JPEG XL vs. AVIF

  1. #1
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts

    JPEG XL vs. AVIF

    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.

  2. Thanks:

    Jyrki Alakuijala (25th May 2020)

  3. #2
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    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.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	jpegXR-avif.jpg 
Views:	125 
Size:	282.8 KB 
ID:	7624  

  4. #3
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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).

  5. #4
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  6. #5
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Thanks Jyrki. Is XL going into cameras?

  7. #6
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  8. #7
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    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.

  9. #8
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  10. #9
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    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?

  11. #10
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Quote Originally Posted by DZgas View Post
    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?

  12. #11
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    Quote Originally Posted by SolidComp View Post
    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.

  13. #12
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    I'm not an expert on jpeg xt. Xt is likely a HDR patch on usual jpegs. Not particularly effective at compression density.

  14. #13
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  15. #14
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  16. #15
    Member
    Join Date
    May 2018
    Location
    Turkey
    Posts
    2
    Thanks
    62
    Thanked 2 Times in 1 Post
    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.

  17. Thanks (2):

    Jyrki Alakuijala (28th May 2020),Piglet (25th May 2020)

  18. #16
    Member
    Join Date
    Nov 2019
    Location
    Moon
    Posts
    31
    Thanks
    8
    Thanked 32 Times in 20 Posts
    How JPEG XL Compares to Other Image Codecs
    https://cloudinary.com/blog/how_jpeg...r_image_codecs

  19. Thanks (3):

    Hakan Abbas (26th May 2020),Jan Wassenberg (27th May 2020),Jyrki Alakuijala (26th May 2020)

  20. #17
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    Quote Originally Posted by Hakan Abbas View Post
    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.
    Last edited by Jyrki Alakuijala; 28th May 2020 at 13:33.

  21. Thanks:

    Hakan Abbas (28th May 2020)

  22. #18
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    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...
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Lenna_tests_q100_jpeg444.jpg 
Views:	46 
Size:	1.95 MB 
ID:	7765  

  23. #19
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  24. #20
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    With this quality (1 BPP) JpegXL is indistinguishable from AVIF.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Lenna_1bpp.png 
Views:	39 
Size:	969.2 KB 
ID:	7766  

  25. #21
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    JpegXL at maximum presset is so slow, same AVIF.

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

  26. #22
    Member
    Join Date
    Nov 2013
    Location
    Kraków, Poland
    Posts
    786
    Thanks
    240
    Thanked 251 Times in 155 Posts
    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

  27. Thanks:

    Piglet (Yesterday)

  28. #23
    Member
    Join Date
    Nov 2011
    Location
    france
    Posts
    65
    Thanks
    7
    Thanked 38 Times in 28 Posts
    Quote Originally Posted by DZgas View Post
    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...

  29. Thanks:

    Jyrki Alakuijala (Yesterday)

  30. #24
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    Perhaps it is just me, but I see differences.

  31. #25
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    Quote Originally Posted by skal View Post
    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.

  32. #26
    Member DZgas's Avatar
    Join Date
    Feb 2020
    Location
    Russia
    Posts
    34
    Thanks
    14
    Thanked 10 Times in 7 Posts
    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.
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Van_Gogh_Starry_Night.jpg 
Views:	29 
Size:	1.34 MB 
ID:	7775  

  33. Thanks (2):

    Hakan Abbas (Today),Jyrki Alakuijala (Today)

  34. #27
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    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.

  35. #28
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    841
    Thanks
    241
    Thanked 308 Times in 184 Posts
    Quote Originally Posted by DZgas View Post
    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.

  36. Thanks:

    Hakan Abbas (Today)

Similar Threads

  1. JPEG issues a draft call for a JPEG reference software
    By thorfdbg in forum Data Compression
    Replies: 11
    Last Post: 19th April 2017, 16:18
  2. JPEG XT Demo software available on jpeg.org
    By thorfdbg in forum Data Compression
    Replies: 40
    Last Post: 16th September 2015, 15:30
  3. Replies: 9
    Last Post: 11th June 2015, 23:28
  4. Replies: 0
    Last Post: 6th February 2015, 05:57

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •