Control Image Slicer

If you're generating a long video one chunk at a time, you've got a problem: your control sequence (depth, pose, whatever) spans the whole shot, but each pass of the loop only sees one slice of it. Control Image Slicer is the node that hands each iteration its own frames_per_iteration-sized window of control frames - and nothing else. It's the counterpart to IterVideoRouter, which handles the generated frames; this one handles the conditioning.

It lives in the pack's Iterative Video category, and it's one of the nodes the pack's prompt handler actively rewrites: at submit time it injects a hidden iteration value into the node, so the slicer always knows which pass it's on. You don't type the iteration number anywhere - the loop does it for you.

How it works

The node computes a start index of iteration * frames_per_iteration (or iteration * (frames_per_iteration - overlap_frames) when overlap is on), takes the next frames_per_iteration frames, and returns them as the control_slice. Then it handles the edge cases:

• overlap_frames - when > 0, each window starts overlap_frames before the previous one would have ended, giving the sampler context to keep motion coherent across seams.
• extend_mode - what happens when the control sequence runs out before the loop does. none returns whatever's left (possibly a short batch, has_frames = false); repeat_last pads with copies of the final frame; loop wraps around to the beginning of the sequence so a looped shot keeps getting valid conditioning.

On top of the frames, it also picks the current iteration's string and seed from a string_batch / seed_batch - so you can vary your prompt and seed per chunk from one set of pre-built arrays, falling back to the last valid value when the batch is shorter than the iteration count. That's why the outputs include them.

The inputs and outputs

The ones you'll actually set:

• control_images - your full control IMAGE batch.
• frames_per_iteration (default 81) - window size; must match the loop's actual per-pass frame count.
• overlap_frames and extend_mode - the seam-handling options above.

Outputs, all consumed by the loop:

• control_slice (IMAGE) - this iteration's conditioning frames.
• has_frames (BOOLEAN) - true while the sequence still has a full window; this is your stop signal.
• string (STRING) and seed (INT) - per-iteration prompt/seed, if you fed batches in.

Installing it

Part of the Mickmumpitz pack. ComfyUI Manager → search "Mickmumpitz" → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git

No extra models or heavy deps beyond the pack's numpy/Pillow/opencv baseline.

Common issues

Two gotchas trip people up. First, frames_per_iteration here must match what your sampler actually produces - if it generates 121 frames per pass but you slice 81, every window after the first is misaligned and your conditioning drifts out of sync. Second, extend_mode = "none" is the honest option: when the control sequence runs out, has_frames goes false and downstream nodes can stop the loop. If you pick repeat_last, the node keeps producing frames forever (a valid choice for tail generation, but it means your loop has no natural stopping signal from this node - you need to cut it off elsewhere).