cv2.getNumberOfCPUs

No inputs, one int out: OpenCV's own CPU count, as the library sees it. This is one of those nodes you'd never search for by name, and then you need it once - when you're wondering why a cv2 filter that should take 40 ms is taking 400, or when you want to pick a batch size that matches the hardware instead of a number you guessed on a different machine.

Why it isn't the same number as "my CPU has 16 cores"

cv2.getNumberOfCPUs() reports the processor count OpenCV's thread pool will size itself against. The practical consequences:

• Containers and VMs. In a Docker container with a --cpus=4 quota on a 32-core host, this typically reads as the host's count, because the underlying OS call reports what the machine exposes, not what your cgroup is allowed to burn. If you size anything against this number inside a container, clamp it yourself - otherwise you'll launch 32 OpenCV threads into a 4-core budget and watch everything get slower through context switching.
• Thread count is not the same number. This is the ceiling; cv2.getNumThreads is what's actually configured right now. Out of the box the second one tracks the first, but not every environment leaves it alone. Run both if you care.

What you'd wire it into

int outputs are a bit awkward in ComfyUI if you've only ever wired images around: an INT socket connects to a converted integer widget (right-click a widget → convert to input) or to the component sockets of CV Tuple, which is how this pack composes loose numbers into a composite (w, h) value. Reading it is easier than using it - drop it into Inspect CV Data and preview the summary as text, which also gives you a permanent on-canvas record of what the machine looked like when a run was captured. comfyui-node-plumbing.md is the full story on why value nodes and converted widgets are the right shape for this kind of scalar; the short version is that a value should have one source and many consumers, and this node is a source.

The genuinely useful pattern: cv2.getNumberOfCPUs feeding a decision about how much to parallelise your graph. Most of this pack runs in-process, one call at a time, so this number is mostly a sanity check. But it is the honest answer to "how much CPU does this box have for cv2", as opposed to "how much CPU did the spec sheet say".

Install

Requires Python ≥ 3.12 and a recent ComfyUI (V3 node API). The dependency is the contrib OpenCV wheel - the pack documents the headless variant because nothing in it uses OpenCV's GUI functions:

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

Then search ComfyUI CV in ComfyUI Manager, or:

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

and restart. Behaviour is curated against OpenCV 5.0.0.93 specifically; the README says other versions may behave differently, and for the introspection nodes that's the loosest kind of promise to keep - this number comes from your OS, not from OpenCV's version.

Gotchas

• It's not a performance knob. Reading this doesn't change anything. There's no cv2.setNumThreads node in the pack - only the getters are wrapped - so if you need to pin OpenCV's thread count you're looking at the environment, not the graph.
• Contrib wheel trap. All four OpenCV PyPI distributions share one site-packages/cv2, so installing plain opencv-python over the contrib wheel quietly strips the contrib submodules and a chunk of this pack's nodes disappear from the menu. tools/repair_opencv_contrib.py --check tells you if that has happened; --apply fixes it.
• Don't cache it as truth. Start ComfyUI on a different machine, or change a container's limits, and the number moves. Read it, log it, don't hardcode it.