Image Resize
A Resize Node That Respects the Latent Grid (Your Sampler Thanks You)
- images
- IMAGE
Resizing an image in ComfyUI sounds like the easiest thing in the world - and then you type in 500×500, hit run, and the sampler complains or the output comes back subtly wrong. The reason is the latent grid: ComfyUI's VAE encodes images with an 8× downsampling factor per side, so the model's latent space expects dimensions that are multiples of 8. Feed it a 500-wide image and you're working with a latent that doesn't line up cleanly, which is a classic source of errors or slightly mushy generations.
HfResizeImage is a resize node that has that baked in. You give it a target width and height, and it resizes your image - then quietly snaps both dimensions down to the nearest multiple of 8 before handing the result back. Ask for 500×500 and you get 496×496. That's the whole selling point, and it's a genuinely useful one for anyone prepping images before a VAE encode or img2img pass.
What the inputs mean. Just three of them:
images- the IMAGE tensor to resizewidth- target width (64 to 2048, default 512)height- target height (64 to 2048, default 512)
And one IMAGE output. The resize itself uses Pillow's ANTIALIAS (a high-quality Lanczos-style resample), so edges stay clean.
Two things to know before you use it. First, there's no aspect-ratio preservation. You specify both width and height, and if your numbers don't match the image's aspect ratio, you get distortion - this is a "make it exactly this size" node, not a "fit within" node. Second, the multiple-of-8 snapping is silent. If you're building a workflow that must produce exactly 1024×1024, no problem - 1024 is already divisible by 8. But if you set 500×500 and wonder why the image came out 496×496, now you know. It's a feature, not a bug: that snapped size is the one your sampler actually wants.
There's also a fast path worth mentioning: if the image is already at the target size and the target is already divisible by 8, the node hands the tensor back untouched, so dropping it into a workflow costs you nothing when it has nothing to do.
Where does this sit versus core ComfyUI? You've got ImageScale and ImageScaleByFactor built in, and they resize fine - but neither snaps to the latent grid for you, and plenty of people have burned an hour on an error that HfResizeImage would have prevented by construction. If you're resizing mixed-resolution source images into a standard size for a batch, or normalizing a reference image before ControlNet preprocessing or img2img, this is a reasonable default. It's not exciting, but it's the kind of node that quietly removes a failure mode.
It's part of Comfyui HiFORCE Plugin, a pack best known for its sampler utilities (Basic Sampler, Loopback Sampler, the mask-aware two-step samplers) - HiFORCE is at hiforce.net, and the image helpers are the supporting cast around those. Install through ComfyUI Manager by searching "Comfyui HiFORCE Plugin," or:
cd ComfyUI/custom_nodes
git clone https://github.com/hiforce/comfyui-hiforce-plugin.git
cd comfyui-hiforce-plugin
pip install -r requirements.txt
Restart ComfyUI and it appears under HiFORCE → Image → Zoom. The README recommends installing ComfyUI-Impact-Pack first, since much of the pack builds on its foundation. Requirements are torch, numpy, Pillow, and requests - nothing exotic, no model downloads.
Fair warning, the pack has essentially zero community footprint - no meaningful Reddit threads about it, which is its own signal that it's a niche, author-maintained project. You'll rely on the README, the GitHub wiki, and the source, which for a node this simple is refreshingly short.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| width | INT | 51264–2048 | — |
| height | INT | 51264–2048 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | — |