Intent to Ship: Animated WebP images

1911 views
Skip to first unread message

Urvang Joshi

unread,
Jun 28, 2013, 12:09:38 AM6/28/13
to blink-dev

Primary eng (and PM) emails

urv...@google.com

sko...@chromium.org

Spec

WebP Container Spec is part of libwebp v0.3.0 and can be accessed here:

https://developers.google.com/speed/webp/docs/riff_container


Summary

Animation support was added to WebP in v0.3.0. This patch adds the same support in Blink.

Note: We already support non-animated WebP images, so this is an incremental feature addition.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!topicsearchin/blink-dev/webp$20animation/blink-dev/Y8tRC4mdQz8


Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.


OWP launch tracking bug?

crbug.com/234777

(Bug related to implementation: crbug.com/229641)


Row on feature dashboard?

Yes.

Darin Fisher

unread,
Jun 28, 2013, 12:42:03 AM6/28/13
to Urvang Joshi, blink-dev
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

With WebP, I understand that we now send an Accept header so web sites can incrementally adopt WebP.  Does animated WebP have its own MIME type?  Or, how will sites know the difference between a browser that supports animated WebP versus one that only supports static WebP?

Thanks,
-Darin

Peter Kasting

unread,
Jun 28, 2013, 4:55:35 PM6/28/13
to Darin Fisher, Urvang Joshi, blink-dev
On Thu, Jun 27, 2013 at 9:42 PM, Darin Fisher <da...@chromium.org> wrote:
Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

This is a concern of mine too.  Animated WebP seems to use a format that is inspired by animated GIF in many ways, which worries me.  Like animated GIF, it seems to be true that you can have an arbitrarily long chain of frames which cannot be decoded correctly without first decoding the previous frame, making seeking more problematic.

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

This one I do know: the integration is just like animated GIFs.

PK 

new...@gmail.com

unread,
Jun 29, 2013, 6:48:16 AM6/29/13
to blin...@chromium.org, Darin Fisher, Urvang Joshi
I think large animations could cause performance problems because the browser tries to re-decode them again and again, for every new loop. And "large" limit is not that big, only 5MB in sum of all decompressed frames. These days, it's like half of GIFs on the internet would go over that limit. Just one such GIF on the page, and CPU's work will never stop.

The limit is hardcoded as 5242880 in  Source/core/platform/graphics/BitmapImage.cpp


P.S. I can't figure out how to make animated WebP work, even by using --experimental-webkit-features runtime flag on a just-compiled build (209277). Am I missing something?

Alpha (Hin-Chung) Lam

unread,
Jun 30, 2013, 10:51:37 PM6/30/13
to Darin Fisher, Urvang Joshi, blink-dev



2013/6/27 Darin Fisher <da...@chromium.org>

I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).

File size:

Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.

Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz 

Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.
 

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

It is implemented exactly like GIFs.

Tom Wiltzius

unread,
Jul 1, 2013, 2:02:17 PM7/1/13
to Alpha (Hin-Chung) Lam, Darin Fisher, Urvang Joshi, blink-dev
On Sun, Jun 30, 2013 at 7:51 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:



2013/6/27 Darin Fisher <da...@chromium.org>
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).

File size:

Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.

Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz 

Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.

I'd be more worried about performance implications of rendering than the over-network size (I think this is what Darin was getting at?).
 
 

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

It is implemented exactly like GIFs.

Is this intrinsic to the format, e.g. with the bad seeking characteristics Peter mentions above? Or just that's how it's implemented for now?

Do we have any hope of teaching the compositor how to run these animations? If arbitrarily-many-frames-long main-thread decodes are the only way we can implement these animations I fear we're stuck in a world where performance will never be good.

Urvang Joshi

unread,
Jul 1, 2013, 3:02:49 PM7/1/13
to Tom Wiltzius, Alpha (Hin-Chung) Lam, Darin Fisher, blink-dev
Hi all,
Some good points! Some have already been answered. To answer the rest:


On Mon, Jul 1, 2013 at 11:02 AM, Tom Wiltzius <wilt...@chromium.org> wrote:



On Sun, Jun 30, 2013 at 7:51 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:



2013/6/27 Darin Fisher <da...@chromium.org>
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).

File size:

Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.

Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz 

Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.

I'd be more worried about performance implications of rendering than the over-network size (I think this is what Darin was getting at?).
 
 

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

It is implemented exactly like GIFs.

Is this intrinsic to the format, e.g. with the bad seeking characteristics Peter mentions above? Or just that's how it's implemented for now?

WebP images have some advantages over GIF:
  • GIF has a DisposeToPrevious dispose method, which as per the GIF spec "imposes severe demands on the decoder to store the section of the graphic that needs to be saved". WebP format does not support this mode, so that rendering performance can improve.
  • In case of GIF, there is no quick way to find out if it is animated. Only when a second image data is encountered, the decoder knows that it's animated. On the other hand, WebP images have a flag indicating whether it's animated int the header itself. That way, deferred decoding can be still work for non-animated WebPs. [Update: Work is ongoing to support deferred decoding for animated images as well, but that will also help animated WebPs].
Moreover: as Adam mentioned in "Intent to implement..." thread: "supporting animation in WebP is valuable because one common use of WebP is as a transcoding target by CDNs and other intermediaries (especially for mobile).  Supporting animations lets these intermediaries transcode animated GIFs as well as other image formats."


