Image Queue Processor Pro (延遲載入)

If you want to run img2img across a whole folder of images - a hundred, a thousand - this is the one to use. The author says so outright, and the reasoning is solid. Point it at a directory and it processes the images one at a time, each a full separate generation, without ever loading the whole folder into memory.

That "without loading the whole folder" part is the entire pitch. The older Image Queue Processor in the same pack reads every image into memory first, then serves them by index - which means a couple hundred images can eat several gigabytes before you've generated anything. Pro flips it: it only reads the folder's file list, then loads the single image at the current index when it's that image's turn. The author's own numbers - 200 images sitting around 20MB of RAM instead of multiple GB. For long batch img2img runs that difference is the whole ballgame.

How it works

Same serial-queue engine as the rest of aidec's pack, but self-contained. It keeps a server-side counter, hands you the image at current_index, then advances and re-queues the workflow so the next image runs on its own. Because it reads the directory itself, you don't need a separate loader node feeding it - that's the big simplification over the plain Image Queue Processor, which needs something like Inspire Pack's Load Image Batch From Dir wired into it. Pro is the folder loader and the queue in one box.

The inputs that matter

• directory - the folder of images to walk. This is basically the whole setup.
• start_index - where to begin (0 for the top of the folder).
• trigger_next - the auto-advance; on means it drives the batch itself.
• queue_id (optional, default default) - a name for this queue's state. Give two Pro nodes different IDs and they track their positions independently, which is how you'd run more than one folder in a graph.
• reset_queue (optional) - flip this to send the counter back to the start without hunting for start_index.

Outputs are the payload of the node: image and mask to feed your sampler, plus filename and full_path for the current image, and current_index / total / completed / status to track progress. Those filename outputs are the good part - wire filename into your Save Image so each output keeps the source image's name, and matching up before/after pairs across a thousand files stops being a nightmare.

Installing it

cd ComfyUI/custom_nodes && git clone https://github.com/aidec/Comfyui_TextBatch_aidec, then restart ComfyUI (or use ComfyUI Manager's Install via Git URL with the repo link). No models, no extra dependencies - pure Python on top of ComfyUI. It lands under the TextBatch category.

Where people get burned

• The first queue sometimes only does one image. Known pack-wide quirk - just queue it a second time and it walks the rest. Don't go debugging your directory path over it.
• Reset between runs. After a full pass, use reset_queue (or set start_index back to 0) before starting again, or it'll think it already finished the folder.
• One ComfyUI tab. The queue state is global server state. Two open workflows, or adding a second queue mid-run, and the counters cross wires. Single tab, let the batch finish.
• Directory path is server-side. On a hosted or serverless ComfyUI the folder has to exist on the server's filesystem, not your local machine - upload the images to a path the ComfyUI process can actually read.

For batch img2img specifically, reach for Pro over the plain Image Queue Processor every time. The memory story alone earns it.