Open Bug 1539075 (JPEG-XL) Opened 6 years ago Updated 6 days ago

Implement support for JPEG XL (image/jxl)

Categories

(Core :: Graphics: ImageLib, enhancement, P3)

Product:
Core
Component:
Graphics: ImageLib
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: Virtual, Assigned: saschanaz)

References

(Depends on 5 open bugs,
URL
)

Details

(4 keywords)

Has Regression Range: --- → irrelevant
Has STR: --- → irrelevant

For the moment, I'm happy to leave this as P5. AFAIK, the final specification isn't even targeted until October 2019, let alone any other browsers discussing shipping it.

Priority: -- → P5

JPEG XL is the future of all image formats.

Why:
https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer

Reference implementation has been added here:
https://gitlab.com/wg1/jpeg-xl

JPEG-XL is standardized in ISO/IEC 18181.
https://jpeg.org/jpegxl/

For reference, JPEG-XL is a combination of Cloudinary's FUIF (succesor of FLIF)
and Google's Pik and Brunsli, being made specifically for the web.

https://github.com/google/pik
https://github.com/google/brunsli
https://github.com/cloudinary/fuif
https://github.com/FLIF-hub/FLIF

Chromium ticket:
https://bugs.chromium.org/p/chromium/issues/detail?id=1056172#c1

WebKit ticket:
https://bugs.webkit.org/show_bug.cgi?id=208235

