• Yote.zip
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    edit-2
    1 year ago

    PNG compression is an absolute joke so that’s not worth anything - JPEG-XL and WebP Lossless beat PNG by a longshot. PNG also requires intense optimization to be truly compressed, and I’m not sure to what extent they tried to optimize their PNG results. As an example, the lossless comparison chart I uploaded was 380KB initially, and I was able to optimize it to 280KB using OxiPNG. The PNGs in the lossless comparison chart were properly optimized.

    Beating FLAC is interesting, but FLAC compression hasn’t really been updated in a long time TMK - I wonder if there’s traditional gains left on the table with modern compression techniques?

    A copy of the original paper can be found here.

    • Ignotum@lemmy.world
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      Yeah, PNG is overly complex, slow to encode/decode, and despite all that, it atill doesn’t compress the picture very well

      I think i heard that one of the creators of the format said he didn’t have any experience with compression, and they more or less just threw things at the wall to see what stuck

      If you want the mediocre compression level of PNG, but waaaay faster, i can recommend QOI

      • Yote.zip
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        QOI should actually be worse than JPEG-XL in both speed and size, if you turn JPEG-XL’s effort level down to a speed-oriented level like -e 1. I wrote a quick script to compare them, and this is the output from 10 random (fully-optimized) PNGs I had: https://pastebin.com/raw/nSkBSePB

        I have a lot of cores on my CPU so you probably want to be looking at the user time metric, but consider that parallelization is a strong and intentional benefit to JPEG-XL.

        The results are not exactly scientific since I only picked 10 PNGs, but it shows a general trend.

        • Ignotum@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Ooh, i didn’t take parallelization into consideration, that’s very interesting, thank you

          • Yote.zip
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            1 year ago

            Not sure if I made it clear but the real time metric is equivalent to time passing in real life, and user time is the total CPU time spent by the application, e.g. 2 seconds of user time across 4 cores might be 0.5 seconds of real time. Parallelization is really good for end users (browsers loading an image, someone saving a file from GIMP, etc), but single-threaded performance can still be very important for enterprise applications where you’re converting a ton of images all the time, and you can just give every conversion its own thread instead. I mainly focused on user time when looking at the difference between JXL and QOI, since that’s more indicative of the total amount of work being done in a CPU-agnostic way.