Unlim Image List

Unlim Image Batch stacks images into one tensor, and a tensor demands a single size - so it crops or pads to reconcile. Unlim Image List is the sibling for when you don't want that. It returns a proper ComfyUI image list instead of a stacked batch, which means images of different sizes can travel together untouched, and each list item is exactly one frame. No options, no reconciliation, no quality decisions made for you.

How it works

The node is deliberately dumb: every connected image_N input is split into its individual frames - a batch of 4 becomes 4 items - and emitted as a list in slot order. The output declares OUTPUT_IS_LIST, which changes how downstream nodes behave: instead of processing one batch, they run once per list item. That's the property loops are built on. The typical pattern is a loop/iterator setup: read the list length, pull an item by index with a Get by Index-style node, do your per-image work inside the loop.

The input list grows the same way as the rest of the pack's "Unlim" family: image_1 is required, image_2 is optional, and a new empty slot appears whenever you connect the last one. Disconnect and trailing empties collapse. There is genuinely nothing else to configure - no mode, no pad_color, no skip_empty.

When to reach for it over Unlim Image Batch

If every image is the same resolution and you want one batch tensor, use the Batch node. If you're feeding an Image Compare or a grid, a batch is usually what it wants. But if your sources are mixed-size - a batch of crops next to a full-res shot - the List node lets them coexist without a lossy crop or a padded letterbox, and it's the one to pick for anything iteration-shaped. The pack's own Get Accumulator (images list) is built on exactly this: it collects same-named Set nodes into a list so accumulated images of different sizes stay intact.

Install

Part of the Kinburg-Nodes pack: ComfyUI Manager (search "Kinburg-Nodes") or cd ComfyUI/custom_nodes && git clone https://github.com/Kinburg/Kinburg-Nodes, then restart. No extra dependencies.

The gotcha

Because downstream nodes run per item, the total execution cost is per-image, not per-batch. A 50-image list means 50 runs of whatever you plug after it - that's the loop semantics working as intended, but it surprises people who expected a single batch pass. Also note that list outputs can't always wire into nodes that only accept a plain IMAGE batch - check that the consumer takes a list, or you'll get a type mismatch at the socket.