Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is WebP really better than JPEG?

siipo.la

Post reply on HN
Print view View original

201–210 of 319 posts

Re: Is WebP really better than JPEG?

#201

Post by pseudosavant »

vernie wrote: post #185
rokweom wrote: post #155

Earlier quoted context omitted.

It's the same situation with VP9. It's supposed to be a competitor to HEVC, but in reality lack of serious psychovisual optimizations in any of the publicly available encoders make it at best on par with x264 compression-wise, while being significantly more computationally expensive. Its only appeal is that it's royalty-free, but since all devices that support VP9 decoding also support h.264, is it really worth it?

Using VP9 recently has really made me appreciate how great x264 is both in terms of quality and speed.

The quality of encoders have a much bigger effect on whether or not a codec is 'good' or not. LAME, mozjpeg, and x264 are great examples.

MP3 is competitive with AAC and far more compatible, if you use LAME. Same with JPEG and WebP, or x264 and VP9. All 3 of those encoders deliver higher quality AND better encoding speed than their competitors.

Switch encoders before you switch formats.

Re: Is WebP really better than JPEG?

#202

Post by jjoonathan »

Andrex wrote: post #190
surround wrote: post #177

Earlier quoted context omitted.

WebP also supports animation, which is important because GIFs are notoriously large.

As a point of data, Animated PNG is finally (as of ~2019) supported natively among all major browsers. https://caniuse.com/#search=animated%20png Edit- I was unaware the recently-announced Safari 14 Technical Preview adds support for WebP too! Making both formats viable for all browsers, finally.

Ooh, does that mean that slack supports WebP now?

Update: nope. Maybe another year :(

Re: Is WebP really better than JPEG?

#203

Post by blattimwind »

willglynn wrote: post #187
jandrese wrote: post #181

Earlier quoted context omitted.

That's kind of scary for something developed in the 90s. It was originally run on Pentiums, K6s, PPC 604s, and the like and it's still too expensive for a Ryzen 7?

Yep. There's a ton of data dependencies, where e.g. you can't begin decoding the next bit until you've finished decoding the current bit. It's all about progressive decoding so there's multiple passes over each group of wavelet coefficients, accessed in a data-dependent sequence. Each wavelet transform involves accessing and interleaving the same 2D arrays in both row- and column-oriented fashions. These design decis…

> These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.

Arguably not a good choice for the year 2000, either, considering that all high performance CPUs at that time were out-of-order, superscalar and deeply pipelined.

Re: Is WebP really better than JPEG?

#204

Post by kccqzy »

floatingatoll wrote: post #68
Eric_WVGG wrote: post #12

I just relaunched a website that makes extensive use of photographic collages that necessitate alpha backgrounds. They were previously shipping "retina-grade", multi-megabyte images all over, a typical page load could easily reach 25mb. I managed to refit it with ` ` tags using WEBP as well as JP2. The latter was a great deal of trouble, it appears that "the community" (notably Gatsby and Contentful) are very happy t…

On iOS, any screenshot taken while iOS background blur is active will balloon from 0.15MB to 15.0MB, because iOS uses PNG for screenshots and blurred backgrounds are apparently irreducible by PNG. Does the WebP format permit bounded areas of an image to be represented at lower fidelity with a smooth blur, so that the blurred-background effect can be stored and retrieved using fewer pixels and a blur algorithm rather…

At that point you might as well use something like PDF, where you can choose exactly what image format you need for each region. Put a JPG as the blurred background, then put a transparent PNG as the foreground for text and buttons in your screenshot.

Re: Is WebP really better than JPEG?

#205

Post by microcolonel »

wnoise wrote: post #132
microcolonel wrote: post #67

Earlier quoted context omitted.

> I bring this both to point out that there is a very valid reason to use WebP over JPEG — alpha blending — and that this entire field is still a gigantic mess. Yeah, you can do manual alpha masking in webkit, but it's freaky and stupid.

Full blending, or just masking? i.e. can alpha values take on the full range from 0-1, or are they limited to full on or full off?

Looks like mask is standard now. In Webkit it is behind the -webkit-* prefix, and it only implements mask-image (which is what you want anyway).

-webkit-mask-image does exactly what you're looking for (poorly) :+ )

The other way to do it is SVG, but if you want that to be data efficient, you generally end up with three HTTP requests at two levels for a single image, or you have base64 and it has to be gzipped or it's larger.

Re: Is WebP really better than JPEG?

#206

Post by ubercow13 »

chrismorgan wrote: post #160
ksec wrote: post #103

Earlier quoted context omitted.

And that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1] https://github.com/google/brunsli

