OpenCV goodFeaturesToTrack_3

goodFeaturesToTrack_3 is goodFeaturesToTrack_2 in a wig. Same required inputs, same optional corners, same N×1×2 float32 output of (x, y) corners. Load both and feed them the same image and they return the same points. There is no functional reason to prefer one. The difference between them is only in the order the pack's generator listed the overloads when it parsed OpenCV's type stubs - and that's worth understanding, because it explains half the duplicate nodes you'll find in this pack.

What "overload" means here

cv2.goodFeaturesToTrack is declared multiple times in OpenCV's Python stubs, each with a slightly different signature (this family has four variants: two without gradientSize, two with). The auto-generator wrapped each as its own numbered node. When two overloads collapse to the same set of node inputs after wrapping, you get identical twins - _0/_1 are one pair, _2/_3 are another. It's a completeness-over-curation artifact the author explicitly flagged with "Expect dragons!" in the README. Not a bug, not a feature - a byproduct.

Using it

If you insist on using _3, here's the job it does: Shi-Tomasi corner detection confined to a region via the required mask (NPARRAY, single-channel, nonzero = search area), with gradientSize (INT, odd, typically 3–7) controlling pre-gradient blur. maxCorners, qualityLevel (~0.01), minDistance, blockSize, useHarrisDetector, and k behave exactly as in the rest of the family. The output is a point list, not an image - route it to a circle node to draw, or into optical flow to track, and never into Nparrays2Image (that yields the pack's 'NoneType' object has no attribute 'shape' error).

But honestly, use _2. The one real reason to standardize on _2 over _3 is workflow clarity: when you share a graph, the person loading it sees goodFeaturesToTrack_2 and recognizes it as the canonical "masked + gradientSize" variant, while _3 reads as an accident. Nothing breaks either way.

Install

Standard pack install:

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

or ComfyUI Manager, search "opencv-comfyui", restart. Needs opencv-contrib-python; numpy/torch ship with ComfyUI. No models, no keys. Known startup issue to keep in mind: Cannot import name 'guidedFilter' from 'cv2.ximgproc' means conflicting OpenCV packages - uninstall duplicates and keep a single opencv-contrib-python.

Bottom line

The existence of _3 next to _2 is the pack's thesis statement: every function wrapped, no judgment applied. Don't waste time comparing them - there's nothing to compare. Pick the canonical _2, and spend your attention on mask and gradientSize, which are the inputs that actually change your corner detection. This node is the duplicate you can safely ignore, which makes it one of the pack's most honest articles to write.