GIF to Sprite Sheet

A GIF is not a video. It is a stack of images with a delay value attached to each one and a disposal rule saying what to do with the previous image before drawing the next. Many encoders also store only the rectangle that changed, so a single frame inside the file can be a small patch rather than a full picture. Decoding a GIF properly means composing each frame onto the canvas the last one left behind.

That is what happens when you drop a GIF in here. Every frame is composed to full size before it becomes a sprite, so what you get is what you would see at that moment in playback, not a partial patch floating in space.

GIF delays are stored in hundredths of a second, and browsers clamp anything under about two hundredths. Encoders work around slow motion by repeating a frame several times instead of setting a long delay. That is invisible in the GIF and a real problem in a sheet, because a repeated frame becomes a duplicate cell that eats texture space and makes the frame count lie.

So the first pass after extraction is a look for repeats. Identical neighbours are safe to delete, and the frame count in the editor drops as you go. Your engine will handle the timing properly through its own animation frame durations, which is where a long pause belongs anyway.

A GIF frame holds at most 256 colours and one of them can be transparent. There is no partial alpha, so any soft edge in the original art has already been either hardened or dithered against a background before the GIF was written. Converting to a sheet recovers the pixels faithfully, but it cannot recover information the GIF never stored.

Practically, this shows up as a fringe of odd pixels around sprites that were once anti-aliased. Pixel art comes through fine, since it had hard edges and a small palette to begin with. For anything else, the pixel editor and the recolor palette list are the tools for cleaning up: find the fringe colour, replace it, or erase it frame by frame.

The common case is an asset you only have as a GIF. Old sprite rips, a character preview from an asset store, an animation a collaborator sent over chat. Engines will not slice a GIF, so it has to become a sheet before it can become an animation.

The second case is reference. A GIF of a run cycle from a video capture becomes twelve frames you can trace, recolor, or trim down to the four that matter. Extract them, and everything else in the editor treats them as ordinary sprites from that point on.

The third is round tripping. Pull a GIF apart, drop the repeats, fix a pose, then export the whole thing back out as a GIF at a proper frame rate. Nothing about the file leaves your machine on the way through, since the decode and the encode both happen in the page.

A GIF made for a web page and a sheet made for a game engine want different frame counts. Web GIFs are often generous with frames because bandwidth is the only cost. In a sheet each extra frame is texture memory that stays resident for as long as the sprite exists, so a twenty four frame idle animation is a poor trade when eight of those frames read identically in motion.

Most GIFs lose a third of their frames with no visible change to the motion.