This is the same Google that wrote the libgav1 decoder instead of using dav1d, they don't have a strong history of starting from code that was invented elsewhere.
(In the case of AV1 I think they eventually gave up and started offering dav1d on Android, but not before shipping their in-house implementation that was much less efficient and no safer than state of the art, perplexing everyone in the process.)
It should be noted that all known independent JPEG XL decoders (especially my J40 [1] and jxl-oxide) were primarily written by a single individual for each library. So the request is that some library, either the future version of jxl-oxide or Rust rewrite of libjxl or something else, should be written in a provably memory-safe manner, actively maintained by JPEG XL developers, and successfully reproducing the original libjxl's decoding performance. I think it is indeed a fair deal to both Mozilla and JPEG XL developers.
[1] The main blocker for J40 was that I don't really want to keep it less safe than I hope to achieve, but I also want to keep it in C for practical reasons. This and my daily job prevented any significant improvements so far.
For one thing, I believe jxl-oxide is not yet performant enough to replace libjxl's decoder (not necessarily because of a difference between C++ and Rust, however).
I think it would make more sense to support the existing implementation than to start yet another one.
As for why jxl-oxide can't be used yet — it just isn't mature enough yet. They're still finding unimplemented or incompatible features, and have some unoptimized code.
JPEG XL is big and complex – it is designed to have every feature of every competing codec (from vector graphics to video), and beat them all on compression in every case, so it's a half a dozen of different codecs in a trench coat.
May be deep down somewhere a large motivation for coding in rust is to invent something here even if that includes reinvention. The memory safety is a by-product.
They are not on the fence about Rust. They are on the fence about JPEG-XL when it entails a major increase in attack surface due to the current implementation being in C++.
Rust adds a lot of complexity (a new language) and does not even offer a general approach to automated correctness verification (not saying that C++ is better in this regard). Maybe it is just better to wait for Rust++.
Rust is much better suited to static analysis and formal verification than C++, primarily thanks to stricter pointer aliasing, immutability without loopholes of const, and thread safety annotations in the type system.
Most things that are advanced correctness verification in C++ are regular compiler errors in Rust.
This is a great news for JPEG XL. Web standards need two independent implementations of every feature – this proves that the spec is actually possible to implement, and makes it possible to verify that the implementations are interoperable.
It makes uses in the wild much less likely to depend on bugs in a particular implementation, which makes it possible to upgrade or replace implementations without creating bug-compatibility problems.
I believe that there are already several decoder implementations that pass the ISO conformance test for JPEG XL. I don't remember which one's exactly but I believe at least both jxl-oxide and libjxl do.
Another implementation is still unlikely to have the exact same bugs. Especially rewrite in Rust will force the code to be structured differently (Rust is very opinionated about that).
The spec is big enough that the team won't be able to just write the exact same implementation from memory.
I don't disagree that it's sufficient, but also, ideally different people would implement the spec. If you have a particular mental model or understanding of a part of the spec that doesn't match what the spec actually says, that is likely to translate identically when writing a second implementation.
I think Highway is a critical component for libjxl and has to be counted towards the line count. (CMS can be ignored here, and any Rust implementation should ideally use qcms [1] which is already in use in Firefox anyway.)
Personally, I'm on the edge on this one. I think both viewpoints are valid.
One way to think of Highway is that it is portable multi-platform SIMD intrinsics for C++. While we developed it originally as a part of JPEG XL, it has long ago graduated into a general-purpose library that has various uses, including the recent Gemma.cpp ML launch. Other modern highway uses include: Audio, Browsers, Computational biology, Computer graphics, Cryptography, Grok JPEG 2000, JPEGenc, Jpegli, OpenHTJ2K, Image processing, Image viewers, Information retrieval, Machine learning, Numpy, and Robotics... (copied from: https://github.com/google/highway)
I derived the name from the CityHash, FarmHash, and then HighwayHash series, and considered that Highway would link this library to its roots in the HighwayHash (of course much is also based on Jan's previous work with SIMD). Notably, I resisted using the -li naming here :-D
Indeed, though Highway is approaching a system library at this point. It is also a thin wrapper over the compiler's intrinsics headers: e.g. ~16KLOC for arm_neon.h, times the number of targets. That's a lot of code, but it is not comparable with actual codec logic lines.
A more efficient image format helps everyone on the web. We’re looking at 30-50% fewer bits sent over the wire for the same image quality. Massive bandwith savings for everyone. JPEG-XL is basically a better version of what Google was already trying to do with WebP, and a suitable long-term replacement for all image formats currently in use.
* Much better quality at high bpp (avif performs better at high compression levels, means shitty quality images can be much smaller, while high quality images either don't compress well or loose quality a lot)
* Best in class lossless compression, to replace png
* Progressive encoding
* Ability to losslessly reconvert existing jpegs for 20% free gains
Google Research (which, if I remember correctly had member working on jxl spec and did reference implementation) has much more freedom, and has already been cleared to work on jxl, than the Chrome Team.
They also don't have the same goal.
Google Research is also responsible for Brotli and Snappy I believe.
For all we know, JXL might be super useful, and is actively being used, for some project at Google for X, Y, and Z reasons, but the Chrome team doesn't want to add it to the browser for A, B, and C reasons. Google does many thing.
They have a general interest in the quality of the web. More web use is good for Google Ads. This sometimes comes into tension with Google's attempts to control and monetize the web.
My take on this is that junior engineers optimize for the cpu as it is easy to measure, senior engineers for the user experienced latency as it matters more.
Users know that their time is valuable. If your website is fast, they will explore it, and came back soon.
It will be fairly challenging to rewrite libjxl or any other independent JPEG XL decoder into wuffs, due to its inherent (and for now necessary) limitations. Even its PNG decoder is not very traditional, and JPEG XL has way more bookkeeping in its format.
Don’t see how. If there is too much telemetry, there is only two options: it can or it cannot be disabled via config. Very unlikely someone complaining about telemetry opted into telemetry on purpose… hence, the fact it can be disabled is “good news in the bad news”.
> mozilla locked as too heated and limited conversation to collaborators.
I wonder which one was objected to - the implementation considered to be in Rust or that a rewrite might not actually make sense for the dying browser (2.75% share) at this stage?
Firefox is around 8% of market share in the US on non-mobile devices -- up from around 4.5% this time last year. It's downright wrong to see 80% increase in users over 12 months as 'dying' -- and in general 1 in 12 users is significant enough that you should be caring about it.
Commenters seen to love declaring things to be dying, and marketshare trends are only tangentially related. (see e.g. "Netcraft confirms it" meme)
I personally feel like softeare is dead once it is no longer useful, and there is no likelihood of that changing in the foreseeable future. That's obviously not the case woth Firefox.
On the other hand I've seen exaggerated reports of the demise of a project that hasn't had a git commit in the last week, or isn't commercially relevant for whatever the commenter is interested in. Even this doesn't seem to me to be true for Firefox, but I don't think the accusations will stop, or the signal-to-noise will increase.
There's already a JPEG-XL decoder written in Rust: https://crates.io/crates/jxl-oxide
It would be nice to hear why it's not good enough.