WebP in the wild
torbit.com
torbit.com
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.
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.
"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."
(Which isn’t to say that WebP isn’t better, but only that that analysis is IMO severely flawed.)
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...
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.
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.
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.