cv2.getTickFrequency

Ticks per second. That's it - no inputs, one float out. It exists because cv2.getTickCount returns a raw counter reading whose unit is defined entirely by this number, so the pair is the unit system and neither half is usable alone.

Why it's a separate node and not a constant

Because the frequency is a property of the machine and the build, not something you can hardcode. Historically it tracked the CPU's timestamp-counter rate; on modern builds the counter is backed by a steady clock, so you'll see a round 1e9 (ticks are effectively nanoseconds) and the numbers get much easier to read. Either way, the contract is the useful part: whatever the counter counts, this is how many of those per second:

seconds = (tick_count_after - tick_count_before) / getTickFrequency()

If you're reimplementing that arithmetic in your head, remember the frequency is a FLOAT - the only one of the four primitive getters in this pack that isn't an INT (getNumThreads, getNumberOfCPUs and getTickCount are all integers). That matters if you're wiring it into something typed: a FLOAT output wants a float-typed consumer, and the pack's CV Tuple accepts float components for exactly this kind of value.

Where it fits

It's the boring half of a timing pair, which is the honest description. cv2.getTickCount gives you "before" and "after" readings; this gives you the divisor. Wrap both around a step you suspect is slow - the pack's heavier OpenCV operations are the usual suspects, and the README is upfront that many of them are genuinely not fast (the DNN examples run on the CPU, one frame pair per execution, and are described by the author as illustrative rather than practical) - and you'll know within one run whether the cv2 call or the model is eating your afternoon.

Reading a float out of a graph: Inspect CV Data takes any value and emits a text summary you can display with core's Preview as Text. Same pattern as every non-image output in this pack, and the same caveat: a diagnostic you read, not a measurement framework - ComfyUI's caching means two readings taken across two runs may simply be the first run's numbers replayed.

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 (V3 node API) are required - the pack's nodes are all built at import time and an older ComfyUI gives you an empty pack rather than an error message. Curated against OpenCV 5.0.0.93 specifically; the README says other versions may behave differently.

Gotchas worth the paragraph

• Wrong wheel, half a pack. The four OpenCV PyPI distributions share one site-packages/cv2. Installing a non-contrib wheel over the contrib one empties the contrib submodules and some of this pack's nodes stop appearing in the menu. tools/repair_opencv_contrib.py --check → --apply is the pack's own repair path, and there's no install-time guard, so it's worth knowing it exists before you start re-cloning repositories at midnight.
• Version check first, always. If timings look bizarre or nodes behave oddly after an environment change, cv2.getVersionString tells you which OpenCV the server actually loaded. It's a five-second check that rules out half the mystery.
• It's a divisor, so don't divide by it the wrong way round. More ticks per second means more precision, not slower timings. Every year or so somebody posts a benchmark where the numbers are off by a factor of a billion because the division went in upside down.
• Nothing here is a calibration tool. If you actually need to profile ComfyUI, use a profiler; this pair is for answering "is it the filter or the model" without leaving the canvas.