Image Resize (Batch)

Resizing one image is trivial. Resizing 200 frames so they all come out the same size, land under a memory cap, and stay aligned to the multiples a video model wants - that's where people start doing arithmetic by hand and then hate themselves. "Image Resize (Batch)" does the arithmetic for you.

What it is

NNImageResizeBatch resizes an image batch to a target width/height, with three guardrails that make it actually useful in real workflows: a scale_by multiplier, an automatic max_resolution cap, and divisible_by rounding so the output dimensions stay friendly to latent and video models. Per the README: "Batch processing, GPU acceleration, automatic maximum resolution limiting, dimension rounding support."

How it works

The pipeline is: take the target width and height, multiply both by scale_by, then check whether the longest side exceeds max_resolution - if it does, scale everything down proportionally to fit. Finally round both dimensions down to a multiple of divisible_by (default 2). If the computed size equals the input size, the node passes the batch through untouched - a nice no-op that keeps re-runs cheap.

Actual resampling uses bicubic interpolation with anti-aliasing, the same high-quality filter family as the pack's NNImageUpscaleBy. The batch handling is the differentiator: batch_size (1–256) controls how many frames are processed per chunk, each chunk moves to your chosen device, and results are copied off-GPU incrementally. A 500-frame batch resized 2× won't spike VRAM to the moon; it churns through in slices and holds.

The inputs that matter

Seven inputs, but only a few you'll set per workflow:

• width / height - target dimensions, 0–8192, defaults 1024 each. Setting scale_by multiplies these.
• scale_by - 0.01–16, default 1.0. The multiplier on top of width/height.
• max_resolution - 64–8192, default 2048. The cap that keeps you from accidentally resizing into OOM territory.
• divisible_by - 2–256, default 2. Rounding multiple for model compatibility; video models often want 16 or 32.
• batch_size - frames per chunk, 1–256.
• device - gpu or cpu.

Single images output, same batch count as the input.

When to reach for it

Any time you're feeding a batch into something with hard size requirements: prepping a frame sequence for a video model's input resolution, normalizing a mixed batch of images before a detailer pass, or shrinking a big batch to workable preview size. The max_resolution cap alone is worth the node - it's the guardrail that prevents "I typed 8192 and killed my GPU." It also pairs naturally with the pack's resolution calculator nodes (NNImageResolution), which produce the width/height you'd feed into this.

Installing

One of ~25 nodes in bandifiu/ComfyUI-NN-custom-nodes:

cd ComfyUI/custom_nodes
git clone https://github.com/bandifiu/ComfyUI-NN-custom-nodes

Restart ComfyUI (or Manager → "NN-custom-nodes"). Deps: torch, numpy, pillow - no models, no downloads. GPL-3.0, newer V3 backend API, no NODE_CLASS_MAPPINGS in the source.

The subtle trap is divisible_by interacting with max_resolution: rounding happens after the cap, so a dimension can land a hair over your intended cap - harmless in practice, but if you're strict about an exact ceiling, account for the rounding in your target. And remember both width and height get multiplied by scale_by; if you set width 1024, height 1024 and scale 2.0, you're asking for 2048×2048, not 1024×1024.