cv2.CV_64SC

cv2.CV_64SC builds the signed-64-bit integer type code - int64, the depth newer OpenCV builds expose so that an array can hold the same integers numpy and torch do. In bmad4ever's ComfyUI CV pack it's one node in a row of eight constant builders: an INT widget named channels in, an INT named int out, wrapping the CV_64SC(channels) macro.

It's honest to say you're unlikely to need it, and more useful to explain why it's there than to pretend otherwise. The pack generates a node for every top-level function and constant cv2 exposes - about 470 wrappers, according to the README, produced mechanically from the library's type stubs, and the author describes them as auto-generated and uncurated. So when a depth like 64-bit signed integers appears in the API, it gets a node. The same mechanical pass is why this pack's registry even carries an entry where two constant names got concatenated into one by the generator. None of that is a defect in this node; it's the nature of a wrapper set built by parsing an API surface instead of by choosing features.

What it means, and when it's the right depth

OpenCV type codes pack depth and channel count into one integer - depth + ((channels − 1) << 3) - so a code is how you tell a function "give me this kind of array". Signed 64-bit is for exact integer arithmetic where 32 bits can overflow: sums and counts over very large arrays, indices into big datasets, identifiers that must not wrap. It is not a pixel format, and nothing about image processing needs it.

In this pack, that means NPARRAY-space data management: an array you're counting, indexing or accumulating and whose total won't fit in int32. You'd pass the code to a wrapper's dtype parameter after converting that widget into an input (right-click → Convert widget to input), and you should check that the function you're feeding actually implements the 64-bit path - kernel coverage for the wide integer depths is much thinner than for the float ones, so an "unsupported type" from inside cv2 is a plausible outcome rather than something you did wrong.

The unchanged cautions apply. channels defaults to 0, and the macro computes channels − 1 from it, so a zero gives you a negative nonsense code - set 1. And the node casts nothing: CV Cast Array performs conversions, CV DType reports an array's dtype as a STRING, and a constant node only produces the number.

So when should you actually care?

Two situations, both peripheral. First, debugging: if an array in your graph is behaving like an integer when you expected floats (a truncating division, a comparison that's always false), checking the dtype with CV DType and Inspect CV Data is how you find out, and recognising the integer codes - 4 for int32, and the 64-bit ones alongside it - is part of reading that output. Second, interop: newer OpenCV APIs hand back 64-bit integer arrays for indices and counts, and you may need to reason about them before casting down to something the image path can carry.

If you want the practical version of this whole family: cv2.CV_32FC is the one that fixes a real and common bug (derivative filters truncating on 8-bit images), cv2.CV_16SC gives you CV_16SC2, the fixed-point remap map that makes stereo rectification fast, and the 64-bit integer code is a completeness artifact. Knowing which is which is more useful than using all eight.

Installing it

Manager → search the pack title (ComfyUI CV) → install → restart. Manual:

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 recent ComfyUI on the V3 node API. Two version notes specific to these constants: the registry is generated against the OpenCV you actually have, so a depth your build doesn't expose gets no node (no error, just silence), and the wide integer depths belong to the newer type system - on an older OpenCV they may be absent entirely. The contrib wheel is required; a non-contrib opencv-python installed over it strips the contrib submodules out of the shared site-packages/cv2 and nodes disappear (tools/repair_opencv_contrib.py --check/--apply).

Common issues and troubleshooting

Negative output. channels left at 0 - set 1.

The output won't connect. It's a plain INT for a numeric input. Convert the destination widget to an input first.

"Unsupported type" from cv2. The function doesn't implement that depth. Cast with CV Cast Array to something it does support, or keep the work in CV_32FC.

The node is missing from the list. Your OpenCV build doesn't expose it. The pack skips what the build lacks rather than failing at import; check cv2.__version__ before assuming a broken install.

You're tempted to route the array through CV Array → Image. Don't - an identifier interpreted as a brightness is noise. Keep it as data and use the array-aware nodes.