OpenCV HoughLinesPointSet_1

HoughLinesPointSet_1 is the duplicate overload of HoughLinesPointSet_0 - identical inputs, identical output, identical cv2.HoughLinesPointSet call underneath. The opencv-comfyui generator emits a node per Python binding and leaves twins like this in place across the whole pack. Everything in the _0 article applies here verbatim; use whichever ComfyUI shows you.

What it does (briefly)

It applies the Hough voting idea to a set of points instead of a pixel image. Points vote for the (rho, theta) lines through them, and lines clearing threshold votes come back as [rho, theta] pairs, shape (N, 1, 2).

The inputs: point (an (N, 1, 2) float32 nparray of (x, y) coordinates - this exact format is the whole challenge), lines_max, threshold, min_rho/max_rho/rho_step, and min_theta/max_theta/theta_step. The lines optional input is the generator's out-parameter; leave it alone.

Who should care

This is a niche-inside-a-niche node. It shines when you already have a scatter of coordinates - corner detections, tracked keypoints, geometric point clouds - and want to recover the lines buried in them. It does not look at an image's pixels, so it's the wrong tool for "find the lines in this photo": that's HoughLinesP_0 or HoughLines_0 with a Canny edge map in front. The practical blocker in ComfyUI is producing the (N, 1, 2) float32 point array in the first place - nothing in the pack's default image flow hands you one, which is exactly the "expect dragons" reality the author flags.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/geroldmeisinger/opencv-comfyui

or "OpenCV" via ComfyUI Manager, plus pip install opencv-contrib-python. No model files.

Bottom line

_0 and _1 are the same function; don't deliberate. Spend your energy on the input array format if you go down this path, and on choosing the right Hough node for the job - for images that's the P variant, for raw point sets it's this one.