LayerUtility: Image Batch To List(Multi)

ComfyUI treats a batch of images as one unit - one wire, N images stacked inside it. That's efficient for a lot of things, but it falls apart the moment you need to do something per image: save each one under a different filename, run a per-item caption node, or feed each frame separately into something that only accepts one image at a time. This node is the bridge - it takes a batch and turns it into a genuine list, where each item flows through downstream nodes individually rather than as one bundled tensor.

How it works

It slices the incoming image batch into groups of batch_size and emits them as a list output rather than a single stacked tensor - the difference matters because ComfyUI executes list outputs by running the downstream chain once per item, instead of once for the whole batch. That's what unlocks per-image processing: a Save Image node fed from this will write out one file per image instead of one grid, a per-item text node will get a fresh execution for each frame, and so on.

The inputs and outputs that matter

• image - the batch you want split.
• batch_size (default 6, range 1–64) - how many images go into each chunk. Set this to 1 if you want the classic "one image, one execution" behavior; a higher number groups images into sub-batches instead of splitting them fully.

Output: a single image output, but marked as a list - everything wired to it downstream will fire once per item (or per chunk, depending on batch_size) rather than once total.

How to install it

Search ComfyUI Layer Style in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/chflame163/ComfyUI_LayerStyle
pip install -r ComfyUI_LayerStyle/requirements.txt

Restart; it's under 😺dzNodes → LayerUtility → Data.

Common issues

The thing that catches people out is batch_size not meaning what they expect - it's not "how many total images," it's "how many images per chunk of the list." If you want true one-at-a-time processing, set it to 1; leaving it at the default 6 will still hand downstream nodes groups of up to six images per list item, which isn't the same as full splitting and can look like the node "isn't working" if you were expecting individual execution. The other one: once you're in list-land, everything downstream re-executes per item, which is correct but easy to forget - a slow node further down the chain now runs N times instead of once, and your total run time scales with batch size accordingly. If a workflow that used to be fast suddenly crawls after adding this node, that's almost always why.