OpenCV copyMakeBorder_1

copyMakeBorder_1 is the second overload of cv2.copyMakeBorder - the UMat variant of a signature that also exists for MatLike - and like every twin in this auto-generated pack, it's byte-identical to its _0 sibling. If you need the full tutorial, copyMakeBorder_0 is where it lives. This page is the signpost, plus the one gotcha worth repeating because it's the most common injury on these nodes.

What both do: add a border around an nparray. Inputs are src, top, bottom, left, right (all INT, the border thickness per side), borderType (INT), and value (STRING). Output is the padded nparray. borderType picks the fill strategy - 0 constant color, 1 replicate edge pixels (usually the nicest for photos), 2 mirror reflect, 4 reflect-101, 3 wrap - and value is only consulted when you chose constant.

The trap: value is a string parsed with Python's literal_eval. You must type a real Python literal - (255, 255, 255) for white, [0, 0, 0] for black. Mismatched brackets, missing parens, JSON-style braces - any of it throws the pack's documented invalid syntax (<unknown>, line 0) error, and it's easy to blame the node when the real culprit is a typo in a text field. When in doubt, copy the (255, 255, 255) form verbatim.

Install, same as the pack

cd ComfyUI/custom_nodes
git clone https://github.com/geroldmeisinger/opencv-comfyui
pip install opencv-python-contrib

Or ComfyUI Manager → opencv-comfyui → restart.

The rest of the shared rules: it runs on numpy NPARRAYs, so Comfy images go through Image2Nparray (batch 1 only) on the way in, and the pack is BGR - a colored value will look channel-swapped until you account for that. The optional dst input is an OpenCV out-parameter; leave it alone.

_0 or _1? Functionally identical. Keep whichever your workflow already has, and if you're building fresh, the suffix genuinely doesn't matter - the string-input rule applies to both.