cv2.getVersionMinor

The middle number of the OpenCV version: 0 in 5.0.0, 12 in 4.12.0. It's the one that moves when OpenCV adds functions, which makes it the digit that answers the specific class of complaint this pack generates most: "the workflow has a node I don't have."

How the pack turns a version mismatch into missing nodes

ComfyUI CV doesn't ship hand-written wrappers for four hundred-odd cv2 functions. It generates them: metadata comes from the type stubs of the installed OpenCV, and each entry is checked against the real library at import time. If the function isn't exposed by your build, the node simply isn't created - no placeholder, no error, no note in the menu. Same story for contrib submodule functions, which only exist at all in contrib wheels.

So the symptom of a minor-version difference is an absence. A workflow built on a machine whose OpenCV has a function that yours doesn't will open with red nodes and unhelpful console output. The version getters are how you cut that down to size in ten seconds: check cv2.getVersionString on both machines, compare the first three numbers, and stop blaming the workflow.

Worth knowing for context: this pack's registry was generated from the stubs of a 5.1.0-dev build, while its behaviour is curated against the released 5.0.0.93 contrib wheel. Minor versions in that neighbourhood are where the new cv2 additions live - the generator's own notes call out a handful of 5.0 additions it wraps (things like rescaleDepth and correctChromaticAberration, which simply don't exist in 4.x).

Using it

No inputs, one int out, and - as with every scalar in this pack - the only interesting question is where the number goes. Inspect CV Data takes any value and emits a text summary you can display with core's Preview as Text; alternatively, link it into a converted integer widget if the value should drive something. If you want all three version components at once, cv2.getVersionString is the cheaper read, and CV Build Information gives you the full build banner (with build-machine paths redacted - the raw getBuildInformation wrapper is deliberately excluded from the pack for that reason).

It's a diagnostic node, so the realistic use is a small "what is this machine" workflow you keep around: the version getters, the two thread counters, a tick pair. That's a genuinely useful artefact when you work across two boxes or a rented GPU instance.

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 recent ComfyUI built on the V3 node API - the whole pack is generated at import, so a mismatch there looks the same as a version mismatch (nodes that don't exist).

Gotchas

• Contrib, always contrib. All four OpenCV PyPI distributions share one site-packages/cv2, so a plain opencv-python install over the contrib wheel silently removes the contrib submodules and a chunk of this pack's nodes with them. tools/repair_opencv_contrib.py --check then --apply.
• Installed ≠ imported. A venv can have several wheels having been installed at different times; only the last one on disk is what Python sees. This node reports reality, which is exactly why you ask it rather than pip list.
• Support expectations are low by design. The README says updates aren't planned and that the pack was developed with heavy LLM assistance, with uncurated auto-generated wrappers. When something's missing, assume environment first and workflow second - the environment is the part you can actually check.