BBox Pad (MEC) (legacy)

If you've ever taken a detection box and found it hugging the subject so tightly that the inpaint had no room to blend, this is the node for that. Four independent paddings, one per side, plus the canvas size to clamp against.

It's also flagged legacy - deprecated in the pack's April 2026 cleanup as a duplicate of what Impact Pack and core already do, kept registered so old graphs keep loading, and hidden from the node search. Fine if you already have it wired; if you're building fresh, most crop/stitch nodes in this same pack now take a context-expansion number and do the padding internally.

How it works

The maths is deliberately dumb, which is the point. pad_left widens the box at the left, pad_right at the right, pad_top and pad_bottom likewise, and then everything is clamped to [0, image_width] × [0, image_height]. Negative numbers shrink the box instead of growing it - the widgets run from −4096 to +4096 for exactly that reason, and it's the fastest way to pull a box inside a rounded or noisy boundary.

Because the clamp happens after padding, a box that's already at the frame edge just stops there. That means two pads that both try to push left past x=0 give you the same result as one, and the reported width is honest about it: the output can never have a negative width or height. If the box shrinks to nothing you get a zero-size rectangle rather than an error, so a suspiciously empty crop downstream usually traces back to negative pads that ate the whole box.

Outputs are bbox and bbox_str. The string is JSON [x, y, w, h], which is what you want when the next node takes a text box rather than a socket.

The input that actually causes problems

image_width and image_height default to 512×512, and they are not read from anything - you have to tell the node how big the canvas is, or the clamp is wrong. Pad a 1920×1080 frame with the defaults in place and your box will get chopped at 512 pixels, quietly, with no error. Wire them from the image dimensions, or set them by hand, but don't leave them at the default and assume the node knows.

There's no reference_image input here, unlike its sibling BBox To Mask, so there is no auto-detect fallback. Just the two integers.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Code2Collapse/ComfyUI-CustomNodePacks.git

Restart, then check the console for [C2C] CustomNodePacks: 142 nodes loaded. Or find "CustomNodePacks" in ComfyUI Manager. Nothing extra to download - the pack's real dependency list (opencv-python, scipy, safetensors) is all for the segmentation and matting side; this node is arithmetic. And resist the urge to run the pack's requirements.txt wholesale: it will happily replace the torch build ComfyUI shipped with, and the README says so in bold for a reason.

Where it fits

Padding a box is one of those steps that sounds optional until you see the alternative. Detectors and grounding models return boxes that wrap the object and nothing else - the cup, not the saucer, as the inpainting doc in our KB puts it - and an inpaint run into a tight box invents clutter to fill the space around it. Padding plus a prompt that describes the surroundings is the standard fix, and five pixels is usually not enough; 40–80 is where most people land.

This node gives you the asymmetric version of that, which matters more than it sounds: a face box often needs more room above (hair) than below (chin), and a person box needs more vertical context than horizontal. One number can't express that. Four can.