Results 1 to 17 of 17

Thread: JPEG XL vs. AVIF

  1. #1
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    278
    Thanks
    109
    Thanked 51 Times in 35 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
    23
    Thanks
    7
    Thanked 7 Times in 5 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:	103 
Size:	282.8 KB 
ID:	7624  

  4. #3
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    278
    Thanks
    109
    Thanked 51 Times in 35 Posts
    Thanks Jyrki. Is XL going into cameras?

  7. #6
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    23
    Thanks
    7
    Thanked 7 Times in 5 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    278
    Thanks
    109
    Thanked 51 Times in 35 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
    278
    Thanks
    109
    Thanked 51 Times in 35 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
    23
    Thanks
    7
    Thanked 7 Times in 5 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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
    55
    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 (Yesterday),Piglet (25th May 2020)

  18. #16
    Member
    Join Date
    Nov 2019
    Location
    Moon
    Posts
    21
    Thanks
    5
    Thanked 24 Times in 13 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
    803
    Thanks
    232
    Thanked 291 Times in 173 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; Yesterday at 13:33.

  21. Thanks:

    Hakan Abbas (Yesterday)

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
  •