DaSiWa Resolution Scale Calculator

Video models like WAN and LTX care about total pixel count more than raw width and height - feed them a resolution with the wrong aspect ratio at a "safe" pixel budget and you can still blow your VRAM, because area, not either dimension alone, is what predicts memory use. This node exists to compute the right width/height pair for a target megapixel budget, at whatever aspect ratio you're actually working with, and to snap the result to whatever grid your model requires.

How it works

The core idea, straight from the README, is a Constant-Area Square-Root method: instead of picking dimensions by eyeballing a resolution list, it solves for the width and height that hit your target pixel area while preserving a given aspect ratio. That's what keeps GPU memory usage predictable across wildly different aspect ratios - a 21:9 output and a 9:16 output at the same megapixel target land on roughly the same VRAM footprint, which a naive "just pick 1920x1080-ish" approach doesn't guarantee.

resolution_preset is one dropdown covering both worlds: standard p targets (144p through 2160p/4K) for people thinking in familiar terms, and dedicated megapixel tiers for people who actually care about the underlying math (the default, 0.52 MP - SD, is one of the latter). scale_from_image decides where the aspect ratio comes from: on (default), it reads the aspect of whatever's wired into the optional image input; off, it falls back to aspect_preset_when_not_image (six named ratios plus CUSTOM) so the node works with nothing but presets when you don't have a reference image yet, like at the very start of a text-to-video graph.

mode is the part that actually matters for video models specifically. Standard does pure math with no snapping. WAN/LTX (Div32) snaps every dimension to a multiple of 32 - this isn't a nice-to-have, LTX-2.3 explicitly requires width and height divisible by 32 or the run fails outright rather than silently rounding. LTX 2-Stage (Div64) snaps to 64 for two-stage pipelines. CUSTOM lets you set your own custom_divisor for anything else with its own grid requirement.

no_scale is the escape hatch: flip it on and every bit of the math above is skipped, the node just passes through the connected image's actual dimensions.

The inputs and outputs that matter

• resolution_preset and mode are the two dropdowns you'll actually touch on a normal run.
• scale_from_image + optional image - leave this on if you have a reference/init image and want the output aspect to match it exactly.
• custom_aspect_width / custom_aspect_height and swap_aspect_when_not_image - only matter when scale_from_image is off.

Four outputs: width_int / height_int (wire these into your KSampler's latent, or a resize node) and width_float / height_float (for nodes that expect a float, saves you a type-cast node).

How to install it

ComfyUI Manager - search DaSiWa-Nodes, install, restart. Manual: clone into custom_nodes, pip install -r requirements.txt, restart. Pure math node, zero dependencies beyond what ComfyUI already ships.

Common issues & troubleshooting

LTX or WAN generation fails immediately with a dimension error. Almost always means mode was left on Standard when it should've been WAN/LTX (Div32) - the model rejects off-grid resolutions rather than rounding them for you, so the snap has to happen upstream, at this node.

Output resolution doesn't match what I expected from the preset. Remember the preset is a target, not a guarantee - the actual output gets adjusted to satisfy both your aspect ratio and the chosen divisor, so the final numbers can land slightly off the nominal preset value. That's expected behavior, not an error.

Aspect ratio looks wrong even with an image connected. Check scale_from_image is actually on - it's easy to leave it off from a previous CUSTOM-aspect experiment and forget it's silently ignoring your connected image.