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

261–270 of 283 posts

Re: Google unkills JPEG XL?

#261

Post by LeifCarrotson »

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…

Using a naive rectangular approximation (40x10^6m x 20x10^6m - infinite resolution at the poles), that's a map of the Earth with a resolution of 37mm per pixel at the equator. Lower resolution than I expected!

Re: Google unkills JPEG XL?

#262

Post by jfindper »

SquareWheel wrote: post #243
jfindper wrote: post #172

Earlier quoted context omitted.

Indeed, you're making my point. SquareWheel implied that Mozilla doesn't count as an "other party" because they are aligned with Google on this specific topic. My comment was pointing out that just because they are aligned on this doesn't mean they are aligned on everything, so Mozilla is an "other party". And, as you have reinforced, Google and Mozilla are not always in alignment.

I made no such implication. Mozilla is certainly an other party, and their positions on standards hold water. They successfully argued for Web Assembly over Native Client, and have blocked other proposals such as HTML Import in the Web Components API. They are still a key member of the WHATWG. The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid. I personally see no re…

>>"[...] support the web standards as determined by other parties."

>"Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's"

If this isn't an implication that Mozilla isn't an other party, than I'm not sure what you were trying to say with "Which other parties?".

Whatever you meant to say, it read as an implication that Mozilla just does what Google does so Mozilla isn't really an "other party".

Re: Google unkills JPEG XL?

#264

Post by GoblinSlayer »

miladyincontrol wrote: post #236
CharlesW wrote: post #130

JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere. That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will ev…

Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format. But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use. Real world usage paints a very different picture. JXL not only has better compression rates at equivalent qualities for sane settings, it…

>Real world usage paints a very different picture.

You don't even know how bad is real world usage of image formats. https://preview.redd.it/wga92ab6li4g1.jpeg?width=828&format=...

Re: Google unkills JPEG XL?

#265

Post by __patchbit__ »

fwip wrote: post #56
xnorswap wrote: post #51

Earlier quoted context omitted.

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.

Grok 4.1 beta finds the answer: approximately 33.1 billion pages.

Re: Google unkills JPEG XL?

#266

Post by UltraSane »

otabdeveloper4 wrote: post #241
UltraSane wrote: post #214

Earlier quoted context omitted.

Because a language happily letting you try to access an array index far past its end isn't stupid at all.

If this was a real problem then you could have just `s/[]/at()/g` across your codebase and called it a day. But you all don't even bother to do that, so I guess it's not actually a problem in practice.

C doesn't have any protection for accessing out of bounds. It does zero bounds checking behind the scenes. Which is actually really, REALLY stupid. And when all computers are connected to the internet this is disastrous.

Re: Google unkills JPEG XL?

#268

Post by majora2007 »

leosanchez wrote: post #35
majora2007 wrote: post #31

Earlier quoted context omitted.

That's interesting, I absolutely hate PDF. Lack of metadata for collecting, format is difficult to support, doesn't layout well on mobile, and very limited customization (like dark mode, changing text size, etc). Only benefit is browsers have built-in support for the format.

One thing I like about PDF is the annotations (notes & highlights) are embedded in the PDF itself. That is not the case for EPUB files, each EPUB reader stores annotations in its own proprietary format.

Very true, I just rolled out annotations for Kavita (a self-hosted book/comic server) and epub doesn't have the ability to store it in the file (although Kavita has a no-modification policy).

Although for cases like Kavita, storing in the file would be problematic if multiple users want their own annotations without concerns of data leaking.

Re: Google unkills JPEG XL?

#269

Post by majora2007 »

swiftcoder wrote: post #45
majora2007 wrote: post #31

Earlier quoted context omitted.

That's interesting, I absolutely hate PDF. Lack of metadata for collecting, format is difficult to support, doesn't layout well on mobile, and very limited customization (like dark mode, changing text size, etc). Only benefit is browsers have built-in support for the format.

> Lack of metadata for collecting PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...

I haven't seen this in the real world or the tooling to back it up. Currently, Calibre is the only software that writes metadata that pulls from online sources.

I'm sure Adobe Acrobat also supports, but that's not used in the scene.

Re: Google unkills JPEG XL?

#270

Post by CharlesW »

miladyincontrol wrote: post #236
CharlesW wrote: post #130

JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere. That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will ev…

Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format. But no its not remotely competitive with JXL, the only benchmarks it trades blows are ones with laughably low quality settings beyond what any user would ever use. Real world usage paints a very different picture. JXL not only has better compression rates at equivalent qualities for sane settings, it…

> Yes AVIF is better at compressing than jpeg and even webp, that should be taken for granted given its a newer format.

Yes, and it turns out that "somewhat better compression efficiency" basically doesn't matter. The ecosystem matters a lot, though — Apple's support of JXL in ProRAW moved the needle 1,000× more than whatever efficiency advantages JXL may have.

A couple ecosystem challenges for JXL that I see is that (1) it has no video story and (2) it's five years behind AV1 in terms of having a hardware encode/decode story (I'm assuming it will have one), and by that time it'll be competing with AV2.

> AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.

They're apples and oranges, which is part of my frustration about the post we're discussing. The industry has clearly aligned behind AV1 as a universal, open, royalty-free image/video distribution format, and is now working on version 2 (AV2). That all happens regardless of JXL's fortunes.

I firmly believe that JXL will find "conscious success" as an authoring and intermediate file format, but that makes it more of a TIFF competitor. For distribution, JXL's "unconscious success" as a distribution format looks like another output format for Cloudflare Images, Cloudinary, Fastly Image Optimizer, etc.

Post reply on HN