Added dev-doc-needed, as if this format ever gets implemented, documentation, BCD, and possibly other databases (hopefully by then
we'll have a "file format compatibility" database) will need updating to recognize it.

Keywords: dev-doc-needed

The current plan for a frozen format is the end of July 2020. JPEG XL is differentiated from other new modern compression efforts (WebP, HEIC and AVIF) by having progressive decoding, possibility to have salience-ordered tiles (middle-out compression!), for being able to transport old-fashioned JPEG images without loss and with compression gains (-22 % in size) and being always YUV444, HDR and wide-gamut — as well as more dense compression in both internet transport and camera-original qualities.

We are hoping to use JPEG XL in both image encoding and content encoding. For content encoding we can deliver traditional JPEGs with the -22 % savings in transferred bytes. We can help in the exploration work, documentation and other aspects of the possible integration.

JPEG XL is building on our previous work in FLIF, FUIF, pik, guetzli, zopfli, butteraugli, knusperli, brunsli, WebP lossless, and brotli. I believe it is the technically strongest, easiest to use, and most backward compatible and full-featured contender of the next-gen image formats.

JPEG XL is in the final stages of standardization and its codestream format is now frozen.
https://gitlab.com/wg1/jpeg-xl/-/releases/v0.2

I do think now that the JPEG-XL bitstream has been finalized(which means any picture produced with JPEG-XL will be decodable 20 years from now), it is the right time to start working on its integration.

There is even a QT JPEGXL plugin that currently works quite well, and allows me to see and interact with JPEG-XL images like if it was just a regular JPG or PNG image: https://i.slow.pics/KZNIB3iX.png

Link to the plugin itself: https://github.com/novomesk/qt-jpegxl-image-plugin

So, yes, I do think it's worth to actually integrate it in Firefox.

At the very least, priority 5 seems very inappropriate now that the format is frozen.

In some cases, JXL looks better than AVIF even when they're only one-third of the size. Add to that the ability to losslessly recompress legacy jpegs, and I'm surprised CDNs aren't screaming for it to be implemented.

Chrome is also adding jxl as Content-Encoding. See https://bugs.chromium.org/p/chromium/issues/detail?id=1088429
I don't know if we need to open a separate bug for this too.

(In reply to Robert-André Mauchin from comment #9)

Chrome is also adding jxl as Content-Encoding. See https://bugs.chromium.org/p/chromium/issues/detail?id=1088429
I don't know if we need to open a separate bug for this too.

It seems it's a confidential issue, I can't access it 🤔

See Also: → 1688064

(In reply to Kagami :saschanaz from comment #10)

(In reply to Robert-André Mauchin from comment #9)

Chrome is also adding jxl as Content-Encoding. See https://bugs.chromium.org/p/chromium/issues/detail?id=1088429
I don't know if we need to open a separate bug for this too.

It seems it's a confidential issue, I can't access it 🤔

Yes it is confidential but mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=1056172#c14

JPEG XL is at the FDIS stage now, meaning the bitstream is officially frozen: no more technical changes to the ISO/IEC specification are allowed.

Chromium has image/jxl support as a priority 1 bug now: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c2

The libjxl reference implementation (https://gitlab.com/wg1/jpeg-xl) has matured to the point that the decode API is stable (no backwards incompatible changes will be made to it).

There is a helpful community of early adopters and developers of jxl available that can be reached via discord: https://discord.gg/DqkQgDRTFu
I am sure they will be able to help with the actual implementation of this feature.

I think this might be a good time to revisit the priority of this bug.

Chrome announced their intent to ship JPEG XL support (behind a flag for now): https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/BK9qXyz1BwAJ

Assignee: nobody → krosylight
Depends on: 1707590
Depends on: 1709814
Depends on: 1709815
Depends on: 1709816
Depends on: 1709818
Depends on: 1709857

The name "Next-Generation Image Compression" is not used anymore. Changing the title to make better search result.

Summary: Implement support for Next-Generation Image Compression (JPEG XL) → Implement support for JPEG XL (image/jxl)
Depends on: 1711850

Erik Andre from the Images Infra team at Facebook here. I'd like to share a bit of our view on JPEG XL in the context of new image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser adoption will let us move forward with our plans to test and hopefully roll out JPEG XL.

After spending the last 5 months investigating and evaluating JPEG XL from both a performance and quality point of view, it's our opinion that JPEG XL has the most potential of the new generation of image formats that are trying to succeed JPEG.

This opinion is based on the following findings:

  • JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content.
  • Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that we can reach parity with JPEG when using multiple threads to decode. This matches and in many cases surpasses the decoding performance of other new image formats.
  • The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.

Having browser support from all the major browsers is going to make our lives a lot easier in upcoming WWW experiments and ensure that we can deliver a consistent experience across platforms and browsers.

I would like to add support from Adobe on the adoption of JPEG-XL into blink/chromium. JXL is an great advancement in raster imaging and we look forward to being able to offer support for content authoring an editing in JPEG-XL to our customers.

QA Whiteboard: qa-not-actionable

Given the manifestations from Facebook and Adobe, shouldn't this issue have its priority increased?

I'd like to pile on with support from SmugMug and Flickr for JXL.

According to https://wiki.mozilla.org/Bugzilla:Priority_System, P5 means "We basically never want this". Yet this has been assigned, so I presume this is no longer true?

Andres Osmond's reasons for leaving at P5 3 years ago were "For the moment, I'm happy to leave this as P5. AFAIK, the final specification isn't even targeted until October 2019, let alone any other browsers discussing shipping it."

I believe the spec is now frozen, and it is behind a flag in Chrome, so those reasons no longer apply.

(In reply to mfishe from comment #25)

I believe the spec is now frozen, and it is behind a flag in Chrome, so those reasons no longer apply.

It is behind a flag in Firefox Nightly too (about:preferences#experimental) via bug 1707590.

As representative of The Guardian, I would like to express our support for the adoption of JPEG XL:

  • JPEG XL has now been standardised and we think web browsers should implement standards and let web content producers decide the best standardised formats for their needs. We believe general adoption of new standardised formats should be driven by usage rather than ability to influence browser roadmaps.
  • We believe JPEG XL backward compatibility and benefits for encoding and decoding over JPEG will result in rapid adoption by CDN (or cloud image services) and content producers. For our own website, we will adopt it as soon as supported by our CDN and some browsers.
  • We believe JPEG XL is currently the strongest image format with the caveat that at very low qualities, AVIF could work better for us.
  • We believe that using more efficient compression formats (such as JPEG XL or Zstandard) has a positive impact on sustainability.

Does it still make sense to keep the priority as P5?

Flags: needinfo?(aosmond)

As pointed out in comment 26, bug 1707590 already landed support for this behind a pref. :saschanaz has been doing the work on this, and they will have a far better grasp on our position of if/when this feature could ship out in release. The priority of the bug itself isn't that important, as that work was still done despite it :).

Flags: needinfo?(aosmond)

They who? I mean, who else besides :aosmond?

Flags: needinfo?(aosmond)
Flags: needinfo?(aosmond) → needinfo?(krosylight)
Priority: P5 → P3

I don't think I have much to say at this point, any public position will be posted on https://github.com/mozilla/standards-positions/issues/522.

Flags: needinfo?(krosylight)

So, now that both ffmpeg and mpv have native support for the JPEG-XL format, I think this is the right time to actually support it by default on all builds.

Flags: needinfo?(krosylight)

Thank you for the information. For the log:

Flags: needinfo?(krosylight)

Is it safe to say jxl will be enabled by default in Firefox 101?

(In reply to charles2000wang from comment #34)

Is it safe to say jxl will be enabled by default in Firefox 101?

(Quick disclaimer: I'm not a Mozilla developer. Just following progress in bugs/features I care about. I think I know what I talk about, but maybe not as much as I think ;-) )

When Zak talks about "support it by default in all builds", I think he talks about making early support available behind a flag in about:config settings in all builds (nightly, beta, release). Currently it is only available that way in nightlies (AFAIK). So it could f.ex. be Mozilla also makes the experimental support available via about:config in beta & release version 103.

As for "enabled by default" I understands it like you talk about "out of the box support" in general? By experience on following work on other features here, incl. AVIF support, I think you should prepare yourself it is not even close yet. If you look at dependencies to this bug, you will see it still depends on unresolved bugs for color profile, progressive decoding, proper transparency, animation & HDR. Maybe one or two of them doesn't have to be closed, but most will have to be, before feature can be 100% enabled in a release version of Firefox.

Thanks for the information Stig. I suppose jxl behind a flag on release build would be fine for my use case since I can't seem to find a jxl viewer that runs on many different platforms yet.

easy solution; install Nightly. run it with a new profile and set your jxl files up: "open with Nightly"
done

So when will the support finally arrive? I don't expect the average user to install a "nightly" and go to developer settings which are actively marked dangerous to enable the image format I use on my webpages. That's ridiculous.

Flags: needinfo?(krosylight)

(In reply to cyrond from comment #38)

So when will the support finally arrive? I don't expect the average user to install a "nightly" and go to developer settings which are actively marked dangerous to enable the image format I use on my webpages. That's ridiculous.

Maybe you shouldn't use an image format on your webpages that isn't guaranteed to be supported by all browsers... There are plenty of good quality alternatives that are supported by everything.

Only JPEG, PNG and GIF are currently guaranteed to be supported by everything. All newer image/animation formats (jpeg 2000, webp, avif, mp4, jxl) are supported by some browsers but only have partial/buggy support in others, or no support at all.

So if guaranteed support by all browsers is a requirement, I wouldn't say there are plenty of good alternatives. Fortunately we do have content type negotiation (Accept headers) and picture tags so fallback is possible and full universal support is not really required.

(In reply to cyrond from comment #38)

So when will the support finally arrive? I don't expect the average user to install a "nightly" and go to developer settings which are actively marked dangerous to enable the image format I use on my webpages. That's ridiculous.

Let's put things in perspective:

https://caniuse.com/jpegxl

But I think it is great you want to be an early adopter. You can for example use the <picture> tag to offer a fallback to jpeg or other formats:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture#the_type_attribute

@Mark Straver which are "the plenty good alternatives" to put images with more than 8-bit color depth on a website, which is supported by "all major browsers?

@jon agreed. It's a mess.

@Stig Nygaard the website you linked showing the same issue on other Browsers as well: If they support it the user needs to do experimental flags. What's the issue of just turning it on? I mean it's a standard and there's plenty demand for sharing images on the web AND it's built into the browser already.

The issue with just turning it on is like with AVIF in the past: current support is incomplete. With missing color profile support, the rendering would be incorrect. Also, if the support is buggy, it could crash the renderer or not display an image instead of falling back to another format if available. Like for AVIF, it is likely to take some time until one of the browser makes a move of enabling it by default. This is unfortunate as JPEG-XL is a better format than AVIF.

@cyrond you can go as far back as standard jpg with color profiles if you want to go beyond sRGB. I don't know about Firefox's status at the moment (I believe still v2 ICC only? or has v4 been enabled? I haven't kept track)
I'm not entirely sure if webp (or upcoming webp2) supports wide gamut natively.

You also have to ask yourself whether wide gamut display is important for websites; considering the very slow and spotty adoption of several alternative image formats by any browser, the real world answer is probably "not so much". I've personally attempted to push for JXR when it was gaining a bit of traction, but ultimately wasn't adopted despite being standardized. JXL just feels like "yet another jpg successor" that isn't being widely adopted, at this point, and a pretty poor investment of resources for implementers.

@Mark Straver There are dozens of image databases with tens of thousands of images that would greatly benefit from an implementation of JPEG-XL. Transitioning would save gigabytes of storage on these sites, obviously reducing the bandwidth needed to browse them. Thousands of people would be able to have tolerable experiences on these sites instead of the borderline unusable experiences offered now.

@basis38 & @cyrond, we will probably soon be asked to stop this irrelevant conversion, which doesn't really bring anything constructive for solving this issue. But what I think that you don't understand is that Mozilla, Google and other browser makers really want to so support JPEG XL and already are working hard on it! But things like this take time. It is not just putting a checkmark somewhere saying we want to support the format, and then next browser-version magically supports it. Implementing the support is a big task and takes time, and enabling support when it is still buggy and incomplete can be harmful for not only browser security and performance, but also for the adaption of JPEG XL in general because of the issues that will cause for sites trying to use it.
If you want to use something more modern now, with better compression, possibility of higher bit depths and other modern features, then take a look at the AVIF-format which have at least decent browser support: https://caniuse.com/avif

Hi people, thank you for your patience. Unfortunately we don't have any sharable public update about this yet.

For now I'd also recommend using <picture> for falling back to existing image formats, given that no browser supports JXL by default yet.

Flags: needinfo?(krosylight)

One note regarding the documentation: Once implemented, this should at least be mentioned at https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types.

Sebastian

@Stig Nygaard thanks for beeing so open. Doesn't want to stirr up things here.

I was wondering if it's not at least possible to move the support to the stable version of Firefox – so users can turn it on and test it and report back without installing a nightly version?

That's how all other browsers seem to handle this right now.

(In reply to cyrond from comment #49)

@Stig Nygaard thanks for beeing so open. Doesn't want to stirr up things here.

I was wondering if it's not at least possible to move the support to the stable version of Firefox – so users can turn it on and test it and report back without installing a nightly version?

That's how all other browsers seem to handle this right now.

You can:

about:config

image.jxl.enabled -> true

(In reply to gfowler1 from comment #50)

Setting image.jxl.enabled to true has no effect on stable version, because from toolkit/moz.configure, JXL support is enabled only for Nightly builds.

Therefore, Firefox stable builds do not link to libjxl - even though you can find image.jxl.enabled in about:config, it does nothing on stable.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S3

Breaking news: Google deprecates JPEG-XL in Chrome/Chromium M110 https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL
This is quite ridiculous https://jpegxl.info/comparison.png

Chiming in here. Due to the current news breaking about Chromium discontinuing JXL, I first heard of the format. Was very glad to find that you can enable it in Firefox. So I did. But it still does not work. Version is 106.0.3 (64-Bit). It gives me the green checkmark saying the version is up to date.

So I can confirm that, as others wrote, the flag is bugged out on stable.

(In reply to existencielle from comment #58)

Chiming in here. Due to the current news breaking about Chromium discontinuing JXL, I first heard of the format. Was very glad to find that you can enable it in Firefox. So I did. But it still does not work. Version is 106.0.3 (64-Bit). It gives me the green checkmark saying the version is up to date.

So I can confirm that, as others wrote, the flag is bugged out on stable, because the functionlity ins't ready.

The necessary code isn't bundled on Firefox stable. So, the flag has no use.

Can someone from the firefox team say if they're planning to keep going with the implementation of jpeg xl, in lieu of what's been going on?

I very much hope so.

Bugzilla is our bug tracker, not a discussion forum about what other browsers are doing. Going to restrict comments here at least for now so the 100+ people CC'd don't get repeated emails from people upset about what other browsers do, or about some features only existing on nightly (which isn't unusual for things that aren't ready for general release).

Any changes to what Gecko does here will go through the usual channels (dev-platform announcements, probably eventual status changes to this bug or its blockers/dependencies). Asking for updates isn't productive use of a bug tracker.

Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.