Most computer-vision conversations start with a camera and a hope. It is more useful to start with the task. Detect, count and check are three useful starting points for many operational vision problems, although they do not cover every type of computer-vision work. They also differ in what makes them difficult.
This is a technical example of how we think about the problem. It is not a case study: nothing here describes a deployment, a client or a measured result.
Three useful starting points
Detect: is the item or event present? A binary question about a frame: is there a person in the exclusion zone, is the pallet on the stand, is the label there at all. How difficult this is depends on the object’s size, the image conditions and the reliability the operation requires.
Count: how many objects passed or remain? Counting may require reliable tracking between frames or a controlled moment where the answer is unambiguous. A common failure is double-counting the same object.
Check: is something missing, damaged or out of place? Checking can be the hardest of the three because it requires a reference for what correct looks like, while useful examples of failure may be rare. A task that encounters a defect once a month provides very little evidence to validate against.
If a request does not fit these three starting points, that does not make it unsuitable for computer vision. It means the task needs to be defined more precisely before anyone chooses an approach.
Before the camera question
The common assumption is that the cameras already installed will do. Existing cameras may be sufficient after checking their placement, resolution, lighting and access. These are four useful early checks, not a complete feasibility assessment. Frame rate, motion blur, camera stability and representative examples may also matter.
Placement. A camera positioned for a human watching a monitor is aimed for context, not for measurement. The angle that lets a supervisor see the whole bay is frequently the angle where objects occlude each other. Ask what the camera has to see, not what it currently shows.
Resolution. What matters is not the sensor’s specification but the pixels landing on the thing being judged. A high-resolution camera covering a wide area may give you fewer usable pixels on a small label than a modest camera aimed at it directly. Check the recorded stream, too; recording is often compressed well below the live feed.
Lighting. Consistency matters more than brightness. Changing daylight, shadows that move through the day, reflective surfaces and mixed artificial light all change what the image looks like from hour to hour. A model validated only on afternoon footage may fail at night because those conditions were not represented adequately. Lighting is one possible cause, alongside the data, preprocessing and model itself.
Access. Can the footage actually be retrieved, and how? Some systems keep everything inside a closed recorder with no practical export. Some retain footage for a week. This check can end the conversation early and is often one of the least expensive to run, which is why it should not be left until last.
What we would want to see first
Recorded footage covering the ordinary case and the awkward one, across the range of conditions the task has to work in. Not a staged clip: the value is in the mess.
If that footage does not exist, obtaining it is the first piece of work, and it is worth doing on its own before anyone commits to building a system on top of it.