The Mystery of the Spotty Animated GIF | Hacker News Reader

The Mystery of the Spotty Animated GIF

smerity.com

On the "Random Thought": The GIF doesn't need to be animated. A GIF is made of multiple frames and each frame contains multiple image blocks. Each image block has its own coördinates and color table. You should be to use multiple image blocks in one frame (GCE block) to get one frame with 24-bit color.

For historical reasons most browsers don't respect a frame delay of 0 (computers used to be slow enough that even a 0 delay was good enough for animation; as they got faster browsers added extra delays to make old animations work correctly), but I think some renderers will correctly treat it as one frame (at least http://slbkbs.org/jsgif/ does! It has other problems with tricky GIFs, though -- the disposal method code is broken, for one).

Of course, you should just use PNG.

There's an example of a true-colour GIF on this page:

http://phil.ipal.org/tc.html

Thanks for pointing that example out! I should have searched when I wrote about it, but it just tangentially dawned on me that true-colour GIFs were possible as I was writing the article.

If I drag that true color GIF in Safari, it doesn't do the drag with transparency like the other two. Weird.

I always wondered if there's efficient GIF compress trick for Cinemagraphs. Looks like GCE is promising.

I always wondered if there's efficient GIF compress trick for Cinemagraphs

LZW compression is primitive. Even in simplest case of all transparent pixels it can only do "repeat previous pattern and add 1 pixel to it" and has to start over every 4K repetitions.

But it's also easy to hack! I've developed lossy GIF compressor: http://pornel.net/lossygif

it's still worse than PNG, but would be awesome for animations. Anyone wants to help? https://github.com/pornel/giflossy/

I never considered how LZW doesn't do RLE!

LZW was probably chosen over Deflate for simplicity reasons. Maybe webP's complexity has been hurting its adoption?

How does giflossy work? I don't see an explanation on that page.

lossy is simple — in the "pick the longest matching string from the dictionary" the match is allowed to be imperfect.

GIF lives because it's expected to work everywhere. WebP so far isn't even a first-class citizen in Google's world :(

Good article, but all of the GIF formats are certainly newer than CDs. Even LZW is newer. CDs have been around widely since 1982 while GIF 87a & 89a came out in ... Well you can guess that.

And the thing it's famous for, the "Netscape looping extension" (NAB) ... that's from 1995 (Netscape Navigator 2.0b4). Yes, there was a time when IE would only play a GIF once and Netscape would loop it.

Oh, you kids and your high-bit-depth graphics. I remember a time when having GIFs with different palettes would cause the colour lookup table for the whole graphics card to be overwritten (last image loaded wins), and much ugliness and hilarity would ensue.

on the subject of GIF animations, they're still the best method for doing very compact animations / demos when few colors are needs. in my case i needed to produce some image scan pattern animations for online docs and what i ended up with after many iterations of screen recording software, codecs and compressors was:

screen-record using a free lossless codec eg http://lags.leetcode.net/codec.html

i used Virtualdub which can produce and AVI, but also an animated GIF. then compress the result using http://www.lcdf.org/gifsicle/

result is extremely tiny filesizes for animations that can be embedded in any web page. hopefully this saves someone a lot of sleuthing work.

I'm just waiting for WebP to take over the world.

You'll need to wait a while longer, then, I think. GIF really should have died a long time ago. It's technologically inferior and lives in only the smallest image niche of the web, animation.

WebP should win over GIF. It's smaller, can be either lossy or lossless, supports full transparency, has animation, ... except for the fact that almost all GIF usage is (a) "clipart", (b) forums/comments/emails or (c) raw links (i.e. Imgur).

When I say clipart, I meant that most GIF image use would be people using GIFs made by other people. The Internet has a large treasure trove of GIFs that people will re-use from here to eternity. I doubt anyone will ever bother to convert the GIF to WebP.

Even if they did, if your browser doesn't natively support WebP[1] then you need a Javascript shim. Most people won't know what a shim is or won't be allowed to arbitrarily inject JS into the forum/comment/email. With raw image links, it's obviously not possibly to add a JS shim either.

I hate to say, but I think we're going to be stuck with GIF for a while longer...

[1]: http://en.wikipedia.org/wiki/WebP#Support

You'll need to wait a while longer, then, I think. GIF really should have died a long time ago. It's technologically inferior and lives in only the smallest image niche of the web, animation.

And GIF's reprieve got extended thanks to Tumblr images of Tom Hiddleston mouthing words, of all things.

APNG is a viable replacement for animation. APNG animations have long been supported in the release versions of firefox and opera, and there is an extension to enable them for chrome. Browser that do not support it will still render the first frame as a static image.

I was going to mention APNG but honestly it's dead. The PNG Group itself decided not to embrace APNG in April 2007. The format's years old now and even if it were to make a comeback, it still faces all the same issues as WebP except without backing from a single major party.

APNG's degraded support is possibly even worse for adoption. It has all the same issues as WebP (see the shim discussion above) bundled with the fact that people don't expect PNGs to move.

People either (a) don't know it's broken (i.e. think the single frame means it's a static image) or (b) know it's broken and chide you for using PNG instead of GIF.

The article doesn't really explain why the GIFs appear spotty, as far as I understand it. The first frame in an animated GIF surely has to be complete; after all there's no previous frame to partially update. Then, a GIF viewer that didn't handle animation would show the first frame only - which wouldn't have any odd pixels and gaps in it.

Good point, I guess I didn't add an explicit explanation, instead building up to it implicitly. I've fixed that now. Thanks for the feedback.

----

When the GIF software decides to take a snapshot of the animation instead of playing it, it grabs an individual frame from somewhere past the start (i.e. movie trailers always start with a "boring" black frame).

This would generally be fine except that, as we've seen, GIFs use partial frames to aid in compression. What we end up with is a partial frame that appears "spotty" as it only contains the difference between the past frame and the current one.

Then the problem lies with programs that do understand animated GIFs, and not those that don't!

If the GIF software can navigate multiple frames, then it must know how to render them. Its only lazy programs that would export these incomplete frames by just copying the bitstream. A properly written program would export a full frame, made from the composites of the previous parts of the animation.

The programs that are viewing these single frame exports are rendering them just fine, they were simply supplied with poor data.

I've always wondered about this!

Smerity!

- NCSS Student :D

Reply on news.ycombinator.com