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

111–120 of 283 posts

Re: Google unkills JPEG XL?

#111

Post by jeffbee »

dpark wrote: post #108
jeffbee wrote: post #32

Earlier quoted context omitted.

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.

The web was designed from the start to solve this problem and you can serve alternate formats to user agents which will select the one they support.

Re: Google unkills JPEG XL?

#112

Post by Finnucane »

NoMoreNicksLeft wrote: post #92
PaulHoule wrote: post #8

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.

The worst epubs are bad because some jackass took some poorly OCRed text and dumped it into the format. The best (retail) epubs are on par with the best PDFs except you don't have to pan-and-scan to read a fucking page. It just reflows. For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied b…

I oversee ebook production for a uni press so I am familiar with how the proverbial sausage is made. Which is why I still mainly prefer print books.

Re: Google unkills JPEG XL?

#113

Post by PaulHoule »

NoMoreNicksLeft wrote: post #92
PaulHoule wrote: post #8

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.

The worst epubs are bad because some jackass took some poorly OCRed text and dumped it into the format. The best (retail) epubs are on par with the best PDFs except you don't have to pan-and-scan to read a fucking page. It just reflows. For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied b…

There is a mode for PDF files that reflows and is logically similar to EPUB in that there is an HTML-derived data model and you have images embedded in the PDF much as they are embedded in the EPUB. Of course if you hate how complex PDF is it is more to hate.

Re: Google unkills JPEG XL?

#114

Post by spookie »

chimeracoder wrote: post #49
MutableLambda wrote: post #46

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.

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

Well, the first public implementation dates to 2020. And, the Cpp choice is obvious, simpler integration with the majority of existing image processing libs, tools and utilities. Not to mention GUI toolkits.

Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!

Re: Google unkills JPEG XL?

#115

Post by otabdeveloper4 »

EMM_386 wrote: 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'…

> ...but now in le Rust!!1

I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.

Re: Google unkills JPEG XL?

#116

Post by dpark »

aleph_minus_one wrote: post #103
dpark wrote: post #60

Earlier quoted context omitted.

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.

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.

Re: Google unkills JPEG XL?

#117

Post by theoldgreybeard »

EMM_386 wrote: 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'…

because memory safety is the only attack vector, as we all know

Re: Google unkills JPEG XL?

#118

Post by dpark »

jeffbee wrote: post #111
dpark wrote: post #108

Earlier quoted context omitted.

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.

The web was designed from the start to solve this problem and you can serve alternate formats to user agents which will select the one they support.

Your statement here amounts to “you can serve JPEG XL to other browsers, just not Chrome”.

Yeah, that’s what I said.

Re: Google unkills JPEG XL?

#119

Post by JyrkiAlakuijala »

EMM_386 wrote: 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'…

This is some strange misinformation.

The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.

It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.

Re: Google unkills JPEG XL?

#120

Post by JyrkiAlakuijala »

munificent wrote: post #102
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

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.

the article includes test code and encoder code, that is not the way how we compute the decoder size

the decoder is something around 30 kloc

Post reply on HN