Animative Blogging

If you've spent much time on my blog, you've probably noticed that I like to include animated GIFs in my posts.  There's no better way to make a point about a game than to show it in action.  When I started blogging, I considered providing videos for readers to click on, but I think that anything that forces an interaction or takes the reader away from the text disrupts the flow of the post.  I like to think of the animations as part of what I write, not as bonus material.

I'm aware that GIFs are not the most efficient way to store an animation, but I have yet to find a way to embed a video into a post that autoplays and loops without adding an ugly frame or website advertisement.  Please let me know in the comments if you're aware of any such method.  In the meantime, my apologies to readers on slow internet connections.  [Note:  In the case of old video games, GIFs may indeed be the most efficient way to store an animation, if recorded directly.  See the comments for details.]

Anyway, the main purpose of this post is to show some general techniques for making the various animations you see scattered throughout the blog.  All of my blog-related activities are on a Windows machine, so any OS-specific instructions I give will be for that platform, but most of the image manipulation is web-based and could be done on OS X, Linux, etc.

Video Capture

My GIFs almost never start their life as GIFs; usually, I convert them from a video file I recorded while playing a game in an emulator.  Some emulators natively provide the option to record gameplay, but in all other cases, Windows users can record video with the XBOX Game Bar (⊞ Win - G).

In the "Capture" window in the upper left corner, select the record symbol ().  It will be grayed out the first time you use it with an application, but push it anyway and it will ask you to enable gaming features.  Then you'll have to push record again to start the video capture.  Note that this only records content from the active application, not everything visible on the screen (unless you're in fullscreen mode).  Captured videos are sent to the "Videos" folder under "This PC".


There are many applications available for converting video to animated GIF, but my preferred resource is ezGIF because it has a convenient interface and supports both conversion and the subsequent processing steps as well.  If you select the "Video to GIF" option in the top menu bar of the website, it will give you the option to upload a video.  Note that there is a 100 MB limit on the video size, so if you're starting from a large video, you'll need to use a video editor in your OS to trim it before uploading to ezGIF.

Once your video is uploaded, you'll be presented with the following options.

I recommend doing as much processing as possible while it's still in video format because animated GIFs are much larger files than videos and take longer to process.  You'll want to do any cropping and cutting here.

Next you convert to GIF by again selecting the "Video to GIF" tool.  Since animated GIFs tend to be large files, it's important to make the size and frame rate no larger than you really need.  When animating old video games, I lean in the direction of smaller image sizes because the native resolution of the game is usually small enough that you won't see much degradation when you expand the image beyond its original size.

You will notice the smaller frame rates, however -- most games run at around 60 fps, which is much higher than most GIFs.  The ezGIF site will let you go up to 25 fps, but the higher the frame rate, the shorter the GIF has to be.  If you want to use their maximum frame rate, for example, your GIF will have to be less than ten seconds long.  Long GIFs with high frame rates tend to be large files, so for blogging purposes, these are reasonable restrictions.  Anything much longer you should probably present as a video anyway.

Creating Transparent Backgrounds

If you want to make the background transparent, it's a lot easier if you're starting with a uniform color in the background.  Fortunately, this is very often the case in early video games.  For example, let's try giving this part of the splash screen from Pac-Man (1980) a transparent background:

Look for the "Replace color with transparency" box in the "Effects" section of ezGIF (bottom left, below):

If you try to go straight from our initial GIF to a transparent background, you'll get something like this:

The distortion you see there is due to the fact that the background wasn't exactly black in all of the pixels.  Fortunately, this can be fixed with a single intermediate step.  In the "Effects" section of ezGIF, there's another option called "change background color", which when selected will show you this panel:

Generally, this tool allows you to globally change one color in an animation to another, but we want to do something slightly different here.  Instead of changing one color to another, we want to change all pixels that are nearly one color to being exactly that color; in this case, the color is black.  So we set both the original and new color to black and then adjust the "Fuzz %" slider based on how close to black the color can be before we no longer consider it black.  This particular animation only features a handful of colors, so we should be able to set the fuzz to a large value without worrying about interfering with anything else.  Here's what happens when I process the animation with an 18% fuzz setting:

Looks pretty much the same as the original, doesn't it?  That's because the "nearly black" pixels in the image were close enough to black that our eyes (or mine, anyway) couldn't distinguish them.  But look what happens when we now use the "replace color with transparency" effect:

Voil√†!  Transparency achieved.

The ezGIF site only allows you to change black or white backgrounds into transparency, but it's easy to enough to change backgrounds of other colors into black or white using the same "change background color" tool I used above.

Finally, before you finish your GIF, make sure to run the "Optimize" tool.  I have sometimes seen size reductions of 50% or more without noticeably changing the appearance of the animation.

