LC Image to Total Megapixels 📐

Sizing by megapixels is the one resize philosophy that doesn't fight you. Picking 1024×1536 by hand means reasoning about aspect ratio, VRAM, and whether your model's VAE divides cleanly by eight. Picking "1.0 MP" means the image keeps whatever shape it already had and you just decide how many total pixels to spend.

This is the same scaling rule as core ComfyUI's Scale Image to Total Pixels - 1.0 MP is counted as 1024×1024 pixels - with two additions: sizes snap to a resolution_steps multiple, and the node hands you back the actual resolution and megapixel count it landed on. That second output is the point. Rounding to steps always nudges the real number, and this node stops you guessing what it nudged to.

How it works

It's short and honest. Take the target megapixels, multiply by 1024², divide by the image's current pixel count, square-root that for a linear scale factor, multiply width and height, round each to the nearest multiple of resolution_steps, then hand it to comfy.utils.common_upscale - ComfyUI's own resampler, so the upscale_method choices behave exactly like the core node's.

Then it measures the result: resolution is the longer side in pixels as an integer, and megapixels is the actual pixel count divided by 1024², rounded to two decimals. Round to a step and you land somewhere slightly off 1.0 MP - and you'll see that instead of troubleshooting a mismatch three nodes later.

Inputs and outputs

Four inputs, and two of them are the decision.

image in. megapixels is the target, 0.01 to 16, default 1.0 - remembered at 1024×1024 per MP. resolution_steps rounds width and height to a multiple of that number: 1 is off, 8/16/32/64 is what you want for models that are picky about latent divisibility. upscale_method picks the filter - lanczos (the default, and the right answer for downscaling), bicubic, bilinear, area, nearest-exact. Reach for area when you're shrinking a batch hard and want no ringing; reach for nearest-exact only for pixel art.

Outputs: image, resolution (INT, longer side), megapixels (FLOAT, actual). Both numbers are useful downstream - resolution is handy for a text overlay, a filename, a save-metadata node, or a log you can actually read.

Install

Manager → ComfyUI LC123 Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC123_nodes.git

Restart. This one is a single class with no dependencies beyond comfy.utils - import math and done. No requirements.txt, nothing to pip install.

Common issues

"My 1.0 MP came out 1016×1016-ish, not 1024×1024." Check resolution_steps. With steps at 64 you're rounding to the nearest 64, so you can't land exactly on 1024 unless the aspect worked out. That's the trade, and it's why the node reports back - read resolution instead of assuming.

The image got smaller and I expected bigger. It's a target, not a scale factor. Feed it a 4 MP image and ask for 1 MP and it will happily shrink it. Useful, actually: Comfy Org's own February 2026 handbook recommends downscaling to 0.35 megapixels before a SeedVR2 upscale, on the logic that a soft source has no detail at full resolution to recover, so you drop it to match its real sharpness and let the model rebuild.

All my images came out the same size but different aspect ratios. That's correct. Megapixels preserve each image's own ratio; if you want one fixed shape, use the pack's Aspect Ratio Simplifier instead. Two different jobs, two different nodes.

Upscaling broke a generation. This node resamples pixels - it doesn't add detail. Generating above a model's native resolution is a known source of tiling and duplicated anatomy, and no resize node fixes that; you fix it with a second pass at low denoise, or by generating at native resolution and upscaling after.

CRT-ish ringing or shimmer on fine lines after a big shrink. You're on bicubic. Use area for heavy downscales and lanczos for everything else.