Remap GIF Frames

GIFs are a special kind of annoying. Most of a GIF's frames are just deltas - "same as the last frame, but this patch changed" - so the raw decode is full of redundant frames. The smart way to work with one is to extract only the unique frames, process those, then rebuild the full animation afterward. RemapGifFrames is the rebuild half of that workflow: it takes your processed unique frames and a mapping table, and reconstructs the complete frame sequence in the right order.

It's from AnotherUtils (marcoc2/ComfyUI-AnotherUtils), and it's designed to pair with the pack's LoadGifFrames node, which outputs the unique frames plus a frame_map. Used together they're a clean "dedupe, process, re-expand" pipeline that saves you from running your image processing on 200 nearly-identical frames when 40 would do.

How it works

The frame_map is a JSON array of indices - something like [0, 0, 1, 2, 2, 1] - where each entry says "the frame at this position in the original GIF corresponds to unique frame N." RemapGifFrames parses that, then reorders your processed frames by indexing into them: processed_frames[i] for every i in the map. The output is the full-length animation, ready to encode or pass to a video model.

The safety check is worth calling out: it verifies that your processed_frames batch actually contains enough unique frames to satisfy the mapping (max(mapping) + 1). If you dropped frames somewhere in the middle of your pipeline, it raises a clear error instead of silently producing a mangled animation. The error message is in Portuguese, which is a small taste of the author's style, but the meaning is unambiguous: your intermediate nodes must preserve all unique frames as a batch.

The inputs

• processed_frames - your processed unique frames, as an IMAGE batch. Whatever you did to them (img2img, upscale, color grade) happens before this node.
• frame_map - the JSON index array. If you started from LoadGifFrames, wire its frame_map output straight in; if you're hand-building it, remember indices are 0-based.

What comes out

• frames - the full re-ordered animation as an IMAGE batch.
• total_frames - the length of the rebuilt sequence, which is len(mapping), not the unique count. Handy for wiring into video-length parameters downstream.

Installing it

Same drill as the rest of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/marcoc2/ComfyUI-AnotherUtils.git

Restart ComfyUI, or find "AnotherUtils" in ComfyUI Manager. No models.

Where people get burned

The whole thing collapses if anything between LoadGifFrames and this node drops or reorders frames - that's exactly the error it's designed to catch, so treat the exception as a real signal, not a bug. Also, processed_frames and frame_map must stay in sync: if you batch-reorder the processed frames, the map becomes wrong. Keep the pair together as a unit through your workflow. And one more: this node expands frames, it doesn't compress them, so if your downstream video encoder chokes on length, the problem is the number of frames in the original GIF, not this node.