WebP, a new image format for the Web

Thursday, September 30, 2010

As part of Google’s initiative to make the web faster, over the past few months we have released a number of tools to help site owners speed up their websites. We launched the Page Speed Firefox extension to evaluate the performance of web pages and to get suggestions on how to improve them, we introduced the Speed Tracer Chrome extension to help identify and fix performance problems in web applications, and we released a set of closure tools to help build rich web applications with fully optimized JavaScript code. While these tools have been incredibly successful in helping developers optimize their sites, as we’ve evaluated our progress, we continue to notice a single component of web pages is consistently responsible for the majority of the latency on pages across the web: images.

Most of the common image formats on the web today were established over a decade ago and are based on technology from around that time. Some engineers at Google decided to figure out if there was a way to further compress lossy images like JPEG to make them load faster, while still preserving quality and resolution. As part of this effort, we are releasing a developer preview of a new image format, WebP, that promises to significantly reduce the byte size of photos on the web, allowing web sites to load faster than before.

Images and photos make up about 65% of the bytes transmitted per web page today. They can significantly slow down a user’s web experience, especially on bandwidth-constrained networks such as a mobile network. Images on the web consist primarily of lossy formats such as JPEG, and to a lesser extent lossless formats such as PNG and GIF. Our team focused on improving compression of the lossy images, which constitute the larger percentage of images on the web today.

To improve on the compression that JPEG provides, we used an image compressor based on the VP8 codec that Google open-sourced in May 2010. We applied the techniques from VP8 video intra frame coding to push the envelope in still image coding. We also adapted a very lightweight container based on RIFF. While this container format contributes a minimal overhead of only 20 bytes per image, it is extensible to allow authors to save meta-data they would like to store.

