Development of an Object Counting System in Frame (Object Counting)

Counting objects in a frame: where accuracy breaks on a live stream

On a test video, the object counting system almost matches manual annotation, but during a real shift the count diverges. It is not about the model: the test video was shot in convenient conditions — one viewpoint, even lighting, rare occlusions.

The flow at the entrance to a workshop or at a checkpoint behaves differently, and counting accuracy on a live stream is determined by how the system withstands these deviations.

The first source of errors is occlusions. In a dense group, the detector sees silhouettes partially, and the tracker either splits one object into two or merges two people into one.

Backlight and night mode add loss of contrast: a person against a window becomes a blob, and noise produces spikes resembling movement. Each such event is plus or minus one in the final count.

The second source is false positives. Glare, reflections in glass, shadows from equipment, and swaying branches fall into the zone of interest and are counted as objects. Raise the confidence threshold — misses increase; lower it — noise increases.

That is why in an object counting system, the threshold and deduplication rules are configured not globally but by zones: stricter at the crossing line, softer at the frame periphery.

Object tracking in video feeds reporting, so discrepancies quickly become noticeable. The duty shift checks the archive manually: runs disputed intervals frame by frame to find two lost people, spending hours on it instead of doing rounds. After that, the system either loses trust or becomes overgrown with constant manual corrections.

We explain how this is resolved: which settings, zones, and checks are needed so that the count matches not in a demo but throughout the entire shift.

What changes after implementation: accounting, accuracy, service response

We measure the effect of implementation not by impressions but by on-site measurements: we take control shifts with manual recount, analyze disputed episodes, and compare the event log with this reference.

This shows where the system actually relieves workload and where a discrepancy remains. Below are three metrics that the customer usually sees first.

Share of episodes closed without viewing the archive

Each event is saved as a card: time, zone, object class, trajectory. The operator does not need to scroll through the recording — 8 out of 10 disputed episodes are closed from the card in a minute instead of fifteen. The remaining two require viewing, and this is already a conscious choice, not a daily routine.

Response time to discrepancy

An event is generated at the moment of line crossing or zone entry, so the signal goes to the dispatch center during the same shift, not at the morning review.

The discrepancy is visible while it can still be corrected: replace a crew, recount a batch, adjust the loading procedure. Previously, this episode surfaced only in the final report, when the decision no longer changed anything.

Class of failures that disappears entirely

The main source of undercounting is dense flow and short occlusions: people and equipment obscure each other, and at night detection fails.

The tracker maintains IDs through occlusions, and illumination pulls out night frames, so the failure "lost an object in a crowd" ceases to be regular.

We additionally train the model based on YOLO on frames from the specific site — accuracy on the live stream holds up instead of dropping after a month.

Methods of video-based counting: comparison of approaches and limitations

The accuracy of counting objects in a frame is determined not by the recognition model but by what the system considers an event: crossing a boundary, being in an area, or traversing a path.

The wrong choice of mode produces systematic undercounting or double counting, which cannot then be fixed by tuning thresholds.

How the mode is selected for the scene

First we fix what we are counting: the fact of entry, the number of simultaneously present objects, or duration of presence.

For a gate, one boundary is enough with direction control and event confirmation over several frames; for a zone, hysteresis is important — an object is counted after sustained presence, not on first contact.

When a frame contains both flow and occupancy, the combined mode separates the tasks: the gate counts entries, the zone counts the current quantity.

Common limitations of the methods — dense occlusions, night, backlight, reflections — are removed by selecting the viewpoint, not only by additional training. We verify the result with manual recounts on short segments: it shows where there is the most noise.

How we implement the system: from camera audit to handover

The stages of video analytics implementation are the same for one camera in a warehouse and for a network of points in a hall: first we record what the camera actually sees, then configure the rules, and only after testing on past recordings do we put the system into operation.

Audit of shooting conditions and viewpoints

An engineer travels to the site and analyzes each viewpoint: suspension height, tilt, backlight from display windows, occlusions by shelving, zones where objects merge into a flow.

The result is a camera placement diagram and zone marking: where the counting line passes, from which area an object should not exit twice.

Configuring counting rules and thresholds

We formulate the rules in terms of the task: count by line or by zone, how to separate people and carts, at what duration of presence an object is considered real rather than a shadow.

We select thresholds on recordings from past shifts — there, night mode and peak hours are also visible.

1. Survey of shooting points: viewpoints, lighting, blind zones.
2. Coordination of the placement diagram and counting zones with the department head.
3. Marking lines and areas, configuring rules and thresholds.
4. Run on video archive from past shifts and comparison with actual data.
5. Correction of discrepancies: viewpoint, thresholds, scene separation.
6. Acceptance on a live stream during peak hours.
7. Handover to operation: reporting instructions, access, maintenance regulations.

What the customer keeps: diagrams, rules, regulations

An object counting system lives not in the model but in the bundle "camera — zone — rule — operator." That is why we hand over not only a working service but also a set of documentation that your team can use to operate, check, and develop it without us.

