Calculate Flux.2 Image Size

Flux.2-era models have opinions about image dimensions. They target around a megapixel of content, and they really don't like resolutions that aren't multiples of 16 - you get latent-size errors, baked-in tiling artifacts, or just an empty latent that shouldn't be. So the standard workflow question is: "what's the best 16-divisible size for a 3:2 image around 1MP?" You can do that math in your head, badly, a dozen times a night. Or you can let Calculate Flux.2 Image Size do it.

Give it a target aspect ratio and a megapixel budget; it returns width and height, snapped to the nearest multiple of 16 so the model actually accepts them. The mechanism is simple: from megapixels * 1,000,000 pixels and the ratio it derives a raw height and width, rounds each to the nearest 16, and clamps to a minimum of 16. The outputs named aspect and megapixels report the actual ratio and pixel count after snapping - because rounding to 16 means you never hit the target exactly, and knowing the real numbers is what keeps downstream math honest.

The inputs and outputs that matter

• aspect_ratio - target width/height, default 1.0, range 0.01–100. 1.5 is 3:2, 0.667 is 2:3 portrait.
• megapixels - pixel budget, default 1.0, range 0.01–16. Stick around 1–2 for Flux.2's native sweet spot; you can go higher, but that's where you're paying for it in VRAM and speed.

Outputs: width (INT), height (INT) - feed these into your Empty Latent, or into a resize node for img2img; aspect and megapixels (both FLOAT) - the post-snap reality check. The width/height are the ones you'll actually wire, usually both at once, so the graph can't drift out of sync.

Where it fits

The honest pitch: it's a convenience node, not a capability node. You could compute 16-multiples in your head or keep a cheat sheet. But when you're iterating - swapping a workflow between 3:2 and 16:9, or batch-testing several aspect ratios - having the two numbers computed from two sliders beats hand-typing four digits, and it keeps the ratio and the resolution linked, so changing one can't silently leave a stale resolution behind. That linkage is the real feature.

Install and gotchas

Part of ComfyUI-TinyBee; one install for all of it:

cd ComfyUI/custom_nodes
git clone https://github.com/TinyBeeman/ComfyUI-TinyBee

or ComfyUI Manager → "ComfyUI-TinyBee" → restart. No models, no dependencies - it's pure math (math.sqrt and a rounding to 16). The gotcha is the snap: the output size is near your target, not equal, and in edge cases (very wide ratios at low megapixels) the nearest multiple of 16 can be a fair bit off - that's what the reported aspect/megapixels are for. If a workflow that worked at 1024 suddenly gets a weird 1040-wide latent, this node is why, and it's doing it on purpose. It's in 🐝TinyBee/Images.