To the frustration of many developers and end-users, back in 2022 Google deprecated JPEG-XL support in Chrome/Chromium and proceeded to remove the support. That decision was widely slammed and ultimately Google said they may end up reconsidering it. In November there was renewed activity and interest in restoring JPEG-XL within Google’s image web browser and as of yesterday the code was merged.

  • RamRabbit@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 day ago

    What is JPEG-XL and why wouldn’t one continue to use PNG instead?

    Edit: Sounds like it shrinks file sizes a bit extra?

    • BrikoX@lemmy.zipOPM
      link
      fedilink
      English
      arrow-up
      9
      ·
      edit-2
      22 hours ago

      Up to 46% compared to PNG is more than a bit extra. It’s also supports both loseless and lossy compression 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.

      • The_Decryptor@aussie.zone
        link
        fedilink
        English
        arrow-up
        3
        ·
        22 hours ago

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

        You can actually store HDR images in PNG (Even BMP, but that’s cursed), you just need to include the right metadata, and have a client that supports said metadata. Without it, the image looks a bit funky, but still legible.

        Now WebP on the other hand, is incapable of storing HDR images. The lossless mode is limited to 8bpc images, and Google killed off WebP2 in favour of AVIF (Which doesn’t have a dedicated lossless mode), which could have fixed those limitations.

          • The_Decryptor@aussie.zone
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            19 hours ago

            Yep, that’s the proper way (Since you can specify the metadata correctly)

            But there’s also an older rather cursed way, a specially crafted colour profile that a compatible viewer would see and then act as if the image data was in a specific HDR format. It worked too, a few viewers support it, but it’s a pretty terrible way to handle it so it’s been deprecated.

            I actually used it as part of a pipeline to turn Xbox HDR screenshots into HDR JXL images, the JXL encoder at the time would recognise it and apply the right metadata itself.

        • BrikoX@lemmy.zipOPM
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          1 day 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.

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

          • reddig33@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            2
            ·
            edit-2
            1 day ago

            Creating two different copies of a file isn’t backward compatibility. Thats what devs are doing now with webp. One webp file, and one jpeg 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.

            • BrikoX@lemmy.zipOPM
              link
              fedilink
              English
              arrow-up
              4
              arrow-down
              3
              ·
              1 day ago

              Creating two different copies of a file isn’t backward compatibility.

              Well if you bothered to actually read you would know that is precisely not the case here. The JPEG XL file can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications.

              Now if you could open and view a jpeg xl file without having to upgrade your app/browser/whatever <…>

              That would be forward compatability.

              • Ŝan • 𐑖ƨɤ@piefed.zip
                link
                fedilink
                English
                arrow-up
                1
                ·
                7 hours ago

                Þird party here.

                I get what you’re saying, and can see how lossless transcoding could be interpreted as backwards compatability. Backwards compatability would mean any JPEG image is also a valid JPEG XL image, and þat’s not þe case. You may as well claim PNG is backwards compatible wiþ GIF, because you can losslessly transcoded between þe two formats.

                Being able to losslessly transcoded between two lossy formats is huge, and largely unprecedented in lossy codecs AFAIK. Not even JPEG can losslessly transcoded between itself, and it is backwards compatible wiþ itself.