While the benefits of a VP8 based image format were clear in theory, we needed to test them in the real world. In order to gauge the effectiveness of our efforts, we randomly picked about 1,000,000 images from the web (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without perceptibly compromising visual quality. This resulted in an average 39% reduction in file size. We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image.

To help you assess WebP’s performance with other formats, we have shared a selection of open-source and classic images along with file sizes so you can visually compare them on this site. We are also releasing a conversion tool that you can use to convert images to the WebP format. We’re looking forward to working with the browser and web developer community on the WebP spec and on adding native support for WebP. While WebP images can’t be viewed until browsers support the format, we are developing a patch for WebKit to provide native support for WebP in an upcoming release of Google Chrome. We plan to add support for a transparency layer, also known as alpha channel in a future update.

We’re excited to hear feedback from the developer community on our discussion group, so download the conversion tool, try it out on your favorite set of images, and let us know what you think.

84 comments:

Baz said...

There are some good differences in file size but the WebP images do look flatter with duller colours. These would be better suited on mobiles with slower connections.

Colin Scroggins said...

Would love to see some examples with composite text over photo images to evaluate the difference between WebP, JPG, and PNG in that area.

Bob Hazard said...

Chromium Web Server please

Nikolay Matsievsky said...

It seems ff you just optimize these images (w/o format changing) you can get -25...30% in size. So I don't see here any significant achievement.

Dokuro said...

does anyone know about the efforts to add support for webp to programs like the Gimp.

randall said...

Will Google ever lend a hand to JPEG-XR? Isn't it now royalty-free too, and supported by another (beta) browser?

http://code.google.com/p/chromium/issues/detail?id=56908

Also, on Chrome for Mac, WebP images in the gallery appear brighter/more saturated than their JPEG counterparts (e.g., check out the football player image -- the blue background and "XLI" on the player's shirt are brighter and more saturated).

Maybe providing both images as PNGs would fix it, or there's some gamma/saturation-related mistake in the conversion pipeline.

unxed said...

And what about animation support, like in GIF or APNG?

Jens Alfke said...

I don't think the problem is a lack of better formats; it's lack of adoption by browsers and graphics tool vendors. Consider JPEG2000, which is quite a lot better than JPEG but hasn't seen any appreciable use despite being available for a decade.

I was hoping this announcement was going to be of a format that lets multiple images be combined together in one file so they can be fetched in a single HTTP request. I know people already do "spriting" to accomplish this, but it's a pain to do and requires changes to the site's CSS. It would be nice to have a way to do this transparently (sic).

Rodrigo Kumpera said...

What's wrong with JPEG2000? It does a lot better than JPEG 89.

Coloroke said...

Great effort, but a few comments.

The 39% file size reduction... I presume it is the average improvement over the entire suite of 1M images, right? In this case the improvement is far less impressive than it sounds because I bet the standard Jpg would be 20% improvement over the exact same suite (because of its compression advantage over most PNGs and GIFs). Please clarify.

As for alpha support... I am not sure whether it is needed for a lossy format. A lossy image with transparency can be quite ugly at the boundary!

Nobu said...

Either the WebP images in the gallery took longer to download (unlikely), or they take a good bit more CPU time to de-compress, because they took a lot longer to load than the JPEG images...maybe this will improve with GPU acceleration?

Troy said...

Nobu: the "WebP images" are really the JPEG files as re-encoded with the WebP coder, then converted to PNG files. They loaded more slowly because the PNG files are substantially larger. They need to be PNG files because the PNG format is a loss-less format and your browser does not yet display WebP.

Darren Kovalchik said...

I have to agree with Randall and Jens. With several other formats already available which offer similar advantages, what we need is better browser support not another format to deal with. With two competing successors to JPEG and no real fallback options, developers will basically be forced to use neither and stick with JPEG.

Rich said...

Why not use this effort to support JPEG2000 natively in WebKit? JPEG2000 already offers a 50% reduction in file size over JPEG, already supports alpha channels, and already supplies a lossless mode if you'd rather compete with PNG, and is already used in several non-browser markets.

junksblogger.com said...

this is definitely worth paying attention to..

Kroc Camen said...

Size limit of only 16383x16383? This seems very limited given 25+MP cameras these days—and increasing. I would have hoped for you to just have pushed JP2 adoption into critical mass.

sarreq said...

since the spec sheet link is broken, what colorspaces are supported, is alpha transparency supported (my 2nd biggest question) and how long till WebP starts making it into browsers, or image viewers and editors (THE biggest question)?

Nobu said...

Troy: Ah, that makes sense, I guess.

Would be nice if they put a note somewhere on the gallery that said as much. ;-)

Dominic said...

The examples page is lame... you can take the same jpeg images and save them with a higher compression level and get effectively the same reduction in file size.

For example I took "10.jpg", a 1.1 meg file, adjusted the jpeg compression and got it down to 189k with no visible loss of quality. That's an over 80% reduction in file size and I didn't have to change the file format.

The Web doesn't need a new file format, especially one that doesn't really do anything substantively different. WebP is no different than JPEG with a higher compression setting as the default.

Austin said...

@ Baz: If I had to guess, this would be because the color profiles in the JPEGs were lost somewhere in the JPEG -> WebP -> PNG conversion process.

teko said...

Comparative Study of WebP, JPEG and JPEG 2000: http://code.google.com/speed/webp/docs/c_study.html

Read the FAQ page for more info: http://code.google.com/speed/webp/faq.html

Lena said...

The promise of future alpha channel transparency support makes WebP a winner for me. PNG-24 are enormous, and obviously PNG/GIF-8 is unusable for many image types.

I'm also seeing brighter oranges and a bit greater contrast in the night image in Mac Chrome for the WebP images. I prefer this colorshift, personally...is webP displaying a broader color space derived from jpgs originally saved to display sRGB-IEC61966-2.1?

It would be helpful to see a side-by-side comparison of JPEG compressed to match the filesize of corresponding WebP images - I suspect this would convey the potential benefit rather dramatically.

darkflame said...

Would be useful to add built in 9-patch support;
http://developer.android.com/reference/android/graphics/NinePatch.html

Matt said...

The colours in the example gallery are substantially different, this is a major problem especially for photography if you're trying to convince people this is better than JPEG. We need to be moving towards better colour management/profiling in browsers, not worse!

Also, do I understand correctly that those example images are re-saved from the original JPEG, in effect double lossy compression? Why not convert both from the same lossless source and compare that way?

darkflame said...

Also, regarding alpha channel-support; why not arbitrary channel support? While the webtoday is starting to make good use of alpha.

If we are building a format for the future too, maybe it would be nice to be able to have RA/GA/BA channels? I'm sure lots of inventive webeffects could be done with them. Possible one day we could even have channels for distorting the background, refraction style effects.

Obviously each channel you add would multiple up the space taken. But it should be possible to construct a slick, small format that has optional extra channels.

In short; If we are to have a new format, lets build it for the next 20 years and not just the next 5.

Paramendra Bhagat said...

The engineering accomplishment might be the easy part. Adoption might be the hard part. There still are people whose ISP is AOL. Most people who use IE use some primitive version.

JMG said...

Nice idea...
You should have support for WebP in "standard" image tools like Picasa, Gimp (as said by Dokuro), Paint.Net, PhotoShop...
Being supported in web browser is nice but we must be able to create those images...
Or you can force some websites (Blogger, ...) to convert those images when they are saved.

John Muccigrosso said...

JPEG2000.

war59312 said...

JPEG XR FTW!

Unless you, Google, releases a WordPress plug-in right now to convert all images on your blog to the WebP format. ;)

