Resize Shortest Side To 📐

There's a specific annoyance this node kills. You have an image of unknown size - a phone photo, a video frame, whatever a folder loader spat out - and the next node in the graph needs a size. Not that size, not this size: a predictable one.

So you open a resize node and it asks whether you mean the long side or the short side. Set the long side to 640 and a 9:16 portrait lands at 360×640, a thumbnail. Set the short side to 640 and the same image lands at 640×1138, still usable. Short side is what video people have always meant by resolution (480p, 720p), and it's the number that correlates with how much detail survives the trip. That's the node.

What it does

ResizeShortestTo scales an image so its shorter side becomes the number you type, preserving aspect ratio. No crop, no pad, no canvas - one scale factor applied to both dimensions. A 1920×1080 frame with size 640 becomes 1138×640; a 300×900 becomes 640×1920.

Be clear about what it is: a plain interpolator, the "more pixels, source already sharp" job in the upscaling taxonomy. It cannot invent anything and runs in milliseconds. If your source is soft and you want detail that was never there, no setting here fixes that - that's the SeedVR2/SUPIR branch. What this does is normalize input geometry: a deterministic starting size for an img2img pass, a video workflow, or a second-stage resize.

How it works

The math is deliberately boring, and both non-obvious details are in the source.

scale = size / min(height, width), applied to both sides. Downscaling runs with antialiasing on. Without it, high frequencies fold back and thin lines, text and hair get a jagged shimmer - precisely what someone choosing lanczos is trying to avoid. torch has no Lanczos kernel, so the README says it plainly: lanczos maps to bicubic + antialias, the closest available match. Bicubic overshoots on hard edges, so the output is clamped back into 0..1 or bright edges ring and clip. area and nearest-exact pass straight through to torch's modes. And if the resize would be a no-op, you get your tensor back untouched instead of a pointless round trip through an interpolator.

Inputs that matter

• image - any IMAGE, batches included.
• size - target length of the shorter side, default 640, range 1–16384. The only number most people touch.
• method - lanczos (default), bicubic, bilinear, area, nearest-exact. Leave it on lanczos for photos. nearest-exact when you want hard pixel edges, area for hard downscales. Pixel-art caveat: float scale factors mean blocks won't land on a whole-pixel grid, and the pixel-art pipeline needs integer ratios.
• round_to_multiple_of - optional, default 1, max 64. Set it to 8 and both sides round up to a multiple of 8, which most VAEs want; 64 if you're on Flux, per the resolution notes.

The "round up, never down" rule is deliberate: truncating 640 to 632 would silently break whatever comes next. The trade is that your output can land a few pixels above target.

Outputs are image, plus width and height as INTs. Don't sleep on those two - wiring them into an empty-latent or video node is how you guarantee downstream geometry matches what actually came out instead of quietly going off by eight pixels.

Installing it

ComfyUI Manager, search AICU Utils, or:

cd ComfyUI/custom_nodes
git clone https://github.com/aicuai/comfyui-aicu-utils

Restart ComfyUI. That's the whole install - the repo's requirements.txt says, in effect, "torch only," and the package depends on nothing else. No model downloads, no pip step.

That emptiness is the point. AICU's book workflows used ResizeShortestToNode from ComfyUI-LogicUtils - and nothing else from that package - while LogicUtils 1.7.2 rolled numpy back to 1.26.4, adding roughly 109 seconds to Colab startup and 18 dependency conflicts in the author's own measurement. A lot to pay for one resize. Upstream declares no license, so forking wasn't an option either; this is a clean-room Apache-2.0 reimplementation. If you've ever watched a custom node downgrade a library your other nodes needed, you know the mechanic.

Where people get burned

A downstream "Sizes must be divisible by 8" error. You resized to 640 on the short side and the other side came out as some prime-number monstrosity. Set round_to_multiple_of to 8 and it's gone.

Expecting exactly size. Both sides round up. If exact dimensions are load-bearing, read the width/height outputs instead of assuming.

Treating it as an upscaler. Hand it 512×512 and ask for 1024 on the short side and it will oblige - with a soft, empty 1024. Pixels are interpolated, not generated.

Thin, brittle results after a big downscale. Stop downscaling so far, or push the small image through a generative restorer after the resize instead of expecting interpolation to hold detail it just threw away.

The repo also ships a test file, if you want to check the behavior before trusting it in a real graph:

cd ComfyUI/custom_nodes/comfyui-aicu-utils
python3 test_resize.py

It verifies that the short side lands where you asked, aspect ratio holds, rounding never goes down, and a zero-sized input raises instead of passing silently.