Optimizing GIF Playback For Microcontrollers

Despite being cooked up by Compuserve back in the late 1980s, GIFs have seen a resurgence on the modern internet, mostly because they’re fun. However, all our small embedded systems are getting color screens these days, and they’d love to join in the party. [Larry Bank] has whipped up a solution for just that reason, letting embedded systems play back short animated GIFs with limited resources.

[Larry] does a great job of explaining how the GIF format works, using LZW compression and variable-length codes. He talks about how the design of the format presents challenges, particularly when working with microcontrollers. Despite this, the final code works well, and is able to work with most animated GIFs of the right dimensions and construction. 24K of RAM is required, and image width is limited to 320 pixels. Images can be loaded from flash, memory, or SD cards, and he notes that best performance is gained with a microcontroller with fast SPI for writing to screens quickly.

It’s a great piece of software that promises to add a lot of charm, or silliness, to microcontroller projects. It also simplifies the use of animations, which can now be designed on computers rather than by using onboard graphics libraries. GIF really is the format that never seems to die; we’ve featured cameras dedicated to the form before. Video after the break.



15 thoughts on “Optimizing GIF Playback For Microcontrollers

  1. There are bazillions of .GIF files out there that were saved as single images with *no* animation, and they were compressed without losses so they look great without the ugly artifacts we see in highly compressed .JPG files.
    Some people decided that .GIFs, contrary to their original purpose, would *always* be animated. Just make sure the software recognizes these single image .GIFs and doesn’t vomit them up as unreadable. The world will thank you for it. 👍

    1. I think you’re just confused on the terminology, because the header must include the x/y size and frame count, even if that is 1. It isn’t possible to have zero frames and also be larger than zero by zero pixels in size.
      Also saying “some” GIFs were compressed lossless implies there is any other option. LZW was the only compression defined for GIF, which is lossless. That is to say all of them are compressed lossless.

      1. I hate to be that guy, but if your read the specification, GIF actually lets you use any compression algorithm you like, as long as you include the binary for decompressing it in one of the chunks inside the file. Sadly, that part is ignored by all GIF-reading software nowadays, I wonder why…

        1. Is that one of the newer extension blocks? I honestly remember nothing about it.
          Although this raises even more questions.
          Binary? I can see why this would be ignored.
          Aren’t extension blocks automatically LZW compressed too? I guess if you supported both. Probably why it wasn’t of much help back when LZW was patent encumbered I assume

          1. Yeah it was in those good old days when malware wasn’t the first thing people thought when presented with such an idea. And it completely ignores the fact that different architectures exist. Fortunately pretty much nothing implements that part.

      1. There are “hacks” to circumvent this limitation, because GIF specifies countless images with each their own 256-color palette and x-y and l-h, so you can partition any high-color image into suitable sub-pictures that can handle a given palette and even over-write parts of other images thanks to the transparent color.

    1. And there’s the dilemma, do you keep the audio in sync to prove you’re technically competent, or do you let it gradually go out of sync so it is authentic to the original SWF ??

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.