Megapixel Size
Stop Typing Width and Height — Give the Node a Megapixel Budget Instead
- image
- width
- height
- megapixels
Every video workflow has the same friction point. You load a start image, the model asks for width and height, and now you're doing arithmetic in your head while trying to remember whether this model wants multiples of 16 or 32 or 64. Square off a 3:2 photo and you get a squashed video. Type 1920×1080 because it's the number you know, and you've just handed a 2 MP job to something that wanted one.
Megapixel Size replaces that ceremony with one idea: say how much image you want, let the node keep the aspect ratio of your input, and let it snap both sides to a number the model will accept. Three outputs, no model code, no dependencies. It's the least glamorous node in osiworx-pack and probably the one you'll end up using most.
How it works
Pure arithmetic, and that's the point. It reads the input image's shape, works out the scale factor that lands that aspect ratio on your target area - the square root of target pixels over source pixels - and applies it to both sides. Then it rounds each side to the nearest multiple you picked, floored at one multiple so it can never hand you a zero.
It never looks at a single pixel value. Nothing is resized, cropped or resampled, and the image doesn't come out the other side. The node reads the shape and hands you three numbers.
A few examples straight from the pack's test suite, so you know what "near" means here:
- 1024×1024 at 1.05 MP with multiple 32 →
1024 × 1024(the H3 workflow's exact setup) - 512×512 at 1.0 MP with multiple 16 →
1008 × 1008 - 1920×1080 at 1.0 MP with multiple 32 →
1344 × 736
That last one is the useful sanity check: 16:9 stays 16:9-ish, the area lands on target, and both sides divide by 32.
The three inputs
image- your source. Only its dimensions matter, so aLoad Imageoutput is fine.megapixels- target area in millions of pixels, 0.05 to 16, step 0.05. Pick from the model's native band rather than a "nice" number: most 2026 image models sit around 1–2 MP and degrade softly above that, while video models are happier at 1 MP or under unless you have the VRAM. The default of 1.0 is a sane start.multiple- 8, 16, 32 or 64, default 16, which covers most video VAEs. Set it to 32 for MiniMax H3, which works on 32-pixel tokens (a 16× VAE times a 2×2 patch); the default 16 can produce a size H3 doesn't divide evenly. 64 is the Flux-family habit.
The three outputs
width and height are INTs - wire them into the H3 node's width/height fields, or EmptyLatentImage, or whatever your video sampler wants. megapixels is a FLOAT: the actual area after rounding, not what you typed. Use that downstream instead of assuming your 1.0 became exactly 1.0 (with multiple 32 on a 16:9 source, it didn't).
Install
It ships in osiworx-pack, in the wos module. Same install as the rest of the pack:
cd ComfyUI/custom_nodes
git clone https://github.com/osi1880vr/osiworx-pack
Restart, search "Megapixel Size", and it appears under osiworx/image. No pip dependencies, no model files - a couple of dozen lines of Python with a plain unit test in the repo that runs without ComfyUI or torch. Unusual for a pack this experimental.
Where it goes wrong
The default multiple is wrong for H3. The author calls this out in the README instead of quietly changing the default, which is either admirable or annoying depending on your patience. Doing H3 image-to-video? Set 32 manually.
Small source images drift on aspect. Rounding error is a fixed number of pixels per side - negligible at 1920×1080, very much not negligible if you feed it a 400×60 crop. The pack's own tests only assert aspect stays within 8% when the short side is over 500 pixels. The author knows exactly where the weak spot is.
It doesn't give you trained aspect ratios. If you want SDXL's 1216×832 or a model's blessed buckets, this isn't that node. It gives you your source ratio at your target area, snapped. Great for keeping the framing you started with; useless for enforcing a canonical ratio.
The image doesn't pass through. Easy first-build mistake: you wire your Load Image in, then look for the IMAGE output, and there isn't one. If you also need it resized, that's a separate ImageScale fed from the same width/height outputs.
The widget won't take a silly number. The range is 0.05 to 16 MP in steps of 0.05, so you can't accidentally ask for a 0.01 MP thumbnail and spend ten minutes wondering why your video is 100 pixels wide.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| megapixels | FLOAT | 1.000.05–16 | Target area in millions of pixels (width * height / 1,000,000). |
| multiple | COMBO | 16 | Round width and height to this multiple. 16 is the usual video latent step. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |
| megapixels | FLOAT | — |