“Algorithms and applications” is usually read as two separate lists: a catalogue of methods on one side, a gallery of use cases on the other. The useful reading is a single mapping, and the thing that decides which pairings are legitimate is not accuracy — it is the data assumption the algorithm carries.
The naive route picks the algorithm first, usually whatever is currently fashionable, then hunts for an application that tolerates it. The route that survives contact with a deployment site runs the other way: name the problem class (classification, detection, segmentation, tracking, registration, reconstruction, anomaly flagging), state the data assumption that class implies, fix an inference budget — and watch the algorithm family collapse into a short list rather than a free choice.
Which pairings are illegitimate, and why?
An algorithm that assumes rigid geometry, stable illumination, or labelled examples will fail silently on an application that cannot supply them. That is the divergence point, and no amount of tuning recovers it. A registration method built on rigid-body assumptions does not become deformation-tolerant with a better learning rate; a supervised detector does not become viable on a defect class that appears twice a year in production.
Two practical consequences we see regularly. First, teams that fix the problem class and the inference budget before selecting a method typically evaluate two or three candidates instead of eight or ten (observed across TechnoLynx computer vision engagements; not a benchmarked rate). Second, the most expensive rework class is discovering after annotation spend that the chosen method assumed a data property the site never had.
The mapping, in one table
| Problem class | Algorithm families | Data assumption it carries | Fails silently when |
|---|---|---|---|
| Classification | CNN / vision-transformer backbones | Labelled examples covering the real class balance | Rare classes are under-represented in training data |
| Detection | Single-stage and two-stage detectors | Boxable, visually distinct objects at consistent scale | Targets are texture-level or scale varies widely |
| Segmentation | Encoder–decoder networks | Dense pixel-level labels, consistent imaging conditions | Illumination or sensor changes between sites |
| Tracking | Detection-plus-association, correlation filters | Temporal continuity, bounded frame-to-frame motion | Frame rate drops or occlusion is long |
| Registration | Classical geometric alignment (feature matching, ICP-style) | Rigid or near-rigid geometry, overlapping views | Objects deform or overlap is minimal |
| Reconstruction | Multi-view geometry, structured light, depth fusion | Known or recoverable camera geometry, static scene | Scene moves during capture |
| Anomaly flagging | Reconstruction error, density models, one-class methods | A large, clean “normal” set; anomalies undefined in advance | “Normal” drifts with process changes |
Read it in both directions. Given an application, it names your candidate families. Given a paper title or a vendor datasheet, it tells you which assumption the claim depends on — so you can ask whether your site satisfies it before anyone quotes an accuracy figure.
Where the inference budget cuts first
Budget narrows the list before accuracy ever enters the conversation. An edge target — Jetson-class hardware, a few watts, a fixed cycle time — rules out heavy transformer backbones regardless of benchmark position, and pushes toward compact convolutional models exported through ONNX and compiled with TensorRT. A server GPU widens the list but introduces its own constraint: network transit and batching latency, which a per-part inspection cycle may not tolerate.
Classical methods deserve their place here rather than as a footnote. When geometry is known and controlled — fixture-mounted parts, calibrated cameras, engineered lighting — OpenCV-grade geometric and signal-processing pipelines still beat learned models on latency, determinism, and the ability to explain a reject to a quality engineer. Learned models earn their keep where appearance variation is genuinely open-ended.
Our broader treatment of scoping, build-versus-buy and deployment constraints sits on the computer vision engineering practice page, which is where this mapping feeds into an actual project plan.
The short list worth memorising
A new engineer does not need the full literature. Hold seven problem classes and roughly the same number of algorithm families, plus one habit: for every method, say out loud what it assumes about the data, then check whether the deployment site provides it.
The open question is how long the mapping stays stable. Foundation-model backbones are quietly loosening the labelled-examples assumption for some classification and segmentation work — but they have not touched the geometric assumptions at all, and that asymmetry is where the next round of mismatches will show up.
