JPEG XL support has officially been removed from Chromium

JPEG XL was not used anywhere which is why it got deprecated. It was never gonna be the future of anything.

> in hopes that Google will change their mind once the rest of the industry has switched to JXL.

What rest of the industry? Apple is clearly not interested, neither is Microsoft[0], and xl weirdoes have been busting mozilla's balls for years with little progress.

Even if you manage to bully Mozilla into shipping and default-enabling xl rather than just removing it, Firefox is currently sitting at an incredible 2.5% market share (and I'm saying that as a Firefox user).

[0] well they obtained a patent on rANS so they might be interested in other people using it I guess, that's money in the bank: https://www.theregister.com/2022/02/17/microsoft_ans_patent/

> I think I will continue using it with WASM polyfills

This is the answer. You can also build your own application-specific codecs this way.

I've been exploring a variation of jpeg/mpeg that uses arithmetic coding and larger block sizes. Virtually all of the fun patented stuff we couldn't use in the early 00's is in the public domain now.

The main reason this is sad to me, despite the existence of AVIF, is: JXL could losslessly re-compress JPEG images. There's a vast amount of JPEG images out there where the uncompressed data is long lost. Those images can't really take advantage of AVIF, since then you'd end up double-compressing the image; AVIF will do its best to re-create the JPEG compression artefacts. JPEG XL can achieve better compression ratios on existing JPEGs without this double-compression problem.

> I think I will continue using it with WASM polyfills

Images that can't be displayed without Javascript. Incredible.

Was it patent encumbered?

JXL had this coming. They should have written specifications. The implementation can never be the standard. I hope everyone watching this learns from their mistake.

> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case.

If Chrome deems that something is useful (to them, for some definition of useful), they just release it (and if this something was on a standards track, too bad, it's out now).

> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support.

Waiting for libjxl 1.0 is reasonable. Though I can't help but to think it would be less work to just keep the experimental feature in there until it is stable.

I think it's fine to assume the more likely interpretation that this company simply isn't interested in the format anymore, rather than whatever larger stretch you're describing here. "You don't want to keep dead code around." That's rich :) maybe if this was some one person hobby project or something.

In that case they would have worded their rejection message differently.

> Using it via WASM is a strong indicator.

Is there a good way to do that, though? What I think will needing to do properly:

1. You can implement picture/audio/video/document file formats as extensions, without needing to intercept requests/responses (so that save, view-source, etc will still access the original file). (I think some versions of Mozilla have this capability (although some details of the design are not as good as they could have been), but as far as I know, WebExtensions does not.)

2. Extensions can be native codes, WebAssembly codes, or JavaScript codes. (Native extensions will be excluded from the extensions catalog, and the end user or system administrator must install them manually.)

3. Add a "Interpreter" response header, to indicate what to do if the browser does not understand the file format. For example, this might link to an implementation of that file format in WebAssembly.

4. Such WebAssembly programs can also be used outside of a web browser, in local standalone programs. For example, an external program might run the WebAssembly code to convert data from stdin to stdout.

>Adding image formats to the web should be the last step because it is so difficult to remove them.

Not from a company that added WebP to its browser and wanted a new video codec every 2 years.

>Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability.

You’ve missed two most important ones: “business reasons”, eg trying to harm some (potential) competitor, and someone trying to get promoted. Don’t assume there are valid technical reasons behind every corporate decision like those; usually there aren’t.

> Browser vendors have other priorities besides having the latest-greatest compressor: code size

If this was the case, Google wouldn't output 400 new web apis every year, and shove every feature under the sun into Chrome

I think the way to go for browsers is to support new codecs (as long as they're plausibly useful for the web, royalty-free, etc), but to avoid getting stuck with them by having web devs assume they can use codecs without content negotiation / fallbacks. So e.g. they could randomly in 1% of the requests pretend only to support the legacy codec (say jpeg and png for images, or h264 for video), which basically forces web devs to put proper fallbacks in place (using multiple sources, or using http content negotiation) since otherwise random parts of their website would just be broken. Putting those fallbacks in place is needed anyway: it's just a bad practice to ignore the long tail of browsers that don't support the latest codecs yet. The 1% "fallback-only" requests would mainly be a way to force web devs to take that long tail seriously since they would notice the failures even when testing only on Chrome.

That way, we can get 99% of the compression gains of new codecs right now, without having to wait until a codec gets sufficient traction outside the web, and without getting stuck with the codec forever if it turns out not to be that great after all, or if a better alternative shows up. If it does turn out to be great and it gets ubiquitous support everywhere (like JPEG and PNG), then it can be considered to make it a permanent addition to the web platform, i.e. make it part of the "fallback formats" pool instead of the "99% of the requests" pool.

The web platform needs a long-term media codec deprecation strategy. It needs to be a better strategy than just resisting any change until a codec has become ubiquitous and unavoidable — the web is an extremely important use case for media compression, and it's at this point unlikely that new codecs can even become ubiquitous when they cannot be used for this key use case. I think the strategy of "enable by default but only for 99% of requests", as bizarre as it may seem at first glance, would be a good way to make progress without adding irreversible bloat to the web platform at every step.

The case is not that compelling to me…

> * Lossless JPEG recompression

Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement.

> * Progressive decoding

jpeg also has this, and it’s a niche feature these days.

> * Lossless compression performance

png covers this

> * Lossy compression performance

Nice, but a relatively small incremental improvement in the general case.

> * Deployable encoder

This isn’t a case for jpeg xl, just table stakes for any format.

> * Works across the workflow

Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows. Actually, this is something of a negative considering the resulting complexity of the codec and image format and that it muddles the distinction between the authoring and published form of an image.

There are negatives too, so it’s not enough to be a little better for some cases..codecs are attack vectors. An all-new complex codec is an all-new broad attack surface. And, of course, it’s yet another feature to test and maintain, which costs time and necessarily pulls focus away from other things.

So obviously not all of Google agrees with the decision to remove support then!

Yeah, jxl support is a huge win for anyone working with large quantities of jpeg files; aka basically everyone now that we all have smartphones with cameras and jpeg is the default format.

Jxl is a huge upgrade for simpler images as well, I think I save something like ~60% of the space used by my comics collection with no visual detail loss by converting to jxl.

You're correct it's possible to have the front end select the right image. That can be done in CSS via "@media(color-gamut: srgb) {}" (p3 and rec2020 are the other supported options) for the different pre-rendered images. In this way you don't need to script anything and the client still only loads the required image.

WebGL/Canvas methods will be possible one day but right now how that will all get implemented is still being worked on. https://github.com/WICG/canvas-color-space/blob/main/CanvasC... the same can be said for general CSS support or any other interface in the browser beyond images and video at the moment https://w3c.github.io/ColorWeb-CG/.

You are trying to do colour management on the web, and also likely in the general consumer PC space.

This is impossible, and will remain so for at least a decade.

No vendor other than Apple has the slightest interest in getting colour even vaguely right, because they're all run either by colorblind lizards, or have corporate drones that are given identical monitors. The cheapest monitors possible that are basically greyscale.

Recently, Windows has taken several steps back from Vista's fairly good colour management. For example, the newer Win UI 3 SDK is 8-bit sRGB SDR only. Similarly, HDR support on Windows 11 is totally broken, and every semi-annual release does random things to it. When bugs are identified by consumers (not Microsoft!), they delay the fixes to the next semiannual release... at which they break other things. There hasn't been a release of Windows ever that can correctly drive a directly attached HDR display, such as the type used in a laptop.

None of these corporate drones understand the problem because they literally cannot see it.

It was no longer unstable beta

The reasons stated are:

- Experimental flags and code should not remain indefinitely

- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...

Seems to have been partly based on this: https://storage.googleapis.com/avif-comparison/index.html

> Do we know why they chose to remove it?

Phoenix had an article on why Google decided to remove JPEG-XL.

https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...

The official justification seems to be a) experimental nature of JPEG-XL, b) lack of demand, c) maintenance burden.

