Image Batch To Sub Batches

ComfyUI treats a "batch of images" as one tensor with a batch dimension on index 0. If you generate 8 images at once, everything downstream sees a single IMAGE with shape [8, H, W, C] - which is great until something in the chain chokes on a big batch. That's where Image Batch To Sub Batches comes in: it takes that one big IMAGE tensor and cuts it into a list of smaller ones. That's the entire job, and the entire pack - the README is upfront that this is the only node in ComfyUI-ImageBatch-Utility so far.

The name is honest, and the use case is real. Crank the batch size on Empty Latent Image to 16 to spin out variations in one pass, and you'll eventually hit the wall everyone hits: some node in the middle blows up with torch.cuda.OutOfMemoryError, or a tool that's finicky about batch size just refuses. "Batch and pick" is a standard strategy in this ecosystem for a reason (you generate a pile and keep the good ones), and this node is how you tame that pile after the sampler has done its work.

How it works

Read the source and it's a one-liner wrapped in a class. It takes image.shape[0] (the batch count), computes ceil(batch / batch_size) chunks, and slices:

num_batches = (image.shape[0] + batch_size - 1) // batch_size
return ([image[i*batch_size:(i+1)*batch_size] for i in range(num_batches)],)

Two details matter. First, if the original batch size isn't perfectly divisible, the last sub-batch gets the remainder - a batch of 10 with batch_size 3 gives you 3, 3, 3, 1, not an error. Second, and this is the part people miss: the output is a list of tensors, not one tensor. The node sets OUTPUT_IS_LIST = True, and ComfyUI's execution engine responds by running whatever node you plug the output into once per list entry. That's the whole trick - it's not just rearranging data, it's forcing downstream steps to process each sub-batch on its own, which is exactly why it actually relieves VRAM pressure instead of just shuffling pixels around.

The inputs that matter

There are only two, both required:

• image - the IMAGE tensor you want to split. Comes straight off a sampler's output, a Load Image batch, or anything else emitting IMAGE.
• batch_size - an INT, default 1, minimum 1. The number of images per output sub-batch.

Set batch_size to 1 (the default) and a 16-image batch becomes a list of 16 single images - this is genuinely the most common way people use it, because a lot of list-aware tooling prefers one image at a time. Set it to 4 and you get four-image chunks.

The single output is also typed IMAGE, so it wires like a normal image socket - but remember it's carrying a list, so it belongs downstream of the list handling, not into a plain node that expects one tensor.

Installing it

This is the friendliest install in the ecosystem: no models, no weights, no requirements.txt, nothing that needs a separate download. The whole thing is one small Python file with zero dependencies beyond what ComfyUI already ships. ComfyUI Manager is the easy route - search "ComfyUI-ImageBatch-Utility" and hit install. Or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/watarika/ComfyUI-ImageBatch-Utility

Then restart ComfyUI. That's it. Search Image Batch To Sub Batches in the node menu (or right-click → Add Node → image).

Where people get tripped up

The list output is the main gotcha, and it's not the node's fault. If you feed this into a downstream node that doesn't accept lists, ComfyUI runs that node once per element - which is usually what you want, but it changes how you think about the graph: each sub-batch now goes through the whole downstream chain separately, so a batch that took one pass now takes several smaller ones. Slightly slower in aggregate, much kinder to your VRAM.

The second gotcha is the remainder. If your workflow downstream assumes every sub-batch is exactly batch_size wide - say, a node with a hard size requirement - the last one can be smaller. Pick a batch_size that divides your batch cleanly, or just know the tail is ragged and design around it.

Beyond that there's nowhere to go wrong. It can't silently corrupt images, it has no secret settings, and it's fast enough that the overhead is a rounding error. For a node this small, that's the best review you can give it.