Nodes/Image Batch Loader by Steve Lasmin/Image Batch Loader by Steve Lasmin
ComfyUI Node

Image Batch Loader by Steve Lasmin

Feed a whole folder through your workflow one image at a time — no clicking

By Eklipsis·Created 2 months ago·Updated 3 days ago· 0
Image Batch Loader by Steve Lasmin
    • image
    • width
    • height
    folder_path
    reset_counterfalse

    The name is the whole pitch: this node loads images from a folder sequentially, one per queue run, and wraps back to the first when it runs out. If you've ever sat there img2img-ing a folder of reference shots and manually dragged the next file into Load Image between runs, this is the "go make coffee instead" upgrade.

    It's a small node from a small pack (one commit, no dependencies, MIT), so treat it as a focused utility rather than a toolkit. But it fills a genuinely awkward gap. Most folder-loaders you'll find dump every image into one big batch tensor or a giant list up front. That's the right shape for "process 40 images in one queue item." This is the opposite shape: it hands you one image per queue item and silently advances a counter, so a fixed pipeline - img2img, ControlNet, a FaceDetailer pass, whatever - runs over your folder one shot at a time and you never touch the graph.

    The thing that makes it more than a counter is the outputs. folder_path and reset_counter are the only inputs; you get image (the loaded IMAGE tensor), plus width and height as STRINGs. Most loader nodes don't expose dimensions at all, and none that I know hand them to you as text. That's aimed at prompt builders and text-concatenation nodes where you want the resolution baked into a prompt string rather than hard-typed into an Empty Latent. If you just need the pixels, the strings are a freebie you can ignore - but they're why the author calls this out as "batch processing where dimensions need to be passed as text."

    How it actually steps forward

    The interesting bit is under the hood, and it's the reason this node doesn't desync. ComfyUI can call a node's execution function more than once per queue item - for validation, previews, downstream re-runs - and a naive "increment every call" loader would skip images or emit mismatched outputs. This one declares an IS_CHANGED method that returns id(prompt), which is the classic "always rerun, but only once per execution" trick from ComfyUI's caching docs: each queue item gets a fresh prompt object, so the node is always considered changed for the next run, yet stable within one. It caches the loaded result keyed to that prompt id, so every duplicate call inside a single run returns the same image, dims included, and the counter advances exactly once. Nice clean piece of plumbing.

    Other mechanism details worth knowing: it reads the folder fresh each time, sorts filenames alphabetically, and accepts PNG, JPG, JPEG, WEBP, BMP, GIF, TIFF and TIF. Images get flattened to RGB, so an alpha channel is dropped (transparency becomes background). It needs torch, numpy, and PIL - all already inside ComfyUI, which is why the pyproject.toml lists zero dependencies.

    Installing and the gotchas

    ComfyUI Manager → Install via Comfy Registry → search "Image Batch Loader by Steve Lasmin", or clone it in:

    cd ComfyUI/custom_nodes
    git clone https://github.com/Eklipsis/comfyui-image-batch-loader-steve-lasmin.git
    

    Restart and you'll find it under Steve Lasmin → image. No models to download, nothing else to configure. The node lives on the boosty.to/stevelasmin support page if you want to thank the author.

    Three gotchas, because each one has bitten someone:

    • It takes an absolute OS path, not a ComfyUI folder. Core Load Image reads from your input/ directory; this node reads straight off the filesystem, so folder_path is something like /home/you/imgs/batch01 or C:\Images\batch01. Point it at input/ relative junk and it errors with "Folder path does not exist."
    • The counter survives reruns. State is keyed to the node's id, so re-running the workflow doesn't restart at image 1 - it continues where it left off. That's the intended "process a folder over days of runs" behavior, but it surprises people the first time.
    • reset_counter is a one-shot. Flip it to true, run once, and the next queue item starts from the first image again; the counter then advances as usual. Set it and forget it only if you actually want image 2 on every subsequent run.

    It's the sort of node that's trivial in concept and quietly saves you an hour of babysitting a queue. If you process folders through a fixed workflow, grab it.

    CategorySteve Lasmin/image

    Inputs (2)

    NameTypeDefaultDescription
    folder_pathSTRINGAbsolute path to the folder containing images
    reset_counterBOOLEANfalseReset counter to start from the first image again

    Outputs (3)

    NameTypeDescription
    imageIMAGE
    widthSTRING
    heightSTRING