Let me save the next person some trouble: The Python Imaging Library (PIL 1.1.5<\/a>) does not support writing<\/em> animated GIFs.<\/p>\n Update:<\/strong> A script that has been published may help. See comments.<\/p>\n It was suggested to me that my previous post<\/a> needed a few diagrams to explain the concepts. I thought about it the number of dimensions I was trying to explain, and decided that some simple machine-generated animations were probably the way to go here.<\/p>\n When I hear machine-generated images, I think of the Python Imaging Library. It has proven to be a very powerful tool on a number of small-to-medium toy projects that I have attempted.<\/p>\n I imagined that I would write a hundred or so lines of Python code that would spit out images of intersections in various states of traffic flow, and I would combine them together in a sequence to produce a a few animated GIFs, and then link the GIFs into appropriate places in the article.<\/p>\n (Some of you are cringing at the idea of getting involved in the GIF ex-controversy<\/a>, but I wanted animation, and couldn’t rely on browser support<\/a> for the uncontroversial GIF-alternative, MNG<\/a>.)<\/p>\n There are two GIF versions, GIF87a<\/a> and GIF89a<\/a>. For reasons I don’t quite get, even though GIF87a supports having multiple images, but GIF89a is required for real animation.<\/p>\n PIL 1.1.5 can read<\/strong> GIF87a and GIF89a [Ref<\/a>]. It can read each of the images in the sequence (see The GIF formats also include some metadata, which appears to be only partially supported by PIL 1.1.5. I found that the However, PIL 1.1.5 can only write<\/strong> to GIF87a. It cannot write to GIF89a. Therefore, it can’t be used to produce GIF89a animations.<\/p>\n I do not believe it can even be used to create new GIF87a sequences. (I can’t find any suitable methods.) I believe it can be used to edit existing (but useless?) GIF87a sequences, but I haven’t tested this.<\/p>\n In 1997, in an online thread titled: “Can PIL handle animated GIFs?<\/a>” appeared to suggest yes. I couldn’t find the referenced example code, but it seems to be a limited “yes”, and consistent with the restrictions above.<\/p>\n In May 2005, Ben Last<\/a> complained<\/a>:<\/p>\n The only thing that let me down was… the damn PIL. An imaging library that has some of the worst GIF support I’ve yet seen. Yes, I know all about the GIF patent issues, but de-emphasising support for a de-facto standard because of ideological convictions doesn’t work in the real world.<\/p><\/blockquote>\n He suggests some alternatives. (BTW, Ben, knolp!<\/a>)<\/p>\n Update:<\/strong> A script, described in the comments below, may help people looking to work-around this missing feature.<\/p>\n","protected":false},"excerpt":{"rendered":"Background<\/h2>\n
Findings<\/h2>\n
Image.seek()<\/code><\/a>).<\/p>\nImage.info()<\/code><\/a> method included “duration” and “loop” fields. The May 6, 2005 draft of the next PIL handbook<\/a> describes the “duration” field only.<\/p>\nOther References<\/h2>\n