Comment on JPEG is Dying - And that's a bad thing | 2kliksphilip

• ProdigalFrog@slrpnk.net ⁨1⁩ ⁨month⁩ ago

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

  Why is that a negative?

  source

  • reddig33@lemmy.world ⁨1⁩ ⁨month⁩ ago

    xkcd.com/927/

    source

    • ProdigalFrog@slrpnk.net ⁨1⁩ ⁨month⁩ 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.

      source

      • jmp242@sopuli.xyz ⁨1⁩ ⁨month⁩ ago

        The other thing is, disk space and internet speeds just keep getting cheaper so… Why change just for disk space?

        source

        • -> View More Comments
    • moonpiedumplings@programming.dev ⁨1⁩ ⁨month⁩ ago

      1000006617

      source
  • seaQueue@lemmy.world ⁨1⁩ ⁨month⁩ 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.

    source

    • RamblingPanda@lemmynsfw.com ⁨1⁩ ⁨month⁩ ago

      But how is that different to any other new format? Webp was no different?

      source

      • seaQueue@lemmy.world ⁨1⁩ ⁨month⁩ ago

        Google rammed webp through because it saved them money on bandwidth 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 the standard.

        source
    • ProdigalFrog@slrpnk.net ⁨1⁩ ⁨month⁩ 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.

      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.

      source

      • seaQueue@lemmy.world ⁨1⁩ ⁨month⁩ 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 webp in JavaScript is, let’s just say it’s not fast and it’s not guaranteed to work on legacy browsers and older machines.

        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.

        source
  • Morphit@feddit.uk ⁨1⁩ ⁨month⁩ ago

    xkcd.com/927/

    Adding more decoders means more overheads in code size, projects dependencies, maintanance, developer bandwidth and higher potential for security vulnerabilities.

    source

    • SkyeStarfall@lemmy.blahaj.zone ⁨1⁩ ⁨month⁩ ago

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

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

      source

      • Morphit@feddit.uk ⁨1⁩ ⁨month⁩ 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.

        source
    • moonpiedumplings@programming.dev ⁨1⁩ ⁨month⁩ ago

      1000006617

      source

      • Morphit@feddit.uk ⁨1⁩ ⁨month⁩ 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.

        source
• JackbyDev@programming.dev ⁨1⁩ ⁨month⁩ 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.

  source