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

  • #31
    Originally posted by jstoik View Post
    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.)
    That reminds me PNG. PNG is just a custom zip container, you cannot expect getting more than a BMP or a TGA in a ZIP with a default PNG format. And almost all tools on earth just produce the default PNG format. PNG comes with a entire wagon of format variants you can combine to save more space, but to make use of it, you need an external optimizer tool (like pngcrunch, optipng/oxipng, pngwolf), then after that you can use a zopfli compressor to bruteforce the zip compression.

    I have a script that just calls pngcrunch, oxipng then a zopflied pngwolf on PNG files (maybe some of them are useless, I don't care, the longest thing is zopfli anyway), I usually get 20% file save in many minutes (sometime dozens) per image, while lossless WebP produce smaller and faster.

    And then, you have to check the software claiming to have PNG support really supports all the variants. I had one day to fix PNG support in a software (the NetRadiant level editor), and I had to produce a set of testing files making use of various PNG format variants to test them and debug the software. After that painful experience, I started to understand why Internet Explorer 6 did not fully supported PNG and I started to feel compassion for the developers of Internet Explorer 6. That says a lot.

    Comment


    • #32
      Originally posted by illwieckz View Post
      That reminds me PNG.
      It is exactly that like. PNG was the first big "kitchen sink" format that tried to do it all. And there are still cases where it does XYZ better than any of the even-more-convoluted next-gen formats.

      FYI, just in case you are using Oxipng's built-in Zopfli mode in your script, I would recommend running them separately. If you use Oxipng with its libdeflater option in one pass and a native zopflipng in a second, that will eek out more lossless savings and finish in about 1/10 the time. (The Zopfli Rust crate is incomplete and a bit stale; it can't compete with the original C/C++.)

      Comment


      • #33
        Originally posted by jstoik View Post

        It is exactly that like. PNG was the first big "kitchen sink" format that tried to do it all. And there are still cases where it does XYZ better than any of the even-more-convoluted next-gen formats.

        FYI, just in case you are using Oxipng's built-in Zopfli mode in your script, I would recommend running them separately. If you use Oxipng with its libdeflater option in one pass and a native zopflipng in a second, that will eek out more lossless savings and finish in about 1/10 the time. (The Zopfli Rust crate is incomplete and a bit stale; it can't compete with the original C/C++.)
        I do “oxipng without zopfli then pngwolf with zopfli” because I noticed it produces smaller files than “oxipng with zopfli”, I have not investigated why, but it confirms what you say. I know advpng from advcomp also has a zopfli option but I have not benchmarked it for png. I use advzip with zopfli option for zip though, and it looks efficient. My quick-and-dirty optimization scripts are there, they may not be perfect. I plan to investigate Yoga optimizer.

        Comment


        • #34
          Originally posted by illwieckz View Post
          ...after that you can use a zopfli compressor to bruteforce the zip compression.
          Zopfli is not a brute force compressor, it's a lot more clever than that. Brute force simply isn't an option with the dictionary sizes involved in zip, and the stream lengths in question.

          Comment


          • #35
            Originally posted by microcode View Post
            Zopfli is not a brute force compressor, it's a lot more clever than that. Brute force simply isn't an option with the dictionary sizes involved in zip, and the stream lengths in question.
            Sorry, I was referring to chaining multiple, independent image utilities together, e.g. pngcrunch + oxipng + zopflipng. No single program can do everything, and you don't know which algorithms will work best for a given source, so you chuck everything at it and see what shakes out.

            Comment

            Working...
            X