Computer vision, explained: what a camera can actually do for your business
Not the research-paper version. The version where a camera points at something you care about, and the answer it gives is good enough that somebody stops checking by hand.
The short version
Computer vision is software that looks at an image and produces an answer a computer can act on. Not a description, not a picture - an answer. How many. Which one. Is it right. Where is it.
That last part is the whole point, and it is what separates a working deployment from a demo. A person watching a monitor already has eyes. What they do not have is the patience to watch for eleven hours, or the ability to be in four places at once, or a record afterwards of what they saw at 3:40pm. The camera is not better at seeing than your staff. It is better at not stopping.
The four jobs a camera actually does
CountHow many items, people, vehicles or units passed, arrived or are currently present. The most reliable class of job, and usually the cheapest to prove.
InspectIs this one acceptable. A missing label, a crack, a wrong colour, a seal that did not close. Harder, because it needs examples of what "wrong" looks like.
ReadTurn what is printed or written into text: a serial number, a batch code, a plate, a handwritten form. Mature technology, but very sensitive to angle and focus.
LocateWhere is it, and is that where it should be. An empty bay, a pallet in a walkway, a tool left behind. Often the highest value, because it catches things nobody was assigned to look for.
Almost every real brief is one of these four, or a chain of them: locate the label, read the code, check it against the order. If a proposal does not resolve into these, it is probably still a wish rather than a specification.
Why "99% accurate" is not an answer
Accuracy is the number every vendor quotes and the number that tells you least. Here is why.
A system can be wrong in two directions. It can miss something that was there - a defect it failed to flag. Or it can flag something that was fine. These are completely different problems with completely different costs, and a single accuracy figure averages them into meaninglessness.
Consider an inspection job where 1 in 200 units is defective. A system that simply passes everything is 99.5% accurate and catches nothing at all. The number looks excellent. The system is useless.
So the question to ask is not "how accurate is it" but "which mistake costs me more, and how often does it make that one?" If a missed defect reaches a customer, you tune hard against misses and accept more false alarms. If every false alarm stops a line and costs twenty minutes, you tune the other way. You cannot have both at once, and anyone who implies you can has not run one of these in production.
That trade-off is a business decision, not a technical one. It belongs to you. Our job is to make it explicit rather than to bury it in a number.
What makes it hard in the real world
Vision demos are easy. Vision deployments are not, and the gap is almost entirely about conditions rather than algorithms.
Light moves. A model tuned in the afternoon can fail at 8am when the sun comes through a roller door, or at night under different lamps. Controlling the lighting is frequently cheaper and more effective than improving the model, and it is the first thing we look at.
Things overlap. Items stacked, partially hidden, or passing behind each other are the single most common cause of miscounts. Where the camera sits matters more than which model runs behind it.
Rare things are rare. To recognise a defect, a system generally needs examples of that defect. If it happens twice a year, you have two examples, and that is not enough. Sometimes the right design is to flag anything unusual for a person rather than to try to name the specific fault.
Nothing stays still. A camera gets nudged. A supplier changes packaging. A process changes and nobody mentions it. Accuracy decays quietly, which is the worst way for it to happen, so anything worth deploying watches its own performance and says when it has drifted.
The edge cases are the job. Getting to 80% takes days. The last stretch is where the work is, and whether you need that stretch depends entirely on the cost of being wrong - which is the trade-off above, showing up again.
What to have ready before the first camera goes up
- A decision, not a wish - "we want AI on the line" is not a brief. "Tell us when a carton leaves without a label" is.
- Someone who can say what correct means - a person whose judgement everyone accepts. If two supervisors disagree about whether a unit passes, no model can settle it for them.
- Examples of both answers - footage of the good case and, crucially, the bad one. The bad examples are almost always the bottleneck.
- A cost for each kind of mistake - rough numbers are fine. They set where the system is tuned.
- Somewhere for the answer to go - an alert, a dashboard, a record, a stop signal. A camera whose output nobody receives has automated nothing.
Where it pays, and where it does not
Vision pays when the task is repetitive, continuous and consequential: something that happens hundreds of times a day, that a person currently checks or currently does not check at all, and where missing it costs something real.
It tends not to pay when the volume is low enough that a person handles it comfortably, when the judgement is genuinely subjective, or when the answer would not change what anyone does. A camera that produces a number nobody acts on is an expensive way to generate a spreadsheet.
We will say so when that is the case. Turning down work that will not deliver is cheaper for everyone than delivering it and watching it get switched off in month three.
Seeing is usually half the job
Detection on its own rarely finishes a brief. Once a system can reliably see something, the next question is what happens next - an alert, a record, a rejected unit, or an actual machine that moves. That is where vision meets robotics and physical AI, and why we treat them as one discipline: what the camera can reliably detect determines what the motion can safely attempt.
For a worked example of vision and a moving platform feeding a business system rather than a dashboard, see the Hock Lim Engineering rover case study.
And if you are still working out which kind of "AI" your problem actually needs, this piece sorts the categories out.
Looking for the service page? The overview lives at computer vision.
Have something you want a camera to notice?
Tell us what the feed should catch, how often it happens, and what it costs when it is missed. You will get a straight answer on whether a camera is the right tool - including when it is not.