GNOME Developer Comes Up With New Animated Image Format

[Chewi]

I was pleasantly surprised to find that this even works in Opera 12. And it works well.

[erendorn]

Inefficient storage/memory isn't a huge issue. The main intended usage for this is self-contained illustrations, which are usually low bandwidth. Like these:
http://en.wikipedia.org/wiki/File:Circle_cos_sin.gif And if it's abused for lolcat videos, who cares about the bandwidth if it is entertaining?

Ah thanks, I was wondering what a real usecase was, as gifs nowadays are mostly used to display small videos, and as animated UI elements and animated smileys should simply be forbidden
But wikipedia has indeed many interesting animated graphs, which are indeed not suitably replaceable by video elements.

[Ronshere]

He needs to come up with a better name. Something easy to pronounce.

Exsengee ??

[curaga]

* Variable framerate (per frame delay defined, although I'm not sure if GIF89a also supported this already).

It does.

[Styromaniac]

Correction: I of course meant to say "even when lossy codec is set to best quality".

PS: It is really annoying edits are only allowed in the first few minutes after posting here. One often doesn't spot one's own error until a minute later or so, or you would not have made the mistake in the first place! The human brain just works (or rather, fails) like that...

I have a big issue with that in these forums. I might forget a key detail in my comment and I might not see my comment until the next day when it's too late to edit.

[Remdul]

Correction: I of course meant to say "even when lossy codec is set to best quality".

PS: It is really annoying edits are only allowed in the first few minutes after posting here. One often doesn't spot one's own error until a minute later or so, or you would not have made the mistake in the first place! The human brain just works (or rather, fails) like that...

[Remdul]

Storing each frame or even just each deltas is just a silly compression technique for videos, lossless or not.

But it's good for this sort of stuff. There are plenty efficient/optimized video compression schemes/formats to choose from, if you care about storage/bandwidth efficiency. But they all suck for GIF replacement. Of the top of my head, XNG should provide:

* Simplicity: this format just takes a series of JPEGs/PNGs and a preset framerate (all you need is an XML parser, libpng, libjpeg).
* No plugin/codec initialization, no graphics hardware invokation causing locks, stutter, or other latency isues in browsers.
* No audio, thus no audo codec, no audio subsystem issues (*cough* Linux!), no synchronisation worries.
* No delta compression, thus you can jump seamlessly to any point in a video (something we've had in 1995 but lost due to agressive delta/buffering optimizations).
* For same reason, play video backwards, or pingpong playback.
* Variable framerate (per frame delay defined, although I'm not sure if GIF89a also supported this already).
* Instant playback frame rate changes without codec/player going bananas (overshooting due to buffering etc).
* Non-lossless support that guarantees your colors/gradients won't be mutilated (pixel-perfect if you use PNG), which often happens even when lossless codec is set to best quality.
* Transparancy support (PNG).
* Grayscale (JPEG and PNG) without wasting two color channels.
* Grayscale+alpha support (PNG).

Inefficient storage/memory isn't a huge issue. The main intended usage for this is self-contained illustrations, which are usually low bandwidth. Like these:
http://en.wikipedia.org/wiki/File:Circle_cos_sin.gif And if it's abused for lolcat videos, who cares about the bandwidth if it is entertaining?

Yeah, it stutters/hangs in Firefox right now, but it seems already more practical in use than APNG or MNG ever was. I bet Mozilla will have this issue fixed by the next update.

[Delgarde]

He needs to come up with a better name. Something easy to pronounce.

I assume it's intended to be pronounced "zing", which is both easy and obvious enough...

[curaga]

Too bad this stutters and uses a ton of cpu in most browsers. Apparently no browser caches the base64-thing-in-SVGs.

[helgewl]

His animations stutter and stop in Firefox, unless one constantly moves the mouse in and out of the image frame (FF 33, Arch Linux).
This hack has been done before. The SVG animation on the following page runs smoothly:

http://sysmagazine.com/posts/201444/