new | show | ask | jobs Github

est 3 hours ago

> removed a while ago and them seemingly not being interested in supporting it

Removed because no one from Google benifits from supporting it then.

Re-added because someone could get a promotion by supporting it now.

▲

andruby 3 hours ago | parent | next [-]

> nobody benifits from supporting it

Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?

▲

thesuitonym 2 hours ago | parent | next [-]

What a silly question, Google has never cared about users.

▲

est 3 hours ago | parent | prev [-]

Yes, I meant Google employees/stakeholders.

They always abandon shit like this.

	▲	alwillis 2 hours ago \| parent [-]
		There were obviously some internal politics going on—Google joined the Alliance for Open Media, a consortium of the who's who of the media/tech industry: Apple, Facebook, Microsoft, Amazon, Netflix, Nvidia… the list goes on. They supported AVIF as the next generation image format. Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland. Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.

▲

crote 3 hours ago | parent | prev [-]

Removed because having yet another giant C codec was a huge risk, re-added because the PDF Association chose JXL as their next image format so anyone rendering PDFs (including browsers) is now required to have it.

▲

nananana9 an hour ago | parent | next [-]

"Required" is a strong word. More than enough people use Chrome as a PDF viewer that if Google decided to not support JXL, you'd see ~0 PDFs with it.

Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.

I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.

▲

est 3 hours ago | parent | prev [-]

> Removed because having yet another giant C codec was a huge risk

Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.

How many man-hour effort does it take to create jxl-rs ?

https://github.com/libjxl/jxl-rs/graphs/contributors

	▲	Gander5739 2 minutes ago \| parent [-]
		But Google is responsible for jxl-rs. https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...