GIR Loopy Dir
Hand it a folder, it hands you files one at a time
- file_count
- current_index
- current_file
- current_file_path
- all_files
The most exhausting part of ComfyUI is rarely the generation - it's the manual bit. You've got a folder of a hundred images you want to run through the same img2img graph, and the "right" way to do it in vanilla ComfyUI is: load file 1, run, load file 2, run, load file 3… and somewhere around file 40 you start googling for a script. GIR Loopy Dir is the "so did I" node from the Dir Gir pack, built to kill that whole dance. You give it a directory, it hands you one file per execution, auto-advances to the next, and wraps back to zero when it runs out. It's the thing a real r/StableDiffusion thread recommended when someone asked how to img2img every image in a folder one at a time.
The idea is simple, and it's the pack's best node - the reason to install Dir Gir at all. Wire in a directory string (from its sibling, GIR Dir Picker, or just typed in), and the node becomes your folder iterator: enumerate, filter, sort, advance, wrap.
How it actually works
Every time the node executes it re-scans the directory with os.listdir - which means new files you drop into the folder get picked up without restarting anything. Then it filters. Then it sorts. Then it picks the current index and serves you the file, and - unless you've told it not to - increments an internal per-node counter that lives on the ComfyUI server, not in your workflow. That counter wraps with a modulo, so queuing more jobs than there are files is fine; it just starts over. The loop_index widget on the node stays synced with the server between runs, which is why queuing works "in real time" the way the README promises.
The inputs that actually matter
directory- the folder to scan. It's aforceInputstring, so wire it from GIR Dir Picker rather than typing a path by hand.filter_type/filter_value- the pair you'll touch most.extensionmatches by suffix;regexmatches by pattern. Everything else has sensible defaults.loop_index- a manual override. Leave it alone for auto-advance; feed it an in-range value and the node will serve that exact file every run.pause_loop- freeze the counter so the same file comes out each time. Handy for testing one image before letting the queue rip.
Two filter gotchas worth knowing, straight from the code. The extension check is file.endswith(filter_value), so type .png with the dot - png will also match notpng. And regex uses re.match, which anchors at the start of the filename; a pattern like .*\.png$ behaves like you expect, a bare .png won't. Also: sort_order: random re-shuffles on every execution, so don't expect a stable random order across runs.
What comes out
Five outputs, but you'll mostly use current_file_path - the full path of the file being served this run, which is what you feed the loader - plus current_index and file_count for progress. There's also current_file (the bare filename) and all_files, the whole matched list.
Here's the trap the README warns about explicitly: don't wire current_index into a loader like LoadImagesFromPath. That node has its own built-in directory filtering and indexing, which won't line up with Loopy Dir's filtered indexes - especially with regex. That's exactly why the pack ships GIR Image Nabber, which loads by exact path and keeps your loop honest. (For video, the README points you at VHS Load Video (Path) instead.)
Install and gotchas
No models, no GPU heavy-lifting. Via ComfyUI Manager, search Dirgir; or manually:
cd Your_ComfyUI_Path/custom_nodes
git clone https://github.com/AshMartian/ComfyUI-DirGir
Then restart ComfyUI. The only real dependency is tkinter, which the pack tries to auto-install at first launch - sudo apt install python3-tk on Linux, brew install python-tk on macOS, pip install tk on Windows - and any can fail silently. If the directory picker's button is dead but Loopy Dir works, tkinter is your culprit. The node itself does zero validation on the path, so a directory that doesn't exist or can't be read will throw when you run it - make sure the string you're feeding it is real.
One honest caveat: this is a queue-time tool. Click Queue (or set the batch count) and it churns beautifully; it's not a "run once, get all files" node. But for that one job - process a whole folder, one at a time, in order - it's the least-fiddly thing I've found.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| directory | STRING | — | |
| filter_type | COMBO | extension | 2 options: regex, extension |
| filter_value | STRING | — | |
| sort_by | COMBO | name | 3 options: name, date_modified, date_created |
| sort_order | COMBO | asc | 3 options: asc, desc, random |
| loop_index | INT | 0 | — |
| pause_loop | BOOLEAN | false | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| file_count | INT | — |
| current_index | INT | — |
| current_file | STRING | — |
| current_file_path | STRING | — |
| all_files | COMBO | — |