OpenCV 5 现已正式发布。公告称，这是自 2018 年 OpenCV 4 发布以来八年间最大的一次升级。

这次升级包含了无数开发者的贡献，其中下面三个单位系统性组织了开发：

• Big Vision公司：负责OpenCV开发、OpenCV大学、OpeCV推广等
• OpenCV中国团队：负责RISC-V和嵌入式系统优化、CPU性能测试基准开发（https://github.com/opencv/cvbenchmark）等（感谢中科院软件所、进迭时空公司支持RISC-V生态优化）
• OpenCV.ai公司

OpenCV 5对中国开发者意味着什么

对中国开发者来说，OpenCV 5有几层特别现实的意义。

• 边缘设备更重要。中国有大量面向机器人、工业检测、智能安防、车载、消费电子和具身智能的视觉应用，部署环境经常不是标准服务器，而是ARM、Snapdragon、RISC-V、NPU等多种硬件。OpenCV 5重新整理HAL，对这类场景尤其关键。

• 现代模型部署更顺。大量科研和工程项目会把模型导出为ONNX，再接入C++或Python视觉流程。OpenCV 5提升ONNX覆盖率和动态shape支持，可以减少“模型训练好了，但部署时卡住”的情况。

• OpenCV正在从传统CV扩展到“视觉系统底座”。未来一个视觉应用里，可能同时有传统图像处理、检测分割、视觉语言模型、几何重建和硬件加速。OpenCV 5的价值，不只是某个单点更强，而是让这些模块尽量在同一套工具链里协同工作。

• 参与开源社区的机会更清晰。OpenCV 5.x周期还会持续推进GPU DNN、非CPU HAL、更多模型与更多硬件支持。对高校、研究机构和企业开发者来说，这也是参与国际开源项目、提交patch、贡献测试和优化的好机会。

关于OpenCV 5

对很多开发者来说，OpenCV是“装上就能用”的底层工具：读图、变换、滤波、检测、跟踪、标定、拼接、部署，几乎每个视觉项目都会在某个环节碰到它。也正因为太常用，OpenCV的每一次大版本更新，都不只是库本身的事情，而会影响大量科研原型、工程系统和产业应用。

这一次的OpenCV 5，不是常规的小修小补。它针对近几年计算机视觉技术栈的变化做了一次系统性升级：深度学习模型越来越复杂，ONNX模型越来越常见，Transformer和大视觉模型进入生产环境，边缘设备和异构硬件越来越多，Python成为很多视觉开发者的第一入口。OpenCV 5正是面向这些变化而来。

OpenCV 5把“传统视觉工具箱”往“现代视觉应用底座”又推进了一大步。

OpenCV关键统计数据

为什么需要OpenCV 5

从OpenCV 4到OpenCV 5，计算机视觉的开发环境已经变了很多。现在的视觉应用往往不再是“读一张图、跑一个传统算法”这么简单，而是把经典图像处理、深度学习、Transformer、大视觉模型、边缘部署、异构硬件和Python工作流混在一起。

开发者的期待也变了：同一套代码最好能在笔记本、服务器、嵌入式设备、ARM芯片、Snapdragon平台以及专用加速器上高效运行；一个从PyTorch导出的ONNX模型，最好能直接加载，而不是到处报算子不支持、动态shape不兼容。

OpenCV 5要解决的核心问题很明确：让核心库更快、更小，让API更干净，让DNN引擎跟上现代模型，让硬件加速路径更清晰，让3D视觉工具更好用，也让文档真正变得容易查。

最大的变化：全新的DNN引擎

OpenCV 5最重要的变化，是DNN引擎重写。ONNX算子覆盖率：OpenCV 4.x时期大约只有22%，到OpenCV 5提升到80%以上。

这个数字背后，解决的是很多开发者过去最熟悉的痛点：模型导出成ONNX后，OpenCV DNN不一定能顺利读；即便能读，也可能因为动态shape、控制流、量化图或某些Transformer结构而失败。OpenCV 5的新DNN引擎不再把网络简单看成一层一层顺序执行的列表，而是重建为带类型信息的计算图。这样一来，系统可以做形状推理、常量折叠、算子融合和更激进的内存复用。

新引擎开始支持过去很难处理的几类模型结构：带If和Loop的子图；符号shape和动态shape；用于量化模型的Quantize/Dequantize图；以及Transformer里常见的Attention和MatMul融合。

