cv2.getHardwareFeatureName

This is a diagnostics node with one integer in and one string out: you give it a CPU-feature index, it gives you the feature's name. That's the whole node. It exists because this pack wraps essentially all of cv2's free functions, introspection included, and because "which instruction sets does the OpenCV on this box actually see?" is a real question when a filter that looks identical on two machines runs three times slower on one of them.

How it works

feature is an INT socket, and OpenCV resolves it against its internal CPU-feature enumeration - the same family that cv2.checkHardwareSupport tests in the same pack. Walk it upward from 0 and you'll get the recognised names for your architecture: on x86 that's the MMX/SSE/AVX lineage, on ARM the NEON family. The string output confirms which name the index maps to; anything past the end of the table has nothing real to report, so don't read meaning into a blank or odd answer there.

Honest caveat: the pack's tooltip on feature is a bare - - -. The tooltips in this pack are extracted from the OpenCV documentation, and this parameter simply doesn't have doc text upstream - which tells you how much OpenCV expects anyone to poke at it. You're expected to know the enumeration you're probing.

What you'd actually use it for

Runtime dispatch. OpenCV picks its fast paths at load time based on what the CPU reports - AVX2, FMA3, SSE4_2, whatever - and silently falls back to a slower generic implementation when the feature is missing. So when someone posts "this morphology/optical-flow/stereo node is way slower on my VM than on my laptop", the CPU feature list is one of the two or three things worth checking before blaming ComfyUI. The pairing is what makes it useful:

cv2.checkHardwareSupport (also in this pack, also an INT in, but a BOOLEAN out) answers "is index N available?". Same table, the other question.
CV Build Information - a curated node, not a raw wrapper - answers the build half: Eigen, non-free, OpenCL and CUDA availability in your OpenCV build. The raw cv2.getBuildInformation wrapper is deliberately not shipped, because the banner quotes build-machine paths; CV Build Information is that same text with the paths redacted.

For the GPU half of the picture, look at ComfyUI's own startup log - this node is strictly about the CPU, and it will happily tell you your CPU has AVX-512 while the model you're loading is queueing behind a 12 GB VRAM ceiling. Different axis, different tool.

Reading the output

The string output is a STRING socket: it wires into any converted string input, and most directly into Inspect CV Data, whose summary output goes to the core Preview as Text node. That's the pattern for every non-image output in this pack - the value is data, and text preview is how you look at data. Running it once per index is a manual sweep, which is the honest description of this node's ergonomics: it's a probe, not a pipeline stage.

Install

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

Then either search ComfyUI CV in ComfyUI Manager or:

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

and restart ComfyUI. Python ≥ 3.12 and a recent ComfyUI on the V3 node API are required - this pack's nodes are all generated at import time, and on an older ComfyUI the whole pack comes up empty rather than erroring gracefully.

The one gotcha worth naming

Don't expect the index to be stable across architectures. It's an enumeration, not a documented API constant you can hardcode into a workflow you plan to share: an index that means "AVX2" on your desktop means something else - or nothing - on an Apple Silicon laptop or an arm64 server. Probe, read the name, and don't ship a workflow that depends on index 9 being a particular instruction set.

If you're comparing machines, also remember what this doesn't say: a CPU feature being present is not the same as OpenCV having been built to use it, and neither tells you whether the function you're benchmarking is even parallelised. See cv2.getNumThreads for that half.