Image Resize Calculator

Some nodes care about dimensions; some care about pixel count. When you're feeding an upscaler a cap, tiling an image into GPU-sized chunks, or budgeting VRAM for a ControlNet pass, what you actually want is "largest size that keeps my aspect ratio under X megapixels." That math is annoying enough to do by hand and genuinely easy to get wrong, so this node exists: three ints in, two ints out, no decimals, no rounding surprises.

How it works

Give it the original width and height plus a target total pixel budget (num_pixels). It computes the aspect ratio, finds the largest integer width/height whose product stays at or under the budget, and returns those. If the original already fits the budget, it returns the original dimensions untouched - no pointless downscale.

The implementation is just careful integer math with a verification loop, so the result is guaranteed to satisfy width_max * height_max <= num_pixels. No floor-division drift, no off-by-one that silently produces a 1-pixel-over-limit image.

Inputs

• width / height - the original dimensions (defaults 1024×1024).
• num_pixels - the cap, as a total pixel count. Default 1048576 = 1024² = 1 megapixel. The max is 4096² (16.7M).

Outputs

width_max and height_max - wire both into a scale/resize node's width and height inputs (e.g. ImageScale or an upscaler that accepts explicit target dimensions). The two outputs are always consumed together; mixing one with a different source is how you get weird aspect ratios.

Install

Standard pack install - ComfyUI Manager (search "ComfyUI-AutoFlow") or:

cd ComfyUI/custom_nodes
git clone https://github.com/ZXL-Xinram/ComfyUI-AutoFlow

Restart after. It's pure Python + the math module, so there are zero extra dependencies - this is the lightest node in the pack.

Where people get burned

• Confusing it with a resize node. This computes; it doesn't transform. Nothing comes out of it except two numbers. If you expected a resized image, you're looking at the wrong node - put a scale node after this.
• Forgetting it preserves aspect ratio. If you want a specific width and let height follow, that's a different job. This node is only about the total-pixel budget.
• Huge budgets on tiny images are a no-op - and that's correct behavior, but it means the outputs will equal the inputs, which can look like a bug if you expected scaling.

For the beginner, this is one of those "you'll be glad it exists once" utilities: budget-driven resizing is exactly the kind of fiddly, easy-to-screw-up calculation that a tiny dedicated node removes from your mental load. It's also the kind of node that only makes sense inside a specific workflow - which is why it's part of a pack rather than a headline feature.