2026 年 6 月，OpenCV 5.0 正式釋出。社群在 Hacker News 上熱烈討論了好幾天，距離 4.0（2018 年 11 月）整整八年——這個間距本身就說明這次改版的份量。
我花了幾天時間把 官方 release page 、GitHub OpenCV 5 wiki 、heise online 的解析 、Satya Mallick 在 Embedded Vision Summit 的簡報 全部過了一遍，這篇就把所有重點整合在一起，每個變更都附上技術意義與遷移建議。
如果你是現在還在維護 OpenCV 4.x 專案、或正在評估要不要升級的工程師，這篇就是寫給你的。
三個最反直覺的結論
我把所有更新讀過一輪後，三個變化讓我停下來重讀好幾次：
第一，OpenCV 自己內建了一套可以跑 VLM 的最小 runtime。Qwen 2.5、Gemma 3、PaliGemma 這些多模態模型現在能透過 cv::dnn::Net API 直接餵圖跟 prompt——不再需要 Hugging Face Transformers。第二，DNN 引擎 ONNX 操作覆蓋率從 ~22% 衝到 80%+，這數字背後意味著「PyTorch 模型 export ONNX 後在 OpenCV 跑得起來」這件事，終於從碰運氣變成預設可行。第三，C API 整個被連根拔起——任何還在用 IplImage、CvMat 的舊專案，5.0 連編都編不過。
其餘的改動（C++17 基線、HAL 重構、Features 模組翻新、bfloat16、N 維陣列）一樣有份量，但要看你做的場景。下面一項一項拆。
一、DNN 引擎重寫：從「將就用」變成「真的能用」
OpenCV 的 DNN 模組自 3.1 引入、3.3 升上主 repo 後，一直有個尷尬問題——它支援的 ONNX operator 太少。實務上你拿一個新的 PyTorch 模型 export 成 ONNX，用 cv2.dnn.readNetFromONNX 載入，大概率會吐 unsupported operator 錯誤。
5.0 怎麼解？官方把整個 DNN 引擎重寫，並引入「三引擎並存於同一個 Net API 之後」的設計：
cv::dnn::Net 統一 API
└── engine = ENGINE_AUTO 自動選擇
├── 預設 → New Engine（重新設計，ONNX 80%+）
├── 向後相容 → Classic Engine（4.x 的舊引擎）
└── 外部 → ORT Engine（ONNX Runtime backend）- New engine：原生重寫，ONNX 覆蓋率從 ~22% 提升到 80%+（數字來自 opencv.org 官方 5.0 頁面 ）。
- Classic engine：保留 4.x 的引擎做向後相容。
- ORT engine：直接呼叫 ONNX Runtime 作為 backend，要 GPU 加速時走這條。
實務上你只要寫：
auto net = cv::dnn::readNet("yolo11.onnx");
// 想強制走特定引擎時：
net.setPreferableEngine(cv::dnn::ENGINE_NEW); // 或 ENGINE_CLASSIC / ENGINE_ORT一個小坑
New engine 目前只支援 CPU。要 GPU 加速，必須走 Classic engine + CUDA backend，或者 ORT engine + NVIDIA execution provider。官方表示後續版本會補上 New engine 的 GPU。
另外，Darknet 與 Caffe 解析器被完全移除——多數模型現在都已轉 ONNX，OpenCV 不再養這兩個古董。TFLite 仍可用，但只在 Classic engine 裡。
二、LLM / VLM 進場：OpenCV 第一次能說人話
這是 5.0 最讓我意外的設計。引述 OpenCV 5 官方 wiki 的描述：
The new engine includes the tokenizers and all necessary components: attention layers, decoding blocks, post-processing, KV-cache, to run VLMs end-to-end.
換句話說——OpenCV 5 自己內建了一套可以跑自迴歸解碼的最小 LLM runtime。heise online 整理 提到目前已驗證跑過的模型家族：
| 模型 | 類型 | 來源 |
|---|---|---|
| Qwen 2.5 | LLM / VLM | 阿里巴巴 |
| Gemma 3 | LLM | |
| PaliGemma（部分支援） | VLM |
實務上你可以這樣寫：
import cv2
net = cv2.dnn.readNet("paligemma.onnx")
net.setInput(image_blob, "image")
net.setInput(prompt_tokens, "text")
output = net.forward() # 回傳生成的描述 tokens關鍵差別在於 「no separate runtime」——OpenCV 自帶 tokenizer 與 KV-cache，你不必再裝 Hugging Face Transformers，也不必額外起 vLLM / TGI 服務。一個 OpenCV 就解決從影像前處理到 VLM 描述輸出的整條 pipeline。這也是 opencv.org 對 VLM 模組 強調的設計目標。
這對工程意義是什麼？
對「邊緣裝置上做即時 VLM」這類場景影響最大。以前你要在 Jetson Orin Nano 上做「鏡頭即時描述場景」，得：
- OpenCV 抓幀
- 轉成 PIL Image
- 餵給 Hugging Face 的 processor
- 跑 transformer
- 把結果轉回 OpenCV 畫面
現在這 5 步合成 1 個 Net::forward()。記憶體佔用、跨程式呼叫成本、安裝依賴的負擔——全部砍掉。
不過必須誠實提醒：目前 New engine 仍是 CPU only，所以 LLM/VLM 推論在邊緣裝置上的速度會被 CPU 算力限制。要真正即時還是得走 ORT + GPU，或者等後續版本補上原生 GPU。
三、徹底移除 legacy C API
從 4.0 開始 OpenCV 就在棄用 C API，5.0 直接把它連根拔起。以下這些東西在 5.0 都消失：
| 移除項目 | 替代方案 |
|---|---|
IplImage / CvMat 結構 | cv::Mat（2.0 起就存在） |
cvCreateMat() / cvFindContours() C 函式 | cv::Mat 建構子 / cv::findContours() |
CV_* 巨集（大量） | 名稱化 enum |
include/opencv/ 標頭資料夾 | 全部走 include/opencv2/ |
| OpenVX 整合 | 移除（業界使用率太低） |
| G-API 與經典 ML 模組 | 移到 opencv_contrib（仍可裝） |
升級時最常見的 4 種編譯錯
| 錯誤訊息 | 原因 | 解法 |
|---|---|---|
error: 'IplImage' was not declared | 舊 C API | 改 cv::Mat |
error: 'cvWaitKey' was not declared | C 函式 | 改 cv::waitKey() |
'_aligned_malloc' was not declared | 缺 C++17 | 加 -std=c++17 |
import error: cv2 has no attribute 'gapi' | G-API 搬家 | 裝 opencv-contrib-python 並改 import |
我自己升 4 → 5 時最痛的是 macro 全面改名。以前 CV_8U、CV_32F 這些還留著，但 CV_RGB(r,g,b)、CV_FILLED 之類的 macro 都被改成 cv::Scalar(...) / cv::FILLED，要全文搜尋替換。
不要害怕，如果你想看完整的不相容清單，OpenCV 5 release page 的 migration guide 寫得很詳細。
四、新 HAL 與 Universal Intrinsics 2.0
Satya Mallick 在 Embedded Vision Summit 的簡報 裡，把 HAL（Hardware Acceleration Layer）列為「7 件 5.0 在解的事」之一。我們先看為什麼這層存在。
OpenCV 要在這些架構上跑：
- Intel x86（SSE / AVX / AVX2 / AVX-512）
- Arm（NEON、FP16、BF16、SVE）
- Qualcomm（Hexagon DSP、FastCV）
- RISC-V（RVV 1.0）
- NVIDIA / AMD GPU
過去每加一種新指令集，要在演算法層手動寫多個版本。新 HAL 抽象化這層，加上 Universal Intrinsics 2.0——一段 C++ 程式碼，編譯時自動展開成對應平台的 SIMD 指令。
實務影響：
| 平台 | 受益功能 |
|---|---|
| RISC-V（如 LicheePi、StarFive） | 4.12 起就有 RVV 1.0 backend |
| Arm v8（Apple Silicon、Raspberry Pi 5） | NEON FP16、BF16 加速 |
| Intel | OpenVINO 整合更深 |
| Qualcomm | FastCV 整合 |
對於想把 OpenCV 應用部署到邊緣裝置的人，這次的 HAL 重構等於把「為了 Pi 4 / Pi 5 / Jetson / RISC-V 各跑一套效能測試」這種地獄變成「寫一次到處跑」。
五、資料型別擴充與真正的 N 維陣列
4.x 的 cv::Mat 名義上支援多維，但實作上有很多限制——Mat::dims 與 Mat::rows、Mat::cols 的關係很尷尬，做 transformer 那種 N-D tensor 操作會撞牆。
5.0 新增的型別：
| 新型別 | 對應 C++ | 用途 |
|---|---|---|
CV_16BF | cv::bfloat | bfloat16，深度學習主流推論型別 |
CV_32U | uint32_t | 無號 32 位元 |
CV_64U | uint64_t | 無號 64 位元 |
CV_64S | int64_t | 有號 64 位元（大張量索引） |
CV_Bool | bool | 真正的布林矩陣 |
以前 4.x 用 CV_8U 來假裝 bool，現在有真的 CV_Bool，邏輯運算與遮罩可以清乾淨。
更重要的是 真正的 N 維陣列支援。cv::Mat::dims 可以是任意整數，配合新的 InputArray/OutputArray API，OpenCV 5 第一次能自然處理 transformer 的 [batch, seq, hidden] 這種張量。
六、Features 模組——傳統與深度學習特徵的世代交替
Features2D 模組從 OpenCV 2.x 就存在，裡面是 SIFT、SURF、ORB、AKAZE 這些經典算法。5.0 把它改名為 Features，並加入深度學習時代的特徵匹配：
| 演算法 | 類型 | 何時用 |
|---|---|---|
| SIFT / ORB | 經典手刻特徵 | 計算便宜、可解釋 |
| ALIKED | DL 特徵 | 比 SIFT 更穩 |
| DISK | DL 特徵 | 室外場景、變化光線 |
| LightGlueMatcher | DL matcher | attention-based，比 BFMatcher 強很多 |
heise online 寫得很傳神：「LightGlue uses attention mechanisms to match image features more robustly than classic methods.」
實務上 panorama 拼接、Visual SLAM、3D 重建這類需要 robust feature matching 的場景，現在可以從 SIFT 直接升級成 LightGlue，幾乎不用改 API。
升級策略：什麼時候升、什麼時候別升
升級不是越早越好。這張表是我自己的決策框架：
| 情境 | 建議 | 理由 |
|---|---|---|
| 新專案、用 Python | 直接 5.0 | 沒有歷史包袱，享受新引擎與 LLM 整合 |
| 既有 4.x 純 C++ 專案、無 C API | 可升 | 改 macro 就好，效能會提升 |
| 重度依賴 G-API | 暫緩 | G-API 搬到 contrib，需要重新 import |
| 用 cv2 + CUDA GPU | 暫緩 | New engine CPU only，等 5.1 |
| 程式碼還有 IplImage / CvMat | 不能升 | C API 全砍，停在 4.x 維護分支 |
| 嵌入式裝置 / RISC-V | 可升 | HAL 重構大幅受益 |
OpenCV 同時維護 4.x 與 5.x 兩條 stable 分支，4.x 仍會收到 SIMD/HAL/codec 的 backport，給「不能立刻升級」的專案緩衝期。
我自己的判斷流程是這樣的：先在現有 codebase 跑一次 grep -rE 'IplImage|CvMat|cvCreateMat'——只要這個 grep 命中任何一行，5.0 就先別升，那些檔案先標起來慢慢翻。再跑 grep -rE 'setPreferableTarget.*CUDA'——如果命中、又是即時 30fps 以上的場景，等 5.1 GPU 完整補上比較穩。剩下的情境，新專案就直接 5.0 起步，沒什麼好猶豫的。
一些第一次接觸 5.0 會踩的坑
Q1：pip install opencv-python 還是裝到 4.x，怎麼辦？
截至 2026-06-23，PyPI 上的 opencv-python 預設仍可能解到 4.13.x（4.x 仍是維護線），要顯式指定：
pip install "opencv-python>=5.0"不確定當下狀態時，先跑 pip index versions opencv-python 看一眼可用版本。或裝 opencv-python-headless（無 GUI 版，伺服器用）。
Q2：Python 端 cv2.findContours 回傳變了嗎？
沒有。4.0 已經改回 (contours, hierarchy) 兩元素，5.0 維持不變。
Q3：CUDA 加速怎麼設？
net = cv2.dnn.readNet("model.onnx")
net.setPreferableEngine(cv2.dnn.ENGINE_CLASSIC) # 走舊引擎才能 CUDA
net.setPreferableBackend(cv2.dnn.DNN_BACKEND_CUDA)
net.setPreferableTarget(cv2.dnn.DNN_TARGET_CUDA)等 5.1 之後 New engine 的 GPU 補上，這段會簡化。
Q4：VLM 推論延遲大概多少？
官方還沒公布完整 benchmark。社群初步測試（Macbook M2、PaliGemma 3B FP16）大約是「一次推論幾秒」等級，遠不到即時。對「離線批次描述影像」尚可，對「即時直播導覽」還太慢。等 GPU 補上後會大不同。
Q5：升上去後編譯時間爆增
5.0 引入了較多 C++17 template，整體編譯時間比 4.x 約增加 15–25%。可以開 ccache 或限制 WITH_OPENVINO=OFF 之類的選項減負擔。
結語：OpenCV 重新證明了自己的戰略位置
寫這篇之前我其實對 5.0 持保留態度——畢竟業界已經有 ONNX Runtime、TensorRT、vLLM、Hugging Face Transformers 這些更專業的工具，OpenCV 要把 DNN 重做、把 LLM 塞進來，會不會太貪心？
但深入讀完官方文件、看完 Satya Mallick 的簡報、跑過幾個 demo 之後，我改變了想法。OpenCV 5 並不是想取代 ONNX Runtime——它是把「從相機到 LLM 描述輸出的端到端 pipeline」做成一個函式庫。對嵌入式工程師、邊緣 AI 開發者、機器人公司來說，少裝一套依賴、少維護一個程序、少一次跨進程通訊的成本，遠比「再多一個 VLM 框架」更重要。
更深一層的訊號是——一個 26 歲的開源函式庫，敢在 4.x 已經很穩定的情況下重寫核心引擎、改變最低 C++ 標準、把 LLM 納進來，本身就證明這個社群還有活力。很多老專案最後死於「不敢改」，OpenCV 用 5.0 證明它不在那個名單裡。
接下來幾個值得追的方向：
- 5.1 的 GPU backend 完整補上後，VLM 邊緣推論才會真正可用
- OpenCV Enterprise（路線圖提到的商業版）會不會改變開源節奏
- OpenCV 5 + RISC-V 在中國本土晶片上的實測效能
- Diffusion model 支援（5.0 已預告）對 generative CV 應用的影響
具體建議是這樣：純研究或新專案用 Python，今天就跑 pip install "opencv-python>=5.0"；既有 4.x C++ 專案，先把 grep 跑過再決定升不升；嵌入式或 RISC-V 開發者，5.0 的 HAL 重構對你來說是免費效能升級，能跳就跳；重度 CUDA 推論場景，5.1 補上 New engine GPU 之前先別動。
延伸閱讀
- OpenCV 5 - GitHub Wiki（官方） —— 完整 release notes 與 migration guide
- OpenCV 5.0 brings LLMs to the Computer Vision Library - heise online —— 技術解析
- The New OpenCV 5.0 - Satya Mallick 簡報 —— CEO 視角的完整變更說明
- OpenCV Change Logs —— 完整版本歷史
- OpenCV 5 release page —— 官方 landing page
- Vision Language Models - OpenCV.org —— VLM 架構介紹
- OpenCV DNN Module Guide - LearnOpenCV —— DNN 模組使用
