Rebatch Images

Say you've decoded a video into 100 frames, wired them all into a workflow that's "very VRAM intensive" - and the sampler promptly explodes. ComfyUI processes a whole batch at once, and a batch of 100 images means the model, 100 latents, and all the intermediate activations trying to live on your card at the same time. Rebatch Images is the built-in answer: it slices one big batch into smaller, individually-processed groups so your VRAM never has to hold everything.

It's the image-side sibling of Rebatch Latents (same idea, for the latent tensors), and it's one of those nodes you don't think about until you hit the wall - then it's the whole solution.

How it works

The node takes a list of images (that's the input type: a list, not a single tensor) plus a batch_size, and does something refreshingly literal:

1. Flatten every tensor in the input list down to individual frames.
2. Group those frames into chunks of batch_size.
3. Output each chunk as its own IMAGE in a list.

So 100 frames with batch_size = 10 comes out as a list of ten IMAGEs, each holding 10 frames. The final chunk can be smaller - 105 frames becomes ten tensors of 10 plus one of 5, and that's fine.

The key is what happens next. Because the output is a list, downstream nodes process each element separately rather than concatenating them back into one giant batch. That's the VRAM win: the sampler sees one group of 10 at a time, finishes it, moves on. Same total work, bounded peak memory.

The inputs that matter

• images - the list of IMAGE tensors to regroup. This is a list input; feed it from a load-image-as-list node or another list-producing node.
• batch_size (default 1, range 1–4096) - how many frames per output chunk. Set it to whatever your card comfortably runs in one pass.
• Output: a list of IMAGE tensors, each with batch_size (or fewer) frames.

The trap everyone hits first

There's a widely-shared moment of confusion about this node, and it's worth saving you the afternoon. People load a 100-frame sequence, plug it in with batch_size = 10, and report "it seems to do always the same 10 images." That's not a bug - it's a misunderstanding of what Rebatch rebatches.

Rebatch Images only regroups the data that's already in your graph. It doesn't load frames, it doesn't advance through a sequence, and it doesn't add any offset or start-frame logic. If the same 10 images keep coming out, the problem is upstream: whatever node is feeding it is producing the same 10 frames every time. For sequence work you still have to control the offset yourself (feed in a start-frame index, or wire up the loader so each chunk starts where the last one ended). Rebatch just reshapes; it never moves the goalposts.

When to reach for it

• Long frame sequences with limited VRAM. This is the canonical use: batch of 10, ten separate passes, no OOM.
• Splitting a batch you can't hold. If an image upscaler or a VAE Encode chokes on a batch of 32, rebatch to 8 and let each group run.
• Feeding a list-oriented pipeline. Anything downstream that expects a list of image groups will be happy here.

Common issues

• "Always the same images." As above - check your upstream loading/offset logic, not this node.
• Expecting it to chunk a single big tensor. The input is a list. A single IMAGE tensor with 100 frames isn't the same thing; make sure whatever feeds it is actually list-shaped.
• Final chunk shorter than batch_size. Not a bug. A remainder is expected and harmless.

It ships with ComfyUI core - nothing to install, and it loads no models. Just the node that lets your 8GB card dream in batches of ten.