K3NK Find Nearest Bucket
This Node Finds the Right Bucket for You
- image
- width
- height
Wan 2.x and other video models don't want your image at whatever resolution it happens to be. They want it snapped to one of a set of "buckets" - resolutions whose width and height are multiples of 32 (or 16, for some models), clustered around a target area. Feed them an off-bucket size and you get distorted output, silent memory waste, or a model that just complains. K3NK Find Nearest Bucket exists to answer the one question you keep having to look up: what size do I resize this to?
It's a tiny utility - one input image, two integer outputs - but it sits in exactly the spot where people hand-calculate resolutions and get it wrong. The author's own tooltip is the whole manual: use base_resolution 640 for 480p, 720 for 720p, and 1088 for Wan 2.x HD.
How it works
The math mirrors the bucket logic in FramePack's bucket_tools.py, which is a good sign - that's a code path that's been battle-tested by thousands of Wan workflows.
Given your image's aspect ratio and a base_resolution, it computes a target pixel count (base_resolution²), then walks through heights in steps of 32 and finds the width (also rounded to 32) whose area lands closest to that target. Your aspect ratio is preserved the whole way; you just get the closest legal version of it. So a 16:9 frame at 640 lands on something like 1136×640 rather than a random 1013×569 that no video model recognizes.
One thing worth knowing: it reads only the tensor's shape, never the pixels. You can feed it the actual IMAGE you're about to resize and it costs you nothing.
The inputs that matter
image- any IMAGE. Used purely for its height/width.base_resolution- the target, in pixels-per-side terms. The defaults that work: 640 (480p-ish), 720 (720p), 1088 (Wan 2.x HD). This is the one knob you'll touch.
The outputs, width and height, are plain INTs - wire them into the width/height inputs of a resize node (any ImageScale variant, or a Wan-friendly one), and you never think about buckets again. They also slot into batch workflows where you're generating multiple images at different aspect ratios and need each one snapped on the fly.
Installing it
It ships in the K3NK pack. Easiest path is ComfyUI Manager - search for ComfyUI-K3NKImageGrab and hit install. Or clone it manually:
cd ComfyUI/custom_nodes
git clone https://github.com/K3NK3/ComfyUI-K3NKImageGrab
Then restart ComfyUI. No model files, no extra Python deps for this node - it's pure math on top of what ComfyUI already ships.
Where people get burned
The common mistake is treating base_resolution as an exact output size. It isn't - it's the target area the node tries to land near, and aspect ratio wins the argument when they conflict. If you feed it an ultra-wide image at 640, you'll get something wider than 640, and that's correct behavior.
Also, if your pipeline is SD 1.5 or SDXL rather than a video model, this node is overkill - those models happily take a wide range of sizes and you can resize to taste. It earns its keep specifically with bucket-based video models, which is exactly what it was built for. Keep it upstream of the resize, and it quietly removes one of the most common causes of "why is my Wan output garbled?" posts.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| base_resolution | INT | 64064–2048 | Base resolution. Use 640 for 480p, 720 for 720p, 1088 for Wan 2.x HD |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| width | INT | — |
| height | INT | — |