Resize To Megapixels

Resize To Megapixels answers the question "what resolution should I use?" the way your GPU actually thinks about it: as a total pixel budget, not as a width and height. You hand it a target megapixel count - say 1.0 for SDXL-class work or 0.5 for something lighter - plus an aspect ratio from a source width/height, and it hands back concrete dimensions that hit that pixel count.

Why think in megapixels at all? Because the thing that matters for VRAM and generation quality is roughly how many pixels you're asking the model to paint, and that number is what stays comparable across different aspect ratios. A 1024×1024 image is 1.05 MP; a 1344×768 image is also about 1.03 MP. Thinking "I want around a megapixel" is more honest than remembering a dozen resolution presets. This is the same reasoning the upscaling world uses, where the community routinely talks about target resolutions in megapixels rather than raw dimensions.

There's an important word in the name though: it calculates dimensions, it doesn't resize any pixels. There's no image input. You feed it numbers, you get numbers out, and you wire those into an Empty Latent Image, a VAE encode, or a resize node. Pure math node.

How it works

It preserves your aspect ratio (width ÷ height), computes the dimensions that land on the target pixel count, then rounds each side to the nearest multiple_of. That last part matters a lot: latent space is quantized, and most diffusion backbones want dimensions divisible by 64 (SD 1.5 and SDXL) or at least 16 (Wan, Flux). The rounding is where "approximately your megapixels" becomes "exactly a number the sampler will accept."

One behavior to note: the multiple_of rounding can push the actual result a bit above or below your target. It's not going to clamp to exactly 1.0 MP - it's going to give you the nearest multiple of 64 that's close to 1.0 MP. That's the right tradeoff.

Inputs and outputs

• width (INT) and height (INT) - your source aspect ratio. Defaults 1024×1024.
• megapixels (FLOAT) - the pixel budget, 0.1 to 100. This is the number you actually care about.
• multiple_of (INT) - rounding granularity. Keep 64 for SD-lineage models; you can drop it to 16 for Flux/Wan-style models if you want finer control.

Outputs:

• adjusted_width (INT)
• adjusted_height (INT)

Wire those into an Empty Latent Image and you've got a resolution that's always the right size for whatever aspect you picked.

Installing it

It's part of ComfyUI Fictiverse Nodes. Easiest: ComfyUI Manager → search "ComfyUI Fictiverse Nodes" → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/Fictiverse/ComfyUI_Fictiverse

No dependencies, no models, Apache 2.0. Pure integer math.

Common issues

Pack-level, the usual: the folder must be named exactly ComfyUI_Fictiverse, or you'll see ModuleNotFoundError: No module named 'custom_nodes.ComfyUI_Fictiverse' and the node won't appear. Rename, restart.

Node-level, the thing people trip on is forgetting this node doesn't touch an image - it's easy to wire an IMAGE into it out of habit and get a type error. It takes integers and gives integers. And remember the multiple_of rounding: if you set multiple_of to 1 and ask for an exotic aspect ratio, you can get a dimension that's off the divisibility grid, which some models will reject or produce tiling artifacts on.