cv2.omnidir.stereoReconstruct

This is the whole omnidir stereo pipeline behind one node. Give it two views from a calibrated fisheye or catadioptric rig, both cameras' intrinsics, distortion and mirror parameter, plus the relative pose, and it rectifies, matches, triangulates, and hands you a rectified pair, a disparity map and a 3D point cloud. For the narrow case it targets, that's a genuine one-stop node rather than a raw function wrapper with plumbing to add.

Inputs

Nine required links, and every one of them is an array, so this node is only as good as your calibration:

• image1, image2 - the stereo pair, one frame each.
• K1, D1, xi1 and K2, D2, xi2 - per camera: 3×3 intrinsics, the omnidir distortion vector (four values in this model), and the mirror parameter. xi = 0 is a pinhole; around 1 is a strongly curved lens or mirror.
• R, T - the relative rotation and translation between the two cameras.

Then the matcher's three knobs, all integers:

• flag - which projection the internal rectification targets, the same family of choice the undistort-rectify maps offer (perspective / cylindrical / stereographic). A bare integer, no dropdown.
• numDisparities - the disparity search range in pixels, and it needs to be a multiple of 16, the same rule OpenCV's other stereo matchers follow. Too small and the near half of the scene falls off the end of the search; too large and you pay for pixels that never match.
• SADWindowSize - the matching block size, odd (5, 9, 11 are the usual stops). Bigger is smoother, slower, and blurrier across depth edges.

Two optional inputs: newSize, a (w, h) CV_TUPLE for the rectified output size, and pointType, a string literal ("0", "1", … drawn from the module's constants) selecting whether the cloud is plain XYZ or carries colour. Both are the kind of parameter whose meaning you read off OpenCV's own cv2.omnidir docs, because the tooltips on this node are blank - the contrib stubs ship no documentation, so the generator had nothing to extract.

Outputs

Four NPARRAYs, and the wrapper names them nparray_0 through nparray_3, which tells you nothing. The underlying call produces the two rectified images, the disparity map and the point cloud; the sockets are in that order, and previewing each once with Preview CV Array is a two-minute job that removes all doubt - the rectified frames look like photographs, the disparity is a grayscale ramp, and the cloud is an N×3 (or N×6) array.

If you'd rather not reverse-engineer sockets, the pack ships a curated CV Omnidir Stereo Reconstruct node that does the same job with named outputs and reports a validity mask so you can tell "this cloud is real" from "this cloud is noise". For a task where success and failure look similarly like a grey blob, that's worth the extra click.

From there the cloud is data, not an image. The pack has point-cloud nodes (downsample, normals, preview, registration) and the KB's 3D doc makes a point worth repeating: a point cloud is usually an intermediate before meshing, and it's rarely the deliverable.

Install

ComfyUI Manager → search ComfyUI CV → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv
pip install "opencv-contrib-python-headless~=5.0.0.93"

Python ≥ 3.12, ComfyUI on the V3 node API. cv2.omnidir is contrib-only; if this node is absent, suspect a non-contrib opencv-python-headless installed over the contrib wheel - tools/repair_opencv_contrib.py --check / --apply is the repair.

Straight talk before you spend an afternoon on it

Three things, in order of how much time they'll save you.

Calibration dominates everything. A slightly wrong xi or a poorly fitted distortion vector and you get a cloud that looks like confetti. The pack's CV Omnidir Calibrate (Chessboard) and its 54_omnidir_calibration example are the front half of this pipeline, and they're not optional.

This is not the node most people want. The KB's depth docs are blunt that the ecosystem's default for "3D from images" is a learned monocular model - one photo, no rig, no calibration, and often good enough that nobody buys a stereo rig. Reach for stereoReconstruct when you have the hardware and want geometry with an actual metric explanation.

The README says so itself. The author warns that the bundled stereo workflows were tuned against a specific dataset (StereoGeo-CARLA) and are not production-grade - individual nodes can still be genuinely useful, but verify against your own data before trusting a pipeline.