Hacker News Reader

Comment by yboris | Hacker News Reader

They claim:

- 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

It's nonsense -- how can they claim "not enough interest" when we can't enable the feature on a public website (our visitors won't be able to see images).

View on HN

Neither Mozilla nor Apple ever finished the implementations enough to even enable them, and they aren't being worked on.

That doesn't seem like a lot of interest as far as anyone can tell. The main interest has been from Facebook and Adobe, afaik.

If it's wrong it can be redone later. It isn't a blood oath never to reimplement it.

Come on, how often has Google been the first to enable new browser features forcing the hand of Mozilla and Apple? Google know they are the gatekeepers of web tech. This is just a way for them to kill the format

People complain to high heaven google shouldn't get to decide. Great, so then convince the others, don't rely on Google to do it.

As for killing the format - Google maintains libjxl, the jpeg-xl reference impl, and has for years.

But like, if the people maintaining the reference impl for years really want to kill the format, maybe we should at least understand why? They've been in the thick of it, after all.

Controlling an image format is basically worthless for a company like Google. Especially since they are always royalty free so far.

The cost to Google in bandwidth/storage/etc of images is much greater than than they could ever make off control.

(Unlike, say, Adobe or someone)

From what I read Firefox is also just linking libjxl , so what kind of finishing should they have been doing? Google gave it, Google took it. If nobody fixes the monopoly, this will be the future of all web standards.

libjxl still exists, it's still available.

The way this gets fixed for real, at least to me, is to get mozilla/apple to have skin in the game.

I'd say this.

There are two reasons why you would use a higher compressing image format.

(1) To save network bandwidth, (2) to save storage.

Adding AVIF, WebP, and JPEG XL to a JPG file help with (1). To help with (2) you have to be able to replace the JPG with something new. Supporting more than one new file format is counterproductive.

It took me years to decide WebP was well-supported enough to be worth using but until very recently it still got a major caveat

https://caniuse.com/webp

that "Safari 14.0 – 15.6 has full support of WebP, but requires macOS 11 Big Sur or later."

With new image formats Apple decides it is a reason why you should buy a new machine and decides not to add a decoder to the library that works with older processors.

None of the other browser vendors have implemented support for it and all the other browser vendors have supported the comparable AVIF format (which is live across the board except in Edge), so this seems pretty much a "noone is interested in this" type scenario.

Ecosystem doesn't mean a few fans on HN, in this context they mean "people building browsers".

real reason is that it compete with WebP format :-)

JPEG XL is based on Google's Pik, and several of the top contributors to libjxl are on Google's payroll: https://github.com/libjxl/libjxl/graphs/contributors

It is literally the same people. I designed WebP lossless and had a lead role in Pik and JPEG XL (invented and implemented gaborish, xyb colorspace, adaptive quantization and block splitting heuristics, modulating epf with adaptive quantization, etc.)

I was confusing JPEG XL with JPEG XR. If google want to kill JPEG XL, this is fine. Since no one is using it I beleive.

Reply on news.ycombinator.com