getImageSide-badger

getImageSide-badger answers one question: how long is this image's shorter (or longer) side? You feed it an image and tell it whether you want "short" or "long," and it returns that dimension as an INT. That's the whole node, and it's one of those deceptively useful little helpers because "normalize by the shortest side" is a sizing pattern you'll hit constantly.

Think about upscaling and preprocessing for a second. A lot of the time you don't care about the exact dimensions of an image - you care about proportion. "Scale so the shortest side is 1024," "make the longest side 2048," "never let it exceed 1536." That's a description of an image's short or long side, not its width or height, because you don't know the orientation in advance. The KB's upscaling essay makes exactly this point: the first decision is what job you're doing, and the second is computing the target. This node is the "read the image's own proportions" half of that computation.

How it works

It reads the image's width and height, compares them, and returns whichever one you asked for: the smaller number for "short," the larger for "long." Nothing resizes, nothing crops - it's a pure measurement node. That matters because it means you can chain it into sizing decisions without the measurement going stale: wire its INT output into ImageScaleToSide-badger (same pack) to build "scale this image so its longest side hits 2048" without ever knowing the orientation yourself.

Inputs and outputs

• image - the IMAGE to measure.
• side_choose - a dropdown with exactly two options: short or long. This is the only setting; there is no third mode and no way to get the "other" dimension out of the same node.

One output: an INT, the length of the chosen side in pixels.

Installing it

In ComfyUI_BadgerTools: ComfyUI Manager → search "BadgerTools" → install, or

cd ComfyUI/custom_nodes
git clone https://github.com/AbyssYuan0/ComfyUI_BadgerTools

Restart after install. No models. The pack's heavyweight requirements load at startup no matter which node you use - moviepy, open_clip, scikit-image and friends, none of which a measurement node needs.

Where it fits

The genuinely useful chains:

• getImageSide (long) → ImageScaleToSide-badger → cap any image at a max side for tiling or model input.
• getImageSide (short) → feed into a min-side parameter for downscaling before upscaling (the "soft source needs a smaller base" trick from the upscaling playbook).
• Orientation-agnostic filename math: "it's a long-side-N image" instead of hardcoding width/height.

Gotcha-wise, it's nearly nothing: the node reads the first image in the tensor (batch-aware it is not), and it returns pixels as a plain INT - no normalization, no scaling by any fraction. If you need "short side minus 20%" you're combining this node with math elsewhere. It measures. You decide what to do with the number.

No community threads exist for this node - it's a personal-pack measurement utility. But in a graph where aspect ratios fight you at every resize, a node that just tells you the proportion is the quiet fix. Pair it with the pack's resize node and "I don't know the orientation" stops being a reason to hardcode dimensions.