cv2.getThreadNum

Let's be honest about this one up front: in a ComfyUI graph it will almost always read 0, and that's correct rather than broken. It's OpenCV's "index of the thread that is currently executing", which is a meaningful question inside a parallel region and a slightly philosophical one outside it. When a node calls cv2.getThreadNum from ComfyUI's execution thread, there's exactly one thread doing the asking, so the answer is the first one.

The pack wraps it because the pack wraps essentially every free function in cv2 - around 470 raw wrappers generated from the type stubs - and the thread-introspection trio (getThreadNum, getNumThreads, getNumberOfCPUs) arrives as a set. No inputs, one int out.

What it's actually for upstream

Inside OpenCV's own parallel loops, this is how code asks "which worker am I?" - it's the hook for work-stealing patterns, per-thread scratch buffers, and diagnostics in the middle of a parallel_for. That's a C++-level concern: by the time a filter has been wrapped as a ComfyUI node, the parallel region is finished before your graph sees anything. You can't drive the index from outside, and you can't see it change.

So the honest use here is a one-off sanity check while you're already looking at the CPU lane: if getNumThreads looks wrong and getThreadNum reads 1, something in your environment is genuinely running cv2 single-threaded. That's a two-node, five-second diagnosis, which is more than most people ever need from it.

If you want the useful ones

• cv2.getNumThreads - the configured width of OpenCV's thread pool. This is the number that shows up in "why is this filter slow" threads.
• cv2.getNumberOfCPUs - the machine's CPU count as the library sees it, which inside a container is often the host's count rather than your cgroup quota.
• CV Build Information - a curated node (the raw getBuildInformation wrapper is deliberately not shipped, since the banner quotes build-machine paths): Eigen, non-free, OpenCL and CUDA availability in your build.

Reading an integer

int output, nowhere obvious to go - that's the usual reason nobody wires these. Two options: into Inspect CV Data (its value input accepts anything, and its summary string goes to core's Preview as Text), or into a converted integer widget downstream. The second pattern is the plumbing-layer staple: one value, one authoritative source, fanned out to wherever it's needed.

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 ComfyUI. Python ≥ 3.12 and a recent ComfyUI on the V3 node API; the pack is curated against OpenCV 5.0.0.93 and warns that other versions may behave differently. One wheel caveat that hits this pack specifically: all four OpenCV PyPI distributions share a single site-packages/cv2, so installing plain opencv-python over a contrib wheel quietly empties the contrib submodules and some nodes disappear from the menu - tools/repair_opencv_contrib.py checks and repairs that.

Not much else to warn you about, and that's the point of a node like this: it's a zero-argument getter with no side effects, which is about as harmless as a node can be. Just don't wire it expecting a changing value, and don't read a 0 as an error.