Some of the images on the blog used more complex techniques that I may present in a later entry, but that's it for now.


  1. I wish there was a way to just capture as GIF. The format is almost perfect for capturing old game footage - lossless compression, 256 indexed colors, and Blogger lets you just embed them in a post. All video formats I've found good support for are optimized for high-color scenes and introduce stochastic artifacts, hence Pac-Man's background not being uniformly black when it should be. And converting from video to GIF keeps the artifacts, needlessly blowing up the size of the GIF with noise meant to aid an algorithm for reducing the filesize. Arghh!

    One technique I've used is to capture as MP4, edit, and then use Shotcut to convert to GIF. But two things are important when capturing. First, capture at 50fps. GIF interframe delays must be in multiples of 10ms, so 50fps will translate to 20ms delays without introducing too much judder. Second, either use an RGB or a 4:4:4 chroma profile, or make sure the output resolution is at least double the native resolution. The more common 4:2:2 profiles will cut your color resolution in half, which makes low color pixel art look terrible.

    1. Yeah, I've noticed that even when I don't want a GIF to be transparent, using the fuzzy background replace is still useful for reducing the file size of GIFs converted from video.

      Thanks for the Shotcut suggestion, I'll give that a try.

    2. This comment has been removed by the author.

    3. I did a little experimentation with file formats and sizes. My raw footage of Ms. Pac-Man, recorded in MPEG4-AVC1 at triple native resolution (necessary so that Youtube will playback at 60fps), runs 10 minutes 50 seconds, and weighs 155MB, making it slightly over 4KB per frame. I use point scaling, so the filesize shouldn't be that much bigger from the higher resolution.

      A snapshot in MAME in PNG format is only 3.39KB. Converting to GIF (in GIMP, not MS Paint) increases it to 3.72KB, slightly higher but still less than a frame of video, and it's a lossless conversion. A conversion to lossless WebP is 19.9KB, so I'm discounting that format.

      Basically, we really ought to have better support for APNG and/or GIF. They're clearly better for this kind of footage than conventional video, but only if recorded and edited that way.

    4. Huh, interesting, thanks for the info. I updated the article with a brief note to this effect. Please give me a heads-up if you find a good way of obtaining direct GIF/APNG footage.

    5. It would be better if you could use video capture software that captures lossless AVI video instead of MP4. The colors would be solid. I personally use Fraps for my video game captures though it's not free.

      Obviously Adobe Photoshop and After Effects would make editing the captures a lot easier, but unless your already a designer that uses that software, it wouldn't be worth the subscription fee. Have you ever looked into using GIMP? I believe there was a way you could import AVIs and export them to GIF with it (using a free plugin).

    6. My most recent blog entries have been using ScreenToGif, which seems to do a much better job of keeping the size down without the need for extra processing. I also haven't seen any evidence of the stochastic artifacts that were present in the Game Bar recordings.

      The primary downside is that processing and writing animations can be slow, especially at high frame rates (it goes up to 60 fps). I've had mixed results in the final size comparison between GIF/MP4, sometimes the GIF is smaller and sometimes it's the mp4.

      As for GIMP, I have started using it more extensively, but not for this. My experiments with animation have become more elaborate and may end up as another blog entry at some point, but not until I've streamlined the process more.

    7. Wow, ScreenToGif is pretty amazing. Just one problem though (apart from a really slow saving function) - recording at 60fps plays havoc with my playback speed, and therefore framerate, which defeats the purpose of recording that high. I'll need to do some more experiments to figure out the optimal framerate (and there are so many settings too), but even with this problem, this is a seriously great piece of software.

      I re-recorded my Ms. Pac-Man session, removed 100% duplicates with delay adjustment, saved using the GIF 2.0 profile, and the final filesize came out to 11.1 MB, with 21054 unique frames. That is an incredible size reduction compared to the 155MB high-quality video that I recorded previously. However, it's a bit jerky, and the runtime is 13 minutes, 34 seconds, quite a bit longer than the 10 minutes 50 seconds when recorded on video, which I attribute to the added stutter. Saving as video puts it at 7.7MB, but this is lossy compression, while the GIF is lossless, and it doesn't fix the stutter since this is baked into the recording.

      Doing some math, the average framerate of the GIF is 25fps, and the average frame size is 553 bytes, a small fraction of the 3.39KB PNG files that MAME exports.

      I'd love to see another blog post on this, and learn what you've learned.

    8. Here's a bit of data I gathered on different framerate recordings.

      At 60fps recording, the runtime was 13:34 and had 21054 unique frames, giving it about 25% lag and about 26 fps on average.

      At 50fps recording, the runtime was 13:46 and had 21069 unique frames, giving it about 27% lag and about 25.5 fps on average.

      At 25fps recording, the runtime was 12:36 and had 13966 unique frames, giving it about 16% lag and about 18 fps on average.

      At 15fps recording, the runtime was 11:27 and had 7877 unique frames, giving it about 5.7% lag and about 11 fps on average.

      At 10fps recording, the runtime was 11:14 and had 5651 unique frames, giving it about 3.7% lag and about 11fps on average.

      Subjectively, the 60fps and 50fps recordings look about the same to me, and the 25fps recording looks much worse. From a motion smoothness perspective, neither can compete with the MP4 video, but its picture is visibly lossy and the filesize is so much larger.

    9. Thanks for the data. I had also noticed that the high frame rates seemed to be falling short of what I expected, but hadn't looked into why. Honestly, I usually end up publishing GIFs at lower frame rates than that anyway, since it's difficult to keep the file size down while also achieving reasonable durations and dimensions. However, it does become a nuisance for manipulating and analyzing individual frames from my playthroughs, since I want to get as much of the game data as possible. I haven't played with the ScreenToGif settings much, so maybe there's something in the software we can tweak...

      As for a follow-up blog entry on this topic, there will probably be one soon that talks about sprite extraction, something which ScreenToGif has made a lot easier. Extracting sprites from lossy video is fraught, to say the least.


Post a Comment