VELVET VICE LTX — FP16 Chunked Image Scale By

VelvetViceLTXFP16ChunkedImageScaleBy is the sibling of the pack's Chunked Image Scale By, and the difference is one word: the output tensor is FP16 instead of matching the input. Every chunk is still computed in FP32 - the same common_upscale routine as the native node - then written into a preallocated FP16 tensor. Half the bytes on disk in RAM, identical math.

Why this variant exists

Because the Velvet Vice LTX workflow's VAE decode is FP16 (see the pack's FP16 Full VAE Decode node). Frames arrive as FP16, so an upscaled FP16 clip is exactly half the RAM of an upscaled FP32 clip. On a long clip that's the difference between a comfortable peak and an OOM. If you're scaling frames that are already FP16, this is the node you want; using the FP32-output sibling would double the output footprint for no quality gain.

How it behaves

Same chunking loop as the plain version: frames processed in frame_chunk_size batches, each chunk promoted to FP32, scaled with the chosen method, written into the FP16 output, intermediates deleted. Two extra touches:

• Zero-copy bypass. If the target size and dtype already match (FP16 input, scale_by 1.0), it returns the input tensor itself - no copy at all.
• Memory snapshots logged around the pass, so the console shows the peak at the scale stage.

Inputs and outputs

• image - frame batch, ideally FP16.
• upscale_method - nearest-exact, bilinear, area, bicubic (default), lanczos.
• scale_by - 0.01 to 8, default 1.0.
• frame_chunk_size - 1 to 64, default 4.
• Output: image, the scaled FP16 batch.

Note the description's caveat that it "never spatially tiles or temporally interpolates" - this is per-frame resampling, same as the plain version.

Installing it

Part of VELVET VICE - LTX (velvet-vice-ltx) via ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Velvet-Vice/velvet-vice-ltx

Restart and hard-refresh with Ctrl+F5. No pip deps.

Gotchas

• Feed it FP16 to get the benefit. Feed it FP32 frames and you're spending FP32 compute to write an FP16 output - fine, but you paid for the FP32 input tensor anyway. The design assumes the FP16 decode upstream.
• The output is FP16. If a downstream node needs FP32, converting later costs the RAM you saved. In this workflow the chain (FP16 decode → FP16 scale → FP16 encode) keeps everything FP16 on purpose, so don't break the chain.
• Not a diffusion upscaler. Same caveat as the plain version: this is classic resampling, memory-safe, no hallucinated detail.

It's a small tweak with a big effect on peak RAM, and in the Velvet Vice pipeline it's the natural pair to the FP16 VAE decode - half-precision end to end, so a 2× rescale of a long clip stops being a memory event.