ComfyUI Node

PainterI2V

The one-knob fix for Wan 2.2 clips that move like molasses

By princepainter·Created 10 months ago·Updated 29 days ago· 634
PainterI2V
  • positive
  • negative
  • vae
  • clip_vision_output
  • start_image
  • positive
  • negative
  • latent
width832
height480
length81
batch_size1
motion_amplitude1.15

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.0 is bit-for-bit "no difference from the stock node." 1.15 is the default and the general-purpose sweet spot, 1.25–1.35 for running/jumping action, up to 1.5 for extreme motion. Move in 0.05 steps.
  • start_image and clip_vision_output are 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.

Categoryconditioning/video_models

Inputs (10)

NameTypeDefaultDescription
positiveCONDITIONING
negativeCONDITIONING
vaeVAE
widthINT83216–4096
heightINT48016–4096
lengthINT811–4096
batch_sizeINT11–4096
motion_amplitudeFLOAT1.151–2
clip_vision_outputoptCLIP_VISION_OUTPUT
start_imageoptIMAGE

Outputs (3)

NameTypeDescription
positiveCONDITIONING
negativeCONDITIONING
latentLATENT