cv2.getVersionString

No inputs, one STRING out: the OpenCV version your ComfyUI process actually loaded. You'd think this belonged in a build-info panel rather than a workflow, and normally you'd be right - but "which OpenCV is this server using?" is the first question in a startling number of this pack's failure modes, and it's the cheapest one to answer without shelling into anything.

Why it matters more here than for a normal pack

This pack's nodes are generated at import time from a registry built from the cv2 type stubs, and every entry is probed against the installed OpenCV - an entry whose function the build doesn't expose is skipped rather than shipped broken. The practical consequence: a version mismatch doesn't announce itself with an error. You get a node pack with holes in it. A workflow someone shared opens with two nodes missing and no explanation, and the reason is that their machine had OpenCV 5.0 and yours has 4.12, where a function simply isn't there.

The pack is curated against 5.0.0.93 and its README says outright that other versions may behave differently. So the version string is your first diagnostic, not your last.

Reading the string

Feed string into Inspect CV Data - its value input takes anything - and send the resulting summary to core's Preview as Text node. That's the universal reading pattern for non-image outputs in this pack, and it works here because the output is just text.

Expect something like 5.0.0 or 4.12.0. Two things to know about that:

• Don't go looking for the .93. The PyPI version of the wheel is 5.0.0.93, but the fourth component is the package build counter, not part of OpenCV's own version. The library reports 5.0.0. If you're comparing what pip installed against what Python loaded, compare the first three numbers.
• A -dev suffix is possible. The pack's registry was generated from stubs for a development build (5.1.0-dev in the generator header), so strings like that are legitimate rather than alarming.

If you want the whole picture instead of three numbers, the pack ships a curated CV Build Information node: OpenCV's full build banner - compiler, third-party libs, Eigen/non-free/OpenCL/CUDA availability - with build-machine paths redacted. The raw cv2.getBuildInformation wrapper is deliberately not in this pack, because that banner leaks paths from whoever compiled it, which for a self-built OpenCV is you.

Install

pip install "opencv-contrib-python-headless~=5.0.0.93"

ComfyUI Manager → search ComfyUI CV, or:

cd ComfyUI/custom_nodes
git clone https://github.com/bmad4ever/comfyui_cv

Restart after. Python ≥ 3.12 and a recent ComfyUI on the V3 node API are required.

The trap this node exists to catch

All four OpenCV PyPI distributions - opencv-python, opencv-python-headless, opencv-contrib-python, opencv-contrib-python-headless - share a single site-packages/cv2. Install a non-contrib wheel over a contrib one and the contrib submodules are silently emptied: no error at install time, no error at import, just a set of nodes that stop appearing in the menu. Some other pack, or a stray pip install from a requirements file, is all it takes.

The pack ships tools/repair_opencv_contrib.py for exactly this: --check tells you whether contrib is intact, --apply reinstalls it. Run the check when nodes go missing before you start re-cloning repositories.

And the standing advice for anything intermittent here: change one thing, keep everything else fixed, and confirm the version before and after. A pack that behaves differently on two machines with the same workflow is usually two machines with different OpenCV, and now you have a node that says so out loud.