萌宝AI·自由裁剪
Crop by exact pixels, and it forgives your bad math
- image
- cropped_image
- x
- y
- width
- height
Most crop nodes in ComfyUI come in two flavours: the ones that want a mask and the ones that hand you a canvas to drag. ImageFreeCrop (萌宝AI·自由裁剪) is neither. It wants four integers - x, y, width, height - and it does exactly that crop, in pixels, on every frame of the batch. Sometimes that's the whole point: you know the coordinates because another node produced them, or because a template is 1080x1350 and you need the bottom 1080x400 gone.
What it actually does
The crop itself is plain tensor slicing: image[:, y0:y1, x0:x1, :]. What makes it useful rather than annoying is the clamping. Before slicing, the node normalizes your numbers against the real image:
xis clamped to0 .. width-1,yto0 .. height-1- the right and bottom edges are clamped to the image, so you can never ask for a rectangle that runs off the canvas
- the resulting size is forced to at least 1x1
So x=1900 on a 1920px-wide image doesn't error and doesn't return an empty tensor - it slides back to somewhere legal and gives you the biggest slice that still exists. That's friendlier than it sounds when you're driving the node from a calculated value or a spreadsheet of coordinates.
The other half of the design: it re-emits the numbers it actually used. So the node is both an operation and a source of truth. Downstream nodes get the clamped rectangle, not the one you typed, which means a paste node, a coordinate logger, or a second crop that has to line up will stay in sync instead of drifting by 40 pixels.
Inputs and outputs
You wire an IMAGE in, then set four integers: x and y (0–16384, defaults 0), width and height (1–16384, defaults 512x512). That's the entire node - no mask, no feathering, no snapping to a multiple of 8, which matters if you care about latent-friendly dimensions. Nothing here forces your output to be divisible by 8; if you're feeding the crop back into a sampler, round it yourself.
Outputs are cropped_image (IMAGE), plus x, y, width, height as plain INTs. The crop is applied to the whole batch, so a batch of 4 in gives a batch of 4 cropped out. If you only need the coordinates and not the pixels, ignore the image output - ComfyUI only executes what the output node actually needs, so the values are cheap to reuse.
The common wiring is: load image → ImageFreeCrop → save/preview, or crop → upscale → paste-back with a pack that takes a rectangle. The coordinates are also handy for a second crop of the same source at a different size, since both can read the same clamped x/y.
Installing it
ImageFreeCrop ships inside ComfyUI-MengBaoAI, a 17-node pack from Corkery520 (Registry id mengbaoai, MIT). If the Registry listing is live for you, search MengBaoAI, mengbaoai or 萌宝AI in ComfyUI-Manager - or use Comfy CLI: comfy node install mengbaoai. The README is explicit that the Git route is the fallback while the first Registry release clears platform scanning, so this always works:
cd ComfyUI/custom_nodes
git clone https://github.com/Corkery520/ComfyUI-MengBaoAI.git
cd ComfyUI-MengBaoAI
python -m pip install -r requirements.txt
The requirements file is three lines - numpy, Pillow, requests. No torch reinstall, no CUDA surgery; the README tells you not to swap the environment's torch or aiohttp. On the Windows portable build, run pip with the embedded interpreter (..\..\..\python_embeded\python.exe) rather than a system Python, or you'll install requests into an environment ComfyUI never sees. Restart ComfyUI, then search the canvas for ImageFreeCrop, 萌宝AI, or 自由裁剪 - the pack registers Chinese and English search aliases.
If you previously used the standalone WANG packs (WANG_image_split_crop_nodes, WANG_load_image_nodes), disable them before loading this one. The README calls this out because duplicate node IDs and duplicate HTTP routes are how a clean install turns into a confusing one.
Things that bite
- Coordinates are top-left origin, and the node doesn't tell you the image size. There's no "fit to image" mode, so a hardcoded 1200-wide crop silently becomes 1080-ish on a smaller source. Wire the real numbers or check the
widthoutput once. - It's not aspect-ratio aware. Paired with the constraint node later in the graph is the sane combination if you're prepping images for a platform that enforces a ratio.
- Batch semantics. Every frame gets the same crop. If you wanted a different crop per image, you're in a loop or a
fornode, not this one.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| image | IMAGE | — | |
| x | INT | 00–16384 | — |
| y | INT | 00–16384 | — |
| width | INT | 5121–16384 | — |
| height | INT | 5121–16384 | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| cropped_image | IMAGE | — |
| x | INT | — |
| y | INT | — |
| width | INT | — |
| height | INT | — |