Nodes/SDXL_sizing/IMAGE -> 'WIDTHxHEIGHT'
ComfyUI Node

IMAGE -> 'WIDTHxHEIGHT'

Feed an image in, get its dimensions out

By Ser-Hilary·Created 3 years ago·Updated 2 years ago· 28
IMAGE -> 'WIDTHxHEIGHT'
  • 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: LoadImageget_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.

Categorysizing/input conversions

Inputs (1)

NameTypeDefaultDescription
imageIMAGE

Outputs (3)

NameTypeDescription
input_strSTRING
int_widthINT
int_heightINT