TS Image Batch to Image List

ComfyUI is inconsistent about batches. Some nodes want one big IMAGE tensor with many frames stacked in the batch dimension; others want a list of single-frame images and will happily process each one. That mismatch is the whole reason this node exists: it converts an IMAGE batch [B,H,W,C] into an IMAGE list - a Python list of single-frame tensors, one per batch item.

It's the kind of boring-but-indispensable plumbing the node-plumbing doc spends whole sections on: half of building workflows is just making data flow between nodes that disagree about shape. The pack ships this node and its mirror (TS Image List to Image Batch) as a pair, and the README puts it plainly: "Needed when one node expects a batch and the next wants per-frame iteration."

How it works

There's nothing to understand beyond the shape conversion. Feed a batch in, get B single-frame images out, in order. The subtlety - and the reason this is a list and not just another batch - is that ComfyUI's type system treats "list of IMAGE" (is_list: true) as a distinct thing from "batched IMAGE." Some custom nodes iterate over a list, one element per run or per sub-batch; some take the whole tensor at once. This node is the adapter between those two worlds.

A quick way to tell which you're dealing with: if a node's input socket says it wants a list, a single batched IMAGE won't satisfy the type check (or worse, will silently treat your whole batch as one image). When that happens, this node - or its inverse for the opposite direction - is the fix.

The input and output

• image - the batch to split.
• images (list) - one single-frame image per batch item.

One in, one out, nothing else. There's no count output and no option - if you want to know how many frames you got, count them from the list or grab a count upstream.

Installing it

Part of comfyui-timesaver (ComfyUI Manager → "Timesaver", or manual clone + pip install -r requirements.txt + restart). No models, no dependencies - it's a tensor reshape.

When you actually need it

You'll know by the error, usually. A node that expects per-frame iteration throws a type mismatch (or worse, produces nonsense because it read B,H,W,C as a single image) when handed a batch, and suddenly you're adding this node to the graph. The other common trigger is custom-node code that explicitly loops for img in images: expecting a Python list - which works on a list but would silently process a batched tensor as one item. If you're assembling workflows from different authors' packs, keep this node (and its inverse) in your back pocket; shape mismatches are the number-one cause of "my graph was fine yesterday" breakage when you swap a loader or sampler for one with a different batching convention. And yes, it handles a single-frame batch fine too - one image in, a one-item list out - so you can keep it in the graph unconditionally without worrying about edge cases.