cv2.aruco.drawDetectedCornersCharuco

This is a debugging-and-paperwork node: it draws the chessboard corners that a ChArUco detection found onto your image. If you're doing camera calibration with a ChArUco board - or building a text-anchored overlay from board coordinates - you want to see which corners were found before you trust the numbers.

It's an aruco-module wrapper, and that module only exists in the contrib build of OpenCV. Which makes this node a direct test of whether your install is healthy.

How it works

Two inputs and a colour: the image to draw on, the corner array from detection, and an optional colour. OpenCV draws the detected corner points onto the image in place; the pack's wrapper passes a private copy, so the array you linked in upstream isn't modified.

ChArUco boards are chessboard squares with ArUco markers inside them. Because the markers identify which square each intersection belongs to, detection survives partial views, occlusion and clipping at the frame edge - the failure mode that makes plain findChessboardCorners unusable in real photos. The corners come out of the pack's curated CV ChArUco Detect, which also emits the corresponding 3-D object points, marker corners and IDs.

The node's output is an NPARRAY - not an echo of the input format. That's the difference between this and the drawing wrappers in the cv2.* drawing family: this one is registered as a data-producing function, so an IMAGE goes in and raw pixels come out. Preview and save it through CV Array → Image.

Inputs and outputs

• image (NPARRAY,IMAGE,MASK) - the photo to draw on. IMAGE arrives as uint8 BGR.
• charucoCorners (NPARRAY,IMAGE,MASK) - the detected corners, from CV ChArUco Detect.
• cornerColor (optional STRING) - an OpenCV scalar literal like "(0, 255, 0)" (BGR). Leave it blank for OpenCV's own default.
• nparray - the annotated image, as a raw array.

What it's for

• Verifying a calibration run. Overlay the corners on one of the calibration frames and look. Corners in the wrong place (or forty of them on a board with seventy) is the fastest way to find a cols/rows or dictionary mismatch - the board parameters must match the printed board, and getting them wrong silently finds nothing or finds nonsense.
• Sanity-checking a partial view. The whole selling point of ChArUco is detecting corners with half the board out of frame. This node is how you confirm it did.
• Debug artefacts for documentation. If you're publishing a calibration pipeline, corner overlays are the figure everyone expects.
• Feeding a pose pipeline visually. The same corners plus object points go to CV Solve PnP Pose; the drawing is how you prove the pairing is right.

The pack also has CV ArUco Draw Markers for the marker outlines themselves, and CV Draw Labels / CV Annotate Points when you want your own annotations rather than OpenCV's rendering.

Install

ComfyUI Manager → comfyui_cv (ComfyUI CV), or:

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

Restart ComfyUI. Python ≥ 3.12 and a recent ComfyUI on the V3 node API; behaviour is curated against OpenCV 5.0.0.93. The contrib requirement is not optional here. All four OpenCV distributions share one site-packages/cv2, so installing opencv-python or opencv-python-headless over the contrib wheel silently empties the contrib submodules - and cv2.aruco stops existing, taking this node with it. tools/repair_opencv_contrib.py --check diagnoses that, --apply repairs it.

Where people get burned

The output won't preview. It's an NPARRAY. Add CV Array → Image and carry on.

Nothing drawn. Either the detection found zero corners (a legitimate, non-error outcome on a bad frame - the detect node reports found = false) or the corners array is empty. Check the detection before blaming the drawing.

Corner count looks wrong. Board parameters: cols/rows in squares (not inner corners), and the dictionary must match the printed board. A mismatch is the number one ChArUco headache.

No aruco module at all. The node won't even appear if the registry was generated without contrib. Repair the wheel.

Wrong corner order later. Drawing doesn't care about order; solvePnP absolutely does. If your pose is flipped or rotated, the pairing of corners to object points is where to look - the detect node emits them together for that reason.