Let's consider APNG support once again.

[Max Stepin]

Last time the APNG support idea was mentioned here on Chromium-dev, it was met with some skepticism, though not outright rejection:
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/0eL52wJPQhw/discussion
But some things changed since then, so maybe it's time to reconsider?

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

2. I hacked APNG support into Chromium and it's 100% functional, works just fine. For now, I put the code here:
http://sourceforge.net/projects/apng/files/Chromium/
I realize that patching two separate src/third_party/ projects (libpng and WebKit) is a serious obstacle. But it's not impossible, right?

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

So what do you guys think?

[Paweł Hajdan, Jr.]

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

2. I hacked APNG support into Chromium and it's 100% functional, works just fine. For now, I put the code here:
http://sourceforge.net/projects/apng/files/Chromium/
I realize that patching two separate src/third_party/ projects (libpng and WebKit) is a serious obstacle. But it's not impossible, right?

I think WebKit is the easier part, since we have a lot of WebKit committers on the team.

Getting the patch into libpng (especially libjpeg-turbo that we use) would be the biggest step - having custom patches there doesn't really sound like the best idea. Alternatively, if you can implement the feature on top of it, but without modifying libpng library (so that people who want can continue to use the system one) that's also something to consider.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

So what do you guys think?

I'll let others comment more on this.

Paweł

[Max Stepin]

I posted WebKit portion here, maybe someone could review it? For some platforms, that would be enough:
https://bugs.webkit.org/show_bug.cgi?id=17022

About libpng... upstream position is well known. But the apng patch for libpng exists for 6 years now, it's well known also. And it's well maintained. Besides, right now src/third_party/libpng is not a vanilla 1.2.45 anyway. It's custom-security-patched by Chromium. And it's almost 2 years old.

Mozilla updated their libpng copy many times over the years without problems, despite having to keep apng support, and it's currently at the latest version: 1.5.14. It's not too hard to keep it maintained.

[Peter Kasting]

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

Does WebP support animation yet?  (I know it's been planned.)  I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

[Bernhard Bauer]

On Mon, Mar 18, 2013 at 8:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

The latter is correct, but I wouldn't say that we ignore stars on bugs. They are a decent indicator of the relative importance of features compared to each other (and in fact we do tell people to star bugs they wish to be fixed), it's just that users who file/star bugs are not a representative subset of all of our users.

Bernhard.

 

Does WebP support animation yet?  (I know it's been planned.)  I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Peter Kasting]

On Mon, Mar 18, 2013 at 1:04 PM, Bernhard Bauer <bau...@google.com> wrote:

On Mon, Mar 18, 2013 at 8:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

The latter is correct, but I wouldn't say that we ignore stars on bugs. They are a decent indicator of the relative importance of features compared to each other (and in fact we do tell people to star bugs they wish to be fixed), it's just that users who file/star bugs are not a representative subset of all of our users.

And bugs with large star counts are usually victims of internet popularity contests, where people star some thing because someone on Slashdot told them to or whatever, but in reality the feature may not actually impact that person at all.  In fact, if anything, bugs with large star counts are often more likely to be WontFix.

Bugs with, say, 20 or 30 stars may actually be more important than bugs with 2 stars, though.  So maybe "ignore completely" is overkill :)

PK 

[Max Stepin]

> I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.

Actually no, if you read the reviews here:
https://chrome.google.com/webstore/detail/apng/ehkepjiconegkhpodgoaeamnpckdbblp/reviews
it's clear that people are installing it NOT preemptively. They are actually using it. Some are even complaining about Chrome performance when there are too many apng files on the page. And most on them wish for native support in Chrome.

WebP was added to WebKit, so why not APNG? I think adding 360 lines of source code into PNGImageDecoder.cpp is not a big deal. It's not a totally new format, just a simple extension over existing PNG, so it's easy to implement.

[Mike Frysinger]

On Mon, Mar 18, 2013 at 4:22 PM, Max Stepin <new...@gmail.com> wrote:
> WebP was added to WebKit, so why not APNG? I think adding 360 lines of
> source code into PNGImageDecoder.cpp is not a big deal. It's not a totally
> new format, just a simple extension over existing PNG, so it's easy to
> implement.

the annoying thing about APNG is that the PNG people themselves
rejected it. you can't say the same thing about WebP.
-mike

[Max Stepin]

APNG is the third-party extension over PNG.

The job of libpng is to be a reference library, not to support every PNG extension invented by third-parties. But it's open-source under permissive license, so...

[Mike Frysinger]

i'm aware of what APNG is. the authors submitted it to the PNG group,
and they rejected it, hence support was also rejected for adding it to
libpng.

the same can not be said of WebP support -- it's not relying on a
series a non-standard extensions to the official spec.
-mike

[Max Stepin]

I only mentioned WebP because Peter asked about "actual prevalence of APNGs in the wild" and it seems to suggest that people should start using a new format, and use it a lot, before it could be included in WebKit. So I wonder how WebP managed to avoid such Catch 22.

Many big-name distros like: Arch, Gentoo, Mageia, FreeBSD already ship with system libpng that is apng-patched. For those platforms, it's only a matter of WebKit using that extended libpng. My patch does all that by adding 360 lines into PNGImageDecoder.cpp

[Mike Frysinger]

i'm aware Gentoo supports APNG ... i'm the one who added it ;).  but that was purely because i had a device that used APNGs, not because it's something i think should see wider deployment.  it also doesn't come enabled by default ... the end user has to explicitly enable themselves.

