Extract N Frames

Running an expensive per-frame process - a heavy upscaler, an img2img pass, some slow filter - across every frame of a 200-frame video batch adds up fast. Extract N Frames is a shortcut around that: pull a smaller number of frames, evenly spaced across the batch, run your expensive process on just those, and use the companion Merge Frames By Index node, also in this pack, to drop the results back into the full sequence afterward.

How it fits into a workflow

The node samples frames indices evenly across whatever batch you feed it - if you ask for 16 frames out of a 200-frame batch, you get roughly every 12th or 13th frame rather than a random or clustered selection, which keeps the sample representative of the whole sequence. Crucially, it also hands back index_list - exactly which original indices got picked - which is what lets the companion merge node put processed results back in the right place afterward instead of just concatenating them in the wrong order.

Inputs and outputs that matter

• frames (default 16, minimum 2) - how many frames to extract.
• images and masks - both optional. Feed either or both depending on what you're sampling from; the node extracts the same indices from whichever you provide.

Outputs: index_list - which original positions were sampled, hang onto this for the merge step - plus images and masks, the extracted subset, matching whichever inputs you actually fed in.

Installing it

Through ComfyUI Manager, search ComfyUI Image Filters, or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/spacepxl/ComfyUI-Image-Filters

Restart. No models needed - this is pure batch indexing, about as lightweight as it gets. The one dependency worth knowing across this whole pack is opencv: version conflicts with other installed node packs cause import errors on startup, fixed by the repo's import_error_install.bat, or manually by removing other opencv variants and keeping only opencv-contrib-python.

Where people get burned

Losing track of index_list is the main way this goes wrong - if you don't carry it through to the merge step, you've got a processed subset of frames with no way to know where they belong in the original sequence. Treat it as a required piece of state, not an optional output you can ignore just because you're only using images downstream.

The other thing to know going in: this is a sampling strategy, not free compute. If whatever you're processing needs to see every frame to work correctly - anything that depends on true temporal continuity - running it on a sparse sample and merging back will show visible seams at the boundaries between sampled and unsampled regions, the same kind of batch-boundary artifact people run into with any tool that processes video in chunks rather than as one continuous pass. This node is the right call for filters where each frame is processed independently and a representative subset is good enough, a cheap way to preview or approximate an expensive full-batch process; it's the wrong call for anything that needs the full temporal sequence to reason about.