Image List Length (XJ)

You've accumulated a list of images with the pack's list nodes, and now your loop logic needs to know how big it is - whether to keep iterating, how many iterations to budget, or whether the list is even worth processing. XJImageListLength answers that: feed it an image list, and it returns the count as an INT.

It's the simplest member of the ComfyUI-XJNodes image-list family (empty list, append, get-by-index, slice, and this), and it exists for the same reason len() exists in Python: collection code constantly needs to know the size of what it's building. The obvious uses are loop termination conditions, "did we collect anything at all?" checks, and reporting - but it's also the node you reach for when you're not sure a batch got split the way you expected.

How it works

The mechanism is one operation: it verifies the input is actually a list (the pack's list nodes all do this defensive check), then returns len(image_list). Because the input is flagged list-aware, it receives the true Python list from the pack's list-producing nodes - not a batch tensor - so the count is the number of individual list entries, which is what you actually want.

A useful mental note: because XJAppendImageList splits multi-frame batches into individual entries when it appends, this node's count reflects the post-split size. Feed it a list that had one batch of 4 appended and it reports 4, not 1. That's usually the intuitive answer, and it's exactly what makes the number trustworthy for loop math.

The inputs and outputs

• image_list (IMAGE, list) - the list to measure.
• Output: length (INT) - number of images in the list.

Wire the INT into a loop end condition, a compare node, or a display - anywhere a count is useful. The output is a plain integer, so it plays nicely with the rest of ComfyUI's math and control nodes.

Installing it

Part of ComfyUI-XJNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/alexjx/ComfyUI-XJNodes

then restart ComfyUI (or ComfyUI Manager → ComfyUI-XJNodes). No models, no dependencies.

Common issues

The one thing to watch is feeding it a batch tensor instead of a list - the type check will fire and you'll get a Expected list error, which is your cue that the upstream node isn't one of the list-aware ones. There's no off-by-one drama because the node just calls len(); the only surprises come from assuming a batch counts as one entry when it actually got split during append. Keep your list sources straight and this node is as boring and reliable as a utility should be.