A strong computer-vision demo can be produced with a model, a video, and a quiet afternoon. A reliable physical system begins when the camera leaves the desk.
The model matters. But the camera, light, lens, shutter, geometry, timing, mounting, compute, and output often matter just as much.
The camera changes the problem
Resolution does not automatically create usable detail. Lens choice, focus distance, exposure, motion blur, sensor noise, rolling versus global shutter, compression, and field of view determine whether the signal reaches the model in a stable form.
A slightly less sophisticated model with the right image can outperform a better model fed inconsistent optics.
The environment is part of the dataset
Lighting changes across hours and seasons. Reflective surfaces create false edges. Background movement becomes noise. Dust and insects look alike at some scales. A mounting point vibrates. A window adds glare. The prototype must be evaluated in the actual environment or a credible reconstruction of it.
Geometry creates truth constraints
When distance, size, or location matters, a two-dimensional detection is not enough. Stereo depth, known scale, calibrated camera position, structured light, or another ranging method can provide a plausibility gate.
A classification answers “what might this be?” Geometry helps answer “could it actually be there?”
Latency is a systems property
Frame capture, transfer, preprocessing, inference, tracking, decision logic, communication, and physical output each consume time. Optimizing only model inference may have little effect if the camera buffers frames or the display pipeline adds delay.
Output needs a safety model
A system that merely reports a candidate has a different risk profile from one that moves hardware, projects light, opens a gate, or changes a process. Physical output requires explicit bounds, confidence thresholds, interlocks, failure states, and a human override.
Prototype the entire loop
The useful prototype includes the sensor, compute, calibration, decision, output, diagnostics, and failure handling. It should expose uncertainty and produce evidence that a production decision can be based on.
That is why computer vision is best treated as systems engineering rather than a model-selection exercise.