Aspect Size V2
The resolution calculator that grew video-model legs
- Width
- Height
AspectSizeV2 is the sequel to the DJZ resolution calculator, and the sequel actually added something: video-model support and a configurable divisibility factor. The V1 took SD/SDXL/Cascade, fixed the multiple-of-16 rounding, and called it a day. V2 ships a model_type dropdown with ten entries - SD, SDXL, QWEN, 1440x, WAN22, Cascade, 3072x, 4K, 8K, 16K - plus a downscale_factor knob (1–128, default 64) that replaces the hardcoded 16.
Same job as V1, same two ratio inputs: aspect_ratio_width and aspect_ratio_height (16/9, 9/16, 1/1, whatever). Outputs are Width and Height integers, now divisible by your chosen downscale_factor instead of fixed at 16. The logic: take the model bucket's base resolution, keep total pixel count roughly constant while stretching to the ratio, round both dimensions to the factor, return the pair. Wire them into an Empty Latent (or your video model's size input) and go.
The new model types are the real story, because video generation is where resolution discipline actually hurts. WAN and Qwen video models have specific width/height multiples (often 32 or 64) that aren't the same as SD's 16, and getting that wrong produces either a latent that the model reshapes under the hood or straight-up load errors. downscale_factor set to 64 for those families is a sensible default - it's why the author chose 64. For 4K/8K/16K stills it's also the memory-saver: a higher factor means fewer awkward in-between resolutions to OOM on.
Where it's overkill: pure SDXL still work. If you generate 1024²-class images and never touch video models, V1's fixed-16 rounding is fine and this node's extra options are just dropdown clutter. The downscale_factor deserves a real caveat too - crank it too high (say 128 for a portrait ratio) and you can round yourself into a smaller total pixel count than the model wants, since coarse rounding on a skinny dimension eats resolution. Start at the defaults, adjust only when a specific model demands it.
One honest gap: the model-type buckets are still just resolution presets. "WAN22" and "QWEN" don't tell the node anything about aspect conventions specific to those models beyond the base resolution it picks for them - it's a smarter calculator, not a model-schema database. If your video model publishes a specific size list (some do, e.g. 1280×704, 704×1280), the bucket gives you a start and you should still sanity-check against the model's own docs.
Zero dependencies, pure math. Install: ComfyUI Manager → "DJZ-Nodes", or cd ComfyUI/custom_nodes && git clone https://github.com/MushroomFleet/DJZ-Nodes && pip install -r requirements.txt. If you're already on the DJZ pack for the video nodes, this is the version of AspectSize you'll actually keep in the video graph.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| model_type | COMBO | 10 options: SD, SDXL, QWEN, 1440x, WAN22, Cascade, +4 | |
| aspect_ratio_width | INT | 1 | — |
| aspect_ratio_height | INT | 1 | — |
| downscale_factor | INT | 641–128 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| Width | INT | — |
| Height | INT | — |