cv2.CV_64UC

cv2.CV_64UC returns a single integer: the OpenCV type code for an unsigned 64-bit matrix with channels channels. No pixels, no array - one number. Unless you're doing something unusual, the interesting fact about this node isn't the value it returns, it's that it exists at all.

What the number is

The <depth>C(n) family is CV_MAKETYPE with a fixed depth, and the packing rule never changes: channel count sits in the high bits, depth in the low ones.

type_code = depth + ((channels - 1) << 3)

For the classic depths you can do the arithmetic in your head - CV_8U is 0, CV_32F is 5, CV_64F is 6 - which is why CV_8UC(3) == 16 and CV_32FC(1) == 5. The unsigned 32- and 64-bit depths are newer arrivals in OpenCV's depth set and are best not memorised: get the depth code from cv2.CV_MAKETYPE's own inputs, or just read what this node hands back.

The node's one input is channels, an INT, and its default is 0. That is not a channel count - set it to 1, 3 or 4. Raw wrappers pass your argument to cv2 untouched and let the chips fall.

What "it exists" tells you

This pack is generated: the ~470 cv2.* wrappers come from parsing the type stubs of a 5.x OpenCV, and at import time the pack resolves each name against your installed cv2 and quietly skips the ones that aren't there (getattr through the dotted name, callable check, node omitted). So a node in your menu is proof that the callable resolved in your build.

CV_64UC is one of the depths that OpenCV 4.x doesn't have. If this node is sitting in your image/CV/low-level/cv2 C folder, your environment is carrying a 5.x opencv-contrib-python-headless - the pack's pinned reference build is 5.0.0.93 - and the family around it (CV_32UC, CV_16BFC, and the rest) is the visible fingerprint of that. On a 4.x wheel, the node just won't be listed.

That's an unusually cheap environment check: no console digging, no pip show, just look for the node.

Should you use it?

For 64-bit unsigned matrices in an image workflow: no. There's no photography pipeline here, nothing in ComfyUI produces that dtype, and Load Image gives you uint8. If you're working in the array domain with this pack's data nodes - matrices, point sets, calibration output - you're in float32/float64 territory, and CV_64FC and CV_32FC are the members of this family you'd actually reach for.

Where it can bite is on the receiving end: several curated depth widgets in the pack offer CV_8U, CV_8S, CV_16U, CV_16S, CV_32S, CV_32F, CV_64F - that's the classic list. If you generated a code for a depth your consumer doesn't know, nothing will tell you until cv2 raises at execution. Check the dropdown's options first.

Install

Manager → Install Custom Nodes → ComfyUI CV (publisher bmad4ever), or by hand:

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

Restart ComfyUI when it's done. Needs Python ≥ 3.12 and a modern V3-API ComfyUI; the contrib headless wheel is the only dependency and these constant nodes need no models. Installed a plain opencv-python over the contrib wheel at some point? All four OpenCV distributions share one site-packages/cv2, so that silently empties the contrib submodules; the pack ships tools/repair_opencv_contrib.py --check (then --apply) for exactly that. The pack itself is GPL-3.0, a fork of geroldmeisinger/opencv-comfyui, LLM-written, with an explicit "not production-ready, updates not planned" notice.

Common issues

• Your number looks insane. channels is still 0.
• You can't find the node. Your cv2 is older than the pack's reference build. Update the contrib headless wheel, restart, look again.
• You tried to wire the INT output into a depth dropdown. Combos take names. The INT goes to raw INT parameters.