What has AOMedia to do with this? That alliance is what has made AV1 (and thus AVIF), which is clearly superior to JPEG. AOMedia had nothing to do with WebP (though Google is a member, and WebP is based on VP8, and AV1 is based in part on VP9 which was the successor to VP8).

Is it better? The AVIF examples in the article look even worse than the WebP ones

Re: Is WebP really better than JPEG?

#207

Post by acdha »

rndgermandude wrote: post #145
TylerE wrote: post #127

Earlier quoted context omitted.

How? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.

Because JPEG 2000 was essentially a patent-covered mess that nobody wanted to touch

That was a little of it but the patents expired years ago. The big blockers I saw were basically that it was a very complex format with a specification behind a paywall and no good open-source implementation or test suite. Interoperability was bad until a couple of years ago and it took significant amounts of complex code to make it fast enough to use.

They've subsequently improved that — OpenJPEG is quite good now https://github.com/uclouvain/openjpeg — but probably missed the window for adoption barring a major upset, which is a shame because it's a very powerful codec and has some neat tricks like progressive decoding (imagine if you could have one file in storage and your responsive design simplify specified the HTTP range requests to get for successively large resolution images?). You could ship it in a browser using WASM but I think the browsers are — not without cause — being really reluctant to add new formats and the ensuing security risks without a good reason, and without browser support no format will be more than a niche.

Re: Is WebP really better than JPEG?

#208

Post by jerryX »

gruturo wrote: post #106
ksec wrote: post #103

Earlier quoted context omitted.

And that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1] https://github.com/google/brunsli

Absolutely. Simply unscrewing the Huffman stage from the bottom of JPEG and replacing it with a more effective, modern lossless stage kills webp's gains and does not incur in generation loss - the image is pixel accurate to the source jpeg. You'll probably know this already, but Brunsli made it into the JPEG XL standard. I'm quite happy about it!

JPEG XL uses this new ANS coding as e.g. zstd: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems

Re: Is WebP really better than JPEG?

#209

Post by SiVal »

ksec wrote: post #103
gruturo wrote: post #86

Every time I run an image comparison, the webp version looks worse and yet Google insists it's the same quality. It's baffling. Even if the above were just an individual... bafflement? and not an actual issue, the size savings really don't seem worth the compatibility hassle, the extra manpower/workflow complexity to support 2 formats, the additional storage (and caching) caused by this duplication. And the above is…

And that is the reason why I dont like Open Media Alliance in General. Not only does the best JPEG encoder perform as good if not better than the best WebP encoder. With a JPEG Repacker [1] JPEG file size could easily be 20% smaller. If you have to support a new format with relatively little benefits, why not just support using the repacked instead. [1] https://github.com/google/brunsli

I thought the JPEG people were supposed to have JPEG XL [1] out by now, and it was supposed to be the open standard for JPEG's next generation. Anyone know what's happening there?

[1] https://en.wikipedia.org/wiki/Joint_Photographic_Experts_Gro...

Re: Is WebP really better than JPEG?

#210

Post by ubercow13 »

zmix wrote: post #66

I wonder, why nobody mentioned Patrice Bellard's BPG[1]. It is based on HEVC and can be supported in any browser via a Javascript. From his website: BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are: * High compression ratio. Files are much smaller than JPEG for similar quality. * Supported by most Web b…

Isnt' Javascript single threaded? Seems a terrible way to do image decoding.
Post reply on HN