Nodes/IAMCCS-nodes/IAMCCS_Ltx2HelperModules Reanchor Latent
ComfyUI Node

IAMCCS_Ltx2HelperModules Reanchor Latent

Drag a drifting LTX-2 video back to its anchors

By IAMCCS·Created 11 months ago·Updated 8 days ago· 113
IAMCCS_Ltx2HelperModules Reanchor Latent
  • vae
  • latent
  • first_anchor_image
  • last_anchor_image
  • parent_contract
  • linx
  • latent
  • reanchor_payload
  • contract
  • linx
  • report
refresh_payload{}

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

  • vae and latent - the encode target and the latent to modify (wire the empty latent for this segment before sampling).
  • refresh_payload - from RefreshPolicy; 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.

CategoryIAMCCS/Ltx2 Helper Modules

Inputs (7)

NameTypeDefaultDescription
vaeVAE
latentLATENT
refresh_payloadSTRING{}
first_anchor_imageoptIMAGE
last_anchor_imageoptIMAGE
parent_contractoptIAMCCS_SUPERNODE_CONTRACT
linxoptIAMCCS_SUPERNODE_LINX

Outputs (5)

NameTypeDescription
latentLATENT
reanchor_payloadSTRING
contractIAMCCS_SUPERNODE_CONTRACT
linxIAMCCS_SUPERNODE_LINX
reportSTRING