5 ms·

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

> 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 https://crates.io/crates/jxl-oxide It would be nice to hear why it's not good enough.

tux3 2y ago
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 2y ago
  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 2y ago
  Well, blink did come out of WebKit ..
Timshel 2y ago
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 2y ago
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 2y ago
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.
- noobermin 2y ago
  Why start from zero then if jpeg xl is big and complex?
- JyrkiAlakuijala 2y ago
  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 2y ago
    But it has an insane API. I wanted to support jxl encoding, but eventually gave up. Too complicated for average users
    - JyrkiAlakuijala 2y ago
      Could it be improved by having a wrapper for simple uses?
noobermin 2y ago
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.
deleted 2y ago
[deleted]

tux3 2y ago

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 2y ago
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 2y ago
Well, blink did come out of WebKit ..

Timshel 2y ago

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 2y ago

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 2y ago

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.

noobermin 2y ago
Why start from zero then if jpeg xl is big and complex?
JyrkiAlakuijala 2y ago
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 2y ago
  But it has an insane API. I wanted to support jxl encoding, but eventually gave up. Too complicated for average users
  - JyrkiAlakuijala 2y ago
    Could it be improved by having a wrapper for simple uses?

noobermin 2y ago

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.

deleted 2y ago

[deleted]