cv2.getNumThreads

Zero inputs, one int out: how many threads OpenCV's parallel backend will use right now. cv2.getNumberOfCPUs tells you the machine; this tells you the setting. Nine times out of ten they're the same number, because OpenCV's default is "use the CPUs" - and the tenth time is why you'd put this node on the canvas.

How it works, and when the number isn't what you expect

OpenCV runs a chunk of its filters - blurs, remap, resize, large morphology, the filter2D family - through an internal parallel loop that splits rows across a thread pool. This node reports that pool's width. It's not ComfyUI's worker count, not torch's thread count, and not the GPU: it's OpenCV's own setting, read from the library, on the machine that's executing the node.

If that number is 1 on a 16-core box, you didn't misread it - that's the interesting case. Something in the environment has pinned OpenCV down: an oversized container quota where the library chose the conservative path, a build without a real threading backend, or an environment that sets the thread count before ComfyUI's process ever imports cv2. Worth knowing before you conclude that a slow cv2 node is the pack's fault. It usually isn't; it's a filter that didn't get to parallelise.

The asymmetry that's worth knowing about

The pack wraps the getter. It does not wrap cv2.setNumThreads - search the generated registry and you'll find getNumThreads, getThreadNum and getNumberOfCPUs, but no setter. That's a real constraint, not an oversight you can work around with a reroute: you can observe this value from a graph, and you can't change it from one. If you genuinely need to pin OpenCV's pool (because you're co-locating cv2 work with torch and both are fighting for the same cores), that's an environment-level fix before launch, not a node.

So the useful posture here is diagnostic. Combine it with the other two getters and you have a one-glance answer to "what CPU capacity does this ComfyUI actually have for cv2": getNumberOfCPUs for the machine, getNumThreads for the pool, and getThreadNum for the index of the thread doing the calling - you'll see 0 there, unsurprisingly, because the top-level call in a ComfyUI execution isn't itself inside a cv2 parallel region.

Reading an integer in ComfyUI

An int output has nowhere obvious to go, which is the main reason people never touch these nodes. Two ways to see it:

• Wire it into Inspect CV Data (its value input takes anything) and send the summary string to core's Preview as Text node.
• Or convert a downstream integer widget to an input and link straight into it, which is the move when the number is meant to drive something rather than be read.

The plumbing-layer essay makes the general case for that second pattern: give a value one authoritative source, fan it out, stop typing the same number into five widgets. This node is a read-only source of exactly one such value.

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 are required - the pack is written against the V3 node API. It's GPL-3.0, forked from Gerold Meisinger's opencv-comfyui, and the README is unusually blunt about its own status: heavy LLM involvement in development, uncurated auto-generated wrappers, and no promise of support. For an introspection node, that's all fine - the wrapper is a one-line call to cv2.

Gotcha

Don't use this to explain a GPU-starved stall. If your sampler is waiting on VRAM, no number from the cv2 introspection lane will tell you anything, because none of these nodes know anything about CUDA. And if you're chasing an intermittent slowdown, the KB's standing advice applies double here: change one thing, keep the seed fixed, and compare - a thread count that looks wrong plus a workflow you're also editing is two variables, which is zero information.