Scene Cut Split

Scene Cut Split takes the frame batch and the cut JSON from Scene Cut Detect and hands back the frames of one shot. Pick the index, get that shot as its own batch, plus the frame range it occupies and a description of it.

It's the other half of the pair, and the split is what makes shot detection useful rather than merely informative. Once you can hand a downstream node a single shot instead of a whole clip, you can do the things that only work per shot: reset a temporal model, apply a different denoise or a different prompt, stabilise, retime, regrade, or hand each shot to a different branch of the graph.

How to drive it

Three required inputs, and the pairing is strict: images must be the same frame batch that was analysed. Not a re-read of the same file, not a different range - the split is index-based into the batch you give it, and feeding it something else means the shot boundaries point at the wrong frames. If cut_data contains no shots, the node returns the batch whole, which is a sensible failure mode: no cuts means one shot.

cut_data is the JSON string from the detector. shot_index is 0-based (default 0, range up to 9999) and picks which shot to extract - so the first shot is shot_index: 0, not 1. That off-by-one is the thing to remember; the schema's tooltip tells you to connect the detector's shot_count output so you know the range, which is exactly the right habit. If you're building a loop or a batch-of-graphs setup, shot_count from the detector is your upper bound and shot_index is your counter.

Five outputs, and they're a nicely complete little bundle. frames is the extracted shot as an IMAGE batch - that's the one you wire onward. shot_index echoes the index back, which is handy when the node is somewhere in the middle of a chain and you want a label. start_frame and end_frame are the shot's boundaries as INTs, and shot_info is a STRING describing the shot. Those last three are the reporting surface: burn them into a frame with a stamp node, name a file with them, or feed them into a report. When you're processing a 40-shot sequence unattended, having each output labelled with its own frame range is the difference between a folder of clips and a deliverable.

The workflow, end to end

1. Get the clip in as a batch - Radiance's Read node handles video and sequences, and note its max_video_frames cap if you're working at 4K.
2. Scene Cut Detect on that batch. Keep the cut_data and look at score_plot once, so you trust the boundaries.
3. Scene Cut Split with the same batch and the JSON, shot_index set to whichever shot you're working on.
4. Process frames as its own clip. This is where per-shot prompts, per-shot denoise and temporal resets live.
5. Export per shot; start_frame and end_frame tell you where it belongs back in the timeline.

Install

Ships with Radiance. ComfyUI Manager → search Radiance → install → restart → refresh. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

No models, no downloads - it's slicing a tensor using the JSON's boundaries. Cheap enough to run many times per graph.

Where people get burned

• Mismatched batches. The single most common mistake, and it fails silently with plausible-looking wrong frames. Detect and split on the same wire.
• Expecting all shots at once. One call, one shot. If you want everything, you either loop over indices with a batch driver or run the graph per shot - there's no "give me all of them" flag.
• Empty cut_data. No shots means the batch comes back whole, so a graph that "did nothing" usually means the detector found no cuts. Check shot_count on the detector before blaming this node.
• Losing the frame numbering. frames is a fresh batch starting at index 0. If the shot's position in the original timeline matters downstream, carry start_frame alongside it rather than assuming the batch knows where it came from.