Video Enhance - Store Enhanced Anchors
Save the Z-Image-enhanced anchors in the order LTX will need them
- enhanced_anchors
- video_enhance_context
- enhanced_anchor_folder
- anchor_indices
- anchor_count
- video_enhance_context
Enhancing the anchors is only half the job - the enhanced frames are useless unless they're stored where LTX can find them, in the exact order it expects. VRGDG Video Enhance - Store Enhanced Anchors is the node that makes that happen. It takes the decoded Z-Image output, writes the enhanced full-frame anchors to disk in deterministic order, and hands the paths and indices to the rest of the pipeline so LTX's conditioning can pull the right guide for the right moment.
In the Video Enhance flow it's the direct counterpart to Load Anchors (Meta Batch). That node feeds anchors into Z-Image in managed batches; this one collects the results and files them away. Get the order wrong here and every downstream anchor reference is off by N frames - subtle, and only visible after you've burned a full LTX render on subtly wrong guidance.
The two inputs
- enhanced_anchors - connect the decoded
IMAGEresult from the Z-Image enhancement. The tooltip sets the contract: its count and order must match the anchors loaded through Meta Batch. If the batch count or sequence disagrees, the store will be wrong. - video_enhance_context - connect the context from Load Anchors (Meta Batch). This is how the node knows which job it's storing into - the same job the Collect LTX Inputs step will later read.
The outputs
- enhanced_anchor_folder - where the enhanced frames were written.
- anchor_indices - the list of frame indices, so downstream knows which source frames these correspond to.
- anchor_count - how many anchors there are; wire this into the Collect LTX Inputs step and the LTX anchor conditioning.
- video_enhance_context - the context, updated with the stored results and passed forward.
This node is flagged is_output_node, so it's an endpoint in the anchor-enhancement branch: it finalizes that branch, and the pipeline converges at Collect LTX Inputs.
Why deterministic order is the whole game
LTX uses these anchors as spaced guidance - the model is told "here's what frames 0, 16, 32… should look like," and it reconstructs everything between. If the store shuffled the order, LTX would be guided by the wrong images at the wrong times, and the result is a video that drifts in look and composition. The deterministic ordering is what makes the multi-stage pipeline composable at all: Prepare picks the frames, Load feeds them in order, Z-Image enhances them, Store files them back in the same order, Collect hands them to LTX. Every node enforces the same sequence, and this one is the check that keeps it honest.
Install
Standard pack install (Manager → search vrgamedev, restart, hard-refresh). It's part of the Video Enhance node set, so it needs the full context chain (Prepare → Load Anchors via VHS Meta Batch → Z-Image) wired in front of it. If you see a mismatch between what Z-Image produced and what the store reports, check the frames_per_batch setting on your VHS Meta Batch Manager against Prepare's anchor_count before touching anything else.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| enhanced_anchors | IMAGE | Connect the decoded Z-Image IMAGE result. Its count and order must match the anchors loaded through Meta Batch. | |
| video_enhance_context | VRGDG_VIDEO_ENHANCE_CONTEXT | Connect the context from Load Anchors (Meta Batch) so enhanced results are stored in the correct job. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| enhanced_anchor_folder | STRING | — |
| anchor_indices | STRING | — |
| anchor_count | INT | — |
| video_enhance_context | VRGDG_VIDEO_ENHANCE_CONTEXT | — |