Atlas Load Camera Path (LTX) 🎥

If you shot a camera move in Atlas Director - actually operated the camera against the scene, the way you would in a real DCC - the take it exports needs to get into ComfyUI as something the LTX warp can render. Atlas Load Camera Path 🎥 is the bridge. Point it at the camera_ltx.json Director wrote beside the take, and out comes the keyframes string that the CrossView Warp node's keyframes input wants.

One input, one job, and a report you should not ignore. The node reads all the formats Director can write and says which one it got - and the format changes what you can trust.

The three cases the report flags

• Single path - a normal take. Wire keyframes into the CrossView Warp node. Doing so makes its orbit sphere read-only, which is correct: this is a recording of a camera someone operated, and a marker dragged in the graph would show a move that isn't the one being rendered.
• Chain - a take too long for one LTX generation, exported in segments. Pick the segment with the segment input (default 1) and generate it, then feed its final generated frame back as the source clip for the next. Segment N's source clip is segment N−1's final frame, not the plate - expect its error to ride on the one before it.
• Compressed - previz. The timing and aim are the take's, but the parallax has been scaled down, so it is not evidence about depth. The report tells you rather than letting a scaled-down move pass for the shot.
• Pose - a per-frame pose path, roll and a breathing lens included. This one wires into CrossView Warp's camera_path input instead - it outranks camera_info and the keyframes, so none of the orbit widgets apply and none needs setting.

Outputs are keyframes, report, and segment_count. The report carries the three CrossView Warp settings the knots depend on (use_keyframes, pivot_override, keep_source_aim) - and getting those wrong doesn't raise an error, it just renders a different move. That's exactly the failure mode that looks like success, so wiring report to a PreviewText at least once per graph is the author's own advice and it's good advice.

Installing

Part of atlas-camera, the standard way:

cd <ComfyUI>/custom_nodes
git clone https://github.com/mikejamesvfx/atlas-camera.git

Restart ComfyUI. No extra pip deps for this node - it reads JSON. The real requirements sit around it: Atlas Director on the export side producing the take, and the CrossView Warp node pack installed alongside in custom_nodes (the two packs live side by side and wire into each other for free).

Common issues

The node refuses a file it doesn't recognise rather than guessing - an unknown format id raises, naming what it can read. That's deliberate: a compressed path read as an ordinary one would render a scaled-down move with nothing saying so. If you see that error, check the file is actually what Director wrote for this take.

Two gotchas that bite silently: the clip you feed the warp must be at least as long as the path - the warp errors on a keyframe past the end, a check this node can't make for you. And a mistyped or relative path is the other classic; it wants the full path to the camera_ltx.json in the take's directory. When in doubt, read the report - it tells you which input the file belongs in, and the file's own format stamps are the ground truth.