Hacker News Reader

Hacker News

Comment by qingcharles | Hacker News Reader

Full thread

qingcharles

And Google just (sadly) pulled support from Chrome.

Your move, Google.

View on HN

With the only justification being "nobody wanted it", a plainly false statement.

WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.

Google is using the wrong tricks to keep marketshare.. I'm not even sure if they know it

Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.

> Their justification was more that adding it would be committing a lot of hardware

Which is completely nonsensical. Hardware support is meaningless for web images.

Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).

No it wasn't. WASM implementations are simply slower than native support. No browser uses HW accelerated decode for AVIF images or JXL. I think Safari might use HW for JPEG, but that's it across all browsers.

>> Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation

> No it wasn't.

https://news.ycombinator.com/item?id=33935355: "Wasm does not have the hardware acceleration necessary to efficiently do codecs."

There's not much Google can do to stop sites from loading libjxl.wasm.

More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp.

The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity, Krita, Facebook, Shopify, Cloudinary, Intel, Nvidia, the VESA DisplayHDR Chairman) telling them they're making a terrible decision and is one of the most-starred and most-commented-on issues of all time for Chromium.

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

You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere.

"and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp."

Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl.

The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. Jyrki is a Googler. Jon is at Cloudinary. Luca is also at Google.

If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case.

Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?

I mean, seriously. You can disagree with the decision, but your argument that they have no idea what they are doing WRT to JPEG-XL seems pretty silly - the only company who arguably has any better idea would be cloudinary.

»they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?« The problem is that they do have the people with expertise but those were not asked. For example, the AVIF team at Google does not have the expertise — they have proven that publicly (there was a AVIF vs JXL comparison thing that got put out) and later on an response they gave to Sneyers (the response got shared on Discord).

Phrasing this like "well Google must know best because they employ some subset of the people that worked on JXL" when the entire rest of the industry has been very overwhelmingly pro-JXL isn't very convincing. Also my point wasn't "Google doesn't know what they're doing", it's that internal politics at Google are probably a factor in them basically being the only opposition to a standard that has been gaining support significantly faster than WebP or AVIF (both much older formats at this point) ever did.

> Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?

It's not the expertise of your employer that is in question but the morals.

Now that Apple supports it, people will want it.

Relevant thread, for those who’re curious: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Firefox came to the conclusion they didn't really care too so it's not just Google that is iffy about it. With Apple pushing it now... maybe that will change things in the long run?

Firefox has next to zero marketshare (unfortunately and despite my best efforts to get people to use FF). There was never any chance that Mozilla was going to waste their very limited resources attempting to be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.

>never any chance that Mozilla was going to waste their very limited resources

Mozilla is many things, but "limited resources" Mozilla is not.

That is if they would stop paying their CEO their entire coffer, anyway.

>be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.

The exact opposite mentality was how Firefox and then Chrome usurped the throne from Internet Explorer. Firefox is never going to usurp anything again so long as Mozilla is content to play second and third fiddle.

I don't disagree but unfortunately that's the state of Mozilla at the moment.

Mozilla had already implemented it in Firefox Nightly before coming to the neutral conclusion in the standards process.

Can't it be enabled via an extension? Similar to how media players support third party codec.

Not really.

AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).

This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.

Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.

It can be, but not perfectly.

Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/?utm_sour...

Chrome: https://chrome.google.com/webstore/detail/add-jxl-support/kh...

Reply on news.ycombinator.com