Computer vision is the field that teaches machines to extract meaning from images and video. The phrase “see like a human” gets repeated a lot, but it is misleading — vision systems do not see, they sample numbers off a sensor and run those numbers through layered transformations until something useful comes out the other side. This walkthrough takes the term apart stage by stage so the black box stops being one, and so the engineering effort lands where it actually matters. For the broader practitioner framing — what to learn first, what to defer, and how the field is structured for somebody arriving from an adjacent discipline — see our Fundamentals of Computer Vision: A Practitioner’s Beginner’s Guide. This article is the mechanism view: how the pipeline actually moves data from a sensor to a decision. Step 1: Capturing the pixels Everything starts at the sensor. A camera converts light into a grid of numbers — typically three values per pixel for red, green, and blue. A 1080p frame is roughly two million pixels, six million numbers per frame, and at 30 fps that is 180 million numbers per second from a single camera. Multiply by the number of cameras and you have the raw data budget the rest of the pipeline must respect. Sensor choice matters more than most teams expect: Resolution and frame rate decide what is even visible. A defect smaller than five pixels is invisible to the model regardless of architecture. Lens and field of view decide what fits in a frame and how distorted the edges are. Lighting and dynamic range decide whether the system works at dawn, noon, and dusk or only one of them. Shutter type (rolling vs global) decides whether fast motion blurs or freezes cleanly. The cheapest improvement most pipelines can make is to upgrade the optics before touching the model. We see this pattern regularly: a team has spent three months tuning a detector when a different lens and an extra LED panel would have closed the gap in a week. Step 2: Pre-processing the image Raw pixels are rarely sent straight into a neural network. Common pre-processing steps include: Resize and crop to the model’s expected input size. Normalise pixel values to a known range (often −1 to 1 or 0 to 1). Colour conversion between RGB, BGR, and grayscale depending on the framework and task. OpenCV defaults to BGR; PyTorch and most published checkpoints assume RGB. The mismatch silently halves accuracy. Denoise and white-balance when conditions are challenging. Augmentation during training — random flips, rotations, brightness shifts — so the model generalises beyond the exact frames it was shown. Skipping pre-processing rarely breaks a system loudly. It quietly costs a few percentage points of accuracy that nobody can later trace. Step 3: Feature extraction with neural networks This is where the AI part lives. The pre-processed image goes into a neural network — usually a convolutional neural network (CNN) like ResNet or EfficientNet, or a vision transformer (ViT) such as DINOv2 or SAM-2’s image encoder. The network applies a stack of learned operations that progressively transform pixels into more abstract representations: Early layers detect edges, corners, and colour blobs. Middle layers combine those into textures and parts of objects. Later layers assemble parts into full objects and scenes. The output is a dense numerical vector — the feature representation — that captures what is in the image in a form a downstream task can use. We covered the layer-by-layer mechanics in Feature Extraction and Image Processing for Computer Vision. Step 4: Making a decision The feature representation is then passed to a task-specific head. The choice of head — not the backbone — defines what the system actually produces. Head type Output Typical use Classification Probability over fixed classes Defect type, content moderation label Detection Bounding box + class per object Counting, ADAS, retail analytics Segmentation Class label per pixel Medical imaging, autonomous driving Embedding Vector for similarity search Face matching, retrieval, dedup Captioning / VQA Natural-language text Accessibility, agentic vision tools The same backbone network can serve multiple heads, which is why teams often share one trained encoder across many tasks. This is also why a well-chosen backbone is a long-lived asset and a poorly chosen one is a recurring tax. Step 5: Tracking and aggregation (video only) A single image is one decision. A 30-fps video stream is 30 per second per camera, and the same object appears in many consecutive frames. Without tracking, the same car gets counted thirty times. A tracker — SORT, DeepSORT, ByteTrack — links detections across frames using motion prediction and appearance similarity, so the system can answer the questions a business actually has: how many unique objects, how long did each stay, what path did it take. The tracker is also where most production-only failure modes live. Detection benchmarks rarely measure identity-switch rate, but in a retail or security deployment that metric matters more than mean average precision. Step 6: Acting on the result Detections without action are an academic exercise. The final stage of any production pipeline pushes results into something useful: A dashboard for an operator. An alert into Slack, PagerDuty, or a control system. A row written to a database for analytics. A control signal to a robot, gate, or camera PTZ mount. The integration work is unglamorous but it is what separates a demo from a deployment. How does computer vision use training data? None of the steps above work without data. A vision model learns from labelled examples — images with their correct answers attached. Building this dataset is usually the longest single line item on a project plan. Common patterns: Public datasets (ImageNet, COCO, OpenImages) for generic capabilities and pre-training. Domain datasets collected on-site, often by the team that will eventually use the system. Synthetic data generated by simulators or generative models when real samples are rare or expensive. Active learning loops that prioritise labelling the frames the current model is least sure about. The hidden cost of data is consistency. Two annotators marking the same defect differently teaches the model that the boundary is fuzzy, and accuracy tops out below what the architecture could achieve. In our experience, label-quality audits return more accuracy per engineering hour than model-architecture changes once a project is past its first iteration. Where the hardware bites Vision is compute-heavy. The hardware decision usually comes down to where the inference happens: Cloud GPUs for training and high-throughput batch jobs. Edge accelerators (NVIDIA Jetson, Google Coral, Hailo, Intel Movidius) for low-latency on-site inference. CPUs for low-frame-rate jobs or where deployment simplicity dominates. Most production stacks use both — train in the cloud, deploy on the edge, typically through an ONNX export and a TensorRT or OpenVINO runtime with INT8 quantisation. The deeper trade-offs sit on the GPU page. What can go wrong A working vision pipeline is a chain of dependent components. The common failure modes: Distribution shift. The model was trained on summer photos and now it is winter. Edge cases without coverage. A class that occurs once per thousand frames is statistically invisible during training but operationally critical. Drift in the camera. A loose mount or a smudged lens degrades input quality silently. Latency creep. A model that ran at 30 fps last quarter now runs at 18 because a side process is starving the GPU. Production vision systems need the same monitoring discipline as any other service — input statistics, latency percentiles, and a sampled stream of inputs that humans actually look at. FAQ How does computer vision actually work? Computer vision turns pixels into structured information about the world. A modern pipeline: (1) image capture via a sensor and ISP; (2) preprocessing (resize, normalise, augment); (3) a deep backbone (CNN like ResNet or EfficientNet, or a vision transformer like ViT, DINOv2, SAM-2) produces a feature representation; (4) task-specific heads produce the actual output — class labels for classification, bounding boxes for detection, masks for segmentation, keypoints for pose, or text for captioning. What is the difference between classical computer vision and modern deep-learning computer vision? Classical CV uses hand-engineered features (edges, corners, gradients, SIFT, HOG) and explicit algorithms (Hough transform, RANSAC, classical SLAM). Modern CV uses deep networks that learn the features and the decision logic from data. Classical CV still wins for low-power, training-data-poor, or interpretability-critical applications; deep CV dominates everything where labelled data and compute are available. Most production stacks combine both — classical for calibration and geometry, deep for perception. Where is computer vision used in 2026? Six categories with the largest revenue: industrial quality inspection, retail loss-prevention and analytics, medical imaging (radiology, pathology, ophthalmology), autonomous driving and ADAS, security and surveillance, content moderation at platform scale. Plus a long tail: agriculture, sports analytics, wildlife monitoring, AR / VR perception, robotics, scientific imaging. The footprint runs from cloud GPUs through edge servers down to single-board NPUs on cameras. What skills do you need to work in computer vision? Solid linear algebra and probability; fluent PyTorch (increasingly JAX); familiarity with modern backbones and how to fine-tune them; understanding of dataset construction, labelling, and evaluation metrics; at least passing knowledge of the classical methods that show up when the deep stack fails; and MLOps and on-device deployment skills (ONNX, TensorRT, quantisation) for production roles. The talent pool is deeper than it was in 2020 but still tight. How TechnoLynx approaches it We design vision pipelines end-to-end: sensor selection, data strategy, model architecture, edge deployment, and the integration work that connects results to the rest of your business. If you have a problem you think computer vision could solve and want a sober second opinion before committing budget, contact us — we will tell you whether the approach fits before we sell you the work.