really, the standard needs to be formalized by the PNG group themselves ...

-mike

[Pascal Massimino]

Hi Peter, all,

On Mon, Mar 18, 2013 at 12:47 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:

1. Presto supported APNG, so Opera devs would probably like not to lose that feature.

Presto had many differences from WebKit/Chromium.  I imagine the Opera folks will decide on a case-by-case basis what they wish to do about those.  For the moment, I wouldn't pre-emptively add APNG support with the explicit goal of minimizing differences with Presto.

3. APNG is actually in big demand now. People really like how simple-to-use GIFs are, and would love to have something just like that, but without color and alpha limitations. Look at crbug.com/1171, with 600 stars it's currently #10 most popular Chromium request. Also, look at APNG plugin for Chrome: it has 28000 users, and they must be visiting web pages with APNG files, otherwise they all would have no reason to install it.

We ignore stars on bugs; they're completely non-representative of anything regarding the userbase.

Does WebP support animation yet?  (I know it's been planned.)

yes, it's been in the HEAD codebase since quite some time now, along with the doc update [1].

The next official version (0.3.0) will freeze these into an official release (probably next week or so).

skal

[1] http://git.chromium.org/gitweb/?p=webm/libwebp.git;a=blob;f=doc/webp-container-spec.txt;h=929d5fa465cd82e009c6f74a61de0933815e9a7b;hb=HEAD

 

 I would assume that'd be the route we'd be interested in seeing as a long-term replacement for animated GIFs, given that it will compress better than PNG.

I am curious as to the actual prevalence of APNGs in the wild.  People installing a plugin doesn't tell me much.  Someone who likes APNG as a format might pre-emptively install the plugin and then not actually encounter any such images.  Servers might not serve APNGs to Chrome UA strings, and use GIFs instead.  Overall, it's hard to know what the size of the benefit here is.

Furthermore, if there is some sort of extension for this (you didn't link to the "plugin" you referred to), that might be a reasonable way to provide this kind of support.

PK

--

[Max Stepin]

When I tried gentoo 20121221.iso it just worked, I didn't have to enable anything. APNG worked out of the box. Just like with other distros.

[Mike Frysinger]

unfortunately, this was done specifically for desktop profiles based on the assumption that the majority of people will be installing firefox which itself requires apng support.  if firefox ever stops requiring that, it'll be dropped again.

-mike

--

[Max Stepin]

Firefox is never going to drop APNG support, there are too many APNG files in the wild for that.

[Daniel Bratell]

Den 2013-03-18 20:47:00 skrev Peter Kasting <pkas...@chromium.org>:

> On Mon, Mar 18, 2013 at 5:20 AM, Max Stepin <new...@gmail.com> wrote:
>
>> 1. Presto supported APNG, so Opera devs would probably like not to lose
>> that feature.
>>
>
> Presto had many differences from WebKit/Chromium. I imagine the Opera
> folks will decide on a case-by-case basis what they wish to do about
> those.
> For the moment, I wouldn't pre-emptively add APNG support with the
> explicit goal of minimizing differences with Presto.

While it sucks to lose features through the switch of web engine, I don't
think APNG is high on the list of things to restore support for. I'm sure
nobody would be sad to see it return, but I also don't think it will break
the web if it's missing. Bigger fish and so on.

/Daniel

[Max Stepin]

While it sucks to lose features through the switch of web engine, I don't  
think APNG is high on the list of things to restore support for.

 
That's perfectly understandable if you don't want to spend any time on this. But that's why I'm not asking people to write the code for apng support. I already wrote it. I'm only asking people to accept my patch.

I'm sure nobody would be sad to see it return 

Would you support my patch, then? I really don't see any negatives in accepting it, really. Only positives.

I'm a bit surprised at the reaction here. I have yet to hear any concrete, specific objections. What's the worst that could happen? 256-color, 1-bit alpha GIF will finally disappear as the '80s format? For 2013, it's long overdue.

[Mike Frysinger]

i think you're forgetting the bigger picture. every bit of active
code is increased maintenance and possible attack surface. so what's
the worse that could happen you ask ? the apng code has bugs which
allow people to post malicious/corrupt images that allow exploiting of
render processes which, when combined with other bugs, allow remote
execution on the system.

i'm not saying apng has these problems, just pointing out your
assumptions are fundamentally flawed here. "nothing is free".
-mike

[Max Stepin]

apng support adds like 5% to libpng size, plus 360 lines of code for PNGImageDecoder.cpp

Any new code is a possible attack surface, but this one is really really small.

And it's been exposed to the web by Firefox since 2008.

[Peter Kasting]

In fairness, though, image decoders are classically a key vector for exploits.  GIF support has been around far longer than APNG, and WebKit basically forked Firefox' GIF decoder, yet in the last year alone we've fixed multiple memory corruption issues as well as some other bugs with decoding.  So there is merit to the "we don't want the attack surface" argument just as there is merit to the "we don't want the maintenance surface" argument.  The issue is to what degree you perceive the pluses and minuses.  I suspect on this one, the perception is of a very small plus and some relatively small minuses.  The perfect recipe for apathy, or a bikeshed debate, depending on your point of view.

PK

[Max Stepin]

On Tuesday, March 19, 2013 10:41:36 AM UTC+4, Peter Kasting wrote:

In fairness, though, image decoders are classically a key vector for exploits.  

And no one would deny it. But most of the decoding work for png/apng is done by libpng. And while we saw some security updates for libpng over the years, I don't remember any of them caused by extra 5% apng functionality. Firefox exposed that functionality to the web since 2008 and Firefox is not an insignificant target.
 

So there is merit to the "we don't want the attack surface" argument just as there is merit to the "we don't want the maintenance surface" argument.

I'm not dismissing those arguments, but objectively, those surfaces are really small. Especially considering you want other browsers to adopt increasingly complex WebP. And by the way, I don't see anyone actively maintaining src/third_party/libpng anyway, it's stuck at very old 1.2.45 version since July 2011, while Mozilla regularly updates their libpng, and currently at the latest 1.5.14 version. Maybe you should just copy it from them, that would solve the maintenance issue and apng issue at the same time.
 

 The issue is to what degree you perceive the pluses and minuses.  I suspect on this one, the perception is of a very small plus and some relatively small minuses.

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus. "256 colors should enough for everybody" might have worked in 1989, but its 2013 now.

Nice comparison:
http://littlesvr.ca/apng/gif_vs_apng.html

 

[Stuart Morgan]

2013/3/19 Max Stepin <new...@gmail.com>

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus.

Do you believe that everyone would simply stop writing sites compatible with IE, Safari, and everything on iOS if Chromium supported APNG? If not, then claiming the plus here as "retiring GIF" is disingenuous.

I understand there's a chicken-and-egg issue here to some extent, but given that there's both an extension to add APNG support to Chromium, and also apparently a server-side polyfill that will translate APNG to canvas, it seems very unlikely that Chromium support is the deciding factor in widespread adoption. Which brings us back to Peter's point that the plus here seems quite small.

This probably isn't the right place for this discussion yet though; since the libpng part of your change isn't useful without the WebCore changes, starting on a WebKit list with trying to get that change accepted seems like the first step.

-Stuart

[Max Stepin]

On Tuesday, March 19, 2013 1:25:56 PM UTC+4, Stuart Morgan wrote:

Do you believe that everyone would simply stop writing sites compatible with IE, Safari, and everything on iOS if Chromium supported APNG? If not, then claiming the plus here as "retiring GIF" is disingenuous.

Well, it would be a significant push in the right direction.
 

I understand there's a chicken-and-egg issue here to some extent, but given that there's both an extension to add APNG support to Chromium, and also apparently a server-side polyfill that will translate APNG to canvas, it seems very unlikely that Chromium support is the deciding factor in widespread adoption.

Chromium support is absolutely the deciding factor here. On many serious websites (and even in some whole countries) Chrome+Firefox cover up to 80% of the users. That would be a significant jump from 25% share of Firefox, and people might actually start posting APNGs there. Other browsers would still see the first frame, it's a nice fallback mechanism.

 

This probably isn't the right place for this discussion yet though; since the libpng part of your change isn't useful without the WebCore changes, starting on a WebKit list with trying to get that change accepted seems like the first step.

I already posted the WebKit patch there and asked for review:
https://bugs.webkit.org/show_bug.cgi?id=17022
But nobody replied to me there, so I'm trying to have a discussion here instead.
I believe there must be some WebKit committers here too.

[Darin Fisher]

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

I think the answer probably involves http://sourceforge.net/mailarchive/message.php?msg_id=131482.  I am a bit nervous about supporting PNG extensions that the "PNG experts" have rejected.  I don't know the basis for their rejections, etc.

-Darin

[Max Stepin]

On Tuesday, March 19, 2013 7:22:41 PM UTC+4, Darin Fisher wrote:

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

Because official libpng is suppose to be the reference implementation of PNG. While PNG specs clearly allows extensions by using third-party chunks, the reference implementation doesn't have to support such third-party functionality. But libpng is open source, with permissive license, so its functionality can be extended by others, there's nothing wrong with that. 

The patch is well maintained (by me) for years now. And as already mentioned, apng-patched system libpng is a part of some well-known distros, for years. It doesn't cause any problems for them.

[Adam Barth]

Max,

Thus far it looks like you're the only advocate for APNG on this thread.  Perhaps we should give other members of the Chromium community a chance to voice their views on this subject.

Adam

[Dominic Mazzoni]

I don't buy the argument that we shouldn't support it because libpng won't accept it, or because the PNG standards group won't accept it. Chromium implements lots of de facto web standards when they're adopted by other browsers and used by web developers. In fact, we probably implement several de facto web standards that are far less prevalent than APNG.

If the consensus is that we don't want to take APNG now because the added technical and security cost don't seem worth the user benefit, that's fine - I don't have a strong opinion there - but I think we should keep an eye on adoption and reconsider if it seems to be growing in popularity among web developers.

Max, thanks for your work in creating the patches and for having a great civil discussion and for sticking to facts and technical arguments.

- Dominic

[Peter Kasting]

On Tue, Mar 19, 2013 at 1:01 AM, Max Stepin <new...@gmail.com> wrote:

Well, minuses are small, but objectively, pushing obsolete and awkward-to-handle GIF format into retirement would be a big plus. "256 colors should enough for everybody" might have worked in 1989, but its 2013 now.

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.  It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

On Tue, Mar 19, 2013 at 8:22 AM, Darin Fisher <da...@chromium.org> wrote:

Why does APNG require a patch to libpng?  Why isn't APNG supported as part of libpng?

I think the answer probably involves http://sourceforge.net/mailarchive/message.php?msg_id=131482.  I am a bit nervous about supporting PNG extensions that the "PNG experts" have rejected.  I don't know the basis for their rejections, etc.

From a combination of memory and Wikipedia: the PNG format was intentionally designed as a single-image format, and the spec notes ( http://www.libpng.org/pub/png/spec/1.1/PNG-Misc.html#Multiple-image-extension , http://www.libpng.org/pub/png/spec/1.1/PNG-Rationale.html#R.Why-not-these-features ) that multi-image cases are explicitly not to be supported in PNG.  The PNG standard committee worried about the consequences of reversing this decision, e.g. that because of Mozilla's decision to make APNGs backwards-compatible, non-supporting editors would fail to notify users that the image had multiple frames, or would modify the image unexpectedly (removing the animation) on loading it and saving it back out.  Basically, the committee wanted to see animation implemented using something that was distinct from existing PNGs, whereas much of the design goal of APNG was precisely to be "a PNG, plus some extra stuff supporting clients may additionally understand".

PK

[Darin Fisher]

Thanks for digging up that history, Peter.  I agree with you that animated WebP seems  much more compelling than APNG.  I'd much rather put effort into making animated WebP ubiquitous.

Dominic, it is true that compatibility across implementations (different browsers) is what matters most.  Features don't need to be codified as standards to be adopted by browsers, etc.  That said, I figured the PNG group probably had some reasons for rejecting APNG, and based on what Peter wrote, it seems like those reasons are rational.

-Darin

[Max Stepin]

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too? At least APNG is very simple with the nice fallback to static PNG for all other browsers. If it's "reasonable to consider alternatives to APNG " why can't we at first give a serious consideration to APNG itself? Wouldn't that be fair? We have not even touched any technical stuff yet.

 It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

I don't you're being fair, since it's completely false. Even GIFs can do deltas, and APNG can do everything GIF does. You absolutely can encode deltas in APNGs, just look at the "GIF vs. APNG" comparison here, it includes the filesizes:

http://littlesvr.ca/apng/gif_vs_apng.html

[Max Stepin]

On Wednesday, March 20, 2013 8:30:44 AM UTC+4, Darin Fisher wrote:

Thanks for digging up that history, Peter.

Here's more history to consider:

http://www.boutell.com/innards/apng.html

[Darin Fisher]

On Tue, Mar 19, 2013 at 9:32 PM, Max Stepin <new...@gmail.com> wrote:

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too? At least APNG is very simple with the nice fallback to static PNG for all other browsers. If it's "reasonable to consider alternatives to APNG " why can't we at first give a serious consideration to APNG itself? Wouldn't that be fair? We have not even touched any technical stuff yet.

Yes, WebP adds attack surface.  However, WebP offers tremendous benefits (in terms of bandwidth savings), so it seems worth the cost to us.

-Darin

[Darin Fisher]

Thanks for the link.

-Darin

[Peter Kasting]

On Tue, Mar 19, 2013 at 9:32 PM, Max Stepin <new...@gmail.com> wrote:

On Wednesday, March 20, 2013 2:30:37 AM UTC+4, Peter Kasting wrote:

Which is part of why I mentioned WebP.  If we're going to bootstrap a replacement for animated GIFs anyway, it's reasonable to consider alternatives to APNG -- and WebP has some notable advantages.

Don't you think your arguments against "APNG attack surface" might apply apply to increasingly complex WebP too?

Absolutely, but we've already made a decision to include WebP, and that decision isn't what's at issue here.  We're talking about adding APNG or not in addition to WebP.

 

 It compresses better than PNG anyway, but crucially, APNGs don't do any kind of delta compression from one frame to the next -- each frame is considered in complete isolation.  For animations longer than a few frames, this can mean APNGs blow up in size even compared to GIFs.

I don't you're being fair, since it's completely false. Even GIFs can do deltas, and APNG can do everything GIF does. You absolutely can encode deltas in APNGs, just look at the "GIF vs. APNG" comparison here, it includes the filesizes:

http://littlesvr.ca/apng/gif_vs_apng.html

I don't really see how this page proves either of our statements.  "X can be bigger than Y" is not falsified by finding three cases where X is not bigger than Y.

I would be very surprised if APNG can really "do everything that GIF does" since GIF does many things, a lot of them stupid.  (I am pretty familiar with the GIF format, sadly.)

Finally, I was pretty careful not to put an editorial slant of my own onto the PNG committee's decision to not standardize APNG.  For the record, at the time it happened I disagreed with the decision.

PK

[Max Stepin]

On Thursday, March 21, 2013 1:12:21 AM UTC+4, Peter Kasting wrote:

Absolutely, but we've already made a decision to include WebP, and that decision isn't what's at issue here.

Of course, but I'm talking about other browsers. You don't think by promoting WebP for the whole Web you might encounter the exact same arguments from others? What would be your counter-arguments then? I want to borrow them for APNG support... ;)

It seems that situations are kinda similar: WebP was invented mostly to be a JPEG alternative, and APNG was invented to be a GIF alternative. I have nothing against WebP as it's clearly better than JPEG, so it's a bit strange to see other people oppose APNG so strongly, even though it's similarly better than GIF. And it's very simple. And the code is ready.
 

I don't really see how this page proves either of our statements.

It just an illustration. I know for a fact those example have deltas, since I created them with deltas.
Why are you claiming that APNGs can't do deltas, even though the specs says they can?
Let's have arguments based on facts.

 

I would be very surprised if APNG can really "do everything that GIF does" since GIF does many things, a lot of them stupid.  (I am pretty familiar with the GIF format, sadly.)

Well, it can do all the important things GIF does: dispose and blend ops, deltas, delays etc. And it avoids a lot of GIF mistakes, for example APNG has the number-of-frames field in the acTL header. I'm sure you know it's a major pain for GIF: have to decode the whole file just to know the number of frames. With APNG you know if it's animated or static before you read the first IDAT chunk. And GIF doesn't even have 32-bit integer fields, only 8-bit and 16-bit, that's how ancient it is.

[Alpha Lam]

Hey Pascal,

Why should user use animated WebP instead of just WebM in video tag? Displaying animated images uses a different pipeline than <video> that is much slower.

Alpha

2013/3/18 Pascal Massimino <pascal.m...@gmail.com>