Track Objects (BoxMOT)

How it fits

Typical backends

Caveats

• Hard constraintThe appearance algorithms (boosttrack, occluboost, deepocsort, strongsort, botsort, hybridsort) require a mounted ReID weights file (.pt); the tracker selects the appearance backbone from the file name, so keep its canonical name (e.g. osnet_x0_25_msmt17.pt). The motion-only algorithms (ocsort, bytetrack, sfsort) need no weights file and ignore one if mounted.
• State lifetimeTrack memory is in-process; a restart drops every id and objects re-appear with new track ids.
• Parameter interactionEach algorithm exposes only its own subset of the knobs below; a knob whose description does not name the selected algorithm has no effect. Confirmation delay and track survival are governed by per-algorithm thresholds (e.g. min_hits/max_age on the SORT-family trackers).
• CostThe appearance algorithms run a re-identification network per detection and benefit from a GPU; the motion-only algorithms are lighter and run well on CPU.
• OrderingThe Image and [BoundingBox] inputs must come from the same frame; mismatched timing degrades both motion and appearance association.
• I/O contractThe output shape is chosen ONCE from the connected downstream type and is fixed for the run: [Track] for id + current box + center trajectory (the default arm), [TrackedObject] for id + confidence, [BoundingBox] for id-less boxes, or [UInt64] for the bare id set. Each fire emits one record per ACTIVE track and every arm derives from that same per-frame track list, so counts and ids stay consistent across arms. The [TrackedSegmentation] arm is NOT served: the BoxMOT bbox trackers associate boxes only and carry no mask, so selecting it fails fast at startup pointing at a mask-capable tracker (e.g. track_objects_sam_3).
• I/O contractThe [Track] arm fills each track's `trajectory` with a bounded history (last 64) of box-center points, oldest first, accumulated per track id across frames in a per-id deque (BoxMOT exposes no uniform per-track history across its trackers, so it is maintained here). The history resets on tracker reset and an id that disappears drops its history. The current box carries the matched detection's real class id and confidence, so `Track.box.class` is meaningful downstream.