Announcement

Collapse
No announcement yet.

Firefox 92 To Try Again With AVIF Image Support By Default

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

  • #11
    Originally posted by birdie View Post
    As far as I understand Google is keen to push WEBP 2 instead of AVIF while VVC in HEIC is a much better option.
    webp2 isn't even ready yet.

    Comment


    • #12
      I highly respect what the people behind it have down and the effort they put in. But it's not supported om Mac so it's basically useless on the web. How many times has Apple gotten in the way of us being able to have nice things?

      Comment


      • #13
        Why not just enable it by default instead of waiting years to do so after long discussions?
        If it works well, then come on!

        Comment


        • #14
          Originally posted by arun54321 View Post
          Jpeg xl is much better than avif. They should enable it on release builds.
          I have personally found JPEG XL very underwhelming.

          Its encoding speeds are (usually) faster than AVIF's, but they're still far too slow and resource-hungry to be practical in most use cases.

          In terms of compression, it wins some and loses some, just like every other format. From my own testing, JPEG XL usually falls somewhere between WebP and AVIF.

          The problem is each new image format has to be that much better than all previous formats to justify their existence in HTML contexts. Take the following, for example:

          HTML Code:
          <picture>
              <source src="image.avif" type="image/avif">
              <source src="image.jxl" type="image/jxl">
              <source src="image.webp" type="image/webp">
              <source src="image.jpg" type="image/jpeg">
          </picture>
          No browser would ever load the JPEG XL source from that list. It's a problem of chronology. If a browser supports JPEG XL, it would also support the older AVIF format, and so would just load that instead.

          The story is the same for AVIF and WebP.

          WebP has it relatively easy. It only needs to out-compete the original GIF/PNG/JPEG source to justify its existence, which it can usually (but not always!) do.

          AVIF, arriving a bit later, needs to beat both WebP and the original GIF/PNG/JPEG source. Again, it can usually (but not always) manage this.

          JPEG XL, being the newest, has to beat AVIF and WebP and GIF/PNG/JPEG. That's a tall order. Except in a few specialized cases, it doesn't usually manage that.

          Of course, the story changes if you completely throw out a format. If you ignore AVIF, JPEG XL offers a reasonably consistent improvement over WebP. But then you're just serving larger images.

          Comment


          • #15
            There is no need to use avif unless you're interested in low fedility and heavy compression ( things may look artificial / plastic-ky or blurry at that range). Also avif performs worse on lossless mode, no progressive decoding. no 16bit support. Takes too much time and memory to encode. it's still better than existing formats like heif & webp but no better than jpeg-xl. Only thing I find avif performs better than jxl is synthetic/anime content.

            Comment


            • #16
              Originally posted by tildearrow View Post
              Why not just enable it by default instead of waiting years to do so after long discussions?
              If it works well, then come on!
              AVIF is a very complicated format, supporting all sorts of different color spaces, matrices, transforms, etc. The details of all of those configurations are stored in various HEIF headers that may or may not exist — encoding support for AVIF is terrible everywhere — making "correct" rendering very challenging. Add to this the fact that portions of the spec are locked behind a paywall, it's not an ideal situation for open source.

              The decoding support that has been in Firefox the past few releases (behind a feature flag) only really handles limited-range Y'CbCr correctly. It will still render greyscale, full-range RGBA, lossless, etc., but with the wrong algorithms applied, resulting in all sorts of distortion and quality loss.

              Presumably decoding support has been expanded to cover a wider swath of the potential ways-to-be-AVIF, which is why that flag is back up for promotion to default.

              Comment


              • #17
                Originally posted by arun54321 View Post
                There is no need to use avif unless you're interested in low fedility and heavy compression ( things may look artificial / plastic-ky or blurry at that range). Also avif performs worse on lossless mode, no progressive decoding. no 16bit support. Takes too much time and memory to encode. it's still better than existing formats like heif & webp but no better than jpeg-xl. Only thing I find avif performs better than jxl is synthetic/anime content.
                AVIF's lossless mode is a joke. You're right about that! If the goal is true lossless representation, WebP and JPEG XL are the way to go. They trade victories back and forth pretty equally depending on the nature of the image source, though. I would have expected more from JPEG XL given more than a decade separates the two.

                The "blurring" AVIF is famous for depends on a lot of factors. Most encoders support parallel tiling optimizations to make its encoding time slightly more bearable, but that negatively affects both quality and size. To get the "best" AVIF, you really need to cycle through every possible combination of quantizer and color mode (with tiling), visually inspect each — DSSIM doesn't cut it — then rerun the best combination without tiling. Sometimes you also need to add or remove pixels to the width or height to make the dimensions more division-friendly. (The latter hack can make a surprisingly huge difference in select cases.)

                Encoder support for AVIF is (still) really bad, so the situation can be quite different depending on the software being used.

                My statements come from using https://github.com/Blobfolio/refract, which implements libwebp, libavif (w/ rav1e), and libjxl directly.

                I spent hours hand-tuning every image on my web sites, aiming for "visually indistinguishable" lossy compression. For those specific image sets — which for better or worse are the sets I actually care about optimizing — AVIF came out smallest about half the time, and WebP and JPEG XL split the remaining victories, minus a few edge cases where the original JPEG/PNG/GIF sources actually remained the best.

                The situation played out differently when I tested "good enough" lossy compression. In that case, good ol' WebP proved best. AVIF tended to be too smudgey at low quality, while JPEG XL tended toward ugly, sharp-edged artifacting.

                Comment


                • #18
                  Originally posted by jstoik View Post
                  My statements come from using https://github.com/Blobfolio/refract, which implements libwebp, libavif (w/ rav1e), and libjxl directly.
                  rav1e is literally the worst encoder right now in both speed and quality from my experience, you would be best to use aomenc

                  Comment


                  • #19
                    AVIF is great. fidelity wise its better than webp in lossy scenarios, but more than that It is absolutely phenomenal for animations. Most of the work for implementing Av1 is directly compatible with avif, as avif is literally just an mp4 encoded with av1. this makes avif the best for being a gif alternative as in can use pretty much the full might of av1 in encoding it.

                    unlike jpeg-xl most of the work implementing it, as I said, was already done by implementing av1 support in browsers. and considering that the industry is heading that way as it is currently the best commercially viable video codec, it makes less sense to not implement. hopefully 92 will have image sequence support. what gif can do in 20Mb avif can do in less than 2Mb. a great file savings, and considering the popularity of gifs, an alternative like this is nice to have.

                    Comment


                    • #20
                      Originally posted by Quackdoc View Post
                      rav1e is literally the worst encoder right now in both speed and quality from my experience, you would be best to use aomenc
                      Ooh, thanks for the tip! AOM is significantly faster!

                      Comment

                      Working...
                      X