其中Attention融合很关键。引擎可以识别Transformer中典型的“MatMul - Softmax - MatMul”模式，并把它折叠成一个融合后的Attention操作，底层采用类似FlashAttention的实现思路。对开发者而言，使用方式没有变：加载模型，运行推理，性能提升由引擎自动完成。

三个引擎，一套API

大版本重写最容易让人担心兼容性。OpenCV 5的处理方式比较稳妥：在同一套DNN API背后保留多个引擎，开发者可以在读取模型时指定使用哪一个。

主要选项包括：ENGINE_CLASSIC，强制使用4.x风格的经典引擎，也是当前支持CUDA、OpenVINO等非CPU后端和target的路径；ENGINE_NEW，强制使用新的图引擎，支持融合和动态shape，但目前只跑CPU；ENGINE_AUTO，默认选项，先尝试新引擎，失败时回退到经典引擎；ENGINE_ORT，使用内置的ONNX Runtime封装，仅适用于ONNX模型，并且编译时需要启用WITH_ONNXRUNTIME。

这意味着，大部分已有代码不必大改。你仍然可以像以前一样调用readNetFromONNX；默认情况下，OpenCV会优先尝试新引擎，必要时自动回退。如果你要明确指定引擎，也可以在加载模型时传入engine参数。​​​​​​

# Python版本import cv2 as cv# 默认行为：ENGINE_AUTO，优先尝试新引擎，失败后回退到经典引擎net = cv.dnn.readNetFromONNX("model.onnx")# 也可以显式指定新图引擎net = cv.dnn.readNetFromONNX("model.onnx", engine=cv.dnn.ENGINE_NEW)net.setInput(blob)out = net.forward()​​​​​

// C++版本#include <opencv2/dnn.hpp>using namespace cv;// Default behaviour (ENGINE_AUTO).dnn::Net net = dnn::readNetFromONNX("model.onnx");// Or pin a specific engine at load time./*dnn::Net netNew = dnn::readNetFromONNX("model.onnx", dnn::ENGINE_NEW);*/net.setInput(blob);Mat out = net.forward();

速度如何：在CPU上对标ONNX Runtime

盖率只是第一步，真正到工程里还要看速度。官方测试在Intel Core i9-14900KS和Ubuntu 24.04 LTS上比较了OpenCV 5 DNN与ONNX Runtime在多个真实模型上的CPU推理延迟。结果显示，在若干模型上，OpenCV 5的新DNN引擎不仅能跑，而且有竞争力，很多情况下还更快。

例如，XFeat上OpenCV 5为6.56毫秒，ONNX Runtime为8.61毫秒；YOLOv8n上分别为10.9毫秒和12.15毫秒；DINOv2 small上分别为23.78毫秒和29.58毫秒；OWLv2上分别为1090毫秒和1489毫秒。数值越低越好。

当然，这些结果不能简单理解为OpenCV 5在所有场景都一定快于ONNX Runtime。更准确的理解是：OpenCV 5的新DNN引擎已经不再只是“能不能加载模型”的补充选项，而是在CPU推理上有了正面竞争的能力。对于希望减少依赖、把视觉流程尽量留在OpenCV内部的项目，这一点很有价值。

更多模型可以开箱即用

ONNX覆盖率提升以后，最直接的好处就是更多现代模型可以直接跑。OpenCV 5已经针对一批覆盖检测、分割、特征骨干网络和生成式模型的现代模型进行了验证。

这对工程项目很实际。过去一个视觉系统里可能同时依赖OpenCV、ONNX Runtime、某个检测框架、某个分割框架，再加上一堆前后处理代码。OpenCV 5的目标不是替代所有深度学习框架，而是让更多常见视觉模型能在同一个库里完成部署，降低依赖复杂度。

LLM和VLM也进入了OpenCV

OpenCV 5里一个很有意思的变化，是DNN模块可以直接运行大语言模型和视觉语言模型，不再必须依赖单独的推理运行时。

为了做到这一点，OpenCV 5加入了两个过去传统CV库不太需要的组件：内置tokenizer，以及用于自回归解码的KV-cache。前者负责把文本转成模型需要的token，后者让模型逐token生成时保持效率。官方文章提到，相关能力覆盖Qwen 2.5、Gemma 3、PaliGemma以及GPT-2/GPT-4家族，并且仍然通过开发者熟悉的Net API调用。

需要强调的是，OpenCV并不是要变成专门的LLM服务框架。它更适合在视觉流程中调用小型语言模型或视觉语言模型，比如图像描述、OCR后处理、开放词表查询，或者在一个视觉系统内部完成简单的图文理解。对于这类任务，少引入一个运行时，往往就少一层部署负担。

