OpenCV composeRT_1

composeRT_1 is composeRT_0 wearing a different ID. Same cv2.composeRT call, same ten outputs, same behavior - I diffed the two node classes and the only difference is the name. This is what you get when a pack auto-generates a node for every overload in OpenCV's type stubs: cv2.composeRT declared two signatures, the generator numbered both, and you end up with a duplicate in your menu. Use composeRT_0, ignore this one, move on.

The short version

Composes two rigid-body transformations:

• rvec1 / rvec2 (NPARRAY) - rotation vectors (3×1 Rodrigues, not 3×3 matrices).
• tvec1 / tvec2 (NPARRAY) - translation vectors (3×1).
• Eight optional Jacobian out-params (dr3…, dt3…) - skip them, per the README's "avoid the out-parameters" advice.

Outputs: nparray_0 (composed rotation vector), nparray_1 (composed translation), then eight derivative matrices. Only the first two matter for most work. The result means: R = R1 * R2, t = R1 * t2 + t1 - chain two camera poses into one.

Install

Standard for this pack:

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

or ComfyUI Manager → "opencv-comfyui". Needs opencv-python-contrib (also numpy, torch in requirements.txt). The one OpenCV-environment trap to know: Cannot import name 'guidedFilter' from 'cv2.ximgproc' means conflicting OpenCV installs - clean up to a single one.

The honest framing

This is deep 3D-vision math, not an image tool - you'd only use it for pose-estimation, calibration, or camera-rig composition, and the inputs are pure nparrays rather than anything you'd get from a Load Image node. And since it's a byte-for-byte duplicate, the only reason to know composeRT_1 exists is so you don't spend ten minutes wondering whether the _1 variant does something extra. It doesn't.