The most useful computer vision system I've seen this year is installed above a conveyor belt in a small bakery in Lyon.
It does one thing: it watches loaves of sourdough come off the oven and flags the ones where the crust is under-bloomed. A human used to do this. She was excellent at it. But her job also involved four other tasks, and by the end of a shift, tired eyes miss things.
Now the camera flags the under-bloomed loaves, she double-checks, and the bakery has reduced wastage by about 6%. That's it. That's the whole story.
It's also, unglamorously, one of the most profitable computer vision deployments per euro spent that I know of.
What the demos don't show
Every computer vision demo I've seen at a conference involves a city street, lots of bounding boxes, and a thrilling voiceover about self-driving cars. Every successful computer vision deployment I've seen in the field looks like the bakery.
The gap matters, because it shapes how you scope a project.
Computer vision is especially good at:
- Detecting repeated anomalies in a controlled environment. Same lighting, same angle, same subject, millions of examples. The bakery belt. A production line. An orchard row.
- Counting things humans get bored counting. Cells in a microscope slide. Salmon in a net pen. Items on a supermarket shelf.
- Watching for things humans can't see fast enough. Drowsy drivers. Early-stage skin lesions. Tiny cracks in concrete.
It is notoriously bad at:
- Anything that requires common sense about the world outside the frame.
- Conditions that vary wildly (weather, lighting, angle, framing).
- Any situation where the cost of being wrong is very high and rare.
When a computer vision project struggles, it's almost always because it crossed from the first column into the second. The self-driving car problem is hard not because cars are hard, but because the world is hard.
What we tell clients considering computer vision
A few things we say in the first meeting:
- Start narrow. Expand later. Don't build "quality inspection for the line." Build "defect detection for failure mode X on station 4." Ship that. Then grow.
- The camera and the lighting matter more than the model. We've fixed more bad computer vision pilots with a better camera and a $200 light panel than with a better neural network.
- Account for drift. The lighting will change seasonally. A new supplier's material will look different. Your model will quietly get worse unless someone's paying attention. Build for that.
- Bring the operator in early. The person whose work the system is augmenting should be involved in the design from day one. Their feedback is how you avoid shipping something that's correct but useless.
Where it's changing lives
The deployments that move me aren't the flashy ones:
- A rural clinic using a smartphone-based retinal scanner to catch early diabetic retinopathy in patients who'd otherwise go blind.
- A recycling facility using computer vision to sort plastics more accurately, diverting tonnes of material from landfill per week.
- A conservation charity counting wildlife from camera-trap footage, turning six months of graduate-student work into something that happens overnight.
None of these made a splash. All of them matter.
If you're starting out
Pick a narrow, visible problem. Budget more for cameras, lighting, and the operator's time than you think. Ship a small thing fast, and let the people closest to the work tell you what's useful next.
If you're wrestling with one of these — we'd love to help you think it through. Book a free chat. No demo slides, promise.
