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

231–240 of 283 posts

Re: Google unkills JPEG XL?

#231

Post by plantain »

von_lohengramm wrote: post #222
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…

> JXL's theoretical maximum image size is bigger. This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or we…

I have no idea what you are talking about. I archive petabytes of space imagery with libjxl on maximum compression, effortlessly.

Re: Google unkills JPEG XL?

#232

Post by asddubs »

shevy-java wrote: post #93

"in favor of the homegrown and inferior AVIF" I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif. I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is. As for JPEG XL - I think the problem here is ... Google. G…

jpeg-xl seems to do the best being successively re-saved, which is important on the web

https://www.youtube.com/watch?v=w7UDJUCMTng

Re: Google unkills JPEG XL?

#233

Post by swiftcoder »

shadowgovt wrote: post #68
Akronymus wrote: post #54

Earlier quoted context omitted.

what does pyramidal mean in this context?

Replicated at different resolutions depending on your zoom level. One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.

Except in the case of a format like JPEG, there is no duplication - higher layers are used to "fill in the gaps" in the data from lower layers.

Re: Google unkills JPEG XL?

#235

Post by izacus »

ipdashc wrote: post #182
izacus wrote: post #136

Earlier quoted context omitted.

That sounds like an even more request for someone to do for free, doesn't it?

It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?

Cool, but why does that mean they need to write a codec for you for free?

Re: Google unkills JPEG XL?

#236

Post by miladyincontrol »

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 does so with faster encoding and decoding, while also supporting progressive decoding leveraging image saliency.

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

Re: Google unkills JPEG XL?

#237

Post by foresterre »

mdriley wrote: post #228
philistine wrote: post #146

Earlier quoted context omitted.

If that's their plan, I predict another situation exactly like this one where Google decides that removing support is the best move forward. Careful, BMP, Chrome is out to get you!

Happy to report the BMP work is actually being done by our friends on the Edge team at Microsoft! https://chromium-review.googlesource.com/c/chromium/src/+/72...

This actually seems to use the encoder/decoder from the Rust image crate (1), which would bring the opportunity for more memory safe formats once BMP would be accepted.

(1) https://crates.io/crates/image

Re: Google unkills JPEG XL?

#238

Post by LtWorf »

UltraSane wrote: post #165
theoldgreybeard wrote: post #117

Earlier quoted context omitted.

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

It is a very big one and eliminating it is a huge improvement in security. You can then spend more time fixing all the other sources of security problems.

https://lwn.net/Articles/1048446/

Re: Google unkills JPEG XL?

#239

Post by gonzalohm »

refibrillator wrote: post #202

One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched. Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG. Only know this because we have tens…

What's the point of transcoding? You still have to store the original DICOM right? That's probably the bulk of the cost

Re: Google unkills JPEG XL?

#240

Post by ncruces »

usrnm wrote: post #85
izacus wrote: post #58

Earlier quoted context omitted.

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.

Are you familiar with the rule of two?

https://chromium.googlesource.com/chromium/src/+/main/docs/s...

No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced.

A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.

Post reply on HN