Take it with a grain of salt. Personally I don't buy it.

It competes with WebP?

Have a look at WASM decoder JXL.js: https://github.com/niutech/jxl.js

JPEG XL was finalized 6-7 years after HEIF so I am not sure it is a good comparison. Especially seeing that JPEG XL was first finalized this and last year.

Camera manufacturers are old spineless companies. In all those years they have done nothing for digital image formats and it is the most important thing in a camera. They weren't even able to come up or attempt to make a standard RAW format. All that came from Adobe (DNG), which the camera manufacturers happily ignored for their own proprietary solution until this day.

That was around the time the the final parts of the standardization procedure was getting finished: https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status

That's when Adobe formally expressed a support for JPEG XL (comment 61), which is a big milestone by its own and people started to push Google to finish the experiment in lieu of that event, as everyone expected that it will land at some point, most likely shortly after libjxl reaches 1.0.

Unfortunately, if the format supports at least lossless compression (i.e. able to represent all uniform range in the pixel domain with a reasonable compression rate, amortized) then there is no practical way to distinguish lossy compression from lossless compression. PNG -> JPEG -> PNG is a lossy compression but the resulting output is seemingly lossless while it isn't.

You should see what they said about supporting DCHP on Android for ipv6.

They have simply opted not to support it because you "should be using something else"

