WanVideoResolutionFinder
Ask Wan which resolution it wants — without resizing a single pixel
- image
- width
- height
Here's the workflow pattern: you want Wan to generate at one of its native resolution buckets, but you don't want this particular node to be the thing that resizes your image - you've got your own resampler, or a latent resize, or you need the same resolution applied to a whole batch first. That's exactly the gap WanVideoResolutionFinder fills. It runs the same selection algorithm as the pack's WanVideoOptimalResizer, but it never touches the image. It looks at your input's aspect ratio, consults the Wan bucket list, and returns two integers.
Think of it as the "planning" half of the resizer. It inherits the resizer's logic - the code literally subclasses it - so you get the exact same answers, just without the upscale step or the output image.
What it does
Inputs are minimal: image (it only reads the dimensions, so any image works) and resolution_preset (480p or 720p). It then:
- Computes your image's aspect ratio.
- Finds the preset bucket with the closest aspect ratio (480p gives you 480×832, 832×480, 624×624, 704×544, or 544×704; 720p gives the 720×1280 family).
- Among ties, picks the one closest in pixel count.
- Returns
widthandheightas INTs.
Because it's computation-only, it's effectively free. Drop it into a graph and it costs nothing at runtime.
Why use it over the resizer
Three situations where you'd reach for the Finder instead of the OptimalResizer:
- You want the number, not the resize. Route the width/height into an Empty Latent, a conditioning prep, or a batch process that resizes many images to a unified target. One node computes the canonical resolution for the whole batch.
- You're using your own resize path. If you have a preferred resampler or a latent-space resize, you don't want a second resize node fighting it. Let the Finder pick the target and your node do the work.
- Debugging. If your Wan output keeps coming out an unexpected size, the Finder makes the chosen bucket explicit - wire the two INTs to a text display and you'll immediately see what the algorithm decided and why.
The honest caveats
It inherits the resizer's quirks: it's Wan-specific, so those buckets belong to Wan 2.1/2.2 and shouldn't be cargo-culted to other video models. And because it only picks from five buckets per preset, unusual aspect ratios get rounded to the nearest Wan-native shape - the Finder will cheerfully tell you 2:1 should be 832×480, and it's your call whether that's acceptable. If you'd rather constrain by pixel count instead of buckets, that's PixelLimitResizer's job; if you want the actual resized image back, that's WanVideoOptimalResizer's job.
Install
Same pack as everything else here - ComfyUI-keitNodes via the Manager (search "ComfyUI-keitNodes"), or:
cd ComfyUI/custom_nodes
git clone https://github.com/keit0728/ComfyUI-keitNodes
cd ComfyUI-keitNodes
pip install -r requirements.txt
Restart, and it appears in the keitNodes category. No downloads, no models, no dependencies beyond ComfyUI itself. This is the lightest node in the pack, and it's the one you'll actually use for batch planning.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| resolution_preset | COMBO | 480p | 2 options: 480p, 720p |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |