Tracking follows an object through change
A card travels from the shoe across the table and stops beside a player. A person sees one action; a tracker receives imperfect observations, timestamps, gaps and possible identity changes. Preserve that uncertainty instead of treating every frame as a definite event, especially when delay could make an old observation look like the current game state.
Movement does not determine its meaning. A hand reaching toward a card is not necessarily a hit, wager or completed deal. Interpret it using game context, allowed actions and the authoritative event stream. This prevents noisy motion from silently changing an account or game record.
Lighting changes, overlaps, blur, camera shake and occlusion complicate tracking. Define explicit states for an unobserved object and uncertain identity. If missing frames affect a game decision, the tracker must not draw a confident, uninterrupted path through them.
Build a time-aligned event model
Give every frame and derived observation a clock reference. Capture, encoding, transport, inference, operator display and game-service processing all add delay. Store capture, processing and receipt times separately. Link each visible event to its frame range, camera, tracker ID, round and acceptance state.
Time fields for a reviewable tracking event
- Capture timestamp
- Purpose:When the camera recorded the source image.· Failure it helps identify:Clock drift or a source stream that paused.
- Processing timestamp
- Purpose:When a model emitted an observation.· Failure it helps identify:Queue backlog or inference slowdown.
- Service receipt
- Purpose:When the event reached the game or monitoring service.· Failure it helps identify:Network delay or duplicate delivery.
- Round and object IDs
- Purpose:Link the observation to the expected game phase and tracked entity.· Failure it helps identify:Card or chip assigned to the wrong round or table zone.
- Decision status
- Purpose:Accepted, unresolved, reviewed or rejected with a reason.· Failure it helps identify:Automated output mistaken for an adjudicated result.
Synchronise camera, edge processor and service clocks; monitor drift and alert when it exceeds tolerance. If the stream is delayed, show an “as of” time to operators so they can distinguish the current table from a buffered view.
Use states instead of a confidence-only rule
Confidence is only one input; a state machine records what should happen next. A card deal might move through ready, detected, tracked, placed in a player area, rank-and-suit read, rule-checked and accepted. Set a timeout and uncertainty route for each stage. If the card leaves view, mark observation interrupted instead of assigning it to the expected seat.
- Start a tracked event only after the game enters the relevant phase.
- Associate a new detection with an existing track using position, appearance and time continuity.
- Retain multiple candidate associations when two objects cross or overlap.
- Confirm a state transition with the game rule and another data source.
- End the track with a recorded reason: settled, removed, occluded or manually resolved.
Temporal filters reduce jitter, but too much smoothing makes the display trail behind the table. Set delay by use: a decorative overlay can lag more than an alert for a dealer handling an unresolved card. Keep raw observations so reviewers can inspect the smoothed path.
Set a latency budget for each function
Latency limits depend on the function. Video monitoring, operator alerts and customer-facing state carry different costs. Budget capture, queueing, inference, validation and display separately; load-test the whole path with peak streams and simultaneous tables. A single-clip model benchmark omits network and queue delays.
When processing falls behind, define whether to discard stale frames, reduce analysis detail or pause automated decisions. Never present old state as live without a timestamp. Monitor queue depth, skipped frames, completion time and recovery after stream stabilisation, and give operators a clear degraded-mode signal.
For a player overlay, show known state rather than predicted movement. “Card detected; confirmation pending” is safer than a final hand value while resolution is incomplete. A delay notice must not imply a wager was accepted or cancelled unless the game service says so.
Coordinate cameras without merging uncertainty
Multiple cameras can show the same table, but their calibration, clocks and blind spots differ. Transform observations to shared table coordinates while preserving source IDs. Disagreement between views may reveal a fault; averaging the values can hide a bad calibration or occlusion.
Choose a preferred source for each event: an overhead view may locate a card, while a side camera estimates stack height. Record the selection rule and escalation route for conflicting views. Recalibrate after changes to lens, mount, table or lighting, and label test images with each camera's conditions for later comparisons.
Retain object tracks and timestamps needed to resolve a hand; discard continuous pose data without an operational purpose. Camera, table-zone and round IDs help a supervisor more than a person-level profile. Keep identity processing technically separate from object tracking.
Reconcile vision with the game record
New Zealand's 2026 online-casino standards cover game rules, relevant audit logs, deliberate starts between rounds and customer-protective recovery after interruption. Tracking may support monitoring, but settlement remains with the platform's game logic. Video provides evidence about a physical table or stream; it does not replace the account ledger.
Specify responses for four cases: vision and game log match; vision detects an event absent from the log; the log has an event vision missed; or cameras conflict. Assign an allowed action, owner and audit record to each. Monitoring must not silently revise a wager record.
| Observation | Response | Record |
|---|---|---|
| Vision and service agree | Close the monitor event and retain evidence links. | Round ID, track ID and both event timestamps. |
| Vision sees an unlogged movement | Flag for operator review; do not infer a valid wager. | Frame sequence, camera health and expected rule phase. |
| Service logs an event not visible on camera | Check camera view, stream gaps and the event source. | Missing-frame span and service request ID. |
| Cameras disagree | Preserve each observation and apply the named source rule. | Calibration version and confidence from each source. |
Operations need measurable recovery criteria
Measure what tracking is for: detection precision, missed events, continuity, event-to-display delay, time in degraded mode, review volume and recovery after camera reset. Report by table and camera, not just site average. Count corrections by cause; more occlusion or rejected assignments can expose a layout change before a game incident.
- Alert when a stream freezes, drops below its frame target or exceeds clock-drift tolerance.
- Make camera health visible to the operator who receives the event alert.
- Require re-calibration after a camera or table configuration changes.
- Keep model release, threshold and tracker configuration in the event record.
- Test duplicate event delivery and service restart with an idempotent event key.
A successful system flags the right exception with evidence a person can resolve. Object or alert counts alone do not show better monitoring. Reduce review time for real discrepancies without increasing incorrect account decisions.
Tracking review before production
Exercise fast motion, overlapping objects, brief occlusion, camera shake, stream freeze, delayed packets, duplicate events, lighting changes and missed game transitions. Stop consequential suggestions when input is stale. Check that operators can locate source frames, inspect calibration and compare machine events with the game log.
During a shadow shift, follow one complete hand from detection to settlement. Log any object-ID switch, missing timestamp and whether staff could find the original frame in the review queue.