ContextRef Keyframe ππ π
Schedule how hard the reference locks in
- prev_kf
- mult_multival
- mode_replace
- tune_replace
- CONTEXTREF_KF
ContextRef's root node gives you one flat strength for the whole render (via strength_multival) or a keyframe schedule (via contextref_kf). This node is a single point in that schedule - chain a few of them together and you get a hand-built curve of exactly how strongly ContextRef locks each stretch of the denoising process to its reference.
What it does
mult (0β1, default 1) is the strength at this keyframe. start_percent (default 0) is where in the sampling process this keyframe kicks in. guarantee_steps (default 1) is a floor: even if the next keyframe in the chain is scheduled to take over almost immediately after, this one is guaranteed to actually run for at least that many steps first - it exists so a very short window between two start_percents doesn't get skipped entirely. mult_multival lets a mask or a list of floats drive the strength instead of one static number, same as everywhere else this pack uses Multival. mode_replace and tune_replace let this specific keyframe override the parent ContextRef node's mode or tune just for its stretch of the schedule - leave them unplugged and, controlled by inherit_missing (default true), the keyframe just inherits whatever mode and tune the parent node is already using.
Chain multiple of these via prev_kf to build a full manual schedule, then feed the last one into ContextRef's contextref_kf input. Output type is CONTEXTREF_KF.
Why hand-build instead of using the List/Interpolation nodes
This node is for when you want a specific, deliberate shape to the schedule - strong at the very start to lock structure, then a sharp drop at a particular percent, held for a guaranteed stretch. The From List and Interpolation siblings are for generating many evenly-spaced keyframes in one shot; this one is for placing a handful by hand where the exact position and value matter.
A concrete example
Say you want ContextRef locked hard for the first third of sampling, then relaxed for the rest: one keyframe at start_percent 0 with mult 1 and guarantee_steps set to cover the first few steps, chained via prev_kf into a second keyframe at start_percent 0.33 with mult 0.3. The first keyframe's guarantee_steps makes sure it actually holds for those opening steps rather than getting immediately overridden if your percents end up close together. That's the shape most hand-built schedules take - a strong opening value, then one or two step-downs - rather than a smooth curve; for a smooth curve, reach for Keyframes Interp. instead.
Installing it
Same as the rest of the pack: ComfyUI Manager, search AnimateDiff Evolved (Kosinkadink), install, restart. Or git clone https://github.com/Kosinkadink/ComfyUI-AnimateDiff-Evolved into custom_nodes and restart manually.
Where to be careful
This whole family of chained keyframe nodes across Kosinkadink's packs is picky about ordering: start_percent values need to actually ascend as you walk the chain, or the schedule won't do what you expect. It's the same design as the sibling ComfyUI-Advanced-ControlNet pack's keyframe nodes, which throw an explicit error when values are given out of order rather than silently misbehaving - a good sign this family takes ordering seriously, and a good reason to double-check your chain's start_percents are strictly increasing before you spend GPU time on a long render.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| prev_kfopt | CONTEXTREF_KEYFRAME | β | |
| mult_multivalopt | MULTIVAL | β | |
| mode_replaceopt | CONTEXTREF_MODE | β | |
| tune_replaceopt | CONTEXTREF_TUNE | β | |
| multopt | FLOAT | 1.0000β1 | β |
| start_percentopt | FLOAT | 0.0000β1 | β |
| guarantee_stepsopt | INT | 10β9007199254740991 | β |
| inherit_missingopt | BOOLEAN | true | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CONTEXTREF_KF | CONTEXTREF_KEYFRAME | β |