Announcement

Collapse
No announcement yet.

Netflix Now Exploring AVIF For Image Compression

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Netflix Now Exploring AVIF For Image Compression

    Phoronix: Netflix Now Exploring AVIF For Image Compression

    Following Netflix's AV1 adoption with collaborating with Intel on the SVT-AV1 encoder, now using AV1 streaming for Android users, and others around this advanced royalty-free video codec, Netflix is now exploring AVIF as their next-gen image format...

    http://www.phoronix.com/scan.php?pag...ge-Compression

  • #2
    They mentioned JPEG XL very briefly, which is the next-gen image codec I believe will have the most traction. It has great lossy and lossless compression, and a great upgrade path from standard jpeg in that in can losslessly recompress jpeg into the JPEG XL format with a 20% size reduction.

    It is currently in late stage standardization, which I suppose means it should be standardized within this month.

    That said, I wouldn't mind a AV1 based format becoming the next-gen standard either, as long as they are royalty free and offer a substantial improvement over current de facto standards, I'm a happy camper.

    Comment


    • #3
      Pretty low-quality/unrepresentative comparison done by Netflix, see: https://www.reddit.com/r/AV1/comment..._image_coding/

      Comment


      • #4
        AVIF is the AV1 Image File Format that reached v1.0 last year and is based on AV1 design concepts while using the HEIF file format
        So is it a file format or is it using a pre-existing format? It can be both at the same time, can it?

        Comment


        • #5
          Originally posted by bug77 View Post
          So is it a file format or is it using a pre-existing format? It can be both at the same time, can it?
          AFAIK is HEIF more like the container and AVIF is AV1 as a single image, like a AV1 video can be used in mkv/webm or mp4 container

          In the area of image coding formats, the Moving Picture Experts Group (MPEG) has standardized a codec-agnostic and generic image container format: ISO/IEC 23000–12 standard (a.k.a. HEIF). HEIF has been used to store most notably HEVC-encoded images (in its HEIC variant) but is also capable of storing AVC-encoded images or even JPEG-encoded images.
          Last edited by Toggleton; 02-15-2020, 11:08 AM. Reason: added quote

          Comment


          • #6
            Originally posted by Grinch View Post
            They mentioned JPEG XL very briefly, which is the next-gen image codec I believe will have the most traction. It has great lossy and lossless compression, and a great upgrade path from standard jpeg in that in can losslessly recompress jpeg into the JPEG XL format with a 20% size reduction. It is currently in late stage standardization, which I suppose means it should be standardized within this month.
            JPEG-XL ist too little, too late - and the JPEG brand is tainted by low image quality and hacks like JPEG-XR. WebP has very good lossless compression, but mediocre lossy compression sinde it's based on the outdated VP8. As most of the industry is behind AV1, I guess it'll be .avif from now on - and it's contain further codec updates like AV2, AV3, ...

            Comment


            • #7
              It's cool to see proper video compresison being used for images. I hope it will be used for animated images kind of like how webp can be used.

              Comment


              • #8
                Originally posted by Marsu42 View Post

                JPEG-XL ist too little, too late - and the JPEG brand is tainted by low image quality and hacks like JPEG-XR. WebP has very good lossless compression, but mediocre lossy compression sinde it's based on the outdated VP8. As most of the industry is behind AV1, I guess it'll be .avif from now on - and it's contain further codec updates like AV2, AV3, ...
                Google is behind JPEG XL. All of their work on Pik has been folded into it. Given the advantages it has for losslessly repacking existing JPEGs, I would be very hesitant to write it off. The industry has shown us time and time again that it values compatibility more than anything.

                Comment


                • #9
                  Originally posted by Marsu42 View Post
                  JPEG-XL ist too little, too late
                  Compared to AVIF, JPEG-XL supports :
                  1) progressive decoding for responsive web images
                  -> consequently on low-resolution devices, browsers can download just part of the file
                  2) reversible compression of existing jpeg images
                  -> consequently a web server can on-the-fly serve a .jpeg version of .jpeg-xl in case browser doesn't support the latter.

                  If compression quality is comparable, I'd choose JPEG-XL any day over AVIF just based on these two features.

                  Edit:

                  For web developers and CDNs that is actually a HUGE difference.
                  It's not just how good the compression is, but how many files you need to produce and carry around.
                  A typical responsive website will need to render images in several resolutions:
                  -> 1) retina.avif, 2) hi-res.avif, 3) med-res.avif, 4) low-res.avif, 5) thumb.avif
                  Now double that and produce both .avif and .jpeg for the transition period until all browsers support avif:
                  -> 1) retina.avif, 2) hi-res.avif, 3) med-res.avif, 4) low-res.avif, 5) thumb.avif
                  -> 6) retina.jpeg, 7) hi-res.jpeg, 8) med-res.jpeg, 9) low-res.jpeg, 10) thumb.jpeg

                  All of that can be replaced with a single JPEG-XL.
                  Feel free to calculate the space-saving.
                  Last edited by pkese; 02-15-2020, 03:59 PM.

                  Comment


                  • #10
                    These are very shiny features and amazing tech, execpt that we're talking about _images_ and it's 2020, so storage and bandwidth concerns are not like in the 80s.

                    Originally posted by pkese View Post
                    1) progressive decoding for responsive web images
                    -> consequently on low-resolution devices, browsers can download just part of the file
                    There's already progsive jpeg - how widely is this used, and what does that say about real world damand?

                    Originally posted by pkese View Post
                    2) reversible compression of existing jpeg images
                    -> consequently a web server can on-the-fly serve a .jpeg version of .jpeg-xl in case browser doesn't support the latter.
                    I have to admit they've pulled a rabbit out of the hat with this, though it tookes decades after the original jpeg and failed jpeg2k

                    Originally posted by pkese View Post
                    For web developers and CDNs that is actually a HUGE differe
                    It's not just how good the compression is, but how many files you need to produce and carry around.
                    A typical responsive website will need to render images in several resolutions:
                    Somehow, I doubt that this is what your _typical_ website does.

                    As for Browser compatibilty - this certainly was a huge concern back in the day, when Internet Explorer took years to be phased out. But today, there are fewer browser engines, rolling releases, and general planned obsolescence - so a new format like isn't blocked by lack up browser updates for long.

                    Originally posted by pkese View Post
                    Feel free to calculate the space-saving.
                    Feel free to compare these space savings with the space and bandwith used for videos.

                    Another advantage of heif/avif is that multiple codecs are supported, and new codecs like VP2 will be supported for images, too. These will probably deliver some space savings for images, again... not that this would really matter vs. video codec use.

                    Comment

                    Working...
                    X