As a radiology software developer: please please let JPEG XL become a thing.
I sincerely hope this might make Chrome change its mind.
JPEG XL is a game changer for 16 bit lossless images. The technical landscape for these kinds of images today is barren.
As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection.
On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
You're using the term "OS" but you're not talking about OSes you're talking about kernels.
The OS is what comes with the computer or gets installed in the default setup if you're installing yourself. Most of it is userspace.
Distros like Arch & Gentoo allow you to build a custom OS which in doing so blurs the definition quite a lot, but ultimately when people say "macOS" that term includes quite a lot of userspace things. Bundled software is absolutely a core part of every popularly used definition of the word "OS".
Yes image codecs are a user space thing, but a Mac or iOS app probably loads images using the Swift Image or UIImage class and passes it a filename, and then these same objects get passed to the display widgets to render. If the UI toolkit that ships with the OS supports a format, it will just work with most all of the apps that use the system UI toolkit.
There’s just not a lot left besides user experience and appearance for an OS to do.
Of course kennels and operating systems are highly complex and represent a ton of work… but what is left to impress with a press release?
My OS does everything I can imagine needing it to and the only thing I can imagine wanting it to do going forward is more or less just maintenance (UX/UI excluded)
Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?
>As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL.
As if people would have the screen to properly watch them? Perhaps a handful of high-end laptop owners... Except if those are the intended audience.
>image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
That's how you get half the apps supporting them (if you're lucky) and others not, and generally a hell of a time...
> I sincerely hope this might make Chrome change its mind.
I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day?
If the decision was intentional: did they state a reason why?
"Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"
The issue on the Chromium tracker is now one of the most-starred and most-commented-on of all time because people from all over came to tell Google that they're insane, from Intel to Adobe to Facebook to Krita to Cloudinary to Shopify to Serif/Affinity to the VESA DisplayHDR Chairman.
It may also be worth noting that the author of commit to remove support from Chromium appears to be a WebP co-author, having given talks about WebP and being the primary contributor to libwebp.
They did all the work required to implement it, sat around for a few months, and then removed it, before anyone else even noticed it was there / had a chance to start integrating it.
My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.
Not an expert either by far, but DICOM isn't just images, it's a much larger data structure and following protocol, which deals with the transmission of the data between devices as well. The files are just one part of it. It also supports more dimensions to the data frames other than 2D. The pixel data in DICOM itself uses JPEG however (among other potential pixel compression methods), and it is possible that JPEG XL rolled into DICOM could allow for benefits.
Video is not lossless, a second of high quality video might be a total of 5 megabytes.
A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well.
You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
https://giannirosato.com/blog/post/nvenc-v-qsv/ This site has WASM-decoded JXL images using JXL.js. Native support would be much faster, & trying to decode much larger images with JXL.js doesn’t work very well.
Could you explain how so? JPEG XL seems cool enough but what about e.g. AVIF makes it "just a passive delivery format" instead of a general-purpose image format? It handles color spaces, lossless, lossy, up to 12 bit, up to 4:4:4/RGB, transparency, and animation at a good quality/size ratio so what's so drastically different about JPEG XL to move them to separate categories?
I think 12-bit colour stops it being adopted for ‘master’ images intended for editing. The current top comment says that 16-bit depth is a requirement for radiology. Also, I've read that its lossless encoding is often very poor — larger than PNG.
(I didn't downvote, BTW; it's a reasonable question.)
the tldr is that video formats are relationship mediocre for images because the tradeoffs you make to compress an image that will be seen for 1/60th of a second are different than those for a static image.
They're suited for delivery because they're based on video codecs (WebP on VP8, AVIF on AV1) for which consumer hardware typically has hardware decoding support, but were not designed for still images. AVIF is newer and substantially better than WebP, but still has limited colour depth and channels, so it's comparatively poor for editing. Lossless mode is not good for non-photo content. Encoding is relatively slow without hardware support.
Good. I can't believe the Google argument for removal, being in effect "it's only slightly better in every single way than all the other formats we support, and not enough people jumped though the hoops to manually opt into it, so we're removing it entirely."
Here's the text of the WWDC session description that will cover JPEG XL [1]:
Learn about the latest image formats and video technologies supported in Safari 17. Discover how you can use JPEG XL, AVIF, and HEIC in your websites and experiences and learn how they differ from previous formats. We’ll also show you how the Managed Media Source API draws less power than Media Source Extensions (MSE) and explore how you can use it to more efficiently manage streaming video over 5G.
The link isn't live yet as the session is scheduled for Thursday, June 8th.
I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome.
Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now, where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as any situation where progressive display helps. For folks producing images, is much easier to fit in than AVIF for anyone who needs to encode a lot on the CPU.
> I hope it shows up in Safari and that this sign of interest from others gets it a second shot in Chrome.
I'm pretty sure the Chrome team knew at the time they dropped JPEG XL that there was a decent chance Apple would implement it--there's certainly enough of a backchannel between the browser teams at Google, Apple, Mozilla and Microsoft.
Yeah, that is all odd to me; Google cited lack of "interest from the entire ecosystem" (https://bugs.chromium.org/p/chromium/issues/detail?id=117805...). Mozilla also had an experimental JXL implemenation out there. I'd hope, like you said, that the browser vendors had enough of a backchannel to keep a good thing from fizzling because each is uncertain if the others will implement it.
But if the Chrome folks did know they had all three major browser engines were ready to go, along with the positive noises from Facebook, Adobe, other parts of Google, and a few other notable folks, that seems like a solid base of support, unless you're really expecting the world to go all-in on a format before a browser supports it without a flag. So I guess I wonder if it's that the Chrome team had set the bar high, that they hadn't expected Apple to support JXL at the time they made the call, or something else.
Those words were about the JPEG recompressor (Brunsli) specifically, which saves about 22% but has a smoother transition from today's .jpg world than any of the new lossy formats; you can bit-for-bit reconstruct the original JPEG from the Brunsli-compressed one, and it's certainly much faster than AVIF to encode with CPUs. You can even insert Brunsli as a Content-Encoding that's transparent to the user (so right click still saves .jpg), and Chrome had an issue open to consider doing that before they backed out JXL support.
JPEG XL is the first image format in over a decade that has shown real quality improvements for high-frequency images (i.e. sharp edges). JPEG 2000 is competitive with all of the video codec I-frame formats I've tried, and you can embed them in PDFs unmodified, so I've not troubled with anything new.
Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.
Firefox came to the conclusion they didn't really care too so it's not just Google that is iffy about it. With Apple pushing it now... maybe that will change things in the long run?
Firefox has next to zero marketshare (unfortunately and despite my best efforts to get people to use FF). There was never any chance that Mozilla was going to waste their very limited resources attempting to be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.
AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).
This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.
Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.
I'm trying to understand the motivation here. There's a few new image formats as potential candidates: jpeg xl, webp v2, avif, heic. Apple already had heic in the os, but still not Safari AFAIK. Avif has the benefit of hardware encoders/decoders (with limited chroma options though).
I see the HDR mentioned in other comments which is interesting.
Are there any (potential conspiracy) reasons they would choose not to go for another format?
I'm trying to understand how they arrived at this answer given it was available for years and ignored in popular software.
I'm confused where you got "it was available for years and ignored in popular software" from? Most of the ISO standard was only published last year, with the last bit being published in October 2022. IIRC AVIF is almost ~4 years old by the same standards and WebP is over a decade old.
Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc.
My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself.
Aside from JPEG 2000, which did in fact gain traction in a few verticals, the grandparent might have also confused it for JPEG-LS (1999), JPEG XR (2009), JPEG XT (2015), or JPEG XS (2019).
Honestly I think the biggest risk to adoption of JPEG XL might be this prior brand dilution.
The big feature JPEG XL offers that HEIC and AVIF do not is lossless filesize reduction for JPEG images (such as those produced by basically every non-iphone camera).
Also AVIF and HEIC as specified don't support >8k images.
Readit News
On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
The OS is what comes with the computer or gets installed in the default setup if you're installing yourself. Most of it is userspace.
Distros like Arch & Gentoo allow you to build a custom OS which in doing so blurs the definition quite a lot, but ultimately when people say "macOS" that term includes quite a lot of userspace things. Bundled software is absolutely a core part of every popularly used definition of the word "OS".
Of course kennels and operating systems are highly complex and represent a ton of work… but what is left to impress with a press release?
My OS does everything I can imagine needing it to and the only thing I can imagine wanting it to do going forward is more or less just maintenance (UX/UI excluded)
Any comparision photos out there?
As if people would have the screen to properly watch them? Perhaps a handful of high-end laptop owners... Except if those are the intended audience.
>image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I just install the codec and code away.
That's how you get half the apps supporting them (if you're lucky) and others not, and generally a hell of a time...
- Better compression ratios
- Ability to modify effort of lossless compression (good for real time transcoding)
- Multi-threaded encode and decode
- Far superior progressive decoding (great for low bandwidth scenarios, just stream in the lossless quality over time)
If things with Apple go well and JPEG XL is supported natively on macOS, iOS and iPadOS this fall, it would be on its way to becoming a thing.
After all, 2 billion devices isn't nothin’.
I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day?
If the decision was intentional: did they state a reason why?
https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
"Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:
- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"
The issue on the Chromium tracker is now one of the most-starred and most-commented-on of all time because people from all over came to tell Google that they're insane, from Intel to Adobe to Facebook to Krita to Cloudinary to Shopify to Serif/Affinity to the VESA DisplayHDR Chairman.
It may also be worth noting that the author of commit to remove support from Chromium appears to be a WebP co-author, having given talks about WebP and being the primary contributor to libwebp.
https://chromium-review.googlesource.com/c/chromium/src/+/40...
https://chromium.googlesource.com/webm/libwebp/+log
My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
JPEG XL has gained broader industry interest than any of the previous attempts to replace JPEG.
I think someone is very hurt that their web p pet project has earned more hate than love
Discussed several times previously on HN:
https://news.ycombinator.com/item?id=35589179
https://news.ycombinator.com/item?id=33399940
https://news.ycombinator.com/item?id=33563378
Deleted Comment
Yes It was intentional.
They stated AVIF is as good if not better than JPEG XL.
A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well.
You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
(I didn't downvote, BTW; it's a reasonable question.)
Learn about the latest image formats and video technologies supported in Safari 17. Discover how you can use JPEG XL, AVIF, and HEIC in your websites and experiences and learn how they differ from previous formats. We’ll also show you how the Managed Media Source API draws less power than Media Source Extensions (MSE) and explore how you can use it to more efficiently manage streaming video over 5G.
The link isn't live yet as the session is scheduled for Thursday, June 8th.
[1]: https://developer.apple.com/videos/play/wwdc2023/10122/
Just the JPEG recompression is arguably worth the price of entry; it's less savings than AVIF, of course, but it's easier to adopt now, where re-encoding everything as AVIF is a much larger hump to get over. Its other modes provide some real benefits for users for very-high-quality and lossless images as well as any situation where progressive display helps. For folks producing images, is much easier to fit in than AVIF for anyone who needs to encode a lot on the CPU.
I'm pretty sure the Chrome team knew at the time they dropped JPEG XL that there was a decent chance Apple would implement it--there's certainly enough of a backchannel between the browser teams at Google, Apple, Mozilla and Microsoft.
But if the Chrome folks did know they had all three major browser engines were ready to go, along with the positive noises from Facebook, Adobe, other parts of Google, and a few other notable folks, that seems like a solid base of support, unless you're really expecting the world to go all-in on a format before a browser supports it without a flag. So I guess I wonder if it's that the Chrome team had set the bar high, that they hadn't expected Apple to support JXL at the time they made the call, or something else.
Deleted Comment
Your move, Google.
WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.
AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).
This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.
Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.
Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/?utm_sour...
Chrome: https://chrome.google.com/webstore/detail/add-jxl-support/kh...
I see the HDR mentioned in other comments which is interesting.
Are there any (potential conspiracy) reasons they would choose not to go for another format?
I'm trying to understand how they arrived at this answer given it was available for years and ignored in popular software.
Adobe has partial support (in Camera RAW) with presumably further support coming considering their website recommends JXL alongside AVIF for HDR images. It's also supported by Affinity Photo 2, Krita, Darkroom, GIMP, ffmpeg, ImageMagick, Paint.net, anything Qt/KDE-based via plugin, Pale Moon, libvips, and almost every third-party image viewer that I've ever used or heard of (nomacs, Irfanview, ImageGlass, xnView, etc.). It also has had vocal support from senior engineers at a variety of companies like Facebook, Shopify, Cloudinary, Intel, Flickr, etc.
My first thought when I heard about JXL several months ago was "oh, a new JPEG-2000?" but I've quickly become a JXL evangelist after reading more about it and then playing around with libjxl myself.
https://jpegxl.info/why-jxl.html
https://jpegxl.io/articles/faq/
https://cloudinary.com/blog/the-case-for-jpeg-xl
Honestly I think the biggest risk to adoption of JPEG XL might be this prior brand dilution.
https://en.wikipedia.org/wiki/Lossless_JPEG#JPEG-LS
https://en.wikipedia.org/wiki/JPEG_2000
https://en.wikipedia.org/wiki/JPEG_XR
https://en.wikipedia.org/wiki/JPEG_XT
https://en.wikipedia.org/wiki/JPEG_XS
Also AVIF and HEIC as specified don't support >8k images.