There’s also the politics of them not supporting img=*.mp4 too

https://bugs.chromium.org/p/chromium/issues/detail?id=791658

MathML is making a return next month. https://chromestatus.com/roadmap

If JPEG XL was actually utilised they would not be deprecating it

chromium is a business?

I thought the business was Chrome, whereas Chromium was the open source (and GPLed) project that makes the code that Chrome uses and that would almost certainly not start out as GPLed if it was a new project now.

Well MIDI support is pretty cool, I could just go to Novation website and update SL49 firmware (after appropriate confirmation). Also Tasmota project has a firmware upload over serial, pretty accessible if you have Chrome.

I think Bluetooth could similarly be useful for e.g. heart rate monitoring apps for sports.

There are people at Google still fighting for JXL

AVIF? The war was lost when Apple set the default iPhone photo format to HEIF. You can't compete with that.

Only JPEG can surpass JPEG.

Pretty sure that JPEG won the format war for the next JPEG, decades ago.

No one wants this. The benefits just don't outweigh the headaches in compatibility and content duplication. JPEG is good enough, and always has been. We'll all be happier by celebrating such a impactful technology than grousing and constantly trying to fix what ain't broken.

No loss there, just slowdown and additional complexity for the web devs to deal with.

Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too.

Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.

It’s a tough battle.

For about 10 years I have been thinking about new file image file formats, it wasn’t until last year that I started really using them. For the web there is the cost of data transfer and the cost of data storage. You can save on data transfer by adding more files in more formats but you pay more in storage cost. To fully realize the economy of better file formats you need to retire JPEG and not add more files.

I finally got convinced that WEBP was supported well enough that it was worth using 𝐚𝐧𝐝 that the image quality was really good with small files. I learned that the disadvantages of new file formats that claim to compress better are real but the better compression isn’t always real. I see people write a blog post where they compress three sample images but a real evaluation project is a lot more than that.

So the world may well be better off with a second-best file format that people really use than being stuck with JPEG because people are struggling to make up their mind about what new format to use, support, etc.

I believe current AVIF decoders and encoders are not competitive against JPEG1 codecs from the libjxl project. Check out the 'jpegli' effort. My guesswork is that jpegli is likely 5-10 % better for photography use case than AVIF. Jpegli also allows for similar HDR dynamics, 10-12 bits, like AVIF.

I don't see why you're getting downvoted. With Chrome removing JXL and all the browser vendors' expressed intentions to get behind AVIF, it certainly seems like AVIF is the clear winner in this round of the image format wars.

An image file format with a maximum resolution of 8193x4320 (without hacking pieces together) can never win a format war, let alone one in 2022 for pete's sake.

I know essentially zero about this space, but I would almost argue categorically that 20% is not "incremental".

> What's up with this JPEG XL cult in hacker news?

I'm not sure it's on HN specifically. There seems to be a JXL cult, and like butters they flock to any mention. And in the same vein, they seem to inject large amounts of copium when reality doesn't go their way.

HN loves, in the aggregate, to hate on Google. So Chrome removing support for an image format is a good opportunity come up with inane conspiracy theories. Repeatedly.

The good thing about a conspiracy theory is that facts don't matter. JPEG XL being a primarily Google-created format in the first place? The format being dead in the water on the web without support from Apple/Safari, which was never forthcoming? Nobody wanting a repeat of web? Irrelevant, you can just pretend that this is actually a format that every other browser supports.

There is an interesting cult I only realized after this affair, namely a group of WebP haters. Apparently there are a lot of them but weren't visible until JPEG XL is seen as a "solution" to WebP, and many of them became a vocal supporter for JPEG XL at any cost. So that's a big part of the cult.