Do we have any hope of teaching the compositor how to run these animations? If arbitrarily-many-frames-long main-thread decodes are the only way we can implement these animations I fear we're stuck in a world where performance will never be good.
 

  • There have already been efforts to make animated GIFs perform better. (e.g. https://codereview.chromium.org/14317005/ and https://codereview.chromium.org/15969015/). The same improvements are going to help animated WebPs too; and similarly any future improvements.
  • We have to accept the fact that animated images are very popular on the web and not going away anytime soon. So, if we can integrate this feature into a single universal format (WebP), we should. And, we should rather focus on improving the animation pipeline in Blink. 
 
 

With WebP, I understand that we now send an Accept header so web sites can incrementally adopt WebP.  Does animated WebP have its own MIME type?  Or, how will sites know the difference between a browser that supports animated WebP versus one that only supports static WebP?
 
The mime type for non-animated and animated WebPs is the same, in fact. However, this should not be an issue in the long run due to Chrome auto-updates.

Peter Kasting

unread,
Jul 1, 2013, 3:17:09 PM7/1/13
to Urvang Joshi, Tom Wiltzius, Alpha (Hin-Chung) Lam, Darin Fisher, blink-dev
On Mon, Jul 1, 2013 at 12:02 PM, Urvang Joshi <urv...@google.com> wrote:
WebP images have some advantages over GIF:
  • GIF has a DisposeToPrevious dispose method, which as per the GIF spec "imposes severe demands on the decoder to store the section of the graphic that needs to be saved". WebP format does not support this mode, so that rendering performance can improve.
Are you referring to the "DisposeOverwritePrevious" value in ImageDecoder.h?  If so, the GIF spec was written in a time where storing this decoded data was murderous on memory; that's no longer true, and these days, use of this method is actually a performance _advantage_, because it means frames with this method can always be discarded without affecting the decoder's ability to decode other frames.

Indeed, it's actually the DisposeNotSpecified/DisposeKeep methods (which do the same thing) that are problematic for performance, and WebP uses these.  So to answer Tom's question, yes, I believe the bad seeking characteristics of GIFs apply to WebP in general as well.

The biggest format change I can think of to improve decode performance would be to store with each frame information about what previous frames are necessary to decode in order to decode this frame.  We recently added code to our image decoders to get a conservative estimate of this, but the encoder knows enough that it could set this more accurately.
  • In case of GIF, there is no quick way to find out if it is animated. Only when a second image data is encountered, the decoder knows that it's animated. On the other hand, WebP images have a flag indicating whether it's animated int the header itself. That way, deferred decoding can be still work for non-animated WebPs. [Update: Work is ongoing to support deferred decoding for animated images as well, but that will also help animated WebPs].
Once we get to the point where we support deferred decoding of animated images, this point will be moot; even without that, I don't think this is a huge factor.
Do we have any hope of teaching the compositor how to run these animations? If arbitrarily-many-frames-long main-thread decodes are the only way we can implement these animations I fear we're stuck in a world where performance will never be good.

Long term I don't believe we will need to decode on the main thread.

PK

Alpha (Hin-Chung) Lam

unread,
Jul 1, 2013, 4:15:12 PM7/1/13
to Peter Kasting, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev

2013/7/1 Peter Kasting <pkas...@google.com>

On Mon, Jul 1, 2013 at 12:02 PM, Urvang Joshi <urv...@google.com> wrote:
WebP images have some advantages over GIF:
  • GIF has a DisposeToPrevious dispose method, which as per the GIF spec "imposes severe demands on the decoder to store the section of the graphic that needs to be saved". WebP format does not support this mode, so that rendering performance can improve.
Are you referring to the "DisposeOverwritePrevious" value in ImageDecoder.h?  If so, the GIF spec was written in a time where storing this decoded data was murderous on memory; that's no longer true, and these days, use of this method is actually a performance _advantage_, because it means frames with this method can always be discarded without affecting the decoder's ability to decode other frames.

Indeed, it's actually the DisposeNotSpecified/DisposeKeep methods (which do the same thing) that are problematic for performance, and WebP uses these.  So to answer Tom's question, yes, I believe the bad seeking characteristics of GIFs apply to WebP in general as well.

The biggest format change I can think of to improve decode performance would be to store with each frame information about what previous frames are necessary to decode in order to decode this frame.  We recently added code to our image decoders to get a conservative estimate of this, but the encoder knows enough that it could set this more accurately.

That's right. The format is deeply inspired by GIF and does not allow specifying a frame explicitly as a key frame (not needing anything before to decode that frame). This feature is critical to to Web because an image should be paused when it's outside of the viewport, discarded in memory and then when it's scrolled into view resume from an arbitrary frame. Without this feature we'll have to cache multiple frames which is not desirable. On mobile most likely the cache will be evicted. Decoding it on impl thread can help but it's still a heavy workload. 

MP4 and Matroska (WebM) containers both have this optimize-for-the-web-mode, I'd like to see such feature in Animated WebP. I'd suggest the format support this feature and the tools for generating WebP automatically inject key frames at interval by default.
  • In case of GIF, there is no quick way to find out if it is animated. Only when a second image data is encountered, the decoder knows that it's animated. On the other hand, WebP images have a flag indicating whether it's animated int the header itself. That way, deferred decoding can be still work for non-animated WebPs. [Update: Work is ongoing to support deferred decoding for animated images as well, but that will also help animated WebPs].
Once we get to the point where we support deferred decoding of animated images, this point will be moot; even without that, I don't think this is a huge factor.

That's not a huge advantage over GIF, we can now parse GIF really lightly. 
Do we have any hope of teaching the compositor how to run these animations? If arbitrarily-many-frames-long main-thread decodes are the only way we can implement these animations I fear we're stuck in a world where performance will never be good.

Long term I don't believe we will need to decode on the main thread.

FYI: The change to move decoding off main thread for animated images is under review. 
 

PK

Alpha (Hin-Chung) Lam

unread,
Jul 1, 2013, 8:40:31 PM7/1/13
to Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev



2013/7/1 Urvang Joshi <urv...@google.com>

Hi all,
Some good points! Some have already been answered. To answer the rest:


On Mon, Jul 1, 2013 at 11:02 AM, Tom Wiltzius <wilt...@chromium.org> wrote:



On Sun, Jun 30, 2013 at 7:51 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:



2013/6/27 Darin Fisher <da...@chromium.org>
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).

File size:

Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.

Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz 

Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.

I'd be more worried about performance implications of rendering than the over-network size (I think this is what Darin was getting at?).
 
 

I haven't studied the implementation. Does it integrate with the rendering system just like animated GIFs or does it work more like <video>?

It is implemented exactly like GIFs.

Is this intrinsic to the format, e.g. with the bad seeking characteristics Peter mentions above? Or just that's how it's implemented for now?

WebP images have some advantages over GIF:
  • GIF has a DisposeToPrevious dispose method, which as per the GIF spec "imposes severe demands on the decoder to store the section of the graphic that needs to be saved". WebP format does not support this mode, so that rendering performance can improve.
  • In case of GIF, there is no quick way to find out if it is animated. Only when a second image data is encountered, the decoder knows that it's animated. On the other hand, WebP images have a flag indicating whether it's animated int the header itself. That way, deferred decoding can be still work for non-animated WebPs. [Update: Work is ongoing to support deferred decoding for animated images as well, but that will also help animated WebPs].
Moreover: as Adam mentioned in "Intent to implement..." thread: "supporting animation in WebP is valuable because one common use of WebP is as a transcoding target by CDNs and other intermediaries (especially for mobile).  Supporting animations lets these intermediaries transcode animated GIFs as well as other image formats."

I really don't think it's a good idea to transcode animated GIF to animated WebP:

1. WebM compress better.

I ran transcoding GIF to WebM and WebP as 42dB PSNR. The data set was 6900 images randomly sourced from Google Image Search. On  average WebM with the same quality is 66% of Animated WebP. WebP is on average 78% of GIF. Please ask me for the data set if anyone is interested.

2. Animated WebP provides no advantage in seeking / caching over GIF.

As mentioned earlier. Animated WebP does not make seeking easier than GIF and put the same amount of cache stress. Comparing with WebM which can provide key frame index in header, it's a clear advantage over animated WebP.

3. Animated WebP is harder to decode than GIF.

The codec complexity is simply higher than GIF. There's a lot more stages in WebP, entropy coding, intraframe coding, IDCT, color space conversion, upsampling. GIF only has entropy coding.

Alpha

Elliott Sprehn

unread,
Jul 1, 2013, 8:47:33 PM7/1/13
to Alpha (Hin-Chung) Lam, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
Why support Animated WebP at all then? :)

- E 

Peter Kasting

unread,
Jul 1, 2013, 8:56:44 PM7/1/13
to Elliott Sprehn, Alpha (Hin-Chung) Lam, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev, Pascal Massimino
+CC skal for the format issue below (last paragraph).

On Mon, Jul 1, 2013 at 5:47 PM, Elliott Sprehn <esp...@chromium.org> wrote:
Why support Animated WebP at all then? :)

I don't know what the ":)" here means, but this has been discussed before.  There are a variety of environments where images are accepted but videos are not; browsers may be set to automatically play (or automatically block) videos differently than images, in a way that makes using a video resource problematic; animation support makes WebP a single format which can support basically all important functions of images (regardless of whether that's the best option from a performance perspective); etc.

I am not so opposed to transcoding as Alpha's comment seems to be.  There is simply a tradeoff: animated WebP can achieve better compression than animated GIF at the cost of potentially being more costly to decode.  I'm also not convinced animated WebP is always going to be more costly to decode than GIF; at least a few things are in WebP's favor, such as not having to look up the color values in a palette for every pixel.

If the WebP format were to include more comprehensive and accurate keyframing, we could at least attenuate the worst case decode times, and possibly improve decode speed in general.  I don't know how possible something like this is; it would have been nice to be consulted by the folks creating the WebP format spec during the process of implementing animation support, and maybe now it's too late.

PK

Alpha (Hin-Chung) Lam

unread,
Jul 1, 2013, 11:30:34 PM7/1/13
to Peter Kasting, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev, Pascal Massimino



2013/7/1 Peter Kasting <pkas...@google.com>

+CC skal for the format issue below (last paragraph).

On Mon, Jul 1, 2013 at 5:47 PM, Elliott Sprehn <esp...@chromium.org> wrote:
Why support Animated WebP at all then? :)

I don't know what the ":)" here means, but this has been discussed before.  There are a variety of environments where images are accepted but videos are not; browsers may be set to automatically play (or automatically block) videos differently than images, in a way that makes using a video resource problematic; animation support makes WebP a single format which can support basically all important functions of images (regardless of whether that's the best option from a performance perspective); etc.

