VLM Track Report

Tracking output is verbose, nested JSON with observation arrays, timestamps, and confidence values - great for machines, useless for a human trying to see "did the tracker actually follow these three people across the clip?" VLMTrackReport is the node that turns a VLM_TRACKS payload into something you can actually read: a human-friendly text report plus the structured JSON, both at once. It's a display node - it does no tracking and no inference, it just makes the results legible.

You'd wire this in as the last step of any tracking pipeline (the pack marks it as an output node, so it renders its report in the UI): after VLMTrackDetections, VLMSAM2VideoSegmentation, or VLMSAM3TrackAdapter, connect tracks here and read the summary instead of poking at raw JSON.

What you get

• report_text - a readable, human-oriented summary of the tracks: how many tracks, which labels, how long each one lasted, observation counts. This is the "is my tracking working at all?" view, and it's what shows up in the node's UI on execution.
• report_json - the same information as structured JSON, for logging, API use, or handing to a downstream process that wants the facts without re-parsing VLM_TRACKS.

Both come from the same computation, so you never have to reconcile a "human version" against a "machine version."

When it earns its keep

Honestly? Every time. This is the node you'll reach for when a track-based workflow produces something unexpected and you need to know whether the tracking is the problem or something downstream. Three people in the scene but the report shows five tracks? Now you can see the label counts and durations at a glance and decide if a false-positive track is merging or splitting. It's also the natural tail for a debugging chain: VLMOpenVocabularyDetection → VLMTrackDetections → VLMTrackReport, and you get a text verdict on the whole pipeline without any extra setup.

Because it's an output node, it renders to the UI - which makes it the easiest way to show someone what your tracking did, whether that's you tomorrow morning or a collaborator who doesn't want to parse schemas.

Install

Part of ComfyUI VLM Nodes (gokayfem/ComfyUI_VLM_nodes). ComfyUI Manager → search "VLM Nodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI_VLM_nodes
python -m pip install -r ComfyUI/custom_nodes/ComfyUI_VLM_nodes/requirements.txt

Run pip with ComfyUI's Python; the repo won't install its own torch. No models, no downloads - pure reporting over an existing VLM_TRACKS payload.

Gotchas

The only real trap is feeding it something that isn't a VLM_TRACKS - it takes exactly one required input and won't accept a raw detection list, so run detection → tracking first. And because it's an output node, remember it sits at the end of a branch; anything downstream that needs the tracks themselves should tap the tracks output of the tracker directly, not try to consume this report.