Real world analysis of google's webp format versus jpg • Hacker News Board

Re: Real world analysis of google's webp format versus jpg

#21

Post by chc » Fri, Oct 01, 2010, 7:59 PM UTC

bstrong wrote: post #14

To my eye, webp reduces compression artifacts at the expense of losing detail (this is especially visible in the portrait example). Another way to accomplish a similar effect without requiring a new file format would be to apply a selective gaussian blur (or another de-artifacting filter) to highly compressed jpegs before displaying them. Of course, no one does that because the trade-off is generally not considered t…

Compression artifacts are loss of detail. Applying any kind of blur filter to an image that had compression artifacts would result in more loss of detail (and applying it strongly enough to remove the artifacts would pretty much obliterate any recognizable details).

Re: Real world analysis of google's webp format versus jpg

#22

Post by astrange » Fri, Oct 01, 2010, 8:12 PM UTC

chc wrote: post #21

bstrong wrote: post #14

To my eye, webp reduces compression artifacts at the expense of losing detail (this is especially visible in the portrait example). Another way to accomplish a similar effect without requiring a new file format would be to apply a selective gaussian blur (or another de-artifacting filter) to highly compressed jpegs before displaying them. Of course, no one does that because the trade-off is generally not considered t…

Compression artifacts are loss of detail. Applying any kind of blur filter to an image that had compression artifacts would result in more loss of detail (and applying it strongly enough to remove the artifacts would pretty much obliterate any recognizable details).

Compression artifacts add noise via coefficient rounding, just like audio codecs add noise instead of "removing sound you can't hear". However, encoders with poor psy-optimization (i.e. not x264) usually choose blurry quantizations that don't add much noise but also remove the original detail.

Also, the deblocking filter in VP8/H264 is nothing but a selectively applied blur that hides previous compression steps. It works pretty well.

Re: Real world analysis of google's webp format versus jpg

#23

Post by bstrong » Fri, Oct 01, 2010, 8:13 PM UTC

chc wrote: post #21

bstrong wrote: post #14

To my eye, webp reduces compression artifacts at the expense of losing detail (this is especially visible in the portrait example). Another way to accomplish a similar effect without requiring a new file format would be to apply a selective gaussian blur (or another de-artifacting filter) to highly compressed jpegs before displaying them. Of course, no one does that because the trade-off is generally not considered t…

Compression artifacts are loss of detail. Applying any kind of blur filter to an image that had compression artifacts would result in more loss of detail (and applying it strongly enough to remove the artifacts would pretty much obliterate any recognizable details).

Actually, while applying a blur does obviously eliminate detail, you can retain most of the important detail with a selective blur. Give it a try in gimp and see for yourself. The default selective gaussian settings work pretty well for de-artifacting, and the loss of detail arguably isn't much worse that that in webp compression. Some of the commercial de-artifacting tools use different techniques (I don't know what they are) that result in even less loss of detail.

Re: Real world analysis of google's webp format versus jpg

#24

Post by ergo98 » Fri, Oct 01, 2010, 8:41 PM UTC

gojomo wrote: post #17

ergo98 wrote: post #13

Those who don't learn from history are doomed to repeat it. This is a futile effort by Google and will go no where. If they somehow managed to chop file sizes by 90% or more, it would have a small chance (it still wouldn't be guaranteed, as in the era of CDNs and caching and large pipes, static images just aren't a big concern). Instead they've marginally chopped file sizes in only certain scenarios, while adding num…

Give it 15 years. If it's free and better, then at some point, all browsers and tools will have it as an option. If CPU keeps improving faster than bandwidth, and free codebases keep growing, then an option to create webP on the fly (or downconvert to jpg for older clients) will become effortless. In the meantime, if early adopters get a slightly better web experience -- that's a win for Google. They want more margin…

The will be no early adopters.

Re: Real world analysis of google's webp format versus jpg

#25

Post by gojomo » Fri, Oct 01, 2010, 8:48 PM UTC

ergo98 wrote: post #24

gojomo wrote: post #17

Earlier quoted context omitted.

Give it 15 years. If it's free and better, then at some point, all browsers and tools will have it as an option. If CPU keeps improving faster than bandwidth, and free codebases keep growing, then an option to create webP on the fly (or downconvert to jpg for older clients) will become effortless. In the meantime, if early adopters get a slightly better web experience -- that's a win for Google. They want more margin…

The will be no early adopters.

Not even Chrome users hitting Google's own websites? At Google's scale, the savings from that alone might pay for the R&D that went into this.

Re: Real world analysis of google's webp format versus jpg

#26

Post by sp332 » Fri, Oct 01, 2010, 9:18 PM UTC

scott_s wrote: post #15

sp332 wrote: post #8

Earlier quoted context omitted.

You asked How else would you construct an objective test? And my answer is, just make sure you're being fair in measuring the same thing the encoders are optimising for.

If I only test the optimal circumstances for a new thing, then I have done a terrible job at trying to understand the consequences of adopting it.

On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" .... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

--Babbage (1864), Passages from the Life of a Philosopher, ch. 5 "Difference Engine No. 1"

You can't reasonably use an encoder optimized for PSNR and then "ding" it for producing output with bad SSIM, or vice-versa.

Re: Real world analysis of google's webp format versus jpg

#27

Post by scott_s » Fri, Oct 01, 2010, 9:41 PM UTC

sp332 wrote: post #26

scott_s wrote: post #15

Earlier quoted context omitted.

If I only test the optimal circumstances for a new thing, then I have done a terrible job at trying to understand the consequences of adopting it.

On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" .... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. --Babbage (1864), Passages from the Life of a Philosopher, ch. 5 "Difference Engine No. 1" You can't reasonably use an encoder optimized for PSNR and then "ding" it for producing o…

I'm not familiar enough with the image encoding algorithms (and the tradeoffs they are faced with) to comment on that, specifically. But I've done enough research with systems in general to disagree with your statement. No matter what I optimize a system for, it's always fair for someone to test it under adverse conditions. If we're going to adopt something, we need to know its limitations.

Further, my understanding of Google's intent with webp is that it is being offered as a replacement to jpeg. In that case, even if it's optimized for one thing, it's not just fair but necessary to see how it works under all other things.