An off-the-shelf model knows 80 generic classes. It does not know your product, your defect, or the specific thing you need counted. Custom detection is the work of teaching it, on the smallest amount of labelled data that will actually get you there.
If one of these sounds like your situation, a short call is probably worth your time.
You need to count units, people or vehicles and the manual count is expensive, slow, or quietly wrong.
A pretrained model nearly works, but misses your specific object class or confuses two that matter.
Defects are being caught by eye at the end of the line, inconsistently and too late to fix the batch.
Counts drift when the scene gets busy, because the system is counting detections instead of tracking identities.
Every stage ends with something you can evaluate, so you are never asked to fund the next stage on faith.
What counts as a detection, and what counts as a miss. This sounds trivial and is where most projects go wrong: a 'defect' that three inspectors label differently cannot be learned by any model. We settle it before labelling.
Targeted labelling beats bulk labelling. Occlusion, odd angles, poor light and the near-miss classes are worth more per image than a thousand clean frames. Existing annotations get audited rather than trusted.
Model selection against your latency budget, then training with the augmentation that matches your real variation. Evaluation reports per-class performance and the confusion pairs, so you can see exactly which mistake the model is making.
Detection is half the job. Counting needs stable identity across frames, a line or zone definition that matches how the business counts, and de-duplication. The training pipeline comes with it, so adding a class later is a retrain your team can run.
Far fewer than most people assume when the images are chosen well. A few hundred well-varied, correctly labelled examples per class usually beats several thousand near-duplicate frames pulled from one video. What matters is how much genuine variation you cover, not how many files you have.
Yes, and counting is a separate problem from detection. Counting unique objects requires tracking, so each object keeps a stable identity across frames and is counted once as it crosses a line or enters a region. Counting raw detections per frame is the single most common reason production counts come out inflated.
Often, though resolution, frame rate and placement set the ceiling. Small objects far from a low-resolution camera are the common blocker. The honest way to find out is to look at your actual footage first, which is where any engagement starts.
You get the training pipeline and the labelling guide, so adding a class is a retrain your team can run rather than a new engagement. That is deliberate: a system you cannot extend without the original vendor is not a system you own.
These are full walkthroughs with code, not case-study summaries. Read them and judge the engineering before you book anything.
A practical walkthrough of a compact Python script that detects, tracks, and counts people inside polygon zones using Ultralytics YOLO26 and OpenCV.
Read article →
Discover how to achieve advanced items segmentation in supermarkets with Ultralytics YOLO11 for efficient object detection and analysis.
Read article →
YOLO26, YOLO11 and YOLOv8 side by side: what actually changed between them, the published accuracy and size numbers per variant, and a straight answer on which one to use for detection, edge deployment, or transfer learning.
Read article →Tell me what you want to see, read, or measure. You will get a straight answer on whether it is solvable, what accuracy is realistic, and what it costs, including when the answer is that you should not build it.