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

81–90 of 283 posts

Re: Google unkills JPEG XL?

#81

Post by fngjdflmdflg »

ocdtrekkie wrote: post #33
dpark wrote: post #27

Earlier quoted context omitted.

The other key browser implementers are also part of WHATWG. Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.

And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations. Honestly, what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform. I really think anyone who has any sort of confusion about what I commented here to take a long, hard look at their worldview.

>what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform

They don't. In general browser specs are defined via various standards groups like WHATWG. As far as I know there is no standard for what image formats must be supported on a web browser,[0] which is why in this one case any browser can decide to support an image format or not.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Re: Google unkills JPEG XL?

#82

Post by tyre »

cubefox wrote: post #21
m348e912 wrote: post #13

A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image

Yes, but unlike AVIF, JPEG XL supports progressive decoding, so you can see the picture in lower quality long before the download has finished. (Ordinary JPEG also supports progressive decoding, but in a much less efficient manner, which means you have to wait longer for previews with lower quality.)

I don’t think the issue with the exabyte image is progressive decoding, though it would at least get you an image of what is bringing down your machine while you wait for the inevitable!

Re: Google unkills JPEG XL?

#83

Post by furyofantares »

crooked-v wrote: post #78
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

It's a container format that does about a bajillion things - lossy, lossless, multiple modes optimized for different image types (photography vs digital design), modern encode/decode algorithms, perceptual color space, adaptive quantization, efficient ultra-high-resolution decoding and display, partial and complete animation, tile handling, everything JPEG does, and a bunch more.

The Linux kernel is 40M lines of code after 34 years of development.

OP might have well have said "infinite lines of code" for JPEGXL and wouldn't have been much less accurate. Although I'm guessing they meant 100k.

Re: Google unkills JPEG XL?

#84

Post by aw1621107 »

tensegrist wrote: post #63
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'…

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/libjxl/libjxl

Re: Google unkills JPEG XL?

#85

Post by usrnm »

izacus wrote: post #58
chimeracoder wrote: post #49

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.

The most popular software in question is also a giant pile of C++, btw.

Re: Google unkills JPEG XL?

#86

Post by ocdtrekkie »

dpark wrote: post #75
ocdtrekkie wrote: post #33

Earlier quoted context omitted.

And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations. Honestly, what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform. I really think anyone who has any sort of confusion about what I commented here to take a long, hard look at their worldview.

> And those implementers should make decisions, Google should be bound by the FTC to supporting their recommendations. Is your proposal essentially that Mozilla defines web standards Google is legally bound to implement them? > what's really funny here is how absolutely horrified people are by the suggestion Not horrified, but asking what the alternative is. I don’t think you’ve actually got a sensible proposal. Coop…

We have the legal force to do this. Google has already been determined to be abusing their illegal monopoly they have with Chrome. The penalty phase is ongoing, but consider that even forcing Google to sell Chrome was originally considered as a possible penalty.

Requiring Google implement the standards as agreed by Apple, Mozilla, and Microsoft is not remotely outside the realm of the legal force that could be applied.

Re: Google unkills JPEG XL?

#87

Post by SoKamil »

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.

> any substantial (non-degenerative)

Why this quality poses security issues?

Re: Google unkills JPEG XL?

#88

Post by ajcp »

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'…

-> They were concerned about the increased attack surface resulting from including the current 100K+ lines C++ libjxl reference decoder, even though most of those lines are testing code.

Seems like Google has created a memory-safe decoder for it in Rust or something.

Re: Google unkills JPEG XL?

#89

Post by cornstalks »

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'…

libjxl is is <112,888 lines of code, about 3 orders of magnitude less than you're 100M+ claim.

Re: Google unkills JPEG XL?

#90

Post by wang_li »

yread wrote: post #29
m348e912 wrote: post #13

A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image

The only practical way to work with such large images is if they are tiled and pyramidal anyway

We call those mipmaps.
Post reply on HN