But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinema / artist workflow production. Hopefully the rust decoder will be ready soon.
And from the wording, it seems to imply Google Chrome will officially support anything from AOM.
I don't think that's strictly true.
The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings.
However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonisagrista.com/blog/2023/jpegxl-vs-avif/)
Even at the point where AVIF should shine: when low bandwidth is important, JXL supports progressive decoding (AVIF is still trying to add this) so the user will see the images sooner with JXL rather than AVIF.
---
There is one part where AVIF does beat JXL hands down, and that's animation (which makes sense considering AVIF comes from the modern AV1 video codec). However, any time you would want an animation in a file, you're better off just using a video codec anyway.
Isn't JPEG-XL a lossy codec?
While lossy codec is hard to compare and up for debate. JPEG-XL is actually better as a lossless codec in terms of compression ratio and compression complexity. There is only one other codec that beats it but it is not open source.
But at what cost? From this the en/decoding speed (links below) is much higher for those advanced video codecs, so for various lower powered devices they wouldn't be very suitable?
Also, can we expect "near max potential" with AV2/near future or is it an ever-unachievable goal that shouldn't stop adding "non-max" codecs?
https://res.cloudinary.com/cloudinary-marketing/image/upload...
https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
blink-dev mailing list
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
Tracking Bug (reopened)
The patch at the end of that thread uses a C++ implementation so it is a dead end.
> The team explained that other platforms moved ahead. Safari supports JPEG XL, and Windows 11 users can add native support through an image extension from Microsoft Store. The format is also confirmed for use in PDF documents.
glad those folks didn't listen to "the format is dead since the biggest browser doesn't support it" (and shame on Firefox for not doing the same)
Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube.
It's absolutely bonkers to me that we've all collectively figured out how to stream a Hollywood movie to a pocket device over radio with a quality exceeding that of a typical cinema theatre, but these multi-trillion market cap corporations have all utterly failed to allow users to reliably send a still image with the same quality to each other!
Any year now, maybe in 2030s, someone will get around to a ticket that is currently at position 11,372 down the list below thousands of internal bullshit that nobody needed done, rearranging a dashboard nobody has ever opened, or whatever, and get around to letting computers be used for images. You know, utilising the screen, the only part billions of users ever look at, with their human eyes.
I can't politely express my disgust at the ineptitude, the sloth, the foot dragging, the uncaring unprofessionalism of people that get paid more annually then I get in a decade who are all too distracted making Clippy 2.0 instead of getting right the most utterly fundamental aspect of consumer computing.
If I could wave a magic wand, I would force a dev team from each of these companies to remain locked in a room until this was sorted out.
What am I missing?
Sure, me too! I can take a HDR P3 gamut picture with my iPhone and share it with all my friends and relatives... that have iPhones.
What I cannot do is take a picture with a $4000 Nikon DSLR and share it in the same way... unless I also buy a Mac so I can encode it in the magic Apple-only format[1] that works... for Mac and IOS users. I have a Windows PC. Linux users are similarly out in the cold.
This situation so incredibly bad that I can pop the SD card of my camera into an reader plugged into my iPhone, process the RAW image on the iPhone with the Lightroom iPhone app in full, glorious HDR... and then be unable to export the HDR image onto the same device for viewing because oh-my-fucking-god-why!?
[1] They claim it is a standards-compliant HEIF file. No, it isn't. That's a filthy lie. My camera produces a HDR HEIF file natively, in-body. Everything opens it just fine, except all Apple ecosystem devices. I suspect the only way to get Apple to budge is to sue them for false advertising. But... sigh... they'll just change their marketing to remove "HEIF" and move on.
I think Ultra HDR (and Apple's take on it, ISO 21496-1) make a lot of sense in a scenario where shipping alternate formats/codecs is not viable because renderer capabilities are not known or vary, similarly to how HDR was implemented on Blu-Ray 4K discs with the backwards-compatible Dolby Vision profiles.
It's also possible to do what Apple has done for HEIC on iOS: Store the modern format, convert to the best-known supported format at export/sharing time.
Indeed. I tried every possible export format from Adobe Lightroom including JPG + HDR gainmaps, and it looks... potato.
With a narrow gamut like sRGB it looks only slightly better than JPG, but with a wider gamut you get terrible posterization. People's faces turn grey and green and blue skies get bands across them.
Meanwhile my iPhone creates flawless 10-bit Dolby Vision video with the press of a button that I can share with anyone without it turning into a garbled mess.
Just last week I checked up on the "state of the art" for HDR still image sharing with Gemini Deep Research and after ten minutes of trawling through obscure forum posts it came back with a blunt "No".
We've figured out how to make machines think, but not how to exchange pictures in the quality that my 12-year-old DSLR is capable of capturing!
... unless I make a YouTube video with the images. That -- and only that -- works!
JPEG XL's normal HDR capabilities were not harmed in the process when UltraHDR was added.
It was added for reaching parity with JPEG1 and HEIF/AVIF for the needs of UltraHDR developers and believers.
It appears we’re getting closer to being able to exchange HDR images [1]:
[1]: https://gregbenzphotography.com/hdr-photos/iso-21496-1-gain-...
That's a size of a 30 minute TV show for a single happy snap.
Not exactly user-friendly for sharing in a text message.
Huh? Safari seems to render HDR JPEG XLs without any issues these days (e.g. [1]), and supports wide gamut in even more formats as far a I remember.
The problem is that I can't, in general widely share a HDR image and have it be correctly displayed via ordinary chat applications, social media, email, or what have you. If it works at all, it only works with that One Particular Format in One Specific Scenario.
If you disagree, find me something "trivial", such as a photo sharing site that supports HDR image uploads and those images are viewable as wide-gamut HDR on mobile devices, desktops, etc... without any endpoint ever displaying the image incorrectly such a very dark, very bright, or shifted colors.
i understand some of this frustration, but really you just have to use ffmpeg to convert it to a web format (which can be done by ffmpeg.js running in a service worker if your cpu is expensive) and spell <img as <video muted autoplay playsinline which is only a little annoying
> I can't politely express my disgust at the ineptitude, the sloth, the foot dragging, the uncaring unprofessionalism of people that get paid more annually then I get in a decade who are all too distracted making Clippy 2.0 instead of getting right the most utterly fundamental aspect of consumer computing.
hear hear
> If I could wave a magic wand, I would force a dev team from each of these companies to remain locked in a room until this was sorted out.
i can think of a few better uses for such a wand...
Doesn't work for sharing images in text messages, social media posts, email, Teams, Wikipedia, etc...
> i can think of a few better uses for such a wand...
We all have our priorities.
You act like this is some kind of mistake or limit of technology, but really it's an obvious intentional business decision.
Under late stage capitalism, it'd be weird if this wasn't the case in 2026.
Address the underlying issue, or don't be surprised by the race to the bottom.
On one hand, there have been (and still are!) several competing HDR formats for videos (HDR+, Dolby Vision, "plain" HLG, Dolby Vision in HLG etc.), and it tooks years for a winner to pull ahead – that race just started earlier, and the set of stakeholders is different (and arguably a bit smaller) than that for still images.
On the other hand, there are also several still image HDR formats competing with each other right now (JPEG with depth map metadata, i.e. Ultra HDR and ISO 21496-1, Apple's older custom metadata, HEIF, AVIF, JPEG XL...), and JPEG XL isn't the clear winner yet.
Format wars are messy, and always have been. Yes, to some extent they are downstream of the lack of a central standardization body, but there's no anti-HDR cabal anywhere. If anything, it's the opposite – new AV formats requiring new hardware is just about the best thing that can happen to device manufacturers.
This has been supported by both Apple and third party apps for over a decade. I’ve implemented it myself.
Actual HDR needs at least 10 bits per channel and a modern display with peak brightness far in excess of traditional monitors. Ideally over 1,000 nits compared to typical LCD brightness of about 200.
You also don't need "three pictures". That was a hack used for the oldest digital cameras that had about 8 bits of precision in their analog to digital converters (ADC). Even my previous camera had a 14-bit ADC and in practice could capture about 12.5 bits of dynamic range, which is plenty for HDR imaging.
Lightroom can now edit and export images in "true" HDR, basically the same as a modern HDR10 or Dolby Vision movie.
The problem is that the only way to share the exported HDR images is to convert them to a movie file format, and share them as a slide show.
There is no widely compatible still image format that can preserve 10-bit-per-channel colours, wide-gamut, and HDR metadata.
But until now, the position of other Googlers (in the Chrome team) was that they didn't want to have JPEG XL support in Chrome. And that changed now. Which is a big deal.
https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines USE_JPEGXL only for macOS < 14 (which aren't actually supported any more!).
All the in-tree JPEG XL support, e.g., https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... is behind a "USE(JPEGXL)" ifdef — so none of that is compiled in.
Instead, it's using what Apple ships at a system level, in Image I/O.
https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines HAVE_JPEGXL for recent versions of Apple's OSes. https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884... is the commit which added this — there's really not much there, because it's just setting the define and adding it to the allowlist of image types.
And yeah, currently I believe this is libjxl — or a fork thereof — hence the inclusion of libjxl in the Acknowledgements.rtf file on macOS.
To be really fair, on Windows:
- H.264 is the only guaranteed (modern-ish) video codec (HEVC, VP9, AV1 is not built-in unless the device manufacturer bothered to do it)
- JPEG, GIF, and PNG are the only guaranteed (widely-used) image codecs (HEIF, AVIF, and JXL is also not built-in)
- MP3 and AAC are the only guaranteed (modern-ish) audio codecs (Opus is another module)
... and all of them are widely used when Windows 7 was released (before the modern codecs) so probably modules are now the modern Windows Method™ for codecs.
Note on pre-8 HEVC support: the codec (when not on VLC or other software bundling their own codecs) is often on that CyberLink Bluray player, not a built-in one.
There is no reason to block its adoption.
