What an Image to Prompt Line Gives a Video Model

An image-to-video request asks for eleven fields. One line of image-to-prompt output fills exactly one of them. I ran forty real files through this tool’s own measurement path — 480 lines, four output shapes, three lengths — and checked each field against them. The prompt field is filled 480 times out of 480. The first frame is the file you already uploaded. Every other field is at zero: 0 of 480 lines carry a duration, a resolution, a frame rate, a seed, a camera instruction, a second frame or a negative prompt. That is not a gap in the wording — it is structural. All twelve slots this tool writes are measured from a single still, its whole output vocabulary is 149 words and none of them is a motion word, and the only number that ever reaches the line is the ratio: the token 16:9, 600 times, with not one bare integer anywhere in the set.

What these numbers are. Forty real files — 39 photographs at 640 × 360 and one code screenshot at 800 × 450 — decoded on this machine, box-downsampled to the 192 × 192 grid the live tool measures on, then pushed through the same analyze → describe → compose path the browser runs. The eleven fields on the right-hand side come from two published image-to-video request schemas, read off their public model pages on 2026-11-03 (no key, no account, read-only fetch). No video model was called and no video was generated: every figure below describes the words this tool writes, not what any generator would do with them.

Eleven fields, and only one of them is in the line

Two image-to-video models publish their request schemas. One takes six input fields and marks two of them required; the other takes ten and marks one required. Between them, after folding the duplicates together — start_image and image are the same field, so are end_image and last_frame_image, and so are mode and resolution — there are eleven distinct things a video request wants. Here is what each of them can get from the line.

The ratio row is the only partial, and it is worth being precise about it, because it looks better than it is. The string 16:9 does appear in all 480 lines — but as English inside a phrase, in widescreen 16:9 composition or A widescreen 16:9 image. Only the Midjourney shape writes it as a parameter, and that is 120 of the 480 lines, one shape out of four. And there is only one ratio to write: all forty files measure to the same arParam, so the line offers 1 of the seven values the request accepts.

Taken together, that is one field fully supplied, one supplied by the file you already had, and nine with no source anywhere in the output. If you are moving a still prompt into a video request, you are not editing a line — you are writing nine fields around it.

The only number that reaches the line is a ratio

Duration, resolution, frame rate and seed are all numbers, so I counted every number-shaped token in all 480 lines. There is exactly one distinct token in the whole set, and it appears 600 times:

480 lines, every token containing a digit:

    16:9      600        (480 as "widescreen 16:9" in the framing slot
                          + 120 again as the "--ar 16:9" parameter)

    bare integers ............. 0 / 480 lines
    "640" "360" "800" "450" ... 0 occurrences
          (the true sizes of the forty files: 640x360 x39, 800x450 x1)

Two things follow. First, nothing in the line can be read as seconds, as frames per second, or as a seed, because no line contains an integer standing on its own — the one number present is a ratio, and it is always attached to a colon. Second, the tool measures the pixel size of every file it reads and then never writes it: the forty files are 640 × 360 and 800 × 450, and those four numbers appear zero times between them. A resolution field has nothing to read.

The ratio itself is narrower than it looks. Fed eleven real-world pixel sizes, this tool’s ratio parameter produces nine distinct strings, and only five of them are values the video request accepts. The two extreme cinematic ratios are unreachable at any input size: a 2520 × 1080 frame comes back as 7:3 and a 1080 × 2520 frame as 3:7, because the ratio is reduced by the greatest common divisor and capped at 60. If your video is 21:9 or 9:21, this line will never hand you that string — you set it in the request, or you do not get it.

Nothing in the vocabulary moves

The nine zeros are not nine separate accidents. They are one fact: the tool measures a still, so nothing it writes can describe an event. To make that checkable rather than rhetorical, I built the full output vocabulary — every word in all 480 lines, plus every string literal in the four source files that produce them — and tested it against two word lists.

The motion list

Sixty-seven motion words: move, pan, tilt, zoom, dolly, orbit, rotate, spin, drift, float, fly, flow, ripple, wave, flicker, walk, run, turn, tracking, handheld, shake, wobble, breeze and the rest of their inflections. Against a 149-word vocabulary, the number of hits is zero. For another angle on the same fact: the vocabulary contains three words ending in -ing — falling, lighting, uplifting — and not one of them is an action. And of the twelve slots the writer fills, none is a time slot or a motion slot; all twelve are per-pixel statistics of one frame.

The one word that looks like it does

The time list — nineteen words: seconds, fps, frame, frames, loop, duration, timelapse, slow, speed and so on — returns a single hit: frame. It occurs in 12 of the 480 lines, all of them the Flux shape, and always in the same fixed sentence, The frame is dominated by …. That is the word for the picture, not for a frame of video. Twelve lines is four files times three lengths — the four files that cross the monochrome threshold, which is the only case in which this writer is allowed to name a subject at all.

