Most introductions to computer vision start with pixels, convolutions and a nod to ImageNet. That teaches you what the field is called. It does not tell you what entering it costs, which is the question most people actually arrived with.
A more useful introduction is a scoping exercise. Before any model is chosen, the work is deciding which problem class you are in, what your input stream really looks like, and what inference budget you have to live inside. Get those three right and a first shippable component is a matter of weeks; get them wrong and you rebuild the pipeline after the architecture turns out not to fit.
Which problem classes count as computer vision?
Computer vision is not one problem. It is a small family of them, each with different labelling costs and different failure behaviour:
| Problem class | Question it answers | Main early cost |
|---|---|---|
| Classification | What is in this image? | Class balance and label noise |
| Detection | Where are the objects, and how many? | Bounding-box annotation volume |
| Segmentation | Which pixels belong to what? | Per-pixel labelling effort |
| Tracking | Is this the same object across frames? | Temporal consistency, ID switches |
| Measurement | How big, how far, how fast? | Camera calibration, not the model |
| OCR / text extraction | What does this say? | Fonts, skew, resolution floor |
Some problems wear a camera without being vision problems. Reading a gauge to trigger a threshold alert is usually a measurement-and-calibration problem where the vision component is trivial. Counting throughput on a fixed conveyor is often solved better by fixing the lighting than by training a detector. The most expensive early error in computer vision is spending months on model selection for a problem that was actually a data-acquisition or calibration problem. We see this pattern regularly in first engagements, and it is nearly always visible in week one if someone asks the right question.
The first three decisions
Before any architecture discussion:
- Problem class. Pick from the table above. If two fit, the pipeline probably needs two stages, not one clever model.
- Input stream reality. Resolution, frame rate, lighting variance, camera placement, and whether frames are independent or a sequence. This determines your data budget more than your model does.
- Inference budget. Latency ceiling, hardware target, and how many streams share it. An architecture that cannot fit the budget is not a candidate, however good its accuracy numbers look.
On the tooling side, the minimum practical background is narrower than survey articles imply: Python, PyTorch or ONNX Runtime for inference, and OpenCV for the image handling and calibration work that sits either side of the model. Linear algebra intuition helps. Deriving backpropagation by hand can be deferred indefinitely.
Where introductory material misleads is in benchmark framing. Public dataset accuracy is measured on curated, well-lit, correctly-framed images; production streams are none of those things, and a model that drops several points when the camera moves has not failed, it has been measured honestly for the first time. Our fuller treatment of how these choices compound is in the computer vision engineering practice overview, which walks the decision path from problem class through deployment.
The open question for anyone starting this month is not which model to learn — it is whether the problem in front of you actually needs one.
