Deforum's own script names the settings that hold a frame steady

The image

The record is the Deforum Stable Diffusion repository, an open-source animation pipeline built on Stable Diffusion, together with its own configuration script, Deforum_Stable_Diffusion.py. Rather than a single still, the visual material the project documents is a settings form: named fields a user fills in before rendering a frame sequence, several carrying an example default value written directly into the script's comments.

What the documents show

The README describes the project as built by "a community of programmers and artists" and states it now offers "over 100 different settings available in the main inference notebook," while directing detailed configuration to an external guide. The script itself is more specific than the README's prose: it names an "animation_mode" field with options including "None," "2D," "3D," "Video Input" and "Interpolation," and lists motion fields — "angle," "zoom," "translation_x," "translation_y," "translation_z," "rotation_3d_x/y/z" — plus schedule fields including "noise_schedule" and "strength_schedule," each given as a keyframe string such as "0: (0.65)." A "color_coherence" field, with options such as "Match Frame 0 LAB" or "Video Input," is the script's own named mechanism for holding a look across frames.

Production context

Read editorially, naming a "Video Input" animation mode with a "video_init_path" field and a "diffusion_cadence" setting documents that the pipeline was built to process an existing video frame-by-frame, not only to animate from a blank prompt — the closest documented analogue to a rotoscoped or style-transferred edit. That the README states the project is "no longer actively maintained" as of this reading is itself a documented fact worth carrying into any production note that cites it as a current tool.

Reference versus imitation

The schedule fields condition frame-to-frame change on numeric keyframes the user sets, not on any external artist's footage; the "color_coherence" options exist, by their own naming, to correct drift the pipeline would otherwise introduce, which is the project's own acknowledgment of a known limitation rather than a claim of temporal stability. Nothing in the README or script asserts the output looks identical to its video input at "Video Input" strength settings below 1; the strength_schedule field explicitly allows partial adherence.

• Which animation_mode and which strength_schedule values were used to produce the sequence in question?
• Is a color_coherence method named, and does it correct drift or merely reduce it, per the tool's own framing?
• Is the repository being cited as actively maintained, when its own README currently states otherwise?

A configuration script's own field names are a primary record of what a pipeline can be told to do; they are not, on their own, evidence that any specific rendered sequence held together across frames.