Elegant Resolution Selector
Pick a shape, keep the pixel count
- width
- height
The single most common way to wreck a generation is to change the aspect ratio and forget the pixel count. Go from 1024×1024 to 16:9 by typing 1920×1080 and you've handed an SDXL checkpoint roughly twice the pixels it was trained on, at a ratio it has never seen. You get stretched bodies, doubled heads, or a tiled mess. This node exists so that changing shape doesn't change size.
What it does
Elegant Resolution Selector gives you a width and a height from an aspect ratio, holding the pixel count at whatever a base × base square would be. Pick 16:9 at base 1024 and you get 1360×768 - still about 1 megapixel, just wider. It's a value node in the plumbing sense: it outputs two INTs that you wire into Empty Latent Image, or into an image-scaling node, or anything else with width and height sockets.
It ships in Elegant Nodes by wipeer, a small utility pack built so its nodes stay usable from the subgraph node. Promote any of this node's widgets and the result line shows on the subgraph node itself, updating live as you change them - which is the point, because a resolution picker buried inside a collapsed subgraph is otherwise blind.
Resolution selectors are a crowded category - half a dozen exist, including a well-liked one that reads an editable presets file. This one's angle isn't presets; it's fixed-megapixel math and zero setup.
The mechanism, briefly
Width is base × √ratio and height is base ÷ √ratio, each rounded to the nearest multiple of round_to. That's it. Because the two are reciprocal, area stays near base² whatever ratio you pick - exactly what the training-bucket problem wants: same pixels, different arrangement.
aspect_ratio offers 1:1, 5:4, 9:7, 4:3, 3:2, 16:9 and 21:9; in portrait the list shows them flipped, so you'll see 4:5 and 9:21 instead. orientation is the landscape/portrait boolean and has no effect at 1:1.
base is the side of the equivalent square, and it's your lever for total pixels: 1024 puts you at roughly 1 MP for every ratio, the sweet spot for SDXL and the Flux generation of models; 512 is the SD 1.5 equivalent. Bump it for 4K-bound work, drop it for drafts.
round_to is the one people ignore and then wonder why things look odd. Latent models downsample by 8, so 8 is the floor. 16 suits Flux and SD3-family models. And 64 matches SDXL's training buckets - this is the setting worth actually changing, because the math then snaps onto real buckets:
base 1024, round_to 16 → 4:3 1184 × 880 16:9 1360 × 768 21:9 1568 × 672
base 1024, round_to 64 → 4:3 1152 × 896 16:9 1344 × 768 21:9 1536 × 640
Those right-hand numbers - 1152×896, 1344×768, 1536×640 - are three of SDXL's trained aspect ratios, the ones the KB's resolution notes tell you to generate at. So the honest configuration for an SDXL checkpoint is base 1024 with round_to 64 - and the node quietly turns "16:9" into a bucket the model actually knows. For Flux, leave it at 16.
There's also a live, read-only readout on the node showing what you've got - something like 1360 × 768 · 1.00 MP · 1.77:1 - with the ratio recomputed after rounding, so if the rounded numbers drifted off your intended ratio, you can see it instead of discovering it in the output.
What you wire it into
width and height (both INT) go to Empty Latent Image first and foremost, which is the whole workflow for most people: convert the width and height widgets on Empty Latent Image to inputs, wire these two outputs, and changing the shape of your generation is one dropdown instead of two numbers you have to get right.
They're plain integers, so they also feed an image-scale node on a hires-fix pass, or a thumbnail node in a batch.
Install
Manager: search Elegant Nodes and install. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/wipeer/comfyui-elegant-nodes.git
pip install -r comfyui-elegant-nodes/requirements.txt
Restart ComfyUI and refresh the browser. No models, no downloads beyond the simpleeval package ComfyUI already has. It's in utilities → elegant.
Gotchas
The pack needs ComfyUI 0.4.0 or newer - it's built on the V3 node API and old builds won't load it. If a workflow shows a missing node where this should be, it's the 1.0.0 rename: this node used to be called plain Elegant Resolution. Swap it in and rewire.
The real limitation is one of ambition: the ratio list is a generic, human-friendly set, not a per-model table. It lands on SDXL's buckets at round_to 64 and keeps you in the 1–2 MP band 2026 models want, but it doesn't know that Anima looks most coherent at 1280 or that HiDream-O1 insists on 2048² and produces noise at 1024. For those, type the numbers yourself.
And if you're after 16:9 output on an SDXL checkpoint, remember the KB's advice is still the advice: generate at the trained ratio, then upscale and crop. A resolution selector makes the good size easy to find. It doesn't make the model tolerate the bad one.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| aspect_ratio | COMBO | 1:1 | Aspect ratio. Shown flipped (e.g. 2:3) in portrait. |
| orientation | BOOLEAN | true | Landscape: wider than tall. Portrait: taller than wide. No effect at 1:1. |
| base | INT | 102464–16384 | Side of the square (1:1) image. Other ratios keep about the same pixel count: 1024 gives about 1 MP for every ratio. |
| round_to | COMBO | 16 | Width and height are rounded to a multiple of this. 8 is the minimum for latent models, 16 suits Flux/SD3, 64 matches SDXL training sizes. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |