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

251–260 of 283 posts

Re: Google unkills JPEG XL?

#251

Post by theandrewbailey »

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…

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

At 1080p, a 100k AVIF image is good enough to serve on a webpage. The same image as a 100k JXL will (probably) look unacceptible.

Source: every year or so, I compile the latest encoders and play around with encoding my blog's images with AVIF and JXL. Smaller AVIF images look ok, but the equivalently sized JXL images look way worse, so I gladly serve AVIF. (And before you accuse me of re-encoding lossy to lossy images, most images I test with are game screenshots stored as PNGs.)

Re: Google unkills JPEG XL?

#252

Post by account42 »

PaulHoule wrote: post #113
NoMoreNicksLeft wrote: post #92

Earlier quoted context omitted.

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.

It's also kind of pointless to add that to PDF when HTML already exists and the only real reason for PDF is if you want a fixed layout.

Re: Google unkills JPEG XL?

#253

Post by flir »

aidenn0 wrote: post #207
flir wrote: post #22

Earlier quoted context omitted.

An image of earth at very roughly 4cmx4cm resolution? (If I've knocked the zero's off correctly)

Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator). No projection of a sphere on a rectangle can preserve both direction and area.

I admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.

Re: Google unkills JPEG XL?

#254

Post by account42 »

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.

What you call wasting several years, I call saving us from years of pointless churn.

Re: Google unkills JPEG XL?

#255

Post by Longhanks »

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…

> is enshrined as an Apple image default

What? iPhones and other Apple devices take HEIF photos, where does Apple claim AVIF as its image default?

Re: Google unkills JPEG XL?

#256

Post by encom »

aniviacat wrote: post #247
izacus wrote: post #235

Earlier quoted context omitted.

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

They don't need to, they're free to become IE6. I don't think it's irrational to be upset when a (near-)monopoly browser holds back useful features. Even if said browser is provided for free.

They are IE6. They have near total market dominance, and dictate web standards. It's a very comparable situation to IE6 days.

Re: Google unkills JPEG XL?

#257

Post by throwawaymobule »

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…

Compared to an average jpeg encoder, or something like mozjpeg?

Re: Google unkills JPEG XL?

#258

Post by bmacho »

stingraycharles wrote: post #211
geokon wrote: post #210

Earlier quoted context omitted.

If it's reversible, why not just store as JPEG XL and then convert back when it's served? Does it take a lot of processing time?

Isn’t that what the comment you’re replying to is suggesting?

I think GP only wants to convert images back for users with legacy browsers, not for everyone. So converting 100% of the images needs more compute money than the amount of storage money it saves, but only converting ~1% of the images on-the-fly would be worth it financially.

Re: Google unkills JPEG XL?

#259

Post by ksec »

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…

>Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.

So basically JXL is only being pushed to Chrome within Google because GCP have large clients that benefits from this and want this to be default.

Re: Google unkills JPEG XL?

#260

Post by chrismorgan »

hxtk wrote: post #215
shmerl wrote: post #204

Good, but mass adoption is a lot slower in sites than in browsers it seems. It's like pulling teeth making sites to actually support even AVIF which is already widely supported in browsers. A ton of inertia even on sites like GitHub and GitLab. Try using AVIF on Wikipedia? Tough luck. Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet. Side note - comparing JPEG XL and AVIF fea…

There’s also the issue of non-browser support. I recently advocated for replacing some GIFs with WEBM because WEBM was faster to encode and took up 3% as much space. Technically it sounded great. Then we talked to users. It turns out some users wanted to embed moving pictures in Word documents, which you can only do with a GIF because it’s an image format that happens to move, so Word treats it as an image (by render…

Animated images were such a mistake.
Post reply on HN