Computer vision works step by step like this: a sensor turns light into a grid of numbers, those numbers are cleaned up, structure such as edges and corners is pulled out, and then hand-designed rules or a trained model turn that structure into a decision, all within the latency and compute budget of the hardware it runs on. Unlike human vision, the machine does not “see”. It computes. That same chain is a good skeleton for a computer vision course. On a Raspberry Pi it also decides what a lab can show live: a grayscale, Sobel and threshold pipeline has run even on the original 700 MHz board.
The six stages from camera frame to decision
This page follows computer vision through six stages, from acquisition through classical and learned methods to deployment, and deploying it often combines classical methods with newer algorithms.
TechnoLynx builds pipelines like this on the target hardware through its Computer Vision R&D work, and for a teaching or demo build the first step is framing the problem: who the learners are, and what the final demo has to prove on which hardware.
OpenCV, an open-source library with several hundred computer vision algorithms, is split into modules, including ones for video capture, image processing, 2D features, object detection and deep networks. Our fundamentals of computer vision guide explains how to assemble these parts, not just list them.
| Stage | What happens to the numbers | Where it shows up in practice |
|---|---|---|
| Acquisition | Camera frames become arrays in memory | OpenCV’s videoio module gives an interface to video capture and codecs |
| Preprocessing | Colour conversion, filtering, resizing, warping | OpenCV’s imgproc module covers linear and non-linear filtering, geometric transforms, colour space conversion and histograms |
| Feature extraction | Edges, corners and descriptors summarise structure | OpenCV’s features2d module provides feature detectors, descriptors and matchers |
| Classical methods | Geometry, thresholds, filters and trackers turn features into estimates | Duckietown maps detected line segments to the ground plane with a homography and estimates lane position with a histogram filter |
| Learned methods | A trained network classifies, detects or segments | OpenCV ships an objdetect module for predefined classes and a dnn module for deep networks |
| Deployment constraints | Latency, frame rate, power and heat bound everything above | Duckietown’s student projects come with specifications such as a 50 ms maximum allowable latency |
Canny edge detection as a worked example of the classical stages
Canny edge detection is the most useful single example for teaching, because one algorithm walks through preprocessing, feature extraction and a decision rule in sequence. The OpenCV tutorial describes Canny as a multi-stage algorithm:
- Noise reduction with a 5x5 Gaussian filter, since edge detection is sensitive to noise.
- Gradient computation with a Sobel kernel in the horizontal and vertical directions, giving the first derivatives Gx and Gy.
- Non-maximum suppression, which keeps a pixel only if it is a local maximum along the gradient direction.
- Hysteresis thresholding with two values, minVal and maxVal: gradients above maxVal are sure edges, those below minVal are discarded, and those in between survive only if they connect to a sure edge.
OpenCV wraps all four in cv.Canny(), which takes the image, minVal, maxVal, an aperture size for the Sobel kernel (3 by default) and an L2gradient flag that selects the more accurate magnitude formula (False by default).
What is the difference between classical computer vision and modern deep-learning computer vision?
Classical computer vision uses operations a person designs (filters, gradients, thresholds, projective geometry), while deep-learning computer vision learns its features and its decision rule from labelled examples. O’Mahony et al. (2019) argue that classical techniques have not become obsolete and review hybrid methods that improve performance and handle problems poorly suited to deep learning, citing panoramic and 3D vision as domains where combinations have been popular. Harvard’s Division of Continuing Education frames its course the same way: deploying computer vision applications often requires combining classical methods with newer algorithms, so the course teaches the classical techniques found in practical pipelines first.
The boundary is blurrier inside a running system than on a syllabus. A benchmark of MobileNet SSD detectors on the Raspberry Pi 5 still resized a 3888x2916 test image down to 300x300 before the network saw it, which is plain classical preprocessing in front of a learned model. Duckietown shows the swap at a higher level: sign detection can be “simulated” with AprilTag fiducials or implemented with real object detection, and the platform scales difficulty from line detection and reactive control up to sign recognition.
That is the argument for teaching both, classical first. For the learned half’s workflow, see computer vision workflow from data to deployment. Choosing a specific detector or segmentation family for a demanding job, such as separating missing tablets from good blister cavities or keeping polyp boundaries stable across live endoscopy video, is a separate selection problem with its own criteria and does not belong in an introductory unit.
A semester order that runs from pixels to a robotics demo
Established courses already follow the pipeline order. Stanford’s CS131 syllabus for Fall 2019 runs pixels and filters, filters and convolutions, edge detection, features and fitting, feature descriptors and visual recognition before reaching deep learning and convolutional neural networks in its final lectures, with homework on Instagram-style filters, smart car lane detection and panorama stitching along the way. Georgia Tech’s CS 6476 orders its projects as convolution and hybrid images, then SIFT feature matching with RANSAC, then recognition with deep learning, semantic segmentation, PointNet and neural radiance fields. The ETH Duckietown MOOC puts image processing for lane following in its robot vision module and only then trains a CNN to detect objects and run onboard through ROS.
A course built on that order and ending in a deployed robotics demo would run in these blocks:
- Image formation and acquisition: camera models, calibration, capturing frames into arrays.
- Filters and convolution: pixels, filters and convolutions.
- Edges and features: Canny edge detection, feature descriptors and SIFT matching.
- Classical methods on live video: thresholding, homographies and a lane-following lab.
- Learned methods: train a CNN to detect objects and run it onboard.
- Deployment: integrate perception with control on the robot and measure latency against the project’s stated specification.
Stanford’s current CS131 runs as a 10-week course built around projects. The right depth per block depends on the cohort’s maths and programming background, and squeezing six blocks into too few weeks produces a buzzword tour rather than competence. The balance between classical and learned blocks also needs revisiting every year or two, as learned methods absorb steps that used to be hand-built.
What skills do you need to work in computer vision?
Computer vision work needs four layers of skill: maths, programming, the image-processing and machine-learning core, and systems integration. Stanford’s CS131 schedules recitations on linear algebra and on Python with NumPy alongside its first lectures, which shows where the foundations sit. Georgia Tech’s learning objectives name the core directly: image processing approaches such as convolution and their use in registration, alignment and matching, plus machine learning (including deep learning) for categorisation, segmentation and detection.
The integration layer is the one a pixels-only course leaves out. Duckietown’s stated objectives include designing subsystems that work together and analysing the constraints of limited onboard computation, sensing and actuation to make trade-offs, and its lectures cover robotics architecture with ROS. In our view, that last skill is what separates an engineer who can ship a vision component from one who can only produce a notebook result.
What frame rate can a Raspberry Pi camera kit run for edge detection versus a small detector?
A Raspberry Pi has run a classical grayscale, Sobel and threshold pipeline on the CPU alone, while live Pi 5 CPU observations put MobileNetV2 SSDLite near 15 FPS, YOLO11 Nano near 11 and YOLO11 Small at 4.5. The evidence is uneven. The classical-pipeline measurements cited here come from a 2013 test on the original 700 MHz Pi and a 2017 Duckietown paper on a Pi 2, not from a Pi 4 or Pi 5. Since those older boards already managed usable rates, we would expect a current board to leave headroom, but that is an inference, not a measurement.
Measured frame rates, with board, resolution and source age
| Source | Board | Workload | Result |
|---|---|---|---|
| Messina blog test, 2013 | Original Pi, 700 MHz ARM | Grayscale, Sobel and threshold at 320x240 | 7.5 to 12.2 FPS, against 8 to 17.6 FPS for capture with no filtering |
| Messina blog test, 2013 | Original Pi, 700 MHz ARM | Same pipeline at 640x480 | 5.3 FPS |
| Paull et al., ICRA 2017 | Pi 2, four 900 MHz cores | Full lane-following pipeline at 320x240 | 10 Hz with 110 ms latency |
| Edge benchmark paper, arXiv 2024 | Pi 4 | SSD MobileNet V1, inference only | 209 ms on CPU, 12 ms with Edge TPU |
| Edge benchmark paper, arXiv 2024 | Pi 5 | SSD MobileNet V1, inference only | 93 ms on CPU, 10 ms with Edge TPU |
| Edge benchmark paper, arXiv 2024 | Pi 5 | YOLOv8 Medium on CPU | 1,348 ms |
| Qengineering repository | Pi 4 overclocked to 2000 MHz, 32-bit OS | TFLite SSD MobileNetV1 at 300x300 | 17 FPS with no accelerator |
| raspberry-pi-vision-bench repository | Pi 5 CPU, two inference threads, live camera | MobileNetV2 SSDLite / YOLO11 Nano / YOLO11 Small | About 15 (camera-limited) / 11 / 4.5 FPS, reported as observations |
| LearnOpenCV YOLO11 tutorial | Pi 5 | YOLO11 across export formats | 8 to 10 FPS average; 25+ FPS only at 240x240 with NCNN conversion and quantisation |
| Fast.io project roundup, 2026 (vendor) | Pi 5 | YOLOv8 object detection | 5 to 8 FPS on CPU, 30 FPS or more with a Hailo accelerator |
Working from the paper’s Pi 5 figure, 93 ms per inference is about 1000 / 93 ≈ 10.8 inferences per second, before any capture, preprocessing or drawing is added, since that paper’s timing excludes pre- and post-processing. The arithmetic for the Pi 4 gives 1000 / 209 ≈ 4.8.
The table also contains a real disagreement: the 2024 paper puts SSD MobileNet V1 on a Pi 4 at 209 ms, yet the Qengineering build reports 17 FPS on the same board. We weigh the paper higher for comparing boards, because it repeats each test three times under one procedure, but it measures a request-driven detection service, whereas Qengineering runs tuned C++ on an overclocked board. The gap is a reason for a lab to measure its own build rather than quote either number.
Frame-rate figures also differ in what they count. One repository separates live completed-frame FPS from a 1000 / inference_ms estimate and warns that the second is not live camera FPS, while Alasdair Allan’s Pi 5 benchmarks on Hackster deliberately time end to end, setup included.
Do you need a Coral USB Accelerator for the class to see real-time results?
Allan’s Hackster benchmarks found the Pi 5 running TensorFlow Lite models almost five times faster than the Pi 4, with essentially the same inference speed as the Coral TPU, and concluded that custom accelerator hardware may no longer be needed for some edge inference tasks. On older boards the accelerator matters: the same author measured roughly a threefold speed-up from the Coral on a Pi 4 once USB 3.0 was available.
The Coral brings constraints a short class session has to absorb:
- It runs only models that are quantised (float32 weights converted to int8 or uint8) and compiled with the Edge TPU compiler; a standard TFLite model, even a quantised one, falls back to the CPU.
- Google recommends USB 3.0 for best performance.
- Models above about 10 MB can exceed on-chip memory and spill operations back to the CPU, according to a Pi 5 setup guide.
- To fit YOLOv8 on the TPU, the 2024 benchmark had to reduce input size from 640x640 to 320x320, and the Edge TPU significantly reduced YOLOv8 accuracy while leaving SSD and EfficientDet Lite accuracy intact.
- Installation adds udev rules, so the stick has to be replugged after setup.
- The accelerator cost $74.99 when Hackster priced it alongside the $35 Pi 4.
| Lab goal | Hardware per kit | Our recommendation |
|---|---|---|
| Guaranteed live response for every student | Any Pi, CPU only | Classical pipeline as the core lab |
| Show a learned detector running live | Pi 5, CPU only | SSD-class or YOLO nano model, low resolution, measured on the actual build |
| Show a learned detector live on older boards | Pi 4 | Add a Coral and use quantised, Edge TPU-compiled SSD models |
| Run YOLO-class models | Jetson Orin Nano | the 2024 benchmark found the Jetson Orin Nano the most suitable of its tested devices for YOLOv8 |
Thermal throttling during a long lab session
A Pi 5 throttles under sustained compute load without airflow, so a long lab session needs cooling. On a Pi 4, a small fan driven from the GPIO header held the CPU at 45°C and cut inference time from 90.9 ms to 79.5 ms. Allan’s Pi 5 tests used active cooling for the same reason, and the Pi 5 Coral setup guide recommends the standard libedgetpu1-std runtime over the overclocked libedgetpu1-max for sustained work on lightly cooled boards. A fan per kit is cheap insurance, and lab FPS targets should be checked once the board has warmed up.
The simplest classical pipeline that still impresses students
Grayscale, Gaussian blur, Canny with live threshold sliders, and the edges painted back onto the colour frame is the pipeline we would start with: it is short enough to read in one sitting, it exercises preprocessing, feature extraction and thresholding, and the live overlay reacts the instant a student moves a slider. Working at 320x240 matches the faster of the 2013 test’s two resolutions and the resolution of Duckietown’s lane follower on the Pi 2.
import cv2 as cv
cap = cv.VideoCapture(0)
cv.namedWindow("edges")
cv.createTrackbar("minVal", "edges", 50, 255, lambda v: None)
cv.createTrackbar("maxVal", "edges", 150, 255, lambda v: None)
while True:
ok, frame = cap.read()
if not ok:
break
frame = cv.resize(frame, (320, 240))
gray = cv.cvtColor(frame, cv.COLOR_BGR2GRAY)
blur = cv.GaussianBlur(gray, (5, 5), 0)
lo = cv.getTrackbarPos("minVal", "edges")
hi = cv.getTrackbarPos("maxVal", "edges")
edges = cv.Canny(blur, lo, hi)
overlay = frame.copy()
overlay[edges > 0] = (0, 255, 0)
cv.imshow("edges", overlay)
if cv.waitKey(1) & 0xFF == ord("q"):
break
cap.release()
cv.destroyAllWindows()
Showing the blurred image and raw edge map in side windows turns each pipeline stage into something visible, and adding a frame counter lets students measure the cost of raising the resolution themselves. Duckietown’s paper makes the same point at system level: perception is its most computationally intensive task, and it controls camera resolution per task and runs perception modules only when the current mode needs them.
Where is computer vision used in 2026?
Stanford’s CS131 for Spring 2026 opens with the applications its students meet daily: robots navigating space, search engines indexing billions of images and videos, medical image diagnosis, self-driving cars, and Instagram filters and Snapchat masks. At the Raspberry Pi end of the scale, one 2026 project roundup lists object detection, pose estimation, face recognition and always-on security monitoring with Frigate among the Pi 5’s vision uses. For industrial inspection, see real-time video tracking on an inspection line. For driving, see computer vision for self-driving cars.
Who can build a lab-ready vision demo for our course hardware?
TechnoLynx builds computer vision demo pipelines on the target hardware and packages them to run in a lab. The work starts by framing what the final demo must show for your learners, then choosing the classical techniques and learned model families that suit the target board, implementing the pipeline on that hardware, validating that it meets its latency and resource limits, and packaging it so it runs in a lab. This work falls under TechnoLynx’s Computer Vision R&D offer. Whether to bring in a specialist depends on how far the demo goes: a classical OpenCV lab is well documented, while a detector that has to stay live across a room of kits is an engineering problem in its own right. When choosing a partner, ask to see a build measured on your board, not a figure quoted from a datasheet.
That engagement covers the engineering of the demo pipelines, not authoring the syllabus, assessment or accreditation, which stay with the teaching team. Courses that only need a ready-made path have real alternatives: the Duckietown platform was designed as an inexpensive, reproducible kit for autonomy education, at roughly $150 per vehicle when its paper was written, and it comes with a structured MOOC. Published course materials such as Georgia Tech’s project sequence set out an order of labs.
FAQ
Is computer vision ML or AI?
Computer vision is a field of artificial intelligence, and much of it now uses machine learning, though not all of it. Georgia Tech’s course, for example, approaches its problems with both classical machine learning and deep learning.