The second-frame fields fail for a harder reason than vocabulary. The adapter that runs in the browser takes one image and returns one measurement: imageToPromptFromImage(img), analyzeImage(img). There is no second argument and no state between runs, so end_image, last_frame_image and reference_images (one to four images) have no input path at all. Whatever second frame your video needs, this tool cannot describe it, because it never sees two.

Six of the seven ratios are out of band in this site’s own parser

So you add the missing fields by hand. That is where an old hazard of this tool’s own syntax comes back: its weight parser reads a colon followed by a number at the end of a comma-separated term as a weight, and its usable band is 0.4 to 1.6. A video request is full of colons and numbers. Here is what the seven accepted aspect ratios become when they land at the end of a term:

Six of the seven are out of band, and the single survivor is the one ratio nobody uses for video. The same rule catches the way people write the other fields, and the spacing is what decides it: duration:10 is read as a weight of 10.00, while duration: 10 with a space is read as 1.00; fps:24 becomes 24.00, while 24 fps stays at 1.00; seed:1234 becomes 1234.00, while seed 1234 stays at 1.00. Written the ordinary way — 10 seconds, 24 fps, 1080p — all of them are read as weight 1.00 and none of them is flagged. Only the colon-and-number form trips it.

Which means the practical rule is about where you put things, not about what you say. I appended an eight-word motion clause — camera slowly dollies in, 10 seconds, 24 fps — to all 480 lines and re-checked: the out-of-band count is 120 of 480 before and 120 of 480 after, unchanged, and the clause contributed 0 new out-of-band terms in 480 of 480 lines. All 120 were already there — the Midjourney shape’s trailing --ar 16:9, which the parser reads as 9.00 and always has. Write your motion clause after the ratio, keep numbers away from colons, and the line you built for a still passes through unchanged.

What you add by hand, and what it costs

That eight-word clause is the whole of what the missing nine fields cost you in prose: one camera move, one duration, one frame rate. Against the median line this tool writes, that clause is between 16.7 and 33.3 percent of the finished prompt — the tool’s own share runs from 66.7 percent (Flux and DALL·E, short length, 16 words) to 83.3 percent (Stable Diffusion, long length, 40 words). So the line is most of the words and one eleventh of the fields. Both of those numbers are true, and they are true for the same reason: the tool is doing the part that a still can answer, and the part it cannot answer is short.

1. Treat the line as the frame, not the shot. Everything in it — framing, exposure, palette, colour temperature, detail, where the light falls, mood — is a true description of the first frame. Nothing in it says what happens next, and no setting will make it say so.
2. Write the motion clause last, and keep your numbers away from colons. Appended after the ratio, the clause added no out-of-band term in any of 480 lines. Written as duration:10 or fps:24, the same numbers become weights of 10.00 and 24.00.
3. Set the ratio yourself if the video is not shaped like your still. Forty files gave one distinct ratio and the eleven sizes tried gave nine strings, five of which the request accepts. A 21:9 or 9:21 video cannot come out of this line at any input size.
4. Do not wait for a negative prompt. No line in 480 contains one, and the negative field is empty by construction — the writer has no slot for it. If your video request has a negative field, it is yours to fill.
5. The second frame has to be your image. One image goes in, one measurement comes out, and no state carries between runs. Any field asking for another image is outside this tool entirely.

Forty stills, 480 lines, four scripts: where each number came from

The forty files are the same corpus used elsewhere on this site: 39 stock photographs at 640 × 360 plus one 800 × 450 code screenshot, decoded locally, box-downsampled to 192 × 192, then measured and written by the identical analyze → describe → compose path the browser runs, across four output shapes and three lengths — 480 lines. The eleven fields are the union of two published image-to-video request schemas as they read on 2026-11-03. Every count in this page was produced by one of four scripts and is on disk:

prep/day45_video.mjs    -> prep/day45-video.json     field fill rates / vocabulary / numbers / parser
                           prep/day45-video.log
prep/day45b_video.mjs   -> prep/day45b-video.json    the 12 "frame" lines / two word lists / clause share
                           prep/day45b-video.log
prep/day45c_ratio.mjs   -> prep/day45c-ratio.json    11 real pixel sizes -> 9 ratio strings
                           prep/day45c-ratio.log
read-only fetch, no key -> prep/day45-video-fields.json   the 11 fields from two public schemas

Three limits on reading these numbers. The corpus is 39 landscape photographs and one screenshot, and every one of them is 16:9 — so the ratio variety here is the variety of this corpus, not of the tool; a set of square and vertical files would produce more of the seven values, though never 21:9 or 9:21. No video model was called, no video was generated and no image was produced: every statement is about the words this tool writes. And the eleven fields are what two published schemas said on the day they were read; vendors add and rename fields, so the inventory is a snapshot, not a constant.

For the twelve slots the line is built from, see what an image to prompt tool measures. For how the same measurements are worded differently by each of the four output shapes, see the four lines measured side by side. For the cut points at which every phrase flips, see the twenty-nine thresholds, and for what the weight parser does to a colon and a number, see weighting a prompt and writing a negative.