# Google’s WebP format compresses 6% better than JPEG

This is an attempt to quantify the compression performance of Google’s WebP image format compared to that of JPEG. The method is as follows:

1. Take a large lossless image like this one and cut it up in a not too small number of large tiles. In my test, I have cropped the image a bit to get a 5,000 x 5,000 pixel image, then split it in 25 tiles of 1,000 x 1,000 pixels.
2. Compress all the tiles to the JPEG format and measure the lossiness of each one (I have used the PSNR value)
3. For each tile, compress the original using WebP with different values for the quality parameter, until for each tile you get a WebP image whose PSNR value is just as good as that of the JPEG image obtained in the previous step. What we are doing is getting images with very similar level of lossiness. PSNR values will never be the same. I have given the JPEG tiles a small advantage by requiring a better PSNR value from the WebP tiles.
4. Compute the size ratio for each pair of tiles as [size of the WebP file] / [size of the JPEG file]
5. Take the resulting ratios and compute their average and standard deviation. We can say that WebP is significantly better than JPEG iff the average plus twice the standard deviation is lower than 1, because we’ll be able to say that in 95% of the cases, the WebP image will be smaller than the equivalent (in terms of lossiness) JPEG image. If the average plus twice the standard deviation is bigger than 1, then we’ll have to say that these formats have similar compression performance. This would be a case where compression performances are not significantly different:

Results

These are the results of my test (click to enlarge):

As we can see, the average plus twice the standard deviation is below 1:

Conclusions

• According to this test, the WebP format is about 6% better than JPEG. We can say that in 95% of the cases, the resulting image will be at least 6% smaller than the equivalent JPEG image.
• Of course this test has important flaws: we have only tested one type of image (aerial orthophoto), the number of tiles is not very high (25), the lossiness of the compared images was not exactly the same, etc, but I think the result is a good indication of how these two formats compare.
• We can see that the size ratios do follow the Normal distribution pattern, so using the average plus twice the standard deviation value was not a bad idea.
• My opinion is that this is a rather poor result for the WebP format, and it will not replace JPEG as the de facto standard for image delivery on the Web.

## Discussion

### 5 thoughts on “Google’s WebP format compresses 6% better than JPEG”

1. Thanks for an interesting article. Did you compare access times at all? One of the issues I find with using jpeg with gdal is that access can be quite slow when it needs to retrieve a small window of data from a large image. It would be interesting to know how webp compares on this front.

Regards

Tim

Posted by Tim Sutton | 14/12/2010, 8:58 AM
2. Hello, thanks for your message. Uncompressing each tile was clearly slower with WebP, and I don’t think they have the ability to uncompress smalll portions of the image, as they are targeting media files (images/videos) where that feature is not very useful.

Posted by Juan Lucas Domínguez Rubio | 14/12/2010, 11:24 PM
3. Thanks for the interesting experiment and your interest in WebP. Can you try to generate a couple of different numbers?
since you’re giving a disadvantage to WebP of 2 stddev’s, can you do the same for jpeg so you can compare apples to apples? or just get rid of the 2 stddevs’, since you’re comparing averages.
You used the math correctly, by saying that in 95% of the cases, WebP will be at least 6% smaller, but the conclusion “the WebP format is about 6% better than JPEG. ” is incorrect.

also, it would be good if you try to run the numbers without “[giving] the JPEG tiles a small advantage by requiring a better PSNR value from the WebP tiles.” It’s amazing what a 0.2 or .5 dB difference does to file size.

Thanks!

Posted by Richard Rabbat | 17/12/2010, 10:58 PM