Making GIFs: Frame Extraction, Composition, File Size

#Three limits decide everything

Every trade-off in animated images comes from three hard limits: 256 colours, frames that may store only differences, and browser handling of very short delays. Without them, banding, missing regions and stutter all look like tool bugs.

#Extraction: why frames cannot be pulled out as stored

GIF lets a frame store only the region that changed, so pulling frames out as stored gives you a pile of patches with holes. They must be composed frame by frame to rebuild the complete picture.

Whether composition is needed depends on the disposal method - what happens after a frame is drawn:

• Keep: later frames draw on top of it
• Restore to background: erase it and fill with the background colour
• Restore to previous: roll back to the state before it

The GIF frame extractor overlays delta frames, handles the transparent index, restores or keeps according to disposal, and fills with the logical screen background colour when needed - so every exported frame is complete.

#Composition: size, frame rate and weight

The most common composition mistake is the automatic size mode, because it does not scale - it takes the largest width and height across all frames and centres each one. Mix in a single oversized image and the whole GIF stretches to it, leaving transparent margins around everything else.

With the GIF maker, the three size modes differ in practice:

• Automatic: largest dimensions, no scaling, centred - mismatched frames get transparent borders
• First frame: everything scales relative to frame one
• Custom: explicit width and height, with contain (letterbox, no distortion) or stretch (fills, distorts)

Two hard numbers on frame rate: at least 2 and at most 60 frames, and total pixels (width × height × frames) up to 7 million - beyond that composition is refused outright.

The delay unit is 1/100 second and the interface minimum is 20ms. There is an unavoidable floor here: browsers generally treat a delay below 2 units (20ms) as 100ms, so setting 10ms does not speed things up, it just gives you a 10fps animation. For smoother motion, cut frames or reduce size.

#Palette: where banding and flicker come from

GIF caps at 256 colours and quantisation targets 255 plus one transparent slot, so photographs and gradients always band. That is the format's ceiling, not a compression setting you can tune.

Subtler is that each frame is quantised independently: neighbouring frames with slightly different palettes flicker during playback. For smooth transitions use flat colours or simple shapes; photographic content belongs in a video format (MP4, WebM), which is both smaller and better looking.

#Transparency: two opposite conventions

Transparent GIFs follow two opposite conventions, and mixing them produces white or black fringes. When the background looks wrong, first establish which kind of file you have.

• Semi-transparent sprites meant to be composited: browsers keep transparency as-is
• Ordinary GIFs without transparency: the background colour is restored per the spec

The first exists so an element can sit on an arbitrary background; the second exists to erase the previous frame. A single GIF that mixes both intents cannot be guessed correctly by any tool.

#Where the file size comes from

GIF size is dominated by pixels times frames, with colour count mattering much less - so shrinking dimensions and dropping frames always beats palette tweaking. That is exactly why video formats win.

Three practical reductions:

• Shrink first: halving the width leaves a quarter of the pixels
• Then drop frames: 20 down to 12 cuts size proportionally, usually with little perceived loss
• Consider another format: the same content as MP4 or WebM is typically an order of magnitude smaller

If you only need to shrink a still image, image compression or the image converter is enough - no GIF workflow needed. Note that a GIF passing through a canvas keeps only its first frame, so some tools turn animations into stills; that is deliberate, not a bug.

#Which tool to use

Order for building your own animation: export every frame at the same size as PNG, compose with first-frame scaling, keep total pixels in budget, then export PNG if transparency matters.

#Frequently asked questions

#My GIF has large transparent borders. Why?

The automatic size mode was used, and it does not scale - it takes the largest dimensions and centres each frame, so smaller frames sit in empty space. Switch to first-frame or a custom size and the frames actually scale to fill.

#I set the frame delay to 10ms but nothing got faster.

Because browsers treat delays below 20ms as 100ms. That is a player convention, and writing 10ms into the file changes nothing. To go faster, reduce the number of frames (with bigger changes per frame) or reduce the dimensions.

#Extracted frames have chunks missing.

That tool did not compose frames. GIF allows a frame to store only the difference from the previous one, so frames must be overlaid according to disposal method to become complete pictures. A tool that follows the spec, such as the GIF frame extractor, gets it right.

#Why does a gradient background show visible bands?

GIF allows 256 colours, so a gradient is quantised into bands. No setting avoids it - use a video format for smooth gradients, or make the background flat.

#The animation flickers slightly during playback.

That is independent per-frame quantisation: neighbouring palettes differ and the switch shows. Flat colours and simple shapes avoid it; photographic content should skip GIF entirely.