Tracking Data Visualize

Tracking data is the invisible half of a pose-driven workflow. Feed upper-body tracking from InstanceDiffusion's Upper Body Tracking From PoseKps node into a pipeline and you get a custom TRACKING socket full of boxes you can't see. If the video has two or three people in it, whose body is whose? TrackingVisualize is the debug view that answers that: it draws every tracked body part back onto your frames, color-coded, with a frame counter burned into the top-left corner. If your animation drifts onto the wrong person, this is the node that shows you where and when.

Why you'd reach for it

This is the "look before you lock" step of the BBoxNodes family. The whole pack exists because face and pose detectors, left to themselves, swap between people mid-video - box riding person A's face for twenty frames, then jumping to person B's, which silently wrecks multi-person Wan 2.2 animation (and anything else that crops a specific character per frame). Before you can pick one person and hold them, you need to see what the tracker thinks it's tracking. That's this node's whole job, and it's the same idea as KJNode's DrawInstanceDiffusionTracking - the author built it to be input-compatible with that KJ ecosystem, so it drops into existing pose-tracking graphs.

It's also just a genuinely good sanity check for any tracking-to-conditioning pipeline. Run it once on a few frames and you'll catch tracker failures - a head box sliding onto a torso, a missing arm - before they burn a multi-minute generation run.

How it works

TrackingVisualize reads the TRACKING custom type: a per-frame dict where each body part (Head, Neck, Shoulder, Torso, arms, forearms) maps to per-person boxes. For every frame it draws each part's rectangle in its own fixed color, so a head is always the same color across the whole clip - that's what makes drift actually visible instead of a wall of identical red boxes. Each part gets its own color, and the frame index is drawn in red in the top-left of every frame. That frame number is deliberate: the author ships it specifically so you can note the exact frame where a bbox jumps, which is the frame you'll reference in the scheduler nodes later.

The inputs that matter

You only really touch three of them:

• person_index - 0 draws every person; 1 through 10 draws just that person (indices are 1-based). Start with 0 to see everything, then narrow down.
• body_part - a dropdown: All, Head, Neck, Shoulder, LArm, RArm, LForearm, RForearm, Torso. Pick one to isolate, say, just heads.
• line_width - rectangle border thickness, 1–5. 1 is fine for previews; bump it if you're exporting something to actually look at.

Plus images and tracking, obviously. The single output is images - the same batch with boxes drawn - which you can preview or send straight to VHS_VideoCombine.

Installing it

ComfyUI Manager is the easy path: search ComfyUI-BBoxNodes and hit Install. Manually it's the standard two-liner:

cd ComfyUI/custom_nodes
git clone https://github.com/masternc80/ComfyUI-BBoxNodes
cd ComfyUI-BBoxNodes && pip install -r requirements.txt

Restart ComfyUI and you're done. Good news: the dependency list is just pillow, which you almost certainly already have, and there are no model downloads - this node doesn't detect anything, it only draws what you feed it. One real gotcha: the pack is written against the new comfy_api.latest extension API, so if the nodes don't appear after restart, update ComfyUI rather than blaming the install.

Troubleshooting

The box that usually bites people: the TRACKING input is compatible with KJ nodes, but the output is a plain image - don't expect it to feed anything back into tracking-land. And if your tracking data is empty or malformed, you'll just get frames with no boxes and no error, which is the tracking node's fault, not this one's. If boxes look right but the colors seem to change between clips, remember the color is tied to body part, not to person - that's the feature, not a bug.