Object Detection and Image Classification
Detection and classification models trained on images from your own cameras and conditions, with a labelling process that survives disagreement and a threshold set from what each error actually costs.
Object detection demonstrations are trivially easy. A pretrained model draws boxes around cars and people, everyone is impressed, and the project is approved. The difficulty is entirely in the gap between that demo and a system that works on your objects, in your lighting, at your camera angle, at three in the morning in February.
Object detection locates and identifies specific objects within an image and returns their position; image classification assigns a label to an image as a whole. Both are supervised techniques trained on labelled examples, and in production both depend far more on the quality and representativeness of those labels than on the choice of architecture.
Labelling is the project
The single largest determinant of accuracy is the labelled dataset, and the largest determinant of labelled dataset quality is whether your own experts agree with each other. In almost every engagement we run an agreement exercise early, and it is routinely uncomfortable:
- Definition drift. Two inspectors label the same borderline object differently, because the class boundary was never written down precisely.
- Boundary cases. Partially occluded, out of frame, reflected in a surface, or at the edge of what counts. Every dataset has them and every one needs a rule.
- Class imbalance. The condition you most need to detect is the one you have the fewest examples of, by definition.
- Consistency over time. Labels made in week one and week six diverge unless the guide is enforced and audited.
We write the labelling guide with your experts, measure inter-annotator agreement, and fix the definitions before volume labelling starts. Doing this after the fact means relabelling, which is the most avoidable cost in computer vision.
How we build a vision model
Collect data that matches production
Images from the cameras you will actually use, in the lighting you will actually have, including night, glare, rain, dust and whatever else your environment provides. A model trained on clean daytime images and deployed to a night shift is a predictable failure, and it is a common one.
Start from a pretrained model
Fine-tuning a strong pretrained backbone on a few hundred to a few thousand labelled examples per class is almost always the right approach. Training from scratch is rarely justified outside unusual imaging modalities, and it multiplies the data requirement.
Augment for the conditions you expect
Rotation, scale, brightness, blur, occlusion and colour shift, matched to real variation rather than applied indiscriminately. Sensible augmentation is often worth more than additional raw images, and it is considerably cheaper to obtain.
Set the threshold from the cost of each error
A missed detection and a false alarm are almost never equally expensive. We establish both costs with you and set the operating point accordingly, then report precision and recall at that point rather than a headline accuracy figure that hides the trade.
Decide edge or cloud on the physics
Latency requirement, bandwidth available, whether images may leave the site, and power budget determine where inference runs. Where it must run on the device, that constrains the model and is a discipline of its own, covered under optical inspection for edge devices.
Monitor for the drift you cannot see
Cameras get dirty, get knocked, get replaced with a different model. Seasons change the light. Products change shape. We monitor input characteristics as well as prediction distributions, because the most common cause of a vision model degrading is that something physical changed and nobody told the software.
Get a hundred images before you promise anything
We ask for a representative sample early and label a small set ourselves. Half a day with real images tells you more about feasibility than a fortnight of specification, and it occasionally establishes that the objects are not reliably distinguishable at your camera resolution, which is a finding worth having before the budget is committed.
Where general detection is applied
| Use | What is detected | Where it usually runs |
|---|---|---|
| Inventory and shelf monitoring | Product presence, facings, gaps | Fixed cameras, cloud or edge |
| Safety compliance | Protective equipment, exclusion zones | Edge, for latency and privacy |
| Asset and vehicle counting | Vehicles, containers, equipment | Edge or cloud depending on bandwidth |
| Agricultural assessment | Crop, weed, fruit, disease markers | Edge, often on moving equipment |
| Retail analytics | Queue length, dwell, movement | Edge, with privacy constraints |
| Content moderation | Prohibited content categories | Cloud, at upload |
Where the application is specifically manufacturing defects, medical images or video over time, the specialised engagements handle the differences: visual quality inspection, medical imaging and video analytics.
How the engagement runs
Feasibility on real images comes first, and labelling agreement is settled before volume work begins.
Feasibility and labelling guide
Representative images assessed, class definitions written with your experts, inter-annotator agreement measured.
Dataset construction
Labelling at volume with audit sampling, augmentation designed for real conditions, splits made by scene rather than at random.
Model development
Pretrained backbone fine-tuned, error analysis by condition and class, threshold set from error costs.
Deployment
Inference deployed to edge or cloud, integrated with the consuming system, latency and throughput verified.
Monitoring and handover
Input and prediction drift monitoring, retraining pipeline, and handover of dataset, guide and code.
What you receive
A model that works in your conditions, and the labelled dataset that makes the next one faster.
Trained model
Weights and inference code, deployed to the target environment as infrastructure as code.
Labelled dataset
Your images with labels, the labelling guide, and the agreement measurements, all yours to reuse.
Performance report
Precision and recall at the operating threshold, broken down by condition, class and camera.
Threshold rationale
The cost of each error type and the operating point derived from it.
Deployment
Edge or cloud inference with measured latency and throughput at production volume.
Drift monitoring
Input characteristics and prediction distribution monitoring, with the retraining trigger.
Is this the right engagement?
Worth being direct. Object Detection and Image Classification is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- You can supply representative images from the cameras and conditions you will use.
- Experts can agree on class definitions and commit time to labelling review.
- A decision or action follows from the detection.
- The cost of a miss and of a false alarm can be estimated.
- There is a path to deploy inference where it needs to run.
Choose something else if
- The objects are not reliably distinguishable at your camera resolution.
- No images are available and none can be collected before the build.
- The task is really document extraction, which is intelligent document processing.
- Nobody will act on the detections once they exist.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How many labelled images do we need?
Typically a few hundred to a few thousand per class when fine-tuning a pretrained model, with more needed for rare classes and highly variable conditions. Quality and representativeness matter more than volume: a thousand images covering your real lighting and angles beat ten thousand from one sunny afternoon.
Can we use a pretrained model without training our own?
For common objects such as people and vehicles, sometimes yes, and we will say so rather than build unnecessarily. For your specific parts, products or conditions, fine-tuning on your own images is almost always required, because a general model has never seen your objects at your angle.
Should inference run on the camera or in the cloud?
It depends on latency, bandwidth, privacy and power. Real-time control and sites with limited connectivity need edge inference; batch analysis with good connectivity is simpler in the cloud. The decision constrains the model, so we make it early rather than after training.
What accuracy can we expect?
Unknowable before we see your images, which is why we label a small sample in the first fortnight. That exercise sometimes establishes that the objects are not distinguishable at your resolution, which is a useful finding before the budget is committed.
Why does a working model degrade over time?
Usually because something physical changed: a camera was cleaned, moved, or replaced with a different model, the lighting was altered, or the product itself changed. We monitor input characteristics as well as predictions, because that is the only way to catch a change nobody thought to mention.
Often paired with this
Most clients combine two or three engagements from the Computer Vision pillar. These are the ones that most often run immediately before or after.
Visual Quality Inspection and Defect Detection
Defect detection engineered from the imaging up, tuned to escape rate and false reject cost on your line.
Read more →Optical Inspection for Edge Devices
Vision models running on device within real thermal, power and latency budgets, with fleet updates handled.
Read more →Video Analytics and Surveillance AI
Video analytics tuned against alert fatigue, with tracking across cameras and privacy designed in from the start.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.