OpenCV getTickCount_0

Every once in a while you want to know how long a node actually takes - not the theoretical speed, the wall-clock truth. getTickCount_0 is OpenCV's stopwatch, exposed raw. It has no inputs and one output: an INT that is the current value of a platform-dependent tick counter. Think of it as a reading from a clock that only ever moves forward, from some arbitrary start point you don't control.

How it actually works

Under the hood it wraps cv2.getTickCount(). On most platforms that's a monotonic, high-resolution counter (OpenCV uses QueryPerformanceCounter on Windows, gettimeofday-style clocks elsewhere). Two properties matter here:

• It's monotonic - it never goes backwards, so two readings taken at different times are comparable.
• Its absolute value is meaningless. It's a count since some system-dependent epoch, not since boot or since ComfyUI started. The number on its own tells you nothing; it only becomes information when you have a second reading.

That's the catch that makes this node awkward in a graph. The classic OpenCV idiom is:

start = cv2.getTickCount()
# ... work ...
elapsed_seconds = (cv2.getTickCount() - start) / cv2.getTickFrequency()

A single invocation of getTickCount_0 gives you one half of that equation. To time a node you'd have to capture a tick before and after it - two instances of the node, with no clean way in ComfyUI to say "this one runs before that one and I want the delta." You can attempt it by chaining the INT outputs into a math node, but graph scheduling doesn't guarantee the "before" fires immediately before the node you're timing. The result is a stopwatch you can't cleanly stop.

When you'd reach for it

Honestly: rarely, and only if you're comfortable with its limits. The realistic uses are:

• A rough "is anything happening at all" probe - if the output changes between runs of your workflow, the clock is live.
• Pairing it with getTickFrequency_0 in a workflow where you can control ordering (e.g. two runs separated by an obviously slow operation) to estimate seconds.

It's the same story as several nodes in this pack: a faithful port of a real OpenCV function that assumes imperative Python, wrapped into a paradigm that doesn't do time-ordering well. It works, it's accurate, it's just not shaped for what you probably want. For actual per-node timing in ComfyUI you're better off watching the console's execution log - the pack's own docs essentially concede that some functions "don't make sense in ComfyUI," and a timer you can't bracket is one of them.

Install & troubleshooting

Nothing special: ComfyUI Manager or

cd ComfyUI/custom_nodes
git clone https://github.com/geroldmeisinger/opencv-comfyui

then restart; the pack needs opencv-contrib-python and the numpy/torch ComfyUI already has. No model files, no API key. If you see Cannot import name 'guidedFilter' from 'cv2.ximgproc' on startup, you've got conflicting OpenCV packages - keep exactly one and it clears up. And if you ever actually need the other half of the stopwatch, getTickFrequency_0 is sitting right next to this node in the list.