Auto Resolution (From Image)
Auto Resolution (From Image)
- image
- width
- height
You've got a 1080x1920 phone photo in Load Image and you want to restyle it, drive a video model with it, or just resize it to something a diffusion model won't choke on. So you open Empty Latent Image and start typing 1080 and 1920 into two boxes like it's 2019. Those numbers are wrong for every model you own, and rounding them by hand skews the aspect ratio until the person in the photo looks slightly fatter than they do.
Auto Resolution (From Image) does that arithmetic for you: feed it an image, set a megapixel budget, get back a width and a height that keep the picture's exact shape and land on a grid your model accepts. That's the whole node. No LATENT output, no model awareness, no download.
Why it earns a slot in the graph
Resolution is one of the few places where ComfyUI still makes you do homework. Every architecture has a native size, going off it gives you duplicated anatomy and stretched limbs, and the dimensions must be divisible by something the VAE can chew - 8 for SD 1.5 and SDXL, 16 for the newer models, 32 for video. The KB's standing advice is "generate at native resolution, upscale after", which is a lot easier when you stop hand-typing numbers.
There are, to be fair, a great many resolution selectors. The top-posted one I can find is a preset picker with 40+ resolutions, whose author opens by admitting "I know there are already plenty of resolution selectors out there". The difference here is the input: presets assume your picture is one of the standard ratios, and your picture is whatever your phone produced. This node keeps that shape.
How the math works
Area-preserving: you name a megapixel target, it works out the scale factor that hits that target for the source's shape, then rounds each axis to the nearest multiple.
scale = sqrt(megapixels * 1024² / (src_w * src_h))
width = max(multiple, round(src_w * scale / multiple) * multiple)
height = max(multiple, round(src_h * scale / multiple) * multiple)
Straight from the source. A 1080x1920 photo at 1.0 MP comes out 768x1376 - same 9:16 shape, 1.01 MP, both axes on the 32 grid. It reads image.shape and nothing else: no pixels inspected, no content classified. A calculator with an image socket.
The three inputs that matter, and the two outputs
image- anyIMAGE. Only its dimensions are used, soLoad Image, a decoded video frame, a scale node, whatever.megapixels- FLOAT, 0.1 to 16, step 0.01, default 1.0. Two decimals, so 1.64 MP is legal. The author's own note: 1.0 means "1024x1024 worth of pixels", not "1024 wide".multiple- INT, 8 to 128, step 8, default 32. The one you should think about, because the node has no idea what model you're loading. Tooltip: 8 for SD/SDXL, 16 for Flux/Wan, 32 for MiniMax H3. LTX video wants 32 as well, which is why 32 is the default.
Outputs are width and height, plain INTs - wire them into Empty Latent Image (or the Flux/SD3 latent equivalent), a resize node, a video latent's dimensions.
One quirk that explains behaviour you'll notice: the node is flagged as an output node and returns its dimensions alongside a tiny ui payload holding the source size. That's what lets the on-node preview keep working when the upstream image node has no thumbnail to read. Side effect: it always executes.
Install
One node, zero dependencies - pyproject.toml has an empty dependencies array, so there's nothing to download.
# ComfyUI Manager: search "Auto Resolution" and install
# or via comfy-cli (it's on the Comfy registry)
comfy node install comfyui-autoresolution
# or manual
cd ComfyUI/custom_nodes
git clone https://github.com/FrTime/ComfyUI-AutoResolution.git
Restart ComfyUI. It lives under utils, or just search "Auto Resolution" in the node list.
Things that trip people up
The green lines say "connect a Load Image" while you're clearly connected. The preview reads dimensions off the thumbnail the upstream node shows - it looks at the linked node's imgs[0]. No preview upstream, nothing to read, and the lines fall back to the source size reported on the last run. Queue once and they fill in.
You're in a batch and the size looks like it came from one frame. It did - the first one. The node reads the tensor shape at indices 1 and 2, so a mixed-shape batch gets image zero's shape.
Your output is slightly off the ratio you wanted. That's multiple doing its job - rounding both axes to a coarse grid moves the ratio a percent or two, which is why the preview prefixes a near-exact ratio with ≈. Drop to 8 when you care. And note that on SDXL, an exact ratio still isn't a trained bucket, so treat the result as a starting point and upscale from there.
You set 2 MP thinking it means "more quality". It means more pixels for a model that may never have seen that size. Past roughly 1.5 MP, SDXL-family checkpoints start doubling limbs and tiling patterns. If the node hands you an unpleasant number, turn megapixels down, not up.
It's a small tool that does one multiplication-and-rounding job correctly, and shows you the answer before you queue instead of after. For a node with no dependencies, that's a fair trade.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| megapixels | FLOAT | 1.000.1–16 | Target area. 1.0 MP = 1024x1024 worth of pixels. |
| multiple | INT | 328–128 | Width and height are rounded to this. Use what your model needs (8 for SD/SDXL, 16 for Flux/Wan, 32 for MiniMax H3). |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |