I was hoping to write a Perlbal plugin that deanimated animated GIFs. As you might see from the GIF specification, the animation instructions are in a "Graphics Control Extension" block before the image data. I hoped removing the Graphics Control block by turning it into a comment would make browsers not consider it animated, but as you can see (original), they do find the other image data and keep animating. I guess you could (a) make the first frame hold for 10 minutes (the maximum pause the format allows), or (b) turn the rest of the file after the first image data block into a comment, at which point you probably might as well just make a deanimated "thumbnail" without the extra image data in.
This is what passes for fun around here.
Comments
comment
that game is billiant
comment
It does sound like a bit of fun.
I think (b) is the right thing to do. The spec notwithstanding, I had always understood that animated GIFs were just GIF with more than one “image”—the equivalent of just putting more stuff after a form-feed or something. I don’t know what really goes on out there, and I’ve only written a GIF parser once, but when I did, I seemed to observe that some GIFs just simply had extra crap at the end, and that’s what made ‘em animate. This is fuzzily-remembered stuff so your mileage may vary.
Are you meaning to do this on the fly when the image goes out?
comment
That was the idea, yeah. LiveJournal uses Perlbal to rewrite the color palette on GIFs so they can have one set of supporting images for any number of color variations on a journal theme. I thought it might make sense to do the same to deanimate GIFs.
It would have the benefit of being able to control the behavior with HTTP, like a
no_anims=1cookie or something, but you could do the same with rewriting rules in Apache too.