Primary eng (and PM) emails
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
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
OWP launch tracking bug?
(Bug related to implementation: crbug.com/229641)
Row on feature dashboard?
Yes.
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>?
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>?
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.
Numbers here: https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AofjqgfYdd-idERuajF2VHJiT2NlNGlsVW9zYUUxSEE#gid=0
Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gzNote 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.
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.
Numbers here: https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AofjqgfYdd-idERuajF2VHJiT2NlNGlsVW9zYUUxSEE#gid=0
Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gzNote 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.
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?
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].
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.
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
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.
Numbers here: https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AofjqgfYdd-idERuajF2VHJiT2NlNGlsVW9zYUUxSEE#gid=0
Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gzNote 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."
Why support Animated WebP at all then? :)
+CC skal for the format issue below (last paragraph).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.
2013/7/1 Peter Kasting <pkas...@google.com>
+CC skal for the format issue below (last paragraph).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 GIFSize comparison:* Lossy (42dB PSNR) animated WebP on average is 86% of GIF* Lossless animated WebP on average is 83% of GIFI 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 transcodingAnimated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.
2. For encoding source materialNote 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.
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).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 GIFSize comparison:* Lossy (42dB PSNR) animated WebP on average is 86% of GIF
* Lossless animated WebP on average is 83% of GIFI 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 transcodingAnimated WebP shows a slight advantage in size but performance is worse and format-wise is no better than GIF.
2. For encoding source materialNote 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.
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.
Numbers here: https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AofjqgfYdd-idERuajF2VHJiT2NlNGlsVW9zYUUxSEE#gid=0
Quality level is the same for WebP and WebM. See source files, patches and scripts: ~hclam/cats.tar.gzNote 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?).
Perf comparison:* Lossy (42dB PSNR) animated WebP on average is 2.6x of GIF* Lossless animated WebP on average is 1.5x of GIF
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 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
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).
2. We should promote the best practice for encoding video content, i.e. WebM. There shouldn't be a lossy animated image format.
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 GIFI 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
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).
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.
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
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?
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.
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).
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.
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.
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.
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?
~TJ
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).
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.
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/
We improved the gif2webp tool to insert key-frames at regular intervals: https://gerrit.chromium.org/gerrit/#/c/67163/. For animated WebP images created in this way, decoding a frame would depend on much fewer previous frames. And hence, the decoding performance would be much better when seeking.
All these features were utilized to improve the performance of animated WebP decoder (especially for the seeking scenario): https://codereview.chromium.org/23068027/
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
Advantages of WebP over GIF
WebP images are smaller in size compared to GIFs. This is specially important on mobiles, as data costs money.
With the optimizations done, WebP has a decoding performance better than than GIF, too.
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.
WebP supports true-color animations -- specifically an 8-bit alpha channel. (GIF has 1-bit alpha).
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.
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.
Huge demand for animated WebPs is evident:
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/
We improved the gif2webp tool to insert key-frames at regular intervals: https://gerrit.chromium.org/gerrit/#/c/67163/. For animated WebP images created in this way, decoding a frame would depend on much fewer previous frames. And hence, the decoding performance would be much better when seeking.
All these features were utilized to improve the performance of animated WebP decoder (especially for the seeking scenario): https://codereview.chromium.org/23068027/
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?
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.
I just went to the top link on reddit on my phone and animated GIFs do appear to be supported. :-)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
However, there are optimizations that benefit multiple thread and multiple core machines as well - right?
When you observed WebP being faster than GIF, was WebP benefiting from using many threads in parallel?
Stephen Konig | | Sr. Product Manager, Chrome | | sko...@google.com | | 843-327-6289 |
Though to be clear, I think supporting WebM video in addition to animated WebP is worth considering.
Hi Darin,To test performance on a mobile device, I ran the benchmark tool on a Nexus 7; and the comparative numbers were similar: Decoding speed is between 0.8x and 0.9x compared to GIF.
PK
Sorry, I should have been clearer. This is "Decode time with seeking" just like the Desktop numbers. So, lower is better.
PK
Yes, the decoding without seeking is slower compared to GIF. Lossless WebP takes 1.8x time while lossy WebP takes 2.9x time compared to GIF.
PK
Not many low-hanging fruits in the core decode loop. But, I do have an idea to improve gif2webp tool for lossy images that has good potential.
On Thu, Sep 19, 2013 at 6:03 PM, Urvang Joshi <urv...@google.com> wrote:
Not many low-hanging fruits in the core decode loop. But, I do have an idea to improve gif2webp tool for lossy images that has good potential.I'm mainly worrying about people with several visible animated WebPs at once. If they just stare at the page, we won't seek, and thus we'll be eating even more CPU than with GIF.
Let's think about the overall impact in the worst case scenario: there are 10 animated images (with average 15 frames per image) visible at a time, and user stares at it until images cycle 5 times.
Suppose, total GIF size was 2.5 MB (estimated from my image set). Then WebP lossy would be 1.28 MB. On a 2 Mbps connection, this would save 4.88 seconds of download time.
At 2162 frames/second, GIF would take 349 ms to decode all frames of all images 5 times. For the same, WebP lossy, at 745 frames/second will take 1 second. Thus WebP would take 650 ms more.
Overall savings for WebP lossy: 4.23 seconds.
SImilarly,
WebP lossless would be 2.05 MB. On a 2 Mbps connection, this would save 1.8 seconds of download time.
WebP lossless, at 1200 frames/second will take 625 ms. Thus WebP would take 276 ms more.
Overall savings for WebP lossless: 1.52 seconds.
It might be nice to investigate the idea (I've heard a few times) to have Blink decode internally to some intermediate form, more compact than the 32bpp FrameBuffer of today, but easier to decode than the original compressed data. Such a form could be very useful for looping GIFs _and_ WebPs, because we could use it to raise the current clamp on saving decoded data, thus putting more images into the "doesn't cost a ton of CPU continuously" category.
PK
Let's think about the overall impact in the worst case scenario: there are 10 animated images (with average 15 frames per image) visible at a time, and user stares at it until images cycle 5 times.
Suppose, total GIF size was 2.5 MB (estimated from my image set). Then WebP lossy would be 1.28 MB. On a 2 Mbps connection, this would save 4.88 seconds of download time.
At 2162 frames/second, GIF would take 349 ms to decode all frames of all images 5 times. For the same, WebP lossy, at 745 frames/second will take 1 second. Thus WebP would take 650 ms more.
Overall savings for WebP lossy: 4.23 seconds.
I think the case for animated WebP would be much stronger if relative to GIF there wasn't a CPU / power usage cost. I recognize that animated WebP can be delivered to clients faster than corresponding GIFs, which is great, but it seems quite unfortunate that CPU / power usage is so much higher.
It would of course be much better if I could point you at precise data collected about machine speed, slow URLs, etc. to make what I'm saying concrete. I realize I'm waving my hands. But I hope others can attest that GIF CPU cost has been a big deal in the past, and while I am extremely pleased that we can make the decode-with-seeking case so much better with WebP, it'd be even more awesome if we could _also_ make straight-line decoding faster.
I think the case for animated WebP would be much stronger if relative to GIF there wasn't a CPU / power usage cost. I recognize that animated WebP can be delivered to clients faster than corresponding GIFs, which is great, but it seems quite unfortunate that CPU / power usage is so much higher.
Presumably WebM is also more costly than GIF to decode? I'm curious if <img src=foo.webm> has better CPU characteristics than <img src=foo.webp>.
Thanks!-Darin
On Fri, Sep 20, 2013 at 3:50 PM, Peter Kasting <pkas...@google.com> wrote:
On Fri, Sep 20, 2013 at 3:09 PM, Urvang Joshi <urv...@google.com> wrote:
Let's think about the overall impact in the worst case scenario: there are 10 animated images (with average 15 frames per image) visible at a time, and user stares at it until images cycle 5 times.
Suppose, total GIF size was 2.5 MB (estimated from my image set). Then WebP lossy would be 1.28 MB. On a 2 Mbps connection, this would save 4.88 seconds of download time.
At 2162 frames/second, GIF would take 349 ms to decode all frames of all images 5 times. For the same, WebP lossy, at 745 frames/second will take 1 second. Thus WebP would take 650 ms more.
Overall savings for WebP lossy: 4.23 seconds.
The only problem I have with this is that the numbers don't match what we can often see on real web pages. In the wild, it's frequently true that pages with lots of GIFs have very large (= high frame count) GIFs, and the decoding machine is either much slower or much more heavily contended than whatever you used to get the 2k FPS decode speed estimate. (Classically, we've had pages where just one animated GIF can burn 50% CPU in perpetuity, which, even assuming the GIF runs at 60 FPS, would mean the CPU is only capable of ~120 FPS.) So I worry about scenarios where either the CPU is much slower or the GIFs are much more demanding than the estimates you have here.It would of course be much better if I could point you at precise data collected about machine speed, slow URLs, etc. to make what I'm saying concrete. I realize I'm waving my hands. But I hope others can attest that GIF CPU cost has been a big deal in the past, and while I am extremely pleased that we can make the decode-with-seeking case so much better with WebP, it'd be even more awesome if we could _also_ make straight-line decoding faster.PK
2013/9/20 Darin Fisher <da...@chromium.org>
I think the case for animated WebP would be much stronger if relative to GIF there wasn't a CPU / power usage cost. I recognize that animated WebP can be delivered to clients faster than corresponding GIFs, which is great, but it seems quite unfortunate that CPU / power usage is so much higher.Peter has answered this question.Presumably WebM is also more costly than GIF to decode? I'm curious if <img src=foo.webm> has better CPU characteristics than <img src=foo.webp>.WebM is a superset of Animated WebP and is at least as complex as Animated WebP to decode.Straight playback without seeking is more complex to decode. Playback with seeking (fast forward due to scrolling, tab visibility change) is about the same. The advantage is better compression ratio and smaller file size for the same quality. WebM can be at least half the size of the same file in Animated WebP.
To be clear, has your positioned changed to supporting shipping animated WebP?
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,-DarinOn Thu, Jun 27, 2013 at 9:09 PM, Urvang Joshi <urv...@google.com> wrote:
Primary eng (and PM) emails
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
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
OWP launch tracking bug?
(Bug related to implementation: crbug.com/229641)
Row on feature dashboard?
Yes.
Note that I am not familiar with the differences between seek based and straight line decoding and I could not find any information with a quick search.
You write the Blink always uses seek based decoding.
So if a page includes an animated WebP and it is always visible and the tab is always active during the animation time - it still uses the seek based decoding?
Eric wrote that in his footnotes -"4. Note that although https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp mentions that WebP takes more CPU time in straight-line decoding, Blink's image decoders always do seek-based decoding."
So the CPU time advantages are only in cases of inactive tabs or otherwise invisible animated WebP images.
The common case (I assume) is straight line decoding,
in which animated WebP is worse than GIF. Thus the seek based advantages are uncommonly relevant.
I see no good reason to ship this yet (especially without any expressed support from at least another vendor),
I just hope we do not end up in the same situation like Firefox with APNG.
Hi folks,To update this thread, after going over all of the issues, we (the Blink API Owners) have decided that it makes sense to proceed with shipping Animated WebP. The reasoning behind the decision is captured by this section of the WebP FAQ: https://developers.google.com/speed/webp/faq#why_should_i_use_animated_webp
Animated WebP is incompatible with WebP, which makes it a whole new format for the web and one that has no support from other browser vendors (much like the original WebP, but still in addition to WebP, since one does not have to activate the animated WebP support when implementing WebP).
I think the lack of multiple vendor support is my 'strongest' argument for not shipping this, anyway.
Recent additions of keyframes might help the performance, but they hurt the compression rates.
I experimented with recent gif2webp, and for longer GIFs, where converter adds a lot of keyframes, WebP often comes with even bigger size than original GIFs.