Internal S2V Process Image

Spreadsheet2Video Process Image (node class Spreadsheet2VideoProcessImage) is the second of the pack's two internal nodes, and it gets the same one-line dismissal in the README: "Ignore them. Used internally only." Its own description is "internal node, ignore." You should not be adding this to a workflow - when the main Spreadsheet2Video node runs, it swaps your Spreadsheet2Video Output Image nodes for this machinery automatically. It's the engine behind the loop's most important promise: each row starts from the last frame of the row before it.

What it does

After every spreadsheet row finishes, this node:

1. Saves the row's output image to the pack's temp folder as a lossless PNG (ComfyUI/temp/Spreadsheet2Video_<prompt_id>/v_000001.png, incrementing per row). If the row produced audio, it saves that as FLAC too.
2. Passes the last image forward - that's what the IMAGE output carries, and it becomes the first_image of the next row's generated subgraph.

If a row outputs a video, the frame that gets saved and passed on is the video's last frame, which is the whole "long video" trick: clip one, clip two, clip three, each starting exactly where the last ended. Combined with the final stitch node (Spreadsheet2VideoFinalVideo), the pack turns a sequence of short clips into one continuous-feeling take.

The inputs and outputs that matter

For completeness, it takes a previous INT (a chain signal from the prior row's node), optional images and audio, and outputs INT, IMAGE, and AUDIO. The only one with any meaning for you is the IMAGE output - that's the hand-off frame. Everything else is bookkeeping.

Why you should care about a node you'll never place

Two reasons. First, the temp PNGs it writes are why the README can say "The raw frames are in the ComfyUI/temp folder if you want lossless quality" - if a final video looks compressed, grab the individual frames from there instead. Second, understanding that each row is an isolated save-and-restore explains some behavior: the loop isn't doing frame interpolation or true temporal continuity, it's a chain of independent generations where each clip's last frame seeds the next. If your rows drift (colors shifting, objects changing), that's the nature of sequential generation - the pack is chaining, not smoothing. Fixes live in your generation nodes, not in this node.

You'll never configure it, and that's the point. It's the quiet middle of the loop doing exactly one job: making sure every row knows where the last one left off.