LaMa图像修复：一个forward完成物体移除

OpenCV 5还展示了基于LaMa的图像修复能力。输入一张图，再给出要移除区域的mask，DNN引擎就可以在一次forward中完成修复，把被遮挡区域补回来，并让边缘自然融合。

流程很直接：准备原图；准备mask；调用一次Net::forward；得到干净输出。官方还在OpenCV 5.x分支里提供了可运行的samples/dnn/inpainting.py。如果希望进一步尝试扩散模型版本，也可以看samples/dnn/ldm_inpainting.py。

实现上图功能的代码只有如下5行：

import cv2 as cvnet = cv.dnn.readNetFromONNX("lama.onnx")blob = cv.dnn.blobFromImages([img, mask], scalefactor=1/255.)net.setInput(blob)out = net.forward()   # inpainted imag

这类能力说明OpenCV 5的DNN模块已经覆盖到更广的现代视觉任务，不再只是传统意义上的分类、检测和分割。

特征匹配也进入深度学习时代

特征检测和匹配是OpenCV最经典的任务之一。图像拼接、图像对齐、三维重建，很多系统都从SIFT、ORB、FAST这些传统特征开始。OpenCV 5保留了这些经典方法，同时把现代学习式特征匹配作为一等公民引入。

新的Features模块替代原来的Features2D，加入了完整的神经网络式检测、描述和匹配流程。

• cv::ALIKED是基于CNN的关键点检测与描述方法，可以像SIFT或ORB一样嵌入已有调用位置；

• cv::DISK是通过强化学习训练出来的学习式特征，在宽基线和低纹理场景中更有优势；

• cv::LightGlueMatcher则是基于Attention的匹配器，可以输出带置信度的匹配结果，并能接入图像拼接模块。

这不是“新方法替代旧方法”，而是让开发者有了更灵活的选择：简单场景继续用稳定、轻量的传统特征；困难场景则可以直接尝试学习式特征和LightGlue匹配。

核心库更快，也更现代

OpenCV 5并不只是在DNN上做文章。底层core模块也做了很多会影响日常开发体验的改动。

首先是数据类型。OpenCV 5加入了原生FP16，也就是cv::hfloat和CV_16F，还加入了BF16，也就是cv::bfloat和CV_16BF，同时补齐了bool、64位整数等类型。现代AI工作负载大量使用这些数据类型，原生支持意味着少做很多来回转换。

其次是更完整的N维数组和标量支持。过去cv::Mat至少需要二维，这在处理标量、1D数组以及很多模型中间结果时并不自然。OpenCV 5的cv::Mat可以表示0D标量和1D数组，并加入broadcasting，以及transposeND、flipND等N维操作。很多过去需要手工reshape、扩维、挤维的代码，可以变得更直接。

语言层面也更清爽：历史包袱很重的C API正式进入弃用状态；C++17成为最低推荐标准，后续5.x还计划引入C++20 modules；Python侧支持NumPy 2.x，并且让C++算法在Python里更好地支持命名参数。也就是说，过去必须记住一串位置参数的调用，现在可以写成cv.someAlgorithm(threshold=0.5)这种更直观的形式。

硬件加速：让同一套代码跑在更多芯片上

OpenCV 5里还有一个不那么显眼、但非常关键的变化：重新设计了Hardware Acceleration Layer，也就是HAL。

过去支持不同硬件，常常意味着大量条件编译、重复实现和分散在各处的优化代码。OpenCV 5希望把这件事收敛到一套干净的HAL契约里：硬件厂商可以为自己的芯片接入优化kernel，OpenCV在可用时自动调用，开发者的上层代码不用改。

目前已经接入或推进的路径包括：Intel IPP/IPPICV，这是OpenCV早期就很重要的x86/x64加速路径；Arm KleidiCV，面向AArch64，使用NEON、SVE和SME加速核心图像处理与DNN kernel；Qualcomm FastCV，面向Snapdragon等移动平台，可通过Hexagon DSP和NPU加速；RISC-V Vector，也就是RVV，相关工作主要由OpenCV China推动。

底层还有Universal Intrinsics 2.0，用一套向量化代码映射到SSE、AVX2/512、NEON、SVE、RVV等不同指令集。对开发者来说，理想状态很简单：写一次OpenCV代码，落到不同硬件上时尽量自动走最优路径。

