Computer Vision Applications: Five Myths I'm Tired of Hearing

Imagine you're at a traffic light, and a car with a camera on its roof rolls up beside you. It's not a government surveillance van — it's a self-driving development vehicle. You wave at the engineer behind the wheel, and the car waves back. That's computer vision in action. But here's the thing: that car isn't 'seeing' the world the way you do. It's processing a stream of numbers, and a lot of what we think about computer vision applications is, frankly, wrong.

I've spent years editing papers and articles in this field, and I've noticed the same misconceptions popping up again and again. So let me bust a few myths, based on the actual research and benchmarks, and tell you what I'd really do if I were starting a vision project today.

Myth 1: Self-driving cars are basically solved if you just use enough data

Every time a Tesla or Waymo video goes viral, someone comments, 'Just give it more training data and it'll be perfect.' If only it were that simple. The KITTI benchmark, captured around Karlsruhe, Germany, shows up to 15 cars and 30 pedestrians in a single image (KITTI Vision Benchmark Suite). That's a chaotic scene, and it's just one city. The nuScenes dataset goes further: it includes 6 cameras, 5 radars, and 1 lidar, all 360-degree, across 1000 scenes of 20 seconds each (nuScenes dataset paper). That's a lot of data — 7x more annotations and 100x more images than KITTI (nuScenes dataset paper). But even with that, perception is only one piece. You need to handle weather, road construction, and the fact that a cardboard box on the highway could be a hazard or just trash.

Data helps, but it doesn't solve the fundamental problem of understanding context. I've seen teams obsess over collecting more footage when their model already fails on a basic edge case. The real bottleneck is often sensor fusion and decision-making, not just the camera feed.

Myth 2: Medical AI can replace doctors

When the FDA authorized IDx-DR in April 2018 as the first autonomous AI diagnostic system in any field of medicine, it was a huge deal (IDx-DR pivotal trial). It screens for diabetic retinopathy without a clinician interpreting the image or results, based on a pivotal trial of 900 patients at 10 primary care sites (IDx-DR pivotal trial). That's impressive. But here's the catch: that system is for a specific condition, and it's a screening tool, not a diagnosis of everything.

A 2022 study found 45 AI/ML-based computer-aided detection devices approved by the US FDA and 12 by Japan's PMDA (FDA AI/ML device study). But many of these are 'computer-aided simple triage' — they flag suspicious areas for a human to review, not make final decisions (FDA AI/ML device study). Even the famous diabetic retinopathy algorithm from JAMA 2016, which achieved an AUC of 0.991 on EyePACS-1 (JAMA 2016 deep learning diabetic retinopathy study), was validated on a specific dataset and still had a sensitivity/specificity trade-off: 90.3% sensitivity and 98.1% specificity at one operating point (JAMA 2016 deep learning diabetic retinopathy study).

So no, medical AI isn't replacing doctors — it's augmenting them. If you're a developer, don't aim to build a 'doctor in a box.' Aim to build a tool that helps a clinician be faster and more accurate.

Myth 3: Object detection is all about the best accuracy on COCO

People love to quote mAP numbers on COCO as if they're the be-all and end-all. But the COCO dataset is 328,000 images with 2.5 million labeled instances across 91 object types (Microsoft COCO paper). That's a lot, but it's not the real world. And the top-performing models like EfficientDet-D7 hit 55.1 AP on COCO test-dev (EfficientDet paper), but that comes at 77M parameters and 410B FLOPs (EfficientDet paper). Do you need that on a drone or a mobile phone?

I remember a startup trying to use a heavy detector for real-time video on a Raspberry Pi. They were stuck at 2 fps. Then they switched to MobileNetV2 (which uses depthwise separable convolutions for efficient inference) and got 30 fps, with a slight accuracy drop. For their use case — counting people in a store — that trade-off was worth it. The lesson: accuracy on a benchmark is not the same as performance in your application. Consider your deployment constraints first.

Myth 4: Face recognition is flawless and unbiased

After seeing face recognition unlock phones and tag friends, some assume it's perfect. But NIST's Face Recognition Vendor Test (FRVT) has been measuring accuracy for years, and it's not uniformly great. The FRVT 1:N 2018 evaluation searches galleries of at least 10 million identities (NIST Face Recognition Vendor Test). And a NIST report on demographic effects quantified differentials for nearly 200 algorithms using over 18 million images of more than 8 million people (NIST Face Recognition Vendor Test). That means some algorithms are more accurate on certain demographics than others — a serious concern.

So if you're building a face recognition system, don't just pick the model with the highest Rank-1 accuracy. Test it on diverse data, and be aware of demographic biases. Also, don't forget about masks — NIST published a report on face mask accuracy, adding 65 new algorithms submitted since mid-March 2020 (NIST Face Recognition Vendor Test).

Myth 5: Deep learning is the only way to do computer vision

With all the hype around CNNs and transformers, you'd think classic methods were dead. But they're not. The Computer Vision courses at NTNU still teach image processing, feature extraction, and machine learning basics (Computer Vision courses). And for many problems, a well-tuned SIFT or HOG feature plus a simple classifier is more robust and explainable than a deep net, especially when you have limited data.

I've seen a manufacturing inspection task where a deep learning model failed because of domain shift — the lighting changed slightly. A classic feature-based approach with a few hand-crafted rules handled it perfectly. Deep learning is powerful, but it's not a silver bullet. Know your problem and your constraints.

Quick tip: Before you jump to a deep model, try a simple baseline like a linear classifier on HOG features. It'll give you a floor and help you debug.

What I'd actually do

If I were starting a computer vision project today, I'd start with the problem, not the model. I'd ask: What's the task? What's my data? What's my deployment environment? Then I'd choose the simplest solution that works. For object detection on edge devices, I'd look at MobileNetV2 or YOLO (which can run at 45 fps on a GPU, and Fast YOLO at 155 fps (YOLO paper)). For segmentation, U-Net is a solid choice, especially with limited data — it won the ISBI cell tracking challenge 2015 and can segment a 512x512 image in under a second on a recent GPU (U-Net paper).

And I'd always validate on real-world data, not just benchmark datasets. Because in the end, computer vision is about making systems work in the messy, unpredictable world, not just on a leaderboard.

Sources

• KITTI Vision Benchmark Suite - https://www.cvlibs.net/datasets/kitti/
• nuScenes dataset paper - https://arxiv.org/abs/1903.11027
• IDx-DR pivotal trial (npj Digital Medicine) - https://pubmed.ncbi.nlm.nih.gov/31304320/
• FDA AI/ML device study (Scientific Reports) - https://www.nature.com/articles/s41598-022-21426-7
• JAMA 2016 deep learning diabetic retinopathy study - https://pubmed.ncbi.nlm.nih.gov/27898976/
• Microsoft COCO paper - https://arxiv.org/abs/1405.0312
• EfficientDet paper - https://arxiv.org/abs/1911.09070
• MobileNetV2 paper - https://arxiv.org/abs/1801.04381
• NIST Face Recognition Vendor Test - https://www.nist.gov/programs-projects/face-recognition-vendor-test-frvt
• Computer Vision courses (Southampton / NTNU) - https://www.ntnu.edu/studies/courses/TDT4265
• YOLO paper - https://arxiv.org/abs/1506.02640
• U-Net paper - https://arxiv.org/abs/1505.04597