A detector fires on a defect in frame 412. It fires again on the same defect in frame 413, and 414, and through frame 421 as the part drifts across the field of view. If your pipeline treats each of those detections as a separate event, you have just counted one bad part ten times — and the defect rate you hand to the line’s control chart is now wrong by a factor nobody can predict, because it depends on belt speed and frame rate rather than on how many parts were actually bad. That gap between “a defect was detected” and “a part was defective” is the whole reason real-time object tracking exists on an inspection line. Detection answers what is in this frame. Tracking answers which physical part is this, and have I seen it before. The two are different problems, and conflating them is the single most common way a technically sound vision system produces statistically useless numbers. What real-time object tracking actually does on a line Object detection runs frame by frame. On each frame it returns a set of boxes (or masks) with class labels and confidence scores. It has no memory: the detector that fires on frame 413 does not know that the box it produced is the same physical object as the box on frame 412. As far as the detector is concerned, every frame is a fresh, independent picture of the world. Tracking sits on top of detection and adds the memory. Its job is data association: taking the detections from each new frame and deciding which of them continue existing tracks and which of them start new ones. The output is a set of tracks, each carrying a stable identity — usually just an integer ID — that persists as the object moves across frames. Track 47 enters at the left edge, gets inspected, and exits at the right edge, and every detection along the way is bound to ID 47. On a conveyor line this is worth saying plainly: tracking is what lets you bind an inspection outcome to a physical part rather than to a frame. Without it, you have a stream of per-frame observations and no way to collapse them into per-part decisions. This is the correct frame for the whole discipline, and it is the reason a per-part defect rate is even computable. The mechanics of the association step itself — motion prediction, matching, track lifecycle — are covered in depth in our walkthrough of multi-object tracking on an inspection line; this article is about why the per-part identity it produces is the thing your metrics depend on. Why per-frame counting corrupts the statistics you actually care about Here is the failure mode stated cleanly. A part that lingers in the field of view generates one detection per frame it is visible. At 60 frames per second, a part that takes 200 milliseconds to cross the camera generates roughly 12 detections. Count detections and you count that part 12 times. Count tracks and you count it once. The distortion is not a constant offset you can calibrate away. It scales with dwell time, which scales inversely with belt speed, which the line operator changes for reasons that have nothing to do with your camera. Speed the belt up and each part is counted fewer times; slow it down and it is counted more. Your “defect rate” now moves with line speed even when the true fraction of bad parts is flat. That is exactly the kind of phantom signal that makes a statistical process control (SPC) chart raise or suppress alarms for the wrong reasons. The point that matters for anyone feeding a control chart: the per-part defect rate is the only defect rate the line’s SPC monitoring can legitimately consume — the per-frame count is a different quantity that happens to share a name. Control charts assume each plotted observation corresponds to a defined sampling unit. If that unit silently drifts between “a part” and “a frame of a part,” the control limits are meaningless. This is an observed-pattern across the industrial-CV inspection work we do: teams almost never decide to count per frame — they inherit it because detection came first and tracking was treated as an optional add-on. The related failure is on the reject side. A reject decision has to name a physical part so a downstream actuator can divert it. If the system’s internal unit is the frame, there is no single object to point the reject mechanism at, and you end up reconciling frame counts against divert counts after the fact — noisy, and impossible to audit. Detection vs tracking: what each one is responsible for Concern Per-frame detection Detection + tracking Question answered What is in this frame? Which physical part is this? Memory across frames None Persistent track identity Counting unit Detections (frames × dwell) Parts Effect of belt speed on count Count scales with dwell time Count is speed-invariant Reject traceability Cannot bind to one object Reject bound to one track ID Suitable input to SPC No — unit is undefined Yes — unit is one part Failure signature Inflated, speed-dependent rate Identity switches (see below) The table is the short answer. The rest of the article is about the one row that most teams underestimate: tracking does not remove error, it changes its shape. Per-frame counting fails loudly and predictably. Tracking fails quietly, through identity switches — which is more dangerous precisely because it is harder to see. What is an identity switch, and why does it poison the numbers? An identity switch is when the tracker swaps the IDs of two tracks, or assigns a new ID to a part it should have recognized as an existing track. Two parts pass close together and their IDs cross. A part is briefly occluded by a fixture and re-enters as a fresh track. A missed detection breaks a track in half so one physical part becomes track 47 then track 63. Every one of these corrupts per-part statistics, and it does so in ways that are individually small and collectively serious. A broken track double-counts one part. A crossed pair binds part A’s inspection result to part B’s identity, so a reject decision diverts the wrong unit. Because identity switches are rare relative to correct associations, they hide in the aggregate — the count looks plausible, just wrong. This is the trap: per-frame counting is obviously broken, so people fix it; tracking with a bad identity-switch rate looks fine, so people trust it. For an inspection line the consequence chain is specific. An identity switch that binds a defect to the wrong track shows up as both a false accept (the real bad part exits with a clean record) and a false reject (a good part inherits the defect). Both feed the false-reject and escape statistics that the monitoring layer watches for drift. A tracker with a quietly rising identity-switch rate will slowly poison those metrics without ever throwing an error. Re-identification techniques — matching a part to its prior identity by appearance rather than motion alone — are the usual defense when parts look alike or occlude each other, and we cover that specific mechanism in Re-ID in CV inspection. What tracking approach fits a conveyor line? A conveyor is, from a tracking standpoint, a benign environment — and it is worth understanding why, because it tells you what to spend engineering effort on. Parts move in one direction, at a roughly known speed, without maneuvering. That makes motion prediction easy: a simple constant-velocity model (the kind used inside SORT-style trackers, built on a Kalman filter for state prediction and the Hungarian algorithm for frame-to-frame assignment) predicts where each track should appear in the next frame with high confidence. When motion is predictable, spatial gating — matching a detection to the nearest predicted track position — does most of the work, and you often do not need heavy appearance modeling at all. The hard cases are the ones that break the motion assumption: parts that touch or overlap so their boxes merge, parts that look identical so a swap is invisible to a position-only matcher, and fixtures or robot arms that occlude the belt. That is where appearance-based re-identification earns its cost, and where a tracker like DeepSORT or ByteTrack — which keeps low-confidence detections in play to bridge momentary misses — outperforms a naive nearest-neighbor scheme. In our experience the right design question is not “which tracker is best” but “does my line have the failure conditions that justify appearance modeling, or is constant-velocity gating sufficient?” Many well-lit, single-file conveyor setups are firmly in the second camp. Whatever the choice, tracking is the layer that consumes detector output — so detector quality sets the ceiling. A tracker cannot recover an object the detector never saw. If detections flicker, tracks break; if boxes are unstable, association degrades. Getting the underlying real-time object detection on the production line stable and low-latency is a prerequisite, not a parallel concern. Our broader computer vision practice treats detection and tracking as one pipeline for exactly this reason. How do you tie one reject decision to one physical part? This is the operational payoff, so it is worth making concrete with an explicit worked example. Assumptions: single-file conveyor, one camera, parts entering left and exiting right, a divert actuator downstream of the camera. The tracker assigns each part a stable ID on entry. On each frame, the detector produces boxes; the tracker associates them into tracks and updates each track’s state. Every inspection result — pass, or a specific defect class with location — is written against the track ID, not the frame. Track 47 accumulates a record across all the frames it is visible. When track 47 crosses the exit boundary, the system finalizes its record: if any frame flagged a defect above the decision threshold, the part is marked reject, bound to ID 47. The divert actuator is triggered for the physical part corresponding to ID 47, using its known exit time and belt speed. The finalized per-part record — one row per track ID — is what feeds the count. Ten frames of track 47 produce exactly one entry in the defect statistics. The unit of everything downstream is the track ID. That is the sentence to remember: on an inspection line, track identity is the accounting unit — the part number the entire quality record is keyed to. It is also the unit a monitoring harness counts defect and false-reject rates against, which is why the tracking scheme is part of what a production validation pack has to sign off on. If the tracking is unsound, the signed metrics are signing noise. How do you measure whether the tracker is good enough? You measure the tracker against the same standard as any other production component: not “does it look right on a demo clip” but “are its errors below the level that corrupts the decisions it feeds.” Three measurements matter on a line, and they are directly auditable. Identity-switch rate — how often IDs swap or a single part fragments into multiple tracks, per hour or per thousand parts. This is the leading indicator of statistical corruption; a rising rate predicts poisoned counts before the counts themselves look wrong. Per-part count accuracy versus a manual audit — run a fixed window, count parts by hand, compare to the tracker’s part count. This is a benchmark-class check because it is a direct operational measurement against ground truth, and it is the most honest single number you can report. Fraction of reject decisions traceable to a single physical part — of the rejects the system called, how many can be tied to exactly one track ID with a clean record. Untraceable rejects are the audit failures that erode trust in the whole line. These three are prerequisites for trusting the per-part statistics that drift monitoring relies on. They are also the reason stable track identity is treated as one of the inspection reliability artifacts an industrial deployment produces and signs against — the tracker is not just a convenience, it is part of the reliability contract. If you want the full argument for why tracking sits inside the reliability envelope, our services overview frames where this fits in an end-to-end engagement. FAQ How does real time object tracking work? A detector runs on each frame and returns boxes with no memory between frames. Tracking adds that memory: it associates detections across frames — using motion prediction and frame-to-frame matching — so each physical object carries one persistent identity from entry to exit. In practice, that identity is what lets you say “this is the same part I saw ten frames ago” instead of treating every frame as a new object. What is the difference between per-frame detection and tracking on an inspection line, and why does it matter for counting? Detection counts detections — one per frame a part is visible — so a part that lingers gets counted many times, and the count moves with belt speed. Tracking counts parts, because it collapses all the frames of one physical object into a single track. It matters for counting because only the per-part count is speed-invariant and can serve as a defined SPC sampling unit; the per-frame count is a different quantity that shares the name “defect rate” but cannot be fed to a control chart. How does associating detections into stable tracks let you compute a per-part defect rate instead of a per-frame one? Every inspection result is written against a track ID rather than a frame. When a part exits, its track record is finalized into one row — pass or reject — regardless of how many frames it appeared in. That collapse from many frames to one track is exactly what converts a noisy per-frame count into a clean per-part defect rate. What is an identity switch, and how does it corrupt the defect-rate and false-reject statistics that feed the line’s control charts? An identity switch is when the tracker swaps two parts’ IDs, or fragments one part into multiple tracks, or assigns a new ID to a part it should have recognized. It corrupts statistics by double-counting fragmented parts and by binding a defect to the wrong track — producing simultaneous false accepts and false rejects. Because switches are rare relative to correct associations, they hide in the aggregate and poison the false-reject and escape metrics without throwing any error. What tracking approach fits a conveyor-line inspection setup where parts move predictably in one direction? Predictable one-directional motion favors a constant-velocity motion model with spatial gating — the SORT-style approach built on a Kalman filter and Hungarian matching — which handles most well-lit, single-file lines. Appearance-based re-identification (DeepSORT, ByteTrack) is worth its cost only when parts overlap, look identical, or get occluded. The design question is whether your line has those failure conditions, not which tracker is fashionable. How do you tie a single reject decision to one physical part using its track identity? Write every inspection result against the track ID, not the frame, so the part accumulates one record across all its frames. When the track crosses the exit boundary, finalize the record and trigger the divert actuator for that specific ID using its known exit time and belt speed. The track ID is the accounting unit the entire quality record is keyed to. How do you measure whether a tracker is working well enough on the line — what metrics indicate track quality? Track three things: the identity-switch rate (the leading indicator of statistical corruption), per-part count accuracy against a manual audit (a direct operational measurement of ground truth), and the fraction of reject decisions traceable to exactly one physical part. These are prerequisites for trusting the per-part statistics that drift monitoring depends on. Detection quality sets the ceiling; tracking quality decides whether the numbers above that ceiling mean anything. The open question on most lines is not whether tracking is needed — it is whether the identity-switch rate has been measured at all, or merely assumed to be low. A per-part track identity that no one has audited is the failure class a production monitoring harness is meant to catch before it reaches a control chart.
