Image Dimension Scaler
This 'scaler' never touches a single pixel — and that's the whole point
- image
- width
- height
- width_float
- height_float
The name is a lie, but a useful one. Image Dimension Scaler doesn't resize an image, upscale it, or touch a pixel of it - it reads an image's dimensions and hands you back the width and height you should generate or resize at. It's a pocket calculator for resolution math, and if you've ever hand-typed 1216×832 into an Empty Latent Image and hoped it looked right, you're exactly who it's for.
Why you'd bother
The situation it solves: you've loaded a reference image, and you want to feed it through a checkpoint at something close to that aspect ratio - but not at its full resolution, because SDXL at 2000px wide turns into tiling and duplicated anatomy (the KB's upscaling and troubleshooting essays make that case thoroughly: generate at or near a model's native sweet spot, then upscale after). So you need the answer to "what's 3:2 that fits under ~1 megapixel?" A dimension scaler computes that answer for you, live, from the actual image - change the input image and the numbers follow. The int outputs wire straight into Empty Latent Image's width/height, or into a Resize node feeding a hires-fix pass. It's the kind of node you use in templates so a shared workflow doesn't assume everyone's input is exactly 1024×1024.
How it works
Feed it any image and it pulls the pixel dimensions off the tensor (width and height of the image array), then applies constraints in order. First an optional cap on the largest side, then a total-pixel budget. The budget is where beginners get confused: max_pixels_side is squared, so 1024 doesn't mean 1024 pixels - it means 1024×1024 ≈ 1,048,576 pixels max, the standard ~1MP SDXL generation budget. It preserves your aspect ratio through both constraints, then spits out two flavors of each dimension: exact floats (width_float, height_float) and integers rounded to your alignment step (width, height).
The one detail worth knowing: the ints are rounded after the caps, so they can nudge a hair past your budget when rounding rounds up. 1280 with an 8-step becomes 1280; a cap that lands on 1277 rounds up past it. It's usually a few pixels and never worth obsessing over, but if you're strict about VRAM, remember the alignment is applied last.
The inputs that matter
image- your reference; the only thing that must be wired in.pixel_alignment- round the result to a multiple of 4/8/16/32/64. Default 8. Latents and VAE encoding like multiples of 8; set 64 if you're matching Flux's or SDXL's divisibility habits.max_pixels_side- the pixel budget, squared as above. Default 1024.limit_largest_dim/largest_dim_cap- a second, independent clamp on the longest side (default 1280). Turn the boolean off if you only want the pixel budget.
Outputs width/height are the aligned ints you'll actually feed downstream; the floats exist for when you want the mathematically exact ratio (say, feeding an exact resize). A small safeguard lives in the code: neither aligned dimension can drop below your alignment step, so a tiny input won't hand you a zero to choke on.
Installing it
This is a one-file pack with zero Python dependencies - no requirements.txt, no model downloads, nothing to fetch. Clone and restart:
cd ComfyUI/custom_nodes
git clone https://github.com/MaxKruse/ComfyUI_Image_Dimension_Scaler
Then restart ComfyUI (or hit "Update" via ComfyUI Manager, where it shows up as ComfyUI_Image_Dimension_Scaler). One honest gotcha: it's written against ComfyUI's newer backend API (from comfy_api.latest import ComfyExtension, io - the V3 schema that's quietly replacing NODE_CLASS_MAPPINGS). If you're on a ComfyUI install from more than a few months back, update ComfyUI first; this node needs a build that ships that API.
Any traps?
It's brand new - a single initial commit from August 2026, essentially undiscovered (hence the silence around it online). Nothing wrong with that, but there's no battle-tested community lore yet. Realistically the main frustrations are the ones above: mistaking max_pixels_side for a literal pixel count, and expecting it to resize something when it only computes numbers. Keep the outputs in mind as targets for another node - an Empty Latent, a resizer, an upscale stage - and it does its one job quietly well.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | Input image to measure dimensions from. | |
| pixel_alignment | COMBO | 8 | Round output dimensions to this multiple. |
| max_pixels_side | INT | 10241–8192 | Max total pixels = this value squared (e.g. 1024 means 1024x1024 max). |
| limit_largest_dim | BOOLEAN | true | If enabled, cap the largest dimension at 1280. |
| largest_dim_cap | INT | 128064–8192 | Maximum value for the largest dimension when limit_largest_dim is enabled. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |
| width_float | FLOAT | — |
| height_float | FLOAT | — |