Load Folder by Type

Core ComfyUI hands you one image at a time. That's fine for a single prompt, useless the moment you have an extracted video - 81 WAN frames sitting in a folder, and every tutorial telling you to "load them as a batch". You need a loader that reads a directory and spits out one batched IMAGE. That's this node, plus a filter layer so a disorganised input folder doesn't collapse into one 200-item dropdown.

Why you'd reach for it

The everyday job is a video round-trip: you rendered a clip, some other tool dumped the frames to disk, and now you want them in a graph for a WAN loop pass or an img2img sweep. Core Load Image won't do it. This node will, and it hands you the frame count as an INT - which matters more than it sounds, since WAN wants 1 + 4n frames and knowing the real number saves a debugging session.

The "by Type" half is the interesting bit. If your ComfyUI/input is a graveyard of 3d_render_01, 3d_render_02, vid_export_a, the node offers you 3d and vid as types and shows only the matching folders.

How it works

It scans the subdirectories of ComfyUI/input (skipping clipspace), list them newest-modified first, and derives a category from each folder's name: strip a leading [O] marker if there is one, then take everything before the first underscore, lowercased. So 3d_shots_day2 and 3d_shots_night both land under 3d. Folders with no underscore keep their whole name as the category. That [O] marker is the pack's own convention - its BatchImageSave symlinks saved sequences back into input - which is why your own renders appear here too.

The two dropdowns are linked: change directory_prefix and the second one repopulates with just that type's folders, served to the frontend on demand.

File loading then mirrors core's Load Image batch behaviour: list the directory, filter to image extensions, alphabetical sort, then apply skip and stride.

The inputs that matter

• directory_prefix - enum, default all, which shows everything. Pick a type to narrow the second dropdown.
• directory - the actual folder name inside input, [O] marker and all.
• image_load_cap - 0 means "all of them". Set it when you want the first N frames only.
• skip_first_images and select_every_nth - trim from the front, then take every Nth frame. select_every_nth: 2 halves your frame count, which is a cheap way to fit a long clip into a WAN segment.

Outputs are IMAGE (one batch), MASK (one per frame), and frame_count. The mask comes from the alpha channel, inverted (1 - alpha) exactly the way core Load Image does it. Files with no alpha get an all-zero mask, so if you were expecting your PNG transparency to show up, that's the reason it doesn't.

Install

ComfyUI Manager → search Link Comfy Nodes → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Mister-Link/link-comfy-nodes
cd link-comfy-nodes
pip install -r requirements.txt

Read that requirements file before you run it: nineteen lines including pytorch_lightning, mambapy, numba and clip straight from OpenAI's GitHub repo, all of which Manager will pull because a folder loader was the only thing you wanted. Worth knowing: the pack imports every node eagerly on startup, and one of the pixel-art nodes imports scikit-learn at module level. Miss a dependency for a node you'll never touch and the whole pack fails to load.

Where people get burned

Frames come out in the wrong order. The sort is a plain alphabetical sorted(os.listdir()), not a natural sort. frame_1.png, frame_10.png, frame_2.png is exactly the order you'll get, and your animation stutters every ten frames with no error to explain it. Zero-pad your exports (frame_0001.png).

The dropdown is empty. The list is subdirectories of ComfyUI/input only - a folder anywhere else is invisible, and so is one whose type doesn't match your selected prefix.

"Image size mismatch." The node refuses to batch frames of different dimensions, which is correct but unforgiving - one stray 1920x1080 in a folder of 1280x720 kills the load.

It re-runs when you don't expect it. Cache invalidation hashes the actual file contents of the selected frames, so dropping a new frame in re-triggers the node - good for iteration, mildly surprising when a graph you thought was cached goes hot again.

One last thing: the pack's README is a single sentence - "use at your own risk, I change how nodes behave without warning" - and it has no community footprint. Save a working workflow before you git pull.