LTX-2 Last Frame Bridge Load ???

In a segmented LTX-2 workflow, segments don't run in the same graph execution - they run in a queue, one after another, and the only thing that connects them is data written to disk. The "last frame bridge" is exactly that: the previous segment saves its final frame as a PNG, and the next segment loads it back as its starting anchor. This node is the load half of that handoff.

The reason you need a dedicated node for this instead of a plain Load Image: segments are identified by a render_id, and the bridge file is keyed to that render. Same render, same continuity chain; a new render starts fresh. The node also handles the first segment gracefully - where there's no previous segment yet - by falling back to a fallback_image you provide.

How it works

Given a bridge_name (default ltx2_detailer_bridge) and a segment_index, it looks for a PNG at:

ComfyUI/output/iamccs_ltx2_bridges/<bridge_name>_<render_id>.png

• segment_index 0 (or missing render_id): no bridge exists yet → return fallback_image, with exists = 0.
• segment_index > 0 and the bridge PNG exists → load it, return it with exists = 1.
• Segment > 0, no file → fall back to fallback_image if wired, otherwise raise a clear FileNotFoundError telling you which path was missing.

That exists INT output is the part people underuse: wire it into a switch or a report so the graph can behave differently on the very first segment versus continuations.

Inputs and outputs

• bridge_name - the bridge's name, must match the Save node.
• segment_index - which segment you're on (0 = first).
• render_id - the render chain identifier (optional; empty disables bridging on segment 0).
• fallback_image - optional IMAGE used when no bridge exists.

Outputs: image (loaded frame or fallback), exists (1 if a real bridge was loaded), report.

Install

ComfyUI Manager → "IAMCCS", or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart. No dependencies beyond ComfyUI core.

Gotchas

The classic failure: mismatch between the bridge_name/render_id on the Save node and the Load node. The bridge path is the concatenation of both, so a typo in either silently produces a "missing bridge → using fallback" and the next segment starts from the wrong anchor. That's not always visible as an error - exists will just be 0. The other footgun is forgetting fallback_image entirely: segment 0 then raises instead of degrading gracefully, because there's genuinely nothing to load. When continuity breaks between segments, check the bridge directory before you blame the model.