Comment on JPEG-XL Image Support Returns To Latest Chrome / Chromium Code

RamRabbit@lemmy.world ⁨4⁩ ⁨days⁩ ago

• BrikoX@lemmy.zip ⁨4⁩ ⁨days⁩ ago

  Up to 46% compared to PNG is more than a bit extra. It’s also both loseless and lossy and supports backwards compatability between legacy JPEG. Among many other modern features.

  And PNG is so old that it lacks basic modern features like HDR support.

  The only competition to JPEG-XL is AVIF. Though both likely to coexist as they have different strenghts.

  source

  • reddig33@lemmy.world ⁨4⁩ ⁨days⁩ ago

    Its not backwards compatible. I don’t know where you got this idea from.

    source

    • BrikoX@lemmy.zip ⁨4⁩ ⁨days⁩ ago

      Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth transition path from legacy JPEG platforms to the modern JPEG XL.

      ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

      source

      • reddig33@lemmy.world ⁨4⁩ ⁨days⁩ ago

        Creating two copies of a file isn’t backward compatibility. Thats what devs are doing now with webp. One webp file, and one joeg file for clients who cant render webp.

        Now if you could open and view a jpeg xl file without having to upgrade your app/browser/whatever — that would be backward compatibility.

        source

        • -> View More Comments
• javasux@lemmy.world ⁨4⁩ ⁨days⁩ ago

  Here’s the white paper on it ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

  source