The Use Of OpenCV In Image Processing – 5 Examples

Large language models have captured most of the AI spotlight since 2023, but computer vision remains one of the most active — and most heavily funded — areas of AI in 2026.

The global computer vision market is on pace to reach roughly $30–35 billion in 2026, still growing at a mid-teens to 20%+ CAGR by most industry estimates, on the back of demand that has nothing to do with chatbots: defect detection on factory lines, medical imaging diagnostics, autonomous driving, and document understanding all depend on it directly.

Behind a large share of these systems sits OpenCV, an open-source library that has anchored practical image processing for over two decades. OpenCV 5.0 shipped in June 2026 — the first major version since 2018 — with a rewritten deep learning engine and, for the first time, native support for running language and vision-language models inside the library.

What OpenCV does best hasn’t changed: the image processing layer — preparation, cleanup, transformation, and feature extraction — that both classical computer vision and modern deep learning depend on. This article walks through five of the most common ways OpenCV is used in image processing, with Python examples you can adapt directly, and covers where OpenCV 5’s new capabilities change the calculus.

Computer Vision and Image Processing – What do you have to know?

Image processing is about transforming the input image file itself — done manually in tools like Photoshop or GIMP, or automatically via algorithms (sharpening, denoising, and so on). One major application area is medicine: enhancing a scan’s quality and perceptibility helps a physician reach a diagnosis faster. Computer vision is a different discipline — it interprets an image’s content rather than modifying the file. A common example is driver-assistance systems that scan a vehicle’s surroundings for obstacles and hazards.

Before you begin

You can’t start a computer vision project on raw data — it has to be gathered and standardized first.

What is the OpenCV library?

OpenCV (Open Source Computer Vision) is an open-source computer vision and machine learning library built to provide infrastructure for computer vision applications. It ships over 2,500 optimized algorithms spanning classical computer vision and machine learning, used to detect and recognize faces, identify objects, classify actions in video, track cameras and moving objects, extract 3D models, search image databases, follow eye movement, recognize scenery, and anchor AR overlays.

OpenCV 5.0: what actually changed

OpenCV 5.0 released in June 2026 — the first major version since the 4.x line began in 2018. It is not an incremental update. The core changes:

• A rewritten DNN engine. The graph-based engine adds proper shape inference, constant folding, operator fusion, and support for dynamic shapes and control-flow subgraphs (If/Loop) that the old engine couldn’t handle.
• ONNX operator coverage jumps from roughly 22% to over 80%. In OpenCV 4.x, a large share of modern exported models — anything with dynamic shapes or quantized ops — simply failed to load. That’s now largely fixed.
• Native LLM and VLM inference. For the first time, OpenCV ships its own tokenizer and KV-cache and can run models like Qwen 2.5, Gemma 3, PaliGemma, and GPT-family architectures through the same Net API used for a detection model — no separate PyTorch or ONNX Runtime process required.
• New data types: FP16, BF16, and bool, plus full N-dimensional array and 0D/1D tensor support, reducing memory pressure on quantized and low-precision models.
• New hardware abstraction layer with tuned paths for Intel IPP (SSE/AVX), Arm KleidiCV, Qualcomm FastCV, and RISC-V Vector (RVV). Native GPU support inside the new engine is planned for a later release — for now, CUDA/OpenCL inference still runs through the classic engine.
• Removed the Darknet and Caffe parsers (most models have moved to ONNX) and dropped the legacy C API, requiring C++17.

What’s changed most since the early days is OpenCV’s expanding role in AI pipelines generally — the DNN module now bridges classical CV and the deep learning and VLM ecosystem around it.

Installing OpenCV in Python

Install with pip:

pip install opencv-python

For the “extra” algorithms (SIFT, SURF, contrib modules):

pip install opencv-contrib-python

For headless servers (Docker, no GUI):

pip install opencv-python-headless

Verify with:

import cv2 
print(cv2.__version__)

