Can LTX 2.5 enforce camera motion reliably in I2V, or only guide it?
For LTX 2.5 image-to-video, can any official workflow guarantee that a requested camera path is followed on the first generation across varied source images? I am especially interested in a truly static camera, pan right, and tilt down.
The documentation lists the API camera_motion parameter and ComfyUI Motion Transfer, sparse-track Motion Control, and Layout-to-Render workflows. Which of these provides the strongest camera-path control, and which are only soft guidance that may drift? Is there an official benchmark, known limitation, or reproducible setup for camera-motion adherence? I am asking about a guaranteed correct camera move on every first attempt, not simply whether a move is sometimes possible.
Not an official answer, but some measured data from a production run that may help.
We shoot a wordless film series on LTX-2.5 (distilled bf16, ComfyUI two-stage I2V, 720p, 121 frames @ 24 fps). Because "it looks static" by eye turned out to be unreliable, we measure camera motion with a small script: scale and shift of the background between the first and the last frame.
What words do (I2V, our prompts):
Static camera. held in roughly half of the clips. In the first batch 3 of 6 "static" clips moved (about 6%, 10% and 20–30% push/shift). On the same start frame and prompt, seed 7 stayed static while seed 11 moved whatever we wrote.
"Very slow push-in" (two different phrasings) overshot on all 5 pairs we tried: about 1.3–2× zoom instead of a gentle move. The phrasing made no difference.
In our one pull-out test, words alone did not produce a pull-out.
In two-person shots with a sharp gesture the model changed the camera angle by itself (6 of 6).
What works: the first + last frame workflow (the official video_ltx2_5_flf2v template). With a drawn last frame, all 6 test clips arrived at that frame: the push-in was exactly as drawn, and the camera was static when the two frames had the same framing. The trade-off we saw: the camera was right every time, but in 2 of 4 shots the performance looked unnatural, so we still judge every clip by eye.
So our practical rule now: any push-in, pull-out or tracking move is shot first+last frame, with the end frame made from the start frame (zoom/crop done by code); clips that must be static get a motion check after generation and a second seed if they drift.
To the LTX team: a short note in the model card on what camera wording I2V is trained to follow (if any), and whether camera_motion from the API has an equivalent in ComfyUI, would save people a lot of seeds.