• rdri@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    It’s very slow on high compression profiles though, and consumes a lot of resources.

    • Yote.zip@pawb.social
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      1 year ago

      You don’t need to use the high compression profiles to get good performance though. If you have a usecase where you are resource limited you should stick to effort levels 5-7 for very little loss in quality, or even 3-4 for lightning quick speed (the default is effort 7). Reference this benchmark against AVIF for effort values vs. speed (SSIMULACRA 2 is a deterministic psychovisual metric - higher is better).

      Also, an important consideration in this realm is that JXL makes really clever use of variable-DCT (how big a chunk is) and adaptive quantization (what quality should be used for that chunk), allowing “quality levels” that you specify to be much more visually consistent across every image, instead of other codecs that make some images look bad at quality level 90 and some images look good at level 70. This allows you to select a consistent quality level and lower your encoding effort to compensate, instead of needing to always drive a high quality+effort level to account for every region in a picture looking good.

      (If you want a slightly deeper dive into JXL’s performance, this is a concise post on various metrics)

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

        I tried getting benefit from the format by recompressing PNGs at some point and it just seemed worthless due to reasons I listed in my comment.

        • Yote.zip@pawb.social
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          1 year ago

          With effort level 7 you should be getting images roughly 2/3’s of the size of the original PNG on average (assuming the PNG is already properly optimized). I would try again with at least effort levels 3, 4, 5, and 7. Also consider that PNGs need very expensive CPU time to properly compress them, using a tool like oxipng.

          What sort of balance are you looking for with regards to filesize and encode time? At the very least, effort levels 1 through 3 will probably still give you better results than PNG while being ridiculously quick, so there shouldn’t be any configuration where PNG is a better choice than JXL with regards to speed.