I am not so opposed to transcoding as Alpha's comment seems to be.  There is simply a tradeoff: animated WebP can achieve better compression than animated GIF at the cost of potentially being more costly to decode.  I'm also not convinced animated WebP is always going to be more costly to decode than GIF; at least a few things are in WebP's favor, such as not having to look up the color values in a palette for every pixel.

I did some performance testing using the decoders in Blink. See attached patch.

Selected ~800 GIFs for transcoding. Again please ask me for the data set. I'm happy to provide.

Perf comparison:
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF

Size comparison:
* Lossy (42dB PSNR)  animated WebP on average is 86% of GIF
* Lossless animated WebP on average is 83% of GIF

I don't see much benefits transcoding GIF to animated WebP given all the factors combined. And no one has tried to optimized GIF for ~10 years.

There's two use cases for a new format for animated images:

1. For transcoding

Animated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.

2. For encoding source material

Note that a lot of GIFs use today is for encoding shot video clips. Apparently using lossless WebP to encode them will result in undesirable large files. Using lossy WebP to encode them is no better than a real video codec. Either way for this use case WebM is the best format for the job.

There are use cases where an <img> tag cannot be replaced by <video>. What about serving WebM files in <img> and internally use the video playback pipeline? This way we promote the best compression for all use cases for about the same CPU usage as lossy WebP. And it has already been optimized to decode off main thread and takes advantage of GPU acceleration.
blink.patch

Alpha (Hin-Chung) Lam

unread,
Jul 1, 2013, 11:36:58 PM7/1/13
to Peter Kasting, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev, Pascal Massimino



2013/7/1 Alpha (Hin-Chung) Lam <hc...@google.com>




2013/7/1 Peter Kasting <pkas...@google.com>
+CC skal for the format issue below (last paragraph).

On Mon, Jul 1, 2013 at 5:47 PM, Elliott Sprehn <esp...@chromium.org> wrote:
Why support Animated WebP at all then? :)

I don't know what the ":)" here means, but this has been discussed before.  There are a variety of environments where images are accepted but videos are not; browsers may be set to automatically play (or automatically block) videos differently than images, in a way that makes using a video resource problematic; animation support makes WebP a single format which can support basically all important functions of images (regardless of whether that's the best option from a performance perspective); etc.

I am not so opposed to transcoding as Alpha's comment seems to be.  There is simply a tradeoff: animated WebP can achieve better compression than animated GIF at the cost of potentially being more costly to decode.  I'm also not convinced animated WebP is always going to be more costly to decode than GIF; at least a few things are in WebP's favor, such as not having to look up the color values in a palette for every pixel.

I did some performance testing using the decoders in Blink. See attached patch.

Selected ~800 GIFs for transcoding. Again please ask me for the data set. I'm happy to provide.

Perf comparison:
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF

Size comparison:
* Lossy (42dB PSNR)  animated WebP on average is 86% of GIF
* Lossless animated WebP on average is 83% of GIF

I don't see much benefits transcoding GIF to animated WebP given all the factors combined. And no one has tried to optimized GIF for ~10 years.

There's two use cases for a new format for animated images:

1. For transcoding

Animated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.

2. For encoding source material

Note that a lot of GIFs use today is for encoding shot video clips. Apparently using lossless WebP to encode them will result in undesirable large files. Using lossy WebP to encode them is no better than a real video codec. Either way for this use case WebM is the best format for the job.

There are use cases where an <img> tag cannot be replaced by <video>. What about serving WebM files in <img> and internally use the video playback pipeline? This way we promote the best compression for all use cases for about the same CPU usage as lossy WebP. And it has already been optimized to decode off main thread and takes advantage of GPU acceleration.

Just to emphasize my worry about this use case. Please look around tumblr and almost all animated GIFs are from some kind of video clips. Using a true video codec compresses a lot better than an image codec. 

Pascal Massimino

unread,
Jul 2, 2013, 7:50:10 AM7/2/13
to Alpha (Hin-Chung) Lam, Peter Kasting, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
Hi,

On Mon, Jul 1, 2013 at 8:36 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:



2013/7/1 Alpha (Hin-Chung) Lam <hc...@google.com>




2013/7/1 Peter Kasting <pkas...@google.com>
+CC skal for the format issue below (last paragraph).

On Mon, Jul 1, 2013 at 5:47 PM, Elliott Sprehn <esp...@chromium.org> wrote:
Why support Animated WebP at all then? :)

I don't know what the ":)" here means, but this has been discussed before.  There are a variety of environments where images are accepted but videos are not; browsers may be set to automatically play (or automatically block) videos differently than images, in a way that makes using a video resource problematic; animation support makes WebP a single format which can support basically all important functions of images (regardless of whether that's the best option from a performance perspective); etc.

I am not so opposed to transcoding as Alpha's comment seems to be.  There is simply a tradeoff: animated WebP can achieve better compression than animated GIF at the cost of potentially being more costly to decode.  I'm also not convinced animated WebP is always going to be more costly to decode than GIF; at least a few things are in WebP's favor, such as not having to look up the color values in a palette for every pixel.

I did some performance testing using the decoders in Blink. See attached patch.

Selected ~800 GIFs for transcoding. Again please ask me for the data set. I'm happy to provide.

Perf comparison:
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF

Size comparison:
* Lossy (42dB PSNR)  animated WebP on average is 86% of GIF

(note: 42dB is high (_if_ you had a clean source, agreed). Either you go lossless, or you go video-style with a PSNR in the 35-37dB whereabouts)
 
* Lossless animated WebP on average is 83% of GIF

I don't see much benefits transcoding GIF to animated WebP given all the factors combined. And no one has tried to optimized GIF for ~10 years.

There's two use cases for a new format for animated images:

1. For transcoding

Animated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.

Note that if you start from the GIF as source and transcode it to WebP, you're at a disadvantage compared to
starting from the real video clip most GIFs seems to be aiming at. We provided the gif2webp tool as a bootstrap
utility, but going forward this should be avoided (working on this).


2. For encoding source material

Note that a lot of GIFs use today is for encoding shot video clips. Apparently using lossless WebP to encode them will result in undesirable large files. Using lossy WebP to encode them is no better than a real video codec. Either way for this use case WebM is the best format for the job.

Yes, there's a thin line to walk between what is a 'video', what is an 'animation', what is an 'avatar' made of few animated frames, what is a logo, etc.
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense. That being said, WebP still offers reasonable advantage over GIF (but less than WebM of course, on purpose):
you can mix lossy/lossless, you have better alpha support, have a possibility for per-frame palette, etc. Just because the tools to
leverage these is not there yet (if you stick to gif2webp) doesn't mean this format doesn't have a place inbetween static <img> and <video>.

 

There are use cases where an <img> tag cannot be replaced by <video>. What about serving WebM files in <img> and internally use the video playback pipeline? This way we promote the best compression for all use cases for about the same CPU usage as lossy WebP. And it has already been optimized to decode off main thread and takes advantage of GPU acceleration.

This is already possible right now, irrespective of WebP, and...
 

Just to emphasize my worry about this use case. Please look around tumblr and almost all animated GIFs are from some kind of video clips. Using a true video codec compresses a lot better than an image codec. 

...well, there's certainly an educational aspect to it. Some site are smarter than tumblr at using both WebP and WebM where appropriate.
For instance: www.memecenter.com

Alex Russell

unread,
Jul 2, 2013, 12:16:22 PM7/2/13
to Tom Wiltzius, Alpha (Hin-Chung) Lam, Darin Fisher, Urvang Joshi, blink-dev
On Mon, Jul 1, 2013 at 7:02 PM, Tom Wiltzius <wilt...@chromium.org> wrote:



On Sun, Jun 30, 2013 at 7:51 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:



2013/6/27 Darin Fisher <da...@chromium.org>
I'm supportive, but can you comment on the performance of the implementation? Animated GIFs are power hogs and really contribute much to slowing down the web. I'd imagine that animated WebP is superior, but by how much? How does it compare to the equivalent content packaged up in a video format?