• Camera placement and counting zone diagrams — topology of shooting points, viewing direction, marking of counting lines and areas of interest linked to the site plan.
• Description of rules and thresholds — which object classes we count, how confidence thresholds are set, track hysteresis and line crossing direction, and why these particular values were chosen.
• Matrix of typical discrepancies — a table "symptom → cause → action": false positives on shadows, double counting of a returning object, merging under dense flow.
• Operator instruction — how to read the panel, what to do when there is a discrepancy with manual recount, where to escalate, and which recording fragments to attach.
• Operation regulations — frequency of channel and image quality checks, procedure for loss of stream, camera firmware updates, and relocation of a shooting point.
• Procedure for additional training for new scenes — how to collect and annotate a sample, which metrics are considered acceptable, how to test the model on reference recordings before publication.
• Configuration change log — versions of rules, zones, and models, indicating what changed and why.

Warehouse case study: counting errors reduced threefold

At a logistics operator's warehouse, the number of units during receiving was checked manually, and disputed episodes were analyzed by reviewing camera archives.

The implementation of object counting Sklad-Obzor covered eight shooting points in the loading zone: receiving, shipping, picking, and exit gates.

What it was before

Discrepancies by shift reached 12% of daily turnover, and at night — higher: mixed lighting, pallets obscuring each other, two zones appearing in the frame at once. Trigger thresholds were set by eye, so the system either lost units or counted them twice. Finding one disputed episode took up to an hour — reviewing the archive without event linkage.

What it became after

Viewpoints were separated by zones, a separate detection was set up for pallets and boxes, and the minimum object size was tied to the unit of accounting. Occlusions are handled by trajectory: an object that has hidden behind another is not counted again.

Handover of results is not just a report: the shift sees its discrepancies in the panel, and a disputed episode opens as a recording segment with a timestamp.

The review procedure and training of storekeepers were assigned to the counting staff so that automation does not argue with a person but confirms their decision.

How to count people at the entrance and not confuse them with shadows in the frame?

Counting objects in a frame "head-on" is a dead end: the shadow from a portal light follows next to a person and is read as a second target, while a reflection in a glass door adds a third.

That is why in counting people at the entrance we record not individual targets but crossings of the counting line inside the zone of interest, confirmed by stable tracking across frames.

The viewpoint matters more than the model. We place the camera at an angle to the counting line, not "head-on": then the shadow moves away from the axis of movement and stops merging with the silhouette.

We remove lights and display windows from the zone of interest, and suppress glass reflection with a hood and exposure.

We build person detection on the YOLO family of models and additionally train on frames from the specific entrance — but without scene geometry this gives little.

In a narrow passage, one counting line almost always counts twice: people walk close together and occlude each other. Moving the line beyond the "bottleneck" and the hysteresis rule help — an event is recorded once per object within a given interval.

We separate opposing flows by direction: entry and exit are counted by the sign of crossing and their own zone, so simultaneous movement in both directions does not break the balance.

We check not by eye but on a recording from a busy hour: we run the stream through the configured setup and compare with manual recount by segments.

We look at the share of false positives on shadows and reflections, the discrepancy "entered minus exited," and losses under dense flow.

Based on these measurements, we adjust the confidence threshold, zone size, and line position — until the discrepancy with manual counting becomes isolated.

Technical concerns: cameras, weather, occlusions, and crowds

Before a pilot, customers ask the same questions: will the cameras already installed work, what happens in rain and snow, will counting "stick together" in a crowd, and what to do with permanently closed zones. We check each point on a recording from a real site, not on a demo video.

What happens in rain, snow, and fog?

More often it is not the weather itself that interferes but a wet lens: splashes and blurred spots are taken by the model as objects. Hence the requirements for a heated housing and training on night, snow, and fog series of frames.

In poor visibility, we count by trajectories — short gaps are restored, and counting remains continuous.

How does counting behave in a dense crowd?

In a dense flow, people occlude each other, so detection is based on heads rather than the whole figure. The ID is maintained during short occlusion through trajectory prediction — a person is not counted twice when entering and leaving a group. In the densest areas, we count along a control line rather than the entire frame area.

Part of the scene is always blocked — a column, pole, vehicle

Permanent occlusion is solved by task formulation, not by the model: we shift the shooting point, add a second viewpoint, or move counting to a line in front of the obstacle.

The appearance of a person from a blind zone is recorded as a known limitation in the system passport — the operator sees where the number is accurate and where verification is needed.

Let's discuss the task and come back with an estimate and work plan

To come back with an estimate and work plan rather than general words, we need a minimum of inputs about the scene and how the result will be used.

These data determine both the model configuration and the amount of annotation, as well as which metrics will become acceptance criteria — so it is better to discuss the task before, not after, development starts.

• Nature of the scene and types of objects: static or mobile camera, flow density, occlusions, night and weather conditions, what is considered one object when it partially enters the frame.
• Access to recordings: archive for 2-4 weeks in source quality plus several reference segments where you manually know the correct answer.
• Expected accuracy and acceptable error class: what is more critical — missing an object or a false positive, and what share of discrepancies with manual counting is considered acceptable.
• Pilot boundaries at one site: which site we take, over what time interval we count, who on the customer side verifies the result.
• Integration points: where we take the video stream from, where we send counters and events, whether history viewing by intervals is needed.
• Reporting format: how often and in what form a summary is needed, whether exports and visual slices by zones and hours are needed.

Based on the discussion, we fix the deployment scheme and come back with an estimate and work plan: implementation timelines by stages, team composition, accuracy verification procedure, and conditions for moving from a pilot at one site to scaling to the rest. Describe the task — we will come back with an estimate and plan.