Animated PNG Support Is Still Being Blocked From Google's Chrome Browser

[rabcor]

APng/Mng vs WebP is like png vs jpeg. No one is better (png better for draw, while jpeg better for photo). Why don't support both? The web desiner will have the choice.
It's better than fight and force every one to use gif.

WROOOOOOOOOONG!

PNG is a lossless format, JPEG is a lossy format (in much the same way as FLAC is a lossless format and MP3 is lossy, but a thousand times more noticable since our eyes are more sensitive to distortions than our ears)

JPEG is better for file-size optimization
PNG always has better quality (And this is absolute unless you are using one of the experimental lossless JPEG variants that aren't really taking off)

Where the hell did the myth of "JPEG is better for photos than PNG" come from anyways? It's actually the opposite, photos and detailed graphical artworks are about the only two things JPEG can display without the viewer noticing significant quality degradation (because if there is enough variation in the image it gets harder to notice that the quality is shit). You wouldn't use jpeg for vector drawings or text. This is why: http://www.practicalecommerce.com/wp...png_vs_jpg.png and it's not because PNG is worse for photos, it's because JPEG is simply worse for everything.

JPEG basically fucking sucks except for web content (for bandwidth and server storage space optimizations). I want to see chrome support APNG, get with the times google! I have wanted to see GIF die for years now...

[smitty3268]

Where the hell did the myth of "JPEG is better for photos than PNG" come from anyways?

It came from the web. File sizes make jpg better for photos there.

[maxst]

They wanted to piggyback on PNG to push through their animation format. This was their central point, and also the "big nono" which other posters in this thread have complained about

But let's look at other recently proposed formats:
Animated WebP piggybacking on static WebP,
Animated BPG piggybacking on static BPG,
Animated FLIF piggybacking on static FLIF,
Fashions change, and what was "big nono" in the past, now is considered a "must have" accessory.
Someone else would've tried the same trick with PNG eventually, you can't be too conservative in the open source world.

As you mentioned MNG: The Mozilla MNG story is in itself a pretty depressing one

The most depressing story is MNG specs. Please tell me why would anyone need MAGN chunk features? Please tell me how could you manipulate MNG sprites without GUI authoring tools? Let's say you need to move that sprite a bit to the left, but how? Etc etc... And on top of that, HTML standard allows only simple animations inside <img> tags, nothing too complex. So not all MNG could be allowed, only some subset. It's a huge mess, and not a single developer wants to touch it, even MNG devs themselves gave up years ago.

https://en.wikipedia.org/wiki/Overengineering

https://en.wikipedia.org/wiki/Feature_creep

Chrome devs in 2011:
"If we were to implement a new animated image format, we'd be much more likely to implement Mozilla's APNG format than MNG."
"much more focused design"

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/0eL52wJPQhw/discussion

About the technical merits of APNG vs WebP I don't think enough data exists yet to conclude that either format is superior. We have datasets chosen by APNG proponents which show that APNG does better and we have datasets chosen by WebP proponents which show that WebP does better.

1. WebP devs only published the results, instead of their datasets, so it's impossible to verify.
2. They only compare WebP against source GIFs, never against APNG.

[LinAGKar]

And yet, I see animated GIF on Google's front page right now, celebrating leap year. Just like every image shouldn't be a JPEG, not every animation should be a webm/mp4. There are some use cases when you really don't want artifacts.

H.264 has a lossless mode though.

[chithanh]

it's not because PNG is worse for photos, it's because JPEG is simply worse for everything.

JPEG has a much better quality per bit than PNG for photos. A PNG photo that is 1 MB in size will be inferior to a 1 MB JPEG.

Of course you can compare a 15 MB PNG to a 1 MB JPEG and claim that the PNG is better, but that is not exactly a fair comparison.

But let's look at other recently proposed formats:

And you know what makes Mozilla stand out from these? They were the only ones who deemed it necessary to trample over other people's standards.

Fashions change, and what was "big nono" in the past, now is considered a "must have" accessory.
Someone else would've tried the same trick with PNG eventually, you can't be too conservative in the open source world.

Again, this is besides the point. Of course Mozilla can take the PNG format and turn it into something which does animations. But (given they are not owners of the PNG standard nor act with the approval of the owners) the result of that will not be PNG. And they pretend it is PNG (as evidenced by Vlad's comment) and try to pull off an embrace&extend/hostile takeover/whatever you may call it. And then they wondered why users got angry and why they got laughed out of the standards bodies they took their APNG format to.

So not all MNG could be allowed, only some subset.

"only some subset" seems deliberately trying to frame it as worse than it actually was. The subset is well defined in MNG-LC or MNG-VLC profiles.

Chrome devs in 2011:
"If we were to implement a new animated image format, we'd be much more likely to implement Mozilla's APNG format than MNG."
"much more focused design"

I am not proposing MNG here, I am just pointing out the disgusting behaviour of Mozilla folks against the libmng author.

1. WebP devs only published the results, instead of their datasets, so it's impossible to verify.
2. They only compare WebP against source GIFs, never against APNG.

That statement is false.

In the very thread which you started, Google employee Chris Blume did an informal comparison from Imgur which showed WebP to perform slightly better than APNG.

https://groups.google.com/a/chromium.org/d/msg/blink-dev/KcMjmFOgG2w/KTlc1FRbDQAJ

[maxst]

H.264 has a lossless mode though.

If you convert GIF into lossless H.264 or lossless VP9 and it becomes bigger than the original GIF, what's the point?

[LinAGKar]

If you convert GIF into lossless H.264 or lossless VP9 and it becomes bigger than the original GIF, what's the point?

You mean due to the GIF being 8-bit color? That's because the GIF ruins the colors. Ideally it would be 24-bit color all the way. But I suppose an 8-bit mode would be useful for images with few colors, and for converting from GIFs.

[maxst]

And you know what makes Mozilla stand out from these? They were the only ones who deemed it necessary to trample over other people's standards.

PNG allows for official registered chunks, and unofficial unregistered ones. PNG spec says: "Applications can also define private (unregistered) chunk types for their own purposes. The names of private chunks have a lowercase second letter, while public chunks will always be assigned names with uppercase second letters." Mozilla asked for the permission to use uppercase second letter in chunk names, like aCTL, fCTL, fDAT but PNG devs refused, and Mozilla settles for lowercase second letter: acTL, fcTL, fdAT. They can define and use lowercase chunks for their own purposes. PNG spec is very clear about that.

But (given they are not owners of the PNG standard nor act with the approval of the owners) the result of that will not be PNG. And they pretend it is PNG (as evidenced by Vlad's comment) and try to pull off an embrace&extend/hostile takeover/whatever you may call it.

It's still PNG according to spec. I can define my own chunk and put GPS coordinates in there, if I want to. I can't use uppercase since it's reserved for official registered chunks, but I can use lowercase without asking them for approval. It would be legal PNG, just with GPS coordinates inside. Nothing's wrong with embrace&extend.

"only some subset" seems deliberately trying to frame it as worse than it actually was. The subset is well defined in MNG-LC or MNG-VLC profiles.

That's not what HTML specs for <img>tag says. Just that "interactive MNG files" are not allowed. They don't mention profiles.
MNG devs eventually realized it's going nowhere, and attempted to make MNG2.0 by eliminating lots of stuff, including LC / VLC profiles:

http://osdir.com/ml/graphics.png.general/2007-09/msg00001.html

But they lost interest pretty soon, just like they lost interest in original MNG.

That statement is false.
In the very thread which you started, Google employee Chris Blume did an informal comparison from Imgur which showed WebP to perform slightly better than APNG.
https://groups.google.com/a/chromium...w/KTlc1FRbDQAJ

One GIF is not really a dataset. That's a short 16-frame GIF and after testing on hundreds files, I can assure you WebP fails badly on longer GIFs. That's why you need a dataset, not just a single file.

[chithanh]

It's still PNG according to spec. I can define my own chunk and put GPS coordinates in there, if I want to. I can't use uppercase since it's reserved for official registered chunks, but I can use lowercase without asking them for approval. It would be legal PNG, just with GPS coordinates inside.

It is not, as was pointed out to you by ssokolow. It is PNG+vendor extensions (which violate guarantees given by PNG spec) by Mozilla.

Nothing's wrong with embrace&extend.

I don't doubt for a second that you (or Mozilla) don't see anything wrong with it. In fact the history of the web has been a big embrace&extend story. Mozilla only ever has a problem with embrace&extend when it works against them (like -webkit CSS extensions on mobile websites).

This is how things would have gone had Mozilla succeeded in their approach:

1. Mozilla browsers start to support PNG with animation
2. Web developers notice that PNG does animation in their Firefox now, w00t!
3. Other browser users don't see the animation but still the first frame, which is Good Enough™. Use of animated PNG slowly spreads.
4. Pressure mounts on competing browsers to support that too, lest their users get suboptimal experience.
5. Pressure mounts on libpng authors to accept APNG patches
6. Congratulations! Without any standards body deciding, Mozilla have now pushed their own format into the web.

Thankfully, they failed at step 4, and are not likely to succeed because their market position is diminishing.

Embrace&extend is actually the whole thing Google is trying to fix with APNG right now. Disentangling APNG from PNG. Stopping the hijacking.

It would in my view consist of three steps:

1. Stop pretending that APNG is PNG.
   Get a different MIME type for it. Stop telling web developers to send out APNG as PNG.
2. (not quite the same, but closely related) No longer make web developers guess based on Browser vendor and version whether it supports APNG. State explicitly in the HTTP request header whether the browser supports APNG. In my opinion this would also include treating anything sent as image/png as a single PNG image and ignore the animation part if one exists.
3. (optional, nobody is working on this AFAIK, but desirable from my point of view as a lowly distro packager) Stop distributing your APNG decoder as patch to libpng. Write libapng instead which calls into libpng as necessary. If the libpng API is insufficient, work with libpng to improve the API. Only if that turns out unfruitful, consider a fork.

But they lost interest pretty soon, just like they lost interest in original MNG.

I repeat: I am not proposing MNG.

One GIF is not really a dataset.

Yes, it is. A small dataset and not very useful, but nonetheless one.

That's a short 16-frame GIF and after testing on hundreds files, I can assure you WebP fails badly on longer GIFs. That's why you need a dataset, not just a single file.

Why that is, and why a dataset which contains only GIFs is insufficient, has been explained to you by LinAGKar.

[maxst]

Stop telling web developers to send out APNG as PNG.

Who's telling them? Nobody.

Most people are not webdevs, they simply upload images into their favorite platform in whatever format the platform allows them. And some of them will always try to push the envelope. They *will* upload animated <insert format>, unless the platform would actively detect and block it.

In my opinion this would also include treating anything sent as image/png as a single PNG image and ignore the animation part if one exists.

I'm not sure how that would work.
Right now the browsers read first 6-8 bytes, detect GIF / PNG / JPEG signature from there, and initialize GIF / PNG / JPEG decoder. That's it.
Chrome is doing the same with WebP, they make no attempt to separate static from animated.
They detect the signature from first 14 bytes, then initialize WebP decoder.

a dataset which contains only GIFs is insufficient.

Tell it to WebP developers, they only made GIF->WebP converter, and after converting 7000 gifs, they posted the results here:

https://developers.google.com/speed/webp/faq

They never wrote APNG->WebP converter, they never attempted to start from APNG.