Zoom Crop (WepeNerd)
Zoom Crop Doesn't Zoom, and That's Exactly Why It's Useful
- image
- image
What it actually does
Zoom Crop takes an IMAGE, takes some pixels off the width, some off the height, lets you say which part of the frame to keep, and hands the result back. No scaling, no interpolation, no resampling filter to argue about. Every output pixel already existed in the input.
The name is a small lie, and it's the useful kind: nothing here zooms. Crop a region and upscale it afterwards and you have a digital zoom - but the zooming happens in some other node.
Why you'd reach for it
Cropping is the unglamorous answer to a surprising number of problems:
- Aspect ratios the model actually likes. The standard advice for 16:9 output is to generate at 7:4 - close to a trained ratio - then crop down, rather than generating at 1920x1080 and eating the distortions.
- Grid nudging without resampling. Cropping shifts your canvas; resizing resamples every pixel in it. When you need to lose eight pixels to land on a legal dimension, dropping a strip of edge beats running Lanczos over the whole frame.
- Off-center reframes. Twenty-five positions, not nine, and the in-between ones aren't tic-tac-toe cells - they're quarter steps across the travel.
- Crop-and-stitch inpainting. The pattern that won 2026 - crop the region, render it at the model's native resolution, paste it back - depends on a crop that leaves everything else alone. This one copies pixels exactly.
How the geometry works
The two numbers are totals, not per-side amounts - the tooltip says so, and it's worth saying twice, because assuming crop_width: 200 removes 200 from each side is the most common way to get surprised. A 1024×768 image with 200 and 100 becomes 824×668.
Position is a 5×5 choice. left keeps the left edge, top keeps the top edge, center splits the removal evenly between both sides, and everything between is a quarter of the available travel. Two details matter for predicting output: a single-word position only affects one axis, so left keeps the left edge and stays vertically centered; and position doesn't interact with the amounts, so changing the amount re-opens the same proportional travel.
Under the hood it's clamping and slice arithmetic: removal is capped at one pixel less than the dimension, so you can never crop an image out of existence, and if both amounts are zero the node returns the input untouched rather than copying it. The slice applies across the whole batch - same frame count, dtype and device in as out - so it works on video batches, not just stills.
On current builds the widget is a click-and-drag 5×5 picker with a hover preview, arrow keys to nudge, and C to recenter. Older installs show the same choice as a 25-item dropdown; both store the same value.
Inputs and outputs
image- the IMAGE being cropped: a still or a batch.crop_width- total pixels removed from the width, 0 to 16384, default 0.crop_height- total pixels removed from the height, 0 to 16384, default 0.position- the 25-way 5×5 choice, defaulting tocenter.imageout - IMAGE, straight into Save Image, VAE Encode, an upscaler, or the stitch half of a crop-and-stitch pair.
No mask input, no scale factor - if you wanted to crop and resize in one step, you need a second node.
Installing it
ComfyUI Manager → search ComfyUI-WepeNerd → install, or:
cd ComfyUI/custom_nodes
git clone https://github.com/WepeNerd/ComfyUI-WepeNerd.git
python -m pip install -r ComfyUI-WepeNerd/requirements.txt
Restart ComfyUI, hard-refresh the browser. Requirements are Pillow, numpy, scipy and av>=17.0.0; the weight comes from the pack's video and paint nodes, but you install the lot either way. No models, no GPU wheels, torch untouched. If you also have the author's older all-in-one pack installed you'll get duplicate nodes - keep one.
Where people get tripped up
The output size changes, and something downstream cared. ComfyUI will happily pass an 824×668 image along; the next node may not be so relaxed. Most VAEs want multiples of 8, and some video models want much coarser grids (LTX wants 32). Pick removal amounts that land you on a legal size rather than just off it.
Huge amounts clamp instead of erroring. Type 5000 into a 1024-wide image and you get a 1-pixel-wide image, not a complaint. A fat-fingered value can sail through and only reveal itself several nodes later.
Zero is a free bypass. Both amounts at 0 passes the image through unchanged - handy for toggling a crop without rewiring.
Core's Crop Image is a different tool. It takes an absolute width, height and x/y, which is better when you know the exact box. Zoom Crop is better when you know how much you want to lose, or when the input size is set by a node upstream.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| crop_width | INT | 00–16384 | Total pixels to remove from the width, not per side. |
| crop_height | INT | 00–16384 | Total pixels to remove from the height, not per side. |
| position | COMBO | center | Position of the retained crop: left/top keeps that edge; center splits removal between both sides. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |