WanHuMoImageToVideo

Wan HuMo is the Wan-family model for "I have a subject and I want it doing something specific" - it takes a reference image to lock the subject's identity and an optional audio track to drive the motion, then generates the video. WanHuMoImageToVideo is the conditioning node for it, and it's flagged experimental in the source, which tells you a lot about where it sits: it works, but it's the kind of node that gets revised as the model matures.

The mechanism mixes two conditioning tricks. The ref_image input is VAE-encoded and appended to both positive and negative conditioning as a reference_latent - the model gets "this is the subject" as a first-class signal, so it doesn't have to guess identity from a first frame alone. (No ref_image? It injects a zero latent instead, which reads as "no strong subject constraint.") Then, if you feed an audio_encoder_output - the same audio-feature type that WanDancerEncodeAudio produces - the node interpolates and windows the audio embeddings to match the clip length, and injects the result as audio_embed on the positive side (negative gets zeros, so the model knows what not to follow). So the two optional inputs are doing very different jobs: one defines who, the other defines how they move. The base node also allocates the empty 16-channel latent at 8x compression, length defaulting to 97 frames.

Inputs: positive/negative, vae, width/height/length/batch_size (defaults 832×480, 97 frames), plus optional ref_image and audio_encoder_output. Outputs: positive, negative, latent, straight into the KSampler.

It's core (comfy_extras/nodes_wan.py), ships with ComfyUI, no install - you just need the Wan HuMo checkpoint and VAE.

The honest read on this one: "HuMo" (human motion) models are the family's attempt at reference-driven motion control, and this node is a slightly raw slice of it. The experimental flag is the main thing to keep in mind - expect template workflows to be the safe path and expect to iterate. Two practical notes: the reference image wants to be a clean single subject, because that's what gets locked as the identity; and if you're feeding audio, make sure it's the output of a compatible audio-encode node - the audio_encoder_output type is shared across the Wan audio-family, but lengths get windowed to the clip, so mismatched durations just get truncated rather than erroring. That silent truncation is the thing that'll have you scratching your head when the motion stops syncing partway through.