Image Sizer

Image Sizer solves a specific annoyance: you've picked a target aspect ratio, but you actually want the freedom to flip it between landscape and portrait without recomputing the numbers by hand, and you want the result to land on dimensions your model can actually use - not "1023x577" because that's what the raw math gave you.

Per the README, this node rescales to a target aspect ratio with an explicit orientation, and snaps the result to a given tolerance (a multiple like 16). Here's what that means in terms of the actual fields. original_dimensions is a preset dropdown (the same family used across GR85's resolution nodes - 512x512, 768x768, 1024x1024, and widescreen options up through 1920x1080) that sets the base ratio you're targeting. width and height (both default 1, up to 4096) are the dimensions you're feeding in - presumably your current image's actual size, which the node reshapes toward the target ratio. orientation is an enum with three choices: original (keep whatever orientation your input already has), landscape (force wide), or portrait (force tall) - this is what lets you flip a ratio without manually swapping width and height yourself. tolerance (default 16, range 1–128) is the rounding grid the final numbers get snapped to, so you don't end up with an odd resolution your VAE chokes on.

Output is width and height, both INT, ready for EmptyLatentImage or a resize step.

The orientation toggle is the feature that actually distinguishes this node from just picking a preset directly - without it, switching a workflow from a wide banner shot to a tall portrait means manually swapping every width/height field you touch. With orientation exposed as its own input, you can drive it from elsewhere in the graph (a text-triggered switch, a batch of mixed requests) and let the node handle the swap consistently every time.

Installing it. Search "comfyui_gr85" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/veighnsche/comfyui_gr85

Restart ComfyUI. No model downloads, no extra dependencies.

The tolerance value is the thing to actually think about. The default of 16 is fine for most SD/SDXL work, but Flux specifically wants dimensions divisible by 64 for clean results - if you're targeting Flux, bump tolerance up to 64 rather than leaving the default, or you can end up with a resolution that's "close enough" to a multiple of 16 but not actually clean for that architecture. More generally: the tighter the tolerance, the closer you stay to the exact target ratio; the looser it is, the more the final numbers can drift, so if your output looks slightly off-ratio from what you expected, check whether a loose tolerance is the reason before assuming the node computed something wrong.