CoTracker Point Tracking

Point tracking is the quiet workhorse behind "make my still image move like this reference clip." This node watches a video and follows how its pixels move using Meta's CoTracker3, then hands you a list of tracked points that plug straight into the ATI Tracks node in Kijai's ComfyUI-WanVideoWrapper. That connection is the whole reason this pack exists - the README says so in its first line - and it's what turns a plain I2V generation into something that follows a driving video's motion without a skeleton, a pose map, or the DWPose-style preprocessing that throws away depth and contact.

The ATI Tracks mechanism wants a set of (x, y) paths across frames, and CoTrackerNode is the front end that produces exactly those. On first run it loads Meta's cotracker3_online model via torch.hub - needs internet once, caches into ~/.cache/torch/hub - then runs the video through it in chunks. Two passes, depending on what you feed it. Type points into tracking_points (one x,y per line) and those get tracked first. Then, unless you set grid_size to 0, it drops a grid of points over the whole frame and lets CoTracker chase them.

Here's the part that's easy to miss: it doesn't just hand you every grid point. It ranks points by total motion, keeps the ones that stayed visible across the clip - that's confidence_threshold, the minimum average visibility a point needs to survive - and enforces min_distance so survivors don't clump into one corner. It even deliberately keeps one low-motion point around, because a static reference point is exactly what you want when most of the scene should stay still. max_num_of_points caps the total, and tracking_mask limits where grid points get placed.

Two outputs, and they tell you everything. tracking_results is a STRING - one JSON array per tracked point, each element a {"x": ..., "y": ...} for a frame - which is what feeds the ATI Tracks node. image_with_results is the same video with red markers drawn on, so you can see what you got before you commit to a long render.

The input you'll actually touch most is grid_size (divisions along width and height; 20 is the default and plenty). Don't sleep on enable_backward either - it's marked experimental and it tracks the clip in reverse to pick up objects that don't exist in the first frame. When it's on, vanishing points are written as (-100, -100) sentinels instead of being silently carried over, which ATI reads as "gone." force_offload defaults to on, pushing the model back to CPU after a run so the next node in your graph gets free VRAM.

Installing is the same for the whole pack: ComfyUI Manager → search "Comfyui CoTracker Node", or cd ComfyUI/custom_nodes && git clone https://github.com/s9roll7/comfyui_cotracker_node and restart. There's no requirements.txt to fight with - it leans on the torch, OpenCV and torchvision that any ComfyUI install already has. The real dependency is the CoTracker3 model, which downloads itself the first time you queue.

Where people get burned: OOM. The author's own node description says it plainly - if you run out of VRAM, lower grid_size. And the model processes video in fixed chunks, so a very short test clip throws an "at least N frames required" error; feed it a proper clip, not two frames.