PVL Image Batch to Image List

ComfyUI has two ways of carrying multiple images around: a batch (one IMAGE tensor with N frames stacked on the batch axis) or a list (a Python list of IMAGE tensors). Most nodes accept one or the other, and the mismatch is a classic "why won't this wire connect" moment. This node is the bridge in one direction: it takes a batch and splits it into a list of single-image tensors, so you can feed nodes that expect lists.

Why you'd need it with this specific pack: the Gemini Multi and Nano Banana Multi nodes take multiple image ports (image1, image2, …), and each port eats a single frame - they don't take a batch and fan it out. A grid of six frames on one IMAGE port only gets its first frame seen. Run that batch through this node first, and each frame becomes its own output you can wire to its own port.

How it works

It slices the input batch along axis 0 - image[0:1], image[1:2], and so on - keeping each slice as a 4D tensor with batch size 1. The output is declared as a list (OUTPUT_IS_LIST = True), which is the part that matters: nodes with list-typed inputs will now accept the wire, and list-consumers like some batch loopers and the pack's own utilities will iterate properly.

One input: image (an IMAGE batch). One output: IMAGE, as a list.

It's worth knowing the pack also ships the reverse: PVL Image List to Image Batch (PVL_ImageListToImageBatch), which concatenates a list back into a batch - and that one even resizes mismatched frames to match the first image, which this node obviously doesn't need to do since splitting never changes sizes.

Installing it

Part of the pvlprk "ComfyUI Assistant Node" pack:

cd ComfyUI/custom_nodes
git clone https://github.com/pvlprk/comfyui-pvl-api-nodes

Restart ComfyUI. No API key, no models, no network - this is pure tensor plumbing and works fully offline.

Common issues

The only real pitfalls are conceptual. First, "list" in the UI sense: after this node, what looks like one output port is actually a list of N items, so a plain IMAGE input on the next node won't necessarily accept it - that's the design, not a bug. Second, order is preserved (splitting never reorders), but if you recombine later with the reverse node and your frames have different sizes, the reverse node resizes to the first frame rather than erroring - know that when you compare before/after pixels. Third, an already-single-frame image goes through fine (list of one), so you can always chain this before a list node without checking batch size first. About as failure-proof as a node gets.