I've done some study. I downloaded 63 cats animated GIFs from tumblr. I compared file size transcoded from GIF using Animated WebP (lossy, no alpha, constant PSNR 42dB) and WebM (VP8, constant PSNR 42dB).

File size:

Animated WebP (lossy) on average is about 38% of the same GIF. WebM (VP8) is on average is about 52.7% of Animated WebP.

Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gz 

Note I have not tested with alpha channel vs VP9. But I expect VP9 to compress even better than VP8.

I'd be more worried about performance implications of rendering than the over-network size (I think this is what Darin was getting at?).

Peter Kasting

unread,
Jul 2, 2013, 1:09:32 PM7/2/13
to Alpha (Hin-Chung) Lam, Pascal Massimino, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Mon, Jul 1, 2013 at 8:30 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
Perf comparison:
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF

I don't know what these multipliers are in reference to.  "Decoding GIF took x% CPU and decoding WebP took 1.5 * x%"?

On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense.

I don't know how to interpret this.  "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"?  I don't understand what negative consequences could possibly come from making the format as good as possible.  Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

PK

Alpha (Hin-Chung) Lam

unread,
Jul 2, 2013, 5:30:04 PM7/2/13
to Peter Kasting, Pascal Massimino, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev


2013/7/2 Alex Russell <sligh...@google.com>
On mobile devices battery life in the most important in my opinion. Once the file is loaded it will keep looping. I think this will be an important angle for improvements for designing a new codec / container.

2013/7/2 Peter Kasting <pkas...@google.com>

I don't know what these multipliers are in reference to.  "Decoding GIF took x% CPU and decoding WebP took 1.5 * x%"?

I meant lossy WebP took 260% of decoding time of GIF. Lossless WebP took on average 150% decoding time of GIF.
 

On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense.

I don't know how to interpret this.  "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"?  I don't understand what negative consequences could possibly come from making the format as good as possible.  Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

There are use cases where lossless Animated WebP will be useful, e.g. transcoding GIF, encoding clip art, etc. It will increase the chance of success if we make this format strictly better than animated GIF in both features, perf and power usage. I have made suggestions how to make it web friendly. 

I share the same fear as Pascal that animated WebP would impact WebM adoption. On top of that I fear that by introducing lossy animated WebP we're not promoting the best practice (i.e. WebM).

My concrete suggestions are:

1. We should improve the container format on Lossless Animated WebP to allow fast seeking and be more web friendly.
2. We should promote the best practice for encoding video content, i.e. WebM. There shouldn't be a lossy animated image format.

Alpha
 

PK

Peter Kasting

unread,
Jul 2, 2013, 5:35:51 PM7/2/13
to Alpha (Hin-Chung) Lam, Pascal Massimino, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Tue, Jul 2, 2013 at 2:30 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
I share the same fear as Pascal that animated WebP would impact WebM adoption. On top of that I fear that by introducing lossy animated WebP we're not promoting the best practice (i.e. WebM).

I don't think we should be trying to force authors to do something we like by refusing to provide them good alternatives.

Either the arguments for why we need an animated image format at all when we have <video> make sense, or they don't.  If they do we should make both lossy and lossless animated WebP as good as possible.  If they don't we shouldn't bother with animated WebP at all.

2. We should promote the best practice for encoding video content, i.e. WebM. There shouldn't be a lossy animated image format.

As you can guess, I disagree quite strongly with this.

PK 

Pascal Massimino

unread,
Jul 2, 2013, 6:13:00 PM7/2/13
to Peter Kasting, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
Hi Peter,


On Tue, Jul 2, 2013 at 10:09 AM, Peter Kasting <pkas...@google.com> wrote:
On Mon, Jul 1, 2013 at 8:30 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
Perf comparison:
* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF
* Lossless animated WebP on average is 1.5x of GIF

I don't know what these multipliers are in reference to.  "Decoding GIF took x% CPU and decoding WebP took 1.5 * x%"?

On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense.

I don't know how to interpret this.  "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"?

that, minus the 'adoption' part: there's a continuum of features <-> complexity, and if you keep making animated WebP 'better', you just end up with P-Frames and VP8 format (or equivalent).
 
 I don't understand what negative consequences could possibly come from making the format as good as possible.

Paraphrasing VP8 / WebM in form and intent, for instance.
 
 Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.


PK

Peter Kasting

unread,
Jul 2, 2013, 6:29:11 PM7/2/13
to Pascal Massimino, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Tue, Jul 2, 2013 at 3:13 PM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 10:09 AM, Peter Kasting <pkas...@google.com> wrote:
On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense.

I don't know how to interpret this.  "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"?

that, minus the 'adoption' part: there's a continuum of features <-> complexity, and if you keep making animated WebP 'better', you just end up with P-Frames and VP8 format (or equivalent).

I don't think what I've suggested as an addition is very much diferent from what the format does now.  It is certainly not going all the way to VP8.  So I don't think this is a very good objection to my comment.

 Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.

You are comparing apples with aircraft carriers.  JPEGs of common size take minimal time to decode and display.  64k x 64k JPEGs are extremely rare.  GIFs of common size take significant time to decode and display, such that they're one of the largest single problem sources we have w.r.t. overall renderer CPU load and responsiveness.  Animated WebP in its current form may make this worse.  This is a huge problem and it deserves attention.

You're beginning to make me feel like the people specifying WebP don't actually understand the nuts and bolts of graphics handling in Blink (or other engines, for that matter, since we want adoption by other browsers).  That is not a good place to be.

PK

Pascal Massimino

unread,
Jul 2, 2013, 7:05:49 PM7/2/13
to Peter Kasting, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
Peter,


On Tue, Jul 2, 2013 at 3:29 PM, Peter Kasting <pkas...@google.com> wrote:
On Tue, Jul 2, 2013 at 3:13 PM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 10:09 AM, Peter Kasting <pkas...@google.com> wrote:
On Tue, Jul 2, 2013 at 4:50 AM, Pascal Massimino <sk...@google.com> wrote:
We deliberately didn't make the Animated WebP format too smart (esp. for frame prediction), so as not to derail people from using <video>
when it makes sense.

I don't know how to interpret this.  "We could have made animated WebP a better format but we chose not to because we were afraid it would impact WebM adoption"?

that, minus the 'adoption' part: there's a continuum of features <-> complexity, and if you keep making animated WebP 'better', you just end up with P-Frames and VP8 format (or equivalent).

I don't think what I've suggested as an addition is very much diferent from what the format does now.  It is certainly not going all the way to VP8.  So I don't think this is a very good objection to my comment.

So, what do you have in mind as 'more comprehensive and accurate keyframing' ? We have this project of adding an 'index' chunk that would provide cues to jumping at individual frames in the an animated webp file. But, can't renderer build such an index on-the-fly while decoding, too?
 

 Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.

You are comparing apples with aircraft carriers.  JPEGs of common size take minimal time to decode and display.  64k x 64k JPEGs are extremely rare.  GIFs of common size take significant time to decode and display, such that they're one of the largest single problem sources we have w.r.t. overall renderer CPU load and responsiveness.  Animated WebP in its current form may make this worse.  This is a huge problem and it deserves attention.

Yes, but it doesn't seem to be related to WebP in particular but rather to large anims in general and habits that have grown around GIF usage.
Animated WebP's purpose is not to fix GIF (<video> can do that), and overly large anims are just a mis-use of both formats capabilities.
Actually, the other important use case foreseen for 'animated' WebP is rather having a collection of images into a single file, that does not
necessarily form an 'animation'. That'd be useful for spriting or comics, say. But that's another discussion i guess.


You're beginning to make me feel like the people specifying WebP don't actually understand the nuts and bolts of graphics handling in Blink (or other engines, for that matter, since we want adoption by other browsers).  That is not a good place to be.

Well, it seems to me that animation handling part was being re-written simultaneously, so yes it's correct i'm not familiar with the new way of handling animations
(but Urvang is).


PK

Peter Kasting

