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