AnyAspectRatio
Turn a megapixel budget into width/height for any ratio
- width
- height
This is a math node, not a generator - it doesn't touch pixels at all. You give it an aspect ratio and a target size, and it hands back a width and height you plug into your Empty Latent Image (or anywhere else that wants dimensions). The point is that SD models don't take "16:9" as an input, they take pixel dimensions, and getting from a ratio to dimensions that are both correct and divisible by whatever your model needs (usually 8 or 64) is fiddly enough that it's worth a dedicated node instead of doing the arithmetic by hand every time.
How it works
It computes a target pixel count from a square of your chosen side length (side_length²), then redistributes those pixels across your ratio: width = sqrt(total_pixels × width_ratio / height_ratio), and height the mirror of that. Both results get floored down to the nearest multiple of rounding_value. So a 1024 side length with 16:9 and the default 64 rounding gives you a genuinely 1-megapixel-ish image at a proper 16:9 shape, with dimensions your model won't choke on. Change the ratio and the total pixel budget stays roughly constant - that's the actual point of the node, keeping compute cost stable while you explore different shapes.
The inputs and outputs that matter
width_ratio/height_ratio(defaults 16 / 9) - your aspect ratio, as two integers. 1:1, 4:3, 21:9, whatever you want.side_length(default 1024) - the size of the reference square this all scales from. The README is blunt about this one: 1024 with 64 rounding is Stability's own recommendation for SDXL, and if you're on SDXL you shouldn't touch it. Drop to 512 for SD 1.5, or match whatever your specific model was trained at (768 for some SD 2.1 checkpoints, for example).rounding_value(default 64) - the multiple your final dimensions get rounded to. Leave this alone unless you know your architecture's specific divisibility requirement is different.- Outputs are
widthandheight, both plain integers - wire them into your Empty Latent Image's width/height, or anywhere else expecting an INT dimension.
The README's own closing note is basically a warning wrapped in a joke: you can crank the ratio or side length to something absurd, and the node will happily compute it, but that doesn't mean the resulting shape will generate anything coherent.
How to install it
ComfyUI Manager: search "comfy_PoP", install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/picturesonpictures/comfy_PoP
No dependencies beyond what ComfyUI already has - it's pure arithmetic, nothing to download.
Common issues & troubleshooting
Generated image has duplicated limbs, tiling, or weird anatomy at an "unusual" ratio. This isn't the node's fault - every model has a native resolution and trained aspect-ratio range, and pushing far outside it (especially at extreme ratios like 21:9 or thinner) is a well-known way to get exactly this failure mode, independent of which node computed your dimensions.
Output looks stretched. SDXL specifically was trained on a fixed set of aspect ratios (1024×1024, 1152×896, 1216×832, 1344×768, 1536×640, and their rotations) - landing outside those bucket ratios, even with technically-correct pixel math, can still produce stretching. If you're chasing a very specific unusual ratio on SDXL, expect some quality trade-off; it's the model, not this node's arithmetic.
Numbers don't look "round." That's the rounding step working as intended - it floors to the nearest multiple of rounding_value, so your exact target pixel count will drift slightly from a pure ratio calculation. That's the price of getting dimensions your model can actually use.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| width_ratio | INT | 161–4096 | — |
| height_ratio | INT | 91–4096 | — |
| side_length | INT | 10241–4096 | — |
| rounding_value | INT | 641–4096 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |