Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

101–110 of 283 posts

Re: Google unkills JPEG XL?

#101
post #64

Earlier quoted context omitted.

Which standard requires support of JXL?

The PDF association apparently recently added jpeg xl to the pdf spec and indicated that it's the preferred solution for HDR content.

Then again PDF also technically supports embedded audio, video, 3D graphics, and arbitrary Javascript. If Flash hadn't died it would probably still support that too. It's a clown car format where everyone besides Adobe just tacitly agrees to ignore huge chunks of the spec.

Re: Google unkills JPEG XL?

#102
post #37

Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…

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

The article says 100K, not 100M. I'm guessing that's what the parent comment meant.

100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.

Re: Google unkills JPEG XL?

#103
post #60
post #41

Earlier quoted context omitted.

How about the users and web authors?

Saying web users should define web standards is like saying laptop users should design CPUs. They lack the expertise to do this meaningfully. Web authors? Maybe. WHATWG was created specifically because W3C wasn’t really listening to web authors though. I don’t think there are a lot of scenarios where standards aren’t driven by implementers, though. USB, DRAM, WiFi, all this stuff is defined by implementers.

> WHATWG was created specifically because W3C wasn’t really listening to web authors though.

Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.

Re: Google unkills JPEG XL?

#104

> Yes, right, “not enough interest from the entire ecosystem”. Sure. Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.

The biggest "win" for JPEG XL so far was last year's adoption by Apple for ProRAW, and prosumer photography is will likely be JPEG XL's primary mainstream use case. Pros will continue to shoot in "actual RAW", and consumers will (and this is not an insult) continue to have no interest in the technical details of the compressed media formats being used.

https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t...

Re: Google unkills JPEG XL?

#105
post #58

Earlier quoted context omitted.

> Have you seen JPEG XL source code? I like the format, but the reference implementation in C++ looked pretty bad at least 2 years ago. I hope they rewrote it, because it surely looked like a security issue waiting to happen. At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.

And yet whole of HN is VERY VERY angry because Google won't ship that pile of C++ into most popular software (and app framework) in the world.

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

Re: Google unkills JPEG XL?

#106
post #37

Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…

> 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.

Re: Google unkills JPEG XL?

#108
post #32

As a monopoly, Google should be barred from having standards positions and be legally required to build and support the web standards as determined by other parties. The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.

Nobody is stopping you from using jpegxl.

This is a vacuous statement. No one is stopping me from using JPEG XL in the same sense that no one is stopping me from using DIMG10K, a format I just invented. But if I attempt to use either of these in my website today, Chrome will not render them.

In a very real sense Google is currently stopping web authors from using JPEG XL.

Re: Google unkills JPEG XL?

#109

Earlier quoted context omitted.

It'll be in PDF sooner, and my experience is that PDF >> any other system for ebooks. I liked the idea of EPUB but when I recently installed an EPUB reader to read some files I was shocked at how awful it looked whereas for 15 years I've been reading PDF files on tablets with relish.

>and my experience is that PDF >> any other system for ebooks. Are you speaking just about technical books? Because I can’t imagine anyone trying to read a novel in epub vs pdf on a phone or epub reader and going with the latter.

I am mostly reading on a tablet, not a phone. I think if you are reading on a phone you are already screwed —- if people are “reading” on phones I think 80% of it is that you just read less.
Post reply on HN