Batch Load Image Sequence (Trigger)

ComfyUI runs nodes the moment their inputs are ready. Most of the time that's exactly what you want - but it's a trap for the save-then-load pattern. If your loader only depends on a filename pattern, nothing in the graph tells ComfyUI "wait until the frames are actually written." The render node finishes scheduling, the loader runs, and you get a FileNotFoundError because the files you asked for don't exist yet. This node exists to close that gap: it's the exact same sequence loader, with one extra optional input - trigger - that you can wire anything into to force the wait.

That's the whole trick. trigger accepts any output type. Connect the WebP saver's count or paths output to it and ComfyUI now sees a dependency, so the loader can't execute until the saver has finished. You don't even have to use the data - the connection is doing the work, which is why the input is type ANY and marked to accept anything.

The rest of the node is byte-for-byte the sequence loader: path_pattern (default ./frame{:06d}.webp), start_index (0), frame_count (16, set 0 for auto-detect of all contiguous frames), and ignore_missing_images (false/true), returning an IMAGE batch and an INT count. Full details are on the plain Batch Load Image Sequence page - same inputs, same auto-detect behavior, same thread-pool loading.

Two implementation details worth knowing, because they explain how the node behaves:

• It won't unroll. The node sets INPUT_IS_LIST = True, which is ComfyUI's way of saying "never run this multiple times even if the trigger is a list." Some loader nodes expand over a list and execute once per item - this one deliberately does not. You get one load, one batch, no surprise re-runs.
• The trigger is optional. Leave it disconnected and this is functionally identical to the non-trigger loader. The node only becomes different the moment you connect something.

Where would you actually use this instead of just wiring the data directly? If you're loading via a pattern rather than via the saver's returned path list, there's no data flowing from saver to loader, so there's no ordering - that's the case where a trigger earns its keep. You rendered to disk with a different layout than you're loading from, but you still need to know the write finished. The README's framing is a render-to-video handoff, and it's the right call there: hook the previous node's output into trigger, load your frames, run your Video Combine, done.

One honest caveat: if you have any data dependency between the producer and the loader - like feeding the saver's paths list into Batch Load Image List - the trigger is redundant. The graph already orders it. This node is for the cases where the ordering is real but the data isn't shared, and those cases exist often enough that the pack author shipped it separately.

Install from ComfyUI Manager (search "ComfyUI-FrameIO") or:

cd ComfyUI/custom_nodes
git clone https://github.com/room3dev/ComfyUI-FrameIO

Restart, and it's under FrameIO next to the plain loader, with the "(Trigger)" suffix. If a missing-file error from a save-then-load workflow ever drove you up the wall, this is the 30-second fix.