PVL Get Image Size

Boring utilities win workflows, and this is one of the most useful boring nodes in the pack. It reads an image and tells you its dimensions - but not just raw pixels. It also gives you the size scaled to a 1-megapixel (1K) area, the aspect ratio rounded to a whole number, and the closest "standard" ratio from a fixed list. Feed it the output of any upscaler and you instantly know what resolution and aspect you're actually working with.

Why the 1K numbers matter: a whole generation of hosted-API image models (including several others in this pack) take width/height or aspect presets, and many expect an area around 1 megapixel. width_1K / height_1K tell you what your image becomes if you downscale it to that ballpark while keeping the aspect - which is exactly what you want to feed a Qwen-Image or SeeDream call without doing the arithmetic in your head. It's glue, and glue is what makes big workflows hold together.

How it works

It reads the H, W from the image tensor's shape - there's no model, no API, no network involved; this is pure local math, and it's instant. The rounded_aspect_ratio output is your raw W/H rounded to a clean fraction like 16:9. The standard_aspect_ratio output compares the real ratio against a fixed list - 21:9, 16:9, 4:3, 3:2, 5:4, 1:1, 4:5, 2:3, 3:4, 9:16, 9:21 - and returns the closest match.

One input: image. Six outputs:

• width, height - raw pixels.
• width_1K, height_1K - scaled to ~1 megapixel area, aspect preserved.
• rounded_aspect_ratio - e.g. 16:9.
• standard_aspect_ratio - the closest match from the fixed list.

Installing it

Part of the pvlprk "ComfyUI Assistant Node" pack:

cd ComfyUI/custom_nodes
git clone https://github.com/pvlprk/comfyui-pvl-api-nodes

Restart ComfyUI. That's the whole install - this node needs no API key, no models, and no extra dependencies beyond what ComfyUI already has. It's one of the few nodes in this pack that works completely offline.

Common issues

Honestly, this node has almost nothing to go wrong - it's shape math. The one real gotcha: it reports the tensor's dimensions, which are the dimensions of the last operation in the graph. If you're checking it on an image that went through a latent decode with padding, what you see is the decoded canvas, not necessarily the "intended" crop. Second, if the standard_aspect_ratio output ever looks wrong (say a 16:9 image snapping to something odd), remember it's a closest-match from a fixed list of 11 ratios - a 2.35:1 cinematic frame has no true home in that list, and it'll pick the nearest neighbor. Neither is a bug; they're just the honest limits of a six-output utility that doesn't know your intent.