For build vs buy people counting, buy an off-the-shelf ONVIF people-counting module only when its accuracy clears the bar your use case needs, measured on your own footage under your own crowding, occlusion and mounting conditions. The per-camera licence price only matters once a module has passed that test. Automating inspection instead of keeping manual technician walk-throughs is a different decision. Its comparator is labour hours rather than a licence, it needs different evidence, and it should be costed separately.
TechnoLynx frames these two decisions separately for teams facing both. It starts by defining the counting or detection taxonomy, the accuracy bar and the cost baseline. It then compares the documented validation conditions of candidate VMS analytics against a custom detection-and-tracking design, and measures both on footage from a pilot site, as part of its computer vision R&D work.
Two decisions that keep getting bundled
In our reading, both questions involve cameras on a site, and that is all they share. Answering both with one business case hides the fact that each one fails for different reasons.
| Inspection automation vs manual walk-throughs | Build vs buy people counting | |
|---|---|---|
| What is replaced | Technician hours per site and per round | A per-camera VMS analytics licence plus integration |
| Binding constraint | Detection accuracy on the defects that matter, compared with what technicians actually catch | Count or queue-length accuracy on your mounts and traffic |
| Evidence you need | Labelled examples of real defects, plus your incident and risk history | Ground-truth counts made from your own recorded footage |
| What can be bought | Depends on the defect taxonomy | ONVIF and Profile M analytics modules from camera and VMS vendors |
| Main way the estimate slips | Taxonomy definition and labelling | Mounting geometry, crowding and occlusion at the real site |
Is automating inspection cheaper and safer than technician walk-throughs?
Automation pays off only if two things hold together: the per-site cost to build and run the pipeline is below the walk-through labour it replaces, and its detection accuracy is high enough that you would trust it over a technician. If either fails, keep the walk-throughs or extend the pilot.
No cost figure for this transfers from one organisation to another, because the inputs (site count, camera count, round frequency and loaded labour rates) belong to you. The cost comparison has two sides. On one side goes the amortised build cost, plus per-site cameras, compute, maintenance and periodic relabelling. On the other goes technician hours per round times rounds per year times the loaded rate.
The accuracy bar is harder. The threshold is a judgement you derive from two things: the cost of a missed defect in your incident data, and the miss rate your technicians actually achieve, measured rather than assumed. The fair comparison is pipeline against people, on the same set of labelled defects.
To estimate the time from taxonomy to a working pilot, establish how quickly the defect classes can be agreed and how much labelled footage already exists. Time-box the taxonomy and labelling stages before committing to a date.
Build vs buy people counting starts with an accuracy gate
People counting reverses the usual purchasing logic. Licence price is easy to compare and accuracy is not, so accuracy has to be settled first. Axis, in its counting-solutions white paper, declines to give an overall accuracy figure. It argues that such a number would only be correct in a laboratory setup and that accuracy depends on an intricate mix of environmental factors that cannot be reproduced from one site to the next. Instead, the white paper describes testing accuracy by manual counting on your own site. That is the basis for our measure-first rule.
Why do bought people counters lose accuracy once they are deployed?
Counting conditions vary between sites, and a result from one site does not predict performance at another. Indivd lists mounting height, camera angle, entrance width, lighting and traffic density as factors that can each change counting performance. The variation is large even when the technology is the same: in four stores using the same type of overhead 3D counter, one undercounted every day by 11.7% to 19.2%, and another moved from a 4.4% overcount to a 14.8% undercount.
Mounting geometry drives occlusion. According to Axis, angled views raise the risk of people being partly or completely hidden, while a top-down mount that detects head and shoulders reduces obstruction. The AXIS People Counter manual also warns against strong sunlight, sharp shadows, loitering people and slightly swaying large objects in view. Axis describes its separate 3D counter as suitable for crowded scenes and difficult light.
MOT20’s authors expect crowding to push trackers to their limits. The MOT20 benchmark was built for very crowded scenes, filmed in high resolution from an elevated viewpoint, with a mean density of 246 pedestrians per frame. That is ten times the density of the first MOTChallenge release. The detection baseline tables published with MOT20 show recall ranging from 55.2 on MOT20-08 to 86.5 on MOT20-01. The MOT20 authors also note that most methods can be heavily overfitted to one dataset and may not handle a different setting without major changes to parameters or model.
These are the failures behind our wider view of production vision. Detection and tracking get treated as solved problems, but off-the-shelf models that work in a demo fail on the edge cases, lighting and throughput of a real deployment.
Has this ONVIF module been validated on fisheye or overhead mounts?
Ask the vendor which footage the accuracy claim came from. If the answer is eye-level entrances, treat the claim as unproven for overhead fisheye mounts. Most people detectors were developed for side-mounted rectilinear cameras, where standing people appear upright. In overhead fisheye images, people appear radially, at any orientation, sometimes upside down, and with lens distortion that grows towards the edge of the image, according to a 2024 review in Frontiers in Imaging. The RAPiD paper (Duan et al., CVPRW 2020) found that such detectors perform poorly on overhead fisheye images and tend to miss non-upright bodies, so rotated bounding boxes are needed.
Good fisheye results on staged data did not carry over to in-the-wild footage. The same review reports AP50 above 93% on three staged datasets recorded with high-quality cameras and instructed subjects. On the in-the-wild WEPDTOF clips, every metric was significantly lower, and bounding boxes appeared and disappeared intermittently. The WEPDTOF authors built their dataset because performance in naturally occurring scenes was unknown.
The counting results are sobering. Over three days, single-camera RAPiD produced exact counts in 46–55% of frames and counts within 10 of the truth in 76–79% of frames, which the review’s authors call mediocre. They put the reliable range of one camera mounted 3.15 m high at about 8.7 × 8.7 m (around 75 m²). Two cameras were enough for a 187 m² space.
Three public overhead fisheye datasets are annotated with rotated, person-aligned boxes:
- HABBOF: 5,837 annotated frames from four videos, with lights switched on and off and furniture moved.
- CEPDOF: 25,504 annotated frames with up to 13 people, severe occlusions, unusual poses and low light, with IDs kept consistent across frames for tracking evaluation.
- WEPDTOF: 16 in-the-wild clips from 14 scenes, with 1 to 35 people per frame and 188 identities labelled across time.
A module that cannot show results on footage like this, or on your own, has not been validated for overhead use.
What ONVIF and Profile M conformance tell you
ONVIF’s Profile M overview (May 2022) lists people counting among its business-intelligence applications and names a line-crossing counter for object counting events. Support for a metadata stream is mandatory for all Profile M conformant products. The ONVIF Analytics Service specification requires a device to implement the Scene Description Interface. A device must implement the rules interface only if it also supports a rule engine.
So a conformance badge tells you the camera can send structured object metadata. It does not guarantee a counting rule, since the rules interface is required only with a rule engine. The specification even sets out how to report the moment the analytics can no longer track two people separately: it signals an object merge, followed by a split when they separate.
The conformance check is therefore narrow: confirm that the counting rule you need is supported on the exact camera and firmware, then measure it. One related question to ask is whether the VMS lets a custom tracking model feed its analytics. If it does, a hybrid route becomes possible, but you have to confirm that per product.
What counting accuracy should we require, and how do we test it on our own footage?
Axis’s own guidance gives a usable starting bar: under normal circumstances, total accuracy should be 95% or higher. A difference of under 5% between people counted going in and people counted going out is a good first sign that the configuration is right. Whether 95% is enough for you depends on what the count drives.
A procedure for testing a vendor’s accuracy claim on your footage
- Fix the metric first. Indivd points out that crossings at a line, occupancy in an area, movement between zones and unique visitors are different measurements, and that accuracy on one does not prove accuracy on another. Queue length is an occupancy problem, and AXIS documents that naive in-minus-out occupancy builds up error over time, more so with high flow.
- Record from the real mounts. Cover both quiet and peak periods, which Indivd says a vendor’s ground truth should also state.
- Build ground truth by hand. Review the recorded footage person by person and compare it with the system’s count. The Axis white paper suggests counting people going in up to 200, then computing the error as (#IN − 200)/2. It also warns that manual counting is far from perfect in crowds.
- Use a real sample. The AXIS manual asks for 100 or more manually counted passages. Indivd adds that a small number of crossings says less than a larger sample covering changing traffic volumes.
- Score with a metric that fits the decision. For occupancy, the Frontiers review’s X-Accuracy gives the share of frames whose count falls within X of the truth. For tracking, MOTA combines false negatives, false positives and identity switches against the ground-truth count.
- Plan re-verification. Indivd notes that accuracy describes an installed camera under current conditions, and that maintenance moves, refocusing, new fixtures, lighting and traffic changes can all alter it.
Run the same procedure on a candidate module and on a custom spike, and you have a like-for-like comparison.
What a custom people-counting pipeline involves
A custom pipeline has four parts: a detector suited to the mount, a multi-object tracker, line-crossing or zone logic, and edge deployment sized to the frame rate. In the Ultralytics guide, you define a line or polygon, pass it to the ObjectCounter, and it tracks objects across frames and tallies IN and OUT crossings. Its defaults matter in production. For example, that counter keeps at most 300 detections per frame before tracking in dense scenes.
Detector. For overhead fisheye, RAPiD extends YOLO to predict a rotation angle for each box, at nearly YOLO’s inference speed because each image is processed once. Fine-tuning a COCO-trained detector on overhead fisheye images gave a significant performance increase. RAPiD still produced false positives on a projection screen and missed people in very low light.
Tracker. ByteTrack (Zhang et al., 2021) keeps low-score detection boxes, which other methods discard, and uses their similarity to existing tracks to recover occluded people. It reports 80.3 MOTA on the MOT17 test set at 30 FPS on a single V100. A V100 is a datacentre GPU, so its throughput does not show what an edge box running several streams achieves. You have to measure that on the target hardware.
Crossing logic. Roboflow’s Supervision LineZone can require a detection to stay on the other side of the line for a minimum number of frames before it counts as a crossing. This guards against unstable boxes that linger on the line.
Multiple cameras. In larger spaces, overlapping fisheye cameras need identities matched between cameras. The Frontiers review used location-based matching, citing earlier work that found it performs better with overhead fisheye cameras.
This is where our primary position applies. Off-the-shelf vision fails in retail and operational deployments less because the task is intractable than because scale breaks assumptions a small deployment never exposes. TechnoLynx holds that such compound failures need an engineering approach, not a model swap.
What does three years of per-camera licensing cost against owning a tracking stack?
Three-year TCO is a model you fill with your own camera count, rates and refresh plans. The structure of the comparison holds even though the numbers vary. The AXIS People Counter licence is valid for one camera only, and covering a wide entrance with neighbour counters requires cameras of the same model.
| Cost line over 3 years | Buy (VMS or camera counting module) | Build (custom tracking stack) |
|---|---|---|
| Software | Licence × cameras, plus renewals | Engineering to build the detector, tracker and counting logic |
| Hardware | Compatible cameras; same model for neighbour counters | Cameras plus edge compute sized to stream count |
| Integration | VMS and event wiring | VMS and event wiring, plus deployment tooling |
| Accuracy validation | Your own ground-truth tests | The same tests |
| Ongoing | Re-verification and tuning after site changes | Re-verification, retraining, dependency and model maintenance |
Validation and re-verification appear in both columns because neither route removes them.
The decision rule follows from the gate. If a module meets the required queue-length accuracy on your fisheye or overhead footage at a lower three-year TCO, buy it. If no module meets the bar on those mounts, build, even at a higher TCO, because a cheap count that is wrong has no value.
Who can run a counting bake-off on our own footage?
TechnoLynx can run this comparison as engineering work. It defines the counting metric and the accuracy bar, configures the candidate VMS module or builds a reference custom pipeline on your target hardware at a pilot site, and measures accuracy on your fisheye or overhead footage. The pilot also produces real per-site cost and timeline figures. The work sits within TechnoLynx’s computer vision R&D practice.
This is not the right engagement for a single, well-lit entrance with a standard angled camera. There, run the vendor’s own validation procedure with your integrator. For a team with in-house vision engineers, the procedure above is the route, and outside help is worth it mainly when the in-house team lacks fisheye or crowded-scene tracking experience.
Settle the metric before the shortlist
Settle what is being counted before arguing build versus buy. A module that counts doorway crossings accurately has not shown it can track queue length under an overhead fisheye lens, and a custom pipeline that tracks well has not shown it can count once across overlapping cameras. Write down the measurement that drives your decision (crossings, occupancy or queue length), the error you can tolerate, and the footage it will be tested on. Shortlisting, and the licence-versus-build arithmetic, are only worth doing after that.
