OpenCV selectROI_1

selectROI_1 is the UMat overload of cv2.selectROI with a window name - which, inside ComfyUI, means it behaves exactly like selectROI_0. The pack generated a numbered node per OpenCV type-stub overload, and this is the second copy. There is no setting to pick the backend, no behavioral difference, and no reason to prefer it over the _0 variant.

What it does

The job, briefly: pop a native window with your image, drag a rectangle, press Enter/space to confirm or c to cancel, and get the selected region back into the graph. Inputs: windowName (STRING - the popup's title), img (NPARRAY), and the three booleans showCrosshair, fromCenter, printNotice. The full context - why you'd interrupt an automated graph for a hand-drawn box, the headless-server failure, the blocking behavior, and the quirk where the STRING-typed "literal" output actually carries the raw (x, y, w, h) tuple - is in the selectROI_0 article. Nothing changes for this variant.

Installing

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

Install: ComfyUI Manager → search "opencv-comfyui", or the commands above, then pip install opencv-contrib-python for the dependency. No model downloads.

Verdict

The practical note for this whole family: selectROI_0 through selectROI_3 are the four overloads of one function - two named-window and two default-window, each doubled for MatLike/UMat. Whichever a workflow references, the behavior is the same family. This is a short article because it's a duplicate; the interesting one is next door.

Also worth knowing before you put it in a graph: the selectROI family blocks the workflow while the window is open, needs a display to run at all, and confirms on Enter/space (cancel on c) - so factor the human interaction into how you run things, not after the graph has already stalled.