Storyboard and previz a sequence with generated frames

Write the beats before you render a frame

A panel is a beat, not a picture you happen to like. Write the sequence first as a list of changes: what is different in this frame from the one before it. If you cannot name the change, the panel is decoration, and decoration costs the same as a beat.

Pacing belongs on that list, because rhythm lives across shots rather than inside one. Cutting, DeLong and Nothelfer, writing in Psychological Science in 2010, measured the shot structure of 150 films released between 1935 and 2005 and found that across that span "shots became increasingly more correlated in length with their neighbors and created power spectra approaching 1/f". Whatever you make of the attention argument they build on it, the unit of rhythm is the run of shots, and you decide it at the board rather than one frame at a time.

This is the job previs was named for. The ASC-ADG-VES joint subcommittee that settled the industry definition in 2009 described previsualization as a process that "generates preliminary versions of shots or sequences", and the operative word is preliminary. Work in cheap frames until the order of the beats stops moving.

Fix the frame shape at the board stage

Aspect ratio binds everything downstream, so choose it early and stay inside it. A board in mixed shapes cannot be read as a sequence at all: the eye spends its attention on the frames instead of on the cuts, which is the one thing a board exists to test. Each model page lists the sizes that model accepts, read from the server as the page loads.

The shape also decides what is left to choose later. Where a panel becomes the opening frame of a clip, that picture sets the clip's shape and there is no ratio left to pick. Other video models take a ratio in the request, and on some it is required. Choosing resolution and length covers how both settings hit the bill, and from a still to a video covers cropping a panel before it becomes a first frame.

Hold the subject from panel to panel

Nothing carries between runs by itself. There is no session that remembers the last panel and no setting that fixes a face, so a character can come back different when your wording barely moved. That is the work rather than a defect in any particular model.

You have two handles on it. The first is what you hand the model: an editing model reworks the picture you supply and leaves the rest of the frame where it is, which is the shape of a storyboard already, one subject carried through changing staging. The second is your wording, which should stay still on purpose. Keeping a character consistent is the whole method, including why you upload a panel rather than link to it, and character design covers building the anchor in the first place.

For a board specifically, the discipline is to write the panel prompt as two parts and only ever edit one of them: a block that never changes, holding the character and the world, and a line that changes every panel, holding the staging and the beat. A board drifts when those two get mixed together and a re-worded description quietly re-opens the face.

Which beat earns a moving test

Not every beat needs a moving test, and animating all of them is how a board stops being cheap. Animate the ones whose open question is motion: whether the action reads at all, whether the camera move is physically possible, whether the beat fits the length you had in mind. A beat whose open question is staging is answered better and faster by another frame.

The routes ask different things of you. Handing a panel over as the opening frame is the tightest, because composition is settled before the run and the whole render goes into movement. A reference-to-video model fixes who appears without fixing the frame, so the staging is still yours to write, and a model working from description alone starts the scene from nothing. Write the camera in all three cases; leaving it out gives you an arbitrary shot rather than a static one. The video overview sets out the routes.

Running the board as batch work

Boards are batch work, which changes what goes wrong. Runs are asynchronous, so closing the tab does not lose a panel, and you can fire a row of them and collect the ids. Image and video runs are counted against separate rate limits per account, and when you cross one the response says how long to wait in a Retry-After header; read it rather than guessing.

From a script, let the catalog supply the options instead of a constant in your source, and treat a failed panel as settled rather than reconciling anything yourself. Calling the API from your code has the loop and the error codes.

Panels do not sit on the server forever, though the record of what they cost does. Download the board the day you make it, because a board you cannot reopen is a sequence you have to shoot from memory.