OCT
7
2007

Animated GIFsanity

So I thought I would spend a tiny bit of time on the weekend trying to get khtml 4.0's gif decoder all finished. Yeah, right. Decoding the frames themselves is easy: giflib does it for us. The messy part comes when it comes to putting them together into an animation.

The way this roughly works is the following: gif has a canvas, which it calls the screen. It provides a palette, the index for the background color in it, and of course the dimensions.

For an animated gif, there is then a sequence of frames, each of which specifies the portion of the screen the frame touches. There may also be a per-frame palette, and a transparency colorkey. More interestingly there is a disposal mode, which specifies how to transition to the next frame:

  1. unspecified (always a good sign in a spec. Not!)<.li>
  2. leave screen as is
  3. clear to background
  4. revert to state before this frame

Sounds easy enough? Well, too bad it's not the entire picture.
Consider for example the mode 2: clear to background. For most images it behaves by clearing to transparency. What's the big deal? Well, the place the background color is specified is with the global palette... and there is no transparency in there! Transparency colorkey is specified per-image, so... how exactly is it supposed to work? Does one interpret background color inside the current frame's palette (which may be a local palette, or the global palette with the transparency colorkey overlaid..)? Does one just use transparency for background if there is transparency involved? Beats me.

And that, actually, isn't the worst. The messy part comes from compositing images. The images have transparency, so when one draws the new frame over the current canvas state, one has to combine them together. There are 2 ways of doing it:

  1. only draw non-transparent pixels (the over operator).
  2. copy over everything, overwriting non-transparent
    pixels with transparency (the src operator).

So which one is right? Both. There are images that need one mode, and there are images that need another... and one can easily construct images where both are in use, and it's entirely unclear how e.g. mozilla decides on which way to do things.

Anyone reading this know what's going on there?

Comments

This ambiguity is a sign that the animated gif standard is flawed - a good standard is unambiguous. IMHO, the best solution would be "bug for bug compatibility": mimic the behavior of some other web browser. Mozilla is a good candidate: it's open source (so one could just see the sources to tell how GIF rendering is implemented there), rather widespread, and I haven't heard any complaints about it rendering animated GIFs incorrectly. So, its behavior would be what most users expect. To save your time? you could just create a test suite of different GIF files and see how different browsers render them. Or just contact Mozilla maintainers - maybe they could shed a little light on that.

-----
60s: drugs, sex, rock'n'roll
90s: bugs, sux, drag'n'drop


By Gleb Litvjak at Sun, 10/07/2007 - 22:46

Over at the ImageMagick site is a complete tutorial about animated gifs, see http://www.imagemagick.org/Usage/anim_basics/


By bartv at Mon, 10/08/2007 - 09:25

Thanks for the link. I don't see it explaining anything, really, but it does have some testcases I get wrong atm...


By Maksim Orlovich at Mon, 10/08/2007 - 14:23