Don’t install both opencv-python and opencv-python-headless in the same environment — they conflict. Pick the one matching your deployment target.

Examples of using OpenCV in image processing

The five most significant use cases where OpenCV plays a key role in image processing, numbered below:

1. Image enhancement

Depending on the use case, OpenCV offers several enhancement methods:

• Histogram equalization. Improves contrast, particularly useful when an image has large areas of low local contrast that need to become more readable.
• Image noise reduction. Removes random variation in brightness or color, most often introduced by low-light camera capture.

A typical preprocessing pipeline combines histogram equalization and noise reduction before any downstream analysis.

2. Feature extraction

OpenCV provides battle-tested implementations of the algorithms that dominate classical computer vision:

• Edge detection with Canny — finding object outlines
• Corner and keypoint detection with SIFT, ORB, or AKAZE — used for image stitching, matching, and tracking
• Contour detection — finding closed shape boundaries for isolation and measurement
• Color histograms — distribution analysis for classification, retrieval, and anomaly detection

import cv2

img = cv2.imread("input.jpg")
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
edges = cv2.Canny(gray, threshold1=100, threshold2=200)
cv2.imwrite("edges.jpg", edges)

These classical techniques remain the backbone of many 2026 production systems — particularly industrial inspection, robotics, and metrology, where explainable, deterministic, fast geometric measurements matter more than a deep learning model’s accuracy ceiling. Nothing about that has changed; SIFT, ORB, and AKAZE are not obsolete.

Where they fall short is generalization. A SIFT or ORB descriptor matches features by comparing local pixel-level geometry, so it struggles when lighting, viewpoint, or the object’s appearance itself shifts — a keypoint set trained under one warehouse’s lighting won’t reliably match the same parts under another’s. That’s a real limitation for tasks like open-ended visual search, retrieval across varied real-world photos, or matching an object the system has never seen labeled before. Foundation vision models fill exactly that gap, at a cost:

Classical features vs. foundation models: SIFT/ORB/AKAZE vs. CLIP/DINO/ViT

Foundation vision models — CLIP for text-image alignment, DINO/DINOv2/DINOv3 for self-supervised visual representations, and Vision Transformers generally — extract features that generalize far better across lighting, viewpoint, and domain shift than classical descriptors, at the cost of GPU inference and far less interpretability. The practical split in 2026: reach for SIFT/ORB/AKAZE when you need speed, determinism, and a small footprint on a well-controlled scene (barcode alignment, panorama stitching, industrial part registration); reach for CLIP/DINO embeddings when you need semantic similarity, zero-shot retrieval, or robustness across varied real-world conditions the classical descriptors weren’t designed for.

3. Text extraction (OCR pipelines)

OpenCV is not an OCR engine — it doesn’t recognize characters itself. What it does well is the preprocessing that makes OCR reliable: deskewing, denoising, contrast enhancement, thresholding, and isolating the text region.

import cv2
import pytesseract

img = cv2.imread("car.jpg")
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
blur = cv2.GaussianBlur(gray, (5, 5), 0)
thresh = cv2.threshold(blur, 0, 255,
    cv2.THRESH_BINARY + cv2.THRESH_OTSU)[1]

plate_text = pytesseract.image_to_string(thresh)
print(plate_text.strip())

The OCR engine landscape in 2026:

• Tesseract — open-source, mature, multilingual
• EasyOCR — PyTorch-based, strong on natural-scene text and non-Latin scripts
• PaddleOCR — accurate, broad language support
• Cloud OCR APIs (Google Cloud Vision, AWS Textract, Azure AI Vision) — for workloads where SLA and accuracy matter more than self-hosting
• Vision-language models (GPT-5.6, Gemini 3.1 Pro, Claude Opus 4.8) — transcribe and interpret content in a single step

