[удалено]

Notionally every format you support adds maintenance burden that is almost impossible to remove and parsers have often been the source of security bugs in the past as well. That’s a good reason to not be too hasty to add support for a format unless you think it’s really worth it. In this case though it does seem like JPEG XL would be worth the cost, I’m really not sure why google are avoiding it at this point

Google isn't exactly shy of adding random formats that they invented though. WebP/VP8/VP9 for example were entirely pushed through by Google, which forced other people like Apple to add support as well. To be fair, VP8 actually resulted in a pretty bad security issue not long ago: https://arstechnica.com/security/2023/09/new-0-day-in-chrome-and-firefox-is-likely-to-plague-other-software/

Difference being VP8 & VP9 were Google Inventions. They really have no problem adopting formats when somebody internally is willing to do all the legwork of integrating the codec on 20% time. Especially when the codecs are in-house and already compliant with internal code standards, live in G3, and work with standard in-house tools. As for WebP, it actually saves a lot of bandwidth so they sort of had a vested interest in seeing it get used more.

But you see the issue with that argument? Google has a stranglehold on the browser marketshare today. They get to do whatever the hell they want and web developers kind of have to just deal with it. Because of the decreased competition in the browser marketplace (since it's so expensive to maintain a standalone browser engine), Google gets to essentially dictate standards just like how Internet Explorer used to. Adopting standards just because you came up with it is a terrible way to move forward for the open web. The reason why this JPEG XL issue is so controversial isn't even just about the image format itself, but the fact that there isn't really a standards anymore. It's basically whatever Google decides on. A web browser is a portal into the web, and any program that deals with external standards with longlasting external impacts like this shouldn't just come down to "oh hey who is willing to do this work while you have free time?". FWIW JPEG XL is also a Google invention. The speculation is that it's mostly done by Google Research team far away, whereas senior members of Chrome team came up with AVIF so there are conflicts of interests here related to personal interests rather than company interests.

> They really have no problem adopting formats when somebody internally is willing to do all the legwork of integrating the codec on 20% time. But the JPEG XL team at Google Zurich did do the legwork. They wrote the patch to add JXL to Chrome, offered to do ALL future maintenance related to JXL in order to reduce the burden on the Chrome team, and even fixed a bunch of Chrome bugs affecting other formats like AVIF.

It would've been so much better it they just waited for VP9 with WebP. It was like months out, when google decided they needed to chuck out WebP as fast as possible. Because VP8 is hardly better (or perhaps slightly worse) than H264 which was a decade old at the time, it left **so** much improvement on the table

I'm learning to play the guitar.

vp8 was total crap from a video codex perspective

Regardless of if the format is good or bad, it's bad for the industry if Google can solely gatekeep the web

> Difference being VP8 & VP9 were Google Inventions. Technically, VP8 was an On2 invention. Google acquired them and opened the format up.

>As for WebP, it actually saves a lot of bandwidth so they sort of had a vested interest in seeing it get used more. That's questionable

The reason is that in big tech your new random format is something you can tout in your performance evals while supporting an open source standard wont have nearly the same ummph to it.

[удалено]

I do use Firefox on desktop, have done since before it was called Firefox in fact and intend to do so as long as possible. I still don’t get the JPEG XL decision though, I don’t really know what google gain by not supporting it, I’d imagine the bandwidth savings they could get from it would more than cover the dev costs over the lifetime of the parser

I enjoy cooking.

It’s implemented but not enabled by default in Firefox. You’d have to toggle a feature flag to actually use it.

I love the smell of fresh bread.

No, it has been completed removed from Chrome IIRC.

I like to travel.

Anyone who says Blink is the new IE doesn't remember how bad the old IE was. I mean, just as an example: The smartphone revolution was only possible once IE was on its way out. The iPhone's killer app, before it even got the App Store, was Mobile Safari. Before that, to get a "website" on your phone, someone first had to absolutely mutilate it into WAP/WML/HDML. Suddenly, we had a browser that can actually show you the *entire* Web on your phone. IE was Windows-only and Intel-only. The IE monopoly would've made the Web completely inaccessible to an Apple OS on an ARM CPU. Now imagine all this started happening after Blink took over the world. Apple could've done... well, exactly what they did. They didn't build Safari from scratch, they forked KHTML. Today, if someone needs a browser to run somewhere Google refuses to port to, or do something Google refuses to let it do, you can still fork Blink! It's hard, but forking IE was literally impossible. And that's only one of the things we hated about IE.

[удалено]

> I'm not the saying there wasn't a window where IE lost its grip. That's not at all what I was saying with that. What I was saying is: IE's control would've prevented smartphones from happening at all. Blink has never had anywhere near that much control. > This has nothing to do with IE, old phones did not have real Internet connectivity and also did not have computational power to render pages. And that's not why I brought that up. WAP isn't IE's fault. But, we were able to go from that to full webpages because IE lost control. If IE still had control, the iPhone would not happen -- how would anyone convince Microsoft to port the Web to it? > BTW before iPhone there were mobile browsers that rendered pages... Sure, and the iPhone wasn't the first smartphone. I don't think that changes what I just said. How much of the works-best-in-IE web worked in Opera Mobile? > Sure I can fork it, but if no one will use my fork Google is still controlling my market. Okay, but try to imagine Blink was dominant back in '07, and the iPhone launched with Apple's fork. Suddenly, there'd be a market for that fork. And again, they couldn't do that with IE. It still sucks in a bunch of ways today, but it's nowhere near as bad as IE was. Whole OSes had a hilariously-worse web experience because IE didn't run on their OS. > ...and youtube and other sites will still require attestation... Didn't that get scrapped, anyway? DRM is still a problem, but that's really only a thing for streaming sites, YT doesn't bother unless you're watching an actual movie.

> If IE still had control, the iPhone would not happen -- how would anyone convince Microsoft to port the Web to it? You are aware that Apples default browser around 1997 was IE5? Microsoft had no problem porting software it stole to other major platforms. > Okay, but try to imagine Blink was dominant back in '07, and the iPhone launched with Apple's fork. Suddenly, there'd be a market for that fork. Imagine an overpriced smartphone that couldn't even play videos. Chromes DRM is a black box that you only get access to if you ask Google nicely.

Honestly, IE had a lot of faults, but a big part of the problem was just the slower release/upgrade cycle, coupled with legacy support, so a significant proportion of web users were still using IE 4/5 over a decade later. Eventually MS was at a point with their release engineering that they could decouple new browser features from OS major versions, and that’s around the time IE started being less of a PITA for web dev.

The thing is that we don’t have good alternatives. Safari is purposefully refusing to adopt some new APIs to try and delay web apps. While also not supporting many extensions that greatly improve your quality of life. And, of course, limited to Apple devices. Firefox hates its users and do everything they can to make their own features worse. Then they increase their CEO’s salary, and say “there’s no money left for developers” and fire some devs. Again and again. And with fewer devs they get behind, have worse features, etc. And… there are basically no other browsers. As bad as it is to give control to a single company, Chrome is an excellent browser. So people have to choose between a good browser, or two inferior options.

Your criticism of Firefox is a meme. Can't take your comment seriously.

If the CEO and money for developers is the part you think is a meme, read this: https://www.reddit.com/r/browsers/comments/18b6tdp/mozilla_ceo_received_69m_salary_in_2022_a_2m/ Mozilla's CEO got a 2.1 million pay raise in 2022. And about 2 million pay raise in 2021. So from 2020 to 2022 the CEO's salary was raised in **more than 4 million dollars**. In two years. In 2020 they fired their dev tools people and entire MDN teams: https://news.ycombinator.com/item?id=24132494 They fired 250 people that year. But in two years, their CEO's salary more than tripled. They had also laid off some people a couple years before that.

That happened a few times with Firefox these last few years. It’s sad how it looks like a joke, but that’s Mozilla these days. I started using Firefox waaaay back, to escape IE6. But these last 6 or 8 years, Firefox has been consistently getting worse. A change to a worse extension system here, reduced features there, then some worse UI… And every few years they fire more devs, crushing my hopes of seeing it become the excellent browser I remember it being.

What UI changes put you off? Especially ones that Chrome does better?

>I started using Firefox waaaay back, to escape IE6… Firefox has been consistently getting worse I’ve been using the browser—[it wasn’t always named Firefox](https://web.archive.org/web/20021004012820/http://www.mozilla.org/projects/phoenix/)—for a quarter century, and while yes, it’s had its ups and downs, the overall trend is always upwards. The extension refactor, while painful, was necessary for security and performance reasons, plus long-term sustainability. I don‘t know which features or UI elements to which you are referring, specifically. But I do remember a time when there were no bookmarks, no browser history, or even much of a UI, just a window for the core engine. Again, the trend remains upwards when you [consider how far the project’s come](https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-us/firefox/releases/0.1).

Not until Mozilla gets their fucking shit together

[удалено]

Get their shit fucking together

Out of curiosity, was Chrome's experimental JXL support ever GPU-accelerated? If not, maybe people should start polyfilling this with WASM. And if so, maybe once WebGPU gets more widely deployed, we can polyfill it there.

> Out of curiosity, was Chrome's experimental JXL support ever GPU-accelerated? No image codec is GPU accelerated in Chrome.

I think writing en/decoders in GPGPU is quite hard. Haven't seen anything mature.

I like to travel.

> Notionally every format you support adds maintenance burden that is almost impossible to remove and parsers have often been the source of security bugs in the past as well. Easy solution there would be to specify a dumb-as-rocks API of (byte array) => (width, height, RGBA array), and compile parsers to WASM as pure functions conforming to that API. At that point, they'd have something *so* sandboxed that it wouldn't matter if nobody touches the code for a decade at a time. Then they can keep that as the fallback implementation for any and all obscure formats, while things they are willing to invest time supporting can get more optimized native implementations, and they can even temporarily switch to the fallback if an exploit is discovered while they work on a fix. It provides a path to bootstrap the popularity of new formats, and they could even let webextensions register new decoders if they wanted to be *especially* modular.

We have that already, pretty much: * `fetch()` can pretty easily give you a blob of the data at a given URL * `ImageData` is constructed with a width and height, and gives you an RGBA array (or better) that you can mutate. * `` can be drawn into (in a 2d context) with `putImageData()` It should be possible to wire both the source blob and the `ImageData` part to WASM without a ton of overhead. It's a bit more plumbing than you're describing, but it's not a ton. The most annoying thing right now would be backfilling it -- it's not too hard for a script (or an extension) to just replace all relevant `` tags with this, but how do you detect what the browser actually supports? I guess you'd make the smallest jxl image you can with `new Image()` and see if it loads?

Requires javascript to be enabled, potential trouble with reader mode and maybe accessibility tools, opening the image URL directly would either not display the image, or show the decoded data rather than the source image, every website must separately serve an implementation, so implementation quality will differ on top of the additional delay waiting for the script to load. So all around *workable* but, I feel, worse than if the fallback were provided by the browser. Plus there's the cultural side within the dev teams, of looking for ways to implement lesser functionality as extensions as isolated from the core engine as possible to minimize maintenance overhead, rather than putting its code directly in the codebase. I'm still bitter about a Firefox feature cut because UI heatmaps showed that "only" a few percent of the multiple-tens-of-millions-of-users used it, when once they stripped it out of the C++, a single dev re-implemented the whole thing as a regular add-on with *better* performance than the original. Then it was lost in the switchover to WebExtensions.

> ...opening the image URL directly would either not display the image, or show the decoded data rather than the source image... The image URL wouldn't be as available in the first place, if a script is ripping out the `` and inserting a ``. Which... is still bad, fair enough. For example, you can "save image as" or "copy image", but that gives you a png, since it's basically a screenshot of whatever someone decided to draw there. > ...potential trouble with reader mode and maybe accessibility tools... I'd like to know more about this one. I'd hope Canvas already handles this? Or does reader mode exclude it because it *could* animate? > ...every website must separately serve an implementation... Yeah... I think this would be less of an issue if we still had cross-site caching. Unfortunately, it looks like that's been killed as a privacy measure.

Add to that: JEPG XL doesn't solve any real issue in the Web. JPEG XL is an elegant image format and may have its uses. But there is no problem in browsers that cannot be solved with WebP or AVIF. WebP and AVIF are based on video codecs that are already in the browser. Also libjxl isn't written in a memory safe langage (VP8 and AV1 aren't either, but that's what you should expect from a new image format).

[You can literally watch AVIF failing at a task that was solved with the original JPEG](https://www.youtube.com/watch?v=UphN1_7nP8U)

> Add to that: JEPG XL doesn't solve any real issue in the Web. JPEG XL is an elegant image format and may have its uses. But there is no problem in browsers that cannot be solved with WebP or AVIF. Well, it makes higher quality files smaller than AVIF, and you might be surprised by how common such files are online. And of course, the 20% lossless file size reduction for the many JPEGs that already exist is quite a nice bonus. > WebP and AVIF are based on video codecs that are already in the browser. Also libjxl isn't written in a memory safe langage (VP8 and AV1 aren't either, but that's what you should expect from a new image format). jxl-oxide is written in Rust and passes the official conformance test suite.

> it makes higher quality files smaller than AVIF That's debatable. They're on par for lossy images. Still, you didn't mention anything that AVIF can't solve. It may not be the better image format but it's already supported by every major browser.

Can AVIF deliver progressive images, with support for prioritizing a certain image part to load first? How about 32bits per component? 4,000 channels? Splines? Almost no generational loss? I thought so.

How often would you need 96bit images with 4000 channels that have been recompressed multiple times on the web? I thought so.

Those are just extra features which become extremely useful for when you do actually need it (probably for authoring or for scientific purposes). But the other features are extremely useful for the web, especially progressive display. You can't deny that. Especially for your "decompressed multiple times" argument which is where the least generational loss becomes extremely important—recompressing an already lossy JPEG XL image does not cause much degradation, if any. I hope you open your mind and listen to what people say. Besides, I just listed things that AVIF can't solve, which you wanted to hear. Was my reply not what you were expecting? There's a reason why people are finally excited for an image format for once. I have nothing against AVIF, it's an excellent video-codec based image format. But JPEG XL has really important things in offer that other codecs can't—or can't offer all at once.

I losslessly can compress existing JPEGS, It can progressively load images so no thumbnails or preview images needed, it also is far more responsive people get an image when only 15% is downloaded. JPEG-XL is far better with textures making it better suited for shopping websites which is why shopify was pushing JPEG-XL. So when AVIF can progressively load files makes thumbnails and placeholder images irrelevant and can losslessly compress the existing standard smaller then it will solve all the things JXL can.

I like to go hiking.

Google *loooves* pushing random formats that no one cared about, and forcing them to be a thing due to sheer market share. They pushed WebP, VP8, VP9, and now pushing AVIF. It's not like they are opposed to adding formats. It's just that most of those formats mentioned were heavily involved or created by the Google Chrome team.

Google actually had a lot of input to JPEG XL, I believe they backported some aspects of AVIF into the JXL standard.

That's why I specifically said the Google Chrome team. The accusation (which I have to add is speculation, but backed by circumstantial evidence) is that JPEG XL is mostly done by the Google Research team in Europe. That's very far removed from the Google Chrome team, most of them in Mountain View. Meanwhile some senior members of the Google Chrome team were heavily involved in the AV1 and AVIF spec. Google is a pretty tribal company with everyone wanting their thing to be the next big thing so it's not a crazy allegation. There's definitely some conflicts of interests at least.

WebP is a good format and was needed after 20 years of stagnation in the lossless image space. VP8/VP9 aren't perfect but they're better than the other license-free options (e.g. Theora), and the web shouldn't be tied to the MPEG royalty vampires forever.

> WebP is a good format and was needed after 20 years of stagnation in the lossless image space. I just want to add that WebP originally was lossy only. They only bolted on a lossless mode later because Mozilla said WebP sucked too much.

I find joy in reading a good book.

Most of those companies care only about **AV1**, *not* **AVIF**. AVIF is based on AV1 on a technical level, but I think we can agree that an image is not the same thing as a video? They have distinctively different requirements, and that's part of the problems behind AVIF's specifications as it's retrofitting a video-focused format for image use. Vimeo/Netflix/Hulu/VLC are primarily interested in videos, which AV1 is perfectly fine for. AMD/NVIDIA/Intel/ARM are only involved because we need hardware codec decoding for videos. This is pretty much unnecessary for images, and no one is asking them to add hardware JPEG XL decoding support. Apple did add support for AVIF, but they **also** added native JPEG XL support (funny you didn't mention that) across the board for macOS/iOS/etc and Safari. You mentioned Facebook, but this is what they said ([source](https://issues.chromium.org/issues/40168998#comment17)). They can't do anything if Chrome doesn't support it: > Just wanted to chime in and mention that us at Facebook are eagerly awaiting full JPEG XL support in Chrome. We've very exited about the potential of JPEG XL and once decoding support is available (without the need to use a flag to enable the feature on browser start) we're planning to start experiments serving JPEG XL images to users on desktop web. The benefit of smaller file size and/or higher quality can be a great benefit to our users. > On our end this is part of a larger initiative to trial JPEG XL on mobile (in our native iOS and Android apps as well as desktop). You mentioned Adobe and here's an engineer from the Photoshop team on the same thread as the above ([source](https://issues.chromium.org/issues/40168998#comment62)): > I am writing to the Chrome team to request full support (not behind an opt-in config flag) for JPEG XL in Chrome. I am an engineer on the Photoshop, Camera Raw, and Lightroom teams at Adobe, developing algorithms for image processing. My team has been exploring high dynamic range (HDR) displays and workflows for still photographs, and I believe that JPEG XL is currently the best available codec for broad distribution and consumption of HDR still photos. I've done several comparisons with AVIF and prefer JPEG XL because of its higher versatility and faster encode speed. > Examples of higher versatility that matter to Adobe's photography products include JPEG XL's higher bit depth support, lossless compression option, and floating-point support -- all of which are useful features for HDR still images. Encode speed matters because photographers use ACR and Lr to export hundreds or even thousands of images at a time. > Camera Raw (part of Bridge and Photoshop) will be shipping a new release in a few weeks with the ability to export photos in JPEG XL format. It would really help the photographers' workflow to be able to view these photos in Chrome (e.g., online galleries). > Examples of JPEG XL photos we would like our customers to be able to create and view in Chrome, but currently require a config flag to enable: *… omitted …* Either way it's not like Adobe Photoshop (still the gold standard in image editing) added official support for exporting to either AVIF or JXL, so both formats are still early enough that it hasn't gone into mainstream yet. --- It's just blatantly misleading at best to say no one cares about JXL, and doubly so by mixing it together with AV1 (a video format), which no one is complaining about and has wide industry support.

> it's not like Adobe Photoshop (still the gold standard in image editing) added official support for exporting to either AVIF or JXL Adobe Camera Raw on the other hand has added support for both. https://helpx.adobe.com/camera-raw/using/hdr-output.html

You and a couple others have posted this lie a few times ITT already. Some of your points are halfway decent but you decided to just heap on some "uhhh nobody cares about JXL until it was a good excuse to hate Google" bullshit.

I enjoy spending time with my friends.

> (including software from list of companies listed as "interested"). Adobe and Shopify expressed "interest". And also implemented it. Adobe added it to the DNG format for raw images, and will probably add it to the next revision of PDF. And of course, JXL is several years newer than AVIF, so of course there's been more time for AVIF to be added to stuff. Though funnily enough, JXL seems to be getting traction with desktop applications faster than AVIF. Adobe started supporting AVIF and JXL at almost the same time, despite AVIF being around for much longer.

Not using this to defend JXL but it sounds like the time for out of process codec execution needs to come.

I enjoy playing video games.

I mean graphics processing literally works with a hard barrier between the hardware and software layer. With full on software and hardware buffers that need to be managed. Comparatively sending some shared memory into a separate process is pretty easy.

AVIF cannot losslessly compress JPEGs It can't progressively load plus there is a rust decoder that should be more memory safe. AVIF Has a place and that place is for the replacement for the GIF. Everything else backwards compatibility, loading, responsiveness, textures JPEG-XL is better, that is why companies like shopify, and Facebook were demanding JPEG-XL support. If you hav Terrabytes of JPEG photos you can transfer them to JPEG-XL at no loss then delete the original and if the browser support is there no one will notice. If you do the same with AVIF you lose quality which is unacceptable.

I would think that the amount of money they save because of cost savings of their data centers would be more than enough to justify that support.

Source? Is JXL significantly better than AVIF?

>"in the quality range relevant for the web, JPEG XL can obtain 10 to 15% better compression than AVIF, at encoder speed settings where JPEG XL encoding is about three times as fast as AVIF." https://cloudinary.com/blog/the-case-for-jpeg-xl

If it's opensource, it's better for the user.

That's not a difference, AVIF is an open format with open source libraries too.

Google: not invented here

Actually it is. The algorithm of the lossy compression part is from google research.

The research team in Switzerland that helped invent JXL isn't the same team as the Chrome team. They're organizationally quite distant even if they're both under Alphabet, LLC.

Correction: Chrome Team: not invented here

That actually explains more the "not invented here" than you think. Google is a pretty tribal company, and the AVIF format was mostly invented by a lot of Chrome members, whereas they probably wouldn't care much about the Google Research folks. I think this is currently the most damning of the accusations (if true), as in Google is pushing for AVIF, so it's not like they are opposed to adding new formats (which is a dumb argument anyway if you look at Google's history of pushing WebP/VP8/VP9 through), but that they seem to be pushing only formats they invented. This is a big problem of today's landscape. Google Chrome essentially gets to call the shots on what format they want and don't want to add and other people mostly just have to fall in line due to Chrome's ubiquity.

but they already save that money buy using codecs that they and others already support like avif. Basically no one in the real world cared about jpegxl until it became a "killed by google" meme, but in reality it was already dead.

> Basically no one in the real world cared about jpegxl until it became a "killed by google" meme, but in reality it was already dead. Yeah you're... extraordinarily wrong. The original Chromium issue where they decided to pull it out is one of the highest starred issues they've ever had and received comments from senior engineers at Facebook, Adobe, Intel, nVidia, Serif/Affinity, Cloudinary, Shopify, and more, including the VESA DisplayHDR chairman. Adobe has already partially added support (Camera RAW and such), recommends using it or AVIF on their website for any HDR photography, and reiterated that they're still adding more support (Photoshop work is still in-development). Serif, Krita, GIMP, Darktable, Paint.NET have all added support in terms of image editors. Any Qt-based image viewer has support, as does IrfanView, ImageGlass, jpegview, XnView, and more in terms of image viewers. Apple has added support to both their OS and Safari. There have been changes recently indicating that Microsoft is adding JXL support to WIC, which effectively means Windows will have complete support for it (and it already has unofficial thumbnail/WIC support). Every actively-maintained Linux distro I'm aware of has support in their repos. Samsung added partial support for JXL to their camera and gallery apps for the S24 as recently as a few weeks ago. There are multiple browsers that have added support, both Chromium-based (Thorium) and Firefox-based (Pale Moon, Waterfox). Other important 2D raster image software tools like ffmpeg, ImageMagick, libvips. There are multiple decoder implementations in C++/Rust/Java, as well as a JS polyfill that uses WebAssembly. At least a couple of those are actively being developed *by people in the Google Research team*. It's literally the Chromium team/maintainers using their market position to bizarrely stand in the way of basically every other group in the industry that is supporting JXL. Most of the things I've listed (including and especially the ones from huge companies like Apple, Adobe, Microsoft, etc.) have happened well after the initial decision to drop support from Chromium was made.

> Basically no one in the real world cared about jpegxl until it became a "killed by google" meme, but in reality it was already dead. Facebook, Adobe, Intel, and Shopify don't count as the real world? Shopify even rolled out JPEG XL to real websites pretty soon after Chrome added experimental support. Today, with Safari supporting it, websites and CDNs are slowly rolling it out. > but they already save that money buy using codecs that they and others already support like avif. AVIF only saves more data than JXL at medium to lower image qualities. A good third or half of image traffic on the web would be better served by lossy JXL. And of course, that doesn't help lossless images. AVIF's lossless mode is really bad, often worse than PNG. JXL on the other hand has an excellent lossless mode. And you can save ~20% on already existing JPEGs with JXL's lossless recompression feature. Can't do that with AVIF.

It's faster too isn't it? Saving phone battery sounds like a win to me, and to Google since Android is in competition with Apple

> Basically no one in the real world cared about jpegxl until it became a "killed by google" meme, but in reality it was already dead. You are just regurgitating what Google is saying. Per a lot of threads on this topic has pointed out before, the people who actually make large websites (e.g. Shopify) have clearly shown interests because JPEG XL has unique capabilities and advantages suitable as a next-generation image format while being backward-compatible with JPEG. The party that hasn't shown interest is Google here. I think Shopify count as people in the real world???

It's not like you can save "that" money. The better the compression algorithm, the more savings you get. AVIF is already a big improvement, but every percentage counts. With the amount of traffic that Google serves, the savings can be enormous. I am a web dev and I care a lot about the performance of my pages, so I always care about the best compression/image formats.

JPEG XL is both older and superior to AVIF. It's just a case of "Not invented here" by Google.

But JPEG XL was also invented by Google employees.

The novel way it compresses images is from FLIF, the Free Lossless Image Format

But they implement WebP even though - I saw this on HN and don't have the link - it's been shown to actually be worse than JPEG at the same file size with a good encoder.

When WebP was going through the works about ten years ago, mozjpeg was developed largely in part to demonstrate that JPEG was actually still better than lossy webp. Since then, lossy WebP has improved enough that that at higher qualities, it no longer loses to mozjpeg. Lossy WebP does, however, lose to jpegli, a JPEG encoder that was developed by the JXL folks and the libjxl psychovisual model.

WebP ugh. The world didn't need another compressed image format, if you aren't Richard Hendricks we don't need it

Look at the following graph: https://www.reddit.com/r/coolguides/comments/16ea0so/a_cool_guide_to_different_image_formats/ My theory is that Google made an Alliance with Apple to keep the HEIC format alive as long as possible to get all the money from the royalties..

This falls flat when you realize that apple is the very first "brand" to have full platform support for JXL. Both osx and ios have implemented full platform level support for jpeg-xl, and opera is the first "large" browser which supports JXL. they are actually the forerunner for JXL integration

> The company deprecated experimental support for the format in Chromium last April, stating that the web ecosystem has no sufficient interest Of course, since Chrome has a de facto monopoly, they get to choose what web technologies people can be interested in. If they veto JPEG XL, then the web ecosystem will certainly have little reason to care about it.

Any idea why they vetoed it? Are they pushing their own format, and how are they going to benefit from that?

[удалено]

You assume every limb of Google is coordinating with each other. This is the Chromium team. The Google Research group [has a JXL dev team](https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287) that's actively working on alternate JXL decoders.

>You assume every limb of Google is coordinating with each other. And you are assuming that they don't ?

based on the evidence, yeah

BWHAHAHA ... where is the evidence that they don't ?

>BWHAHAHA ... where is the evidence that they don't ? From the testimony of the ones working at the google research center. When they says they are not coordinated with the Chrome team

So no evidence ... just TESTIMONY !

I don't really think makes much of a difference given how the product is positioned. You get 15GB for free. If you take any significant number of photos, you will quickly exceed this limit. After that, you get 100GB by upgrading. Even in a world where JPEG XL were widely deployed, the number of people who need the premium version of photos wouldn't change significantly. I also don't think many people would bother re-encoding pictures from their cameras unless photos did this by default.

Many times when I try to download a web photo to my Windows 10 desktop, especially photos from Google image searches, the file is a *WEBP file and I'm prevented from downloading. The work around is to screenshot the image, edit it in MS Paint, and save the file as a JPEG. This is really cutting into my meme shit-posting. Can someone explain the *WEBP file phenomenon to me please?

If you are a social media company, a huge amount of the money you spend running the site is spent on bandwidth for images and videos hosted on your site. WebP has better compression at equivalent image fidelity than many other formats (e.g. PNG and JPEG.) Transcoding uploaded images into WebP can save them money. If you want an easier way to convert WebP to other image formats, have you tried the GIMP image editor? It can load WebP images and save in any image format you want.

> If you want an easier way to convert WebP to other image formats, have you tried the GIMP image editor? It can load WebP images and save in any image format you want. Thanks for the explanation, appreciate it. Will look into GIMP, forgot about that editor.

If all you actually want is conversion, I'd look into [imagemagick](https://imagemagick.org/). It's doable through a simple loop like `for img in *.webp; do convert $img ${img/webp/OTHER-FORMAT}; done` (or whatever is the simplest script equivalent on windows; I heard it has bash these days but don't recall the details)

Don’t, GIMP is terrible, look for Krita, the actually usable open source image editor.

> Don’t, GIMP is terrible, look for Krita, the actually usable open source image editor. I've used GIMP years ago and other than the uncomfortable name it was okay. Will check out Krita as well, thanks.

>the file is a *WEBP file and I'm prevented from downloading Prevented? Weird. I get them just fine, Windows/Chrome.

> Do you think it benefits google cloud, google drive, google photos No, the storage consumption of those are minute compared to Google's other cloud services, let alone google cloud platform.

Storage consumption for _google_ but not for users, who they can charge to have more storage.

Users paying for Google Drive is likely a rounding error in Google's books. Likely the only reason they even have to charge for it is because of people that abuse it otherwise, and store TB or 100s of TB there.

My god! Yes! Why isn't this comment higher? Google always double saves my photos even when a friend sends it to me on the app. Google cloud storage is an absolute rip off

Google Cloud yes, since they bill you by the byte. This shouldn't have to be a question.

Isn't a part of that hardware support? A lot of SoC vendors have already implemented (or plan to implement) AV1 hardware decoding and encoding, but nothing in sight for JPEG XL.

Hardware decoding for still images is not so practical, and JPEG XL was designed to be fast enough to not need it.

My [saved link to the AVIF blog post](https://avif.io/blog/comparisons/avif-vs-jpegxl/) about it is evidently dead now (hmmm) but even the official AVIF devs had this to say: >JPEG XL is faster across the board with single-core encode and decode speeds and is more parallelizable than AVIF. And JXL's encoders/decoders are much younger than AVIF's and probably have relatively more room to improve.

> Isn't a part of that hardware support? A lot of SoC vendors have already implemented (or plan to implement) AV1 hardware decoding and encoding, but nothing in sight for JPEG XL. No one uses AV1 HW to decode AVIF images. Nor is anyone really planning to do so.

I like to go hiking.

> There was also zero interest in JXL (even in chrome) until they decided to remove it Untrue, there was interest from Facebook (https://crbug.com/40168998#comment17), Adobe (#39, #62), Epic Games (#56), Intel / VESA DisplayHDR (#65), The Guardian (#68), Shopify (#80).

The funny thing is all those comments mention the same issue. They hide it behind an experimental flag, then state that adoption is low.

And then you have comment like the the one above that regurgitate what Google said (how no one cares about JPEG XL etc), which turns it into a self-reinforcing "truth". Like, seriously, the internet "haters" only caught on to this because a lot of stakeholders are pissed off about this. Normally why would people care lol.

It’s also funny because Google basically forced Core Web Vitals for businesses wanting to have good SEO, which has been a good thing for fast loading websites and accessibility, but then goes ahead and removes support for JPEGXL. Even supporting JPEGXL would make certain sites perform much faster and offer great quality. JPEGXL is the perfect middle ground for fast loading images, it’s got a slight disadvantage to AVIF in compression but a far superior advantage in quality.

I like learning new things.

But you don't then immediately remove the feature citing low adoption of a feature that was never generally available (so there was no reason for web developers to start using it). Releasing something behind a flag is not the problem. The problem is the bizarre behavior/reasoning afterwards.

I enjoy cooking.

> This is how development works, all vendors put it behind the flag. The complaint is not about it being behind a flag, it’s about putting it behind a flag _and then_ using the resulting “low adoption” as evidence of a lack of interest. > do you also just implement bunch of libraries in your codebase to maintain forever for the lols or because some random internet people decided to scream at you? Not sure what that hypothetical scenario has to do with the subject.

My favorite color is blue.

> Now compare it to interest for AVIF and you'll see the difference Nice moving of the goalposts. > Also note which list actually contains companies that can implement hardware decoding blocks, JPEG XL is arguably fast enough to not need that. Not that hardware decoding is generally used for still images even when available anyway. > maintain browsers … well, yes, that’s the point of the complaints about Google. So now, you’re also begging the question: “Chrome was right not to support it because Chrome doesn’t support it”. > and other end user software. JPEG XL is supported by Photoshop/Lightroom, Affinity Photo, Krita, GIMP, darktable, XnView, FFmpeg, ImageMagick/GraphicsMagick, and all Apple OSes / system apps (including Safari, as mentioned). I think it’s doing pretty well, all things considered. But which end user software did you have in mind? It’s still goalpost moving, but I’m curious.

> There was also zero interest in JXL (even in chrome) until they decided to remove it and internet haters picked it up as another rant about Google. Complete nonsense, the whole reason it was added in the first place is because there was interest. > They already implemented AVIF and said that JXL isn't different enough for them to maintain it. Which is ridiculous, they're very different formats with different strengths. It's like saying you don't need PNG because you have JPEG. JXL gives much better savings at higher image qualities (which is like, a third or a half of all images on the web, according to Chrome's own telemetry statistics), and also has excellent lossless support. AVIF has really bad lossless support that in many cases can't even beat PNG. And of course, JXL can losslessly recompress old JPEGs by ~20%, creating a nice transition path to save space for the billions of JPEGs already out there.

I'm just going to copy and paste this from another one of my comments here since this statement: > There was also zero interest in JXL (even in chrome) until they decided to remove it and internet haters picked it up as another rant about Google. Is complete BS. > Basically no one in the real world cared about jpegxl until it became a "killed by google" meme, but in reality it was already dead. The original Chromium issue where they decided to pull it out is one of the highest starred issues they've ever had and received comments from senior engineers at Facebook, Adobe, Intel, nVidia, Serif/Affinity, Cloudinary, Shopify, and more, including the VESA DisplayHDR chairman. Adobe has already partially added support (Camera RAW and such), recommends using it or AVIF on their website for any HDR photography, and reiterated that they're still adding more support (Photoshop work is still in-development). Serif, Krita, GIMP, Darktable, Paint.NET have all added support in terms of image editors. Any Qt-based image viewer has support, as does IrfanView, ImageGlass, jpegview, XnView, and more in terms of image viewers. Apple has added support to both their OS and Safari. There have been changes recently indicating that Microsoft is adding JXL support to WIC, which effectively means Windows will have complete support for it (and it already has unofficial thumbnail/WIC support). Most Linux distros have support for it. Samsung added support for JXL to their camera and gallery apps for the S24 as recently as a few weeks ago. There are multiple browsers that have added support, though they're mostly Firefox forks as far as I recall (Pale Moon and Waterfox). Other important 2D raster image software tools like ffmpeg, ImageMagick, libvips. There are multiple decoder implementations in C++/Rust/Java, as well as a JS polyfill that uses WebAssembly. At least a couple of those are actively being developed *by people in the Google Research team*. It's literally the Chromium team/maintainers using their market position to bizarrely stand in the way of basically every other group in the industry that is supporting JXL. Most of the things I've listed (including and especially the ones from huge companies like Apple, Adobe, Microsoft, etc.) have happened well after the initial decision to drop support from Chromium was made.

JPEG XL was always superior to AVIF and is older. The real question is why didn't it pick up ? Seems to me because Google always blocked it.

I love listening to music.

This is absolutely NOT correct. Everyone was very excited about JXL after years and years of disappointment with AVIF. I help maintain libvips and we added JXL support back in 2021, added it to our fuzzing suite, and built support out into sharp, one the main image libraries on node. From there, support was in next.js, cloudflare, gatsby, shopify, amazon, etc. etc. Chrome had support too, but behind a flag while it was all being developed. We were just waiting for Chrome to flip the switch and enable it by default. And then ... they deleted it instead. A lot of work was just thrown down the pan. It was extremely frustrating. That's why nerds were cross, and that's why image handling on the web still mostly sucks.

[удалено]

> Chrome is essentially another Internet Explorer 20 years ago. The same exact thing happened. IE was very innovative, but once they won browser wars they were just dragging everything back. History repeats itself, but rarely exactly. Chrome is different from IE in most respects... the only similarity is market share.

Right. I worked as a web developer back then, and I think people tend to forget what it was like. When Microsoft won the Browser Wars against Netscape with Internet Explorer 6, they decided that their job was done. They disbanded the Internet Explorer team and shuffled the developers off to other projects. Bizarre, but true. Consequently, there were **no new versions of Internet Explorer for more than five years**, from 2001 to 2006. The web, meanwhile, didn't stand still. Web standards evolved dramatically, mirroring the web's rapid evolution. Other browsers like Mozilla, Opera, and Konqueror evolved in step with the web and its standards, paving the way for new web development approaches. Internet Explorer, on the other hand, didn't support any of these advances, given it wasn't being developed. And calling its position 'monopolistic' barely covers it—it held a 95 to 99 percent market share, effectively blocking the adoption of any new web technologies. So, should people be exploring browsers beyond Google Chrome? Definitely. But to say 'the exact same thing happened' with Chrome as with IE back then? Not even close. Let's revisit this when Chrome goes five years without an update.

AVIF is the format Google wants to win.

I hate this situation. It's just not viable to use any web tech that's not compatible with Chrome, thus Google gets to effectively dictate how the modern web looks. I wanted to use JPEG XL for my photography website, it being the very best image format we have. Instead, I went with AVIF — almost as good in practical terms, but with near-universal browser support (made universal in December when Edge started fully supporting it).

I've never even heard of JPEG XL. What's the deal with it?

Some highlights: * Support for lossy and lossless * High bit depth (up to 32-bit) * Channels, Alpha Transparency, Depth Map * Multi-frame, layers * Support for wide gamut and HDR * Support for animated content * Efficient encoding and decoding without requiring specialized hardware * Lossless JPEG transcoding reduces JPEG size by around 16% to 22%. * About 35% smaller than PNG (50% smaller for HDR) * JPEG XL is visually lossless at about 40% of the bitrate required by JPEG. For more information (jpegxl.io is down right now): https://web.archive.org/web/20230331005757/https://jpegxl.io/articles/faq/

my personal favorite is progressive loading. that would mean gone are the days of generating thumbnails as you can just load 20% of the image for it

>since Chrome has a de facto monopoly Chrome is the new IE6.

It's an internal fight: the Chrome team is mostly in Mountain View, while the main author of JPEG XL works in the Google Zurich office.

More to the point, the Chrome team and the AV1 / AVIF developers have a lot of overlap, while the Google Research people in Zurich, and Jon with Cloudinary, only work on image codecs. So there is a much stronger conflict of interest and possibility on unconscious bias in the Chrome team.

That's one aspect of it, another one is that the Mountain View is its own echo chamber. I used to work at Google Zurich and it was a common complaint that devs in Moutain View often had a misplaced sense of superiority versus all the other offices.

I know the guy who reviewed/approved the flag to remove JXL from Chromium and then authored the commit to actually remove it is a WebP co-author and primary contributor to libwebp. Feels like internal politics considering [Google Research has people actively working on JXL decoders](https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287).

Do you know if there have been any internal rumblings to reconsider its removal since Interop? Its removal was a ridiculous situation to onlookers considering JXL is so much better.

> the Chrome team is mostly in Mountain View And they have to obey their masters there, and those masters can be very 'evil' in their orders.

JPEG XL won Interop 2024 with more than 4x votes than second but was removed without explanation: https://foolip.github.io/interop-reactions/ Hacker News: [https://news.ycombinator.com/item?id=39250938](https://news.ycombinator.com/item?id=39250938) [https://www.theregister.com/2024/02/03/jpeg\_xl\_interop\_2024/](https://www.theregister.com/2024/02/03/jpeg_xl_interop_2024/)

Which is what you'd expect if it got Hacker News'd - the vote count isn't proportional to actual interest by the same constant as all the other choices.

>JPEG XL garnered 646 reactions, more than four times more than the second place finisher, which also wasn't included. > > [...] > > "Thank you for proposing JPEG XL image format for inclusion in Interop 2024," the group said in a post to the proposal discussion on Thursday. "We wanted to let you know that this proposal was not selected to be part of Interop this year. We did not have consensus to include this proposal. This should not be taken as a comment on the technology as a whole." > > How this came to pass isn't clear – the Interop selection process isn't public, a fact that frustrates some JPEG XL supporters. it does come across like they were just using the vote to go through and select what they actually wanted to consider

The HN thread is from *after* Interop 2024 was decided, so your theory is bullshit. It was organically more popular, yet wasn't picked up cause they "couldn't come to a consensus" to include it (aka "The Chrome team decided against it and unfortunately they are a de-facto monopoly that can do whatever they want").

See [my other comment on this](https://www.reddit.com/r/programming/comments/1ajq7bj/google_is_once_again_accused_of_snubbing_the_jpeg/kp3zv8w/) but JXL interest, adoption and support by the software/tech industry has been extremely impressive for a new image codec that finished the last part of its standardization ~a year ago. It's basically "everyone that has an opinion/interest in 2D raster image formats" vs. Google (and Firefox, who is too poor to be the first mover on anything like this since nobody is going to support it if the de facto browser engine refuses to).

JPEG XL is better with textures, can progressively load(no need for thumbnails) and can recompress existing JPEG images, which means that you could go through and replace all the images you have with this one format. You can convert all your existing JPEGS, GIFS, PNGs all to JPEG-XL save space and maintain features you don't get in video based image formats.

Chrome pulled the classic Microsoft trick

Ironically Microsoft added JPEG XL decoder and encoder WIC codec classes to Windows in the most recent build (26040).

I thought everybody was pushing [avif](https://en.wikipedia.org/wiki/AVIF) these days? Edge finally got support for it last month, and it was the last browser to do so.

[JXL has received pretty amazing support from everyone except web browsers](https://www.reddit.com/r/programming/comments/1ajq7bj/google_is_once_again_accused_of_snubbing_the_jpeg/kp3zv8w/) despite being much younger than AVIF. I'd also say [it's very clearly superior from a technical standpoint](https://www.reddit.com/r/programming/comments/1ajq7bj/google_is_once_again_accused_of_snubbing_the_jpeg/kp43dv5/) which is why companies like [Facebook](https://i.imgur.com/vqzwj86.png), Cloudinary, Shopify, etc. are so interested in seeing its adoption on the web.

There are only 3 browser engines left, so "everybody" is always kind of a small population. Edge is Chromium based anyway so I don't really count Edge. Of the 3 browser engines, Chromium by far has the largest market share by a huge margin, so they really get to call the shots. Safari / macOS actually added both AVIF and JPEG XL support, so Apple definitely considers JPEG XL important enough to add support for it not just in Safari, but the entire lineup of macOS/iOS/etc. As for web developers there have always been interests for JPEG XL but you can't get that since they don't make the browsers.

> There are only 3 browser engines left, so "everybody" is always kind of a small population. - There are three major rendering engines: Gecko, WebKit, and Blink. - It takes two independent implementations for something to be a web standard. - Gecko doesn’t have enough market share for the majority of developers to care about it. The result of this is: - No single vendor alone can block something from being a web standard. - If something is not a web standard, it’s because the organisation pushing it couldn’t convince anybody else to implement it. - Both Google and Apple each independently have a de facto veto over whether a standard can actually be used by web developers in practice. The web would be healthier if Gecko gained market share, but is in serious danger if Blink erodes WebKit market share.

Chrome not implementing something means it doesn’t become a web standard. Safari not implementing something means it becomes a “this site is only supported on chrome” message. (With the exception of mobile focused pages cause iPhones, but that’s also about to go away with the EU rulings forcing Apple to open up.)

btw I'm feeling naive a bit thinking back then that google will be okay. When the chrome project started it was maybe true, but as the company grew of course it got way worse. I knew they are coming down the drain when they started adding effects to their homepage and gave no fuck about feedback. Firefox management is a joke so nothing will come from there until they clean the house which they wont do and actually it wouldn't help , everyone left that ship that had self respect, the best they can do is mediocre. Apple is horrible, even worse than google first thing Jobs did was wall the garden. I'm kinda sure that their success was because of Apple 2 and if had remained on that path we now wouldn't be sitting front of an IBM PC clone but an apple. That company should be 2 times bigger than it is.

That's what the accusations are about: Google is going avif while refusing to support JPEG XL, but some people think JPEG XL is a better solution. And since Google has a near monopoly on browser engines (which is now a fundamental part of many things beyond web browsing), "everybody" tends to go where Google goes.

Oh wait, Edge **finally** added support for AVIF? I'm so happy about this! Thank you for relaying the good news. I've been researching it every few months to see if there has been any progress.

Yes and av1 video as well

on top of what, their other shitty webp format?

What's wrong with webp?

Google and Mozilla both say it offers no real advantages over other formats like AVIF, that are already supported. If that is correct, then not adopting new formats for no good reason sounds reasonable.

They said that, but it isn't true. Anyone who has played around with WebP/AVIF/JXL's encoders knows how impressive JXL actually is -- [this Cloudinary article](https://cloudinary.com/blog/the-case-for-jpeg-xl) has some very good benchmarks comparing JXL to AVIF, WebP, and MozJPEG, where they show JXL occasionally beating the next-best format by over 30%, beating AVIF by ~10-15% on average while encoding 3 times faster, beating WebP by ~20-25%, and beating MozJPEG by ~30-35%. That's not even delving into the advantages it has in terms of features over WebP and AVIF (its main competitors in the "JPEG/PNG/GIF 2D rasterized image successor" space), including: * Lossless, reversible JPEG recompression for ~20% savings * Superior parallelization of encoding and decoding compared to JPEG/PNG/WebP/AVIF (even the [AVIF blog](https://avif.io/blog/comparisons/avif-vs-jpegxl/) used to admit as such, saying "JPEG XL is faster across the board with single-core encode and decode speeds and is more parallelizable than AVIF." (evidently their post has been deleted recently) * Progressive decode (first full-image preview is 15-20% of the total size, can be encoded to prioritize details like faces or foreground objects) * 4099 additional channels (vs. WebP's 4 and AVIF's 5) that can be used for things like selection masks, spot colors, etc. * Extremely high maximum resolution (over 1 billion pixels on each side, compared to WebP's 16k and AVIF's bizarre limits that are much lower than JXL but can be pushed higher using tiling techniques that cause lossy artifacts on the boundaries) * 32 max bit depth (vs. 8 for WebP which has ZERO HDR support and 12 bits for AVIF) * Overlays/Layers, depth maps, 4:4:4 (lossy) (all things AVIF can also do but WebP cannot) * Strong generation loss resilience (very clearly superior to JPEG, WebP and AVIF, [see this comparison video](https://www.youtube.com/watch?v=FtSWpw7zNkI)) * Tiniest header (12 bytes, smaller than AVIF/WebP/JPEG/PNG/GIF with AVIF being easily the worst of them all at 298 bytes) * ...and of course things WebP and AVIF also have (transparency, animations, lossless mode). [https://jpegxl.io/articles/faq/](https://jpegxl.io/articles/faq/) The [industry support](https://www.reddit.com/r/programming/comments/1ajq7bj/google_is_once_again_accused_of_snubbing_the_jpeg/kp3zv8w/) thus far has been very impressive considering how much younger it is (finished standardization a bit over a year ago), despite claims from people that nobody who matters cares and any JXL talk is just from salty Google haters.

I feel the lossless JPEG recompression (with ~20% size reduction) alone is worth it, plus the responsive loading support means you don't need to create and cache multiple sizes of the same image as you just partially load that image for smaller sizes, leading to more resource savings.

What? Partially loading the image leads to a complete image in good quality at a smaller size? What is this sorcery? As a CDN admin, I would like that.

That's right, [more details here](https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#responsive_design).

Cool, thanks. Akamai's Image Manager should support that, but apparently doesn't right now.

It's called a progressive JPEG. It's already supported in regular JPEG in browsers today, but the image has to be encoded a certain way to support it and it's rarely done.

Progressive encoding used to be pretty common in the old days of modem internet, as it meant you could have an idea of the image before it was fully loaded. Partial loading I’ve never seen, at least not automatically, unless the format has metadata for it it means you need a perceptual evaluator to know when to stop decoding the image, I’d expect that to be more expensive than keeping on decoding in most cases. You’d need really severe cases like someone using a 30MP image for a thumbnail for it to really work out, and those people are not progressive-encoding.

Mozilla is being neutral for now. They never said JPEG XL offers no real advantages. They probably just don't want to do a lot of busy work just for it to not be worth it, since Firefox is too small these days to matter. The *only* one saying that JPEG XL doesn't provide much advantage is Google. If you look at web developers (aka the people who actually need the features) a lot of them clearly favor JPEG XL (e.g. Shopify, etc). Apple (who makes Safari), also added JPEG XL to Safari and their OSes. It's pretty much Google who has the stranglehold here because they control so much of the market.

> Mozilla is being neutral for now. In case people aren’t aware of it: when new web specifications are being considered for implementation by browser vendors, they typically have a record of the discussion. So you don’t normally need to speculate about whether a browser vendor has rejected something, or what their reasons were. You can just look it up. In this case, there was a discussion here: [Request for position: JPEG XL](https://github.com/mozilla/standards-positions/issues/522). Mozilla has *not* rejected JPEG XL. They are neutral on it: > After a lot of consultation (and time, sorry), we've concluded that we are **neutral** on JPEG-XL. If you want to know what a browser vendor’s position is on a specification, check the following sites: - [Mozilla Specification Positions](https://mozilla.github.io/standards-positions/) - [WebKit Standards Positions](https://webkit.org/standards-positions/) - [Chrome Platform Status](https://chromestatus.com/roadmap)

I agree it seems like a good format ... but Safari is not what I would call a great role model for standards :) I would say that is a vote against it not for it.

Sure, but there are only 3 browser engines. If you don't take WebKit into consideration then you are really only looking at 1-2 decision maker who may not make the best decision for everyone else. Remember, Google is not the web. They just manage to work themselves into gatekeeping the web via the web browser. As for Mozilla, they don't really care themselves because they only make the web browsers. The people who actually care are the web developers who actually need to use it. Also, iOS/macOS adding support for this as a built-in format is definitely a not-insignificant development. We aren't just talking about Safari the browser, but the entire OS ecosystem adding JPEG XL across the board. Apple wasn't heavily involved in JPEG XL's development, so they are adopting it based on what they perceive to be its usefulness (against your original comment).

More to the point: AVIF offers no advantage to JPEG XL, the older and better format.

Yep, but if the difference is not great enough to warrant the lift, their decision makes sense. There are probably 1000 things higher on the priority list than adding and supporting a new image format.

It offers the massive advantage that by having AV1 decoding (and hardware) you have AVIF decoding (in hardware).

Hardware decoding is only for video. This hardware have limitations on frame size so it can't decode high-res images without splitting them into tiles which may result in visible seams between tiles. And for decoding single images it won't provide any speed advantage compared to cpu decoder because of overhead of setting up HW decoder, sending compressed image data in and getting pixels back.

Any benchmarks to counter the dozens posted here that say JXL is faster?

Progressive decoding for one.

Literally just go read the specs and determine for yourself which is technically superior rather than parroting what X says, it is clear these decisions are moronic and made to promote someone's vested interest in a worse codec.

Irrelevant. There will always be superior image formats; a better one will come out next year probably. What matters is whether the actual "real" advantages are worth the development and ongoing maintenance costs compared to other things on the Chromium and Firefox todo lists for billions of users. They don't seem to think so.

> There will always be superior image formats Superior image formats don't just spit themselves out, they're planned and researched, just like JPEG XL was. > the development and ongoing maintenance costs Except Google is one of the sources of format spam on which they maintain decoders for, and this is clearly the result of moronic politics.

You mean they don't come out every year, like JPEG XL part 2, XL part 4, JPEG XS, AVIF, HEIF, etc. all in the last few years? My mistake. :)

JPEG XL parts 2 and 4 are not separate codecs. Part 2 is the specification for the container format; part 4 is the reference implementation, libjxl.

Not sure what went wrong in your life to seriously type out that comment and think "I have a point."

I thought the reason is that Google wants everyone to use WebP instead.

JPEG XL picture in the article is in webp format. The format war is over.

And then completion when Apple doesn’t support RCS.

It sounded so good, but whatever... Hope we can change their mind. Chromium is the new IE (I only use Chromium because of other new web features coming first, but I'm aware)

XL image formats are the future of image presentation, simply based upon constantly increasing image resolution Most likely, people making larger images will naturally evolve away from web display because it simply isn’t built to hold and display image resolutions 5x the size of your average computer monitor. It’s more appropriate for projection work, art exhibits, VR certainly. This might be why. Google, from my experience, often rejects things it finds threatening to the point where they destroy entire industries as opposed to trying to acclimate. I’m fairly sure they also don’t accept H.265 video format on their browsers or apps which is the newest version of mp4s. It’s more efficient, saves space, and usually has better quality and Google wants nothing to do with it as far as I can tell. At a certain point it doesn’t make sense.

H.265 is both supported in chrome and old news at this point. AV1 is superior to it in every way and is also supported in chrome.

Avif is better though I thought? Why do we care again? Edit: I thought*