TL;DR: An image to video prompt has a different job than a text-to-video one. The still already fixes subject, composition, palette and lighting, so the prompt should describe motion and time only. Re-describing what the image already shows is the single most common cause of drift.
One honesty note first. Prompt Architects writes the prompt. It does not make your image and it does not render your video. This page is about the handoff between the two, and about the sentence you type after you already have a still you like.
Here is the failure everybody hits once. You generate an image you like. You paste it into a video model, and because a year of text-to-video trained you to, you paste your image prompt in alongside it. The clip comes back and the subject has shifted, the colour grade has drifted, the lens looks different. Nothing you asked for went wrong, exactly; the model had two descriptions of one scene and reconciled them, and the words won more often than the pixels did.
The image was the specification. The prompt was supposed to be the direction.
What Does an Image to Video Prompt Actually Have to Say?
Motion and time, and almost nothing else. The still has already answered every spatial question, so the prompt's only remaining job is the part a single frame physically cannot carry: what moves, in what order, how fast, and where the camera goes.
This is not our invention. It is visible in how the vendors define the field. Lightricks documents the LTX prompt as a "Text description of how the image should be animated, can relate to the details in the image" (docs.ltx.io, accessed 27 Aug 2026). Runway describes the promptText on its Gemini Omni Flash branch as "An optional text prompt describing how the video should evolve from the first frame", and on both the Grok Imagine 1.5 and Happyhorse branches as "An optional text prompt describing motion or changes in the output video" (docs.dev.runwayml.com/api.md, accessed 27 Aug 2026). Three separate branches, three phrasings, one idea: evolve, animate, change.
ByteDance goes furthest. Its Seedance 2.5 prompt guide, writing about video references, states plainly that "There is no need to describe details such as raising a hand, turning around, or having the camera slowly orbit" when the reference already contains them (docs.byteplus.com, accessed 27 Aug 2026). The same logic transfers directly to a still.
Which Models Accept a First Frame, a Last Frame, or Both?
Most accept both, but the exceptions matter and the costs differ. Every row below was read on the vendor's own documentation on 27 August 2026.
| Model / surface | First frame | Last frame | Extra image inputs | Duration range |
|---|---|---|---|---|
| Kling 3.0 / 3.0 Omni | first_frame, required | last_frame, optional | Up to 3 Elements | 3–15 s, default 5 |
| Veo 3.1 (Gemini API) | image | lastFrame, needs image | referenceImages, up to 3 | 4, 6 or 8 s |
| Seedance 2.5 | role: first_frame | role: last_frame | 30 images + 10 video + 10 audio, in a separate mode | 4–30 s |
| Seedance 2.0 series | role: first_frame | role: last_frame | 9 images + 3 video + 3 audio, separate mode | 4–15 s |
| LTX 2.5 (both variants) | image_uri | last_frame_uri | None documented | 6–20 s, variant-dependent |
| LTX 2.3 Pro | image_uri | last_frame_uri | None documented | 6, 8 or 10 s |
| Wan 2.7 | first_frame | last_frame | Video clip via first_clip | 2–15 s, default 5 |
| Luma Ray 3.2 | video.start_frame | video.end_frame | keyframes, 1–64 | 5 s or 10 s |
| Vidu Q3 / Q2 | images[0] | images[1], separate endpoint | Multi-frame, 2–9 frames, Q2 only | 1–16 s by generation |
| Runway Gen-4.5 | position: first | Not supported | None | 2–10 s |
| Runway Gen-4 Turbo | position: first | Not supported | None | 2–10 s |
| Gemini Omni Flash (via Runway) | position: first | Not supported | None | 3–10 s |
| Grok Imagine 1.5 (via Runway) | position: first | Not supported | None | 1–15 s |
Three details are worth pulling out of that table.
Kling makes the first frame mandatory and the last frame optional. Its 3.0 Omni image-to-video spec sets contents[].type to an enum of prompt, first_frame, last_frame and element, and states outright: "Supports first-frame-to-video and first-and-last-frame-to-video generation; last-frame-only video generation is not supported." The input image has to be JPG, JPEG or PNG, under 50 MB, and Kling constrains its shape: "The width and height of the image must be no less than 300px, and the aspect ratio of the image should fall within the range of 1:2.5 to 2.5:1" (kling.ai/document-api, accessed 27 Aug 2026). Kling's API docs render as an empty shell in a browser, but every page has a readable .md twin at the same path, which is how the fields above were verified. Frame rate appears nowhere in that spec: zero occurrences of fps, "frame rate" or "frames per second". Treat any "Kling does 60fps" claim you read elsewhere as unsourced.
Runway's own models are first-frame only. Its single /v1/image_to_video endpoint is "one of 12 shapes, selected by model", and on the gen4.5 and gen4_turbo branches position is "one of first". The Veo 3.1 branches resold through the same endpoint do take a last frame, with the caveat that "This model does not support generating with only a last frame." Gemini Omni Flash gets an explicit note: "Gemini Omni Flash only supports a first frame."
Seedance treats frames and references as separate, incompatible jobs. On the ModelArk create-task API, image-to-video from a first frame takes exactly 1 image and first-and-last-frame takes exactly 2, while omni reference-to-video takes "reference images (0–30), reference videos (0–10), reference audio clips (0–10)" on 2.5, and "reference images (0–9), reference videos (0–3), reference audio clips (0–3)" on the 2.0 series (docs.byteplus.com, accessed 27 Aug 2026). That is 50 assets against 15. The two modes are documented as mutually exclusive scenarios that cannot be mixed, so you choose one.
What Does Pinning a Frame Actually Cost You?
Usually duration, sometimes resolution, and on one model your ability to let the system choose the length. This is the part every tool roundup omits, and the part that generates the error message. The wider pattern is in our AI video duration reference.
Veo 3.1 is the strictest. Its Gemini API parameter table gives durationSeconds as "4", "6", "8" and then requires the value 8 "when using extension, reference images or with 1080p and 4k resolutions". The model-versions table on the same page repeats it from the other direction: "8 seconds only if 1080p or 4k or using reference images" (ai.google.dev, accessed 27 Aug 2026). So the moment you hand Veo the three reference images it allows, your 4-second option disappears. Note also that the same page's own intro calls Veo 3.1 "a model for generating 8-second videos", which contradicts the 4/6/8 table sitting below it. Google has not reconciled the two; we are reporting both rather than picking.
Luma is the cleanest illustration of the trade, and also the one surface here where an end frame can stand alone: "Either, both, or neither of start_frame / end_frame is valid." But on Ray 3.2, video.duration accepts 5s or 10s, and the docs mark 10s as not supported with hdr: true, start_frame, or end_frame. Pin an anchor and you are capped at five seconds. The escape hatch is the newer multi-keyframe surface: video.keyframes takes 1 to 64 guide images with a parallel video.keyframe_indexes array of output-frame positions on a duration-times-24fps grid, and Luma notes that this path "lifts those anchors’ restrictions", restoring 10 seconds and HDR. The two surfaces are mutually exclusive; sending both returns a 400.
Vidu charges the same toll more quietly. On /ent/v2/img2video, the Q2 generation accepts durations from 1 to 10 seconds. On /ent/v2/start-end2video, where you supply "Two images: first is start frame, second is end frame", the same Q2 models accept 1 to 8. Two seconds vanish for adding an end frame, and Vidu also requires the pair to be similar in shape (platform.vidu.com, accessed 27 Aug 2026). Vidu's docs are server-rendered and readable to plain curl, which is rarer than it should be among video vendors.
LTX trades something different. On LTX 2.5 you can send "duration": null and let the model pick the length from your prompt, but Lightricks is explicit that "Automatic duration cannot be combined with last_frame_uri on image-to-video. A last frame fixes where the clip has to end, which requires a known length." Separately, the repair tools live on the older generation: "Audio-to-video, retake, extend, and reframe require ltx-2-3-pro", and every ltx-2-3-pro row in the support matrix caps at 10 seconds. A long take and the ability to fix it are two different products.
Why Won't Seedance Take a Photo of a Real Person?
Because it is documented not to, and this kills the workflow most people try first. BytePlus states that Dreamina Seedance 2.5 and the Seedance 2.0 series "do not support directly uploading reference images or videos that contain real human faces". So the obvious move, feeding it a photograph of your founder or your model and asking for a reference-driven clip, is refused by design.
ModelArk documents three supported routes instead: original face-containing outputs from certain models generated in your own account within the past 30 days, preset digital characters, and authorised real-person assets. Plan around that at the start of a campaign, not after the first rejection.
Worth flagging alongside it — ByteDance's API allows up to 30 reference images, while its own prompt guide recommends "1-8 subjects" for stability and warns that 9 to 12 may need multiple attempts. The permitted maximum and the recommended maximum are different numbers on different pages.
How Do You Describe Motion the Still Can Actually Support?
By naming one primary motion, giving it a direction and a rough speed, and letting everything else stay implied. The still already contains a physics proposal: hair that is settled or lifting, water that is glassy or broken, fabric that is hanging or mid-swing. Motion that agrees with that proposal renders cleanly. Motion that argues with it produces the warping people blame on the model — an older problem than image-to-video, covered in our piece on why AI video morphs and warps.
Three rules survive across every model we tested against.
One primary motion per clip. A five-second generation has room for one thing to happen and one thing to react. Give it two equals and you get a tug-of-war.
Anchor the motion to something visible. "The steam rises from the cup" is answerable from the frame. "She thinks about leaving" is not.
Give the motion a stated duration where the model supports it. Seedance 2.5 reads integer-second timestamps; Kling 3.0 reads a shot n, m, words syntax where the per-shot seconds must sum to the total. Where neither exists, phrases like "over the full clip" still bias the pacing.
Which Camera Moves Work From a Fixed Frame?
The ones that reveal what is plausibly just outside the frame, and the ones that change focus rather than position. The ones that fight a still are the ones that demand geometry the image never contained.
LTX is useful here because it turned the working set into an enum. Its camera_motion field accepts exactly dolly_in, dolly_out, dolly_left, dolly_right, jib_up, jib_down, static and focus_shift. That is a shortlist of moves a single frame can support, and it is a reasonable vocabulary to borrow even on models that take camera direction as prose. For the wider terminology, we keep a full camera movement vocabulary for AI video.
What that list excludes is instructive. There is no orbit, no arc, no crane-around. A move that travels around a subject has to invent the far side of it, and a still gives the model nothing to invent from. Push in, pull out, drift sideways, tilt, or rack focus, and you are asking for interpolation. Orbit, and you are asking for authorship.
What Happens at the Edges When the Camera Moves?
The model invents them, with less information than it had for the centre of your frame. This is the most reliable source of ugly output in image-to-video, and it is predictable: a dolly out or a jib up widens the visible area, and every new pixel is a guess.
Two consequences. First, if the subject or a hard graphic element already touches an edge, a widening move will extend it, and extensions of hands, typography and architectural lines are where models are weakest. Second, your frame will not survive the trip at exactly the ratio you gave it. Alibaba is unusually candid about this for Wan 2.7: the output aspect ratio follows the input material but is "not guaranteed to match exactly", because encoders require "width and height to be multiples of 16", and it works the arithmetic in public. A 750 by 1000 pixel input at the 720P tier comes back at 816 by 1104 (alibabacloud.com, accessed 27 Aug 2026).
Other vendors refuse the mismatch instead. Seedance locks the output ratio to the first frame and requires ratio to be adaptive. Kling rejects anything outside 1:2.5 to 2.5:1. Vidu wants the two frames of a pair close in ratio. Give all of them a frame that is already the shape you want and none of this applies.
How Do You Keep the Last Frame Recognisable as the First?
Pin it, chain it, or loop it, in that order of reliability. If the end state matters, do not describe it; supply it. That is the entire reason last_frame exists, and interpolation between two real images is a much easier problem than extrapolation from one.
When you need more than one clip, chain rather than restart. Seedance exposes return_last_frame, which hands back the final frame of a generation as a watermark-free PNG at the output's pixel dimensions, explicitly so you can use it as the first frame of the next task. Luma lets you pass a prior generation's generation_id as an anchor. Either way you are handing the next clip a real image instead of hoping a paragraph reproduces one, which is the same principle behind keeping a character consistent across video clips.
For genuinely cyclical subjects, Luma's video.loop closes the cycle for you, though it is create-only and is not supported alongside duration: "10s", hdr: true or end_frame.
When Is a Still Simply a Bad Candidate?
When the image withholds information the model needs to move it. Four patterns account for nearly every failure we have seen, and none of them are fixable by prompting harder.
- Heavy occlusion. A subject cut by a railing, a crowd, or foreground foliage. The model has to decide what is behind the occluder the instant anything moves, and it will decide differently each frame.
- Ambiguous depth. Flat lighting, a shallow or painted-looking background, or a reflection the model can read as a window. Push in, and the scene either fails to part correctly or peels.
- Readable text in frame. Signage, packaging, UI, subtitles. Text rarely survives motion intact; ByteDance says as much for storyboard references, advising "Avoid adding text directly on the storyboard." If the text is the point, animate around it or composite it back afterwards.
- Edge-touching subjects. Anything important already flush against a frame boundary, for the reasons in the previous section.
There is a fifth that is not a technical limit at all. If the still is good because of a moment that is already resolved, adding motion can only take it somewhere else. Some images are finished. Our post on why AI video looks generic covers what happens when you animate something that had nothing left to say.
18 Copy-Paste Motion Prompts for an Existing Still
Every prompt below assumes an image is already attached. None describe the subject, palette or lighting, because the frame did that. Swap the bracketed nouns for what is in your image.
Ambient motion, for stills where nothing should visibly act:
Only the [steam] moves, rising slowly and drifting left out of frame. Everything else is still. Camera static.
Wind moves through the [foliage] in one slow gust that builds over the first two seconds and settles for the rest. No camera movement.
Surface of the [water] ripples continuously; the reflection breaks and re-forms. Nothing else changes. Camera static.
Dust motes drift downward through the existing light. Hold the frame. No other motion.
Single-subject motion, one action per clip:
The [figure] turns their head to the left over about one second, then holds. Nothing else moves.
The [door] swings open away from camera across the full clip, at a constant slow speed.
The [hands] complete the action already in progress, then come to rest. No camera movement.
The [bird] leaves the frame to the right in the final second. Until then, only small idle motion.
Camera moves that a fixed frame can support:
Slow dolly in toward the [subject] across the full clip. No subject movement. Ends slightly tighter than it began.
Slow dolly out, revealing a little more of the [room] on all sides. Subject stays centred and still.
Gentle lateral drift to the right, parallax only. Nothing in the scene moves under its own power.
Rack focus from the [foreground object] to the [background subject] over two seconds. Camera locked.
Slow jib up, ending looking slightly down on the [subject]. No other motion in the frame.
First-and-last-frame pairs, where you supply both images:
Interpolate between the two frames at a constant rate. No added action, no camera move beyond what the two frames imply.
Move from the first frame to the last frame in the final two seconds; hold near the first frame before that.
Transition between the two frames with a single continuous push in. No cuts.
Diagnostic prompts, for working out what went wrong:
Freeze everything. Camera static, subject static, no motion of any kind for the full duration.
Move only the [element]. Nothing else in the frame changes, including the camera.
That first diagnostic is more useful than it looks. If a fully frozen instruction still comes back with drift, the problem is your source image rather than your wording. Run the second one next, and between them the two clips tell you whether to rewrite the prompt or reshoot the still.
| Feature | Kling 3.0 | Veo 3.1 | Seedance 2.5 | LTX 2.5 | Luma Ray 3.2 | Runway Gen-4.5 |
|---|---|---|---|---|---|---|
| Takes a first frame | ||||||
| Takes a last frame | ||||||
| Last frame is optional | ||||||
| Extra reference images | 3 Elements | 3 | 30, separate mode | 64 keyframes | ||
| Pinning costs duration | Refs force 8s | Blocks auto-length | Caps at 5s | |||
| Last frame can stand alone | Not documented | |||||
| Frame rate is published | 24 fps | 24 fps | 24/25/48/50 | 24 fps |
The Reusable Half
Model capabilities in this table will move within months. The habit will not. An image to video prompt is a direction, not a description, and its quality is measured by what it leaves out.
That makes it an unusually good candidate for a saved prompt template. The motion clause changes per shot; the constraints tail and the per-model duration and ratio notes are identical every time. Prompt Architects stores that structure with variables so you fill in the moving part and keep the rest, across ChatGPT, Claude, Gemini and whichever video tool you paste into next. It generates and keeps the prompt. The image and the video stay with the tools that make them.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountStart from the still. Write one motion, one direction, one duration. Delete every adjective the image already earned.