IPAdapter Weights

This one doesn't touch your model or your image directly - it's a scheduler. Its job is to spit out a list of per-frame weights so IPAdapter's influence can rise and fall over an animation. Think of it as the thing that lets you crossfade: image A dominates the first stretch of a video, image B takes over by the end, and the transition in between is smooth instead of a hard cut. If you've seen those "morph from one reference to another over 60 frames" AnimateDiff clips, this is a big part of how they're built.

It exists because animation with IPAdapter isn't one generation, it's a batch of frames, and you usually want the conditioning to change across that batch. Typing 60 weight values by hand is misery. This node generates them from a few simple settings instead.

How it works

You tell it how many frames you have and what shape the transition should take, and it computes a weight for every frame. It also, conveniently, splits your input image batch into two groups - the "from" set and the "to" set - so it can hand you the two reference streams the crossfade needs. That's why the output list is longer than you might expect.

Inputs and outputs

The inputs you'll actually set:

• weights - a multiline field of base weight values (default 1.0, 0.0). This defines the endpoints and any keyframes; the timing curve interpolates between them.
• timing - the interpolation shape: linear, ease_in, ease_out, ease_in_out, random, or custom. Ease curves give you that soft, natural-feeling fade; linear is a constant slide.
• frames - how many frames the schedule spans.
• start_frame / end_frame - where in the batch the transition happens, if you don't want it to run the whole length.
• add_starting_frames / add_ending_frames - pad hold-frames on either end (stay on image A for a beat before the fade begins).
• method - full batch, shift batches, or alternate batches, which controls how the two image groups get interleaved.

The outputs are the payoff. weights and weights_invert are the per-frame float lists (invert is the mirror, for the second image so the two crossfade). total_frames is the count. image_1 and image_2 are your split reference streams. And weights_strategy is a bundled WEIGHTS_STRATEGY object - hand that to the Prompt Schedule From Weights Strategy node or the Weights From Strategy node to reuse the exact same timing elsewhere without re-entering it.

In practice the weights output feeds the weight input of an IPAdapter Batch apply node, and image_1 / image_2 feed the references. That's the crossfade wired up.

Installing the pack

ComfyUI Manager: search ComfyUI IPAdapter plus, install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/cubiq/ComfyUI_IPAdapter_plus

then restart, and keep ComfyUI updated. This node itself needs no model files - it's pure math - but the apply nodes it feeds do (CLIP vision encoders in ComfyUI/models/clip_vision, adapters in ComfyUI/models/ipadapter).

Where people get burned

The classic mistake is a frame-count mismatch: the number of weights this node produces has to line up with the number of latents your AnimateDiff setup is actually generating. If your fade looks like it stops halfway or the batch throws a length error, that's almost always it - check that frames (and any padding) matches your sampler's batch size. The other one is expecting this node to do something visible on its own; it doesn't. It's plumbing that produces numbers. The magic happens once those numbers reach an IPAdapter apply node driving a real animation batch.