Note: I originally made this comparison in 2013, and promptly forgot about it until mid-2017, when I decided to publish it here. I am fairly certain that progress has been made with both x264 and WebP's encoders since then, and will write up another comparison when I have the time.
JPEG has had incredible staying power as an image compression format. Originally ratified as a standard in 1992, JPEG saw widespread use across the world wide web, as early internet connections were low-bandwidth and loading webpages could take over a minute. As technology has progressed, formats for other forms of compression (generic data, video, and audio) have improved, but the compression of JPEG has been "good enough" that people only started to make efforts to replace it in the late 2000s.
One of the main contenders for dethroning JPEG, WebP, is now taking off, with Chrome now supporting decoding of .webp files natively. WebP is based upon the video codec VP8, which is commonly used in the .webm container for internet video.
A few years ago, Dark_Shikari (one of the main developers of x264) made a blog post comparing WebP to x264 frames, and determined that x264 was more suitable as an image format. Unfortunately that blog is no longer accessible, although you can view an archived version here thanks to the efforts of the archive.org team.
WebP as a format hasn't changed since then, but the encoder has had a lot of development put into it - Dark_Shikari was actually using libvpx, the vp8 video codec compression library, to encode single video frames as still images. Since then, Google has released a purpose-built WebP encoder and decoder, and several browsers support decoding .webp files natively.
Let's see how JPEG and WebP stack up against each other in 2013... and we'll throw in x264 intra frames for good measure, too.
For WebP, I used google's libwebp encoder (version 0.3.1), available from the official site. This is the most "official" encoder out there, as the WebP standard is being pushed by google themselves.
For x264, I used r2345 of the official builds available from the videolan website here.
Image sources used
I used 9 frames from the test video sequences made available by the Xiph Foundation, available here. These are a mix of live-action and computer-generated animation.
I encoded the JPEG images first, using -q:v 8, then reduced the resulting images with jpegtran. This gave a target filesize to aim for with the other encoders.I then used the --crf option in x264 and the -q option in libwebp to find compression ratios that would match the JPEG images as closely as possible. eventually I was able to get within ~3kB of each file's size..
Finally, all images were losslessly transcoded to PNG for comparison purposes, using ffmpeg.
|Filename||source PNG filesize (bytes)||JPEG filesize (bytes)||WebP filesize (bytes)||x264 filesize (bytes)|
Note: it appears that both the x264 and webp images have had their brightness levels affected by a colorspace conversion somewhere. However this should not affect the amount of detail shown in the images. In future comparisons I hope to fix this issue.
While JPEG offers huge compression gains when compared to the lossless compression of PNG, it still falls far behind the more modern encoders in x264 and webp. blocking can be seen on gradients, and mosquito noise near sharp edges. Fine details in the background are sacrificed to save bits. Overall, it's acceptable, but we can do better.
WebP offers a much smoother final product, with much less blocking, and greater background detail. some noise is present.
x264 also offers more detail than JPEG, while introducing some grainy mosquito noise, most likely a byproduct of psy-rd. Fine details are preserved, and there is a small amount of blocking.
WebP is still in its infancy as a compression format. There will be more improvements to make as development continues. However it is already clear that the format offers significant gains over JPEG, and as support for the format improves in browsers and other applications, I hope we can switch to WebP as a new format.
As for x264, it is an interesting comparison, even if it's not that likely to be supported as a still-image format in the future. Hopefully, the competition will become strong in the future, as having just one format for compression will stifle innovation.