[gardaani]

> the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust

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.

[tux3]

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.)

[lifthrasiir]

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.

[pchangr]

Well, blink did come out of WebKit ..

[Timshel]

They are relatively neutral about the format, so I'm guessing they want a commitment from Google to maintain it.

As good as Oxide might be it looks like a one developer project.

[lifthrasiir]

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).

[pornel]

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.

[JyrkiAlakuijala]

I believe that analysis is unfair or imprecise

libjxl decoder is 3-5x smaller in binary and 10x smaller in specification text size than an avif decoder

[rurban]

But it has an insane API. I wanted to support jxl encoding, but eventually gave up. Too complicated for average users

[JyrkiAlakuijala]

Could it be improved by having a wrapper for simple uses?

[noobermin]

Why start from zero then if jpeg xl is big and complex?

[noobermin]

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.