Hacker News Reader

Comment by gardaani | Hacker News Reader

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

View on HN

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.

Well, blink did come out of WebKit ..

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.

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.

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

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

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

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

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.

Reply on news.ycombinator.com