PainterI2V
The one-knob fix for Wan 2.2 clips that move like molasses
- positive
- negative
- vae
- clip_vision_output
- start_image
- positive
- negative
- latent
If you've run Wan 2.2 with a 4-step speed LoRA like lightx2v, you know the feeling: great frame, gorgeous start, and then the video moves like it's underwater. The model walks in slow motion while the camera barely drifts, and no amount of "running fast" in the prompt fixes it. It's the single most-discussed quirk of the speed-LoRA setup, and PainterI2V exists to do exactly one thing about it: add a motion_amplitude knob to the stock Wan image-to-video pipeline so your clips actually move.
It comes from princepainter, a prolific Douyin-based ComfyUI node author behind the whole "Painter" family of Wan/LTX video packs. The README is honest about scope - this node is a drop-in replacement for ComfyUI's built-in WanImageToVideo, nothing more. No model downloads, no extra Python dependencies, no reconfiguring your sampler. If you're on the ComfyUI-native Wan 2.2 I2V workflow, you swap one node and get a dial the stock one doesn't have.
How it actually works
Wan 2.2 I2V doesn't just feed your image into the model. ComfyUI's native path builds an "image conditioning" latent: a sequence where the first frame is your real start image and the rest are gray placeholders, all VAE-encoded and concatenated to the video latent, plus a mask that only pins down frame 0 and reference_latents to hold the subject. The model infers all the motion from the gap between the real frame and those gray frames.
PainterI2V's trick is to widen that gap. It takes the difference between the real first frame's latent and the gray placeholder latents, separates out the per-channel brightness mean, scales the centered difference by motion_amplitude, then adds the mean back - so you amplify the motion signal without shifting overall luminance. A bigger gap tells the model "this sequence diverges a lot from frame 0," which pushes it to generate more movement and makes camera-movement prompts more obedient. The author reports a 15–50% motion boost depending on the value. It also zero-initializes the output latent itself, which is what keeps the temporal dependency chain intact for 4-step LoRAs - a deliberate detail, not an accident.
The inputs that matter
Most of the schema is identical to WanImageToVideo, so your existing workflow carries straight over:
positive/negative- your Wan conditioning, unchanged.vae- your Wan VAE; there's no special one required.width,height,length,batch_size- same defaults as stock (832×480, 81 frames).motion_amplitude- the whole point.1.0is bit-for-bit "no difference from the stock node."1.15is the default and the general-purpose sweet spot,1.25–1.35for running/jumping action, up to1.5for extreme motion. Move in0.05steps.start_imageandclip_vision_outputare both optional - the image path and the CLIP-vision path (used by the 5B/TI2V-style workflows) are both supported.
Outputs: positive, negative, and latent, which wire into your existing KSampler exactly like the stock node. Note the node itself doesn't sample anything.
Installing and using it
The pack has zero requirements and downloads nothing, so it's about as painless as ComfyUI gets:
- ComfyUI Manager: search "PainterI2V" and install.
- Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/princepainter/ComfyUI-PainterI2V.git
# restart ComfyUI
One real compatibility caveat: it imports comfy_api.latest, ComfyUI's newer extension API. On an old build the node simply won't load - update ComfyUI first if you hit an import error. And if your workflow is Kijai's WanVideoWrapper rather than the native path, grab the author's PainterI2VforKJ variant instead; the conditioning format differs, and the effect is the same.
Gotchas
The motion knob is a hammer, and the nail it drives is real. Crank motion_amplitude too hard and users report the classic over-scaling artifact - a jittery "ping-pong" where motion builds then reverses. Dial back in 0.05 steps until it settles. Pair it with explicit motion phrasing in the prompt ("running forward quickly", not "move"); vague motion language leaves the model no direction to amplify. And remember this fixes speed, not quality - the speed-LoRA tradeoff where lightx2v flattens detail at CFG 1.0 is a separate, well-documented beast.
The author has since released a superseding PainterI2Vadvanced pack and recommends it, so treat this repo as the polished v1 that got the community's attention - it still does the job, and it's still the drop-in people point to.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| positive | CONDITIONING | — | |
| negative | CONDITIONING | — | |
| vae | VAE | — | |
| width | INT | 83216–4096 | — |
| height | INT | 48016–4096 | — |
| length | INT | 811–4096 | — |
| batch_size | INT | 11–4096 | — |
| motion_amplitude | FLOAT | 1.151–2 | — |
| clip_vision_outputopt | CLIP_VISION_OUTPUT | — | |
| start_imageopt | IMAGE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| latent | LATENT | — |