Here’s what that looks like in practice. Addepto built a pipeline for a Polish retailer that needed to read the ingredients list on thousands of product-label photos automatically — useful, for example, for flagging allergens. Two steps did the work: first, a computer vision model found where on the label the ingredients text actually was (labels are cluttered, so this matters); then OCR read the text in that spot.

VLM OCR accuracy vs. traditional OCR: how much better are vision-language models, really?

The gap between traditional OCR and vision-language model (VLM) OCR depends heavily on document type and how “accuracy” is measured — there’s no single number that holds across use cases.

On clean, single-column typed documents, traditional OCR and VLM pipelines both land in the mid-90s to high-90s percent range on field-level accuracy — the two approaches are close to interchangeable here. The gap widens on messy real-world documents:

4. Background removal

Background removal is central to eCommerce product photography: isolate the product, drop or replace the background, remove distraction.

Classical OpenCV methods (thresholding, GrabCut, watershed segmentation) still work well for controlled scenes — a product against a uniform backdrop. For complex backgrounds, modern pipelines combine OpenCV with segmentation models trained specifically for this task:

• U²-Net and MODNet — handle complex backgrounds, hair, and transparency
• Segment Anything Model (SAM) 2 from Meta — isolates any object from a click or bounding box
• SAM 3 (“Segment Anything with Concepts”), presented at ICLR 2026 — extends this from single-object prompts to concepts: given a short phrase like “yellow school bus” or an image exemplar, it detects, segments, and tracks every matching instance across an image or video, not just the one you clicked.
• rembg — a Python library wrapping U²-Net and similar models for one-line background removal

A typical 2026 production pipeline combines these layers: SAM 3 or a task-specific model (U²-Net, MODNet) produces the mask, OpenCV refines edges and handles compositing and batch processing, and — for catalogs where many images share a concept (“remove every instance of the mannequin stand”) — SAM 3’s concept prompting reduces per-image manual selection versus click-based SAM 2 workflows.

5. Bulk geometric operations: rotating, cropping, and resizing at scale

The fifth and final of the five core use cases — related to background removal above only in that it’s often the next step after it, cleaning up a batch of already-isolated product images before publishing.

Rotating, cropping, resizing, and similar operations are trivial individually — you could do any single one in MS Paint — but valuable at scale: looping over thousands of images with OpenCV takes minutes, where manual editing in Photoshop would take days. These aren’t sophisticated algorithms; they’re time-consuming manual work made fast.

OpenCV and deep learning in 2026

The most important shift since this article was first written: OpenCV is no longer used in isolation. Modern computer vision systems combine OpenCV — for preprocessing, post-processing, and classical algorithms — with deep learning and VLMs for perception. Three patterns recur in production:

1. OpenCV preprocesses, a deep learning framework predicts. The most common pattern — OpenCV reads, resizes, denoises, and normalizes, then hands off to PyTorch, TensorFlow, or ONNX.
2. OpenCV runs the model directly with cv2.dnn. With OpenCV 5’s rewritten engine, this now extends meaningfully further than before: beyond classic detection/segmentation models, the DNN module can run LLMs and VLMs (Qwen 2.5, Gemma 3, PaliGemma, GPT-family architectures) end-to-end, with OpenCV’s own tokenizer and KV-cache handling autoregressive decoding. That means a captioning or visual-QA step can run inside the same process as your classical pipeline, without adding a PyTorch dependency — useful on edge devices, robotics, and embedded systems where every dependency has a cost.
3. OpenCV post-processes deep learning outputs. Bounding boxes, non-maximum suppression, contour cleanup, overlays, heatmaps — the visual output that makes predictions usable.

Object detection: where YOLO fits

Object detection isn’t one of the five core OpenCV examples above — OpenCV doesn’t detect objects on its own — but it’s the deep learning task most commonly paired with OpenCV in production (pattern 1 and 2 above), so it belongs here rather than in the examples list. For real-time object detection specifically, three families dominate production 2026 deployments:

