MOSS DyPE-M Resolution (MP)

This is the least glamorous node in the pack and the one you'll end up using on every workflow anyway. It converts "6 megapixels at 3:2" into actual width and height numbers that MOSS-Image will accept, and it tells you what you actually got after rounding.

Why it exists

High-resolution generation talks in megapixels, but every ComfyUI latent node wants two integers. Doing the arithmetic in your head gets you sizes like 3000×2000, which is fine until something downstream rounds it - and here something does. MOSS-Image works on 16-pixel patches, so the pack's own scale calculation divides your canvas by the patch size. Odd dimensions don't crash anything; they just drift from the resolution you thought you asked for. 3000 rounds to 3008. Your "6 MP" render is 6.016 MP and nobody told you.

That matters more than usual in this pack because the sibling MossDyPEPatch derives its extrapolation strength from the latent extent. Deliberate, 16-aligned canvases keep your testing honest - otherwise you're changing two variables at once and blaming the sampler.

What it does

Two inputs. aspect_ratio is width/height as a plain float - 1.0 is square, 1.5 is landscape 3:2, 0.667 is portrait. It is not a dropdown of common ratios, so portrait means a number below 1, which trips up roughly everyone the first time. megapixels is the total pixel budget.

The math is straightforward: take the square root of the budget over the aspect, snap that to the nearest multiple of 16, multiply back out. Three outputs - width, height, and actual_megapixels, which is the truth after rounding rather than the number you typed.

Some real numbers, so you know the shape of the drift:

| input | output | actual | |---|---|---| | 1.25 AR, 8.19 MP | 3200×2560 | 8.192 MP | | 1.0, 8 MP | 2832×2832 | 8.020 MP | | 1.5, 6 MP | 3008×2000 | 6.016 MP |

That first row isn't a coincidence - 1.25 at 8.19 MP reproduces the exact 3200×2560 canvas the pack's README benchmarks on, which makes this node the fast way to rebuild the author's test setup.

Wiring it up

width and height go straight into whatever makes your empty latent - in the pack's example workflow that's EmptyFlux2LatentImage, and MOSS-Image follows the same shape. actual_megapixels is the odd one out: nothing in the pack consumes it. Feed it into a display or note node if you want to see it, or ignore it. It's there for sanity-checking, not for driving anything.

Note that this node does not connect to MossDyPEPatch - the patch takes no resolution input, it reads the latent at sample time. You set your canvas here, you set your strength there, and they meet at the sampler.

Install

It ships in the same pack as the patch node, so there's nothing separate to do:

comfy node install comfyui-mossdype

Or clone into ComfyUI/custom_nodes/ and restart. No dependencies, no models to download - this node is pure arithmetic and works whether or not you have a MOSS-Image checkpoint anywhere on disk.

The one gotcha

The whole pack is registered under model/patch/moss_image, including this one. A pure math node filed under a model-patching category is a filing quirk, not a bug, but it means right-click → Add Node → browse by category will put width-and-height arithmetic somewhere you weren't looking. Double-click search for "MOSS DyPE-M Resolution" and move on with your life.

The other thing to internalize: 6 MP at 3:2 is not 3000×2000, and if you care about matching a previous render exactly, let the node produce both numbers instead of typing one of them. Reproducibility is a choice you make before the first run, not a thing you fix afterward.