Size Selector

Every model family wants a different latent shape. SD 1.5 and SDXL want four channels. Flux, SD3 and the video models want sixteen. Core's Empty Latent Image gives you dimensions and a batch and nothing else; get the channel count wrong and you don't get an error, you get a sampler that produces noise or dies several nodes later with a shape mismatch nobody can decode. 尺寸选择器 (QG_SizeSelector) is a latent factory that lets you say which kind you need.

How it works

Start with preset, a list of about forty resolutions each tagged with its ratio - 832x1216 - 2:3, 1344x768 - 16:9, widescreen and vertical variants, the usual SDXL-friendly numbers. Then optionally reshape it:

• ratio overrides the preset's aspect ratio with a string: 16:9, 2.39:1, even 1 1 with a space. Leave it at 无 and the preset's own ratio is used.
• long_edge scales the result so its long side is that many pixels, keeping the ratio. 0 keeps the preset's native size.
• factor rounds width and height up to a multiple of whatever you put here - 8, 16, 32. 0 disables it. This is the field that stops you shipping an 833-pixel-wide latent by accident.
• batch_size is what you'd expect.

Then the two fields that make this node worth installing:

latent_channels picks 4 or 16. SD 1.5 and SDXL: 4. Flux, SD3, and video models: 16. This is the bug the QG port fixed - the upstream node hardcoded 16 channels, which quietly broke plain SDXL latents. If you've ever had a Flux-era node produce latents that made an SDXL sampler behave strangely, this class of mistake is why.

frames is the other one. At 0 you get a plain image latent with no temporal dimension. Above 0 you get a video latent, and the node divides the frame count for the temporal compression the video VAEs apply - the tensor is built with ((frames - 1) // 4) + 1 in the time axis, so asking for 49 frames gives 13 latent frames, which is what the model actually consumes.

width and height are optional wildcard inputs. Wire anything numeric into them and a value above 0 wins over the preset. That's how you make the whole graph size-driven from a single source upstream.

Inputs and outputs

Required: preset, batch_size, long_edge, ratio, frames, factor, latent_channels. Optional: width, height (wildcards, parsed as numbers).

Outputs: LATENT (the empty latent), WIDTH and HEIGHT (the dimensions actually used, as INTs), and FRAMES (the frame count, 0 for image models).

Those integers are the useful part in a big workflow - feed WIDTH/HEIGHT into whatever needs them downstream and stop maintaining two copies of the truth. That's the plumbing principle the KB keeps coming back to: one authoritative value, fanned out by wire.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/live1617/ComfyUI-QG-tools

Full ComfyUI restart; the console confirms with [QG-tools] v0.9.2 加载完成 | 节点数 24. Manager search ComfyUI-QG-Tools where the registry listing exists. Nothing to pip install - the requirements file is deliberately comments only so Manager skips pip, and this node needs only torch plus ComfyUI's model management module.

Ported from ComfyUI_Muye (MIT), searchable as size selector, aspect ratio, resolution or 尺寸选择器.

Where people get burned

FRAMES is not the latent's frame count. It reports the number you asked for; the latent holds the temporally compressed value. Don't wire FRAMES into something expecting latent["samples"].shape[2].

Wrong channel count, no error. Four vs sixteen doesn't fail at latent creation - it fails when the model's patch embedding sees a shape it doesn't recognise, several nodes downstream. If a Flux workflow produces garbage, check this widget before you check anything else.

long_edge with ratio set. Both reshape the preset, and it's easy to set a long edge that pushes the short side somewhere you didn't intend - the node's original upstream bug was assigning the long edge to both dimensions and producing a square. Fixed here, but a 21:9 with a 2048 long edge still gives you a very short side, and no model likes 460 pixels tall.

Preset numbers aren't sacred. These are hand-picked model-friendly resolutions, not magic. If you're running a model with a specific native training resolution, use factor and the override inputs to land exactly on it rather than trusting the nearest preset.