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

51–60 of 283 posts

Re: Google unkills JPEG XL?

#51

Post by xnorswap »

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

At 600DPI that's over a marathon in each dimension.

I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.

I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash:

    Number of A4 pages=0.0625 square meters per A4 page * 784 square miles   =13,200 A4 pages.
No Gemini, you can't equate meters and miles, even if they do both abbreviate to 'm' sometimes.

Re: Google unkills JPEG XL?

#52

Post by dpark »

simonw wrote: post #16
ocdtrekkie wrote: post #3

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.

Having key browser implementers not involved in the standards processes is what lead us to the W3C wasting several years chasing XHTML 2.0.

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 retrospect very unimportant stuff.

“Hey, we need to be able to build applications.”

“Ok, but first we need compound documents.”

There was one group who thought they needed to build the web as Microsoft Word and another that wanted to create the platform on which Microsoft Word could be built.

Re: Google unkills JPEG XL?

#53

Post by dralley »

pornel wrote: post #36

AV2 is in the works, so I guess we'll have AVIF2 soon, and another AVIF2 vs JPEG XL battle.

There's no particular reason for an image format based on video codec keyframes to ever support a lot of the advanced features that JPEG XL supports. It might compress better than AVIF 1, but I doubt it would resolve the other issues.

Re: Google unkills JPEG XL?

#54

Post by Akronymus »

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

what does pyramidal mean in this context?

Re: Google unkills JPEG XL?

#56

Post by fwip »

xnorswap wrote: post #51
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

At 600DPI that's over a marathon in each dimension. I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space. I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash: Number of A4 pages=0.0625 square meters per A4 page * 784 squ…

Wolfram alpha is the better calculator for that sort of thing.

Re: Google unkills JPEG XL?

#58

Post by izacus »

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.

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.

Re: Google unkills JPEG XL?

#60

Post by dpark »

xg15 wrote: post #41
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.

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.

Post reply on HN