DropFirstImage

A one-line node that does one thing: take an IMAGE batch and hand back the same batch minus its first frame. If you've ever watched an image-to-video generation open on a static duplicate of your input picture before the motion actually starts, this is the fix.

The pack's own author uses it exactly that way. In the shipped i2v.sample.json workflow, the decoded Wan output goes through FlipImage → DropFirstImage → SaveAnimatedWEBP, so the clip that gets saved starts on the first generated frame rather than the conditioning frame the model re-emitted.

How it works

Three lines of runnable logic:

def drop(self, images: Any):
    if len(images) > 1:
        return (images[1:],)
    else:
        return (images,)

An IMAGE in ComfyUI is a batch tensor, so images[1:] is a slice along the batch axis - no decoding, no copy of pixel data you care about, and the rest of the frames keep their order. Because it's slicing and not resampling, it's cheap on a 100-frame video.

Note the second branch: a batch of exactly one image comes back untouched. That's deliberate (an empty batch breaks most downstream nodes) but it does mean the node is not a way to guarantee a frame count drop.

Inputs and outputs

images in, IMAGE out. That's the entire interface - no index, no count, no mode. If you wanted to trim the last frame instead, this isn't it.

Install

Manager search for the pack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/morino-kumasan/comfyui-toml-prompt

restart ComfyUI, done. Nothing to install beyond ComfyUI itself; the repo's requirements.txt is empty and the README's clone line is stale (old repo name, SSH URL).

Where people get burned

Single-frame batches pass through. Video VAE decode of a one-frame latent, or an IMAGE that isn't a batch at all, and the node silently does nothing. It looks like the node is broken when it's actually refusing to hand you an empty batch.

It's not the same as trimming a keyframe out of the middle. The awkward frame in a Wan i2v result is usually frame 0 specifically because that's the encoded conditioning image; if the duplicate is somewhere else, you're looking at a different problem.

Frame-index bookkeeping downstream. Anything that counts frames - an interpolation node, an ffmpeg re-encode with a hardcoded frame count, a SaveAnimatedWEBP with a fixed fps and duration assumption - is one frame off after this. Usually harmless, occasionally a one-frame hitch at the loop point.