Email or username:

Password:

Forgot your password?
Kornel

Firefox will reconsider supporting JPEG XL if they get a Rust implementation:

github.com/mozilla/standards-p

This is a very good news for web standards:

mastodon.social/@kornel/113078

and will fix a blocker that is hurting adoption of JPEG XL.

The reference implementation has unfortunately been written in C++ just as browser vendors started looking into migrating away from C++ for security reasons, and saw the C++ codec primarily as a big new attack surface.

24 comments
Marcin Juszkiewicz

@kornel I got lost in all those "soon to be popular" image formats.

We had GIF, JPEG, PNG in past (still have). Then WebP arrived and took some time before it became some kind of popularity.

In meantime there was JPEG2000, JPEGXL and probably few other mutations which were mentioned as "soon".

And <imgset> tag was announced as a solution for web devs. To provide jpeg2000, jpegxl, webp, jpeg etc images in hope that browser will choose what they support. Or this is how I understood it.

Kornel

@hrw The old JPEG is exceptionally good, like alien technology from the future.

Also interoperability is more important than anything else. People care more that the files will work everywhere than about file size savings (GIF is an extreme example of this).

JPEG XL is a very complex format, because it's trying to beat every other format at everything.

Fabien

@kornel I assume you've heard the rumours about Apple making JPEG XL the new default on its phones?

Moritz Firsching

@kornel @hrw

I guess "very complex" is relative. Of course it is more complex than old JPEG, but compared to some image formats derived from video formats it is significantly less complex.

Ryan Townsend

@kornel do
you happen to know Google’s latest stance on JPEG XL for Chrome?

It was experimental but they pulled it, right? Are they reconsidering this now WebKit supports it?

Kornel

@ryantownsend I don't have insider info about Chrome.

A second safe implementation removes some objections. Code size is still going to be an issue (every Electron app will be even larger by the size of JXL!)

Safari+Firefox don't have market share large enough to force Chrome to adopt JXL, like Chrome-only websites forced them to adopt WebP.

ThunderComplex (Silly Mode)
@grin @kornel I'm using this project to hack JPEG XL support into browsers via WASM and so far I'm quite happy with it
Soblow Xaselgio

You know what to do Rust folks, arm your Clippy~

fennec :verified:

@Soblow seriously considering it if it didn't mean i'd get roped into maintaining it

MadMike77

@kornel And here I thought new image formats were held back because of patent encumbrance?

LiquidParasyte

@kornel cRustaceans, if there was any a time to #RIIR, it's now

Kornel

@LiquidParasyte It's already been done github.com/tirr-c/jxl-oxide/ but apparently they'd like to rewrite it once more.

Aslak Raanes

@kornel @LiquidParasyte Have they said why they can't use @tirr's implementation of a JPEG XL decoder as a starting point?

Isaac Lyman

@kornel
TIRED: CSS isn’t a programming language
WIRED: C++ is an attack surface

DELETED

@isaaclyman @kornel I bet at this point people will find vulnerabilities in CSS rendering engines and make CSS an attack surface

Pixel Doge

@kornel what happened about that thing of building native libraries to Wasm, then doing AOT compilation and running the resulting code in a sandbox that Firefox was supposed to be doing? Sounds like the perfect solution to to add support while avoiding directly using the C++ implementation, yet having a complete implementation today:

hacks.mozilla.org/2021/12/weba

Saying “we want to support JPEG-XL but we won't until $X that somebody else had to do” sounds like moving goalposts in an attempt to silence the people asking for the feature without really committing to work on it.

@kornel what happened about that thing of building native libraries to Wasm, then doing AOT compilation and running the resulting code in a sandbox that Firefox was supposed to be doing? Sounds like the perfect solution to to add support while avoiding directly using the C++ implementation, yet having a complete implementation today:

Haelwenn /элвэн/ :triskell:
@aperezdc @kornel Which reminds me that I wonder how big a jpeg-xl decoder compiled to wasm would be, as if it's small enough webapps with a lot of images could probably use it and still save some bandwidth.
Jeff Muizelaar

@aperezdc @kornel WASM sandboxing has a performance cost (especially because of having a separate heap) that we don't really want for image decoding.

Hovav Shacham

@jrmuizel @aperezdc @kornel Can you say a bit more about your performance targets? If SoundTouch (which has hard latency requirements) can be RLBoxed, I'm surprised that jxl can't!

Frost, Wolffucker 🐺:therian:

@kornel *sighs* Of COURSE this'll just fuel the Rust Cult people.

JPEG XL is cool though.

feld
@kornel okay, but they didn't seem to have any issues with supporting the Widevine DRM modules which aren't written in Rust

Cisco's OpenH264 is 150,000 lines of C++. When are they gonna eject that?
Go Up