Mpi Round To Multiple Res

Every model has a resolution step it expects: SD 1.5 wants multiples of 8, SDXL and Flux want 16, most video models want 32. Feed one side a dimension that doesn't divide, and you get errors or a silently shifted frame. MpiRoundToMultipleRes is the both-sides version of MpiRoundToMultiple - it takes a width and height, snaps each to a common multiple, and hands back a resolution the model will actually accept.

The reason this exists as its own node rather than two copies of the single-value version is that resolutions travel as pairs. You read an image's size, or compute a target from an aspect ratio, and you need both sides cleaned at once - wiring two separate rounding nodes and keeping their multiple_of in sync is exactly the kind of duplication that drifts. One node, four widgets, both sides consistent.

How it works

Same floor/ceil math as its single-value sibling, applied twice:

• width, height - the numbers to snap.
• multiple_of - the base (default 64, range 1–1024).
• round - the up/down toggle. Checked is up (ceil), unchecked is down (floor), default down.

Each dimension is rounded independently, so 1000×750 with multiple_of = 64 floors to 960×704 - that's what the "Res" version is for: you get a valid pair, not just two valid numbers. Outputs are width and height as separate INT sockets, ready to wire into an Empty Latent Image or a video node's resolution input.

Install

Ships with ComfyUi-MpiNodes. ComfyUI Manager → search "MpiNodes" (or publisher "mad-pony-interactive"), or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

Restart after installing. Zero extra dependencies or model files - this node is arithmetic, not machinery.

The context that makes it click

Where this earns its keep is in chains. Feed it the scaled_width/scaled_height out of MpiScaledDimensions (which gives you a proportional but unrounded size) and you get a resolution that's both the right aspect and divisible by the model's stride. It's also quietly useful before video encoding - libx264 wants even dimensions, so snapping video frames to a multiple keeps the encoder happy without the extra crop step. The round direction question is the same one as the single-value node: floor to stay inside a model's max, ceil when you need to fill the frame. Pick deliberately, because "round" here is floor/ceil, not nearest.