📐 Nearest Qwen Resolution

Qwen-Image is picky about resolution in a way SDXL and Flux aren't. Its official recommended sizes live on a small list of presets - 928x1664 for 9:16, 1328x1328 for square, 1664x928 for 16:9 - and Alibaba tuned the final training phase on exactly those. Feed it a random 1080x1350 and you'll often get artifacts or soft output, because that size never showed up in training data. 📐 Nearest Qwen Resolution exists to stop you from guessing which preset fits your input. Give it any image, it hands back the width and height you should actually generate at.

It's a two-integer node, so it's small by design. Drop it in wherever a Qwen workflow needs dimensions: img2img, edit, or the "generate a variation of this composition" flows. In the pack's own layered workflow it feeds width/height into the scaling step and the latent setup, which is the canonical wiring - LoadImage → this node → ImageScale (or an EmptyLatentImage-style node) → sampler.

How it decides

The mechanism is dead simple, and the code is short enough to read in one sitting. It takes your image tensor (B,H,W,C), grabs the first frame's dimensions, and classifies the orientation:

• Wide / Vertical / Square, with square_tolerance deciding how close to 1:1 counts as square.
• It filters the seven Qwen presets down to that orientation.
• Then picks the preset with the smallest aspect ratio difference from your input, breaking ties by the smallest total difference in width + height.

That ordering matters. Two presets can both be "close enough" on aspect ratio (say 2:3 and 3:4 for a portrait shot), and the tie-break picks the one that changes your image size the least. It's a sensible heuristic, and it means a 1024x1536 input doesn't get blown up to a 9:16 frame if a 2:3 one fits better.

No 64-multiple rounding anywhere - Qwen doesn't need it, so the node reports presets exactly as-is.

The inputs and outputs that matter

Only two inputs, both required:

• image (IMAGE) - the tensor. First frame is used, so batch size doesn't matter.
• square_tolerance (INT, default 3, range 0–20) - percent within which an aspect ratio counts as square. At 3, a 1050x1080 image is treated as square; crank it to 10 and noticeably taller images get snapped to 1328x1328 instead of a vertical preset.

Outputs are just width (INT) and height (INT). Wire them into whatever needs dimensions downstream.

One trap beginners hit: it needs the IMAGE, not the LATENT. If you connect the encoder's latent output you'll get a type mismatch or a crash, since it's reading tensor shape. Feed it straight from LoadImage and you're fine.

Installing it

This is a one-file pack with zero dependencies - no requirements.txt, no model downloads, no API keys. Just pure Python and torch, which ComfyUI already ships.

Via ComfyUI Manager: search "Nearest Qwen Resolution" (or the pack title) and install, then restart. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/DenRakEiw/ComfyUI-nearest-qwen-resolution

Restart ComfyUI and the node appears under image/resolution.

Common issues

There's not much to break in a node this small, but a couple of things come up:

• Wrong orientation in the output. Usually means square_tolerance is doing more than you expect. Remember 0–20 is the full range; at 20, a 4:5 portrait gets classified as square.
• "Unsupported image tensor shape" - you've passed something that isn't a batched image tensor. Re-check the connection.
• Nothing shows under resolution. Make sure you restarted ComfyUI after cloning; Manager picks it up on refresh, a manual clone needs the restart.

The honest caveat: this node is a thin utility, and "pick the nearest preset" is a solved problem in about six different packs now (ResolutionMaster is the big, flashy one). But this one is also the most single-minded - no giant UI, no model-specific settings to fumble, just two integers out. If you run Qwen-Image workflows more than once a month, it saves you from memorizing a lookup table, and it costs nothing to install. That's a fair trade.