Nodes/ComfyUI-ResolutionHelper/Resolution from Dimensions
ComfyUI Node

Resolution from Dimensions

1080p Means 1080p's Worth of Pixels, Not 1920x1080

By AlfredSartan572·Created 29 days ago·Updated 7 days ago· 1
Resolution from Dimensions
    • width
    • height
    • longest
    • megapixels
    ◄width—►
    ◄height—►
    ◄scanlines▾►
    ◄multiple32►

    You have a source resolution and you want it at "720p" or "1080p" without stretching it into a ratio it was never in. That's what Resolution from Dimensions is for. Feed it the width and height you've got, pick a vertical resolution off a dropdown, and it hands back the pair of numbers that keeps your aspect ratio and gives you that resolution's worth of pixels.

    The author's own framing is the important bit, and it's what most people get wrong: picking 1080p does not output 1920x1080. It gives dimensions with the same pixel count as 1920x1080 (2,073,600 of them), shaped to your source. A square 1024x1024 becomes 1440x1440. 1080p is a budget, not a canvas.

    How the math actually works

    The source (resolution_nodes.py) is 340 lines of pure Python - import math and nothing else - and this node's function is six lines of it. It computes:

    scale = math.sqrt((scanlines ** 2 * 16 / 9) / (height * width))
    

    That numerator is the pixel count of a 16:9 frame at your chosen scanline height (1080² × 16/9 = 2,073,600, i.e. exactly 1920x1080's pixels). Divide by your source's area, square-root it, and you have the scale factor that lands your image at that pixel total. Your width and height get multiplied by it, then floored down to the nearest multiple of multiple.

    That floor is where all the drift lives.

    Inputs that matter

    width and height are plain INTs, 8 to 7680. Note there's no default value set for either (the author commented the defaults out), so a freshly dropped node sits at the slider minimum until you type something real in. There's no image input here - this node is for when you know the numbers. Want it to read your actual image instead? That's ResolutionCalculator, same pack.

    scanlines is the one you'll actually enjoy: 20 entries from 240p through 720p, 1080p, 1440p, 2160p up to 4320p. Video-language resolution naming, which is the point - the author wrote the pack because most pickers want megapixels or a preset ratio, and nearly all of them skip 16:10.

    multiple defaults to 32, range 1–112, with the author's tooltip as the guide:

    • MiniMaxH3 = 32 - the 2026 open-weights video model wants a coarser latent grid
    • Illustrious / Pony = 8 - the SDXL anime family, so leave it at 8 and stop losing rows
    • everything else = 16

    multiple = 1 turns snapping off entirely. You almost never want that - the VAE compresses 8x per side, and off-grid sizes bite you later.

    What comes out

    Four outputs, all useful. width and height go straight into an EmptyLatentImage, an ImageScale, or a second-pass node - anywhere a width/height socket exists. longest is the bigger of the two, for nodes that want a single edge length. megapixels (FLOAT) chains beautifully into Resolution from Megapixels from the same pack if you want to re-shape the result against a different aspect ratio.

    One quirk worth knowing: megapixels is computed as pixels ÷ 1024², so a perfect 1080p's worth of pixels reports as 1.9775, not 2.07. Nothing is broken; it's binary megapixels.

    Install

    The pack carries Comfy registry metadata ([tool.comfy], publisher alfredsartan572), so ComfyUI Manager → Custom Nodes → search ResolutionHelper is the easy path. If it doesn't turn up, clone it:

    cd ComfyUI/custom_nodes
    git clone https://github.com/AlfredSartan572/ComfyUI-ResolutionHelper
    # restart ComfyUI
    

    No requirements.txt, no pip step, no downloads - the pyproject declares zero dependencies. The node shows up under Resolution Tools as "Resolution from Dimensions".

    Where people get burned

    The multiple cleans your aspect ratio in a way you can see. Take a downloaded 1920x1080 photo, ask for 1080p, multiple = 32: you get 1920x1056, because 1080 floors to 33×32. That's 1.93MP instead of 2.07, and the ratio nudged from 1.778 to 1.818. Same inputs with multiple = 8 give you 1920x1080 exactly. On a 16:9 source, 32 is the wrong answer even when the model demands it - pick a coarser grid only if you must.

    Don't confuse "1080p's worth of pixels" with "a size SDXL can render". Generating straight at 1080p-plus on an SDXL checkpoint is the classic path to doubled heads and stretched limbs; the fix is always generate near native (1024-ish), then upscale. The consensus is blunt: 1024x1024 native, trained ratios like 1216x832 and 1344x768, and nothing useful at 1920x1080. Where this node earns its place is sizing the later stages - hires-fix second pass, image scale, tiled upscale, or the canvas for a 2026 model whose native band is 1–2MP and takes any shape you give it.

    Pixel budgets get expensive fast. 2160p's worth is 8.3MP; hand that to a sampler instead of an upscaler and expect the usual VRAM wall.

    The pack's other four nodes are worth a look while you're there - ResolutionFromScanlines, ResolutionFromMegapixels, ResolutionCalculator, and AspectRatioSelector (which feeds the other three a ratio over a wire, notably including 16:10, the one everyone forgets).

    CategoryResolution Tools

    Inputs (4)

    NameTypeDefaultDescription
    widthINT8–7680—
    heightINT8–7680—
    scanlinesCOMBO20 options: 240p, 360p, 480p, 544p, 640p, 720p, +14
    multipleINT321–112MiniMaxH3=32, Illustrious/Pony=8, other=16

    Outputs (4)

    NameTypeDescription
    widthINT—
    heightINT—
    longestINT—
    megapixelsFLOAT—