WanCameraImageToVideo

The single most annoying thing about vanilla image-to-video is that the "camera" does whatever it wants. Wan's camera-control model is the fix - you decide whether the shot dollies in, pans, or orbits - and this node is how a camera-controlled generation gets set up. WanCameraImageToVideo is the I2V conditioning node for the Wan 2.2 camera family: it anchors your start image, attaches the camera trajectory you planned, and hands the sampler a latent ready to go.

Mechanically it's the standard Wan I2V recipe with a camera channel bolted on. It builds a 16-channel latent at 8x spatial compression (Wan 2.1/2.2-style), and with a start_image it VAE-encodes the frames into a concat_latent_image plus a concat_mask (0 over the anchored frames). Then two optional additions layer on: camera_conditions - a WAN_CAMERA_EMBEDDING produced by the sibling WanCameraEmbedding node from your camera path - gets stamped into both positive and negative conditioning, and clip_vision_output (from a CLIPVisionEncode of the start frame) gets attached the same way. Outputs are positive, negative, and latent, all ready for the KSampler.

Inputs that matter: positive/negative (from the Wan text-encode node), vae, width/height/length (defaults 832×480, 81 frames - the model's training sweet spot), start_image, and the two optional adds: camera_conditions and clip_vision_output. Feed it the camera path you designed and a CLIP vision of your frame and you get a dolly; leave both unplugged and you've basically built a plain Wan I2V conditioning node.

It's core (comfy_extras/nodes_wan.py), ships with ComfyUI, no install - the camera family is part of the native Wan support. You'll need the Wan 2.2 camera-aware checkpoint and its VAE.

The real-world advice from the motion crowd: camera control is a promise, not a guarantee - the model follows the trajectory you give it but a wild path or a busy subject will still fight it. Keep trajectories simple (a push-in, a pan, a modest orbit) and let the start image carry the subject fidelity. And the familiar trap applies here too: the camera_conditions must come from the camera-embedding node for the same checkpoint family, and clip_vision_output from a matching CLIP vision - mismatched pieces and the model just ignores the camera entirely, which reads as "why is my dolly a static shot." Check that wiring before you blame the trajectory.