Nodes/ComfyUI-Advanced-ControlNet/🚫Load Images [DEPRECATED] πŸ›‚πŸ…πŸ…’πŸ…
ComfyUI Node Runs on cloud

🚫Load Images [DEPRECATED] πŸ›‚πŸ…πŸ…’πŸ…

Deprecated β€” here's what it did and what to use instead

By KosinkadinkΒ·Created 3 years agoΒ·Updated 12 days agoΒ· 994
🚫Load Images [DEPRECATED] πŸ›‚πŸ…πŸ…’πŸ…
    • IMAGE
    • MASK
    • INT
    β—„directoryβ–Ί
    β—„image_load_cap0β–Ί
    β—„start_index0β–Ί

    Let's get the important part out of the way first: this node is marked DEPRECATED right in its own display name inside ComfyUI (you'll see it show up as "🚫Load Images [DEPRECATED]" in the node picker). If you're wiring up a new workflow, don't reach for this one - it's a leftover utility from Advanced-ControlNet's early days, not something the pack's own README even documents anymore. The README's node reference covers the ControlNet, Timestep Keyframe, and Latent Keyframe nodes in detail; this one isn't mentioned at all.

    What it did

    Point it at a folder, and it loads every image inside as a batch, along with a matching batch of masks and a count of how many it found. The obvious use case, given what pack it lives in, was feeding a folder of reference frames or preprocessed condition images straight into Apply Advanced ControlNet's image input - which explicitly supports one image per latent when you hand it a batch ("if more images provided, will use each image separately for each latent").

    The inputs and outputs (for reference)

    • directory (required, string) - a path on disk. This has to be a path the ComfyUI process itself can see and read; if you're running on a hosted executor rather than a local install, a folder path from your own computer won't resolve, since the run environment has its own filesystem separate from your machine.
    • image_load_cap (optional, default 0 = no cap) - stop after loading this many images.
    • start_index (optional, default 0) - skip ahead this many files before loading, useful for resuming a batch partway through a large folder.

    Outputs: IMAGE (the batch), MASK (a matching batch), and an INT reporting how many images actually got loaded - handy for wiring into downstream nodes that need to know the batch size.

    What to use instead

    This exact job - load a folder of images as a sequence, in order, for a video or ControlNet-per-frame workflow - is one of the most common asks in the ComfyUI community, and several actively maintained packs cover it better now: WAS Node Suite has a "Load Batch Images" node built for it, and ComfyUI-Inspire-Pack's "Load Image List From Dir" is the one people point newcomers to for sequential, index-driven loading. If your actual goal is feeding video frames into an AnimateDiff or Advanced-ControlNet pipeline specifically, ComfyUI-VideoHelperSuite's video/image-sequence loaders are the standard choice - they're what most current AnimateDiff workflows actually chain together.

    For a lighter, dependency-free option with no extra pack at all: use core ComfyUI's Load Image node, right-click it and convert the image widget to an input, wire in a Primitive set to increment, and set your queue's batch count to the number of files - that walks through a folder one image per queued run without installing anything.

    Common issues & troubleshooting

    The node doesn't appear, or looks stripped down. Since it's deprecated and unmaintained inside an active pack, don't spend time debugging it - the fix is almost always "use one of the alternatives above" rather than fighting this node into working.

    Directory path errors on a cloud or hosted executor. As noted above, "directory" nodes assume local filesystem access. On a hosted run, your images need to already be somewhere the execution environment can reach - check how your platform expects input files to be supplied rather than assuming a path from your own machine will work.

    Memory blowing up on a large folder. This was a known complaint about directory-loading nodes generally in the community: loading everything into a batch at once means everything sits in RAM/VRAM simultaneously. If you're working through hundreds of frames, prefer a sequential per-run loader (the increment-primitive trick above, or a purpose-built sequential loader) over anything that loads a whole folder as one batch.

    Inputs (3)

    NameTypeDefaultDescription
    directorySTRINGβ€”
    image_load_capoptINT00–9007199254740991β€”
    start_indexoptINT00–9007199254740991β€”

    Outputs (3)

    NameTypeDescription
    IMAGEIMAGEβ€”
    MASKMASKβ€”
    INTINTβ€”