Difforum · Storyboard

The dumbest way to find out your camera move is wrong is to render it. A feedback render is hundreds of sampler calls in a row - the pack's own measurements put the sampler at around 90% of the wall clock - so "let's see how it looks" costs you the afternoon. Storyboard is the node that lets you see first.

It runs the same engine the Feedback Sampler uses, with the sampler switched off. No diffusion, no model, no prompt. Load a still, describe the camera, and the node warps that picture through the whole move and hands you the result in roughly a second. Because it's the same engine, what you see is exactly the motion the render will get - including the failure modes.

What you get back

Four outputs, and they each answer a different question.

sheet is a contact sheet: one cell every every_nth frames, laid out columns across, each labelled with its timecode. This is the one you look at. Six cells across a row is a storyboard; two is a flipbook. The cell width is fixed, so a 60-second shot at every_nth: 8 gives you a very wide sheet - raise every_nth rather than lowering columns when that happens.

frames is the full warped batch, which is more useful than it sounds: it's a legitimate "no-diffusion" version of your clip, and people use it as a clean plate or as the init for a later pass.

camera_path is a top-down render of the camera's positions, so you can see the shape of the move - whether your orbit actually orbits, or whether it's drifting off to one side while you weren't looking.

info is the one I'd read even if I looked at nothing else. It reports average and peak frame-to-frame drift, then a plain-English verdict. Under a certain threshold it says the camera is nearly still and the feedback will stagnate - which is the real reason a Deforum-style render comes out looking like a still image with grain. Very fast and it warns about smearing unless the energy is high. A single spike that's several times the average gets called out with its timestamp, and the fix is to ease that cut in the Director's transition rather than to touch the camera. If none of that fires, it says the motion is evenly paced. Then it appends the engine's own notes, including which mode it ran in - and that last part is where the depth conversation happens.

Depth, and the honest fallback

depth is optional and takes a depth map - Depth Anything 3 is the pack's recommendation and is in ComfyUI core now (depth_anything_3_mono_large, near = white, which is Difforum's convention). With a depth map, 3D moves are real: dolly, truck, orbit with parallax that holds for the whole clip. Without one, 3D moves fall back to pseudo-3D, and the node says so in info instead of silently freezing the move the way older Deforum builds did. That's the whole reason I trust this node: it tells you when it's pretending.

The rest of the inputs

init_image is any still. preview_scale is your time budget - 0.5 works at half size and is much faster; 1.0 is full Setup size. direction is the check-you-want, because it carries the camera, the energy curve, the scene prompts and the keys in one wire from the Director. Alternatively feed params from Setup plus a camera track from the Camera nodes (or a Camera Import from After Effects or Blender), which overrides the Director's camera. symmetry previews an in-loop symmetry as the sampler would apply it.

One thing the node insists on: it needs a direction, or params and camera both. Feed it none of those and it raises rather than guessing a camera.

Install

ComfyUI Manager → search Difforum, or:

cd ComfyUI/custom_nodes
git clone https://github.com/chillithebillis/Difforum.git difforum

Restart. numpy only. Start from template 01 (storyboard_no_model) - it needs an image and nothing else, which makes it the cheapest possible introduction to whether this pack's way of thinking suits you. Template 03 adds the depth map for genuine 3D parallax.

Where people get burned

Setting preview_scale to 1.0 on a long clip and wondering why the "instant preview" took a while - the work scales with pixel count and frame count, and the speed claim assumes half size. Second, trusting the sheet at the wrong granularity: every_nth: 8 hides a two-frame pop completely. If your info shows a spike, lower every_nth and re-run, because the sheet is a summary, not a render. And keep in mind what Storyboard can't show you: it warps a still, so it can tell you the motion is right and the pacing is even, but it will never tell you whether the diffusion looks good. That's what the short test render is for.