• 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.