IMAGE -> 'WIDTHxHEIGHT'
Feed an image in, get its dimensions out
- image
- input_str
- int_width
- int_height
get_aspect_from_image (display name "IMAGE -> 'WIDTHxHEIGHT'") is the glue node that makes img2img workflows in the Ser-Hilary/SDXL_sizing pack actually convenient. You connect any image - a loaded input, a decoded generation, a VAE output - and it tells you that image's width and height, both as a ready-to-use string and as two integers. For a pack built around sizing for SDXL, that's the difference between typing dimensions by hand and letting the workflow measure them.
How it works
ComfyUI stores images as tensors shaped [batch, height, width, channels]. The node reads image.shape[2] for width and image.shape[1] for height, and returns three things from that one read:
- input_str - STRING,
"WIDTHxHEIGHT", formatted exactly like the string inputs the pack's other sizing nodes expect - int_width - INT
- int_height - INT
Nothing is resized, reinterpreted, or approximated. You get the resolution the tensor is actually holding.
Where it fits
The intended wiring, per the pack's bundled example_img2img_workflow.json: LoadImage → get_aspect_from_image → feed int_width/int_height into sizing_node_unparsed's gen-size inputs (or build the original_res string for the string-based nodes). The sizing node then computes bucketed generation dimensions and the six SDXL conditioning values consistent with your real input image, instead of you guessing "uh, I think that was 800 wide?"
It's also handy whenever you need an image's dimensions downstream but the resolution isn't known until runtime - a dynamic canvas, an upscale pass, a ControlNet that wants to know what it's looking at.
Install and gotchas
Pack install is the standard: ComfyUI Manager → search SDXL_sizing, or git clone https://github.com/Ser-Hilary/SDXL_sizing into ComfyUI/custom_nodes, then restart. Zero dependencies, no model files - it's a single shape read.
One thing to keep straight: it reports the resolution of the tensor, which is the input image's stored size, not necessarily where you'll generate. For img2img that's usually what you want - you're sizing the conditioning to match your source. And if you already have width and height as numbers instead of an image, its sibling get_aspect_from_ints does the same formatting job from plain ints, though without the convenience of handing you the ints back. For image-driven workflows, this is the one to grab.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| input_str | STRING | — |
| int_width | INT | — |
| int_height | INT | — |