OpenCV undistortPointsIter_1

Every lens bends light, and undistortPointsIter is the math that un-bends it for a list of 2D points instead of for a whole image. Feed it pixel coordinates that were captured through a distorted lens, plus the camera's calibration, and it hands back where those points would sit on an ideal, flat, distortion-free projection. If you've ever wondered why the OpenCV-camera folks get so pedantic about "intrinsics" and "distortion coefficients" - this is one of the nodes that makes that pedantry pay off.

The first thing to know: this is not an image node. The sibling undistort_0 in the same pack reshapes pixels so a warped photo looks straight; this one reshapes coordinates so downstream geometry math is correct. You reach for it when you're doing camera calibration, pose estimation (solvePnP lives in this pack too), augmented-reality-style alignment, or stitching where a lens's radial distortion is bending where tracked features land. For plain image generation, honestly, you almost never need it - which is fine, because "the whole image" version is what your compositing actually wants.

How it works

It's the iterative big brother of undistortPoints. The non-iterative version assumes mild distortion and corrects points in a single closed-form step. undistortPointsIter instead runs a Levenberg–Marquardt optimization - it keeps nudging the undistorted points until the re-projection error stops shrinking or it hits your stopping condition. That extra work buys real accuracy under strong radial distortion, the fisheye-ish cases where the one-shot version drifts. It's still one call and milliseconds; you just pay a little more compute for a more honest answer.

Inputs and outputs

The three that carry the weight:

• src - the points to correct, an NPARRAY of 2D coordinates (say, N×2 or N×1×2 float).
• cameraMatrix - the 3×3 intrinsics (fx, fy, cx, cy) as an NPARRAY.
• distCoeffs - the distortion coefficients, typically 1×4 to 1×18.

Then there's criteria, which is the fiddly one. It's a STRING that the pack parses as a Python literal into OpenCV's TermCriteria - the tuple (type, maxCount, epsilon). A sane starting point is (3, 30, 0.01), where 3 means "count + epsilon" (TermCriteria::COUNT | EPS), 30 caps the iterations, and 0.01 is the epsilon you're chasing. R and P are optional rectification/projection matrices - pass identity if you don't have them, or leave the optional dst out entirely; the README's advice to skip out-params applies here.

The single output, nparray, is the corrected point set, same shape as src. In ComfyUI terms: it's a raw nparray, not an image, so you'd feed it to whatever point-hungry node comes next, or save it with imwrite if you're persistent.

Installing

Everything in this pack installs the same way. Via ComfyUI Manager, search "opencv-comfyui" (it also brands itself as "OpenCV") and install. Or do it by hand:

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

then restart ComfyUI. The pack's requirements.txt pulls in opencv-contrib-python, numpy, and torch - note the README prints the package name slightly wrong (opencv-python-contrib isn't on PyPI), so let the requirements file do the installing.

Common issues

• Where do cameraMatrix and distCoeffs come from? The pack doesn't ship calibrateCamera, so you usually bring these in from a calibration you ran elsewhere and saved (a .npz/.npy loaded through another node). Don't invent them - garbage intrinsics make the output confident and wrong.
• invalid syntax (<unknown>, line 0) on criteria means your literal isn't a valid Python tuple. It must look like (3, 30, 0.01), not 3 30 0.01.

This is one of the pack's "expect dragons" corners: auto-generated from OpenCV's type stubs, real, and genuinely useful - but only once you already have calibration data in hand.