All APNG has ever really needed to build a sustainable momentum is--like most other web features--a plurality of web browser support. These days, that usually means "supported in both Firefox and Chrome." Until that happens, nobody has any reason to create APNGs, because you can't stick them in your cutesy forum signature and expect other people using the website to see what you see.
Firefox already has APNG support; Chrome is the hold-out here. It's mostly because Google only want to use the "official" libpng. libpng, though, is intentionally a minimalist reference implementation! The PNG group will never accept the APNG patches into the official libpng, because that would distract from libpng's purpose in being a reference for how to encode/decode PNGs. And Google don't want to apply the APNG patches themselves, because that means, basically, supporting their own fork of libpng.
In other words, what's really been needed this whole time isn't "better authoring tools" (create consumption tools, and authoring tools will follow) but rather for some large organization to get behind maintaining and supporting a regular release of "current libpng with apng patches." Big enough, at least, for Google to feel as confident in their work as they do the PNG group's.
The easy solution, of course, would be to split out the work Mozilla is already doing in maintaining their "current libpng with apng patches" from Gecko into a separate project, and let both Mozilla and Google (and Apple and Microsoft and whoever else) be consumers for that project. If there's anything to get done, it's that.
Alas, both have stalled: MNG was initially implemented by Mozilla but later dropped, and the PNG/MNG folks consider APNG a hackish substitute so are unlikely to standardize or support it.
However, Google (Blink) themselves rejected WebP animation (http://news.cnet.com/8301-1023_3-57594084-93/blink-leaders-r...) due to performance concerns.
Which brings up an interesting dilemma, which is balancing network performance with CPU or rendering performance.
We need a format that's optimal for mobile network transport, optimal for decoding speed, and optimal for rendering and memory. ;-)
Here's an animated GIF used for animation: http://i.imgur.com/rwUt664.gif
Here's an animated GIF used for video: https://mediacru.sh/demo
Obviously, in the video case, a real video format wins, and if social networks let us upload videos with the same filesize cap they allowed for images, you'd start to see short videos used in place of GIFs.[1]
However, in the animation case, video-encoding wouldn't even work--videos don't have alpha-layers, after all. In this case, animated GIFs are currently the only solution--and APNGs would be a decided improvement.
---
[1] This has only just become possible for video formats, though, so some latency in implementing a policy change like this is to be expected. Until recently "video on the web" meant Flash, and Flash content didn't have any of the viral properties of images; you couldn't just right-click a Flash <embed> to save the FLV from it, then upload it somewhere else and expect it to work. We do have that now with HTML5 <video> elements, but they're still pretty rare, and as long as there isn't a place to take the tiny-little-video-files from, nobody will have them to re-upload them to anywhere else.
- So you say, that APG (APNG) requires compatibility support from major browser and development support from a hard working organization, with relative financial support.
But what about, compatibility support in Photoshop, GIMP? I think the stretch goal amount should be spent on this, if anything. I don't want to try a new editor just for APG.
- One more suggestion I have is to make it as simple to use as Unfreez Program for creating GIF, which as simple as : 1. Drag and Drop 2. Type Delay time 3. Click "OK" to compile
http://www.whitsoftdev.com/unfreez/ (a very good program, damn simple to use for even a noob, only 19KB, I have used it for years to make animated GIF)
- Editing frames should be easy, but the whole program should not be as complex as animation software are supposed to be.
At first, it won't matter that it's difficult to create APNGs; like animated GIFs, one of the core strengths of APNG, given cross-browser support, is that they're inherently viral--you just right-click-save one to your desktop, and then you can stick it into any other app that expects an image (upload them to Imgur, drop them into Tumblr, use them as emoticons in a message in Gmail...) and they'll "just work."
The majority of people won't be authoring APNGs--just like the majority of people aren't authoring animated GIFs. Instead, most people will just be taking and resharing other people's APNGs. It could take a half-hour with ImageMagick to generate a valid APNG and it wouldn't matter, as long as you can take "translucent_pusheen_dance.png", stick it on your blog, and have it loop its cute little animation in full 32-bit RGBA glory.
As long as the original creator of the animation decided they would be better-served creating an APNG than an animated GIF, then everyone else will share and spread that APNG. But only if they can see it in their browsers, of course. The original creator won't care about the hassle of creating APNGs--we go through lots of hassles, as web-developers, to get things into arcane formats (e.g. spritesheets) so that clients can experience them slightly better. The content author's only consideration will be how many people can successfully see it, vs. what the quality of the thing they'll be seeing is. As soon as APNG can be seen in every browser animated GIFs work in, it'll be equal on one criteria, and beat GIFs hands-down on the other. But not until then.
(Edit: Also, it seems that name was selected by the author of the original CLI program for APNGs, who does not appear to be involved in this kickstarter)
Now, we'r stuck with all these trendy sounding SaaS projects that have adopted some of the most irritating names imaginable.
I wish people would stop dreaming up stupid website domains like:
dork.ly
fart.ly
retard.ly (note that in most cases, it would take a small leap of imagination to choose "retarded" over "retard" in case like this, but that opportunity is often squandered)
adverb.ly
grammar.ly
and-so-on.ly
...even worse is when someone truly brainless comes along, and adheres to the trend, but registers under a .com TLD, and still botches the grammar of the word. as in:
botchedly.com
I have always hated these sorts of names.
APG sounds more catchy.. just giving my nickels on the name, use it if you want.
This project is something I have been waiting for, like forever, the idea is very good, I hope the execution of this idea is good as well. Somehow I have high expectations (which is unusual for me for such works)
Are you pronouncing it as if it were the verb, "aping", like as in "poorly imitating a person's behavior in the primitive manner of an ape"?
My inclination was to spell out the letters of the acronym, as in "A-P-N-G", like: Ay, Pee, En, Gee.
I don't think they were targeting a funny name. I wonder if they're fluent in English.
Aping assembler?
I don't see much problem.
Automatic fallback to a normal static PNG is a terrible idea. If you want an animation format, give it its own extension and MIME type. The only reason why it works for GIF is that it's basically assumed to be animated nowadays, and it started out with animation support (as far as the web is concerned).
I don't see why fallback is bad. Having a single canonical file is so much nicer than multiple files. APNG has been around for ages. If you as an upload-accepting web dev aren't aware of it you're not a very good web dev. And as a user you don't even know what container an image is using 99% of the time, so MIME type doesn't matter. Browsers tend to ignore image MIME anyway because of how common mislabelings are.
I hate APNG personally, though, because I think MNG makes a lot more sense. The server can return what is appropriate based on standard HTTP content negotiation with that. APNG is just a stupid hack and the only reason Mozilla went with it instead of MNG is because is saves 100KB in the browser binary, which I couldn't care less about.
