cv2.CV_64FC

cv2.CV_64FC builds the double-precision (float64) type code. In the ComfyUI CV pack it's a node with one INT input, channels, and one INT output, int, wrapping OpenCV's CV_64FC(channels) macro. You'll use it less than the float32 one, but not never - there are places in OpenCV where double precision isn't optional, and knowing which ones saves you from a slow, oddly-wrong graph.

The rule of thumb: pixels don't need float64; geometry and solvers do. Calibration, pose estimation, homography and fundamental-matrix fits, SVD, eigensolvers and polynomial solves all produce CV_64F arrays in OpenCV, because accumulating over thousands of coordinates in float32 loses real accuracy. Kernel construction is the other place: getGaussianKernel and getGaborKernel default to a CV_64F kernel, and this pack's own defaults follow OpenCV exactly - its ktype widgets preset CV_64F for those two and CV_32F for getDerivKernels. cv2.rescaleDepth offers a two-option dropdown of CV_32F/CV_64F and nothing else, which tells you what the API considers the usable float depths.

How the code works

Depth and channel count are packed into one integer: depth + ((channels − 1) << 3). CV_64F is depth 6, so CV_64FC(1) is 6 and CV_64FC(3) is 22. Filters' ddepth parameters want the depth part; arithmetic dtype parameters can carry a full type with channels.

channels defaults to 0, which the macro turns into a negative nonsense code (it computes channels − 1). Set 1 unless you specifically need a multi-channel double array.

The output is a plain INT named int. Convert the receiving widget to an input first - right-click → Convert widget to input - and wire it. In this pack the ddepth/dtype/ktype parameters that take these codes render as plain integer widgets unless the author enumerated a closed set, so typing 6 is an equally valid route. The nodes exist because the pack's ~470 raw wrappers are generated from the cv2 type stubs rather than hand-picked; the README says so plainly.

The conversion caution is the same as ever: this node builds a code, it doesn't cast anything. CV Cast Array is the node that changes an array's dtype, and CV DType reports one.

Reality check on double precision in a ComfyUI graph

Two honest caveats. First, float64 lives in NPARRAY space. ComfyUI's IMAGE is a 3-channel float32 tensor, so a CV_64F array can't ride the image wiring; that's fine, because the data that wants double - camera matrices, poses, homographies, point clouds - is exactly the data the pack already carries as arrays. Second, the cost is real: eight bytes per element instead of four, and no SIMD fast paths to speak of.

So the discipline is: let the solver produce double (you don't get a choice, and you shouldn't want one), keep it double while you chain geometry operations, and convert deliberately at the boundary - CV Cast Array down to float32 when the numbers are going into an image-shaped operation. The pack exposes the same idea in the other direction with cv2.rescaleDepth, which exists specifically to move a depth map between the two float types without wrecking its scale.

One API rule worth knowing while you're here: OpenCV's accumulator destinations (the accumulate* family) are specified as 32F or 64F, precisely because they accumulate over many frames. If you're averaging a video sequence, that's the depth question you're answering.

Installing it

Manager → search the pack title (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 and a ComfyUI on the V3 node API - the pack is a V3 rewrite, not a legacy-mapping addon, so an older ComfyUI fails rather than limping. The install is a single pinned wheel; just don't let a non-contrib opencv-python land on top of it, because all four distributions share one site-packages/cv2 and the shared module quietly loses its contrib submodules. tools/repair_opencv_contrib.py --check/--apply is the repair, and python -c "import cv2; print(cv2.__file__, cv2.__version__)" is the one-line diagnosis.

Common issues and troubleshooting

Negative output. channels = 0. Set it to 1.

Values look like science notation with 15 digits after a bridge. They're doubles being displayed as floats; Inspect CV Data shows the real dtype and shape.

"Unsupported type" downstream. Several cv2 functions don't implement float64 kernels. Cast to CV_32FC(1) for the processing and back up if you need the precision at the end.

A solver result won't fit an image node. Correct - doubles stay in NPARRAY space. Bridge with CV Cast Array then CV Array → Image if you need to look at it as a picture.