• YOLO, now at YOLO26 (released January 2026) — the standard reference point for real-time detection. YOLO26 removes Distribution Focal Loss and moves to NMS-free, end-to-end inference, which makes latency deterministic even in crowded scenes — a meaningful property for production SLAs. Reported gains include up to ~43% faster CPU inference than earlier YOLO generations at comparable accuracy, making it a common default for edge and mobile deployment.
• Detectron2 / MMDetection — PyTorch-based frameworks favored where you need broader model-architecture flexibility or research-grade configurability over YOLO’s deployment-first design.
• RT-DETR and other transformer-based detectors — competitive accuracy on server GPUs, generally worse latency and quantization robustness on edge hardware than YOLO26.

OpenCV’s role here is unchanged in kind, larger in scope: reading frames, preprocessing, and — increasingly, via cv2.dnn in OpenCV 5 — running the detection model itself when a full framework isn’t wanted.

The takeaway: OpenCV’s role hasn’t shrunk in the deep learning era — it has shifted and, with OpenCV 5, expanded. In 2026 it is most often the layer surrounding your model, handling everything before, during (via cv2.dnn), and after inference.

Hardware acceleration and embedded deployment

Why this matters for an OpenCV pipeline specifically: once a pipeline moves off a desktop or cloud GPU onto embedded hardware — a camera on a factory line, a robot, a vehicle — the chip and accelerator you pick determine what OpenCV can actually speed up and what has to happen outside it. This section is about that boundary: what OpenCV 5 accelerates directly, and where the decision moves to hardware chosen separately.

What OpenCV 5 speeds up directly. Its new hardware abstraction layer adds tuned kernels for Intel IPP (SSE/AVX), Arm KleidiCV, Qualcomm FastCV, and RISC-V Vector (RVV) — none of which existed as first-class targets in 4.x. That’s a direct win for CPU-only edge deployment on Arm or RISC-V silicon. What it doesn’t cover yet: native GPU support inside the new DNN engine isn’t ready, so CUDA and OpenCL inference still route through the classic engine — if your target is GPU-based, that part of the pipeline is unchanged from 4.x.

Where the decision moves outside OpenCV: the chip itself. Arm-based system-on-chip designs are the most common target for embedded vision in 2026, combining CPU, GPU, and increasingly NPU/DSP blocks on one low-power die — a fit for camera-adjacent inference under tight thermal and power budgets (industrial cameras, robotics controllers, automotive ECUs). In that setup, OpenCV’s role narrows to what it’s good at: classical preprocessing and postprocessing on the CPU (where KleidiCV now helps), while the actual model inference runs on the NPU/DSP through the vendor’s own runtime. OpenCV moves data between them; it doesn’t run the model.

When FPGAs beat GPU/NPU. The one case where you’d skip both the CPU path above and a GPU/NPU: deterministic, low-jitter latency requirements — safety-critical inspection lines with hard cycle-time guarantees, high-speed line-scan cameras, or certification regimes that favor a fixed, auditable data path over a general-purpose scheduler’s variability. FPGAs cost more engineering time to build but remove the tail-latency variance a GPU/NPU scheduler can introduce under load.

When to reach for something other than OpenCV?

OpenCV is broad but not always the best fit. Most modern Python computer vision projects pair it with a specialized tool for the piece OpenCV doesn’t cover. Same structure for each: what the tool does, and how it pairs with OpenCV.