abales said...

@darkflame

I agree, 9-patch support would be great.

I'm not sure if that belongs in an image format though, maybe it could support the metadata and provide it to renderers.

johnprattchristian said...

like the sound of that! :)

Dethe Elza said...

This would be much more exciting if they were converting to diffusion curves (http://artis.imag.fr/Publications/2008/OBWBTS08/). One image format that compresses well, and scales to different sizes and resolutions without dithering. That would be worth pushing browser adoption for.

Mark said...

What's wrong with JPEG XR?

KupoKoMaPa said...

https://www.imagemagick.org/subversion/jpeg/trunk/README

FILE FORMAT WARS
================

The ISO JPEG standards committee actually promotes different formats like
JPEG-2000 or JPEG-XR which are incompatible with original DCT-based JPEG
and which are based on faulty technologies. IJG therefore does not and
will not support such momentary mistakes (see REFERENCES).
We have little or no sympathy for the promotion of these formats. Indeed,
one of the original reasons for developing this free software was to help
force convergence on common, interoperable format standards for JPEG files.
Don't use an incompatible file format!
(In any case, our decoder will remain capable of reading existing JPEG
image files indefinitely.)

Fabio said...

Did you consider the
DLI Image format?

Thomas said...

Why do we need an image format specifically for the Web, can't we use this at other places as well? I understand the Web probably has the most pressing need for smaller Images, nevertheless we should be able to use this new format everywhere and the name is misleading.

CD Simpson said...

You guys really should talk to FreeDesktop when doing this kind of thing. Or not; it's not like we got any communication over WebM either. (Protip: Don't expect people to implement these formats in GPU drivers without talking to GPU driver authors first.)

Also, optipng can crunch random PNGs down with roughly the same improvements you're seeing -- losslessly! The More You Know. :3

Fred Truter said...

I propose we go even further and make a proper progressively downloading image format.

Read more on my blog

Emmanuel said...

Google is starting to do the same mistake that MS:
Thinking that they do everything better than the rest of the world, and try to push their own technology to everybody.

JPEG2000 is better in low compression,
much better in high compression,
better in transparency, support loseless compression, is already supported by some browsers and graphic softwares...

flameonarium said...

may be it's future, but may be it's just another fail.

SydneyBlue120d said...

Why don't You propose this format for future Digital Cinema specification revision? Ref: http://en.wikipedia.org/wiki/Digital_cinema
http://www.dcimovies.com/

igitur said...

'WebP' doesn't exactly roll off the tongue. An easier pronounced format would go a long way to making it popular.

tudza said...

When I took steps to stop the loading of the various Google tools for statistic reporting and bringing up ads I found the vast majority of web pages loaded much faster.

This WebP business is just throwing us a bone.

Gábor said...

It's indeed flatter and i don't like this. But it would be great to speed up the network with replacing jpg/png images with webP leaving the choice to download (or change on a page to) the original jpg/png files with greater details. But it would lead to more disk usage on servers.

Thomas said...

There is a difference in file size but the quality is not that good. If you look at this images you can see this colors are changing from JPEG to WebP.

I agree with @randall

zjs.name said...

Have you considered putting together a small test to demonstrate to users that they can't tell the difference?

It seems like a simple "pick image that looks better" game that displays a random image in both JPG and a WebP formats side-by-side, tracks the number of each selected by the user, and displays a running percentage would be fun enough to be used.

Ideally, users would realize that they can't tell the difference, which would hopefully improve perception of the new format and its adoption.

Abe said...

Packing the assets could speed things up, independently of the image format used. I wrote about it here http://314bits.com/blog/2010/10/make-the-web-faster-zip-it/

Today, to watch one website we have at least two types of fragmentation. On a higher level, our browser can make a hundred requests just to view one web page. This could be just one request, either by packing assets in one file, or by allowing the browser to request multiple assets at once. At a lower level, I read a problem is IPv4. Each request is answered by tons of small packets, maybe too small for today's Internet. This is a hard one to solve.

A thought: if the decoding of images in all browsers was more "plug-in like" we could experiment with letting browsers understand new image formats.

