FlashVSR+ Upscale Frames

Video upscalers can do something image upscalers can't: they know what the previous frame looked like. Point one at a single photo and you get a restorer that has been trained on temporal consistency, which is weird overkill - and also surprisingly good, because it has learned to reconstruct faces and fine texture instead of just sharpening edges.

That's what this node exposes. It takes an IMAGE batch, and by default that's the lane it stays in: the pack's own single-image workflow is Load Image → FlashVSR+ Upscale Frames → Save Image, 4×, seed 1, colour correction on.

How it works

The batch goes in as a [frames, height, width, 3] RGB tensor. The node computes a target size, then pads the frame up to the nearest multiple of 128 in both axes, runs the model, and crops back down to the size you asked for. So the model always sees a clean canvas and you always get back exactly the dimensions you requested - no mystery 128px letterbox. Padding is replicate, not black, which is why the crop is survivable.

Two consequences worth internalising. First, the whole batch is held in CPU RAM - the code deliberately keeps the full clip out of VRAM and only feeds bounded windows to the GPU. Second, the batch is interpreted as consecutive video frames, not as independent images. Feed it four unrelated photos and the model will try to reconcile them temporally, because as far as it's concerned time just passed.

The inputs that matter

• model - from FlashVSR+ Model Loader. Non-negotiable, that's where mode/precision/decoder live.
• scale - default 4, range 0.25 to 16. This is the default sizing path.
• width / height - the tooltip on width is the rule: "0 uses scale or preserves aspect ratio from height." Leave both at 0 and you get scale ×; set one and the other follows from the source aspect; set both and you've overridden the geometry entirely. 16384 is the ceiling.
• seed - default 1, and it has control_after_generate enabled, so ComfyUI will offer to randomise it. For a restorer you generally want the default fixed, so you can compare settings honestly.

options is the optional socket for FlashVSR+ Options. It isn't required, but it's the only way to reach colour correction, and colour correction is the usual fix for a washed-out result after a VAE round-trip.

Outputs

images is the upscaled IMAGE at your requested size - wire it straight into Save Image, or back into a blend/compare node. info is a JSON string: mode, precision, the attention backend that was actually selected, seed, and both the content and padded canvas dimensions. When output looks like a different model than you expected, actual_backend in that string is the first thing to check.

Installing

ComfyUI Manager, search FlashVSR+ T8, install and restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-Flashvsr-Plus-T8.git
python -m pip install -r Comfyui-Flashvsr-Plus-T8/requirements.txt

Models live in ComfyUI/models/flashvsr_plus (or the pack's ckpts folder) and download automatically on first run if auto_download is on - around 5.7GB per DiT pair at bf16, or ~1.45GB if you go INT8. CUDA only.

Where it goes wrong

Small text and flat graphics. The author validated this honestly and it did not pass: a 256×192 text chart upscaled fine, but "small glyphs changed, flat fields gained texture, and faint edge halos appeared." It's a photo restorer. Screenshots of terminal output are the wrong tool, and no setting fixes that.

Transparency. RGB only. The node doesn't composite alpha; that's a separate pass by design.

Batch of unrelated images. Already covered, but it's the number one mistake. Loop them, or use one image per run. There's also a minimum processing-block cost per image, so a folder of 200 thumbnails is a miserable way to spend an evening.

VRAM maths. A 4× upscale of a 1080p photo is 7680×4320. You get a mid-run allocation failure, not a warning. Drop scale, or set width/height to something a card can actually chew - and if you keep the Tiny decoder, drop decode_every in the Options node.

On vae vs tiny for stills. The strict decode_every=0 requirement people hit in the video node doesn't bite here - that check is on the file-based video path. Still, Tiny plus a small decode_every is the memory-friendly combo, and one frame at a time is exactly the workload it was built for.