Nodes/IAMCCS-nodes/AU+IMG2VID Reanchor Latent (legacy alias)
ComfyUI Node

AU+IMG2VID Reanchor Latent (legacy alias)

Lock the video back to a reference frame before the next chunk drifts

By IAMCCS·Created 11 months ago·Updated 7 days ago· 113
AU+IMG2VID Reanchor Latent (legacy alias)
  • vae
  • latent
  • first_anchor_image
  • last_anchor_image
  • parent_contract
  • linx
  • latent
  • reanchor_payload
  • contract
  • linx
  • report
refresh_payload{}

This is the node that actually does the re-anchoring the rest of the chain has been talking about. When your long video drifts - face changes, color shifts, the scene slowly forgets itself - the fix is to decode a reference frame back into latent space and blend it into the current latent, so the next chunk starts from a known-good state. IAMCCS_AUIMG2VID_ReanchorLatent (legacy alias for Ltx2HelperModules_ReanchorLatent) is that mechanism.

It's one of the few nodes in this chain that touches the heavy stuff directly: it takes a vae, a latent, and a refresh_payload (the JSON the RefreshPolicy node produced, which carries the anchor strengths and overlap mode). Optionally you feed it first_anchor_image and last_anchor_image - the clean reference frames to re-anchor on. If you don't supply them, it re-anchors to the latent's own content; supplying explicit references is how you lock identity to a specific face or scene element.

Under the hood it decodes the anchor image(s) through the VAE, blends them into the latent at the region the refresh_payload specifies (using the strengths and overlap mode the policy decided), and returns a new latent that's ready for the next sampling pass. It also returns a reanchor_payload JSON recording what it did, which is handy for debugging "why is this segment suddenly frozen?"

What you actually set, as a user: the vae and latent (wire from your existing VAE and sampler chain), the refresh_payload from the RefreshPolicy node, and the two anchor images if you have them. The contract/linx inputs are the pack's supernode connectors - wire them if you're in a full IAMCCS workflow, ignore them otherwise.

The important mental model: re-anchoring is a reset, and resets cost motion. If you re-anchor every segment with a strong first_anchor_strength, you'll get rock-solid identity and noticeably stiffer video. The RefreshPolicy node tunes that strength; this node is just the obedient executor. They're designed to work as a pair, and grabbing this node without the policy upstream means feeding it a refresh_payload of {} - which still works (defaults apply), just without the per-segment intelligence.

Installing: part of IAMCCS/IAMCCS-nodes. ComfyUI Manager → search "IAMCCS", or cd ComfyUI/custom_nodes && git clone https://github.com/IAMCCS/IAMCCS-nodes.git, restart. No models to download; it uses the VAE you already have loaded. It does mean a VAE decode per re-anchor, so on low-end cards those re-anchor segments are measurably slower - that's the price of the drift fix, and why the policy node exists to skip re-anchoring on segments that don't need it.

Where people get burned: feeding it a first_anchor_image that's a different resolution or aspect ratio than the latent. The blend assumes compatible shapes, and mismatched dimensions produce visibly broken output rather than a clean error in some paths. Keep your reference frames the same size as the generation and this node becomes boringly reliable.

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