> Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome.
That conversation doesn't apply to their core products: Search, Mail, Maps, Chrome, Android. Their commitment to maintaining these services over decades has been amazing. It's everything else that sucks.
JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).
avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
You also get it for basically free because it's just an av1 key frame. Every browser needs an av1 decoder already unless it's willing to forego users who would like to be able to watch Netflix and YouTube.
I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.
> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.
Their standards position is still neutral; what switched a year ago was that they said they would be open to shipping an implementation that met their requirements. The tracking bug hasn't been updated[2] The patches you mention are still part of the intent to prototype (behind a flag), similar to the earlier implementation that was removed in Chrome.
They're looking at the same signals as Chrome of a format that's actually getting use, has a memory safe implementation, and that will stick around for decades to justify adding it to the web platform, all of which seem more and more positive since 2022.
I disagree about the image quality at typical sizes - I find JPEG-XL is generally similar or better than AVIF at any reasonable compression ratios for web images. See this for example: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
AVIF only comes out as superior at extreme compression ratios at much lower bit rates than are typically used for web images, and the images generally look like smothered messes at those extreme ratios.
If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.
People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG.
Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
> Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
That’s a function of the website, not the browser.
> That’s a function of the website, not the browser.
That's hand-waving away quite a lot. The task changes from serving a copy of a file on disk, as every other image format in common use, to needing a transcoding pipeline more akin to sites like YouTube. Technically possible, but lots of extra complexity in return for what gain?
Even though AVIF decoding support is fairly widespread by now, it is still not ubiquitous like JPEG/PNG/GIF. So typically services will store or generate the same image in multiple formats including AVIF for bandwidth optimization and JPEG for universal client support. Browser headers help to determine compatibility, but it's still fairly complicated to implement, and users also end up having to deal with different platforms supporting different formats when they are served WebP or AVIF and want to reupload an image somewhere else that does not like those formats. As far as I can tell, JXL solves that issue for most websites since it is backwards-compatible and can be decoded into JPEG when a client does not support JXL. I would happily give up a few percent in compression efficiency to get back to a single all-purpose lossy image format.
It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.
I have no previous first-hand knowledge of this, but I vaguely remember discussions of avif in google photos from reddit a while back so FWIW I just tried uploading some avif photos and it handled them just fine.
Listed as avif in file info, downloads as the original file, though inspecting the network in the web frontend, it serves versions of it as jpg and webp, so there's obviously still transcoding going on.
I'm not sure when they added support, the consumer documentation seem to be more landing site than docs unless I'm completely missing the right page, but the API docs list avif support[1], and according to the way back machine, "AVIF" was added to that page some time between August and November 2023.
You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail. Defeating the whole purpose of putting them into Photo.
Given it's an app, they didn't even need Google chrome to add support. Avif is supported on Android natively.
> You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail.
I'm not sure what you mean. They appear to act like any other photo in the interface. You can view them and they're visible in the thumbnail view, but maybe I'm misinterpreting what you mean?
I take a photo, the format is jpeg. It backs up to Google photo, the Google photo app on Android renders the photo just fine.
I then convert that photo (via a local converter) to AVIF, Google backs it up, I can see the file in Google Photo on Android but it doesn't render the image. That being full size or thumbnail, all I get is a grayed square. So I concluded the app doesn't support avif rasterizing.
I then gave up on the automation that converted all my jpeg into avif, which in turn would have saved hundred of gigabytes given I have 10y worth of photos.
The experiment was done about 3 months ago, as of 2025 Google Photo on Android, latest version, would not render my AVIF photos.
See cousin comment, it accepts AVIF files. At least they would render on the app. Which would be enough for many. As it stands it accepts this format and renders nothing at all.
The killer feature of JXL is that most websites already have a whole bunch of images in JPEG format, and converting those to JXL shrinks them by about 30% without introducing any new artifacts.
> Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains
On a slightly related note, I wanted to have a HDR background image in Windows 11. Should be a breeze in 2025 right?
Well, Windows 11 only supports JPEG XR[1] for HDR background images. And my commonly used tools did either not support JPEG XR (Gimp fex) or they did not work correctly (ImageMagick).
So I had a look at the JPEG XR reference implementation, which was hosted on Codeplex but has been mirrored on GitHub[2]. And boy, I sure hope that isn't the code that lives in Windows 11...
Ok most of the gunk is in the encoder/decoder wrapper code, but still, for something that's supposedly still in active use by Microsoft... Though not even hosting their own copy of the reference implementation is telling enough I suppose.
Another JPEG XR user is Zeiss. It saves both grayscale and color microscope images with JPEG XR compression in a container format. Zeiss also released a C++ library (libczi) using the reference JPEG XR implementation to read/write these images. Somehow Zeiss is moving away from JPEG XR - its newer version of microscope control software saves with zstd compression by default.
>avif is just better for typical web image quality,
What does "typical web image quality" even mean? I see lots of benchmarks with very low BPPs, like 0.5 or even lower, and that's where video-based image codecs shine.
However, I just visited CNN.com and these are the BPPs of the first 10 images my browser loaded: 1.40, 2.29, 1.88, 18.03 (PNG "CNN headlines" logo), 1.19, 2.01, 2.21, 2.32, 1.14, 2.45.
I believe people are underestimating the BPP values that are actually used on the web. I'm not saying that low-BPP images don't exist, but clearly it isn't hard to find examples of higher-quality images in the wild.
> Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
Sure, 12-bit too, with HDR transfer functions (PQ and HLG), wide-gamut primaries (BT.2020, P3, etc.), and high-dynamic-range metadata (ITU/CTA mastering metadata, content light level metadata).
JPEG XL matches or exceeds these capabilities on paper, but not in practice. The reality is that the world is going to support the JPEG XL capabilities that Apple supports, and probably not much more.
Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!
HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level.
I want JXL in web browsers, but without HDR support.
What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect?
Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)
Because then a user who wants to see the HDR image in all its full glory can do so. If the base image is not HDR, then there is nothing they can do about it.
> And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?
While I very much support more HDR in the online world, I fully agree with you here.
However, I suspect the reason will boil down to what it usually does: almost no users change the default settings ever. And so, any default which goes the other way will invariably lead to a ton of support cases of "why doesn't this work".
However, web browsers are dark-mode aware, they could be HDR aware and do what you prefer based on that.
That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame.
Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics.
However, like I said, it's up to the browser to handle this.
One suggestion I saw mentioned by some browser devs was to make the default to tone map HDR if the page is not viewed in fullscreen mode, and switch to full HDR range if it is fullscreen.
Even if that doesn't become the default, it could be a behavior the browser could let the user select.
Actually I forgot about auto-HDR conversion of SDR videos which some operating systems do. So it might not be the video itself, but rather the OS and video driver ruining things in this case.
Just because we're in the infancy of wide HDR adoption and thus experience some niggling issues while software folks work out the kinks isn't a good reason to just wholesale forego the feature in such a crucial piece of infrastructure.
Sure, if you don't want HDR in the browser I do think there should be a browser option to let you achieve that. I don't want to force it on everyone out there.
Keep in mind the screenshot you showed is how things looked on my Windows until I changed the auto-HDR option. It wasn't the browser that did it, it was completely innocent.
It was just so long ago I completely forgot I had changed that OS configuration.
If you want to avoid eye pain then you want caps on how much brightness can be in what percent of the image, not to throw the baby out with the bathwater and disable it entirely.
And if you're speaking from iphone experience, my understanding is the main problem there isn't extra bright things in the image, it's the renderer ignoring your brightness settings when HDR shows up, which is obviously stupid and not a problem with HDR in general.
> If the brightness cap of the HDR image is full SDR brightness, what value remains in HDR?
If you set #ffffff to be a comfortable max, then that would be the brightness cap for HDR flares that fill the entire screen.
But filling the entire screen like that rarely happens. Smaller flares would have a higher cap.
For example, let's say an HDR scene has an average brightness that's 55% of #ffffff, but a tenth of the screen is up at 200% of #ffffff. That should give you a visually impressive boosted range without blinding you.
I don't want the ability for 10% of the screen to be so bright it hurts my eyes. That's the exact thing I want to avoid. I don't understand why you think your suggestion would help. I want SDR FFFFFF to be the brightest any part of my screen goes to, because that's what I've configured to be at a comfortable value using my OS brightness controls.
I just don't want your "in between" "only hurt my eyes a little" solution. I don't see how that's so hard to understand. I set my brightness so that SDR FFFFFF is a comfortable max brightness. I don't understand why web content should be allowed to go brighter than that.
Yes, it's uncomfortable to have it get "ridiculously" bright.
But there's a level that is comfortable that is higher than what you set for FFFFFF.
And the comfortable level for 1% of the screen is even higher.
HDR could take advantage of that to make more realistic scenes without making you uncomfortable. If it was coded right to respect your limits. Which is probably isn't right now. But it could be.
I severely doubt that I could ever be comfortable with 10% of my screen getting much brighter than the value I set as max brightness.
But say you're right. Now you've achieved images looking completely out of place. You've achieved making the surrounding GUI look grey instead of white. And the screen looks broken when it suddenly dims after switching tabs away from one with an HDR video. What's the point? Even ignoring the painful aspects (which is a big thing to ignore, since my laptop currently physically hurts me at night with no setting to make it not hurt me, which I don't appreciate), you're just making the experience of browsing the web worse. Why?
Do they? Do people report that an HDR image on a web page that takes up roughly 10% of the screen looks more realistic? Do they report that an HDR YouTube video, which mostly consists of a screen recording with the recorded SDR FFF being mapped to the brightness of the sun, looks pretty? Do people like when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white? (see e.g https://floss.social/@mort/115147174361502259)
Because that's what HDR web content is.
HDR movies playing on a livingroom TV? Sure, nothing against that. I mean it's stupid that it tries to achieve some kind of absolute brightness, but in principle, some form of "brighter than SDR FFF" could make sense there. But for web content, surrounded by an SDR GUI?
> when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white
I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.
And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up. I am aware that HDR can be done wrong...
But for HDR videos where the HDR actually makes sense, yeah it's fine for highlights in the video to be a little brighter than the GUI around them, or for tiny little blips to be significantly brighter. Not enough to make it look gray like the misbehavior you linked.
> I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.
Other than the exaggerated 10x, I don't understand how it violates the rules you proposed. You proposed a scheme where part of the screen should be allowed to be significantly brighter than the surrounding SDR GUI's FFF. That makes the surrounding GUI look grey.
> And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up.
I'm bringing it up because that's how HDR looks on the web. Most web content isn't made by professional movie studios.
The example video I linked conforms with your suggested rules, FWIW: most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF. Yet it still hurts.
The whole chip in the middle is brighter than white. Half that video is super bright, making this example way more than I was suggesting in both area and average brightness.
> most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF.
It's a lot more than I suggested, and I said average brightness half of FFF for my example.
Also if I knew you were going to hammer on the loose example numbers I would have said 2% or 1%.
> I'm bringing it up because that's how HDR looks on the web.
But I'm not defending how it looks. I'm defending how it could look, since you don't see why anyone would even want HDR on the web.
This is going on for too long. Maybe you can somehow find a way to process all HDR content so that it's reasonable (i.e never makes the surrounding SDR GUI look grey, never makes bright pots which are bright enough to hurt) across all screens imaginable and all contexts. Maybe. I have my doubts, but go ahead.
Convince the web standards bodies and browser implementers and transform the world into one where HDR on the web is perfect and never causes issues.
But until that's done, there's a simple solution: Just don't support HDR. Until your hypothetical perfect solution is universally implemented, it does more harm than good on the web and should not be supported.
I don't see why anyone would want HDR on the web in its current form.
Well the reason I was talking about limits that way is because it's something screens already do when displaying HDR content. They can't go full power over much area, and the bigger you go the dimmer your limit gets. So repurposing those existing algorithms with some tweaking.
It's not very hard on a technical level.
And no it doesn't have to be universal and perfect to reach the point that HDR is a benefit. There are some blatant flaws that need fixing, and just a few fixes would get us a lot closer.
Again, go convince standards bodies and browser implementers to implement those algorithms after doing studies to demonstrate that it fixes the issue. Until then, I just don't want it in my browser.
it actually is somewhat an HDR problem because the HDR standards made some dumb choices. SDR standardizes relative brightness, but HDR uses absolute brightness even though that's an obviously dumb idea and in practice no one with a brain actually implements it.
In a modern image chain, capture is more often than not HDR.
These images are then graded for HDR or SDR. I.e., sacrifices are made on the image data such that it is suitable for a display standard.
If you have an HDR image, it's relatively easy to tone-map that into SDR space, see e.g. BT.2408 for an approach in Video.
The underlying problem here is that the Web isn't ready for HDR at all, and I'm almost 100% confident browsers don't do the right things yet. HDR displays have enormous variance. From "Slightly above SDR" to experimental displays at Dolby Labs. So to display an image correctly, you need to render it properly to the displays capabilities. Likewise if you want to display a HDR image on an SDR monitor. I.e., tone mapping is a required part of the solution.
A correctly graded HDR image taken of the real world will have like 95% of the pixel values falling within your typical SDR (Rec.709/sRGB) range. You only use the "physically hurt my eyes" values sparingly, and you will take the room conditions into consideration when designing the peak value. As an example: cinemas using DCI-P3 peaks at 48 nits because the cinema is completely dark. 48 nits is more than enough for a pure white in that environment. But take that image and put it on a display sitting inside during the day, and it's not nearly enough for a white. Add HDR peaks into this, and it's easy to see that in a cinema, you probably shouldn't peak at 1000 nits (which is about 4.x stops of light above the DCI-P3 peak). In short: your rendering to the displays capabilities require that you probe the light conditions in the room.
It's also why you shouldn't be able to manipulate brightness on an HDR display. We need that to be part of the image rendering chain such that the right decisions can be made.
You asked “which web browsers have a setting to tone map HDR images such that they look like SDR images?”; I answered. Were you not actually looking for a solution?
Wanted to note https://issues.chromium.org/issues/40141863 on making the lossless JPEG recompression a Content-Encoding, which provides a way that, say, a CDN could deploy it in a way that's fully transparent to end users (if the user clicks Save it would save a .jpg).
(And: this is great! I think JPEG XL has chance of being adopted with the recompression "bridge" and fast decoding options, and things like progressive decoding for its VarDCT mode are practical advantages too.)
The last discussion in libjxl about this was seemingly taking the stance it wasn't necessary since JXL has "native HDR" which completely fails to understand the problem space entirely.
Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.
> With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding.
This is simply not true. In fact, you get less banding than you do with 10-bit bt2020 PQ.
> JXL otoh is completely immune to banding
Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
> The JXL spec already has gainmaps...
Ah looks like they added that sometime last year but decided to call it "JHGM" and also made almost no mention of this in the issue tracker, and didn't bother updating the previous feature requests asking for this that are still open.
> Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
color banding is not a result of lossy compression*, it results from not having enough precision in the color channels to represent slow gradients. VarDCT, JPEG XL's lossy mode, encodes values as 32-bit floats. in fact, image bit depth in VarDCT is just a single value that tells the decoder what bit depth it should output to, not what bit depth the image is encoded as internally. optionally, the decoder can even blue-noise dither it for you if your image wants to be displayed in a higher bit depth than your display or software supports
this is more than enough precision to prevent any color banding (assuming of course the source data that was encoded into a JXL didn't have any banding either). if you still want more precision for whatever reason, the spec just defines that the values in XYB color channels are a real number between 0 and 1, and the header supports signaling an internal depth up to 64 bit per channel
* technically color banding could result from "lossy compression" if high bit depth values are quantized to lower bit depth values, however with sophisticated compression, higher bit depths often compress better because transitions are less harsh and as such need fewer high-frequency coefficients to be represented. even in lossless images, slow gradients can be compressed better if they're high bit depth, because frequent consistent changes in pixel values can be predicted better than sudden occasional changes (like suddenly transitioning from one color band to another)
Isn't this exactly the case that wuffs [1] is built for? I had the vague (and, looking into it now, probably incorrect) impression that Google was going to start building all their decoders with that.
AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot.
There's a lot of power in not having to convert for distribution.
Nice example for how a standard, like PDF, can even persuade/force one of the mighty to adopt a crucial bit of technology, so that this may become a common standard in its own right (i.e. "cascading standards").
> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images
Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format.
For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.
If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs.
JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that.
The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.
In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'.
You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.
Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable.
If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version.
JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.
Let's be realistic - when most users are upset they got a .webp, they're not annoyed because of quality-loss, they're annoyed because they can't immediately use it in many other services & software.
This is still a problem with AVIF, too. Image viewers that support the format often don't support animated AVIFs, and even GitHub still for some godforsaken reason treats .avif files in a repo/PR as binary files instead of images. I think Discord just recently started supporting AVIFs, so that's progress.
That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality.
i.e. you can also serve downscaled & thumbnail versions directly from the original image.
Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.
AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go.
Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels.
With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)
Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case.
Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun.
So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.
The names and extensions of JPEG XL files aren't specified, except that the IANA media type is `image/jxl`. I think an argument could be made to use the double extension convention when the encoder performs lossless JPEG recompression, so image.jpg becomes image.jpg.jxl (while not entirely semantically correct, since it's not an additional layer of compression around the JPEG, it's a reimplementation of the image using identical coding features as JPEG, in JXL).
But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.
Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
Webp was a nice new format now widely adopted in browsers, yet it's barely supported in websites (upload) and softwares. It's hard to see this being different.
WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images...
JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc.
WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
I didn't realize WebP was limited-RGB in addition to 4:2:0.
According to RFC 9649, this is accurate.
While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB:
> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
This comment is of course breaking the HN Guidelines as a shallow dismissal, but the parent is right: After Google killed Ublock Origin and turned Android into a nanny OS, I have no idea why anyone would stick to anything from them. Also Firefox is better in almost every way.
It's not really used interchangeably: "bug" is used to mean "entry in the bug tracker database", while "feature" is used to mean what we colloquially think of as a feature of a computer program.
It's arguably a slight abuse of a bug tracking system to also track progress and discussion on features, but it's not exactly uncommon; it's just that many systems would call it an "issue" rather than a "bug".
Google's internal issue tracker, Buganizer (which the Chromium Issue Tracker is based on), refers to everything as a "bug". It's confusing, yeah. You get used to it.
Not really -- they're all "potential todos" that need to be tracked and prioritized in the same place.
And the difference between a bug and a feature is often in the eye of the beholder. I'll very often title a GitHub issue with "Bug/Feature Request:" since it's often debatable whether the existing behavior was by design or not, and I don't want to presume one way or the other.
So I do consider them all pretty interchangeable at the end of the day, and therefore not really confusing.
JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.
Seems like a very small advantage to warrant all the necessary work needed to make it mainstream. Who would use it as advanced image format when a person that would be interested in such a thing would likely already be handling webp or avif?
"Yes, re-opening.".
> Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome.
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
Context: Mozilla has had the same stance and many devs (including Googlers) are already working on a Rust decoder which has made good progress.
LOL. Google, the "yeah that thing we bought six months ago, we're killing it off 30 days for 4 weeks ago" company demanding "long-term" anything.
That conversation doesn't apply to their core products: Search, Mail, Maps, Chrome, Android. Their commitment to maintaining these services over decades has been amazing. It's everything else that sucks.
Mail is dropping features left and right, like gmailify. I'm pretty sure they're trying to limit the maintenance costs as much as possible.
I could almost imagine the normal search going away to be replaced by a chatbot.
long term support is actually being provided by google...
just a different team in a different country :D
most jxl devs are at google research in zurich, and already pledged to handle long tetm support
Just like google pledges long term support for everything until the next new and shiny comes along.
I think Chrome can safely be said to have a track record of long term investment.
It is, after all, their primary ad delivery vector.
Very good track record there, native clients, floc, manifest v2, ...
Dupe. From yesterday (183 points, 82 comments):
https://news.ycombinator.com/item?id=46021179
Ah, I think I searched for "jpegxl", that's why there was no match.
JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).
It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either:
https://github.com/mozilla/standards-positions/pull/1064
avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
You also get it for basically free because it's just an av1 key frame. Every browser needs an av1 decoder already unless it's willing to forego users who would like to be able to watch Netflix and YouTube.
I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.
> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.
Their standards position is still neutral; what switched a year ago was that they said they would be open to shipping an implementation that met their requirements. The tracking bug hasn't been updated[2] The patches you mention are still part of the intent to prototype (behind a flag), similar to the earlier implementation that was removed in Chrome.
They're looking at the same signals as Chrome of a format that's actually getting use, has a memory safe implementation, and that will stick around for decades to justify adding it to the web platform, all of which seem more and more positive since 2022.
[1] https://mozilla.github.io/standards-positions/#jpegxl
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
I disagree about the image quality at typical sizes - I find JPEG-XL is generally similar or better than AVIF at any reasonable compression ratios for web images. See this for example: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
AVIF only comes out as superior at extreme compression ratios at much lower bit rates than are typically used for web images, and the images generally look like smothered messes at those extreme ratios.
Not everything in the world is passive end-of-the-line presentation. JPEG-XL is the only one that tries to be a general-purpose image format.
If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.
People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG.
Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
> Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
That’s a function of the website, not the browser.
> That’s a function of the website, not the browser.
That's hand-waving away quite a lot. The task changes from serving a copy of a file on disk, as every other image format in common use, to needing a transcoding pipeline more akin to sites like YouTube. Technically possible, but lots of extra complexity in return for what gain?
Even though AVIF decoding support is fairly widespread by now, it is still not ubiquitous like JPEG/PNG/GIF. So typically services will store or generate the same image in multiple formats including AVIF for bandwidth optimization and JPEG for universal client support. Browser headers help to determine compatibility, but it's still fairly complicated to implement, and users also end up having to deal with different platforms supporting different formats when they are served WebP or AVIF and want to reupload an image somewhere else that does not like those formats. As far as I can tell, JXL solves that issue for most websites since it is backwards-compatible and can be decoded into JPEG when a client does not support JXL. I would happily give up a few percent in compression efficiency to get back to a single all-purpose lossy image format.
Even Google photo does not support avif.
It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.
> Even Google photo does not support avif
I have no previous first-hand knowledge of this, but I vaguely remember discussions of avif in google photos from reddit a while back so FWIW I just tried uploading some avif photos and it handled them just fine.
Listed as avif in file info, downloads as the original file, though inspecting the network in the web frontend, it serves versions of it as jpg and webp, so there's obviously still transcoding going on.
I'm not sure when they added support, the consumer documentation seem to be more landing site than docs unless I'm completely missing the right page, but the API docs list avif support[1], and according to the way back machine, "AVIF" was added to that page some time between August and November 2023.
[1] https://developers.google.com/photos/library/guides/upload-m...
You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail. Defeating the whole purpose of putting them into Photo.
Given it's an app, they didn't even need Google chrome to add support. Avif is supported on Android natively.
> You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail.
I'm not sure what you mean. They appear to act like any other photo in the interface. You can view them and they're visible in the thumbnail view, but maybe I'm misinterpreting what you mean?
Or perhaps I don't see what you see.
I take a photo, the format is jpeg. It backs up to Google photo, the Google photo app on Android renders the photo just fine.
I then convert that photo (via a local converter) to AVIF, Google backs it up, I can see the file in Google Photo on Android but it doesn't render the image. That being full size or thumbnail, all I get is a grayed square. So I concluded the app doesn't support avif rasterizing.
I then gave up on the automation that converted all my jpeg into avif, which in turn would have saved hundred of gigabytes given I have 10y worth of photos.
The experiment was done about 3 months ago, as of 2025 Google Photo on Android, latest version, would not render my AVIF photos.
Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.
They could have added support themselves to the app as it doesn't use the WebView
Google Photos isn't just the app
See cousin comment, it accepts AVIF files. At least they would render on the app. Which would be enough for many. As it stands it accepts this format and renders nothing at all.
The killer feature of JXL is that most websites already have a whole bunch of images in JPEG format, and converting those to JXL shrinks them by about 30% without introducing any new artifacts.
> Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains
On a slightly related note, I wanted to have a HDR background image in Windows 11. Should be a breeze in 2025 right?
Well, Windows 11 only supports JPEG XR[1] for HDR background images. And my commonly used tools did either not support JPEG XR (Gimp fex) or they did not work correctly (ImageMagick).
So I had a look at the JPEG XR reference implementation, which was hosted on Codeplex but has been mirrored on GitHub[2]. And boy, I sure hope that isn't the code that lives in Windows 11...
Ok most of the gunk is in the encoder/decoder wrapper code, but still, for something that's supposedly still in active use by Microsoft... Though not even hosting their own copy of the reference implementation is telling enough I suppose.
[1]: https://en.wikipedia.org/wiki/JPEG_XR
[2]: https://github.com/4creators/jxrlib
Another JPEG XR user is Zeiss. It saves both grayscale and color microscope images with JPEG XR compression in a container format. Zeiss also released a C++ library (libczi) using the reference JPEG XR implementation to read/write these images. Somehow Zeiss is moving away from JPEG XR - its newer version of microscope control software saves with zstd compression by default.
"Marginal Gains"
Generation Loss – JPEG, WebP, JPEG XL, AVIF : https://www.youtube.com/watch?v=w7UDJUCMTng
Marginal gains over AVIF.
(Also I am highly skeptical of the importance of these generation loss tests.)
Very nice in video workflows, where it's common to write out image sequences to disk.
Social media exists
>avif is just better for typical web image quality,
What does "typical web image quality" even mean? I see lots of benchmarks with very low BPPs, like 0.5 or even lower, and that's where video-based image codecs shine.
However, I just visited CNN.com and these are the BPPs of the first 10 images my browser loaded: 1.40, 2.29, 1.88, 18.03 (PNG "CNN headlines" logo), 1.19, 2.01, 2.21, 2.32, 1.14, 2.45.
I believe people are underestimating the BPP values that are actually used on the web. I'm not saying that low-BPP images don't exist, but clearly it isn't hard to find examples of higher-quality images in the wild.
Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
> Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
Sure, 12-bit too, with HDR transfer functions (PQ and HLG), wide-gamut primaries (BT.2020, P3, etc.), and high-dynamic-range metadata (ITU/CTA mastering metadata, content light level metadata).
JPEG XL matches or exceeds these capabilities on paper, but not in practice. The reality is that the world is going to support the JPEG XL capabilities that Apple supports, and probably not much more.
if you actually read your parent comment: "typical web image quality"
Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!
PNG supports HDR with up to 16 bits per channel, see https://www.w3.org/TR/png-3/ and the cICP, mDCV and cLLI chunks.
With incredibly bad compression ratios.
HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level.
I want JXL in web browsers, but without HDR support.
There's nothing stopping browsers from tone mapping[1] those HDR images using your tone mapping preference.
[1]: https://en.wikipedia.org/wiki/Tone_mapping
What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect?
Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)
> What does that achieve?
Because then a user who wants to see the HDR image in all its full glory can do so. If the base image is not HDR, then there is nothing they can do about it.
> And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?
While I very much support more HDR in the online world, I fully agree with you here.
However, I suspect the reason will boil down to what it usually does: almost no users change the default settings ever. And so, any default which goes the other way will invariably lead to a ton of support cases of "why doesn't this work".
However, web browsers are dark-mode aware, they could be HDR aware and do what you prefer based on that.
What user wants the web to look like this? https://floss.social/@mort/115147174361502259
That video is clearly not encoded correctly. If it were the levels would match the background, given there is no actual HDR content visible in that video frame.
Anyway, even if the video was of a lovely nature scene in proper HDR, you might still find it jarring compared to the surrounding non-HDR desktop elements. I might too, depending on the specifics.
However, like I said, it's up to the browser to handle this.
One suggestion I saw mentioned by some browser devs was to make the default to tone map HDR if the page is not viewed in fullscreen mode, and switch to full HDR range if it is fullscreen.
Even if that doesn't become the default, it could be a behavior the browser could let the user select.
> That video is clearly not encoded correctly.
Actually I forgot about auto-HDR conversion of SDR videos which some operating systems do. So it might not be the video itself, but rather the OS and video driver ruining things in this case.
Ideally, browsers should just not support HDR.
Well I strongly disagree on that point.
Just because we're in the infancy of wide HDR adoption and thus experience some niggling issues while software folks work out the kinks isn't a good reason to just wholesale forego the feature in such a crucial piece of infrastructure.
Sure, if you don't want HDR in the browser I do think there should be a browser option to let you achieve that. I don't want to force it on everyone out there.
Keep in mind the screenshot you showed is how things looked on my Windows until I changed the auto-HDR option. It wasn't the browser that did it, it was completely innocent.
It was just so long ago I completely forgot I had changed that OS configuration.
If you want to avoid eye pain then you want caps on how much brightness can be in what percent of the image, not to throw the baby out with the bathwater and disable it entirely.
And if you're speaking from iphone experience, my understanding is the main problem there isn't extra bright things in the image, it's the renderer ignoring your brightness settings when HDR shows up, which is obviously stupid and not a problem with HDR in general.
If the brightness cap of the HDR image is full SDR brightness, what value remains in HDR? As far as I can see, it's all bath water, no baby
> If the brightness cap of the HDR image is full SDR brightness, what value remains in HDR?
If you set #ffffff to be a comfortable max, then that would be the brightness cap for HDR flares that fill the entire screen.
But filling the entire screen like that rarely happens. Smaller flares would have a higher cap.
For example, let's say an HDR scene has an average brightness that's 55% of #ffffff, but a tenth of the screen is up at 200% of #ffffff. That should give you a visually impressive boosted range without blinding you.
Oh.
I don't want the ability for 10% of the screen to be so bright it hurts my eyes. That's the exact thing I want to avoid. I don't understand why you think your suggestion would help. I want SDR FFFFFF to be the brightest any part of my screen goes to, because that's what I've configured to be at a comfortable value using my OS brightness controls.
I strongly doubt that the brightness to hurt your eyes is the same for 10% of the screen and 100% of the screen.
I am not suggesting eye hurting. The opposite really, I'm suggesting a curve that stays similarly comfortable at all sizes.
I don't want any one part of my screen to be a stupidly bright point light. It's not just the total amount of photons that matters.
It is not just the total amount.
But it's not the brightest spot either.
It's in between.
I just don't want your "in between" "only hurt my eyes a little" solution. I don't see how that's so hard to understand. I set my brightness so that SDR FFFFFF is a comfortable max brightness. I don't understand why web content should be allowed to go brighter than that.
I'm suggesting something that WON'T hurt your eyes. I don't see how that's so hard to understand.
You set a comfortable max brightness for the entire screen.
Comfortable max brightness for small parts of the screen is a different brightness. Comfortable. NO eye hurting.
It's still uncomfortable to have 10% of the screen get ridiculously bright.
Yes, it's uncomfortable to have it get "ridiculously" bright.
But there's a level that is comfortable that is higher than what you set for FFFFFF.
And the comfortable level for 1% of the screen is even higher.
HDR could take advantage of that to make more realistic scenes without making you uncomfortable. If it was coded right to respect your limits. Which is probably isn't right now. But it could be.
I severely doubt that I could ever be comfortable with 10% of my screen getting much brighter than the value I set as max brightness.
But say you're right. Now you've achieved images looking completely out of place. You've achieved making the surrounding GUI look grey instead of white. And the screen looks broken when it suddenly dims after switching tabs away from one with an HDR video. What's the point? Even ignoring the painful aspects (which is a big thing to ignore, since my laptop currently physically hurts me at night with no setting to make it not hurt me, which I don't appreciate), you're just making the experience of browsing the web worse. Why?
In general, people report that HDR content looks more realistic and pretty. That's the point, if it can be done without hurting you.
Do they? Do people report that an HDR image on a web page that takes up roughly 10% of the screen looks more realistic? Do they report that an HDR YouTube video, which mostly consists of a screen recording with the recorded SDR FFF being mapped to the brightness of the sun, looks pretty? Do people like when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white? (see e.g https://floss.social/@mort/115147174361502259)
Because that's what HDR web content is.
HDR movies playing on a livingroom TV? Sure, nothing against that. I mean it's stupid that it tries to achieve some kind of absolute brightness, but in principle, some form of "brighter than SDR FFF" could make sense there. But for web content, surrounded by an SDR GUI?
> when their light-mode GUI suddenly turns grey as a part of it becomes 10x the brightness of what used to be white
I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.
And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up. I am aware that HDR can be done wrong...
But for HDR videos where the HDR actually makes sense, yeah it's fine for highlights in the video to be a little brighter than the GUI around them, or for tiny little blips to be significantly brighter. Not enough to make it look gray like the misbehavior you linked.
> I don't know why you're asking me about examples that violate the rules I proposed. No I don't want that.
Other than the exaggerated 10x, I don't understand how it violates the rules you proposed. You proposed a scheme where part of the screen should be allowed to be significantly brighter than the surrounding SDR GUI's FFF. That makes the surrounding GUI look grey.
> And obviously boosting the brightness of a screen capture is bad. It would look bad in SDR too. I don't know why you're even bringing it up.
I'm bringing it up because that's how HDR looks on the web. Most web content isn't made by professional movie studios.
The example video I linked conforms with your suggested rules, FWIW: most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF. Yet it still hurts.
The whole chip in the middle is brighter than white. Half that video is super bright, making this example way more than I was suggesting in both area and average brightness.
> most of the image is near black, only a relatively smart part of it is white. The average brightness probably isn't over SDR FFF.
It's a lot more than I suggested, and I said average brightness half of FFF for my example.
Also if I knew you were going to hammer on the loose example numbers I would have said 2% or 1%.
> I'm bringing it up because that's how HDR looks on the web.
But I'm not defending how it looks. I'm defending how it could look, since you don't see why anyone would even want HDR on the web.
This is going on for too long. Maybe you can somehow find a way to process all HDR content so that it's reasonable (i.e never makes the surrounding SDR GUI look grey, never makes bright pots which are bright enough to hurt) across all screens imaginable and all contexts. Maybe. I have my doubts, but go ahead.
Convince the web standards bodies and browser implementers and transform the world into one where HDR on the web is perfect and never causes issues.
But until that's done, there's a simple solution: Just don't support HDR. Until your hypothetical perfect solution is universally implemented, it does more harm than good on the web and should not be supported.
I don't see why anyone would want HDR on the web in its current form.
Well the reason I was talking about limits that way is because it's something screens already do when displaying HDR content. They can't go full power over much area, and the bigger you go the dimmer your limit gets. So repurposing those existing algorithms with some tweaking.
It's not very hard on a technical level.
And no it doesn't have to be universal and perfect to reach the point that HDR is a benefit. There are some blatant flaws that need fixing, and just a few fixes would get us a lot closer.
It has to be universally not harmful.
Again, go convince standards bodies and browser implementers to implement those algorithms after doing studies to demonstrate that it fixes the issue. Until then, I just don't want it in my browser.
it actually is somewhat an HDR problem because the HDR standards made some dumb choices. SDR standardizes relative brightness, but HDR uses absolute brightness even though that's an obviously dumb idea and in practice no one with a brain actually implements it.
In a modern image chain, capture is more often than not HDR.
These images are then graded for HDR or SDR. I.e., sacrifices are made on the image data such that it is suitable for a display standard.
If you have an HDR image, it's relatively easy to tone-map that into SDR space, see e.g. BT.2408 for an approach in Video.
The underlying problem here is that the Web isn't ready for HDR at all, and I'm almost 100% confident browsers don't do the right things yet. HDR displays have enormous variance. From "Slightly above SDR" to experimental displays at Dolby Labs. So to display an image correctly, you need to render it properly to the displays capabilities. Likewise if you want to display a HDR image on an SDR monitor. I.e., tone mapping is a required part of the solution.
A correctly graded HDR image taken of the real world will have like 95% of the pixel values falling within your typical SDR (Rec.709/sRGB) range. You only use the "physically hurt my eyes" values sparingly, and you will take the room conditions into consideration when designing the peak value. As an example: cinemas using DCI-P3 peaks at 48 nits because the cinema is completely dark. 48 nits is more than enough for a pure white in that environment. But take that image and put it on a display sitting inside during the day, and it's not nearly enough for a white. Add HDR peaks into this, and it's easy to see that in a cinema, you probably shouldn't peak at 1000 nits (which is about 4.x stops of light above the DCI-P3 peak). In short: your rendering to the displays capabilities require that you probe the light conditions in the room.
It's also why you shouldn't be able to manipulate brightness on an HDR display. We need that to be part of the image rendering chain such that the right decisions can be made.
How about a user stylesheet that uses https://www.w3.org/TR/css-color-hdr-1/#the-dynamic-range-lim... ?
How about websites just straight up aren't allowed to physically hurt me, by default?
Web sites aren’t made for just you. If images from your screen are causing you issues, that is a you / your device problem, not a web site problem.
I agree, it's not a web site problem. It's a web standards problem that it's possible for web sites to do that.
Note the spec does recommend providing a user option: https://drafts.csswg.org/css-color-hdr-1/#a11y
You asked “which web browsers have a setting to tone map HDR images such that they look like SDR images?”; I answered. Were you not actually looking for a solution?
I was looking for a setting, not a hack.
Wanted to note https://issues.chromium.org/issues/40141863 on making the lossless JPEG recompression a Content-Encoding, which provides a way that, say, a CDN could deploy it in a way that's fully transparent to end users (if the user clicks Save it would save a .jpg).
(And: this is great! I think JPEG XL has chance of being adopted with the recompression "bridge" and fast decoding options, and things like progressive decoding for its VarDCT mode are practical advantages too.)
> (in Rust?)
Looks like that's the idea: https://issues.chromium.org/issues/462919304
> and generally its HDR support is much better than AVIF
Not anymore. JPEG had the best HDR support with ISO 21496-1 weirdly enough, but AVIF also just recently got that capability with 1.2 ( https://aomedia.org/blog%20posts/Libavif-Improves-Support-fo... ).
The last discussion in libjxl about this was seemingly taking the stance it wasn't necessary since JXL has "native HDR" which completely fails to understand the problem space entirely.
The JXL spec already has gainmaps...
Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.
> With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding.
This is simply not true. In fact, you get less banding than you do with 10-bit bt2020 PQ.
> JXL otoh is completely immune to banding
Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
> The JXL spec already has gainmaps...
Ah looks like they added that sometime last year but decided to call it "JHGM" and also made almost no mention of this in the issue tracker, and didn't bother updating the previous feature requests asking for this that are still open.
> Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
color banding is not a result of lossy compression*, it results from not having enough precision in the color channels to represent slow gradients. VarDCT, JPEG XL's lossy mode, encodes values as 32-bit floats. in fact, image bit depth in VarDCT is just a single value that tells the decoder what bit depth it should output to, not what bit depth the image is encoded as internally. optionally, the decoder can even blue-noise dither it for you if your image wants to be displayed in a higher bit depth than your display or software supports
this is more than enough precision to prevent any color banding (assuming of course the source data that was encoded into a JXL didn't have any banding either). if you still want more precision for whatever reason, the spec just defines that the values in XYB color channels are a real number between 0 and 1, and the header supports signaling an internal depth up to 64 bit per channel
* technically color banding could result from "lossy compression" if high bit depth values are quantized to lower bit depth values, however with sophisticated compression, higher bit depths often compress better because transitions are less harsh and as such need fewer high-frequency coefficients to be represented. even in lossless images, slow gradients can be compressed better if they're high bit depth, because frequent consistent changes in pixel values can be predicted better than sudden occasional changes (like suddenly transitioning from one color band to another)
> performant and memory safe decoder (in Rust?).
Isn't this exactly the case that wuffs [1] is built for? I had the vague (and, looking into it now, probably incorrect) impression that Google was going to start building all their decoders with that.
[1] https://github.com/google/wuffs
WUFFS only works for very simple codecs. Basically useless for anything complex enough that memory bugs would be common.
Love this, been waiting for Google to integrate this, from my experience with AVIF and JPEGXL, JPEGXL is much more promising for the next 20years.
This is welcome.
AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot.
There's a lot of power in not having to convert for distribution.
Nice example for how a standard, like PDF, can even persuade/force one of the mighty to adopt a crucial bit of technology, so that this may become a common standard in its own right (i.e. "cascading standards").
> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images
Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format.
For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.
If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs.
JPEG XL is the first image format in a long while that's been actually designed for images and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that.
The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.
Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression.
Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.
In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'.
You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.
FLIF got integrated in to JPEG-XL as the modular mode.
If I recall correctly, that's FUIF, originally created by the same author as FLIF's successor of sorts.
Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.
You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.
Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable.
[1] https://pngquant.org/
I think there's a difference here.
If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version.
JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.
Let's be realistic - when most users are upset they got a .webp, they're not annoyed because of quality-loss, they're annoyed because they can't immediately use it in many other services & software.
This is still a problem with AVIF, too. Image viewers that support the format often don't support animated AVIFs, and even GitHub still for some godforsaken reason treats .avif files in a repo/PR as binary files instead of images. I think Discord just recently started supporting AVIFs, so that's progress.
20% is massive for those storing those social media images though.
I get that there are people who are super excited by this for very good reasons, but for those of us downstream this is just going to be a hassle.
> For example, ask a normal social media user how they feel about .webp and expect to get an earful.
I've seen enough software that gets petulant about not supporting webp to fight the Google monopoly or whatever to understand their frustration.
That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality.
i.e. you can also serve downscaled & thumbnail versions directly from the original image.
Since the recompression is lossless, you don’t need every tool you use to support it, as long as one of them is one that can do the decompression back to JPEG. This sounds a bit like complaining that you can’t upload .7z everywhere.
AFAIK downconverting to jpeg is only an option for legacy jpegs that have been upconverted to jpegxl though. Many jpegxl images likely won't support downconverting if they were created as jxl from the get-go.
Basically, jpeg->jxl->jpeg is perfectly lossless conversion, but a newly-made jxl->jpeg is not, even if it doesn't use modern jxl-only features like alpha channels.
With that in mind I'd actually prefer if those were treated as separate file-formats with distinct file-extensions (backwards-compatible jpeg->jxls vs pure-jxl). The former could be trivially handled with automated tools, but the latter can't.
I'm not sure if that will be an issue in practice. in any case, you need a JPEG XL decoder to perform the transition from a recompressed-JPEG-JXL to the original JPEG, so whatever tool is doing this, it can already handle native-JXL too. it could be the conversion happens on the server side and the client always sees JPEG, in which case a native JXL can also be decoded to a JPEG (or if lossless a PNG), though obviously with information loss since JPEG is a subset of JXL (to put it lightly)
Well, sure, but wasn’t that the use case we were discussing?
Right. And that particular use-case sounds nice, but realistically this new format will not be exclusively used in that particular case.
Dealing with basically another .webp-like format in those cases (one that might be a backwards-compatible jpeg or might not and determining that can only be done by inspecting the file contents) doesn't sound super fun.
So ideally, to make up names, I wish they'd used separate extensions and so a ".jp3" is a file that can be downconverted to a jpg and you could get a browser extension to automate that for you if you wanted, and a ".jxl" is the new file format that's functionally another ".webp"-like thing to deal with and all the pain-points that implies.
The names and extensions of JPEG XL files aren't specified, except that the IANA media type is `image/jxl`. I think an argument could be made to use the double extension convention when the encoder performs lossless JPEG recompression, so image.jpg becomes image.jpg.jxl (while not entirely semantically correct, since it's not an additional layer of compression around the JPEG, it's a reimplementation of the image using identical coding features as JPEG, in JXL).
But like I said in my other comment (which got hidden for some reason), it should be noted that a recompressed JPEG is also a valid JXL on its own. If you have the means to turn a recompressed JPEG into the original, you also have the means to view native JXLs.
Hopefully adoption is widespread and we won't really have to worry about it. JPEG XL is a much more appealing format than WebP, and unlike WebP there are great arguments for software to support it other than "Google started using them, so they're everywhere now."
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
Webp was a nice new format now widely adopted in browsers, yet it's barely supported in websites (upload) and softwares. It's hard to see this being different.
WebP is much more limiting than JPEG XL. in lossy mode WebP has forced 4:2:0 chroma subsampling, supports only 8 bit per channel colors (really only about 7.8 bits, because thanks to WebP being tv-range the values aren't in a 0-255 range but in a 16-235 range, causing even more color banding than 8 bit per channel already has), no HDR, a maximum resolution of 16385 x 16385 making it unsuitable for larger images...
JPEG XL on the other hand supports up to 4099 color channels, a bit depth up to 32 bit per channel (technically up to 64 bit, but this currently isn't used), supports HDR natively, can use splines to compress elements like strands of hair, thin tree branches or line art that are typically hard to compress with DCT, supports patches for compressing repeating image elements, supports thermal, depth and alpha channels, supports losslessly recompressing existing JPEGs saving about 20%, supports CMYK and spot colors for printing, supports layers and selection masks, supports storing raw camera sensor data in bayer patterns, etc.
WebP is just a web delivery format, JPEG XL was designed to support many uses cases like web delivery, medical imaging, raw camera sensor data, authoring, multi-spectral imaging... the list goes on. if we support JPEG XL now, chances are it'll be quite a while before we need a new general purpose image format because JPEG XL covers so many current use cases and was designed to accommodate potential future use cases as well.
I didn't realize WebP was limited-RGB in addition to 4:2:0. According to RFC 9649, this is accurate. While the ITU-R Recommendation 601 on color is only a "SHOULD" in the RFC, you'd need a custom decoder to break out of limited RGB:
> The VP8 specification describes how to decode the image into Y'CbCr format. To convert to RGB, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders.
[dupe] https://news.ycombinator.com/item?id=46021179
[dead]
[flagged]
This comment is of course breaking the HN Guidelines as a shallow dismissal, but the parent is right: After Google killed Ublock Origin and turned Android into a nanny OS, I have no idea why anyone would stick to anything from them. Also Firefox is better in almost every way.
> Chrome Jpegxl Issue Reopened
> (this is the tracking bug for this feature)
Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?
It's not really used interchangeably: "bug" is used to mean "entry in the bug tracker database", while "feature" is used to mean what we colloquially think of as a feature of a computer program.
It's arguably a slight abuse of a bug tracking system to also track progress and discussion on features, but it's not exactly uncommon; it's just that many systems would call it an "issue" rather than a "bug".
Maybe more like a heading bug:
https://aviation.stackexchange.com/questions/23166/what-is-t...
Google's internal issue tracker, Buganizer (which the Chromium Issue Tracker is based on), refers to everything as a "bug". It's confusing, yeah. You get used to it.
Not really -- they're all "potential todos" that need to be tracked and prioritized in the same place.
And the difference between a bug and a feature is often in the eye of the beholder. I'll very often title a GitHub issue with "Bug/Feature Request:" since it's often debatable whether the existing behavior was by design or not, and I don't want to presume one way or the other.
So I do consider them all pretty interchangeable at the end of the day, and therefore not really confusing.
jpg -> png -> webp -> avif
Why are we going backward?
JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.
Seems like a very small advantage to warrant all the necessary work needed to make it mainstream. Who would use it as advanced image format when a person that would be interested in such a thing would likely already be handling webp or avif?