Lossless and Transparency Encoding in WebP
Thursday, November 17, 2011
Labels: webp
In September 2010 we announced the WebP image format with lossy compression. WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index. We received lots of feedback, and have been busy improving the format. Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling. Today, we introduce a new mode in WebP to compress images losslessly, and support for transparency – also known as alpha channel – in both the lossless and lossy modes.
With these new modes, you can now use WebP to better compress all types of images on the web. Photographic images typically encoded as JPEG can be encoded in WebP lossy mode to achieve smaller file size. Icons and graphics can be encoded better in WebP lossless mode than in PNG. WebP lossy with alpha can be used to create transparent images that have minimal visual degradation, yet are much smaller in file size. Animations compressed as GIFs can use animation support in WebP.
New lossless mode
Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads.
New transparency mode
Today, webmasters who need transparency must encode images losslessly in PNG, leading to a significant size bloat. WebP alpha encodes images with low bits-per-pixel and provides an effective way to reduce the size of such images. Lossless compression of the alpha channel adds just 22% bytes over lossy (quality 90) WebP encoding. Smaller alpha overhead means richer images on webpages.
You can find a more detailed compression study for these modes here and sample images in the WebP-Gallery. The bit stream specification has not been finalized, and the encoding and decoding implementations have not yet been optimized for processing speed. We encourage you to try it out on your favorite set of images, check out the code, and provide feedback. We hope WebP will now handle all your needs for web images, and we're working to get WebP supported in more browsers.
19 comments:
SqTH said...
And what about the APNG format ?
November 18, 2011 1:38 AM
Vikas said...
Clarification w.r.t APNG: WebP format do support Animation frames, represented as individual image chunks in RIFF container.
November 18, 2011 2:07 AM
sep332 said...
November 18, 2011 6:40 AM
Devon Govett said...
Is there a spec for the lossless format yet?
November 18, 2011 6:44 AM
Jyrki said...
Alpha-encoding (within the context of lossy rgb) can be either lossless or lossy, but when lossy, it is lossy in a different way than the rgb image, for example 0 and 255 values are always preserved exactly.
November 18, 2011 7:04 AM
Dag Ågren said...
This looks pretty great!
I am slightly disappointed by the lossless format using Huffman encoding, though, that seems sort of archaic. Why not use the arithmetic coder that VP8 already uses? You'd think that would give you a slight compression ratio boost.
Also, is there some reason that the alpha and lossless formats are apparently compressed differently? Does the lossless compression not work that well on typical alpha channels?
November 18, 2011 7:26 AM
Pascal said...
Dag,
consolidating the various tools is part of the ongoing experimentation work. Goal is to re-use as much as possible of the existing (to reduce format complexity) without sacrificing the accrued compression efficiency.
Huffman is one of the target, definitely.
As for alpha lossless vs lossy, note that lossless mode makes explicit use of whole R,G,B,A quadruplets (if just for palettisation. But also, it exploits cross-channel correlations). Lossy, on the other hand, compresses RGB and A separately at possibly different quality levels.
Both modes have their usefulness. Big transparency gradients (shadows e.g.) can tolerate some loss and are better suited for lossy-alpha compression, for instance. Graph-like source (chart, etc) can achieve better lossless compression when RGBA is treated as a whole, due to the small number of color values.
November 18, 2011 8:09 AM
adrien said...
You need to compare to optipng's output, not pngcrush's. optipng gives better results.
November 18, 2011 8:22 AM
Dag Ågren said...
Good to hear you're planning on using the existing encoders. Like I said, I'd expect it to actually improve compression.
What I meant with the alpha question was that the linked short description seems to describe that lossless and lossy alpha both use their own compression method ("zlib-like") rather than using the same algorithm as the regular lossless compression. Is that right, or just a misunderstanding?
November 18, 2011 9:28 AM
Unknown said...
PNGQuant can do lossy PNG+alpha compression too. It's in the same league as WebP:
http://pngmini.com/vs-webp/
November 18, 2011 11:13 AM
asunto_vuokralla said...
November 18, 2011 3:23 PM
Skeuomorph said...
Is transparency specified as pre-multiplied or straight alpha? If pre-multiplied, is there some guarantee made that color will be <= alpha, if the original data before lossy compression was that way? Some hardware (ATI/AMD specifically), can produce bad results if color is > alpha, when doing pre-multiplied alpha blending in some cases. Internally, for those cases, it does a divide by alpha, which wraps (rather than clips), then it does straight-alpha blending, so one must always ensure that color is <= alpha to avoid the wrapping).
November 18, 2011 4:27 PM
Urvang said...
@ Skeuomorph:
Transparency is stored as a separate alpha channel (and not pre-multiplied), so that image appears correctly on different backgrounds.
November 18, 2011 10:32 PM
Skeuomorph said...
@Urvang, I realize the alpha is stored separately. The question is, is it expected that the color has been pre-multiplied by the alpha or not? If it has not, then it's referred to as 'straight' alpha. If it has, then it's referred to as 'pre-multiplied' alpha (or sometimes 'associative' alpha). I know the terminology is confusing, because it's the color that's different.
In both cases, it can be used on different backgrounds. The difference is that for straight alpha, the blend formula is:
result = bg * (1-fga) + (fg*fga)
and for pre-multiplied alpha it's:
result = bg * (1-fga) + fg
So, which is it?
PNG is straight alpha. TIFF can be either, depending on some tag. Almost everything else assumes pre-multiplied alpha.
November 18, 2011 11:32 PM
Urvang said...
@ Skeuomorph:
Ahh... sorry for not being clear there.
To clarify, WebP has straight alpha (just like PNG).
November 19, 2011 12:00 AM
Anon4Eju7yrE said...
I use http://pngnq.sourceforge.net/ for optimizing my PNGs. It's similar to pngquant, although I had the impression it gives even smaller and better results.
It's a palettized RGB8 with alpha, a mode that many people don't seem to know about.
It's not losless - it relies on reducing the number of colors. But it makes a pretty good optimization for the web.
Many other PNG quantiziation tools don't handle alpha very well.
November 19, 2011 1:21 AM
Anselm Hannemann said...
Any plans to implement responsive image-sizes to WebP? This is a big discussion in w3c mailing list and the web community and, in fact, we need a image format which can serve different resolutions like video-formats can do.
How about this in WebP? This would be the killer-feature for the format :-)
November 19, 2011 1:43 AM
Pascal said...
Skeuomorph:
pre-multiplied alpha might make it harder to compress the 'alpha' plane, since few masking alpha values can lead to a lot of different final values once pre-multiplied.
November 21, 2011 9:49 AM
Oliver @ AnonSphere said...
When is chrome (opera, others) able to display transparency and animation?
November 21, 2011 3:34 PM
Post a Comment