Kandinsky5ImageToVideo
Kandinsky 5's image-to-video node, and the one output everyone misses
- positive
- negative
- vae
- start_image
- positive
- negative
- latent
- cond_latent
Kandinsky doesn't get the love it used to - the family name carries weight from the 2.x era but the 5.x line is a quieter release, and this node is where that line's image-to-video support lives. It's the setup step in a Kandinsky 5 I2V workflow: it takes your positive and negative conditioning, optionally a start_image, and builds both the empty video latent and the conditioning that tells the model to keep your image.
Mechanically it works a lot like other first-frame-anchoring nodes, with one twist. An empty 16-channel latent is built at [batch, 16, frames, h/8, w/8] - Kandinsky's VAE compresses 8x spatially, 4x temporally, so the default length: 121 at 768×512 means a 121-frame clip. If you feed a start_image, it gets upscaled to width × height, VAE-encoded, and attached to the conditioning as time_dim_replace plus a concat_mask that's 0 for the first frames. time_dim_replace is the interesting bit: instead of concatenating extra channels like Hunyuan or Wan do, Kandinsky 5 literally swaps the model's noisy start with your clean encoded frames. That's why the node has a second latent output most people wire past - cond_latent, the clean VAE-encoded start image, exists so you can replace the noisy start of the sampler's output latents on the way out. Follow the official Kandinsky 5 workflow and you'll see it fed back in around the decode step.
Inputs to care about: positive/negative come from CLIPTextEncodeKandinsky5 - that's the sibling text-encode node and it needs two prompt fields, clip_l and qwen25_7b, because Kandinsky 5 conditions on both a CLIP-style encoder and Qwen2.5-7B. Using a generic SD encode here quietly gives you mush. start_image, width, height, length, batch_size behave as you'd expect.
Outputs: positive, negative, latent (the empty noise latent for the sampler), and cond_latent (the clean start frames, only populated when start_image is set). The first three wire into the KSampler normally; cond_latent is the one to route into the workflow's latent-replacement step if the reference implementation does one.
It ships with ComfyUI core (comfy_extras/nodes_kandinsky5.py), so no install. You need the Kandinsky 5 checkpoint plus the Qwen2.5-7B text encoder in the right folders - the node itself loads nothing; the loaders handle that.
The classic failure mode: encoding your prompt with the wrong text-encode node and getting generic output, or forgetting the two-text-encoder requirement entirely. The secondary one is treating cond_latent as decorative. If your template skips it and the video drifts off your first frame by mid-clip, that's the knob - it's the whole reason the node hands you the clean frames separately instead of burying them in the latent.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| vae | VAE | — | |
| width | INT | 76816–16384 | — |
| height | INT | 51216–16384 | — |
| length | INT | 1211–16384 | — |
| batch_size | INT | 11–4096 | — |
| start_imageopt | IMAGE | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| latent | LATENT | Empty video latent |
| cond_latent | LATENT | Clean encoded start images, used to replace the noisy start of the model output latents |