Adaptive Image Resize

Here's the workflow problem this node exists to kill: you've got a great still frame, you want to feed it into Wan 2.2 (or any I2V model) for an image-to-video run, and the model wants a fixed pixel budget - 720p, or 480p, dimensions snapped to a multiple of 16. Your image is 1249×1873 or some other resolution ComfyUI refuses to run. So you fire up an editor, resize manually, hope the math lands on a 16-multiple, and lose ten minutes. Adaptive Image Resize does that math for you in one node, and it's genuinely the one thing it does well.

The pack name (ComfyUI-Wanify) overpromises, by the way. There's no Wan-specific magic here, no model loading, no API. It's a single-file, dependency-free resize utility that happens to be pitched at video work. It'll happily serve any pipeline with a pixel budget - Hunyuan, LTX, or just keeping a batch of images under a memory ceiling.

How it works

The mechanism is small enough to read in one sitting, which is a feature. The node keeps a table of target pixel counts: 720p high/medium/low is 921,600 / 691,200 / 460,800 (that's 100% / 75% / 50%), and 480p is 409,600 / 307,200 / 204,800. It takes your image's aspect ratio, solves for the dimensions that hit that pixel count, then rounds both sides down to the nearest multiple of 16 and clamps to a 16×16 minimum.

That multiple-of-16 step is the whole point. Video backbones like Wan hard-require it, and it's the step people botch by hand. Real talk though: that rounding means the output is approximately the target, not exactly it. A true 16:9 input at 720p high lands dead-on 1280×720, but a portrait image at 480p high comes out 848×480 (407,040 pixels), not the nominal 409,600. The node's total_pixels output tells you the truth.

Resizing itself is torch.nn.functional.interpolate under torch.no_grad(). fast_mode on (the default) uses area interpolation for big downscales and bilinear otherwise; switch it off and you get bicubic. For feeding a diffusion video model, quality mode is the right call - you're paying a few extra milliseconds per image, and bicubic keeps edges cleaner going in. Fast mode is for batch pre-processing where you don't care.

Inputs and outputs

Four inputs, and you'll actually touch three of them:

• model (720p / 480p) - the pixel budget. 480p is the community's default production resolution for I2V; 720p costs you real VRAM and minutes per clip.
• quality (high / medium / low) - scales the target pixel count down. high is fine for most work; medium/low are for squeezing into tight VRAM.
• fast_mode (bool) - bilinear/area vs bicubic. Leave it off for video input.
• image - the tensor from any Load Image / VAE decode.

Outputs: the resized image, plus width, height, and total_pixels as ints. The last three aren't decoration - wire them into an Empty Latent or a conditioning that needs to know the exact dimensions, and you've removed the "wait, what resolution did it actually produce?" guesswork.

One more honest caveat: this guarantees multiples of 16, not 32 or 64. If your target model wants a stricter grid, you'll still be rounding by hand. For the Wan 480p/720p world, 16 is enough.

Installing it

Two routes. Easiest: ComfyUI Manager, search "Wanify", hit install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/blird/ComfyUI-Wanify

Then restart ComfyUI. It appears as "Adaptive Image Resize" under image/transform.

Here's the gotcha that'll eat a minute: the README tells you to "copy the comfyui-wanify folder" into custom_nodes - that folder doesn't exist in this repo. __init__.py lives at the repo root, so the clone is the node. Just clone it in place and move on. And the good news: no requirements.txt, no model downloads, no heavy deps. It's one .py file using PyTorch, which you already have. Install is done in one command.

When to reach for it

Use it the way the community uses it: downscale to a 480p/720p budget, generate, then upscale. The KB's wan-video notes make the pipeline explicit - generate at 480p, then hit it with SeedVR2 or a tile-based upscaler afterward. Don't feed the video model a bigger starting image than its budget wants; you gain nothing and lose VRAM. If your source is already small, this node leaves it alone (it skips the resize when dimensions are unchanged), so you can run it as a guardrail on every workflow and never think about it again.