An animated GIF is not necessarily a stack of complete pictures. Some GIFs store small rectangular image patches that depend on pixels from earlier frames. Extract one of those patches without reconstructing the animation, and the result may look incomplete: a moving object without its background, a transparent rectangle, or remnants of other frames.
A GIF disposal method tells the decoder what to do with the displayed canvas after that frame's delay and before drawing the next image. Values 0, 1, 2, and 3 respectively mean unspecified, do not dispose, restore to background, and restore to previous. To understand the result, follow the sequence of canvas operations rather than treating each stored image as a complete picture. The GIF89a specification defines those operations.
Four different things that are often called a “GIF frame”
| State | What it means |
|---|---|
| Raw frame rectangle | The current image's own pixel indices, width, height, and position on the logical screen. It can be smaller than the overall GIF. |
| Pre-frame canvas | The state ready for the current frame, after the previous frame's disposal has been applied. |
| Displayed composite | The full logical-screen picture after the current patch is drawn over the pre-frame canvas, ignoring pixels marked transparent. |
| Post-disposal canvas | The canvas after the current picture's delay and disposal operation, ready for the next patch. |
The logical screen defines the overall GIF dimensions. An image descriptor then specifies its rectangle and zero-based left/top offsets. A 300 × 200 GIF, for instance, might contain a 40 × 30 image at offset (120, 80). Pixels outside that rectangle do not come from that record. A frame can carry a local palette, or use the global color table. GIF89a, Image Descriptor and Logical Screen Descriptor.
The order is:
Start with the canvas left by the previous image's disposal.
If the current image uses restore-to-previous, save the necessary pre-draw pixels.
Draw the current rectangle at its offsets; transparent-index pixels do not overwrite the underlying canvas.
Present the resulting full-screen composite for the frame's specified delay.
Apply the current image's disposal, then continue to the next image.
Disposal describes what happens after displaying the current composite, not how the patch initially appears.
The four GIF disposal methods
| Numeric value | Official meaning | What happens after the display interval |
|---|---|---|
| 0 | No disposal specified | No particular cleanup action is required of the decoder. Do not rely on one predictable result. |
| 1 | Do not dispose | Leave the displayed image in place; the next patch draws over it. |
| 2 | Restore to background | Restore the area used by this image rectangle to the background color. |
| 3 | Restore to previous | Restore the affected pixels to the appearance they had immediately before this image was drawn. |
Values 4–7 are reserved in GIF89a, not additional standardized disposal instructions. GIF89a, Graphic Control Extension; GIFLIB's GraphicsControlBlock.
Method 0: unspecified is not a guarantee
Some decoders handle disposal 0 as though it were method 1. That does not make the two values interchangeable in the format. The specification explicitly says the decoder is not required to take action when no disposal method is specified. If a workflow relies on retaining or clearing a region, use well-formed frames with an explicit intended method rather than making assumptions about method 0.
Method 1: keep the pixels
Method 1 makes the next image an overlay onto the current result. This is useful when several small patches gradually build or modify a scene. If a moving object was intended to disappear between images, however, leaving it in place can produce a trail.
Method 2: clear the image rectangle
Method 2 restores the whole rectangle used by the current image, not just the pixels visibly colored within it. This matters when a raw patch has transparent-index pixels: those positions skip drawing when the patch is first composited, yet still lie inside its disposal rectangle.
In the specification, restoration uses the background color. The logical screen's background index refers to the global color table when such a table exists; without a global color table, the index is not meaningful. Some real animation implementations represent cleared pixels as transparent when producing RGBA composites instead. Check whether an exported image is being viewed against white, black, or a checkerboard. GIF89a, Logical Screen Descriptor; ImageMagick animation/disposal examples.
Method 3: restore what was underneath
Method 3 is a temporary-overlay operation. Before painting the current patch, the decoder preserves the affected preceding canvas; after the frame's delay, it brings back that appearance. A blue line underneath a red overlay can therefore reappear, unlike method 2, which clears the rectangle to background.
“Previous” means the pre-draw canvas, not necessarily the raw pixels of the immediately preceding GIF record. GIF89a notes that storing this state can be expensive and recommends sparing use. It also recommends restoration to background as a fallback for decoders unable to save the previous area. GIF89a, Graphic Control Extension recommendations.
A six-by-four GIF: watch one patch under three disposal methods
Here is a small original example designed specifically to expose the difference. The logical screen is 6 × 4 pixels. It has a global palette with background index 0 = white. In the grids below, . means white, B means blue, R means red, and G means green. _ means a transparent-index pixel in the raw patch—a command to leave the preceding pixel unchanged, not a white pixel.
There are three stored images, with zero-based frame indices:
| Frame | Stored rectangle and position | Delay in GIF file | Disposal |
|---|---|---|---|
| 0 | Full canvas, 6 × 4 at (0, 0) | 30 centiseconds = 300 ms | 1 |
| 1 | 3 × 2 at (1, 1) | 12 centiseconds = 120 ms | 1, 2, or 3 in three separate control files |
| 2 | 1 × 1 at (2, 1) | 40 centiseconds = 400 ms | 1 |
All three controls use the same geometry, palette, pixel indices, and delays. Only frame 1's disposal value changes. Frame 1 uses transparent index 4, which is distinct from the white background index 0.
Stage A: the pre-frame canvas
Frame 0 paints a blue row on an otherwise white screen and leaves it in place. Immediately before frame 1 is drawn, the canvas is:
......
......
BBBBBB
......Stage B: the raw frame-1 rectangle
The second image contains only this 3 × 2 patch, placed at left = 1, top = 1:
R_R
R_RIt is not a complete 6 × 4 picture. In this patch, _ represents palette index 4 with the frame's transparency flag set, so the canvas pixels at those positions are not touched.
Stage C: the displayed composite
After drawing the red pixels and leaving the transparent positions unchanged, the image displayed for frame 1's 120 ms nominal delay is:
......
.R.R..
BRBRBB
......Notice the blue pixel that remains visible through the transparent center of the lower patch row. The composite at this stage is identical in all three control GIFs. The disposal method has not yet been applied.
Stage D: the post-disposal canvas
After frame 1's delay, the decoder applies its disposal instruction. These are the calculated specification-model canvases (white is the global background color):
| If frame 1 uses... | Post-disposal canvas | Why |
|---|---|---|
| 1 — keep | ...... / .R.R.. / BRBRBB / ...... | Both red and underlying blue pixels remain. |
| 2 — background | ...... / ...... / B...BB / ...... | All positions in the 3 × 2 rectangle are cleared, including the center where transparent pixels skipped drawing. |
| 3 — previous | ...... / ...... / BBBBBB / ...... | The exact pre-frame blue row returns. |
This is the easiest way to distinguish methods 2 and 3: method 2 removes the blue pixels inside the rectangle, while method 3 restores them.
Stage E: the next image is drawn
Frame 2 now draws one green pixel at (2, 1). The resulting complete pictures differ:
Previous disposal = 1 (keep):
......
.RGR..
BRBRBB
......Previous disposal = 2 (background):
......
..G...
B...BB
......Previous disposal = 3 (previous):
......
..G...
BBBBBB
......That difference is why reconstructing only the current patch, or combining all patches without disposal, cannot reliably produce the frame a viewer saw. The original controls and expected state arrays are available in the example download. The interactive diagram above models the white background specified for these controls; it is not a recording of browser playback.
Transparency, offsets, and delay each solve a different problem
Transparency is not disposal. A GIF frame may name one palette index as transparent. When that index occurs within its raw image, the decoder leaves the destination pixel unmodified during drawing. GIF transparency is a pixel-or-skip mechanism, not arbitrary partial alpha or a request to erase an earlier frame. The transparent index applies to that frame's active color table and only when its transparency flag is enabled. GIF89a, Transparency Index; MDN image format guide.
Offsets position the patch. A 3 × 2 patch at (1, 1) has six stored pixel positions, none of which identifies the complete GIF background. A tool that ignores image-descriptor offsets can place the patch in the wrong corner. A tool that treats its local dimensions as the animation dimensions can crop away the rest of the scene.
Delays control how long a composite is shown. GIF89a stores a delay as an integer number of hundredths of a second in the Graphic Control Extension (GCE) associated with the following graphic-rendering block. For instance, a stored delay of 12 means 0.12 seconds, or 120 ms. A zero value does not specify a positive waiting interval; player behavior, scheduling, and short-delay clamping may vary. A series of PNG pictures does not by itself preserve these per-frame holds. The disposal method does not set the playback speed. GIF89a, Graphic Control Extension.
Keep the source delays separately if you need to rebuild an animation later. Do not infer an equal frame rate just because the extracted images are numbered sequentially.
Why raw GIF frames produce broken-looking exports
| Symptom | Likely mistake | What to check |
|---|---|---|
| A sprite appears without its background | Extracted the raw, reduced-size patch rather than the displayed composite | Image rectangle vs logical screen; reconstruct prior frames |
| A moving object leaves ghost trails | Previous frame not cleared as intended, or disposal treated as method 1 | The previous image's disposal value and rectangle |
| A background line disappears in a rectangle | Method 2 clears even areas where transparent patch pixels did not draw | Clear rectangle bounds; compare with method 3 |
| Red or magenta squares appear unexpectedly | Transparency index interpreted as an ordinary palette color, or decoder-specific background handling | Transparency flag, active color table, RGBA pixel values and decoder version |
| A patch is in the wrong location | Image-descriptor left/top offsets ignored | Original image descriptor, not just decoded patch dimensions |
| Frames look correct but animation timing changes | Delay metadata discarded, rounded, or replaced by a fixed interval | Per-frame centisecond delays and intended playback model |
A full-frame PNG is usually the right artifact for inspecting the picture shown at a particular moment. A raw patch can be valuable for studying GIF internals or optimizing an animation, but it answers a different question.
How to reconstruct and inspect the displayed frames
For a reconstruction implementation, maintain a full logical-screen canvas. After the previous disposal has prepared the canvas, preserve pre-draw pixels if the current image needs method 3, place its rectangle at the offsets, skip transparent-index pixels, capture the displayed full canvas, record the delay, and apply the current disposal exactly once before the next image. Treat method 0 conservatively and document the chosen decoder behavior.
For practical inspection with ImageMagick 7, you can check geometry, offsets, disposal, and delay before exporting composited PNGs. These commands assume a Bash-compatible terminal and an unused output directory:
magick identify -format 'frame=%p patch=%wx%h offset=%X%Y disposal=%D delay=%Tcs\n' input.gif
mkdir gif_composited_frames &&
magick input.gif -coalesce gif_composited_frames/frame_%03d.pngIn ImageMagick's format strings, %D prints disposal, %T prints the delay in centiseconds, and %X%Y prints the page offset. The -coalesce operation reconstructs each displayed full-canvas picture rather than exporting the stored subimage alone. See ImageMagick's property escapes and animation basics.
Do not equate a coalesced PNG with all the information in the original GIF. The PNG gives you pixel appearance, but the separate GIF frame delay and disposal metadata still matter for reconstruction or re-encoding. An output PNG's alpha channel can also expose differences concealed by a white preview background.
If you prefer a browser-based full-frame export, the GIF Frame Extractor is intended to reconstruct displayed GIF frames for image export. If you then want a regular grid of those displayed frames, use GIF to Sprite Sheet. These are downstream output tasks; they do not replace understanding the stored patches and their disposal rules.
A real decoder difference worth testing
We created original 6 × 4 GIF89a controls with explicit disposal 1, 2, and 3; each has three stored frames and delays of 300, 120, and 400 ms. On the transparent-index method-2 control, ImageMagick 6.9.12-98 in the independent rerun (using convert, the older CLI name) produced transparent pixels in the cleared rectangle after coalescing; when those PNGs were placed on a white matte, their visible colors matched the specification-model diagram. Pillow 12.3.0, reading the same GIF, produced opaque magenta pixels in that rectangle on the next composited frame, matching the source palette's transparent index color rather than the white background.
That is an observed comparison of two local decoder paths, not proof that every browser handles method 2 in the same way. It reinforces an important diagnostic: inspect both RGBA values and the background used to preview them. GIF89a's nominal background-color instruction, a decoder's compositing choices, and a PNG preview's matte are related but not identical concepts. The fixtures, program versions, and exact output grids are included with this draft.
Before declaring an exported GIF frame “broken”
Check the logical screen size and the stored frame rectangle. Check its offsets and whether a transparent palette index is active. Determine the preceding canvas state and apply the previous image's disposal before drawing the current one. Compare the current composite with the raw patch, not with a raw patch from another frame. Finally, verify the GCE delay and inspect transparent areas against more than one background color.
A correctly reconstructed GIF frame is a displayed canvas state at a particular moment, not necessarily the rectangular pixels stored for that frame. Once you distinguish the raw patch, the preceding canvas, the displayed composite, and the post-disposal state, seemingly missing or duplicated image parts become explainable rather than mysterious.
For a downstream animation workflow, see bringing the reconstructed GIF frames into Unity. A PNG grid needs both correct pictures and a separate plan for unequal frame holds.
Try the original examples
Tiny GIF controls and expected canvas states ↓Synthetic examples for inspection and learning. Keep your original media unchanged.
Owned 6 × 4 GIF controls were checked against specification-model arrays, Pillow 12.3.0 and ImageMagick 6.9.12. Alpha/background differences are explicitly scoped to these decoder paths.
Examples and calculations are scoped to their stated settings. Source links support the instructions; an illustration is not a screenshot of an application test.