Services
Computer vision for industry, on the cameras you already have
Quality inspection, counting, tracking and anomaly detection, running on the device next to the camera. No stable uplink required, no rip-and-replace of the equipment on the line.
A two-week audit on your own images tells you whether the problem is solvable before you commit to a pilot.
Send us a handful of images
An engineer, not a sales rep, replies within one business day.
The inspection problem, stated honestly
Visual checks on a line are done by people, and people are good at them. The difficulty is not perception, it is consistency, coverage and evidence. Three problems follow from that, and computer vision addresses them in different degrees.
The standard depends on who is on shift
Two experienced inspectors will disagree about borderline cases, and the same inspector will judge differently at the end of a shift than at the start. Neither is negligence. It is what visual judgement under time pressure looks like.
The consequence is that your quality standard is not a fixed line, it drifts by person and by hour, and nobody can say by how much. That also sets a hard ceiling on any model you train, because a model can only be as consistent as the labels it learns from.
You inspect a sample, and the defect is in the rest
Full inspection of every unit is usually impossible by hand, so a sample stands in for the batch. That works until the defect is intermittent, which is exactly when it matters most and exactly when a sample misses it.
A camera does not get bored and does not take a sample. Where the defect is visible in a still frame, inspecting everything becomes possible for the first time.
There is no record to argue from
When a customer rejects a delivery, the question is what left your plant in what condition. A tick in a logbook is not evidence. Without images attached to units, the discussion is one recollection against another and you will usually concede it.
What we build with computer vision for industry
Computer vision for industry is narrower than the phrase suggests. The systems that pay for themselves tend to be one of five things:
- Visual quality inspection. Surface defects, dimensional deviation, assembly errors, checked on every unit rather than a sample.
- Counting and tracking. Throughput, yield and work-in-progress measured directly instead of inferred from production records.
- Anomaly detection. Models trained on normal output that flag the unusual, for defects too rare or too varied to label.
- Condition and behaviour monitoring. Equipment and, in agriculture, animals. Our lameness-detection work under the AGRARIAN programme is this: cameras in the barn, inference at the edge, an alert to the farmer.
- Safety and compliance checks. Zone intrusion, protective equipment, process step verification.
All of them run at the edge. Sending video to a cloud for inference costs bandwidth you do not have and adds latency the line cannot absorb.
Where it works, and where it does not
The deciding factor is rarely the model. It is whether the thing you want detected is visible, consistently, in the images you can actually capture.
Works well
- The defect is visible to a trained human in a still frame
- Lighting and camera position can be held constant
- The product presents in a limited number of orientations
- You have historical images, or can collect them in weeks
- A false positive costs a second look, not a stopped line
- The decision is currently made by eye, and inconsistently
Works badly
- Inspectors disagree with each other about what counts as a defect
- The signal is subsurface, or needs touch, sound or smell
- Lighting changes through the day and cannot be controlled
- The defect appears a handful of times a year
- Nobody will act on the output, because the process has no slack
- The real requirement is a report, and a sensor would produce it
The second column is the more useful one. If a project sits there, we will say so in the audit rather than build a pilot that confirms it eight weeks later.
How much data you need
Less than most vendors imply, and more than most clients expect to provide. For a defect class with a consistent appearance, a few hundred labelled examples is usually enough to establish feasibility. The harder constraint is agreement: if two inspectors label the same image differently, the ceiling on model accuracy is set by that disagreement, not by the architecture.
The first thing the audit does is measure inter-inspector agreement on a sample of your images. When it comes back low, the fix is a clearer defect definition, and that fix is worth more than any model.
The hardware question
Usually there is no hardware question. We act as a layer on top of the cameras, controllers and gateways you run. Where an edge device is genuinely needed, we specify commodity hardware, NVIDIA Jetson class or an industrial x86 gateway, and size it against the model after optimisation rather than before. Quantisation, distillation and pruning routinely cut the requirement by an order of magnitude, which is the difference between a device per line and a device per plant.
How a pilot runs
- Discovery callThe operational problem, sample images, and what success would look like as a number.
- Data auditImage quality, inspector agreement, edge constraints. Written go or no-go. About two weeks.
- Pilot on one lineA working model on real hardware, measured against the agreed target. 8-12 weeks.
- Scale and operateFurther lines or sites, with monitoring, retraining and handover documentation.
Once a model is live, keeping it accurate is a separate discipline. That is the MLOps side of the work, and it is where vision projects quietly decay if nobody owns it.
Questions we get asked
Can you use our existing cameras?
Usually yes. Most industrial and CCTV cameras are adequate for detection and counting. The common blockers are not resolution but lighting, camera angle and motion blur, and all three are cheaper to fix than a camera replacement programme. The audit tells you which of them applies.
How many labelled images do we need?
For a well-defined defect on a consistent background, a few hundred examples per class is often enough to know whether the approach works. For rare defects, anomaly detection on normal images is usually the better route, because you cannot collect what almost never happens.
Does it need an internet connection?
No. Inference runs on the device, next to the camera. A connection is used to ship model updates and to send results upstream, and the system buffers and continues when the link drops. Farms and remote sites are the normal case, not the exception.
What accuracy can you promise before we start?
None, and you should be wary of anyone who does. What we commit to is a measurement: the audit reports what your data supports, and the pilot is measured against targets we agree in writing before it starts.
What if the audit says it will not work?
Then it says so, in writing, and you have spent two weeks instead of a year. That outcome is common enough that we treat it as a normal result rather than a failure.
Next step
Bring images, not a specification
The fastest way to find out whether computer vision fits your line is to look at your own images. The two-week audit reports what they support and returns a written go or no-go before a pilot is scoped.
Free 45-minute call. Then a two-week data audit with a written go/no-go before you commit to anything.
Send us the problem
An engineer, not a sales rep, replies within one business day.