PD:GetImageRatio

PD:GetImageRatio (PD_GetImageRatio) reads an image, computes its width-to-height aspect ratio, and outputs it as a clean string like 4:3 or 16:9. That's the entire feature. It feels trivial until you're building a workflow that needs to branch on an image's shape - then a ratio string you can compare against is exactly what you wished you had.

Why you'd reach for it

Aspect ratio is a decision input. Maybe you're routing different compositions to different resize or crop paths, deciding whether an image is portrait or landscape before a save/paste step, or logging shapes during a batch run. ComfyUI core gives you image dimensions as ints, but a reduced 4:3 string is one you can match directly against the ratio presets that every size-selector dropdown in this ecosystem uses. It pairs naturally with the pack's ratio-aware nodes (like the size-by-ratio and ratio-selector nodes), where the string form is the native currency.

How it works

The node takes the image's width and height, computes the greatest common divisor (the source literally implements Euclid's algorithm), and divides both dimensions by it. So 1920×1080 becomes 16:9, 1024×1024 becomes 1:1. Out comes the reduced ratio as a STRING. Nothing more - no width/height outputs, no rounding options. If you need the raw pixel dimensions too, grab those from an image-info node and let this one supply the pretty string.

Input and output

• image - any single IMAGE tensor. Batch inputs aren't handled - feed one image at a time.
• Output: ratio - the reduced aspect ratio as a string.

Installing

Part of the 7BEII/Comfyui_PDuse pack. ComfyUI Manager → search "Comfyui_PDuse" → install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/7BEII/Comfyui_PDuse
cd Comfyui_PDuse
pip install -r requirements.txt

Restart after. No models; pure math, no special dependencies.

Gotchas

The output is always the reduced ratio - 4:3 stays 4:3, but 1200×900 also becomes 4:3, so don't treat the string as an exact resolution fingerprint. Near-misses also produce oddballs: 1919×1080 reduces to 1919:1080, which is technically correct and practically useless for matching against 16:9. And it's strictly single-image - throw a batch at it and the ratio reflects the first frame's shape at best. For a workflow that needs to react to ratio, wire this into a text-match or switch node and compare against the preset strings.