SDXL Resolutions (JPS)

SDXL wasn't trained on "any width times any height you feel like." Stability trained it on a specific shortlist of aspect-ratio buckets, and drift off that list and you start paying for it in warped anatomy, weird horizons, and compositions that look subtly wrong even when you can't say why. This node is that shortlist, turned into a dropdown, so you stop typing guessed numbers into an Empty Latent Image node.

It's about as simple as JPS nodes get. One input, resolution, is an enum with nine entries: the 1:1 square (1024x1024) plus four landscape ratios and their four portrait mirrors - 4:3, 3:2, 16:9, and the wide 21:9, each labeled with its exact pixel dimensions so you're not doing math in your head. These are the real multi-aspect training buckets SDXL shipped with, not someone's approximation. Pick the ratio that matches what you're actually making - square for an avatar, 16:9 for a banner, 9:16 for a phone wallpaper - and the node spits out two plain integers: width and height.

That's the whole mechanism. There's no image processing, no math, no hidden logic - it's a lookup table with a nice UI. The value is entirely in not having to remember (or mistype) nine specific number pairs every time you start a new workflow.

Where it plugs in. Wire width and height straight into your Empty Latent Image node's own width/height inputs, and that's the most common use. But because the outputs are just plain INTs, you can also feed them into JPS's own Resolution Multiply node to get a clean 2x or 4x target for an upscale pass, or into SDXL Recommended Resolution Calc if you're going the other direction - snapping an existing image's dimensions back onto this same list.

Why it matters more than it looks. SDXL's positional encoding was trained specifically against these ratios. Stray far from them - say, a 1920x1080 render because "that's what monitors are" - and you're generating at a resolution the model never saw a matching composition for, which is where the classic symptoms come from: doubled limbs at wide ratios, faces mushed at the edges of extreme crops, that generally "off" feeling. Sticking to the trained list, then upscaling afterward if you need more pixels, is still the standard advice years after SDXL launched, and this node is just a fast way to do that without a cheat sheet taped to your monitor.

Installing it. Either search "JPS Custom Nodes for ComfyUI" in ComfyUI Manager and hit install, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart ComfyUI and it shows up under JPS Nodes/Settings in the node menu. If you've got an old copy of this pack from a previous version, the author is explicit that you should delete it first rather than let two copies collide - the class names will clash otherwise. There's nothing to download beyond the code itself: no checkpoints, no auxiliary models, no heavyweight Python dependencies. It's pure graph logic, so install is genuinely just clone-and-restart.

Troubleshooting. Because there's so little surface area, there's not much that goes wrong here specifically - the failure modes belong to the rest of your graph. The one thing worth flagging: this node only produces two numbers, it doesn't touch your latent. If your output still looks stretched after wiring it up, check that Empty Latent Image is actually reading these outputs and not still holding its own default 512x512 (a classic case of a node looking connected in the graph view while an old cached value is still sitting in the widget). And if you're doing img2img or ControlNet from an existing photo rather than starting from an empty latent, this node alone won't snap that source image onto the grid - pair it with SDXL Recommended Resolution Calc for that job instead.