ComfyUI Node Runs on cloud

Write to GIF

Build an animation one generated frame at a time

By WASasquatch·Created 3 years ago·Updated 2 days ago· 1,839
Write to GIF
  • image
  • image_pass
  • filepath_text
  • filename_text
transition_frames30
image_delay_ms2500.0
duration_ms0.1
loops0
max_size512
root
filenamemorph_writer

Most GIF nodes want the whole batch of frames at once, then assemble the file at the end. Write to GIF works the other way: it appends frames to a GIF as you generate them, one at a time, and can interpolate extra in-between frames so the motion looks smoother than your actual frame count. The WAS README calls it writing "a new frame to an existing GIF (or create new one) with interpolation between frames." That incremental design is the whole reason to reach for it.

Where it shines is long or memory-heavy sequences. If you're looping a generation and don't want to hold hundreds of image tensors in VRAM to hand off to a batch encoder at the end, this streams each frame straight to disk and moves on. It's the animated-GIF cousin of WAS's Write to Video node.

How it works

You run it inside a loop or a batch, and each execution tacks the current frame onto the GIF file it's building. The interpolation step blends between the previous frame and the new one, inventing intermediate frames so a small number of real generations turns into a fluid little animation instead of a choppy slideshow. Because it's writing progressively, the file grows on disk as you go rather than materializing all at once.

The inputs and outputs that matter

The core idea is simple even without a formal schema in front of me:

  • An image in - the current frame you want appended.
  • A file path / name - where the GIF lives so repeated runs know to keep appending to the same file instead of starting fresh.
  • Interpolation amount - how many blended frames to synthesize between the last frame and this one. More smoothing, longer GIF, bigger file.

The exact widget labels aren't something I can pull from a schema for this node, so treat those as the shape of what you'll see, not literal field names. This is an output-style node - its job is the file it writes, so you generally don't wire its result onward the way you would a normal image.

How to install it

It comes with the WAS Node Suite:

  • ComfyUI Manager: search was-node-suite-comfyui, install, restart.
  • Manually: cd ComfyUI/custom_nodes && git clone https://github.com/WASasquatch/was-node-suite-comfyui/, then pip install -r requirements.txt against your ComfyUI Python (use python_embeded\python.exe -s -m pip ... on the portable build), and restart.

Common issues

Read the fine print in the WAS README before you get attached to this one. The author states the video/animation side was only ever tested and supported on Windows - they didn't have Mac or standalone Linux to verify it, and asked for PRs to fill the gap. It was never under active development after December 2023, so that caveat still stands. On Linux or Mac it may work, may not; you're on the frontier.

The sibling Write to Video node needs FFMPEG installed and pointed at in the config, and the README warns that re-compressing frames run-to-run "will start exponentially ruining the starting frames" unless you use a lossless codec. The GIF path avoids the codec mess but shares the same spirit: it's an experimental node from a retired pack, so keep a copy of your source frames and don't build a fragile pipeline on top of it.

And the usual WAS gotcha applies to the whole pack - if a ComfyUI update makes every WAS node vanish with an "Import Failed", that's dependency drift, not this node. Re-run requirements.txt against the right Python environment (or run the bundled install.bat), restart, and they come back.

CategoryWAS Suite/Animation

Inputs (8)

NameTypeDefaultDescription
imageIMAGEThe images to append. A batch is appended one image at a time, in batch order, each faded in from the one before it.
transition_framesINT302–60How many blended frames are drawn between the last frame in the file and the incoming image. 2 is almost a hard cut, 30 is a smooth fade. Ignored the first time, when there is nothing to fade from.
image_delay_msFLOAT2500.00.1–60000How long each appended image is held once the fade into it has finished, in milliseconds. 2500 holds it for two and a half seconds.
duration_msFLOAT0.10.1–60000How long each blended frame is shown, in milliseconds. The default 0.1 asks for the shortest frame the format allows, which most players round up to about 10ms; raise it to slow the fade down.
loopsINT00–100How many times the animation plays before it stops. 0 = forever, 1 = once through, 3 = three times. Written on every append, so the finished file carries the count set on the last run.
max_sizeINT512128–1280Longest side any frame is written at, in pixels. 512 keeps a big render down to a shareable file; an image already smaller is left alone. The first frame still sets the canvas, and a later one is centred on it.
rootCOMBOWhich folder the file lands in: ComfyUI's own 'output' or 'temp', or any folder added under paths.allow_write in config.yaml, listed by its own name. filename names the part below it, so '[time(%Y-%m-%d)]/clip' files each day's under a dated folder.
filenameSTRINGmorph_writerName of the GIF, without an extension, '.gif' is added. Every prompt using the same name appends to the same file, so change the name, or put a token such as [time(%Y-%m-%d)] in it, to start a new animation.

Outputs (3)

NameTypeDescription
image_passIMAGEThe images exactly as they arrived, so this node can sit mid-chain.
filepath_textSTRINGFull path of the GIF that was written, '.gif' included.
filename_textSTRINGThe filename widget as it was typed, with no folder and no extension, for feeding a caption or a log.