OpenCV copyTo_1

copyTo_1 is the UMat overload of cv2.copyTo, auto-generated into a node that's byte-identical to copyTo_0. That's the entire difference. The real guide is over at copyTo_0; this page exists so the _1 search result lands somewhere useful instead of a dead end.

The shared behavior, since you're here: the node copies pixels from src (NPARRAY) only where mask (NPARRAY) is nonzero and returns the result. With no dst wired, it extracts the masked region onto a black background; with the optional dst fed, it pastes src's pixels into dst where the mask is active, leaving the rest of dst untouched. That dst distinction is the one real design feature - it's an OpenCV out-parameter that happens to be load-bearing here, giving you extract vs. composite in a single node.

It's the low-level compositor for mask-based workflows - pulling a detected region out for a detailer pass, pasting a refined crop back, or restoring original pixels into areas an inpainting pass shouldn't have touched. Exactly the loop the detection/inpainting docs describe, one layer down from the fancy SEGS and detailer nodes.

Install and shared caveats

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

Or ComfyUI Manager → opencv-comfyui → restart.

Same pack rules as everywhere: it runs on numpy NPARRAYs - Image2Nparray (batch 1 only) converts your Comfy IMAGE in - and src and mask must be the same size or you get an assertion error. The mask should be single-channel uint8; a float tensor from a masking node needs converting first. And BGR, not RGB - the whole pack speaks it.

Between copyTo_0 and copyTo_1, there's nothing to compare. Same inputs, same outputs, same behavior. The suffix is auto-generation noise from overloaded type signatures; wire whichever your workflow references and move on.