Computer Vision: Architecture, Trade-offs, and What Production Actually Requires

"Computer vision" isn't one capability — it's a family of distinct tasks that happen to share an input format. Classification answers "what's in this image." Object detection answers "where is it." Segmentation answers "which exact pixels belong to it." OCR answers "what text does it contain." Treating these as interchangeable is where a lot of vision projects go wrong before they even start.

The core vision pipeline

A raw image is just a grid of pixel values — nothing a model can reason about directly. Preprocessing resizes and normalizes it into a consistent format. A backbone — historically a convolutional neural network (CNN), increasingly a vision transformer (ViT) — extracts a hierarchy of features: edges and textures in early layers, shapes and object parts in deeper ones. A task head sits on top of those features and produces whatever the task needs. The same backbone can often feed multiple heads — one model, several outputs.

Diagram to source: a 5-stage left-to-right pipeline (Image → Preprocess → Backbone → Task head → Output). A live reference version of this diagram was rendered during planning — use it as the design spec for a commissioned or licensed final asset, then host it through your own media library.

The four core tasks, compared

Scroll to see more →

What's in this image — classification, the coarsest and fastest signal.

Where it is — detection, a box and a label per object instance.

The exact pixel boundary — segmentation, when a bounding box isn't precise enough.

What text it contains — OCR, turning an image of text into structured, searchable data.

CNNs vs. vision transformers

A convolution kernel looks at a small local window of the image and slides across it — it builds understanding of the whole image gradually, layer by layer, from local patterns upward. A vision transformer instead splits the image into patches and lets every patch attend to every other patch directly, from the first layer — global context immediately, at the cost of needing far more training data to learn what a convolution gets for free as a built-in assumption.

Diagram to source: side-by-side or stacked comparison — a small sliding kernel window over a few grid cells (CNN), and one patch fanning attention lines out to every other patch (ViT). A live reference version was rendered during planning; use it as the design spec.

Scroll to see more →

What enterprise-grade computer vision actually requires

Data privacy by design — sensitive imagery (medical, biometric, surveillance) often needs on-device or private-cloud inference, not a third-party API call per frame.

Real-time latency for video — streaming and live camera feeds need per-frame inference budgets, not batch-job latency.

Versioned model rollouts — so a regression in accuracy on a specific camera or site can be traced to exactly which model version was live.

Bias and fairness evaluation — accuracy tested across demographics, lighting conditions, and camera hardware, not just an aggregate benchmark score.

Where Automex fits in

Automex handles the full vision pipeline — ingestion, preprocessing, inference, and post-processing — as one managed system, with the production requirements above built in rather than added after an incident. Classification, detection, segmentation, and OCR share the same infrastructure, monitoring, and confidence-threshold tooling.

One pipeline, every task — classification, detection, segmentation, and OCR without separate integrations for each.

Deployment flexibility — on-device, private cloud, or managed inference depending on data sensitivity.

Built for streaming — latency budgets designed for live video, not just batch image processing.

Have a vision use case to evaluate? Talk to us about a pilot.