Introducing a Firefox package with JPEG XL enabled

Hello,

So I’ve been an advocate for JPEG XL from the start, and I was a bit miffed when Google removed it from Chromium, and when Mozilla said their position was “neutral”, which concretely means hide it behind a flag in Nightly only and do nothing about its implementation.

Since I don’t want to run Nightly on the daily, why not patch Firefox stable?
This is the COPR : eclipseo/firefox-jxl Copr

So what you get:

Source is here: https://src.fedoraproject.org/fork/eclipseo/rpms/firefox/c/90702891fefc97ff9e347dbab0091136822a0f3b?branch=jxl

The whole thing is built with Clang instead of GCC to enjoy cross-language LTO between Rust and C/C++

I’ll try to keep up with upstream as much as I can, it’s partially automated.

If you do install it, you can check it is functioning on JPEG XL Test Page

You should see the progressive decoding, transparency and animation.

Of course, this is not a Fedora official project, just a personal, use at your own risk

2 Likes

Thanks, I’ll definitely take a look. Although it raises the obvious question of why anyone should have to do this? Safari of all things now has JPEG XL incorporated. The chrome-a-clone Thorium also incorporates JPEG-XL, and now you’ve done it. Mozilla has included this support in Fx Nightly for years. What exactly is the issue keeping Mozilla from doing this for Fx? I’m not one normally for conspiracy theories, but this situation just seems a bit bizarre.

The went with avif because of the push for av1 content. I’m sure if it’s raised again or there’s enough support around it they will add it.

I also went with avif , currently converting over 500,000+ images to the format. For these images specifally the file size is small and the changes imperceptible.

:stop_sign:
The browser that should be run in a container with sandbox_t SELinux flags. . .

Firefox do not include these 3 patchs:

  • Bug 1709814 - Add support for color profiles (by wwwwwwww (Samuel)).
  • Bug 1709818 - Add support for animated JPEG XL (by wwwwwwww (Samuel)).
  • Bug 1709815 - Add support for progressive decoding for JPEG XL (by wwwwwwww (Samuel)).

But some forks do like Waterfox, R3dfox, and Librewolf.

As for Mozilla, I don’t know, maybe with Apple putting it in iOS (all iPhone will have it), and Samsung using it into its Camera Raw, they will bulge. The biggest problem is Google though, Chrome is the market leader, and Android too. Which is ironic because it is mainly developed by Google Zurich team and Cloudinary. But Google US said no:

‘Jim Bankoski’ via blink-dev Fri, 11 Nov 2022 07:58:27 -0800

Helping the web to evolve is challenging, and it requires us to make difficult choices. We’ve also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We’ll work to publish data in the next couple of weeks. For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward. Jim

  • compression performance across a broad range of images : better than AVIF at 1 bpp, which is according to Google, 80% of the images served on the Web
  • is the decoder fast : faster than AVIF
  • allowing for speedy rendering of smaller images: yes and allow progressive rendering
  • are there fast encoders: there is a minimal fast encoder if needed
  • ideally with hardware support: we don’t need a chip for decoding image, but phone camera are sating to support it
  • keep encoding costs reasonable for large users: the benefits in bandwith and storage outweighs the cost of transcoding. In long term too.
  • can we optimize existing formats to meet any new use-cases: that’s what Google Zurich team did too with the JPEGLI encoder, at the request of Google. But there are still benefit to JPEG XL, like transparency, lossless, lossless transcoding, animation, ICC support…
  • do other browsers and OSes support it: iOS/Safari does, Microsoft is implementing it in Windows, industry support is pretty large. And this is rich coming from them saying do other browsers support it when you are the one in a dominant position worldwide and basically decide web standard,
1 Like

Yeah, me thinks Google’s reasoning doesn’t pass the smell test. That said, Fx is suppose to be an independent, not-for-profit browser that is looking to advance technologies to advance the web. Seems to me that something that is backward compatible with all existing JPG images and offers lossless compression and increased performance fits the bill. I’m just wondering if there is something in Mozilla’s agreement with Google that is preventing them from adding JPEG-XL. In a world where Fx should be looking for opportunities to differentiate themselves from the Chrome ecosystem, this would seem to be an easy lift.

It’s a bit laughable that Google, who is known for literally throwing stuff at the wall and see what sticks would all of a sudden decide they need to try to put the kibosh on it.

The whole situation seems a bit suspect.

I like your approach, but I would go farther and say that distributions need to start making it part of their official Fx distribution. We’re in a chicken/egg situation, and the only way out of it at this point is to make it available to all by default.

Because the industry is moving to AV1. Youtube is starting to convert content over, Twitch will soon and so on. The same goes for avif, it only makes sense they would do that since they are moving towards AV1 compatability and Hardware supported feature.