3D视觉模块重新整理

OpenCV的3D能力这些年一直在增长，但旧的calib3d模块已经越来越像一个“大抽屉”。OpenCV 5把相关能力拆成三个更清晰的模块：3d、calib和stereo。

3d模块负责基础3D几何与视觉能力，包括I/O、几何基本元素、ICP等算法，以及部分SLAM相关能力；calib模块负责相机标定，包括单相机标定和重构后的多相机标定流程；stereo模块负责双目深度。

更值得注意的功能包括：通过calibrateMultiview进行多相机标定，也就是N相机bundle adjustment；通过registerCameras做相机间外参注册，并支持手眼标定、机器人世界标定等机器人场景；通过loadPointCloud、savePointCloud、loadMesh、saveMesh读写点云和网格，支持OBJ、PLY；通过TSDF、HashTSDF和ColorTSDF完成稠密RGB-D融合，并加入视觉里程计；此外还有包含MAGSAC的现代USAC框架，以及RANSAC平面和球体拟合。

如果你的工作涉及SfM、机器人、三维重建或RGB-D融合，这次调整不是简单改名，而是一次实用的能力升级。

文档终于更好用了

OpenCV 5的文档也重做了。新的文档系统从纯Doxygen转向Sphinx + Doxygen，带来了更现代的阅读体验：左侧导航常驻，手写教程和自动生成的API参考放在一起，Python签名可以和C++一起展示，提交前还有链接检查，整体样式也更清爽。

这类变化听起来不如DNN引擎重写那么“硬核”，但对日常开发非常重要。很多人学习OpenCV、查函数签名、找样例代码，首先接触的就是文档。文档少一点阻力，库本身就更容易被用起来。

OpenCV 5.0到底带来了什么

要点：ONNX算子覆盖率从4.x时期的大约22%提升到80%以上；DNN引擎重写为图引擎，支持融合、动态shape和统一buffer pool；可以通过ENGINE_ORT接入ONNX Runtime；LLM/VLM支持进入DNN模块，内置tokenizer和KV-cache；动态shape ONNX由新的形状推理引擎原生支持；cv::Mat支持0D标量和1D数组；数据类型补齐FP16、BF16、bool、64位整数等。

这些变化合在一起，说明OpenCV 5不是简单增加几个函数，而是在补现代视觉应用所需要的底层能力。

下一步：GPU版DNN引擎，以及非CPU HAL

OpenCV 5.0是一次大更新，但更像是一个新架构的起点。接下来最值得关注的，是两条路线。

第一条是新DNN引擎的原生GPU支持。当前官方展示的DNN benchmark主要在CPU上运行，新图引擎也是CPU优先。如果现在要GPU推理，可以使用ONNX Runtime后端以及CUDA、TensorRT等execution provider。OpenCV后续希望把GPU加速带入自己的原生图引擎，让开发者仍然通过同一个Net API拿到GPU速度，而不是必须额外引入独立运行时。

第二条是非CPU HAL，用于加速前处理和后处理。真实视觉流水线里，模型推理往往只是其中一部分。每一次forward前后都有resize、颜色转换、归一化、letterbox、NMS、mask resize、结果绘制等步骤。今天很多系统是CPU做前后处理，加速器做推理，数据在CPU和GPU/NPU之间来回搬。很多时候，真正的瓶颈不是模型，而是这些搬运。

非CPU HAL的目标，是让常见imgproc函数也能跑在GPU、NPU或其他加速器上。理想流程是：帧保留在加速器上，resize和normalize在上面做，推理在上面做，后处理也在上面

结语

OpenCV 5的意义，不在于多了几个新函数，而在于它把OpenCV带回了现代计算机视觉开发的主战场。全新的DNN引擎解决了最常见的模型部署痛点，核心库和Python接口减少了日常摩擦，HAL为异构硬件打开了更干净的加速路径，3D视觉和特征匹配也补上了近年来的发展。

更重要的是，OpenCV 5没有抛弃庞大的既有用户。经典引擎还在，传统特征还在，已有API尽量保持不变。它一边激进现代化，一边保留兼容性。对这样一个被广泛嵌入科研、教学和工程系统的基础库来说，这种克制很重要。

如果说OpenCV过去二十多年是计算机视觉应用的“基础水电”，那么OpenCV 5就是一次面向AI时代的管线改造。它不会让所有问题一夜之间消失，但它让很多过去绕不开的麻烦，终于有了更干净的解决路径。