Image Iterator

ComfyUI queues run a graph once per execution - there's no native "for each image in this folder" loop. Image Iterator fakes that loop by keeping state between queue runs: every time you hit queue, it hands you the next image from a folder instead of the same one, so a workflow you'd otherwise run manually 200 times becomes one you queue 200 times and walk away from.

How it works

folder_path is where the images live. iterator_mode picks how it walks through them: sequential goes in order and stops (or holds) at the end, random picks a different one each run, Infinite loops back to the start once it runs out instead of stopping, and sequential_flagout is the sequential mode with the end-of-list signal actually wired up for you to use. is_reload forces the node to re-scan the folder on the next run - flip this on if you've added or removed files since the workflow was built, since otherwise it's presumably working off a list captured earlier. is_enable is this pack's usual toggle to bypass the node without deleting it.

Four outputs come back per run: image, the actual IMAGE for that step, ready to feed into a VLM node or any other image-consuming node; image_name and image_path, string metadata about which file you're currently on - genuinely useful if you're logging results or naming output files to match the source; and is_end, a boolean that flips true once you've gone through the whole folder. That last one is the important one for automation: wire it into whatever stop-condition logic your workflow uses (or a loop-controller node) so a batch job actually knows when to stop instead of running forever on Infinite mode or silently re-processing the first image once sequential wraps.

Where it fits

The obvious pairing is a VLM node - this pack's Easy VLM-GGUF Loader plus an LLM node configured for local/GGUF image input, or an API-based vision model. Point Image Iterator at a folder of screenshots, product photos, or generated renders, and you've got an automated captioning or tagging pipeline: queue once per image (or use ComfyUI's own queue-count controls), let the model process each one, and use image_name/image_path to keep the results attributable to the right source file.

Installing it

No separate install - it's part of the full pack:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart ComfyUI.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt inside your ComfyUI Python environment, restart.

This node itself doesn't need the pack's heavier local-model dependencies - it's file I/O, not inference - but whatever you're feeding the images into (a local VLM loader, for instance) will.

Common issues

The state-between-runs behavior is the thing to actually understand, because it's also the thing that trips people up. This node isn't stateless the way most ComfyUI nodes are - its output depends on how many times you've already queued the graph since it last reset, which means if you're testing your workflow by repeatedly hitting queue while iterating on unrelated parts of the graph, you're also silently advancing through the folder. If your outputs look mismatched from what you expected, check whether you've been burning through iterator state without meaning to, rather than assuming the node picked the wrong file.

sequential mode's exact behavior once it reaches the last file is worth verifying with a small test folder before trusting it on a big batch - whether it holds on the last image, errors, or needs is_end handled explicitly to avoid an unwanted extra run is exactly the kind of edge case worth confirming yourself rather than assuming, since the schema doesn't spell it out. And if you've dropped new files into folder_path mid-session and they're not showing up, that's what is_reload is for - the node likely isn't watching the filesystem live.