cv2.getVersionMajor

One integer out, no inputs: the leading number of the OpenCV version your ComfyUI process loaded. 5 or 4. That single digit is the most consequential of the three version getters in this pack, because the 4→5 jump is a real API boundary, and this pack lives on the far side of it.

Why the major number decides whether your pack works

ComfyUI CV is generated from cv2 5.x. Its registry of wrappers - around 470 of them, plus the contrib submodule functions - is built from the type stubs of the installed OpenCV, and each entry is probed against the actual library: if the function isn't there, the node is skipped instead of shipped broken. That design is doing you a favour when the version is wrong, and it's also why the symptom is confusing. You don't get "OpenCV 4 detected, expected 5". You get a node pack with holes. A shared workflow opens with two red nodes, the console says nothing useful, and the answer is a single digit reported by this node.

OpenCV 5 also adds functions the pack wraps - things like rescaleDepth and correctChromaticAberration - so a 4.x install doesn't just behave differently, it's missing entries the pack's own example workflows demonstrate. The pack's stated curation target is the 5.0.0.93 contrib wheel.

Reading it

int out, which in ComfyUI has nowhere obvious to go: wire it into Inspect CV Data (its value input accepts any type) and preview the summary string with core's Preview as Text. Or link it into a converted integer widget if you want the value to drive something. Same pattern for cv2.getVersionMinor and cv2.getVersionRevision; if you just want one readable string, cv2.getVersionString gives you all three numbers at once, and CV Build Information gives you the whole banner.

Practical setup: this is a node you add to a diagnostic workflow next to the three other version getters and a couple of thread counters, save it, and drop it onto the canvas any time a machine misbehaves. It costs nothing to run and it retires a whole category of guesswork - "is the environment different, or is the workflow wrong?"

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

Then restart. Python ≥ 3.12 and a current ComfyUI on the V3 node API are required - the version getters are generated like everything else, so on an old ComfyUI the node won't even appear.

Gotchas

• The version you pip-installed isn't necessarily the version you imported. All four OpenCV PyPI distributions share one site-packages/cv2, so whichever wheel was installed last wins - and a non-contrib wheel installed over a contrib one empties the contrib submodules, making an unknown subset of this pack's nodes disappear. tools/repair_opencv_contrib.py --check (then --apply) is the pack's own diagnosis and repair path.
• Check it before you file a bug. With this pack there's no support queue to file into - the README states that updates aren't planned and prompt support shouldn't be expected - so the version check is more valuable than usual. It converts "this node is broken" into "this node doesn't exist on my build", which is a different problem with a different fix (install the contrib 5.0.0.93 wheel).
• Major version alone isn't the whole story. getVersionMajor telling you 5 doesn't mean the build has contrib, or that the minor matches what the pack's examples expect. If you're going to the trouble of checking, grab the string.