Witek Baryluk said...

Sorry, but this is bad idea. Please use something based on wevelets, like JPEG200, it have better compresion and better quality.

The advantage of 30% of WebP can be easly done in (standard) JPEG by using larger blocks than 8x8 (in webm it is 16x16 right?). It is very bad idea imho to use motion picture compression to compress still images.

Gaz said...

I'd like to see:

1. 3D images, just two images bundled together in the same file to be rendered by the client.

2. Floating point image formats for HDR images, both 64-bit and 128-bit formats. In a few years time we'll laugh at the low dynamic range of today's JPEG images.

3. Built-in mipmaps, offsets and an entire image pyramid broken into tiles at each level. I can host a ten gigabyte image and the client can steam just the visible parts, maybe the smallest tile for use as an icon. The resource looks good and uses minimal bandwidth no matter how big the image is or how small the screen is.

A format with those would be truly future-proof.

macewan said...

On the iPad jpg images loaded, all of them, before any of the webp images.

Mike said...

Why not add support for _simple_ animation? Then you could aim to replace not just JPEG, but also GIF (also in light of plans to add a lossless option to VP8).

jkent said...

If I can get lossy AND alpha, I'd be set!

royiavital said...

I think supporting JPEG Would be much better.
It's there, it's an open standard and it is great.

Developex said...

before the windows executable theres no sense to even mention this.

nharding said...

It would be worth adding simple image animation similar to animated gif (much more lightweight than embedding a video file), with simple timing and delta images. So frame 1 = WEBP format, frame 2 = multiple x-y position, w-h data and also x-y,w-h copy to x1-y1 (w1-h1 to allow simple scaling). With looping and variable timing.

Vladimir said...

I'm agree with those who said that simple transferring video compression techniques to still images will not provide an opportunity to use all possible methods to improve compression and SNR. Although, more deep and detailed analysis of already existing compression techniques is needed. Simple comparison of JPEG images recompressed with WebP is not enough, does not matter 1M images were used or 100M images. Anyway, would be interesting to take a look at the WebP spec to understand what are exact technologies proposed to use and to see what are the limitations.

Witek Baryluk said...

PGF format looks much better I would say.

Fast, good quality, no artifacts, good compression, progressive download, optional alpha channel, mutiple modes, open source, free.

MrTAZ said...

A Stéréoscopic integration with only diff of pictures(compressed) soon ?
And to WebM too ?
That will be so cool !
I'd like deposed a patent for this...

jpblock82 said...

First off, I think the WebP images look better thab their jpeg counterpart..

Secondly... just for fun, I downloaded one of the webP images via my droid 1... and the format says png...sup with that??

ron said...

Boy this sure seems like a rather clueless plan. Emmanuel said it best: "Google is starting to do the same mistake that MS: Thinking that they do everything better than the rest of the world, and try to push their own technology to everybody."

There is indeed a huge need for a more modern file format to be adopted throughout the industry but this sure doesn't look like it brings much to the table relative to other stuff that's already out there. Considerations for HDR, multi-channel support, progressive downloading, etc., etc. are ALL critical.

By proposing this without considering all of these things Google has just set the industry back, not moved it forward.

kidjan said...

Your comparison methods leave much to be desired. First, PSNR is a bad metric that should not be used, and its usage is particularly egregious here considering the WebM encoder was optimized for PSNR.

A better approach would be SSIM. An even better approach would be to manually collect mean opinion scores.

Second, recompressing JPEG images like that is definitely not kosher. Your results are almost undoubtedly skewed due to the natural artifacting JPEG compression creates in their images.

Of course, this doesn't mean WebP isn't better--but if you are really being honest with people, you should retally the data using an MS-SSIM metric (note the output needs to be interpreted logarithmically) and only lossless source material (PNG, BMP, etc.)

randall said...