• Pillow (PIL) — basic file conversion and resizing; no computer vision algorithms. Pairing: Pillow for I/O, OpenCV for the actual processing.
• scikit-image — pure Python, research-oriented. Pairing: prototype here, move to OpenCV when production speed matters.
• PyTorch torchvision / TensorFlow Keras Vision — the standard for training and deploying deep learning models. Pairing: OpenCV preprocesses, these run the model.
• albumentations — data augmentation, built on OpenCV internally with a cleaner training-pipeline API. Pairing: used alongside OpenCV, not instead of it.
• MediaPipe (Google) — pre-built pipelines for face detection, hand tracking, pose estimation, and segmentation. Pairing: use MediaPipe when a ready-made pipeline covers the task; drop to OpenCV only for what it doesn’t cover.
• Detectron2 / MMDetection — PyTorch frameworks for state-of-the-art detection and segmentation research. Pairing: OpenCV handles I/O and postprocessing around them.
• Ultralytics YOLO (YOLO26) — the default for real-time detection where latency and edge deployment matter. Pairing: OpenCV reads frames in and draws/post-processes outputs.
• Vision-language models (GPT-5.6, Gemini 3.1 Pro, Claude Opus 4.8) — open-ended visual understanding, not just detection. Pairing: OpenCV crops and preprocesses the image before it goes to the VLM.

The common 2026 pattern this produces: OpenCV for geometric and pixel-level work — now including some model inference directly, via OpenCV 5’s DNN engine — YOLO or a PyTorch model for detection/segmentation, a VLM for semantic understanding, albumentations for training data, and a cloud API for OCR where the SLA matters more than self-hosting.

When classical OpenCV still wins

The section above is about replacing or supplementing OpenCV with something newer. This one is the opposite question: when does the older, simpler tool remain the right call? Deep learning and VLMs aren’t a strict upgrade in every case — classical OpenCV techniques win when:

• Latency and cost are tight and the scene is controlled — a fixed camera angle, consistent lighting, a known object class. A Canny edge detector or GrabCut segmentation runs in milliseconds on a CPU with no model-hosting cost; a deep learning or VLM call adds inference latency and, for hosted models, per-call cost that doesn’t pay for itself on a simple, stable task.
• Explainability is a requirement, not a nice-to-have — safety-critical inspection, regulated industries, or any system where you need to point to exactly why a measurement passed or failed rather than trusting a model’s confidence score.
• You don’t have training data or budget for one, and the task is genuinely geometric (measuring a distance, checking alignment, counting contours) rather than semantic.

OpenCV in image processing – Conclusion

OpenCV remains the foundation of practical image processing in 2026 — not because it’s the newest tool, but because it’s reliable, fast, well-documented, and now, with OpenCV 5, considerably better integrated with the deep learning and VLM ecosystem around it. For most production computer vision systems, OpenCV is the preprocessing, post-processing, and increasingly the inference-hosting layer that makes everything else possible.

The five use cases here — image enhancement, feature extraction, OCR pipelines, background removal, and bulk geometric operations — are the patterns you’ll see most often in real-world systems, whether the underlying task is industrial defect detection, medical imaging, document understanding, or e-commerce product photography.

References

1. OpenCV. Official documentation and library home. https://opencv.org/
2. OpenCV. OpenCV 5 release notes. https://opencv.org/opencv-5/
3. OpenCV. OpenCV 5 wiki / technical changelog. https://github.com/opencv/opencv/wiki/OpenCV-5
4. Wikipedia. OpenCV. https://en.wikipedia.org/wiki/OpenCV
5. PyPI. opencv-python package. https://pypi.org/project/opencv-python/
6. Carion, Gustafson, et al. “SAM 3: Segment Anything with Concepts.” ICLR 2026. https://openreview.net/forum?id=r35clVtGzw
7. Ultralytics. YOLO26 documentation. https://docs.ultralytics.com/compare/yolov5-vs-yolo26
8. Extend.ai. “How Brex Reached 99% Accuracy Across Millions of Financial Documents.” https://www.extend.ai/resources/how-brex-reached-99-accuracy-across-millions-of-financial-documents
9. Addepto. “Computer Vision Case Study: Image Generation Process (Step-by-Step).” https://addepto.com/blog/computer-vision-case-study-image-generation-process-step-by-step/
10. Addepto. Computer Vision Solutions. https://addepto.com/computer-vision-solutions/
11. Mordor Intelligence. Computer Vision Market Size & Share, 2026–2031. https://www.mordorintelligence.com/industry-reports/computer-vision-market