Firefox will consider a Rust implementation of JPEG-XL by bholley · Pull Request #1064 · mozilla/standards-positions
github.com
Over the past few months, we’ve had some productive conversations with the JPEG-XL team at Google Research around the future of the format in Firefox. Our primary concern has long been the increase...
    • shadowtofu@discuss.tchncs.de
      55·
      3 months ago

      I took my existing JPEG file, compressed it using JXL, 15% smaller.

      Then I decompressed it again into JPEG. The file was bit-for-bit identical to the original file (same hash). Blew my mind!

      Directly using JXL is even better of course.

        • drwankingstein@lemmy.dbzer0.comEnglish
          6·
          3 months ago

          this has been a bit of a meme, but if you wanted to look at XL as extra large, then that could refer to the max resolution which is far great. I’ve seen people refere to it as “extra long-term” but I think the real reason is they just wanted to fuck with us

  • GolfNovemberUniform
    443·
    3 months ago

    Google’s involvement should always raise concerns but I guess it’s good Mozilla is trying to improve stuff.

    • drwankingstein@lemmy.dbzer0.comEnglish
      78·
      3 months ago

      this is from the google research team, they contribute a LOT to many foss projects. Google is not a monolith, each team is made of often very different folk, who have very different goals

      • 1984@lemmy.today
        181·
        3 months ago

        As long as their goals suite the company, sure. The endgame of Google is very clear and it doesn’t include a free and open web.

        • drwankingstein@lemmy.dbzer0.comEnglish
          4·
          3 months ago

          I don’t even think this is the case, google does a lot pretty much everywhere. one example is one of the things they are pushing for is locally run AI (gemini, stable diffusion etc.) to run on your gpu via webgpu instead of needing to use cloud services, which is obviously privacy friendly for a myriad of reasons, in fact, we now have multiple implementations of LLMs that run locally in browser on webgpu, and even a stable diffusion implementation (never got it to work though since my most beefy gpu is an arc a380 with 6gb of ram)

          they do other stuff too, but with the recent craze push for AI, I think this is probably the most relevant.

            • drwankingstein@lemmy.dbzer0.comEnglish
              2·
              3 months ago

              ehh… not really, the amount of generated data you can get by snopping on LLM traffic is going to far out weigh the costs of running LLMs

              • Leaflet@lemmy.worldOPEnglish
                1·
                3 months ago

                There’s nothing technical stopping Google from sending the prompt text (and maybe generated results) back to their servers. Only political/social backlash for worsened privacy.

      • GolfNovemberUniform
        3·
        3 months ago

        Well Google can still lock Mozilla out of the features and cooperation if they do something Google doesn’t like. It’s just one example. Nobody should ever trust Google.

          • jokeyrhymeEnglish
            2·
            3 months ago

            One example I can think of is Widevine DRM, which is owned by Google and is closed source: https://en.wikipedia.org/wiki/Widevine

            Google currently allows Mozilla (and others) to distribute this within Firefox, allowing Netflix, Disney+, and various other video streaming services to work within Firefox without any technical work performed by the user

            I don’t believe Google would ever willingly take this away from Mozilla, but it’s entirely possible that the movie and music industries pressure Google to reduce access to Widevine (the same way they pressured Netflix into adopting DRM)

            • drwankingstein@lemmy.dbzer0.comEnglish
              1·
              3 months ago

              yeah, that could indeed happen I suppose, didn’t think of that. Though I wonder if because of EME, an alternative drm solution could be viably implemented.

  • IHave69XiBucks@lemmygrad.ml
    16·
    3 months ago

    Think the headline kind of buries the lead. Firefox is basically holding google by the balls and saying “Make a better decoder if you want this shit to become standard” which imo is great. Force them to do what they should have done already.

    • fossphi@lemm.eeEnglish
      11·
      3 months ago

      This is not right on multiple levels. Google, or at least the chromium team were not interested in implementing jxl at all

      • IHave69XiBucks@lemmygrad.ml
        7·
        3 months ago

        maybe i misunderstood what they were saying on github then cuz to me it sounded like they were using their leverage as firefox to get a decoder made that was more secure.

  • merthyr1831English
    3·
    2 months ago

    Google’s involvement is weird, not for any conspiracy reasons but because the chromium team previously cancelled JPEG-XL.

  • Redruth@feddit.nlEnglish
    2·
    3 months ago

    I have a nagging doubt; jpeg-xl has a very extensive feature set (text overlays, etc). meanwhile, tech/media consortia want a basic spec for AV1 + OPUS on chip and push that to all media capable devices. we can expect av1, avif and opus to be ubiquitous in a few years. So i think they will prioritise AVIF.

    • merthyr1831English
      1·
      2 months ago

      I did some reading in AV1 and it’s derivative formats - are they any more accessible to Linux than HEVC/H265? Fedora IIRC removed support for them and a few other codecs out of the box over some patent concerns or something.