This is scary. Especially for a Web browser.

Well this is mostly automated, it checks for commits every hour and rebase then build on COPR. Then only problem would be a failed rebase, which would notify me. Build time is 8 hours. You’re more likely to have the update faster since it doesn’t go through Bodhi (which could be scary too though).

For example, we have currently in F40:

Stable firefox-125.0.3-1.fc40
Testing firefox-126.0-5.fc40

But currently 126.0-6 is building on COPR, Build 7446334 in eclipseo/firefox-jxl and will be available in 4 hours.

So, what sites have implemented .jxl ? Why do this now? Why patch a browser just for 1 protocol?

If this was Debian/KeepassXC situation, I could understand somewhat. Though the argument there has gone in many directions.

I do hope Mozilla will change its mind in the (maybe not) long run, after Apple and Microsoft move. My goal was to update the code for personal website use, and if I can share the work and encourage people to use JPEG XL the better.

Here is the bottom line, JXL is backwardly compatible with JPEG. The performance is at least if not better than AVIF (do a web search). You’re never going to get rid of JPG images. They have been around for years. IMHO, there is something horribly suspect with what Google has done, and I really don’t understand Mozilla’s complicity. The fact that Apple and MS are also support JXL speaks volumes. @eclipseo has done us a great service by taking the time to package this.

Works great! IMHO, it’s beyond ridiculous that this isn’t included by default in Fx, especially when it has been languishing in Nightly for years. The sad part is that if Google announced they were going to add it to Chrome, Mozilla include it immediately. They should be making their decisions on what is good for the web, not based upon what Google does or does not do. Say what you will about Apple, but they have defied Google and made JXL available in Safari.

The guy who announced the drop of JPEG XL in Google:

Co-author of all the papers on AV1. As much as AOM AV1 was co-authored by Mozilla Xiph and Google, Xiph completely disappeared. Google is mostly in control of it because it needed a royalty-free codec for YouTube to not pay the extortionous royalties of the various patent pool involved in h265, IMHO.

They could also believe that, we already have AVIF, why bother? I was interested in AVIF too before it existed as such, I was doing testing with picture encoding with AV1 intra coding and x265/BPG. But JPEG XL brings lossless transcoding (its lossless encoding is better too, but not important for the web).

1 Like

As I mentioned earlier, IMHO the elephant in the room that makes JXL superior is that it is backwardly compatible with JXL. That’s probably why Apple and MS jumped on board. I’m a bit gobsmacked that Mozilla hasn’t grabbed onto this opportunity to differentiate themselves from Google and Chrome. Now they even have Apple giving them cover, and they still haven’t done it. The amount of effort required, vs. the potential reward makes it a no-brainer. Makes me wonder what is going on over there.

What makes this worthwhile to use? Images load fine for me currently, so why might I want to use JPEG XL?

Also does JPEG XL require explicit support from browsers? Even if some browsers support it, I wouldn’t want to break compat with incompatible devices with hosted websites, and I can just continue serving stuff without JPEG XL for all browsers like I’ve been doing for years :stuck_out_tongue:

With Chrome not supporting it and them having the largest userbase, I’d need sold hard as to what would make JPEG XL worth looking into.

It doesn’t matter, AV1 was chosen not for “pictures” but for streaming. So naturally avif will accompany it. That’s what I’ve been saying the whole time.

Will there be adoption with jxl ? Maybe, or it’ll fall by the wayside like other JPEG technologies over the years. I’ve been around long enough to see them all come and go.

AV1 is getting hardware acceleration with all upcoming and present hardware. AMD / Intel are beyond being onboard since their gpu’s and cpu’s will focused on AV1.

I find it more “suspect” to repackage a Web Browser for 1 image format that is currently not on many peoples roadmap, and might not get support like many other in it’s family. . .

Then we can agree to disagree.

1 Like

There are many websites that explain what JXL is and it’s benefits. If you’re interested, you can do a quick websearch.

1 Like

Maybe only for JXL, but it’s a whole different picture with WebUSB: RFP: WebUSB API · Issue #100 · mozilla/standards-positions · GitHub

Chrome supports it no problem, as do some other browsers iirc. Firefox doesn’t support it because of politics (if it was really security just disable it by-default and hide it behind a config). But at least they have a stance.

1 Like

Yeah, the Fx stance on JXL is “neutral”, which is IMHO is weak sauce, but whatever.

1 Like

For me, the principal of least astonishment by users strongly suggests that whatever default configuration(s) is on the platforms FF ships (in binary form) should be the default configuration on Fedora’s builds to the largest extent possible.