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

171–180 of 319 posts

Re: Is WebP really better than JPEG?

#171

Post by realityking »

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…

Contentful person here - what could we do to make your experience better?

Feel free to shoot me an email if you don’t want to respond here. rouven _at_ contentful _dot_ com

Re: Is WebP really better than JPEG?

#172

Post by TylerE »

moring wrote: post #144
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.

All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't h…

You don't have 15 year old binaries linking against an 18 year old version of libwebp.

Re: Is WebP really better than JPEG?

#173

Post by jws »

moring wrote: post #117
JimDabell wrote: post #112

Earlier quoted context omitted.

You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.

If transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.

I did some proof-of-concepts ages ago (October 2010) exploring different ways of embedding a PNG alpha channel in JPEG application specific fields to have 100% JPEG compliant files which web browsers could display with transparency. It worked just fine.

If you want transparent JPEGs on your web page that works.

Back then the number of GETs was really important, so stuffing the mask into the JPEG made sense. Now with our HTTP/3 and QUIC world that isn't such a big deal.You might be better off just using a CSS mask image.

Re: Is WebP really better than JPEG?

#174

Post by floatingatoll »

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…

I did some reading of the PNG specification and it may be possible to take advantage of Adam7 interlacing (8 passes total) and scanline filtering (several methods) to write out an image where the scanlines of 'known to be blurry' areas contain only 1 pass of image data and 7 passes of highly-compressible scanlines with filters that generate blur at decode-time.

Doing this formally at scale would require the compositor and the encoder to cooperate, as the encoder would benefit greatly from having access to both the 'blurred' and 'unblurred' areas without the blur filter having been applied to the former, as it could then construct low-fidelity, low-bandwidth, visually pleasing blur for the 'blurred' segments.

This exceeds my ability to write PNGs by hand and it certainly exceeds the bounds of what most people think 'an encoder' should be capable of doing, but at least it presents a path forward. I'll post to HN someday if I ever somehow manage to do this.

Re: Is WebP really better than JPEG?

#175

Post by imtringued »

cptskippy wrote: post #169
jonny_eh wrote: post #135

Earlier quoted context omitted.

WebP also supports animation, and is clearly more efficient than GIF.

What's the benefit of WebP over something like h264? Most sites today just convert uploaded GIFs to MP4 or GIFV.

Or just use .webm without audio.

Re: Is WebP really better than JPEG?

#177

Post by surround »

JimDabell wrote: post #112
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…

You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.

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

Re: Is WebP really better than JPEG?

#178

Post by wizzwizz4 »

TylerE wrote: post #172
moring wrote: post #144

Earlier quoted context omitted.

All that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't h…

You don't have 15 year old binaries linking against an 18 year old version of libwebp.

No; you just have no compatibility whatsoever.

Re: Is WebP really better than JPEG?

#179

Post by duaoebg »

jandrese wrote: post #164
rndgermandude wrote: post #145

Earlier quoted context omitted.

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

Shouldn't those patents be expiring soon? Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.

It’s too compute intensive

Re: Is WebP really better than JPEG?

#180

Post by felixfbecker »

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…

The only image format I can think of where you can encode a blur applied to some part of the image is SVG
Post reply on HN