• reddig33@lemmy.world
    link
    fedilink
    English
    arrow-up
    28
    ·
    3 months ago

    It’s only backwards compatible in that it can re-encode existing jpeg content into the newer format without any image loss. Existing browsers and apps can’t render jpegXL without adding a new decoder.

    • ProdigalFrog@slrpnk.netOP
      link
      fedilink
      English
      arrow-up
      17
      ·
      3 months ago

      Existing browsers and apps can’t render jpegXL without adding a new decoder.

      Why is that a negative?

        • ProdigalFrog@slrpnk.netOP
          link
          fedilink
          English
          arrow-up
          16
          ·
          edit-2
          3 months ago

          The video actually references that comic at the end.

          But I don’t see how that applies in your example, since both JPEG and JPEG XL existing in parallel doesn’t really have any downsides, it’d just be nice to have the newer option available. The thrust of the video is that Google is kneecapping JPEG XL in favor of their own format, which is not backwards compatible with JPEG in any capacity. So we’re getting a brand new format either way, but a monopoly is forcing a worse format.

      • seaQueue@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        3 months ago

        Legacy client support. Old devices running old browser code can’t support a new format without software updates, and that’s not always possible. Decoding jxl on a 15yo device that’s not upgradable isn’t good UX. Sure, you probably can work around that with slow JavaScript decoding for many but it’ll be slow and processor intensive. Imagine decoding jxl on a low power arm device or something like a Celeron from the early 2010s and you’ll get the idea, it will not be anywhere near as fast as good old jpeg.

          • seaQueue@lemmy.world
            link
            fedilink
            English
            arrow-up
            4
            ·
            edit-2
            3 months ago

            Google rammed webp through because it saved them money on bandwidth (and time during page loading) and because they controlled the standard. They’re doing the same thing with jpeg now that they control jpegli. Jpegli directly lifts the majority of features from jpegxl and google controls that standard.

        • ProdigalFrog@slrpnk.netOP
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          3 months ago

          That’s a good argument, and as a fan of permacomputing and reducing e-waste, I must admit I’m fairly swayed by it.

          However, are you sure JPEG XL decode/encode is more computationally heavy than JPEG to where it would struggle on older hardware? This measurement seems to show that it’s quite comparable to standard JPEG, unless I’m misunderstanding something (and I very well might be).

          That wouldn’t help the people stuck on an outdated browser (older, unsupported phones?), but for those who can change their OS, like older PC’s, a modern Linux distro with an updated browser would still allow that old hardware to decode JPEG XL’s fairly well, I would hope.

          • seaQueue@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            ·
            edit-2
            3 months ago

            Optimized jpegxl decoding can be as fast as jpeg but only if the browser supports the format natively. If you’re trying to bolt jxl decoding onto a legacy browser your options become JavaScript and WASM decoding. WASM can be as fast but browsers released before like 2020 won’t support it and need to use JavaScript to do the job. Decoding jxl in JavaScript is, let’s just say it’s not fast and it’s not guaranteed to work on legacy browsers and older machines. Additionally any of these bolt on mechanisms require sending the decoder package on page load so unless you’re able to load that from the user’s cache you pay the bandwidth/time price of downloading and initializing the decoder code before images even start to render on the page. Ultimately bolting on support for the new format just isn’t worth the cost of the implementation in many cases so sites usually implement fallback to the older format as well.

            Webp succeeded because Google rammed the format through and they did that because they controlled the standard. You’ll see the same thing happen with the jpegli format next, it lifts the majority of its featureset from jpegxl and Google controls the standard.

        • SkyeStarfall@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          3 months ago

          The alternative is to never have anything better, which is not realistic

          Yes, it means more code, but that’s an inevitability. We already have lots of legacy stuff, like, say, floppy disk drivers

          • Morphit @feddit.uk
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            A balance has to be struck. The alternative isn’t not getting anything better, it’s being sure the benefits are worth the costs. The comment was “Why is [adding another decoder] a negative?” There is a cost to it, and while most people don’t think about this stuff, someone does.

            The floppy code was destined to be removed from Linux because no one wanted to maintain it and it had such a small user base. Fortunately I think some people stepped up to look after it but that could have made preserving old software significantly harder.

            If image formats get abandoned, browsers are going to face hard decisions as to whether to drop support. There has to be some push-back to over-proliferation of formats or we could be in a worse position than now, where there are only two or three viable browser alternatives that can keep up with the churn of web technologies.

          • Morphit @feddit.uk
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            I mean, the comic is even in the OP. The whole point is that AVIF is already out there, like it or not. I’m not happy about Google setting the standards but that has to be supported. Does JPEGXL cross the line where it’s really worth adding in addition to AVIF? It’s easy to yes when you’re not the one supporting it.

    • JackbyDev@programming.dev
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 months ago

      They’re confusing backwards and forwards compatible. The new file format is backwards compatible but the old renderers are not forward compatible with the new format.