Computer vision
Running computer vision on CCTV cameras you didn’t choose
Nobody replaces sixty cameras to try analytics. What it takes to get useful results from mixed, badly angled, years-old hardware.
6 min readByteWeave Studio
Vision papers assume a camera you selected, mounted where you wanted it, at a resolution you specified. Retail analytics assumes none of that. The cameras are already there, they were installed for insurance rather than analysis, and replacing them across eight stores is not a conversation anyone wants to have.
Everything then follows from working with what exists. That constraint is not a limitation on the project so much as the actual shape of it.
What "existing cameras" really means
In practice it means a mix. Some 1080p IP cameras from a recent refit, some 720p, and a few analogue units behind an encoder that introduces its own compression artefacts. Frame rates vary per stream and drop under load. Several cameras are mounted high in a corner for maximum coverage, which is the worst angle for counting people and a poor one for anything at shelf height.
Lighting changes through the day in ways a fixed threshold cannot absorb: bright at the entrance in the morning, mixed under fluorescents by afternoon, and reflective off the floor near close. Any approach that needs consistent framing or consistent illumination is out before you start.
Do the work on site
The instinct is to ship frames to a server and run inference centrally. The uplink at a typical retail store makes that impossible for more than a couple of streams, and running it anyway is how you discover the store’s card terminal shares that connection.
Inference belongs on a small box in the back office, with only events leaving the premises. A zone count and an incident with a timestamp are a few hundred bytes; the video they came from is not. This also resolves most of the privacy conversation before it starts, because footage never leaves the site.
Reason about zones, not frames
A detector that outputs bounding boxes gives an operations team nothing they can act on. What a store manager can act on is "the counter queue has been above four people for six minutes". Getting from one to the other means someone marks the regions that matter on a still from each camera — the entrance, an aisle, the billing counter — and the system reports at that level.
This also makes a bad camera angle survivable. A camera too high to identify individuals reliably can still tell you how many people are inside a marked region and how long they stay, and that is most of the operational value.
Set expectations per camera, not per system
Some cameras will support everything. Some will only support occupancy. Being explicit about which is which, at install, prevents the slow erosion of trust that happens when one badly angled camera produces nonsense and the client generalises from it.
We write it down per stream: what this camera can report, and what it cannot. It is a short document and it has saved more difficult conversations than any accuracy improvement.
- Computer vision
- CCTV
- Edge inference
- Retail
More reading
Computer vision
Edge or cloud for video analytics: what it actually costs
The cloud version looks cheaper until you price the bandwidth. A worked comparison for a small multi-site deployment.
6 min read
Document AI
Why your invoice OCR works in testing and fails in production
The test folder is clean exports. The real intake is phone photographs. What changes between the two, and how to find out before a client does.
5 min read
LLM engineering
Why your RAG demo works and your RAG product doesn’t
A retrieval demo on twenty documents proves almost nothing about the same system on twenty thousand. The four things that break in between.
6 min read
Have a problem
worth solving?
Tell us what you're building. We'll help you figure out what's possible — and say so if we're not the right people for it.