Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

Post reply on HN
Print view View original

181–190 of 283 posts

Re: Google unkills JPEG XL?

#181

Post by dpark »

xg15 wrote: post #150
dpark wrote: post #116

Earlier quoted context omitted.

Literally the WHATWG founders wanted to focus on web applications, which they said web authors were asking for, and they got voted down. Google was not involved in the founding of WHATWG, though certainly the WHATWG vision was better aligned with Google than with what the W3C was doing.

They only paid the salary of its chief editor (Ian Hickson) for a significant amount of time... But that's not very relevant actually. The WHATWG is more like a private arbitrator, not like a court or parliament. Their mission is to document browser features and coordinate them in such a way that implementation between browsers doesn't diverge too much. It's NOT their mission to decide which features will or will not…

This is such a bizarre response to me saying Google was not part of the founding WHATWG group. It’s like you want to have an argument but don’t have anything to argue about.

“Oh, yeah? Well they paid Hickson’s salary. And the WHATWG doesn’t matter anyway. And also Google is really powerful.”

Um, ok.

WHATWG was founded in 2004 by Mozilla, Opera, and Apple. Google had no browser at that point and didn’t hire Ian Hickson until 2005.

Google is currently a WHATWG member and clearly wields a great deal of influence there. And yeah, the 4 trillion dollar internet giant is powerful. No argument there.

Re: Google unkills JPEG XL?

#182

Post by ipdashc »

izacus wrote: post #136
ux266478 wrote: post #105

Earlier quoted context omitted.

Who is saying Google should ship the reference implementation? It's a standard, and Google has the labor to write their own implementation.

That sounds like an even more request for someone to do for free, doesn't it?

It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?

Re: Google unkills JPEG XL?

#183

Post by arccy »

josefx wrote: post #152
dpark wrote: post #52

Earlier quoted context omitted.

I kind of liked xhtml, though clearly it was not necessary for the web to be successful. I think the bigger issue is that W3C pursued this to the detriment of more important investments. Reading over the minutes for the last W3C WG session before WHATWG was announced, the end result seems obvious. The eventual WHATWG folks were pushing for investment in web-as-an-app-platform and everyone else was focused on in retro…

> and another that wanted to create the platform on which Microsoft Word could be built. Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.

that's just microsoft not being good. Google Docs exists and is pretty good.

Re: Google unkills JPEG XL?

#184

Post by Fileformat »

dralley wrote: post #162
Fileformat wrote: post #157

Earlier quoted context omitted.

I don't disagree with you, but given (A) how will Firefox ever compete? One possible way is doing things that Google and Chrome don't (can't). Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete. Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).

>Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO). Good thing they aren't? Firefox's detached video player feature is far superior to anything Chrome has that I'm aware of. Likewise for container tabs, Manifest V2 and anti-fingerprinting mode. And there are AI integrations that do make sense, like local-only AI translation & summaries, which could be a "niche feature" that people care about…

And these aren't niche/advanced features? I'm using Firefox now, and did not know about them. If I'm using them, it is only accidentally or because they are the defaults.

But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.

Re: Google unkills JPEG XL?

#185

Post by jiggawatts »

aw1621107 wrote: post #84
tensegrist wrote: post #63

Earlier quoted context omitted.

100M+ is a bit more than i would expect for an image format. have i not been paying attention

According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/…

One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else.

By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.

Re: Google unkills JPEG XL?

#186

Post by jiggawatts »

ragall wrote: post #173

Quick reminder that it's not "Google" that killed JXL before, it was the Chrome team. Jpeg XL was designed by a Google engineer (JyrkiAlakuijala here) who is not part of the Chrome team, but in Google Research in the Zurich office while the Chrome team, although it has offices all around the world, at its core is very insular and lives in the Mountain View bubble.

https://en.wikipedia.org/wiki/Conway%27s_law

Re: Google unkills JPEG XL?

#187

Post by darrenf »

lsecondario wrote: post #169
phatfish wrote: post #153

Earlier quoted context omitted.

German speakers usually have very good English, but this is one of their tells.

Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.

Wait, what? Englishman in my 50s here and I use phrases like that all the time — “I’ll be missing standup cos I’ve a GP appointment”, “leaving at lunchtime as I’ve a train to catch”, “gotta dash, I’ve chores to do”. No one’s ever said I sound German!

Re: Google unkills JPEG XL?

#188

Post by MaxBarraclough »

dgacmu wrote: post #129
MaxBarraclough wrote: post #106

Earlier quoted context omitted.

> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.

99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.

Agreed, and Google developers can probably be trusted to 'act responsibly', but too often people forget the distinction. Some Rust codebases are wildly unsafe, and too often people see written in Rust and falsely conclude it's a memory-safe codebase.

Re: Google unkills JPEG XL?

#189

Post by tkfoss »

jiggawatts wrote: post #185
aw1621107 wrote: post #84

Earlier quoted context omitted.

According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/…

One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else. By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.

Interesting approach

Re: Google unkills JPEG XL?

#190

Post by nine_k »

philistine wrote: post #146
jsheard wrote: post #48

Earlier quoted context omitted.

That's why both Mozilla and Google have predicated their JXL support on a memory-safe implementation. There's a Rust one in the works. I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.

If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!

BMP decoding may seem easy and fun (I wrote a toy decoder back in the day), but the vulnerabilities are real: https://nvd.nist.gov/vuln/detail/CVE-2025-32468

It's not the format, it's the C / C++ unfortunate baggage.

Post reply on HN