Second what kidjan said. I don't know about PSNR vs. SSIM, but recompressing JPEGs isn't a good way to do a comparison. (And something's up with the colors, as several have mentioned.)

Kent said...

I would have liked to see Google support JPEG XR instead. I noticed they didn't provide any quality/size comparisons between WebP and XR, only the older JPEG and JPEG 2000 formats.

Barry said...

This comment has been removed by the author.

Barry said...

Dominic:

That doesn't make any sense, there IS a visible loss of quality if you're compressing it that much. The idea behind WebP is that you can have a high quality image, with a smaller file size than a jpeg of the same quality. The very nature of lossy formats makes it so that the more you compress it, the worse it looks.

To be honest, I hate the jpeg format, even with the quality setting set to 70-90 I can see artifacts (90 only if I compare it side by side with a lossless copy.) This is the exact reason why I save any pictures I take/make in the .png format-- It provides great quality, with file sizes only slightly larger than a high quality jpeg.

andrecassal said...

as a designer i need much more than just another format, i need one single format for: raster, vector, 9-scale, alpha, animation with alpha, any way for labeling parts of the image to be able to "sprite" like image.png#tool, photoshop filters???, 3d images, dynamic textured images.
And I'd like all that edit ready, to be able to edit right in the browser. And of course, smallest size possible.

Roberto Colnaghi Junior said...

Just curious about how would mobile browsers (iPhone, Blackberry, ...) or even IE behave when finding these new images.

robUx4 said...

Why go for RIFF when WebM is already EBML which offers the same extensibility be can reduce the general overhead even more

Magnesus said...

For those who say they shouldn't use JPEG images as source for recompression - keep in mind that 99% photos on Internet are recompressed JPG images.

TECNO MUNDOS said...

Muito bom!
Isso sera muito bom pois fara as páginas da web carregarem mais rápido.

Jessie said...

we're not interested in yet another new lossy image format with a dorky name like webp, google! what we ARE interested in is you making a patch for webkit to support the animation extention in png, and to support PGF, a superior, faster, and most of all patent-free and open lossy image format.

lazyweb said...

You designers are a bunch of dicks. Wow.

Steven said...

I'm going to try this one and I will see if it works for me. Thank you for sharing this one at least I will have something to do. :)

http://www.filecure.com/open/File-Extension-PNG/

Jackie said...

Sites will run faster and picture storage decreases saving on space without sacrificing quality!
Sounds great!
The only downside is waiting on everyone to adjust for compatibility..but I still can't wait! Trying it out asap!

xoxo
Jackie
www.jackiesjungle.com

talamus said...

Please support alpha channel and HDR.

David D said...

Can anyone tell me how I can make it so that the navigation buttons are more visible. In my current setup these buttons are barely visible. Any assistance in this matter would be greatly appreciated.

Yogi said...

well let browser start supporting this formating then only we will be able to use it

Drako said...

jpblock82 said...

First off, I think the WebP images look better thab their jpeg counterpart..

Secondly... just for fun, I downloaded one of the webP images via my droid 1... and the format says png...sup with that??

October 1, 2010 12:38 PM

Keep in mind guys as a previous poster mentioned, the images on the demo page are .png because webp isn't supported by your browser yet, they are just giving you a comparable example.

What I would like to see if this in a beta with images compressed from source using various methods to do a REAL comparison

openid said...

Kroc Camen said...
Size limit of only 16383x16383? This seems very limited given 25+MP cameras these days—and increasing. I would have hoped for you to just have pushed JP2 adoption into critical mass.
---
You do know that a 16383x16383 image is about 269MP, right?

whc said...

In your test image "http://en.wikipedia.org/wiki/File:09-Station_Sign.JPG", the WEBP file contains significantly more detail in the sign than the original JPG. Are WEBP's enhanced to remove edge noise and JPG artifacting?

Vince said...

Sounds a bit early in the lifecycle for me to want to covert my jpg collection to WebP. Also, as some others have mentioned, having a single format that will allow compression, transparency, simple animation, tagging/EXIF, etc., would be awesome. I'm sure there are some large-scale projects that can make use of this now, but I'll wait on this one for a while to see where it goes. Right now I'm ok with JPG, PNG and Gif.

kidjan said...

<< For those who say they shouldn't use JPEG images as source for recompression - keep in mind that 99% photos on Internet are recompressed JPG images. >>

Not the point: if you're testing how well a codec works, it's really not a valid test to use pre-compressed material. It's running the same material through another JPEG encode, which will skew the results due to JPEG's block-splitting algorithm.

Dror Gill said...

I don't understand why you need a proprietary format to reduce file size. My company developed JPEGmini technology which has a 2X advantage in compression over WebP, and is fully standard JPEG compliant - www.jpegmini.com.

David_SM said...

All great but converting from other image files over to WebP MUST preserve ALL metadata available on the files. If it doesn't... good try, but give us something else, because we won't use it.
Photoshop's save for web/devices option is terrible because strips all metadata from the files, and that makes the files smaller indeed... but not really appropriate for web use. Who wants to put image files online without metadata?
Again, if the conversion to WebP preserves metadata could be great, but if it doesn't... we won't use it. Not good.