- cross-posted to:
- linux
- jpegxl@lemmy.world
- cross-posted to:
- linux
- jpegxl@lemmy.world
You must log in or register to comment.
This decision has probably saved us from a decade long trickle of very embarrassing security vulnerabilities.
And has also gifted us a decade of less, but also more interesting, security vulnerabilities.
Good algorithm, bad name. JPEG Extra Large.
O.g. JPEG has bad reputation, because of visual artifacts.It’s sad to see how Mozilla needs Google even for this.
I hate that Google seems to have a finger in absolutely everything. Why? Because their end goal is a web where you need to identity yourself to them.
Google created the original reference implementation, libjxl. It’s not stupid that they would prefer a Rust rewrite be created by the same team.
It’s likely that Google offered, and Mozilla doesn’t have a reason to say no. Google Research do this for a bunch of open source projects.
Chrome needs a JPEG-XL decoder too, so I’d guess they’re going to share the code across both Chrome and Firefox.
deleted by creator
Interestingly, the reference implementation libjxl appears to be a Google project. They’re all over the patents file and CLA.
If Mozilla isn’t merely being hopeful about having the same team create a Rust implementation, that might actually mean there’s internal interest within Google. Assuming they pull it off, the bullshit reason for refusing to add JPEG XL to Chromium might finally stop being a blocker.
Google basically made jxl. I’m sure there’s plenty of interested people in there, it’s always just been the chromium team blocking it
It’s not the Chromium team. Google could have added JPEG XL to Android, but that’s been stalled for nearly two years with zero explanation as for why.
The whole thing smells of managerial interference somewhere.
The dream lives on.
♥️ jpegxl
