IAMCCS_Ltx2HelperModules Reanchor Latent
Drag a drifting LTX-2 video back to its anchors
- vae
- latent
- first_anchor_image
- last_anchor_image
- parent_contract
- linx
- latent
- reanchor_payload
- contract
- linx
- report
Identity drift is the thing that ruins long LTX-2 pieces: by segment ten your protagonist has subtly stopped being your protagonist. The fix the whole helper-module chain is built around is periodic reanchoring - every few segments, lock the generation back onto reference frames hard enough that it can't wander. ReanchorLatent is the node that actually does it: on reanchor segments, it takes the fresh latent and injects your anchor images into it via the FirstLastLatentControl_Pro mechanism (VAE encode + noise_mask lock). On normal segments it passes the latent through untouched.
It's the execution arm of the refresh system. The decision of whether to reanchor comes from RefreshPolicy; this node just reads the decision and does it, or doesn't.
How it works
It reads refresh_payload and checks the segment_role. If the role is reanchor and at least one anchor strength is above zero, it runs the same logic as IAMCCS_LTX2_FirstLastLatentControl_Pro: VAE-encode your first_anchor_image / last_anchor_image, inject them into the head/tail of the latent, and set the noise_mask lock - using the effective strengths and slot caps (first_lock_slots, last_lock_slots, end_transition_slots) that RefreshPolicy computed. If the role is continuity (or the strengths are zero), it's a pure pass-through: your latent comes back byte-identical, which is exactly right, because a continuity segment shouldn't be re-locked.
The reanchor_payload output records what happened - reanchor_applied: true/false, the effective strengths, the slot caps - so the rest of the chain and your debugging both know whether this segment actually anchored.
The inputs and outputs that matter
vaeandlatent- the encode target and the latent to modify (wire the empty latent for this segment before sampling).refresh_payload- fromRefreshPolicy; this drives everything (role, strengths, slots).first_anchor_image/last_anchor_image(optional) - your reference frames. These are your "this is what the character looks like" images.
Outputs: latent (modified or passed through), reanchor_payload, contract, linx, and report.
Installing it
Ships in IAMCCS-nodes under IAMCCS/Ltx2 Helper Modules. Manager → "IAMCCS" → install, or:
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Restart ComfyUI. Needs your LTX VAE and stock ComfyUI - nothing extra.
Common issues
Two things. First, position in the graph: it must run on the latent before your sampler - if it's after, the lock never reaches the denoise and you'll conclude reanchoring is broken when it's just wired wrong. Second, the pass-through behavior surprises people: on continuity segments nothing appears to happen, which is correct. If you want to see it working, the report output states "reanchor_applied: False" explicitly rather than silently doing nothing. And if the reanchor visibly locks too hard (the segment snaps onto the anchor), the lever is upstream - reduce first_anchor_strength in RefreshPolicy, not here; this node takes its orders.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| vae | VAE | — | |
| latent | LATENT | — | |
| refresh_payload | STRING | {} | — |
| first_anchor_imageopt | IMAGE | — | |
| last_anchor_imageopt | IMAGE | — | |
| parent_contractopt | IAMCCS_SUPERNODE_CONTRACT | — | |
| linxopt | IAMCCS_SUPERNODE_LINX | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |
| reanchor_payload | STRING | — |
| contract | IAMCCS_SUPERNODE_CONTRACT | — |
| linx | IAMCCS_SUPERNODE_LINX | — |
| report | STRING | — |