Weird things I love about GIFs

I was recently reminded that I never wrote down all the weird things I learned about the GIF file format when implementing GIF decoding/playback at work last year. (I was reminded of this because I wrote a line in a corporate blog post draft that started with “If there’s one thing I love more than debugging rendering bugs, it’s reading specs about internet technologies,” and someone thought surely I was being sarcastic. I was not!) Without further ado, some strange things about GIFs (hard G because language evolves):

The compression algorithm used in GIFs was, way back in the day, under patent,

and in the 90s, some kerfuffles ensued about this, resulting in someone inventing PNG. PNG used to be PING, which stood for “Ping Is Not GIF.”

The GIF spec provides for encoding multiple images, but no one ever codified what this meant.

The most common usage of this is, of course, encoding multiple images to yield an animating image. But you could also use it to fit lots of colors into one image (since each image maxes out at 256 colors)! [See here.]

A later extension (the Netscape Application Block) introduced the concept of “loop count,” to indicate how many times the animating image should loop.

If you read this and think “loop count=1 loops once,” you would not be alone, and you’d be wrong:

|| loop count         || GIF plays N times      ||
||--------------------||------------------------||
|| unset              || 1                      ||
|| 0                  || infinite               ||
|| 1                  || 2                      ||
|| 2                  || 3                      ||

A value of 0 causes the GIF to loop infinitely; otherwise, browsers choose to interpret this value as “play the GIF once, then play n=loop more times” (an alternative interpretation might have been something like “play the GIF n times,” but then there are two different ways to play the GIF once, which is a bit weird).

GIF frames have a field to indicate frame delay (i.e. how long to show this frame before moving on to the next one).

But (in the interest of saving space), delays are encoded in hundredths of a second, not milliseconds, so 100 indicates one full second, which is a little strange.

It gets weirder: in the old days of the internet, a bunch of newfangled advertisers tried to make really annoying ad images by encoding super fast frames to flash wildly at people. Browser vendors decided this was not cool (and would kill browser performance, at that time), so at some point someone decided not to show frames with delays of <11 milliseconds, and to correct those frames by setting those delays to 100 milliseconds, and now this is what all GIF renderers do. So a frame encoded with delay=2 will render 5x faster than a frame encoded with delay=1 or delay=0. (See: [old Chromium bug with a Star Trek test case], [Webkit patch], [some Chromium code]). Here, then, is a GIF with delays encoded to 1 (10 milliseconds):

vs. the same GIF with delays of 2 (20 milliseconds):

GIF has a plain text extension,

where you can encode plain text that is meant to be rendered on top of the GIF. In other words, rather than rasterizing text on top of a GIF, you can just hardcode the text itself into the binary code, along with its intended position data and colors. If this doesn’t sound bananas to you, I must tell you: this is an absolutely bananas way to design an image format spec. (Browsers don’t actually render this block; you can check it out when you get to BOB_89A, below.)

GIF has a comment extension as well,

where you can encode plain text comments not meant to be rendered on top of the GIF. Which means you can bloat the size of your GIF by encoding a secret message that people can only see if they know to decode and inspect your GIF.

There’s a user input flag that you can use to indicate that,

instead of autoplaying the next frame after n hundredths of a second delay, we should wait until the user clicks or presses any key to advance frames. So yes, if everyone still respected the GIF spec, you could absolutely use GIFs as full-fledged slideshows.

Bob Berry, one of the creators of the file format, created a GIF to demonstrate all the new features in GIF89a (most of the good stuff — animation and transparency — came in ’89), and to teach people how to pronounce “GIF.” This is that GIF:

As you can see, it doesn’t look like an exciting GIF, because browsers don’t render the plain text extension; you need a special GIF inspector/custom renderer to view it. Behold, in all of its glory, BOB_89A (if you expand “Comments” in the bottom right, you can read the comments Bob encoded into this GIF about his Arizona vacation).

There are a bunch more old-school GIFs that use all the weird features, but apparently a lot of old-school internet dudes were gross and pervy, so a few of these involve naked cartoon women, and I’m not going to link them here.

Instead, my favorite GIF (my dog Thea reacting to men mansplaining things to me on video calls):