Intent to Implement: Animated WebP images

[Urvang Joshi]

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 from github:
https://gerrit.chromium.org/gerrit/gitweb?p=webm/libwebp.git;a=blob;f=doc/webp-container-spec.txt;h=f3d753108a939e5c6a5d386018ef99305ee75770;hb=b66caee410bdc0cad5b1de2719098058a64658fe

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.

Usecases

Animated WebP is an excellent alternative to GIF images, and presents some important benefits over GIFs. For example,

• Each frame in an animated WebP can be lossy or lossless as per need.
  
• It has a true alpha channel (8-bit) as compared to a binary (1-bit) alpha in GIFs.

Adding support to animated WebPs in Chrome would make it possible for web developers to use it widely.

Compatibility Risk

• Opera supports non-animated WebP images (libwebp v0.2.0) as of now: http://www.opera.com/docs/specs/presto2.12/#m212-395
  
• Firefox is considering WebP support as well:  https://bugzilla.mozilla.org/show_bug.cgi?id=856375

OWP launch tracking bug?

(A normal bug)

https://code.google.com/p/chromium/issues/detail?id=229641

Row on feature dashboard?

Fits under an existing row:"WebP image format support"

[Eric Seidel]

Mozilla sounds rather negative in that bug.
Presto is dead. :(

But given that we are already shipping WebP, I see no reason why we
shouldn't support this newer version of WebP which includes animation.

Clearly adding a new web image format is a chicken-and-egg problem here.

[Dimitri Glazkov]

Just curious. What would be the standards body that takes this spec as
a deliverable?

:DG<

[Emil A Eklund]

Presumably ISO or IETF.

[Dominic Mazzoni]

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh, and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink.

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

- Dominic

[Stephen Konig]

Just a couple of thoughts:

Mozilla sounds rather negative in that bug.

Considering that they had previously rejected WebP support outright, their decision to re-open the evaluation is a strong positive signal.  I'm hopeful that we now have strong evidence to satisfy their earlier concerns.

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh,

That's a reasonable concern but I'm not sure how Blink's freshness impacts WebP.  Is there something specific you fear may break if we proceed now versus later?

and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink. 

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

In general I understand your concern; however I view this case as somewhat different.  Animation has always been part of the WebP spec, just not implemented until now.  In a sense we are just completing work that's been planned for some time, and the ship sailed once we agreed to include WebP in Chromium in the first place.  Similarly we added incremental features to WebP in previous releases too, such as lossless and alpha support -- I don't view this case as any different.

Further to the earlier point about Mozilla, one of the things that's been holding back broader support for WebP has been the fact that it was perceived to be an incomplete implementation (until now).  Perversely not supporting what's now the complete feature set will perpetuate compatibility risk; adding 0.3.0 support will enhance our ability to get it supported by other browser vendors.

Thanks,

Stephen

[Ehsan Akhgari]

On Thu, Apr 11, 2013 at 12:15 PM, Stephen Konig <sko...@chromium.org> wrote:

Just a couple of thoughts:

Mozilla sounds rather negative in that bug.

Considering that they had previously rejected WebP support outright, their decision to re-open the evaluation is a strong positive signal.  I'm hopeful that we now have strong evidence to satisfy their earlier concerns.

No, Mozilla has not yet made any decisions to support WebP.

 

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh,

That's a reasonable concern but I'm not sure how Blink's freshness impacts WebP.  Is there something specific you fear may break if we proceed now versus later?

and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink. 

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

In general I understand your concern; however I view this case as somewhat different.  Animation has always been part of the WebP spec, just not implemented until now.  In a sense we are just completing work that's been planned for some time, and the ship sailed once we agreed to include WebP in Chromium in the first place.  Similarly we added incremental features to WebP in previous releases too, such as lossless and alpha support -- I don't view this case as any different.

Gecko has been shipping Animated PNG for quite some time now (since Firefox 3 IIRC) but that has not been received well by other vendors, and as such Animated PNG is not an interoperable feature right now.  There's nothing very special about Animated WebP here, I think that deserves to be considered a web facing new feature.

Cheers,

--
Ehsan
<http://ehsanakhgari.org/>

[sko...@chromium.org]

On Thursday, April 11, 2013 1:11:45 PM UTC-7, Ehsan Akhgari wrote:

On Thu, Apr 11, 2013 at 12:15 PM, Stephen Konig <sko...@chromium.org> wrote:

Just a couple of thoughts:

Mozilla sounds rather negative in that bug.

Considering that they had previously rejected WebP support outright, their decision to re-open the evaluation is a strong positive signal.  I'm hopeful that we now have strong evidence to satisfy their earlier concerns.

No, Mozilla has not yet made any decisions to support WebP.

I didn't say that they had; I said they'd made a decision to re-open consideration of WebP support.

 

 

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh,

That's a reasonable concern but I'm not sure how Blink's freshness impacts WebP.  Is there something specific you fear may break if we proceed now versus later?

and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink. 

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

In general I understand your concern; however I view this case as somewhat different.  Animation has always been part of the WebP spec, just not implemented until now.  In a sense we are just completing work that's been planned for some time, and the ship sailed once we agreed to include WebP in Chromium in the first place.  Similarly we added incremental features to WebP in previous releases too, such as lossless and alpha support -- I don't view this case as any different.

Gecko has been shipping Animated PNG for quite some time now (since Firefox 3 IIRC) but that has not been received well by other vendors, and as such Animated PNG is not an interoperable feature right now.  There's nothing very special about Animated WebP here, I think that deserves to be considered a web facing new feature.

I'm not sure how that's relevant.  Even if we maintained the status quo with respect to browser WebP support, adding animated WebP features wouldn't change anything with respect to WebP's interoperability.  Presumably if and when other browser vendors add WebP support, they'll do so based off the 0.3.0 version that supports animation.

Thanks,

Stephen

[Alpha (Hin-Chung) Lam]

2013/4/11 Stephen Konig <sko...@chromium.org>

Just a couple of thoughts:

Mozilla sounds rather negative in that bug.

Considering that they had previously rejected WebP support outright, their decision to re-open the evaluation is a strong positive signal.  I'm hopeful that we now have strong evidence to satisfy their earlier concerns.

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh,

That's a reasonable concern but I'm not sure how Blink's freshness impacts WebP.  Is there something specific you fear may break if we proceed now versus later?

Blink not yet support deferred image decoding for animated images (it's on my todo list though). Deferred image decoding is an important feature that allows smooth scrolling with page loaded with images and is default in Clank. Is there a way to identify a webp image is animated by parsing the headers? This way we can retain deferred image decoding for single frame WebP, which is critical to Clank because of transcoding images to webp.

[PhistucK]

I vaguely remember reading that WebP images that use features that were not supported at first (alpha, lossless, animation) are unreadable by the initial implementations (found in earlier Chrome, Android and Opera releases). But I might be mistaken.

Are Animated WebP images backward compatible?

Will older browsers just show the first frame, or will older browsers not be able to read the image?

☆PhistucK

[Ehsan Akhgari]

On Thu, Apr 11, 2013 at 4:20 PM, <sko...@chromium.org> wrote:

On Thursday, April 11, 2013 1:11:45 PM UTC-7, Ehsan Akhgari wrote:

On Thu, Apr 11, 2013 at 12:15 PM, Stephen Konig <sko...@chromium.org> wrote:

Just a couple of thoughts:

Mozilla sounds rather negative in that bug.

Considering that they had previously rejected WebP support outright, their decision to re-open the evaluation is a strong positive signal.  I'm hopeful that we now have strong evidence to satisfy their earlier concerns.

No, Mozilla has not yet made any decisions to support WebP.

I didn't say that they had; I said they'd made a decision to re-open consideration of WebP support.

Right, and I was trying to say that it should not be counted as a strong positive signal (or a negative signal for that matter.)  Nobody at Mozilla has made a decision about WebP support to the best of my knowledge.

 

 

 

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh,

That's a reasonable concern but I'm not sure how Blink's freshness impacts WebP.  Is there something specific you fear may break if we proceed now versus later?

and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink. 

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

In general I understand your concern; however I view this case as somewhat different.  Animation has always been part of the WebP spec, just not implemented until now.  In a sense we are just completing work that's been planned for some time, and the ship sailed once we agreed to include WebP in Chromium in the first place.  Similarly we added incremental features to WebP in previous releases too, such as lossless and alpha support -- I don't view this case as any different.

Gecko has been shipping Animated PNG for quite some time now (since Firefox 3 IIRC) but that has not been received well by other vendors, and as such Animated PNG is not an interoperable feature right now.  There's nothing very special about Animated WebP here, I think that deserves to be considered a web facing new feature.

I'm not sure how that's relevant.  Even if we maintained the status quo with respect to browser WebP support, adding animated WebP features wouldn't change anything with respect to WebP's interoperability.  Presumably if and when other browser vendors add WebP support, they'll do so based off the 0.3.0 version that supports animation.

Simply because an implementation uses that version of the library doesn't mean that they will support Animated WebP.  Shipping this in one engine would probably mean that if another engine adopts WebP in the future but not Animated WebP, then Animated WebP will not be interoperable (assuming that my understanding that Animated WebP is backwards compatible with WebP is correct.)

--
Ehsan
<http://ehsanakhgari.org/>

[Stephen Konig]

Are Animated WebP images backward compatible?

Will older browsers just show the first frame, or will older browsers not be able to read the image?

The new features aren't backwards compatible, no (how could they be?).  But only images that take use those new features (e.g. animation) would be affected; images encoded with the 0.3.0 encoder that don't use those features (e.g. ordinary lossy or lossless images) will still render just fine in older browsers/be decodable by earlier versions of the decoder.

This is really less of an issue than it seems though, as with auto-update features in Chrome and Opera there aren't likely to be any older browsers out there to have difficulty rendering images that use these new features.  To this point however, it's better to adopt this sooner rather than later, so that as additional browser support does come online we don't run into this problem (e.g., IE).

Thanks,

Stephen

Stephen Konig |

Product Management, Chrome |

sko...@google.com |

843-327-6289

[Petter Nilsen]

On Thu, 11 Apr 2013 22:11:45 +0200, Ehsan Akhgari <ehsan....@gmail.com> wrote:

Gecko has been shipping Animated PNG for quite some time now (since Firefox 3 IIRC) but that has not been received well by other vendors, and as such Animated PNG is not an interoperable feature right now.  There's nothing very special about Animated WebP here, I think that deserves to be considered a web facing new feature.

Opera has supported APNG for quite a while, both in Presto and in the UI (for spinners and such). 

--

- Petter

[Ehsan Akhgari]

Ah, right, I stand corrected, but the rest of my argument still applies.  :-)

--
Ehsan
<http://ehsanakhgari.org/>

 

[Stephen Konig]

On Thu, Apr 11, 2013 at 2:00 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

Right, and I was trying to say that it should not be counted as a strong positive signal (or a negative signal for that matter.)  Nobody at Mozilla has made a decision about WebP support to the best of my knowledge.

Again, I'm not claiming that they have.  To be clear, my statement is entirely subjective -- I consider going from "No" to "Maybe" to be a positive step (from the standpoint of wanting to see broader WebP adoption). 

Simply because an implementation uses that version of the library doesn't mean that they will support Animated WebP.  Shipping this in one engine would probably mean that if another engine adopts WebP in the future but not Animated WebP, then Animated WebP will not be interoperable (assuming that my understanding that Animated WebP is backwards compatible with WebP is correct.)

True, but I don't see how that's likely here.  Presumably if and when a new engine adopts WebP it will do so based on the most recent version of the decoder.  Unless you're suggesting that they'd deliberately pick an earlier version and never upgrade it, I'm not sure how this would happen in practice.  

I suppose it's possible for an engine to use the 0.3.0 or later decoder but explicitly break interoperability by choosing not to render animated WebP's, but that's true of any feature of WebP (e.g., someone could choose not to implement lossless decode support), and in any case not something Chromium can control and thus not relevant to the question at hand.  Adopting 0.3.0 for Chromium doesn't seem like it would introduce any additional interoperability concerns as things stand today. 

Thanks,

Stephen

[Alpha (Hin-Chung) Lam]

My earlier question was not answered. Since this is a new feature it needs to work well with the general direction of Blink rendering is going (i.e. impl-side painting and deferred image decoding). We certainly don't want to regress single frame WebP. It's not yet clear to me whether this feature will affect deferred image decoding for webp or not.

2013/4/11 Stephen Konig <sko...@chromium.org>

[Nat Duca]

Just to echo what Alpha said, this is incredibly importan to get right, folks. Deferred image decoding working efficiently is central to the multithreaded rendering architecture. Having features of WebP that defeat that architecture would be a real shame.

[Elliott Sprehn]

I'd much rather we support APNG. Adding WebP support doesn't get web interop at all since Gecko doesn't even support the basic format. Adding APNG support would be immediately useful since it's already supported in another browser.

Adding animated WebP also now seems almost a slight to the other vendors seeing as we're adding extensions to a format no one else has yet to implement (sadly Presto is dead).

[Thiago Farina]

On Thu, Apr 11, 2013 at 7:04 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd much rather we support APNG. Adding WebP support doesn't get web interop at all since Gecko doesn't even support the basic format. Adding APNG support would be immediately useful since it's already supported in another browser.

There was a discussion about APNG on Chromium-dev.

https://groups.google.com/a/chromium.org/d/topic/chromium-dev/2xvXNJMsgxc/discussion

--
Thiago

[Urvang Joshi]

Hi Alpha,

On Thu, Apr 11, 2013 at 2:58 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

My earlier question was not answered. Since this is a new feature it needs to work well with the general direction of Blink rendering is going (i.e. impl-side painting and deferred image decoding). We certainly don't want to regress single frame WebP. It's not yet clear to me whether this feature will affect deferred image decoding for webp or not.

To answer your earlier question,

Yes, there is a way to identify whether a WebP image is animated or not by parsing the headers. (I'm already using this check in the patch as well. See how the ANIMATION_FLAG is used for this.)

And so, the deferred image decoding of a non-animated WebP image would be retained.

Once again, let's be clear that non-animated WebP images are not affected in any way by adding this feature.

[Elliott Sprehn]

I'm aware of this discussion, but all the things in the intent to implement email seem true for APNG _except_ that Chromium has an agenda to push WebP.

Since Presto is dead, and Mozilla is not even sure they want to support the basic format, Animated WebP doesn't seem to have support from other vendors so we're effectively pushing for browser specific content until Mozilla or MS agrees to support the format. On the other hand if we implemented APNG we'd get the same benefits, plus there's already another browser with an implementation.

It doesn't make sense to me for us to get so upset about browser specific CSS properties, but push forward with browser specific image formats...

Can we wait until Mozilla or MS agrees to support this format?

- E

[Christian Biesinger]

APNG is not nearly as interesting as WebP in my opinion, because APNG
only gives you animation, whereas WebP gives you much smaller image
sizes. And the official PNG authors have rejected APNG. So I'd much
rather see us trying to convince other websites and browser vendors to
care about WebP than to implement APNG -- lack of interest from
content authors was cited by Mozilla as an important argument against
WebP.

-christian

[Stephen Konig]

On Thu, Apr 11, 2013 at 3:04 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd much rather we support APNG. Adding WebP support doesn't get web interop at all since Gecko doesn't even support the basic format. Adding APNG support would be immediately useful since it's already supported in another browser.

Adding animated WebP also now seems almost a slight to the other vendors seeing as we're adding extensions to a format no one else has yet to implement (sadly Presto is dead).

This thread isn't about APNG; if you'd like to propose that Blink support it, feel free to create your own proposal.  But I would note that I can apply your argument in reverse, even more powerfully: Adding WebP support elsewhere would be immediately useful since it's already supported in other browsers (two, in fact), and whose proven benefits that far exceed the just the ability to now have animated PNGs.  As for Presto, it may be dead but Opera support for WebP will remain thanks to Blink.

Can we wait until Mozilla or MS agrees to support this format?

Again, I don't see how this is relevant.  If we were discussing whether to introduce WebP support, I could see your point; but we're talking about supporting additional features to a format that's already supported.  Adding this now does nothing to change the calculus on the part of other browser vendors on whether to support WebP, nor does their support or lack thereof really inform a question as to whether we should support the latest version of the decoder.

[Peter Kasting]

On Thu, Apr 11, 2013 at 12:59 AM, Eric Seidel <ese...@chromium.org> wrote:

But given that we are already shipping WebP, I see no reason why we
shouldn't support this newer version of WebP which includes animation.

If anyone can be considered the owner of the current image decoders, I think I can.  So hopefully my position carries some weight.

That position is similar to Eric's.  I don't think this represents a feature addition that needs discussion from the "web platform compatibility" side.  This is an implementation detail of a feature we're already shipping.  Deciding to support WebP, when we weren't already shipping it, would merit such discussion; adding the decoder-framework-side of support for WebP subfeatures like color correction or animation does not.  I don't think that e.g. improving our support for color correction of other image formats (such as adding it for GIF, which can do color correction via a nonstandard extension) merits discussion at this level either.  (These things all merit discussion, but I see that discussion as being at a lower and more informal level, centered around whether the features are interesting at all and whether the code owners are happy with the idea of supporting them.)

I think arguing about supporting APNG is also out of scope here.  Whether or not we continue working on our shipping WebP implementation is unaffected by whether we are shipping, or plan to later ship, APNG.  I believe the folks bringing this issue up are unhappy that we're not currently supporting APNG and either feel that blocking animated WebP will make shipping APNG more likely, or feel like in principle it's unfair that we would even debate shipping APNG but have people like me arguing that we shouldn't debate WebP.  The correct response to this is to separately re-raise the APNG issue and argue that we similarly ought to take APNG, and we have been guilty of faulty reasoning in the past for not doing so.  In the course of this argument you will have to demonstrate that the PNG committee's opposition to APNG -- which is literally the only reason I see for opposing APNG -- is not something that should stop us from shipping that feature.  But all of that belongs in another thread.  "All these arguments apply to APNG too!" is completely irrelevant here since APNG is not under discussion.

Finally, I think hclam's comments about deferred image decoding have merit, but they're orthogonal to the question of whether this has to get web platform approval.  Those are questions of concern to the technical implementation of the feature.  And incidentally, I don't foresee any problems with preserving deferred decoding on single-frame WebP images.  (Or multi-frame images, assuming I understand the issues correctly -- ultimately, we ought to be able to do deferred decoding of those too.)

PK

[Peter Kasting]

On Thu, Apr 11, 2013 at 3:33 PM, Peter Kasting <pkas...@google.com> wrote:

The correct response to this is to separately re-raise the APNG issue and argue that we similarly ought to take APNG, and we have been guilty of faulty reasoning in the past for not doing so.

And just in case you think I'm being disingenuous here -- I never said in the recent thread about this that I was opposed to supporting APNG.  The closest I came was saying that the issue is perceived as having fairly small costs and benefits, which I think is accurate.  abarth said on the WK bug that Chromium is uninterested in shipping APNG, which is a position that didn't involve consulting me.  So please do not take this as a mealy-mouthed way of trying to shut down legitimate concerns.  You might find my position on APNG different than you expect.  But that position doesn't belong here.

PK

[Darin Fisher]

Peter's words resonate with me as well.  We have already decided to ship WebP.  I agree that animation is a significant feature, but an extension to something that is already an extension of the standard web platform, feels okay to fast track through our process.

I'm also really hopeful that we can optimize multi-frame images as well.  Like it or not, animated GIFs seem to be increasingly common on the web.  I wish they interfered less with page scrolling!

It seems like animated WebP has the opportunity to displace some of these animated GIFs, and if we can design animated WebP in such a way as to perhaps make it easier to implement multi-frame deferred image rendering, then that would be all the more reason to explore this feature.

Perhaps we should keep this feature behind a run-time flag until we are confident that it is implemented efficiently given our impl-side rendering / deferred image decoding model.

-Darin

On Thu, Apr 11, 2013 at 3:33 PM, Peter Kasting <pkas...@google.com> wrote:

[Ehsan Akhgari]

On Thu, Apr 11, 2013 at 6:32 PM, Stephen Konig <sko...@chromium.org> wrote:

On Thu, Apr 11, 2013 at 3:04 PM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd much rather we support APNG. Adding WebP support doesn't get web interop at all since Gecko doesn't even support the basic format. Adding APNG support would be immediately useful since it's already supported in another browser.

Adding animated WebP also now seems almost a slight to the other vendors seeing as we're adding extensions to a format no one else has yet to implement (sadly Presto is dead).

This thread isn't about APNG; if you'd like to propose that Blink support it, feel free to create your own proposal.  But I would note that I can apply your argument in reverse, even more powerfully: Adding WebP support elsewhere would be immediately useful since it's already supported in other browsers (two, in fact), and whose proven benefits that far exceed the just the ability to now have animated PNGs.  As for Presto, it may be dead but Opera support for WebP will remain thanks to Blink.

I only used APNG as an example of an extension of an existing image format which was not adopted by everybody and turned out to be a non-interoperable feature and a bad idea in the end.  I did not mean to distract this thread by mentioning it.  :-)

And just to make it clear, I actually do think that Mozilla shipping APNG without buy-in from other browser vendors was a bad idea.

 

Can we wait until Mozilla or MS agrees to support this format?

Again, I don't see how this is relevant.  If we were discussing whether to introduce WebP support, I could see your point; but we're talking about supporting additional features to a format that's already supported.  Adding this now does nothing to change the calculus on the part of other browser vendors on whether to support WebP, nor does their support or lack thereof really inform a question as to whether we should support the latest version of the decoder.

It's not going to change the calculus of whether or not other engines should support WebP, but once an engine decides that they want to support WebP, then may not necessarily decide to implement Animated WebP, in which case Animated WebP will end up in the same position as APNG did on the web, and I think that's what the guidelines for shipping new features in Blink were designed to prevent.

[Peter Kasting]

On Thu, Apr 11, 2013 at 4:03 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

once an engine decides that they want to support WebP, then may not necessarily decide to implement Animated WebP, in which case Animated WebP will end up in the same position as APNG did on the web, and I think that's what the guidelines for shipping new features in Blink were designed to prevent.

I would share your concerns more if I thought it realistic that someone might decide to ship WebP but not ship animation.  But I honestly don't see why anyone would do this.  The factors that led to browsers supporting PNG but not APNG aren't really present in this case.  And indeed my reading of the relevant Mozilla bug is that they're considering whether to support WebP as of the 0.3.0 spec/feature list.  Are you aware of vendors who might ship the situation you describe long-term, and why they'd do so?

PK

[Ehsan Akhgari]

Not to say that this is what will happen, but I can definitely see Mozilla implementing WebP but not Animated WebP (if we decide to support WebP at all) in case there is not enough demand for Animated WebP from developers, or at least resist it at first to keep the code simpler etc.  Or just simply because of lack of resources to implement support for Animated WebP.

--
Ehsan
<http://ehsanakhgari.org/>

 

[Stephen Konig]

On Thu, Apr 11, 2013 at 4:30 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

Not to say that this is what will happen, but I can definitely see Mozilla implementing WebP but not Animated WebP (if we decide to support WebP at all) in case there is not enough demand for Animated WebP from developers, or at least resist it at first to keep the code simpler etc.  Or just simply because of lack of resources to implement support for Animated WebP.

I would hope that should Mozilla choose to implement WebP, they'd support all of the features that are part of the WebP spec.  But even if they decided not to support animated WebP images, the net benefit to the web and to users from having broader WebP support would be huge.  I'd accept a small amount of feature fragmentation for that.

Stephen

[Elliott Sprehn]

I don't understand the purpose of these feature announcement threads if we're not going to have meaningful technical discussions about the impact the feature has on the web, if vendors will actually support it, and alternate competing ideas and existing support for those competing ideas (ex. APNG).

Certainly if I send an email about a CSS feature I'd hope people would discuss if another browser vendor had a similar feature that solved the same problem, or if that browser vendor had said they didn't plan to ever implement it.

- E 

[Alpha (Hin-Chung) Lam]

To be fair judging from the patch it seems to be safe with single frame WebP and deferred image decoding.

I agree that the architecture for impl-side painting is moving to cover multi-frame images such as animated GIFs and it can possibly apply to animated WebP as well. But what is our end goal of animated WebP in Blink? There is a significant difference in engineering effort between making it work and making it working beautifully. Top of my head I can think of several technical obstacles that makes rendering animated images difficult to optimize: main-thread decoding, limited size of image cache and lacking of seeking support. If our goal is to make this work beautifully then I think the effort needed here is much more than just an extension, e.g. color profile. If the plan is to make this just work, I will be sad to see this perform no better than GIFs (or worse because of complexity).

I don't think we have discussed the technical merits of animated WebP over other formats in this thread, notably WebM. As I understand WebP is based on-I-Frames of WebM. Other than lossless mode WebM in <video> can perform pretty much all the features with animated images. <video> is designed from the ground up and perform well in morden browsers. I did an experiment comparing WebM and GIFs (~hclam/cats.tar.gz/all_gif.html and ~hclam/cats.tar.gz/all_webm.html), despite higher complexity with WebM I can scroll 60FPS and only 10FPS with animated GIFs. I hope we realize they are comparable offerings to the user: <video> works wonderfully across all browser vendors; animated images remains a legacy pipeline that need significant effort to match. Given how bad browsers today handle animated GIFs today I am not hopefully animated images will be anywhere near <video> and that other browser vendors will put effort optimizing it.

My last point is about the use case of animated images, my last research shows that 0.2% of images in our data (ask me privately how to get this data) are animated GIFs. I will leave you guys to interpret this number.

Alpha

2013/4/11 Darin Fisher <da...@chromium.org>

[Stephen Konig]

I would just refer you back to what Peter said earlier:

I don't think this represents a feature addition that needs discussion from the "web platform compatibility" side.  This is an implementation detail of a feature we're already shipping.  Deciding to support WebP, when we weren't already shipping it, would merit such discussion; adding the decoder-framework-side of support for WebP subfeatures like color correction or animation does not. 

Stephen

[Peter Kasting]

On Thu, Apr 11, 2013 at 7:14 PM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:

I agree that the architecture for impl-side painting is moving to cover multi-frame images such as animated GIFs and it can possibly apply to animated WebP as well. But what is our end goal of animated WebP in Blink? There is a significant difference in engineering effort between making it work and making it working beautifully.

The end goal is to make animated WebP, as well as all other image formats we support, be as awesome as possible.  The work you've been doing to start cleaning up the GIF decoder, for example, is valuable work and there is lots more that we can and should do.

The goal is not "dump support into the product using some cheap implementation and run away".  Images are a huge part of the web.  IMO we have under-invested in our pipeline for them.  I will happily go to bat for you or anyone else who wants to sink more resources into making our image decoding better. Right now we use noticeably more CPU and memory than we should in a variety of ways.

That said, I don't think that "our image rendering pipeline has problems in general" is really a factor in whether or not to support animation in WebP.

I don't think we have discussed the technical merits of animated WebP over other formats in this thread, notably WebM. As I understand WebP is based on-I-Frames of WebM.

That's because that precise discussion already happened in one of the previous public threads on this.  It seems clear to me (and several points were raised in the last thread supporting this) that animated images are indeed a useful thing even with the existence of <video>.

 

Given how bad browsers today handle animated GIFs today

To be fair, a lot of this is because animated GIF is a horrible, horrible format that imposes many types of suck on the decoder.  I would be surprised if even a simplistic implementation of animated WebP was not noticeably more performant.

PK

[PhistucK]

Actually, this comment says they are more interested in the lossy and alpha features, unless I am misunderstanding -

https://bugzilla.mozilla.org/show_bug.cgi?id=856375#c22

I am not sure who Ralph Giles is, though, but he seems to be part of the Mozilla Video team according to his signature -

http://lists.w3.org/Archives/Public/public-webrtc/2011Jul/0037.html

You should check with them directly to find out whether they are indeed considering support for all of the features.

☆PhistucK

[PhistucK]

The second question (to which you did not respond) was really an elaboration of the first question. Sorry.

Will older browsers just show the first frame, or will older browsers not be able to read the image at all?

Android 4 - 4.2 (and Opera 11.x - 12.x, I guess) are not going away soon (platform updates are blocked by manufacturer or carriers in too many cases), so there is a compatibility risk with shipping this feature, encouraging websites to use animated WebP when those browser would just show broken images. The server should do much more than it needs if it had to browser sniff support for animated WebP since it must look into the image headers or something to know it is in fact an animated one.

☆PhistucK

[Stephen Konig]

On Fri, Apr 12, 2013 at 3:50 AM, PhistucK <phis...@gmail.com> wrote:

Will older browsers just show the first frame, or will older browsers not be able to read the image at all?

They won't be able to render the image at all.  We deliberately took this approach in order to simplify the file structure and parsing since one frame or none is probably not what the author intended.

Android 4 - 4.2 (and Opera 11.x - 12.x, I guess) are not going away soon (platform updates are blocked by manufacturer or carriers in too many cases), so there is a compatibility risk with shipping this feature, encouraging websites to use animated WebP when those browser would just show broken images. The server should do much more than it needs if it had to browser sniff support for animated WebP since it must look into the image headers or something to know it is in fact an animated one.

True, but this problem exists already and I don't see this feature magnifying its impact significantly.  For example Android ICS can only decode lossy WebP images, not lossless ones; you need JB in order to render lossless WebPs.  This problem can be worked around in a number of ways though (native app that bundles the most recent decoder, for example); and our forthcoming change to specify WebP in the Accept header (crbug.com/169182) will occur post-animated WebP being added, so if you check for that then you can safely return any WebP image.  Additionally, older browsers really aren't a concern here since the ones that support it today (Chrome & Opera) both provide auto-update.  

Stephen

[Adam Barth]

First of all, I'd like to thank everyone who participated in this thread.

I find myself agreeing with Eric Seidel [1], Peter Kasting [2], and Darin Fisher [3].  Specifically, given that we've decided to support WebP, we should support the latest and greatest version of the format, include color profiles and animation.

On the merits, 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.

Alpha asked [4] why we shouldn't just use <video> for animations.  This question was discussed some on the chromium-dev thread about APNG [7].  Unfortunately, when transcoding animated GIFs into WebP, we can't change the embedding context to <video>, we're stuck with <img>, which means we need to support animation in WebP in order to transcode animated GIFs.

I'm not sure anyone answered Dimitri Glazkov's question [6] about the standardization status of WebP.  The answer, as best as I can determine, is that the WebP spec is located at [7], which does the "heavy lifting" by referring to RFC6386 [8] for the bitstream definition.

To answer Dominic Mazzoni's question [9] about how WebP fairs on Blink's compatibility risk scale [10], I think a fair assessment is that it falls roughly into the third bucket.  The reason that the bucket isn't entirely clear is because there isn't an "appropriate standards body" for image formats.  Most image formats are specified somewhat informally on web sites [11, 12], the exception being PNG which is a W3C Recommendation [13].  WebP appears to have a complete informal specification of its container format and a formal specification of the bitstream at the IETF.

From a technical point of view, it sounds like the biggest risk is the one Alpha Lam raised [14] regarding the interaction between animation in impl-side image decoding.  For this reason, I agree with Darin Fisher that we should keep animation support for WebP behind a runtime flag until we can integrate animation support with impl-side painting.  However, we that shouldn't stop us from moving forward with the implementation.

I think we would all like to see other browser vendors adopt WebP.  Mozilla is currently in the process of evaluating WebP. We should do what we can to help them make that decision.

Adam

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/AgGZSfNTfuYJ

[2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/qJV1wxDyufEJ

[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/uC1-H3QnJgQJ

[4] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/6cSlpo8jcdUJ

[5] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/2xvXNJMsgxc
[6] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/F8v0x_QHxC4J

[7] https://developers.google.com/speed/webp/docs/riff_container

[8] http://tools.ietf.org/html/rfc6386

[9] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/R9c5jRAUGr4J

[10] http://www.chromium.org/blink/#compatibility

[11] http://www.jpeg.org/public/jfif.pdf

[12] http://www.w3.org/Graphics/GIF/spec-gif89a.txt

[13] http://www.w3.org/TR/PNG/

[14] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Y8tRC4mdQz8/7Vv8fGw3nkMJ

On Thu, Apr 11, 2013 at 12:54 AM, Urvang Joshi <urv...@google.com> wrote:

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 from github:
https://gerrit.chromium.org/gerrit/gitweb?p=webm/libwebp.git;a=blob;f=doc/webp-container-spec.txt;h=f3d753108a939e5c6a5d386018ef99305ee75770;hb=b66caee410bdc0cad5b1de2719098058a64658fe

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.

Usecases

Animated WebP is an excellent alternative to GIF images, and presents some important benefits over GIFs. For example,

• Each frame in an animated WebP can be lossy or lossless as per need.
  
• It has a true alpha channel (8-bit) as compared to a binary (1-bit) alpha in GIFs.

Adding support to animated WebPs in Chrome would make it possible for web developers to use it widely.

Compatibility Risk

• Opera supports non-animated WebP images (libwebp v0.2.0) as of now: http://www.opera.com/docs/specs/presto2.12/#m212-395
  
• Firefox is considering WebP support as well:  https://bugzilla.mozilla.org/show_bug.cgi?id=856375

OWP launch tracking bug?

(A normal bug)

https://code.google.com/p/chromium/issues/detail?id=229641

Row on feature dashboard?

Fits under an existing row:"WebP image format support"

[Eric Seidel]

Since our launch-process was updated since this thread started.  I wanted to be explicit:

This is LGTM to ship.

[Eric Seidel]

Apologies.  I'm attempted to review too many of these too quickly and got my wires crossed.

As Adam correctly stated, the consensus from API review, was that this is LGTM to *implement* behind a runtime flag.  With resolution of impl-side-painting concerns, this should be re-considered to ship.  (Technical bugs like that are not really the purpose of this process, but I'm glad the issue was raised during this as I at least had not considered the effect on impl-side-painting.)

LGTM to implement.

[Urvang Joshi]

Thanks guys, I'll go ahead with this then!

[Matthew Dempsky]

On Fri, Apr 12, 2013 at 12:27 PM, Adam Barth <aba...@chromium.org> wrote:

Alpha asked [4] why we shouldn't just use <video> for animations.  This question was discussed some on the chromium-dev thread about APNG [7].  Unfortunately, when transcoding animated GIFs into WebP, we can't change the embedding context to <video>, we're stuck with <img>, which means we need to support animation in WebP in order to transcode animated GIFs.

Looking at that chromium-dev thread, Scott Hess proposed that <img> tags could be extended to support video resources, and no one followed up on idea.  Is that ruled out for some other reasons?  E.g., why not just allow <img> tags to play WebM videos (perhaps without sound or something)?  What fundamentally distinguishes an audio-free WebM video from an animated GIF or animated SVG?  If <img> supported WebM, does animated WebP still serve a purpose?

[Alpha (Hin-Chung) Lam]

I wanted to point out that animated WebP are all I-frames and thus compress a lot worse than WebM for the same quality. The method of animation used in WebP is just the same as animated GIF. 

2013/4/15 Matthew Dempsky <mdem...@google.com>

[Adam Barth]

On Mon, Apr 15, 2013 at 2:31 PM, Matthew Dempsky <mdem...@google.com> wrote:

On Fri, Apr 12, 2013 at 12:27 PM, Adam Barth <aba...@chromium.org> wrote:

Alpha asked [4] why we shouldn't just use <video> for animations.  This question was discussed some on the chromium-dev thread about APNG [7].  Unfortunately, when transcoding animated GIFs into WebP, we can't change the embedding context to <video>, we're stuck with <img>, which means we need to support animation in WebP in order to transcode animated GIFs.

Looking at that chromium-dev thread, Scott Hess proposed that <img> tags could be extended to support video resources, and no one followed up on idea.  Is that ruled out for some other reasons?

I don't think it's been ruled out.  If we want to implement that feature, we'd want to start by socializing it with other browser vendors.  I suspect that supporting videos in <img> elements will have some implementation complexity because the rendering pipelines for <img> and <video> can be substantially different.  For example, Safari uses QuickTime to render <video> but renders <img> using CoreGraphics.

 

E.g., why not just allow <img> tags to play WebM videos (perhaps without sound or something)?  What fundamentally distinguishes an audio-free WebM video from an animated GIF or animated SVG?

I'm not sure there's anything fundamentally different.  It might be interesting to read the standards discussions around the introduction of the <video> element to try to understand why the working group chose to introduce a new element rather than re-use <img>.

 

If <img> supported WebM, does animated WebP still serve a purpose?

They're difficult to compare because the standardization and implementation timescales are very different.  Animated WebP is just an iteration on the WebP image format, whereas supporting video in <img> is a change to HTML.  That's not to say we can't change HTML, just that it requires broader discussion and consensus.

Adam

[Matthew Dempsky]

On Mon, Apr 15, 2013 at 4:07 PM, Adam Barth <aba...@chromium.org> wrote:

On Mon, Apr 15, 2013 at 2:31 PM, Matthew Dempsky <mdem...@google.com> wrote:

E.g., why not just allow <img> tags to play WebM videos (perhaps without sound or something)?  What fundamentally distinguishes an audio-free WebM video from an animated GIF or animated SVG?

I'm not sure there's anything fundamentally different.  It might be interesting to read the standards discussions around the introduction of the <video> element to try to understand why the working group chose to introduce a new element rather than re-use <img>.

I would imagine it's because of the extra functionality provided by <video> that couldn't be easily added to <img> cleanly.  E.g., selection between multiple resources based on media support and fallback for browsers that don't support the <video> tag.  Maybe the playback controls too.

The spec does forbid "non-image resources" from being presented by an <img> element, but I don't see anywhere that it defines "image resources" or distinguishes it from "video resources".  It would seem rather arbitrary to me to decide that an animated GIF or SVG counts as an "image resource", but an audio-free WebM counts as a "video resource" when they're functionally equivalent.

The <img> tag also expressly forbid interactive or scripted content, but neither of those apply to forbiding WebM in <img>.

If <img> supported WebM, does animated WebP still serve a purpose?

They're difficult to compare because the standardization and implementation timescales are very different.  Animated WebP is just an iteration on the WebP image format, whereas supporting video in <img> is a change to HTML.  That's not to say we can't change HTML, just that it requires broader discussion and consensus.

It still doesn't seem to me that supporting WebM in <img> requires a change to the HTML spec.  But like you said, it's probably still something worth discussing with other vendors.  Not much point in implementing it if everyone else opposes.

[nige...@golang.org]

On Saturday, April 13, 2013 5:27:40 AM UTC+10, Adam Barth wrote:

Most image formats are specified somewhat informally on web sites [11, 12], the exception being PNG which is a W3C Recommendation [13].

[11] http://www.jpeg.org/public/jfif.pdf

[12] http://www.w3.org/Graphics/GIF/spec-gif89a.txt

[13] http://www.w3.org/TR/PNG/

JPEG is defined by the International Telecommunication Union in ITU-T T.81: http://www.w3.org/Graphics/JPEG/itu-t81.pdf 

[nelson....@gmail.com]

Hey I'm really excited about WebP image extension, as me and fellow developers  have been waiting on .apng to become universally accepted for sometime.  The gif needs replaced badly, many alpha levels and losslessness are a must.  I was concerned the WebP was going to fail as it has been three years with little news, but I have just read that FB is using it, if they detect you are on the Chrome browser which is awesome.  Please keep up the good work, I assume it is currently difficult to make WebP animations as I have yet to see one online (I have been searching).  Keep up the good work!

sincerely,

-nelson

[Alex Russell]

I don't think we should hold implementation of this back.

On 11 Apr 2013 17:02, "Dominic Mazzoni" <dmaz...@chromium.org> wrote:

Just my $0.02, but I humbly suggest that we postpone this a while, since Blink is so fresh, and animated WebP doesn't fare very well according to the criteria under the "compatibility risk" section of chromium.org/blink.

I don't buy the argument that we're just upgrading to a new version of the upstream library - we could add all sorts of crazy undesirable features using that logic.

- Dominic

[Vladimir Vukicevic]

Matthew Dempsky wrote:

If <img> supported WebM, does animated WebP still serve a purpose?

They're difficult to compare because the standardization and implementation timescales are very different.  Animated WebP is just an iteration on the WebP image format, whereas supporting video in <img> is a change to HTML.  That's not to say we can't change HTML, just that it requires broader discussion and consensus.

It still doesn't seem to me that supporting WebM in <img> requires a change to the HTML spec.  But like you said, it's probably still something worth discussing with other vendors.  Not much point in implementing it if everyone else opposes.

I just independently suggested WebM (or other video formats) in <img>, behaving exactly like animated GIFs.  I would be in support of this... it's an easy path towards a significant improvement over animated GIF.  Autoplay, autoloop, no sound (no sound you could extend with an additional attribute that explicitly turns on sound).  I'd push for this in Gecko.

   - Vlad

[Ehsan Akhgari]

And hopefully nocontrols as well, right?

Should we consider accepting WebM everywhere that images can currently be used?  (For example, background-image, etc.)