

WebP in the wild - joshfraser
http://torbit.com/blog/2011/05/02/webp-statistics/

======
pornel
> After applying our standard image optimizations (stripping EXIF data,
> running smush.it, etc), the average size drops to 49k (91%). After
> converting to WebP the average drops to 22.8kb (42%)

This sounds like they've been converting JPEG to WebP. Conversion of one lossy
format to another lossy format is going to lose even more information, so the
final size is not really fair — it's a size of _lower-quality_ image.

A fair comparison would use high-quality source (uncompressed or high-
resolution image that is downsampled) for both algorithms, rather than
comparing original-to-JPEG with JPEG-to-WebP.

~~~
joshfraser
Great point, except we've compared hundreds of images are haven't been able to
detect a noticeable drop in quality.

~~~
pornel
It is possible that JPEGs could have been even smaller with no noticeable drop
in quality either.

You can't fairly compare it with recompression of JPEG to lower-quality JPEG,
as this JPEG encoding its own artifacts will amplify them.

However, compression from original to same file size or quality as WebP could
narrow gap between JPEG and WebP.

~~~
dchest
<http://code.google.com/speed/webp/docs/c_study.html>

"Three compression methods, WebP, JPEG 2000 and Re-JPEG, were applied to the
900,000 JPEG images contained in the data set. JPEG images were re-compressed
with Re-JPEG so that each was as close as possible to a target peak signal-to-
noise ratio (PSNR) value."

~~~
jacobolus
That assumes that PSNR is a good measure of perceived image quality. I don’t
buy it.

(Which isn’t to say that WebP isn’t better, but only that that analysis is IMO
severely flawed.)

------
ronaldj
The quality of WebP is interesting. After reviewing the sample images
(<http://code.google.com/speed/webp/gallery.html>) provided by Google I prefer
some of the images in WebP and some in jpeg.

~~~
joshfraser
Which images in particular are you referring to? I can't spot any difference
between most of them.

~~~
pornel
<http://www.gstatic.com/webp/gallery/2.webp>
<http://www.gstatic.com/webp/gallery/2.jpg>
<http://www.gstatic.com/webp/gallery/2.png>

In WebP man's face is heavily blurred (especially nose), orange of the kayak
is less saturated, subtle high-frequency noise on the water is gone.

I've also compared these images with my DSSIM tool[1] and WebP version was 14%
more different from original than JPEG version (admittedly it doesn't mean
that WebP looks that much worse, because good psychovisual enhancements in
image encoder could be better than DSSIM's model of perception).

Google did not optimize Huffman tables in JPEGs in their gallery, which would
make JPEGs 3-5% smaller.

WebP beats JPEG at very low bitrates where distortions are quite visible,
especially that JPEGs compression just falls apart below "good" quality, so
it's a great option for Opera Mini[2].

However, in high-quality range JPEG is pretty good and tendency to blur that
saves WebP in low-quality images becomes a problem when you want noise and
fine textures preserved.

I think we should modernize JPEG[3] instead of fragmenting image format
landscape. Just like Gif survived PNG, JPEG is here to stay. Currently WebP
doesn't even offer alpha channel, and supports less even color spaces than
JPEG, so it's not even as superior as PNG was to Gif.

[1] <https://github.com/pornel/dssim> [2] <http://www.favbrowser.com/opera-
turbocharges-opera-turbo/> [3]
[http://cbloomrants.blogspot.com/2010/10/10-08-10-optimal-
bas...](http://cbloomrants.blogspot.com/2010/10/10-08-10-optimal-baseline-
jpeg.html)

~~~
ZeroGravitas
Any thoughts on why JPEG hasn't already been enhanced to near its maximum
potential in reaction to competition from JPEG-2000 and JPEG-XR (or changes in
usage, computer power etc.)? Is it because they are targeted at the high-end
of the quality spectrum, whereas WebP seems (via it's WebM heritage) to focus
more at the lower end and typical web, rather than photography, use?

It seems like those wanting to introduce WebP and those wanting to enhance
JPEG for web use need to agree on some benchmarks/metrics to use. Either in
collaboration (as why would Google object to smaller JPEGs?) or in competition
like Sunspider vs V8 vs Kraken in javascript-land.

Whatever they come up with will have drawbacks but it'll be better than
randomly comparing a handful of images by eye. And if it's automated and open
sourced then criticisms can lead to improvements for everyone.

~~~
pornel
> Any thoughts on why JPEG hasn't already been enhanced to near its maximum
> potential in reaction to competition

I don't know. I guess it was because of computational power — 10 years ago you
had to do more speed/quality trade-offs.

Nowdays libjpeg is very very old, but it also means it's proven to be stable
and secure. This coupled with opinion that JPEG is good enough may lead to
"don't fix what's not broken" conclusion.

Also, perhaps codec developers want to do something more glorious than making
existing simple algorithm way more complicated and orders of magnitude slower
for 10% improvement?

> those wanting to enhance JPEG for web use need to agree on some
> benchmarks/metrics to use

Codec developers have worked it out - PSNR is weak, SSIM is decent, and only
large-scale human tests are definitive, but they're expensive.

~~~
ZeroGravitas
It's more complicated than simply psnr vs ssim though.

You need a large corpus of representative images (including typical PNG logos
or other non-photographic sources would apparently favor WebP over JPEG). You
need to decide target bitrates or quality levels to focus on since JPEG (at
least with current code) falls apart at the low end and loses out on the high
end. You need a specific implementation of ssim (or whatever, perhaps multiple
measures) that anyone can run, and agree on the results of. A way to auto-
generate pretty pictures summarizing results would be good too, and so on.

Basically, it's a project in itself. But perhaps like tuning JPEG, it's too
boring for people to get motivated to do it and we'll end up with
underutilised next generation tech, replacing older, but equally underutilised
tech that could have been tuned to the same level without ditching the
associated infrastructure (which seems wasteful), or we'll repeat JPEG-2000
and JPEG-XR and only get limited uptake of the new stuff and just struggle on
with the old'n'busted tech as it stands now.

On the other hand it seems like this wheel gets re-invented badly every time
someone writes a paper comparing codecs or tries to tune their own image
codec. You'd think someone would make a start on a proper repeatable process
or toolkit for building such a thing.

