Aspect Ratio Calculator

Feed a diffusion model an off-ratio image and you get the classic tells: double heads, stretched limbs, a composition that looks like it was generated for a different aspect ratio and cropped after the fact - because it was. Models are trained on a handful of specific aspect ratios, and drifting away from them is one of the more reliable ways to get garbage. This node exists to stop that before it happens: give it the width and height you've actually got, and it tells you which "known good" ratio your source is closest to, plus the pixel dimensions to crop or resize it to.

What it's for

Think of it as the decision step that goes before an image resize or crop node, not a replacement for one. It doesn't touch pixels itself - both its required inputs, width and height, are plain integers, not an image. In practice you wire in the dimensions of whatever you're about to process (from a Get Image Size node, say), and it hands back the target width/height to crop or resize toward. This matters specifically because SDXL, Flux, and friends were trained on a short list of aspect ratios - SDXL's is roughly 1024x1024, 1152x896, 1216x832, 1344x768, 1536x640 and their rotations - and generating (or even img2img-ing) way outside that list is where the "why does this look warped" complaints usually trace back to.

How it works

You give it a width and height (both default to 1024, but you'll normally override them from upstream). It then checks that pair against whichever standard ratios you've left switched on: use_1_1, use_2_3, use_3_2, use_4_3, use_3_4, use_16_9, use_9_16 - all seven default to on, so out of the box it's comparing your image against the full common set. If none of those fit what you need, custom_ratios takes a string for your own list. And if you already know exactly which ratio you want and don't want the node guessing, force_aspect_ratio_width / force_aspect_ratio_height (both default -1, meaning "let the node decide") let you pin it directly - set them to, say, 16 and 9 and it skips the comparison entirely.

Outputs

Four, all INT:

• width / height - the actual target pixel dimensions to crop or resize your source to.
• aspect_ratio_width / aspect_ratio_height - the ratio it matched, as the raw numerator/denominator (e.g. 16 and 9), separate from the pixel values above. Handy if you want to log or display which bucket got picked, or feed it into a second node that just needs the ratio, not the resolution.

Wire width/height straight into whatever does the actual crop or resize in your graph - this node is pure decision-making, no image processing.

Installing it

The README is deliberately thin - just the pack name and a one-line description - which tells you something useful on its own: there's no requirements.txt called out, no model to download, nothing GPU-related. It's arithmetic against a list of ratios. Install via ComfyUI Manager: search optimal-crop-resolution, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/hodanajan/optimal-crop-resolution

Restart ComfyUI and it'll show up under image/resolution.

Where people get tripped up

Because all seven standard ratios default to on, the node will happily match against a portrait ratio when you were expecting landscape, or vice versa, if your source dimensions are ambiguous (close to square, for instance). If you keep getting a ratio you didn't want, don't fight it - either flip off the ones you don't want considered, or skip the guessing entirely with force_aspect_ratio_width/height. And remember this node only calculates; if your actual crop or resize node downstream isn't wired to its width/height outputs, changing this node's settings won't do anything visible - a surprisingly common "why isn't this working" moment with decision-only nodes like this one.