unread,
Jul 2, 2013, 7:25:22 PM7/2/13
to Pascal Massimino, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Tue, Jul 2, 2013 at 4:05 PM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 3:29 PM, Peter Kasting <pkas...@google.com> wrote:
I don't think what I've suggested as an addition is very much diferent from what the format does now.  It is certainly not going all the way to VP8.  So I don't think this is a very good objection to my comment.

So, what do you have in mind as 'more comprehensive and accurate keyframing' ? We have this project of adding an 'index' chunk that would provide cues to jumping at individual frames in the an animated webp file. But, can't renderer build such an index on-the-fly while decoding, too?

You simply specify, with each frame, which pieces of which previous frames must first be decoded before the current frame can be layered on top.

The current decoder uses disposal methods to determine a conservative estimation for this, but it's not terribly accurate or time-saving when we have the (common) case of new frames that only modify small portions of previous frames.  And while we could attempt to enhance the decoder by more careful checking of per-pixel alpha and the like, at best we would only be able to build this accurate data structure after decoding all frames once -- which means we still have a long, CPU-intensive decode period before we can begin skipping frames (which often delays the start of actual animation by a long time).

 Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.

You are comparing apples with aircraft carriers.  JPEGs of common size take minimal time to decode and display.  64k x 64k JPEGs are extremely rare.  GIFs of common size take significant time to decode and display, such that they're one of the largest single problem sources we have w.r.t. overall renderer CPU load and responsiveness.  Animated WebP in its current form may make this worse.  This is a huge problem and it deserves attention.

Yes, but it doesn't seem to be related to WebP in particular but rather to large anims in general and habits that have grown around GIF usage.
Animated WebP's purpose is not to fix GIF (<video> can do that), and overly large anims are just a mis-use of both formats capabilities.

Proclaiming that will not cause people on the web to change their habits.  You are repeating the problems of XHTML by ignoring the stupid ways real people use things and trying to instead get everyone to change to a better, but not backwards-compatible, way.

If you're not trying to fix GIF, I am opposed to shipping animated WebP at all.  Since you're going to be trying to convince the entire world to change direction anyway, you should convince them all to switch to <video> and be done with it.
 
You're beginning to make me feel like the people specifying WebP don't actually understand the nuts and bolts of graphics handling in Blink (or other engines, for that matter, since we want adoption by other browsers).  That is not a good place to be.

Well, it seems to me that animation handling part was being re-written simultaneously, so yes it's correct i'm not familiar with the new way of handling animations
(but Urvang is).

What I'm saying is, I don't think either of you deeply understand the problems that animated GIF has and how they play out in the wild.  But you seem to be trying to convince me that it's not that you don't understand, but that you simply don't care, because you're not trying to fix animated GIFs in the first place.  This is a stance I find mind-boggling.

PK

Alex Russell

unread,
Jul 3, 2013, 12:05:29 AM7/3/13
to Hin-chung Lam, blink-dev, Elliott Sprehn, Peter Kasting, Tom Wiltzius, Urvang Joshi, Pascal Massimino, Darin Fisher

On 2 Jul 2013 22:30, "Alpha (Hin-Chung) Lam" <hc...@google.com> wrote:
>
>
>
> 2013/7/2 Alex Russell <sligh...@google.com>
>>
>>
>> Both matter.
>>
>> http://httparchive.org/trends.php#bytesImg&reqImg
>>
>> http://httparchive.org/interesting.php#onLoad
>
>
> On mobile devices battery life in the most important in my opinion. Once the file is loaded it will keep looping.

...assuming it is in view, etc.

It's safe to say that appealing to battery life concerns doesn't let you off the hook for network size: radios take power and data often costs money.

Pascal Massimino

unread,
Jul 3, 2013, 11:30:08 AM7/3/13
to Peter Kasting, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
Peter,


On Tue, Jul 2, 2013 at 4:25 PM, Peter Kasting <pkas...@google.com> wrote:
On Tue, Jul 2, 2013 at 4:05 PM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 3:29 PM, Peter Kasting <pkas...@google.com> wrote:
I don't think what I've suggested as an addition is very much diferent from what the format does now.  It is certainly not going all the way to VP8.  So I don't think this is a very good objection to my comment.

So, what do you have in mind as 'more comprehensive and accurate keyframing' ? We have this project of adding an 'index' chunk that would provide cues to jumping at individual frames in the an animated webp file. But, can't renderer build such an index on-the-fly while decoding, too?

You simply specify, with each frame, which pieces of which previous frames must first be decoded before the current frame can be layered on top.

The current decoder uses disposal methods to determine a conservative estimation for this, but it's not terribly accurate or time-saving when we have the (common) case of new frames that only modify small portions of previous frames.

this is a reasonable trade-off for (cheaply) gaining compression efficiency. Short of that, files would be terribly large. And anything more complex goes down the video frame-prediction way, with motion vectors and such.
 
 And while we could attempt to enhance the decoder by more careful checking of per-pixel alpha and the like, at best we would only be able to build this accurate data structure after decoding all frames once -- which means we still have a long, CPU-intensive decode period before we can begin skipping frames (which often delays the start of actual animation by a long time).

You'd have exactly the same problem with video files... if reasonable encoders didn't insert I-frames regularly to allow random jumps into the stream.
You can even have evil video files without any i-frames at all, only p-frames with lot of intra blocks.


 Especially if animated WebP sees significant use, we really, really, really want to avoid the current performance problems with animated GIFs, where even on a fast machine the load can become unbearable with just a few images.

That's also true with JPEG, e.g.: you can make the browser crawl to its knees with insane 64k x 64k JPEGs, e.g. All formats have their possibilities of mis-use.

You are comparing apples with aircraft carriers.  JPEGs of common size take minimal time to decode and display.  64k x 64k JPEGs are extremely rare.  GIFs of common size take significant time to decode and display, such that they're one of the largest single problem sources we have w.r.t. overall renderer CPU load and responsiveness.  Animated WebP in its current form may make this worse.  This is a huge problem and it deserves attention.

Yes, but it doesn't seem to be related to WebP in particular but rather to large anims in general and habits that have grown around GIF usage.
Animated WebP's purpose is not to fix GIF (<video> can do that), and overly large anims are just a mis-use of both formats capabilities.

Proclaiming that will not cause people on the web to change their habits.  You are repeating the problems of XHTML by ignoring the stupid ways real people use things and trying to instead get everyone to change to a better, but not backwards-compatible, way. 

If you're not trying to fix GIF, I am opposed to shipping animated WebP at all.  Since you're going to be trying to convince the entire world to change direction anyway, you should convince them all to switch to <video> and be done with it.
 
You're beginning to make me feel like the people specifying WebP don't actually understand the nuts and bolts of graphics handling in Blink (or other engines, for that matter, since we want adoption by other browsers).  That is not a good place to be.

Well, it seems to me that animation handling part was being re-written simultaneously, so yes it's correct i'm not familiar with the new way of handling animations
(but Urvang is).

What I'm saying is, I don't think either of you deeply understand the problems that animated GIF has and how they play out in the wild.  But you seem to be trying to convince me that it's not that you don't understand, but that you simply don't care, because you're not trying to fix animated GIFs in the first place.  This is a stance I find mind-boggling.

WebP is not trying to fix GIF (it's trying to make the web faster). GIF could be already fixed by itself if gif encoders were to regularly insert Dispose=Background frames for long anim (so we could easily seek into the files), like any regular video codec do by default.
They don't, and that's a pitfall that animated WebP encoder can avoid falling into. What would you do to fix GIF?
It's still my opinion there's room for Animated WebP between GIF and <video>, for short-and-better-compressed animated files. It offers somewhat higher compression (i can shave off 20% of tumblr/ gif pages, that's something), ARGB colorspace (and not just YUV420 like <video>), better alpha handling compared to GIF, and reasonable decoding (and transcoding) time.

Tom Wiltzius

unread,
Jul 3, 2013, 8:44:59 PM7/3/13
to Pascal Massimino, Peter Kasting, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Darin Fisher, blink-dev
It's clear that there are some great advantages to animated WebP over GIFs, as you list above. My concern is that shaving 20% off network load time of tumblr/ gif pages is great, but if that compression comes at the expense of rendering performance (as Alpha's numbers from earlier in this thread indicate) for one of our worst-case scenarios (i.e. animated GIFs), we're going to saddle everyone with an overall worse experience on the web. Pages that are covered in animated GIFs have terrible scrolling performance and burn a lot of CPU / battery time decoding.

My hope would be that in introducing a new format, we can make sure we don't end up in the same bad place we're in for GIFs in this particular regard. It sounds like there's no hope of that. Do you think we can at least get to the point where WebP decoding times are competitive with animated GIFs, rather than worse?



Peter Kasting

unread,
Jul 8, 2013, 4:18:20 PM7/8/13
to Pascal Massimino, Alpha (Hin-Chung) Lam, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Wed, Jul 3, 2013 at 8:30 AM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 4:25 PM, Peter Kasting <pkas...@google.com> wrote:
On Tue, Jul 2, 2013 at 4:05 PM, Pascal Massimino <sk...@google.com> wrote:
On Tue, Jul 2, 2013 at 3:29 PM, Peter Kasting <pkas...@google.com> wrote:
I don't think what I've suggested as an addition is very much diferent from what the format does now.  It is certainly not going all the way to VP8.  So I don't think this is a very good objection to my comment.

So, what do you have in mind as 'more comprehensive and accurate keyframing' ? We have this project of adding an 'index' chunk that would provide cues to jumping at individual frames in the an animated webp file. But, can't renderer build such an index on-the-fly while decoding, too?

You simply specify, with each frame, which pieces of which previous frames must first be decoded before the current frame can be layered on top.

The current decoder uses disposal methods to determine a conservative estimation for this, but it's not terribly accurate or time-saving when we have the (common) case of new frames that only modify small portions of previous frames.

this is a reasonable trade-off for (cheaply) gaining compression efficiency. Short of that, files would be terribly large. And anything more complex goes down the video frame-prediction way, with motion vectors and such.

I think I have a pretty concrete suggestion that does not involve motion vectors and does not make file sizes terribly large.  It seems like you're objecting in principle to a class of suggestions that I'm not making.  I'm being specific on purpose here, so there shouldn't be any reason to argue against a strawman.

What I'm saying is, I don't think either of you deeply understand the problems that animated GIF has and how they play out in the wild.  But you seem to be trying to convince me that it's not that you don't understand, but that you simply don't care, because you're not trying to fix animated GIFs in the first place.  This is a stance I find mind-boggling.

WebP is not trying to fix GIF (it's trying to make the web faster).

I don't know what criteria you use to measure "make the web faster", but network bandwidth cannot be the only relevant issue.  GIFs cause huge, obvious performance problems today for many users even with fast machines.  WebP is set to worsen this rather than improve it.  That's making the web slower in an important way even if it makes it faster in another.

GIF could be already fixed by itself if gif encoders were to regularly insert Dispose=Background frames for long anim (so we could easily seek into the files), like any regular video codec do by default.

I think that suggestion is complementary with mine.  (I'm also not sure offhand when in the GIF bitstream we know we have the authoritative disposal method for a frame.)
 
They don't, and that's a pitfall that animated WebP encoder can avoid falling into. What would you do to fix GIF?

I already said (repeatedly): provide with each frame the frame numbers of the minimal set of previous frames required to decode the current frame.

PK

Alpha (Hin-Chung) Lam

unread,
Jul 9, 2013, 6:39:10 PM7/9/13
to blink-dev
I uploaded the data set here: https://drive.google.com/a/google.com/uc?id=0B4fjqgfYdd-id3JWOEMyd2hBanM&export=download

It contains 7k GIFs crawled from google image search. Corresponding converted WebP and WebM files. It's a big file.

Tab Atkins Jr.

unread,
Jul 12, 2013, 12:55:52 PM7/12/13
to Alpha (Hin-Chung) Lam, Peter Kasting, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev, Pascal Massimino
On Mon, Jul 1, 2013 at 8:36 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
> Just to emphasize my worry about this use case. Please look around tumblr
> and almost all animated GIFs are from some kind of video clips. Using a true
> video codec compresses a lot better than an image codec.

Sorry for the delay in responding to this thread, but this touches on
something potentially important.

WebM, being a lossy, highly-tuned video codec, is better for encoding
video, which happens to match the major animated-GIF use-case well.
But people like the ease and general acceptableness of images (that
is, lots of sites that allow file uploads will take images, but not
videos).

There's perhaps a middle-ground here - can we treat WebM as an
"image", for the purpose of HTML's <img> element? We could even
optimize the display, perhaps adopting something like what Vine does -
videos start automatically, muted and auto-looping, and show no
controls except for an "unmute" button. This would make the use of
video-in-<img> less enticing for real video (longer than a few
seconds), but would fit the animated-GIF use-case perfectly, and even
allow (optional) sound to go along with them.

~TJ

Tom Wiltzius

unread,
Jul 12, 2013, 2:33:14 PM7/12/13
to Tab Atkins Jr., Alpha (Hin-Chung) Lam, Peter Kasting, Elliott Sprehn, Urvang Joshi, Darin Fisher, blink-dev, Pascal Massimino
I think this was proposed earlier in the thread too, indirectly, in the notion of using the webm playback pipeline behind the scenes for images. It seems pretty reasonable. 
 

~TJ

new...@gmail.com

unread,
Jul 12, 2013, 4:02:48 PM7/12/13
to blin...@chromium.org, Alpha (Hin-Chung) Lam, Peter Kasting, Elliott Sprehn, Urvang Joshi, Tom Wiltzius, Darin Fisher, Pascal Massimino


On Friday, July 12, 2013 8:55:52 PM UTC+4, Tab Atkins Jr. wrote:

WebM, being a lossy, highly-tuned video codec, is better for encoding
video, which happens to match the major animated-GIF use-case well.
But people like the ease and general acceptableness of images (that
is, lots of sites that allow file uploads will take images, but not
videos).


That's the key. The times when web-developers were creators of graphics/animation content, are gone. Those days web-developers make a platform for users to upload their graphics/animations. Sometimes we see amusing/interactive animations on the Google front page, but regular users don't do that. Simply because regular users can't upload such stuff on imgur or tumblr, or whatever their favorite place is.

Keep in mind it's very unlikely that their favorite place will let them upload the video (or anything including javascript) and just put it in <img> without checking the content is really an image.

So, in many places, animated GIFs is still the only way for users to upload and post their animations. It's not because they love GIFs, it's because there is no other way. The users would love to find a loophole, but on major websites all loopholes in "uploading arbitrary files" are already closed.


Eric Seidel

unread,
Jul 16, 2013, 6:26:51 PM7/16/13
to Alpha (Hin-Chung) Lam, Peter Kasting, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Mon, Jul 1, 2013 at 1:15 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

> That's right. The format is deeply inspired by GIF and does not allow
> specifying a frame explicitly as a key frame (not needing anything before to
> decode that frame). This feature is critical to to Web because an image
> should be paused when it's outside of the viewport, discarded in memory and
> then when it's scrolled into view resume from an arbitrary frame. Without
> this feature we'll have to cache multiple frames which is not desirable. On
> mobile most likely the cache will be evicted. Decoding it on impl thread can
> help but it's still a heavy workload.

I don't believe we pause any GIFs outside the viewport, do we?

Testing with:
http://commons.wikimedia.org/wiki/File:Seven_segment_display-animated.gif

I don't see the gifs pause when I scroll or switch to other tabs, etc.

Peter Kasting

unread,
Jul 16, 2013, 6:28:12 PM7/16/13
to Eric Seidel, Alpha (Hin-Chung) Lam, Urvang Joshi, Tom Wiltzius, Darin Fisher, blink-dev
On Tue, Jul 16, 2013 at 3:26 PM, Eric Seidel <ese...@chromium.org> wrote:
Testing with:
http://commons.wikimedia.org/wiki/File:Seven_segment_display-animated.gif

I don't see the gifs pause when I scroll or switch to other tabs, etc.

When the GIF is made visible again, we "spin it forward" to the point its animation should have been at if it had continued animating while offscreen.

PK

Darin Fisher

unread,
Jul 16, 2013, 7:43:40 PM7/16/13
to Urvang Joshi, blink-dev
Hi Urvang,

It seems that a number of concerns have been raised on this thread.  It's not clear that we are ready to ship Animated WebP.

For instance, it seems that Animated WebP is trying to be an improvement over Animated GIF, but based on Alpha's findings, the results are not great.  Transport size is marginally reduced at the cost of much greater CPU / power usage.  That seems like a questionable trade-off.

The proposal of <img src="foo.webm"> is intriguing.  I'm keen on seeing the idea explored further.

At any rate, the recommendation of the Blink API Owners is to work on resolving some of these issues with the goal of building more consensus.  (Personally, I'm a big fan of finding some way to improve on Animated GIFs, so I wish you success.)

Regards,
-Darin

Urvang Joshi

unread,
Jul 16, 2013, 7:50:27 PM7/16/13
to Darin Fisher, blink-dev
Hi Darin, others,
I've discussed some of the concerns raised here offline with Alpha.

Pascal and I feel that many of the concerns are addressable. But, as it seemed hard to discuss these concerns over email, we are meeting Alpha and Peter Kasting to resolve the same.

I'll update the thread about the conclusions.

Regards,
Urvang

Darin Fisher

unread,
Jul 16, 2013, 7:52:45 PM7/16/13
to Urvang Joshi, blink-dev
Sounds great.  Looking forward to an update.
-Darin

nl

unread,
Aug 26, 2013, 7:01:53 PM8/26/13
to blin...@chromium.org
Hi... first, I apologize for butting in on this discussion between experts but I thought maybe you might benefit from an outsider's point of view.  As someone with an interest in this field I've constructed what I hope to be some well-reasoned and practical arguments in favor of animated webp being implemented, and I hope you'll be willing to read them.  I understand you're busy people and your time's valuable so I'm sorry about how long the post is but to get my points across effectively I needed to be a bit verbose.

My main job is in web development and I also work on PC games as a hobby in my spare time.  Whether I'm designing a game or a website, I find it's rarely beneficial to work with my current PC (or mobile device) in mind as the target, or even today's mainstream PC; I need to consider what will be mainstream at the time when people will hopefully be viewing my websites or playing my games.  Likewise, I think you need to consider the amount of time it will take for animated webp to come into common use and what will have changed or stayed the same by that time.

It's true that low-power devices using a wifi connection may, in the short term, suffer some performance reduction when viewing pages with animated webp images.  While this is an important use-case, such devices tend to be either low-end (where good performance is not expected) and likely using an OS that Chrome/Chromium can't run on (Android <4.0), or on the opposite side of the spectrum the device may be one that has relatively powerful internals because of the reduced costs associated with wifi-only devices and larger acceptable form factor.  In the first case it doesn't matter if animated webp is too performance-intensive, and in the second case it likely won't be that much of an issue because the device is more capable.

A much more common and important scenario is a device using a mobile data network.  Even in relatively well-serviced countries, people tend to spend much of their time in areas which have sub-optimal cellular reception: indoors, in crowded areas, or in areas with poor coverage.  If you're loading a 5 MB web page in these conditions, each portion of that page will have ample time available to be decoded while the next chunk of usable data arrives.  A significantly smaller filesize thanks to using animated webp instead of GIF will be a huge win and certainly result in a better user experience.  The battery usage of a few extra seconds of work for the CPU can often be greatly outweighed by the battery usage of a phone's radio being active.

If you're in an area with a very fast connection such as LTE, transferring large files is less of a concern.  Devices using LTE often have better battery life than devices using HSPA simply by virtue of the radio being able to go into a low-power state much sooner, in spite of LTE using much more power for the time it's active.  However, if you consider that GIFs are frequently a megabyte in size if not more, and that very often pages will have either no GIFs at all or tons of GIFs, I'd still argue that the increased CPU power usage would be comparable to the reduced modem power usage.

Even if the performance hit is 300%, animated webp won't have any performance impact on desktop PCs.  Mobile CPUs are quickly becoming more power-efficient, adding more cores, and improving performance per core.  On the other hand, websites are following a similar curve in their increased functionality and complexity, and CPU performance doesn't scale linearly with core count and frequency.  Page rendering speed is obviously still improving at a rapid pace on mobile devices though.  While it's foolish to assume that everyone will have a high-end device that benefits from the latest SoC improvements, these improvements are rapidly filtering down into mainstream and low-end devices.  By the time animated webp becomes common, today's processors could easily be considered too slow for a low-end phone.

PNG is still not used in place of GIF in many places where it would be more appropriate; webp is still not used in place of JPG where it would be more appropriate; archaic codecs like h.263 (xvid) are often used where h.264 (AVC) or VP8 would be more appropriate; it won't be long before VP9 arrives and despite its promised improvements it won't be adopted very quickly either.  Bearing in mind the extremely slow pace of adoption that new standards have, the mere availability of animated webp (on just one browser at that) isn't going to suddenly make everyone switch to it and have the web grind to a halt on devices that don't handle the format well.  When it's available in Chromium/Chrome, it likely won't be adopted by Firefox and Opera for another year, and Internet Explorer might easily take much longer.  Game consoles and other standalone devices probably won't support it for 5 years or more, and any <4.0 Android device will almost certainly never support it.

Image formats can remain in common use for decades even as superior alternatives arrive; the GIF specification was finalized in 1987, JPG in 1992, PNG in 1996.  Effectively killing (or just unnecessarily delaying) animated webp by not supporting it in the web browser of the company responsible for its existence, simply on the basis that some percentage of users may not have an ideal experience for the first few years it's available, seems overly conservative.  I do understand that this is a discussion about Chromium, not Chrome, but I have to imagine that some of the people here also have an interest in the most visible Chromium project succeed, especially when the project in question is intended to replace a badly outdated and inefficient format which has greatly outlived its usefulness.

Chromium supports many other standards which can have usability issues on a large percentage of devices.  A couple examples are WebGL and SVG, both of which are very slow and demanding to display even on many desktop PCs.  Chrome for Android can also be very flaky on websites with native touch-based interfaces.  Despite these weaknesses, you put the responsibility for deciding if and when it's appropriate to use these standards on web developers, which was the right thing to do.  A web browser is designed to facilitate the correct display of a web developer's vision, not to hold back relevant and useful technologies until every device on the market is optimized for them.  Web developers routinely design different versions of websites and different assets for different targets; we're capable of using new technologies responsibly, in this case by only using webp on certain platforms while displaying an equivalent GIF on ones where there's likely to be a performance concern.

Data caps are probably one of the biggest constraining factors in the use of mobile services.  Less data usage for animated images means more use of the internet in general, which is good for anyone working in this industry.  If animated webp catches on, awareness of the advantages of static webp will also begin to grow rapidly.  If major image hosts realize the bandwidth savings of millions of GIFs being significantly reduced in size, they will adopt it and drive mainstream support, just like how Firefox wasn't going to implement webp support but changed their mind when some major sites began using it.

GIF needs to be retired, everyone in this field knows it and we've known it for many years.  If webp doesn't become the new standard, something else will inevitably come along.  What will it be?  Will the other standard be as efficient?  Royalty-free in commercial use?  Maybe it'll be based on HEVC, which means it'll be the h.264 mess all over again if MPEG-LA decides everyone using it commercially owes them a nickel.

new...@gmail.com

unread,
Aug 27, 2013, 3:38:24 AM8/27/13
to blin...@chromium.org, nawoa...@gmail.com
As I understand, animated WebP code is already implemented in Chromium, it's just hidden behind a runtime flag.
You just need to enable this flag and then restart browser:
chrome://flags/#enable-experimental-web-platform-features
Animated WebP works for me after that.
That way you might already experiment with the format, its implementation performance etc.
Developers would appreciate a feedback, no doubt.

Message has been deleted
Message has been deleted

Darin Fisher

unread,
Sep 16, 2013, 3:44:46 PM9/16/13
to Urvang Joshi, blink-dev
This sounds great. One question below:


On Fri, Sep 13, 2013 at 3:59 PM, Urvang Joshi <urv...@google.com> wrote:

Hi all,

Thank you for all the comments.


The main concern raised was that animated images have a poor performance when seeking to a random animation frame -- because all prior dependent frames would need to be decoded.


Based on a number of discussions with Peter and Alpha, I’ve been working on improving the decoding performance of animated WebP images. After some optimizations to the format itself, decoder library as well as the gif2webp tool, WebP decoding performance is much more compelling.


Here is a summary:

Optimizations


Results

  • File size:

    • WebP-lossy is 49.16% smaller than GIF

    • WebP-lossless is 18.26% smaller than GIF

  • Decode time with seeking:

    • WebP-lossy takes 0.8x decode time compared to GIF

    • WebP-lossless takes 0.76x decode time compared to GIF


On what kind of system did you perform this performance comparison? How does CPU utilization (power consumption) compare between WebP and GIF?

-Darin

 

Advantages of WebP over GIF

  1. WebP images are smaller in size compared to GIFs. This is specially important on mobiles, as data costs money.

  2. With the optimizations done, WebP has a decoding performance better than than GIF, too.

  3. Note that certain optimizations can, by design, only be done for WebP and not GIF:

    • In case of WebP, it’s easy for the encoder to heuristically add key-frames at regular intervals to improve decoding performance. This is made possible by ‘blend method’ option in WebP -- not available in GIF.

    • For a WebP animation frame, one can find out whether it contains alpha without decoding the frame. This leads to much more accurate inference of which previous frames a given frame depends on; thereby reducing unnecessary decoding of previous frames.

    • When a WebP animation frame uses ‘blend method’ option, the alpha-blending step would be avoided.

  4. WebP supports true-color animations -- specifically an 8-bit alpha channel. (GIF has 1-bit alpha).

  5. WebP can support both lossy and lossless animations (GIF can only be lossless). In fact, a single animation can combine lossily and losslessly encoded frames.

  6. Animation support makes WebP a single format which can support basically all important functions of images. This can be useful for CDNs that optimize images, for example.

  7. Huge demand for animated WebPs is evident:



Peter Kasting

unread,
Sep 16, 2013, 4:20:20 PM9/16/13
to Urvang Joshi, blink-dev
FWIW, after the changes to the WebP encoder, decoder, and GIF transcoder, I support the inclusion of animated WebP in Blink.

PK

Urvang Joshi

unread,
Sep 16, 2013, 5:06:31 PM9/16/13
to Darin Fisher, blink-dev
Hi Darin,

On Mon, Sep 16, 2013 at 12:44 PM, Darin Fisher <da...@chromium.org> wrote:
This sounds great. One question below:


On Fri, Sep 13, 2013 at 3:59 PM, Urvang Joshi <urv...@google.com> wrote:

Hi all,

Thank you for all the comments.


The main concern raised was that animated images have a poor performance when seeking to a random animation frame -- because all prior dependent frames would need to be decoded.


Based on a number of discussions with Peter and Alpha, I’ve been working on improving the decoding performance of animated WebP images. After some optimizations to the format itself, decoder library as well as the gif2webp tool, WebP decoding performance is much more compelling.


Here is a summary:

Optimizations


Results

  • File size:

    • WebP-lossy is 49.16% smaller than GIF

    • WebP-lossless is 18.26% smaller than GIF

  • Decode time with seeking:

    • WebP-lossy takes 0.8x decode time compared to GIF

    • WebP-lossless takes 0.76x decode time compared to GIF


On what kind of system did you perform this performance comparison? How does CPU utilization (power consumption) compare between WebP and GIF?

I ran this decoder benchmark (https://codereview.chromium.org/23532077/) on a set of about 7k images (image set provided by Alpha). The benchmark was run on my Linux machine.
And, the benchmark tool is single-threaded, and AFAIK the decoders run single-threaded, too. So, the decode times should be correlated to the CPU utilization.

Darin Fisher

unread,
Sep 16, 2013, 6:59:00 PM9/16/13
to Urvang Joshi, blink-dev
Is it possible for you to repeat the performance test on an Android device? I think it would help to understand the performance characteristics on mobile.

-Darin
Message has been deleted

James Robinson

unread,
Sep 16, 2013, 7:38:59 PM9/16/13
to Urvang Joshi, Darin Fisher, blink-dev
On Mon, Sep 16, 2013 at 4:28 PM, Urvang Joshi <urv...@google.com> wrote:
Hi Darin,


Is it possible for you to repeat the performance test on an Android device? I think it would help to understand the performance characteristics on mobile.

Android doesn't support animated images as yet (be it GIF or WebP). So, that's not a concern right now.


Chrome on Android most certainly does support animated GIF and always has.

- James 

Adam Barth

unread,
Sep 16, 2013, 7:39:00 PM9/16/13
to Urvang Joshi, Darin Fisher, blink-dev
I just went to the top link on reddit on my phone and animated GIFs do appear to be supported.  :-)

Adam



On Monday, September 16, 2013, Urvang Joshi <urv...@google.com> wrote:
> Hi Darin,
>
> On Mon, Sep 16, 2013 at 3:59 PM, Darin Fisher <da...@chromium.org> wrote:
>
>
>
> On Mon, Sep 16, 2013 at 2:06 PM, Urvang Joshi <urv...@google.com> wrote:
>
> Hi Darin,
> On Mon, Sep 16, 2013 at 12:44 PM, Darin Fisher <da...@chromium.org> wrote:
>
> This sounds great. One question below:
>
> On Fri, Sep 13, 2013 at 3:59 PM, Urvang Joshi <urv...@google.com> wrote:
>
> Hi all,
>
> Thank you for all the comments.
>
> The main concern raised was that animated images have a poor performance when seeking to a random animation frame -- because all prior dependent frames would need to be decoded.
>
> Based on a number of discussions with Peter and Alpha, I’ve been working on improving the decoding performance of animated WebP images. After some optimizations to the format itself, decoder library as well as the gif2webp tool, WebP decoding performance is much more compelling.
>
> Here is a summary:
>
> Optimizations
>
> Demux library was enhanced to report the presence of alpha for each animated frame: https://gerrit.chromium.org/gerrit/#/c/62581/
>
> We added ‘blend method’ to  WebP animation frames, which specifies whether that frame should be blended with the previous canvas or not: https://gerrit.chromium.org/gerrit/#/c/65379/
>
> <
>
> Android doesn't support animated images as yet (be it GIF or WebP). So, that's not a concern right now.
>  
>

Urvang Joshi

unread,
Sep 16, 2013, 7:41:54 PM9/16/13
to Adam Barth, Darin Fisher, blink-dev
Adam/James,


On Mon, Sep 16, 2013 at 4:39 PM, Adam Barth <aba...@chromium.org> wrote:
I just went to the top link on reddit on my phone and animated GIFs do appear to be supported.  :-)

Yes, my bad.
I confused it with the fact that native android apps don't support animated GIFs

Urvang Joshi

unread,
Sep 16, 2013, 7:56:39 PM9/16/13
to Darin Fisher, blink-dev
Let me find out if it's feasible to run the tests on Android.

PhistucK

unread,
Sep 17, 2013, 2:21:10 AM9/17/13
to Urvang Joshi, Darin Fisher, blink-dev
However, there are optimizations that benefit multiple thread and multiple core machines as well - right?


PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Urvang Joshi

unread,
Sep 17, 2013, 2:26:24 AM9/17/13
to PhistucK, Darin Fisher, blink-dev
On Mon, Sep 16, 2013 at 11:21 PM, PhistucK <phis...@gmail.com> wrote:
However, there are optimizations that benefit multiple thread and multiple core machines as well - right?

Yes, libwebp does have multithreaded decoding support, too.

Darin Fisher

unread,
Sep 17, 2013, 2:32:11 AM9/17/13
to Urvang Joshi, PhistucK, blink-dev
When you observed WebP being faster than GIF, was WebP benefiting from using many threads in parallel? If so, I'm even more curious what the results look like on more constrained systems (mobile hardware).