What is Track Completeness and Fragmentation?
Track Completeness and Fragmentation are trajectory diagnostics that classify each ground-truth identity by its matched-lifetime ratio and count how often successful tracking is interrupted and later resumed.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
Classify complete ground-truth lifetimes after matching
For each Ground Truth identity g, compute r_g = matched occurrences / evaluated occurrences. Under the commonly used py-motmetrics convention, r_g >= 0.8 is Mostly Tracked, 0.2 <= r_g < 0.8 is Partially Tracked, and r_g < 0.2 is Mostly Lost. Report counts or divide each count by the number of Ground Truth trajectories to obtain MTR, PTR, and MLR.
The matched numerator can include different predicted IDs over time. MT therefore means high temporal coverage, not identity correctness. MOTChallenge recommends these measures as track-quality diagnostics alongside detection, localization, and identity scores.
Count resumed interruptions rather than every missed frame
A fragmentation occurs when a Ground Truth trajectory was tracked, becomes untracked, and is tracked again later. A ten-frame gap is one fragmentation, while a trailing miss with no later recovery is not. Continuous matching with a changed predicted ID is an identity switch, not necessarily a fragmentation.
Both py-motmetrics and TrackEval implement this resumed-segment idea, but matching continuity and preprocessing still determine the event sequence.
Treat boundary and aggregation rules as protocol
Implementations disagree at an exact 0.8 ratio: py-motmetrics classifies it as MT, while the cited TrackEval revision uses strict > 0.8, making it PT. Both place exactly 0.2 in PT. Sequence-level counts are normally summed before deriving rates; averaging per-sequence percentages can overweight short sequences.
Report evaluator commit, overlap threshold, ignored regions, minimum visibility, class filters, and whether counts or rates are shown. Pair these diagnostics with TID and LGD for outage duration, HOTA or IDF1 for identity consistency, and MOTA for false and missed detections.
Key Characteristics
- Classifies each ground-truth trajectory by matched-lifetime ratio
- Separates mostly tracked, partially tracked, and mostly lost tracks
- Counts interrupted-and-resumed tracking episodes
- Ignores predicted identity consistency in the coverage classes
- Depends on matching, lifetime, ignore, and visibility rules
- Contains an exact-80-percent implementation boundary difference
Common Use Cases
- Auditing whether a tracker covers full object lifetimes
- Comparing persistent tracking through occlusion
- Diagnosing repeated loss and reacquisition
- Reporting MOTChallenge-compatible secondary metrics
- Testing track-management confirmation and termination policies
Example
Loading code...Frequently Asked Questions
How are Mostly Tracked, Partially Tracked, and Mostly Lost calculated?
Divide each ground-truth trajectory's accepted matched occurrences by its evaluated lifetime. A common convention uses at least 80% for MT, 20% through below 80% for PT, and below 20% for ML, but the exact evaluator boundary must be stated.
Does Mostly Tracked mean the identity stayed correct?
No. The coverage ratio counts accepted matches to the ground-truth trajectory even if different predicted identities supply those matches. Use IDF1, HOTA association components, or identity-switch counts to assess identity continuity.
How is fragmentation counted?
Fragmentation counts a tracked-to-untracked interruption only when tracking of that ground-truth trajectory later resumes. Gap length does not change the count, and leading or final misses without a completed interruption-and-recovery cycle are excluded.
Why can MT differ between py-motmetrics and TrackEval?
At their cited revisions, py-motmetrics uses `ratio >= 0.8`, whereas TrackEval uses `ratio > 0.8`. A trajectory matched on exactly 80% of evaluated occurrences is therefore MT in one and PT in the other.
What should be reported with MT, PT, ML, and Frag?
Report counts and rates, evaluator version, matching threshold, ignore and visibility rules, sequence aggregation, and raw lifetime distributions. Add LGD, identity metrics, and error counts so a few long gaps or frequent ID changes are not hidden.