OpenCV correctMatches_1

correctMatches_1 is the auto-generated twin of correctMatches_0 - same call to cv2.correctMatches, same inputs, same two outputs, interchangeable. So the useful thing to add here isn't more of the same; it's the part every tutorial skips: where does the F matrix come from, and why does the whole thing fall apart without it?

The dependency chain, spelled out

correctMatches corrects point pairs against a fundamental matrix F, the 3×3 object that encodes the epipolar geometry between two views. You can't fake it. The honest pipeline inside this pack:

1. Detect matched features between two images (feature extraction + matching - the pack has the primitives; matching itself may take other nodes).
2. Compute F with findFundamentalMat_0 (this pack) from the raw matches. findFundamentalMat is the 8-point/RANSAC solver that produces the matrix.
3. Feed F, points1, points2 into correctMatches_1.
4. Get corrected nparray_0 and nparray_1 back, and hand those to whatever triangulates or reconstructs.

The point of the correction step is that step 2's raw matches are noisy. findFundamentalMat already filters with RANSAC, but the surviving inliers still don't lie exactly on epipolar lines. correctMatches pushes them there, which is precisely the difference between a reconstruction that's "close" and one that's numerically stable.

Inputs and outputs

• F - 3×3 fundamental matrix, float.
• points1, points2 - matched points, N×2 or N×1×2, float32, same order in both.
• newPoints1 / newPoints2 - optional out-parameters; leave unconnected (README's standing advice on dst-style inputs).
• Outputs: nparray_0 and nparray_1, the corrected point sets.

Both outputs are point data, not images - wiring them into Nparrays2Image gives you the NoneType shape error.

Install

ComfyUI Manager → search opencv-comfyui → install, or:

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

Restart. Requirements: opencv-contrib-python, numpy, torch. No models.

Gotchas

• The _1 suffix means nothing - same overload twin as everywhere in this pack.
• Bad F = garbage out. If your fundamental matrix came from the wrong solver or wrong view ordering, "correcting" against it makes things worse, not better.
• dtype discipline - float F, float32 points. OpenCV asserts on this.
• Sub-pixel corrections look like no-op - they're the whole point; verify by numbers.

This is the geometry end of the pack, where "expect dragons" applies to the plumbing, not the math. Nail the F step and correctMatches_1 is the quiet workhorse that keeps your 3D honest.