Nodes/ComfyUI_EmAySee_CustomNodes/EmAySee Megapixel Image Resizer
ComfyUI Node

EmAySee Megapixel Image Resizer

Scale to a target megapixel count, not a fixed resolution

By EmAySee·Created about a year ago·Updated 4 months ago· 2
EmAySee Megapixel Image Resizer
  • image
  • IMAGE
  • width
  • height
  • actual_mp
target_megapixels1.0
multiple_of8
methodbicubic

EmAySee Megapixel Image Resizer answers a question ComfyUI's built-in scale node can't: "make this image roughly this many total pixels, whatever its aspect ratio." Instead of telling it a width and height, you tell it a target in megapixels and it figures out the dimensions that get you there while preserving the aspect ratio. That's genuinely useful, and it's a pain to do with stock nodes.

The case that made me install it: you're batching images of wildly different shapes through a model that cares about total resolution more than exact dimensions. SDXL wants to live around a megapixel. Flux-class models have sweet spots. When you're upscaling or conditioning a mixed batch, "hit about 1.0–1.5MP with a consistent total pixel budget" is the real requirement, and this node turns that sentence into a parameter. The author built it for exactly this kind of pre-processing, and it sits naturally next to the pack's Qwen image-prep nodes in a pipeline.

How it works

It computes the input's aspect ratio, derives the dimensions that would give you your target pixel count at that ratio, then snaps both dimensions to a multiple of your choosing. The snap is the part that matters - models and latents work much better on multiples of 8 or 64, so a naive sqrt(pixels * ratio) resize leaves you with an awkward 1097×731 that the VAE will groan at. With multiple_of set to 8 you get a clean 1088×728, and the node tells you exactly what it produced.

There's a small honesty built in: since snapping changes the pixel count slightly, the actual_mp output reports what you actually got, not what you asked for. Rounding to the nearest multiple means you land as close as possible, sometimes a hair over, sometimes a hair under.

The inputs that matter

Four inputs, two you'll set:

  • image - the IMAGE to resize.
  • target_megapixels - float from 0.1 to 64, default 1.0. This is the dial. 1.0 ≈ SDXL's native territory; go up for hi-res passes.
  • multiple_of - integer from 1 to 64, default 8. Snap factor. 8 for most things, 16 or 64 if you're feeding a strict VAE.
  • method - nearest-exact, bilinear, area, bicubic (default), or lanczos. One caveat straight from the code: lanczos is silently mapped to bicubic under the hood, so don't pick it expecting a magic quality win.

Outputs: the resized IMAGE, plus width and height as INTs and actual_mp as a FLOAT. Those last three are handy when you want to feed the resulting resolution into a latent size or a prompt without hard-coding it.

Installing it

Part of the EmAySee pack:

# ComfyUI Manager: search "ComfyUI_EmAySee_CustomNodes" and install
# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes

Restart ComfyUI. No requirements.txt, no pip step - just torch and ComfyUI internals, plus the pack's startup banner.

Common issues

The realistic gotchas are all about the snap. If multiple_of is large and your target is small, rounding to the nearest multiple can push you noticeably off target - that's what actual_mp is for, so read it before you trust the output. And because it preserves aspect ratio and then snaps, extremely wide or tall images can end up with one dimension that looks arbitrary; if you need exact dimensions, this isn't the node. For "give me a consistent pixel budget," it's the right tool, and the actual_mp output makes it honest about what you got.

CategoryEmAySee/Image

Inputs (4)

NameTypeDefaultDescription
imageIMAGE
target_megapixelsFLOAT1.00.1–64
multiple_ofINT81–64
methodCOMBObicubic5 options: nearest-exact, bilinear, area, bicubic, lanczos

Outputs (4)

NameTypeDescription
IMAGEIMAGE
widthINT
heightINT
actual_mpFLOAT