Image Conveyor
The node that turns your canvas into an image assembly line
- image
- mask
- path
- index
- remaining_pending
- source_path
- ref_image_1
- ref_image_2
- ref_image_3
- ref_image_4
- ref_image_5
- ref_image_6
- ref_image_7
- ref_image_8
- last_frame
Image Conveyor is the batch loader you reach for when "process a folder" isn't what you want. Drop twenty images onto it, and it hands them to your graph one at a time, per prompt run, in the order you see them - no folder iterator, no glob pattern, no "which file is it on now" guessing. The whole queue lives visibly on the node as thumbnails, and you can reorder, delete, or re-run any item by hand. If you've ever built a folder-walking workflow and then spent ten minutes fighting the order, this is aimed squarely at you.
The pitch is the explicit queue state. Where most batch loaders are iterators - they walk a directory and load whatever's next - this one keeps each image in one of three states: pending, queued, and processed. pending means waiting, queued means a prompt run has already reserved it, processed means done. You can see at a glance where the run will land next, and the remaining_pending output tells your workflow how much is left.
How it works
ComfyUI nodes are stateless, so the queue is serialized into a JSON string and stored in the node's own widget - that's what state_json, ui_state_json, and queue_item_json are. Don't edit them by hand; they're the plumbing. state_json holds the actual queue (and the auto_queue / catch_canvas_drops toggles you flip in the UI), ui_state_json tracks selection, and queue_item_json is how consecutive queued prompt runs pass their reservation to each other so the next run picks up exactly the next item.
When you run, the node calls its load_next() and actually loads the image through ComfyUI's built-in LoadImage node, then marks the item processed via an internal UI delta. Dropped files get copied into your ComfyUI input folder by the node's own server routes, with thumbnails generated as it goes - which is also why a saved workflow keeps working on another machine as long as you bring the images.
The outputs that matter
image- wire this into your conditioning, sampler, or whatever the pipeline is processing. The whole point of the node.mask- the image's alpha channel if it has one; empty otherwise.index- 1-based position in the queue, handy for stamping filenames or tracking progress.remaining_pending- how many items are still waiting after this run. Wire it into a counter or a loop condition and you can build a "stop when the queue is empty" graph.path- the ComfyUI-side annotated input path that actually got loaded.source_path- a best-effort hint of the original dropped path. One caveat the README is upfront about: absolute native paths get redacted to filename-only so exported workflows don't leak your local directory layout. Don't count on getting a full filesystem path back.
Install
No models, no heavy dependencies - pyproject.toml lists zero Python dependencies, and there are no model downloads. Install through ComfyUI-Manager (search "ComfyUI Image Conveyor") or:
cd ComfyUI/custom_nodes
git clone https://github.com/xmarre/ComfyUI-Image-Conveyor.git
Then restart ComfyUI. The gallery is a custom widget built on the frontend's supported DOMWidget path (VueNodes-compatible), so it needs a reasonably modern ComfyUI frontend - if you're on an ancient install and the node shows up with nothing inside it, update the frontend before blaming the pack.
Troubleshooting
- Items stuck on
queued. If a prompt run is reserved but fails before the loader executes, its items stayqueuedforever. There's a Clear queued action for exactly this. - "missing file" validation errors. Because paths resolve against your ComfyUI input folder, moving or deleting a dropped image breaks the queue. Re-add it or the node refuses to run.
- Catch canvas drops ambiguity. If several conveyors have it enabled and the node can't infer a target, the drop falls back to ComfyUI's normal handling. Select the conveyor you want first.
- Empty queue. The node will tell you "no images have been added" - which beats silently loading nothing.
Where people get burned is expecting a folder iterator and finding a stateful queue. Different tools. If you want "process everything in this directory every run," Image Conveyor isn't it; if you want a visible, manually-tamable queue that advances one step per execution, it's the one you'd reach for.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| state_json | STRING | {"version":2,"items":[],"auto_queue":false,"dont_consume":false,"catch_canvas_drops":false,"images_per_execution":1,"output_mode":"persistent_refs","reference_slots":[null,null,null,null,null,null,null,null],"active_reference_preset_id":""} | — |
| ui_state_json | STRING | {"version":2,"selected_ids":[],"source_paths":{}} | — |
| queue_item_json | STRING | — |
Outputs (15)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| mask | MASK | — |
| path | STRING | — |
| index | INT | — |
| remaining_pending | INT | — |
| source_path | STRING | — |
| ref_image_1 | IMAGE | — |
| ref_image_2 | IMAGE | — |
| ref_image_3 | IMAGE | — |
| ref_image_4 | IMAGE | — |
| ref_image_5 | IMAGE | — |
| ref_image_6 | IMAGE | — |
| ref_image_7 | IMAGE | — |
| ref_image_8 | IMAGE | — |
| last_frame | IMAGE | — |