Implement support for JPEG XL (image/jxl)
Categories
(Core :: Graphics: ImageLib, enhancement, P3)
Tracking
()
People
(Reporter: Virtual, Assigned: saschanaz)
References
(Depends on 5 open bugs, )
Details
(4 keywords)
More info here - https://jpeg.org/items/20180423_cfp_jpeg_xl.html
final Call for Proposals - https://jpeg.org/downloads/jpegxl/jpegxl-cfp.pdf
additional information on Coding of Still Pictures - https://jpeg.org/downloads/jpegxl/wg1n80024-additional-information-cfp.pdf
JPEG XL Reference Software - https://gitlab.com/wg1/jpeg-xl
Overview of JPEG XL - https://jpeg.org/jpegxl/
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
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.
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
Comment 4•4 years ago
|
||
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.
Comment 5•4 years ago
|
||
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.
Comment 6•4 years ago
|
||
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.
Comment 9•4 years ago
|
||
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.
Assignee | ||
Comment 10•4 years ago
|
||
(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 🤔
Comment 11•4 years ago
|
||
Filed jxl as Content-Encoding here: https://bugzilla.mozilla.org/show_bug.cgi?id=1688064
Comment 12•4 years ago
|
||
(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
Comment hidden (advocacy) |
Comment 14•4 years ago
|
||
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.
Comment 15•3 years ago
|
||
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 | ||
Updated•3 years ago
|
Assignee | ||
Comment 16•3 years ago
|
||
The name "Next-Generation Image Compression" is not used anymore. Changing the title to make better search result.
Updated•3 years ago
|
Assignee | ||
Comment 17•3 years ago
|
||
Changing the URL since it's marked as duplicated:
Comment 18•3 years ago
|
||
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.
Assignee | ||
Updated•3 years ago
|
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•3 years ago
|
Comment 19•3 years ago
|
||
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.
Comment hidden (metoo) |
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•3 years ago
|
Comment 21•3 years ago
|
||
Given the manifestations from Facebook and Adobe, shouldn't this issue have its priority increased?
Comment hidden (advocacy) |
Comment 23•3 years ago
|
||
I'd like to pile on with support from SmugMug and Flickr for JXL.
Comment hidden (advocacy) |
Comment 25•3 years ago
|
||
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.
Comment 26•3 years ago
|
||
(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.
Comment 27•3 years ago
|
||
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.
Comment 28•3 years ago
|
||
Does it still make sense to keep the priority as P5?
Comment 29•3 years ago
|
||
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 :).
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 31•3 years ago
•
|
||
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.
Comment 32•2 years ago
|
||
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.
Assignee | ||
Comment 33•2 years ago
|
||
Thank you for the information. For the log:
- ffmpeg (libavcodec): https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=458cc7e314e1a00017dd090db388db6659d1bb5f
- mpv (which uses libavcodec): https://github.com/mpv-player/mpv/pull/10126
Comment 34•2 years ago
|
||
Is it safe to say jxl will be enabled by default in Firefox 101?
Comment 35•2 years ago
|
||
(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.
Comment 36•2 years ago
|
||
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.
Comment 37•2 years ago
|
||
easy solution; install Nightly. run it with a new profile and set your jxl files up: "open with Nightly"
done
Comment 38•2 years ago
|
||
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.
Comment 39•2 years ago
|
||
(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.
Comment 40•2 years ago
|
||
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.
Comment 41•2 years ago
|
||
(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:
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
Comment 42•2 years ago
|
||
@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.
Comment 43•2 years ago
|
||
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.
Comment 44•2 years ago
|
||
@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.
Comment 45•2 years ago
|
||
@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.
Comment 46•2 years ago
|
||
@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
Assignee | ||
Comment 47•2 years ago
|
||
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.
Comment 48•2 years ago
•
|
||
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
Comment 49•2 years ago
|
||
@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.
Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)
Reporter
|
||
Updated•2 years ago
|
Comment 50•2 years ago
|
||
(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
Comment 51•2 years ago
|
||
(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.
Comment 52•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 53•2 years ago
|
||
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
Comment hidden (advocacy) |
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment 58•2 years ago
|
||
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.
Comment 59•2 years ago
|
||
(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.
Comment 60•2 years ago
|
||
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.
Comment 61•2 years ago
|
||
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.
Updated•1 year ago
|
Description
•