Object Counting
Live per-label counts and cumulative line counting — track-ID semantics and the line-throughput trade-off.
On top of the labeled boxes, Helios shows two kinds of counts, both drawn on the video overlay and mirrored in the UI. Both are presence-mode features: the count overlay and the count controls appear in presence mode only.
Live per-label counts
For every active concept currently in view, the overlay panel and the concept chips show how many are visible right now (person: 3). Labels with zero in frame are not shown, so the panel stays quiet instead of listing empty concepts.
Live counts include every detection in frame, whether or not the tracker has assigned it an ID.
Cumulative line counting
Press ▶ Count to start a running total per label that climbs as new objects pass through frame (cups: 1, 2, 3, …). While counting, the overlay adds a visually distinct COUNTING header above the totals.
| Control | Effect |
|---|---|
| ▶ Count | Start accumulating. Existing totals are preserved. |
| ⏸ Counting | Freeze the totals. Nothing is lost. |
| Reset | Zero the totals and the set of counted track IDs. |
Track-ID semantics
Counting rides persistent per-object track IDs from Ultralytics tracking, which Helios runs on every frame — not just while counting — so IDs are already stable the instant you press Count.
Accumulation is per label: Helios keeps the set of track IDs it has already counted for each label, and a total only increments when a new ID appears for that label. Detections without a track ID still contribute to live counts but are never accumulated into the cumulative totals.
Cumulative accumulation is restricted to presence mode, so the counted-ID set cannot grow silently while the counting UI is hidden in another mode. Reset is the release valve for that set — sessions are short and bounded by design.
This is line throughput, not unique-object identity
An object that simply stays in frame is counted once. An object that leaves frame and re-enters is counted again — accepted by design. Helios counts objects passing a line; it does not claim to recognise that a returning object is the same one it saw before.
Update cadence
The video overlay updates per frame. The UI badges and totals refresh on the roughly 3-second /api/status poll, the same cadence as the FPS readout — an accepted, documented difference between the burned-in overlay and the surrounding HTML.
When totals climb too fast
Double-counting almost always means track-ID flicker: the tracker lost an object briefly and assigned it a new ID on reacquisition.
- Raise
track_bufferin the tracker YAML — the number of frames a lost ID survives. - Or switch
trackertobotsort.yamlfor occlusion-heavy scenes.
The tracker is a config knob (tracker in helios.toml, default bytetrack.yaml). ByteTrack is light and well suited to a fixed camera watching a line. If tracking pushes FPS below your target, lower imgsz or raise conf — see Tuning.
Tiling disables tracking-based counting
With the Tiling toggle on, tiles are inferred independently and carry no tracker IDs, so cumulative counting and the anti-strobe smoothing both degrade to instantaneous behavior. That is the documented opt-in trade-off for better small-object recall; tiling ships off by default. See the tiling toggle.
Smoke-testing tracking
The self-test prints each detection's track_id, which should stay stable for a stationary object across its short multi-frame loop:
python -m app.vision --selftest # uses the helios.toml camera_index
python -m app.vision --selftest --camera 700 # or target a specific index