Object Detection in Practice: YOLO, R-CNN and Better Dataset Design
A practical research note on choosing an object-detection approach from latency, localization, segmentation and dataset constraints—not from model-version numbers alone.
When people describe computer-vision skills, they often list model names: YOLOv5, YOLOv6, YOLOv7, YOLOv8. That is useful for documenting experiments, but it is not the best way to explain engineering capability. A stronger question is: what kind of perception problem are we solving, under what deployment constraints, and what data do we actually have?
My own vehicle-detection work has reinforced this view. The model family matters, but dataset definition, labels, domain shift, latency and the downstream control objective often matter more.
Start with the task, not the version number
Object detection means locating and classifying objects in an image. In an intelligent-transportation system, that might mean cars, buses, motorcycles, ambulances and fire trucks. In medical imaging, the visual target and evaluation protocol can be very different. The detector should follow the task.
A useful first split is between one-stage and region-based / two-stage approaches.
One-stage detectors: a compact real-time pipeline
The original YOLO paper reframed object detection as a single end-to-end prediction problem. Instead of running a separate proposal-and-classification pipeline, one network predicts object locations and class probabilities from the full image. That design made YOLO influential for real-time perception.
For engineering systems such as traffic monitoring, the attraction is clear:
- a relatively compact inference pipeline;
- good fit for video and edge-oriented applications;
- easier integration with a control loop that needs frequent updates;
- a mature ecosystem for training on custom datasets.
This is why the YOLO family became a natural choice in my vehicle datasets and traffic-perception experiments.
R-CNN-style methods: region reasoning still matters
The R-CNN line takes a different path. Faster R-CNN introduced a Region Proposal Network (RPN) that shares convolutional features with the detector, making region proposals part of the learned pipeline. Mask R-CNN then extended this idea with an additional branch for instance masks.
That family remains conceptually important because it makes the region-level structure explicit. It is a useful comparison point when:
- localization quality is central;
- region proposals are useful to the task;
- instance segmentation is required;
- throughput is less important than richer per-instance analysis.
So the right portfolio statement is not “I know four YOLO versions.” It is closer to: I work on object detection and visual perception, understand one-stage and region-based detector families, and choose the architecture around the system requirement.
The hidden variable: dataset quality
Architecture discussions can distract from the most important practical variable: the data.
In our Iranian Vehicle Images Dataset study, we collected 3,000 images and manually created 5,765 bounding boxes for car, bus and truck classes. Training on that domain-specific dataset produced 91.7% precision and 92.6% mAP@0.5 in the reported experiment. The important lesson was not simply that a particular YOLO release worked; it was that a detector trained on data closer to the deployment domain could outperform a generic baseline by a meaningful margin.
Our larger seven-class vehicle work pushed the same idea further. It separated ambulances and fire trucks from generic vehicle classes because those labels can matter to an intelligent traffic controller. If the final system needs to prioritize an ambulance, a detector that only says “truck” or “van” has lost information before the control problem even starts.
How I choose an object-detection approach
I use a system-oriented checklist:
| Question | Why it matters |
|---|---|
| Is inference real-time? | Influences model family, input size and deployment hardware |
| Is bounding-box detection enough? | If not, instance segmentation may be more appropriate |
| Are small or crowded objects critical? | Changes data collection, resolution and evaluation priorities |
| Is the deployment domain different from public benchmarks? | Domain-specific data may be essential |
| Is the output feeding a controller? | False negatives and class definitions may have asymmetric costs |
| Can the dataset be expanded or relabeled? | Data work may outperform architecture swapping |
Metrics need context
Precision, recall and mAP are useful, but the “best” detector depends on the application. Missing an emergency vehicle may be more costly than a small change in average mAP. A medical prototype may need a completely different validation strategy from a traffic camera. A real-time controller also cares about latency and stability, not only image-level accuracy.
That is why I prefer to describe my computer-vision work through problem definition → dataset → model family → evaluation → system integration.
References and related work
- Redmon et al., You Only Look Once: Unified, Real-Time Object Detection, CVPR 2016.
- Ren et al., Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks, NeurIPS 2015.
- He et al., Mask R-CNN, ICCV 2017.
- Maleki et al., Iranian Vehicle Images Dataset for Object Detection Algorithm, JAIDM 2024.
- Maleki et al., Object Detection for Vehicles with YOLO, IEEE SAMI 2024.
The version number will change. The engineering questions remain.
