cv2.ximgproc.FastHoughTransform

Set expectations first, because this is where everyone bounces off: FastHoughTransform does not return lines. No endpoints, no rho, no theta. It returns the raw Hough accumulator - a matrix where the votes for candidate lines have been piled up - and peak-picking is a problem you now own. If what you wanted was "find me the lines in this image", the pack's generated cv2.HoughLinesP wrapper or the curated CV Detect Lines (Hough) node (Canny plus probabilistic Hough in one step) is the sane door.

What FHT gives you instead is speed and control. It's the fast approximation of the Hough transform, and for a binary edge image at video resolution it's the one that keeps up.

How it works

Your src should be a binary image - run Canny or a threshold first, because FHT accumulates votes from non-zero pixels. Every non-zero pixel votes for all the lines that could pass through it within your chosen angle range, and the votes are combined with the operator you select.

Output is a single NPARRAY of transform coefficients. That's it. It's not a picture of the scene; it's a histogram in coordinates you have to interpret. Send it to Inspect CV Data to see its shape in the first place, then feed it to CV Array → Image (which min-max normalizes floats) if you want to look at the accumulator - real lines show up as bright dots or ridges.

The four knobs

• dstMatDepth (CV_32S by default) - the accumulator's depth. Stays at CV_32S; the tooltip says sums overflow an 8- or 16-bit accumulator on a large image, and an overflowing vote count is silent garbage.
• angleRange (ARO_315_135) - which band of line directions gets searched. ARO_315_135 covers everything; the narrow options (ARO_0_45, ARO_90_135, …) are much faster when you already know you want near-horizontal or near-vertical lines. This is the single biggest speed lever.
• op (FHT_ADD) - how votes along one line are combined. FHT_ADD is the standard sum, FHT_AVE normalizes by line length so long and short lines compete fairly, and FHT_MIN/FHT_MAX look for fully-covered or brightest lines respectively.
• makeSkew (HDO_DESKEW) - the accumulator layout. HDO_DESKEW gives the rectified layout that OpenCV's own HoughPoint2Line expects; HDO_RAW keeps the skewed internal one. If you're reimplementing the standard FHT peak-search recipe, leave it deskewed.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart, or install ComfyUI CV from ComfyUI Manager. Python ≥3.12, a recent V3-API ComfyUI, and opencv-contrib-python-headless~=5.0.0.93. Nothing to download - ximgproc comes from the contrib wheel, so a non-contrib OpenCV install is the one thing that breaks this node. If it disappears from the menu, tools/repair_opencv_contrib.py --check will tell you why.

Common issues

"It returns noise." Usually a colour photo went in instead of a binary edge map. Every pixel voting for every line drowns the real structure - you get a near-uniform accumulator.

Output looks almost black when previewed. Of course it does: raw vote sums are small numbers in a big matrix, and previewing min-max normalizes them. That's fine for eyeballing, misleading for measuring.

Zero lines found. Not a bug and not even an error - the node emits an accumulator regardless. Also remember src takes a ComfyUI IMAGE/MASK directly (frame 0 of a batch) or an NPARRAY, and if you're feeding a batch you're only transforming frame 0.

You still need your own peak finder. There's no threshold, no min-line-length, no output of coordinates here. This is one of the pack's ~470 auto-generated raw cv2.* wrappers, and the README is upfront that they're uncurated: conversions and edge cases are on you. If you want the answer rather than the ingredients, use the Hough wrappers with HoughLinesP semantics instead.