IPAdapter Weights V2

IP-Adapter with a single static weight is fine for a still image. The moment you're animating - AnimateDiff, a latent batch, an image-to-image sequence - you want the reference to fade in, fade out, or morph between two of them frame by frame. IPAdapterWeightsV2 builds that weight curve, stretches it to match your image batch, and hands the result to an apply node. It's the "timing" half of animated IP-Adapter, and it's the node that turns a flat sequence of frames into something that actually crossfades.

How it works: you give it a weights string (a comma- or newline-separated list of floats), and the node either uses those directly (timing: custom) or generates a curve - linear, ease_in_out, ease_in, ease_out, or random - between the first and last values of that list across frames. Then the method decides how the curve maps onto your images. full batch applies the same weights to the whole batch; shift batches and alternate batches are for the crossfade case, where you're interpolating between one image and the next.

The outputs tell you what it's doing:

• weights - the per-frame FLOAT list, wired into the weight input of an apply node (feed image_1 as the reference alongside it)
• weights_invert - the same list reversed, for the outgoing half of a fade
• total_frames - how many frames the curve ended up spanning, useful as the length on an AnimateDiff batch
• image_1 / image_2 - your input images repeated to match the weights, for crossfade
• weights_strategy - a small pipe that packages up the whole configuration, which the Prompt Schedule node reads

The three inputs a beginner actually sets: weights (the ramp endpoints), timing (how the curve bends between them), and frames (how long it runs). start_frame, end_frame, add_starting_frames, and add_ending_frames are refinements - hold the starting weight for N frames before the ramp, hold the end weight after it.

A typical animated crossfade

WeightsV2 (weights "1.0, 0.0", timing "linear", method "shift batches")
    ├── weights → IPAdapterAdvancedV2.weight
    ├── image_1 → IPAdapterAdvancedV2.image
    └── total_frames → your batch size

Install

Same pack as the rest of these articles: chflame163/ComfyUI_IPAdapter_plus_V2, a GPL-3.0 fork of cubiq's ComfyUI_IPAdapter_plus with V2 node names so both packs can be installed at once. ComfyUI Manager → search ComfyUI_IPAdapter_plus_V2, or:

cd ComfyUI/custom_nodes
git clone https://github.com/chflame163/ComfyUI_IPAdapter_plus_V2

Restart. No pip dependencies - the pack runs on ComfyUI's own torch/torchvision/PIL stack.

Where people get burned

The weights string parsing is picky about commas and newlines but forgiving of stray whitespace - keep it to floats separated by commas. If you pick a timing other than custom and leave frames at 0, it clamps to 2 frames, which is almost never what you wanted. And the most common confusion: this node produces per-frame weights, but the apply node only honors a weight list if the image you feed it is also a list/batch - that's why the node outputs image_1 and image_2 alongside the weights. If you wire only weights into a single still image, the node quietly treats it as a scalar and you won't see a ramp at all. For stills, don't bother with this node - that's what plain weight on IPAdapterV2 is for.