Another part is probably a growing opposition to Google and Chrome. I had to explain again and again that JPEG XL was also jointly developed by Google (Research Zurich) and Cloudinary, but you can still reasonably argue that Chrome aligns better with Google's own interest than Google Research. And if you apply the same stringent criteria to AVIF, AVIF doesn't stand well either---it would have made zero positive difference if AVIF was deployed this year and not 2 years ago, and libavif is not that small. As AVIF and JPEG XL have their pros and cons when compared to each other, this alone can be seen suspicious enough from outsiders. Keep in mind that Chrome is now the Web Browser so there are a lot more to expect from them, like or not.

Some people don't like Google or Chrome in general, for various reasons (valid or not), and they'll use any opportunity to criticize them.

JPEG XL was made in the JPEG committee and the two main proponents were Google and Cloudinary. So it's insane to say that Google in general would be opposed to JPEG XL. This was not a Google team that was part of the Chrome team though.

The way the Chrome team has handled this was not "the best way possible" in my opinion. They first made a decision, and then a month later they showed the data that lead to it (that was one week ago). This data was created by the AVIF team. They did invite anyone to provide feedback on this data, but they did not wait for this feedback to execute on the decision. I don't think this is the best way possible to handle this. A better way would be to first provide data, then wait for feedback, allow all sides to provide their input, have an open and honest discussion involving all stakeholders and experts, and then make a decision. That would be a better ordering of steps.

I agree though that this is not some conspiracy by Google. It is just a difficult technical decision to make, and they're currently making the wrong decision in my opinion, but this is something that has to be motivated technically, not emotionally or politically.

Proposal: some of the criticism may be motivated primarily by the meta-level issue rather than the object-level issue, viz. what this kerfuffle says about HTML5 and web technology in general.

The web has many positive aspects but modularity isn't one of them. HTML5 has turned into an unfocused attempt to specify a whole computer from bottom to top - everything from a [virtual] CPU, to programming languages, graphics stacks, text rendering, UI toolkits, MIDI, sockets, storage, Bluetooth, USB and more. Unlike other operating systems, the resulting Chrome pseudo-OS has nearly no extensibility. Attempts to use WebAssembly to hack around this yield mixed results at best given the problems of needing to constantly re-download the modules (cache segmentation), needing to re-JITC the modules and inability to share code (process isolation).

Images are a core part of the web's functionality, they were literally one of the first features ever added to HTML. The fact that new image formats can't be added for code maintenance reasons, even when having clearly unique features and interest from major companies, worryingly suggests that the web platform may be heading towards a form of technical bankruptcy. HTML has support for obscure features virtually no web sites will ever use like MIDI or USB support, whilst an upgrade to a core feature that every website uses (except HN of course!) apparently cannot be done any longer. It means implementing a complete yet non-extensible OS stack from top to bottom is a task too large for even the world's largest and richest corporations.

In the beginning, the web's architects realized and understood that it wasn't feasible for browsers to implement everything you might want to embed in a web page. The plugins API was an early addition to the platform as a consequence. When it was deprecated, the stated reasoning was as follows:

https://blog.chromium.org/2014/11/the-final-countdown-for-np...

"Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base"

At the time this sounded wise. But since then tens of millions of lines of code have been added to Chrome (almost all C++) so "reducing complexity in the codebase" seems like a hard argument to make with hindsight. Browsers were capable of running plugins inside their process sandboxes and exploits in Blink are found regularly, so it's not really clear that it made much security difference either.

So maybe that's one reason it's getting such a reaction. This JXL incident isn't just about JXL. It's about what it implies for the future. Who will even bother researching new image codecs now, if even Google itself can't get a better codec into the web?

It may be time to start thinking about what alternative designs to the web might look like, with a strong focus on modularity and extensibility whilst still taking into account everything that was learned over the past 30 years. I have some ideas already but haven't written them up yet.

I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google.

I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL.

Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected.

So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec?

I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it.

Just dont ever come out again and say everything you do is better for the Web.

[1] https://storage.googleapis.com/avif-comparison/index.html

[2] https://twitter.com/jonsneyers/status/1563442356493230080

No. It's some random person sending a pull request, which has not been accepted. Looking at their history [0], the account was created two weeks ago and the only contributions were attempts to revert earlier JPEG XL removal commits. Those requests were not accepted.

[0] https://chromium-review.googlesource.com/q/owner:ayz.out%254...

did you tell chatgpt to act like jar jar binks or what?

JPEG XL is royalty-free

Are you thinking of JPEG 2000? Different thing.

Some options: ffmpeg, GIMP, Krita, Photoshop (if you enable it in the settings), and the reference implementation cjxl which you probably already have installed if you use Linux (because QT and GTK depend on it).