⬡ Polyhedron Pick Frame
One frame out of a batch — the one that converges cleanest
- images
- image
The whole node is one idea: grab a single frame out of a video batch and hand it on as an image. Two inputs, one output, no config to fiddle with. It exists because of a very specific Wan workflow - the "T2I LoRA fix" - but it's handy anywhere you need one representative frame out of a clip.
The input is images (an IMAGE batch) and frame_index, which is 0-based. Set 3 and you get the fourth frame. Leave it at -1 and you get the middle frame, and for the use case this node was built for, the middle frame is the recommended pick. The tooltip says it plainly: the sampler converges most cleanly on the central frame, since the first frame can carry anchor artifacts and the last can be slightly blurred by motion continuity. If you're going to spend a whole upscale or refine pass on one frame, don't spend it on the weakest ones.
Where it fits
The companion node is ULSWanFrameInflate, and together they're the workaround for a nasty kijai/WanVideoWrapper bug (issue #1827) where a T2I LoRA silently does nothing because the latent is only one frame long - too short for the LoRA's attention to trigger. The workflow looks like this:
WanVideoEmptyEmbeds → ULSWanFrameInflate → WanVideoSampler → WanVideoDecode → ULSImagePickFrame
Inflate bumps the latent from 1 frame to N so the LoRA actually activates; the sampler runs in video mode; and after decode you pull the best frame back out with this node. If you're generating a still, the middle frame is the frame worth keeping.
Installing it
It's in the Polyhedron Suite pack, same as everything else here:
cd ComfyUI/custom_nodes
git clone https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack.git
# restart ComfyUI
Or use ComfyUI Manager and search "Polyhedron Suite". No extra dependencies - this node is pure tensor slicing on top of a video decode.
That's genuinely it. There's no deep mode here, no hidden gotcha worth a paragraph - the node picks a frame, and the only decision it asks you to make is which one. The answer, for the run it was built for, is -1.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| frame_index | INT | -1-4096–4096 | Which frame to pick (0-based). In the default 'middle (legacy)' mode, -1 means the MIDDLE frame (recommended for inflated T2I runs — the sampler converges most cleanly on the central frame, since the first frame can carry anchor artifacts and the last can be slightly blurred by motion continuity). In 'index' and 'range' it is Core's convention instead: -1 is the LAST frame. The mode below says which reading applies. |
| mode | COMBO | middle (legacy) | Which frame(s) to take. 'middle (legacy)' is this node's original behaviour and stays the default so saved workflows do not change: frame_index -1 means the MIDDLE frame, any other value is a plain 0-based index. WATCH OUT -- Core's 'Get Image from Batch' reads -1 as the LAST frame instead, which is why the other modes are named rather than numbered. 'last' / 'first' take one frame from either end. 'index' is 0-based and accepts negatives the way Core does (-1 last, -2 second to last). 'range' takes `count` frames starting at frame_index. 'every Nth' takes every count-th frame from the whole batch -- a contact sheet from a video. |
| count | INT | 11–4096 | How many frames for 'range', and the step for 'every Nth'. Ignored by the other modes. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |