Wan Keyframe To Video

The name sounds like it dials a paid API, but it doesn't - no key, no cloud, nothing. Wan Keyframe To Video is a conditioning node from the small apenguin24/ComfyUI-WanKeyframing pack that takes a handful of keyframe images and builds one latent clip that interpolates between all of them, with a different prompt per segment. It's the "keyframe chaining" trick the Wan community has been doing by hand - generate clip 1, take its last frame, feed it into clip 2 - collapsed into a single node that runs all the segments in one sampler pass.

Why you'd reach for it: the manual version is fiddly and accumulates quality drift; this is the automated version. Feed it four or five stills (say, the same character at dawn, noon, sunset, night) and it generates the transitions between each pair, holding the start and end frames of each segment as anchors so the model doesn't wander off into a new scene. You can also give each segment its own prompt, which is the part stock Wan I2V won't do without a pile of custom nodes.

How it works under the hood

The mechanism is straight out of ComfyUI's native Wan I2V conditioning, generalized to N keyframes. Each consecutive pair of keyframes becomes one segment: the node upscales both frames to your target width/height, encodes them with the VAE, and builds a concat_mask that keeps the first ~4 latent frames and the last frame frozen while the middle gets denoised. That's the inpainting-style trick that lets the sampler see "here's frame 1, here's frame 6 - make the frames in between." Text conditioning is encoded per segment, and if you pass clip_vision_outputs, the start and end CLIP vision states get merged so the reference image identity carries through.

The three outputs are the giveaway that this is a conditioning node, not a generator: positive and negative CONDITIONING plus a latent. The latent is literally a tensor of zeros - its shape (segments × latent frames × height × width) just tells the sampler how many frames to denoise. The real keyframe pixels ride along inside the conditioning. Don't hook up the latent, see black, and panic; that's expected.

The inputs that matter

Only a few of these are yours to think about:

• keyframes (IMAGE, optional) - a batch of at least 2 images. Fewer than 2 and the node raises ValueError: At least 2 keyframes are required. The sibling LoadImagesFromDirectory node in the same pack feeds this from a folder with name_asc sorting.
• positive_prompt - the keyframing secret sauce. Each line is [N] prompt, where N is the segment index (segment 0 runs between keyframes 0 and 1, and so on). Any segment without a matching line silently falls back to the [0] prompt, so keep the count right.
• width/height - defaults to a modest 496×496 (multiples of 16, up to 8192). Cheap to iterate on, then bump up.
• fps/seconds - default 16 fps, 1 second. The node actually renders (fps × seconds) + 1 frames rounded to a 4k + 1 shape, which is what Wan's temporal VAE wants.
• clip_vision_outputs (CLIP_VISION_OUTPUT, optional) - from a CLIP vision encode of your keyframes. Optional in the schema, but without it you lose the reference-image conditioning and Wan behaves more like an inpainter than an I2V model. Feed it if you care about identity.

Wiring it into a real generation

Load a Wan checkpoint (2.2 5B or 14B, GGUF if VRAM is tight), its VAE and CLIP, and run this node's three outputs straight into your sampler - positive and negative into the conditioning slots, latent into samples. Then VAEDecode and combine the video. This node replaces the "encode image, build mask, condition" block you'd otherwise assemble from native nodes.

Installing it

ComfyUI Manager, search WanKeyframing, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/apenguin24/ComfyUI-WanKeyframing.git
# restart ComfyUI

There's no requirements.txt and nothing exotic in pyproject.toml - the node only touches ComfyUI core, torch, and the model stack. The real download cost is the Wan models themselves (checkpoint, VAE, CLIP, CLIP vision), which this node doesn't bundle and can't generate without.

Where people get burned

VRAM is the big one. Every segment is a full clip, and all segments are stacked into one latent batch - so 4 keyframes at 2 seconds each is like generating four clips simultaneously. Keep keyframe count and resolution modest while testing. Second, the keyframe-count-to-prompt-index mismatch: too few prompt lines and segments silently reuse [0]. Third, mismatched keyframe sizes get bilinear-smeared to width/height, so feeding consistent-sized keyframes from the start gives you cleaner anchors. It's an obscure little pack with no real community track record, so expect to debug by reading the terminal output - which is chatty and prints which prompt each segment is using.