Scale By Short Side @zn123
The minimum-resolution guarantee you didn't know you wanted
- image
- scaled_image
- width
- height
Most image nodes ask you to think in pixels: "make it 1024x1024." Scale By Short Side @zn123 asks a better question - how small is your smallest dimension, and how big do you want it? It rescales an image so its short edge hits a target length while keeping the aspect ratio intact. Portrait or landscape, tiny thumb or 4K scan, the short edge lands exactly where you told it to.
Why you'd reach for it
The short side is the bottleneck. A 1920x1080 landscape and a 1080x1920 portrait both have a short side of 1080, and any pipeline that cares about a minimum resolution - SDXL generation, ControlNet preprocessors, IPAdapter reference conditioning - cares about that smaller number, not the big one. So this is your "guarantee every input clears 1024 on its weak edge" node. It's the preprocessing step that makes a batch of wildly different source images behave like they belong to the same pipeline.
How it works
Simple math, visible in the source: it reads the current short side, computes scale_factor = short_side_target / current_short_side, and scales both dimensions by that factor with round(). Then it hands off to ComfyUI's own common_upscale with your chosen method.
The inputs that matter:
short_side_target- INT, 64 to 8192, default 1024. The length your short edge will become.upscale_method-nearest,bilinear,bicubic,area,lanczos(defaultbicubic).only_upscale- BOOLEAN, default true.
The outputs: scaled_image (IMAGE), plus width and height (both INT). Those two integers are the sleeper feature - wire them into an Empty Latent Image or any node that wants dimensions, and your conditioning is guaranteed to match what the image node actually produced.
The gotcha: it won't shrink by default
Here's where people burn themselves. only_upscale defaults to true, which means if the image's short side is already at or above your target, the node passes the image through untouched and returns the original width and height. That's great for "make sure nothing is below 1024" - it silently skips anything already big enough, saving you pointless resampling. But it also means this is not a "normalize everything to exactly 1024 short side" tool out of the box. If you feed it a 4000px-tall image expecting it to come out smaller, it won't. Flip only_upscale to false and it becomes a true resize that can also shrink.
Installing it
Same pack, same boring install:
- ComfyUI Manager - search "ComfyUI-image-processor-zn123", install, restart.
- Manual - from
ComfyUI/custom_nodes:
cd ComfyUI/custom_nodes
git clone https://github.com/zn123/ComfyUI-image-processor-zn123
Restart and it's under image/processor. No models, no extra deps - requirements are torch/numpy/Pillow, all of which ComfyUI already has.
Gotchas
- only_upscale=true is the default. Expect pass-through on already-large inputs until you change it.
- This is a pixel-space resize, not generative upscaling. Setting a target above your source just interpolates; it doesn't add detail. If you want real detail recovery on a small source, upscale small first with a proper upscaler, then scale by short side.
areais the sane pick if your target is below the current size (onceonly_upscaleis off);lanczosorbicubicfor up.
Set a floor, feed it anything, get a consistent pipeline. That's the whole trick, and it's a good one.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| short_side_target | INT | 102464–8192 | — |
| upscale_method | COMBO | bicubic | 5 options: nearest, bilinear, bicubic, area, lanczos |
| only_upscale | BOOLEAN | true | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| scaled_image | IMAGE | — |
| width | INT | — |
| height | INT | — |