IMG_resolution_multiple_of
Crop your image to a friendly resolution β and read this before it eats your edges
- image
- IMAGE
IMG_resolution_multiple_of solves one specific, boring, essential problem: many models and processing steps want image dimensions that divide evenly by some number. Video models want 16. Some VAEs and attention-heavy pipelines prefer 64. Your source image is 1003Γ761 and you need clean multiples - this node gets you there.
But here's the thing you need to know before you drop it in: it crops, it doesn't pad. The node name and the "resolution" framing suggest something that adjusts dimensions; the reality is it trims pixels off the bottom and right edges until the width and height are divisible by your chosen number. The source code is unapologetic about it: h = h - h % multiple_of, then it slices the image. No scaling, no letterboxing, no centering - just crop.
It's part of eden_comfy_pipelines, Eden.art's 70+ node suite, under Eden π±/Image.
What you set
- image - the input image (batch-friendly, it crops every image in the stack the same way).
- multiple_of - the divisor to align to, 2β264, default 8. 8 is the classic SD/ComfyUI floor; 16 is common for video; 64 for some SDXL pipelines. Higher values mean more aggressive cropping.
One output, IMAGE, the cropped result.
Where people get burned
The trap is subtle: if you're 3 pixels off a clean multiple, cropping loses 3 pixels - nobody notices. But a 1003-wide image aligned to 64 loses 43 pixels of your right edge, and if that edge contains a face, a logo, or the horizon, you'll wonder why your output is subtly mangled. Because the crop isn't centered, you also consistently lose the same side (bottom and right), which can bias a whole batch in a way you'll spot only after several runs.
The fix when edges matter: pad first, crop second - or use a padder to add pixels, then align. The pack ships IMG_padder for exactly this dance. If you just need the dimension math and don't care about preserving edges, this node is perfect; if you're processing anything with content near the borders, pad before you crop.
Why alignment matters at all
It's not superstition. Diffusion backbones fold spatial dimensions through downsample/upsample layers, and a residual few pixels on a non-aligned input gets either thrown away inconsistently or forces uneven padding inside the model - the kind of thing that shows up as one-pixel drift, seam artifacts, or dimension errors that come and go depending on the source. The KB's own guidance on native resolutions and model quirks keeps circling back to the same theme: models are trained at specific resolutions and multiples, and feeding them exact multiples removes a whole class of artifacts. This node is the cheap way to enforce that discipline.
Installing it
Standard pack install - ComfyUI Manager (search "eden"), or:
cd ComfyUI/custom_nodes
git clone https://github.com/edenartlab/eden_comfy_pipelines.git
cd eden_comfy_pipelines
pip install -r requirements.txt
Restart ComfyUI. Pure tensor slicing - no models, no downloads, CPU-cheap. Use it freely, just remember it's a cropping tool that happens to be named like a resizing tool.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | β | |
| multiple_of | INT | 82β264 | β |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| IMAGE | IMAGE | β |