Nuke FrameHold

ComfyUI treats a video as a stack of frames shoved into one IMAGE tensor - a "batch." And until this node showed up, there was no clean way to reach into that stack and say "hold this one frame for a while." Nuke FrameHold does exactly that, borrowing the semantics of The Foundry's FrameHold node: you give it a timeline position, and it freezes that frame across the whole batch. It ships in the nuke-nodes-comfyui pack, which is basically a Nuke port-a-kit for ComfyUI - merge ops, reformatting, OCIO color, LUTs, the works.

Why would you reach for this? Think freeze-frames. You've got a batch of frames from a video model or an image sequence, and you want one frame held static while downstream nodes do their thing - a held reference pose while you img2img the rest, a "freeze on this keyframe" shot, or a still you want to ride out for a fixed duration instead of repeating it manually. There's no stock ComfyUI node for re-indexing a batch like this, so if you've ever hand-built one with batch manipulation nodes and a bunch of index math, this is the node that makes that graph disappear.

How it works

The model is "batch as timeline." If your input has B frames, batch item 0 is timeline frame frame_start, item 1 is frame_start + 1, and so on. You tell it which timeline frame to hold, and it builds a new batch where every output frame is a copy of some held frame.

The output always has the same length as the input - it never adds or removes frames, it just re-samples which input frame each slot shows. And it's clamped: if you ask to hold frame 99 on a 15-frame clip, you get the last available frame rather than an error.

The three inputs that matter

• first_frame - the timeline frame to hold. With increment at 0 (the default), this is the only decision you make: every output frame shows this frame.
• increment - set it to N and the held frame advances every N frames: first_frame, first_frame+N, first_frame+2N, and so on. Nuke's own example: first_frame=1, increment=5 over frames 1–15 gives you 1,1,1,1,1,6,6,6,6,6,11,11,11,11,11. Use it to step through a sequence in chunks, or to hold each frame for N frames.
• frame_start - the timeline number of the first batch item. Defaults to 1, so the node is 1-based like Nuke. If you're wired up to a 0-based workflow, set it to 0.

The single output is an IMAGE tensor of the same batch length, ready to feed anything that takes video - a VAE, a save-video node, or whatever's downstream.

Installing it

The whole pack installs in one go, via ComfyUI Manager (search "Nuke Nodes") or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/sumitchatterjee13/nuke-nodes-comfyui.git nuke-nodes
cd nuke-nodes && pip install -r requirements.txt

Restart ComfyUI and you'll find Nuke FrameHold under the Nuke → Time category. The pack's requirements.txt pulls in OpenCV, OpenColorIO, and OpenImageIO - a chunky install, but FrameHold itself only needs PyTorch and NumPy, which you already have. If OpenImageIO refuses to build on your platform, the rest of the pack still works; the read/write nodes just fall back to OpenCV/PIL.

Where people get burned

The classic mistake is feeding it a single image. Load Image gives you a batch of one frame, so there's nothing to hold - the node dutifully returns that one frame and you wonder what the point was. You need an actual sequence or a video loader (NukeRead, a video node, a batch of generated frames) to get the behavior you're after. And remember the defaults are Nuke-style 1-based frame numbers: first_frame=1, frame_start=1. If you're coming from zero-based thinking, the off-by-one will bite you exactly once.