OpenCV3 cv::compare()详解：从像素循环到高效掩膜生成

写这篇文章的起因很简单：我最初做图像处理项目时，遇到“把图像里亮度大于某个值的像素挑出来”这类需求，第一反应总是写双重for循环，一张 640×480 的小图还好，一旦换成 2000 万像素的工业相机图，那段循环直接变成性能瓶颈。后来翻 OpenCV3 的文档，才发现cv::compare()就是专门干这个的——一句话，把元素级比较变成矢量化操作，输出一张 0/255 的掩膜图（mask），参数简单到一眼能看懂，但很多人容易忽略它的类型约束和边界语义。

这篇东西写给刚接触 OpenCV3 的读者，也写给那些已经用了一段时间、但习惯用threshold()或inRange()绕路的人。我会把这函数的原理、六个算子的差异、调用形态、实际代码和踩过的坑一次性讲清楚。

1. 为什么我后来把所有像素循环都换成了 compare

1.1 暴力循环与 compare 的差距

先看一段最典型的“新手写法”。假设我想生成一张掩膜，标记出灰度图中所有像素值大于 128 的点：

cv::Mat src = cv::imread("image.jpg", cv::IMREAD_GRAYSCALE); cv::Mat mask(src.size(), CV_8UC1, cv::Scalar(0)); for (int y = 0; y < src.rows; y++) { for (int x = 0; x < src.cols; x++) { if (src.at<uchar>(y, x) > 128) { mask.at<uchar>(y, x) = 255; } } }

这段代码逻辑没错，但问题很多。at<uchar>()本身带边界检查，每个像素调用一次是额外开销；循环是单线程的，CPU 的多核能力完全没用上；代码量还长，读起来要花两秒钟才明白意图。换成cv::compare()：

cv::Mat src = cv::imread("image.jpg", cv::IMREAD_GRAYSCALE); cv::Mat mask; cv::compare(src, 128, mask, cv::CMP_GT);

四行解决，mask自动创建为单通道CV_8U类型，满足条件的像素填 255，不满足的填 0。运行效率上，OpenCV 内部把这种逐元素操作做了底层优化，某些 Build 还会启用多线程并行。我实测过一张 4000×3000 的图，compare版本比朴素循环快 10 到 20 倍，具体取决于编译时是否开启了 SIMD 优化。

1.2 为什么 OpenCV3 要单独设计这样一个函数

有人会问：已经有了cv::threshold()，为什么还要compare()？这里的关键差异在于threshold()只能做“图像与固定标量”的比较，它本质是阈值化工具；而compare()支持的比较对象分两种——标量（Scalar）和另一张同尺寸同类型的矩阵（cv::Mat）。也就是说，你可以用compare()实现“两帧图像变化检测”“图像与背景模型比较”这类threshold()根本做不了的事。

另外，compare()的输出天然就是掩膜，这个掩膜可以作为cv::bitwise_and()、cv::bitwise_or()等位运算的输入，也可以传给cv::mean()做区域统计。可以说它处在“像素级判断”和“区域级逻辑”之间的一座桥上，理解了这一点，你写图像处理流水线的时候思路会清晰很多。

2. 六个算子的语义差异，一张表格看懂

cv::compare()的函数签名是：

void cv::compare( InputArray src1, InputArray src2, OutputArray dst, int cmpop );

其中cmpop有六个可选值，定义在opencv2/core/cuda_types.hpp或opencv2/core/base.hpp中，对应关系如下：

不满足条件时，对应像素一律置 0。这六个算子覆盖了所有常规比较需求，输出只有两种像素值：0 和 255。为什么 OpenCV3 选择用 255 而不是 1 来表示“真”，这是为了后续位运算方便——255 的二进制是11111111，和任意掩膜做bitwise_and时可以完整保留另一张图的对应区域，而如果用 1 表示真，和CV_8U图像做位运算时经常会丢失信息，这是初学者很容易忽略的一个细节。

结合我自己的经验，六个算子中最容易混淆的是CMP_GE和CMP_GT的边界处理。比如判断“像素值是否大于 128”，你应该用CMP_GT；判断“是否不小于 128”，用CMP_GE。OpenCV3 的Mat表达式重载（比如src > 128）内部调用的就是对应的 compare 实现，语义完全一致，注意别把src > 128写成src >= 128.0001这种绕弯子的写法，没必要。

3. 三种调用形态和完整可运行示例

3.1 图像与图像：逐像素比较两幅图

这是compare()最常用的形态，特别适合做“变化检测”。我举个例子：摄像头固定机位，隔一段时间采集一帧背景图bg，再用当前帧current和背景做逐像素比较，从而得到运动区域掩膜。

#include <opencv2/opencv.hpp> #include <iostream> int main() { cv::Mat bg = cv::imread("background.png", cv::IMREAD_GRAYSCALE); cv::Mat current = cv::imread("current.png", cv::IMREAD_GRAYSCALE); if (bg.empty() || current.empty()) { std::cerr << "image load failed" << std::endl; return -1; } // 两图尺寸/类型必须一致，否则会抛异常 cv::Mat diffMask; cv::compare(bg, current, diffMask, cv::CMP_NE); cv::imwrite("diff_mask.png", diffMask); return 0; }

这里CMP_NE会把两幅图所有亮度不一样的像素点置为 255。要注意的是，这样的掩膜会包含所有噪声像素，所以实际项目中通常不会直接用原始帧做比较，而是先对图像做滤波降噪，或者配合形态学开闭操作去掉离散噪点。后面第四节我会专门说这个坑。

3.2 图像与标量：从单阈值到复杂条件的过渡

当src2传入一个cv::Scalar时，比较操作是逐通道进行的。对于灰度图，这没什么可说的；对于彩色图，我的建议是不要直接用compare()处理多通道，原因后面会讲，这里先给一个灰度图与标量比较的完整例子：

cv::Mat gray = cv::imread("gray.png", cv::IMREAD_GRAYSCALE); cv::Mat brightMask; cv::compare(gray, 100, brightMask, cv::CMP_GT);

另外，Scalar 的通道数和你传入的图像通道数必须匹配。比如三通道图像配合cv::Scalar(100, 150, 200)，逐个通道比较；如果你只传一个值cv::Scalar(100)，OpenCV3 会把剩下的通道按 0 处理，这往往不是你想要的结果。

3.3 配合split()处理多通道图像

刚才提到不要直接用compare()处理彩色图，原因在于结果掩膜是单通道的，当三通道图中三个通道的像素分别比较后，OpenCV3 对“该像素最终是否为真”的处理方式在版本间不够明确，我测试时也遇到过不同版本行为不一致的情况。最稳妥的做法是先拆通道，分别比较，再按自己的业务需求合并：

cv::Mat bgr = cv::imread("color.png"); std::vector<cv::Mat> channels; cv::split(bgr, channels); // channels[0]: B, channels[1]: G, channels[2]: R cv::Mat maskB, maskG, maskR; cv::compare(channels[0], 80, maskB, cv::CMP_GT); cv::compare(channels[1], 80, maskG, cv::CMP_GT); cv::compare(channels[2], 80, maskR, cv::CMP_GT); cv::Mat mask; cv::bitwise_and(maskB, maskG, mask); cv::bitwise_and(mask, maskR, mask);

这样逻辑明确：mask表示“B、G、R三个通道同时大于 80”的像素位置。如果你想要“任一通道大于 80”，把bitwise_and换成bitwise_or即可。这条经验帮我避开了很多莫名其妙的“掩膜不对”的调试时间。

4. 参数类型与尺寸约束：常见的坑和规避方式

4.1 尺寸、类型必须一致（否则运行时崩溃）

src1和src2同为cv::Mat时，它们必须满足：尺寸相同、类型相同、通道数相同。违反任何一条，compare()会直接抛出cv::Exception，而不是返回错误码。这一点在工程里很坑，因为很多图像来源不同（摄像头帧率不同、图像解码后格式变化），调试时往往一眼看不出来。

我自己的习惯是在调用前加一个断言：

CV_Assert(bg.size() == current.size()); CV_Assert(bg.type() == current.type());

CV_Assert在 Debug 模式下能把问题暴露得很早，避免程序在中间某个看不到的地方崩掉。

4.2 dst 的自动分配与手动分配差异

cv::compare()会自动根据src1的尺寸创建dst，类型固定为CV_8U（单通道、无符号 8 位）。关于这一点，官方文档的表述是：“如果 dst 尚未分配，函数会为其分配合适的内存。”但如果你提前手动声明了dst，请务必指定类型为CV_8U或CV_8UC1。

有一种很常见的错误写法：

cv::Mat mask = cv::Mat::zeros(src.size(), CV_32FC1); cv::compare(src, 100, mask, cv::CMP_GT); // 运行时报错

因为dst类型不是CV_8U，会比较逻辑不一致而报错。所以最简单的做法就是不要手动分配，直接cv::Mat mask;，让函数自行处理。

4.3 多通道图像时 dst 的单通道限制

前面说了，compare()的dst一定是单通道。如果你需要生成一张和三通道彩色图同样尺寸的彩色掩膜（比如每个通道保留各自的比较结果），就必须借助split()/merge()，或者使用cv::Mat::forEach自定义逻辑。这是我实际项目里遇到的第二个高频问题——很多初学者期望compare()输出一张三通道图，结果发现输出是单通道的，然后就去上网查资料，白白浪费半天时间。

4.4 浮点型图像与 NaN 的问题

当src1是CV_32F或CV_64F浮点图像时，比较运算遵循 IEEE 754 标准。注意CMP_EQ对浮点数的“精确相等”判断非常严格，两个浮点结果如果只是数值上极近但不同，也会被判为不相等。如果你要做浮点掩膜，一般建议先用cv::absdiff()得到差值，再和一个小阈值epsilon用CMP_LE比较，这样可以容忍微小的数值波动。

顺带一提：如果图像里有NaN像素，比较结果可能不符合直觉，NaN > x和NaN < x永远为假，只有NaN != x为真。这很容易让人排查半天，但实际工作里很少遇到，知道有这回事就行。

5. 从 mask 到业务逻辑：组合使用的几种经典场景

5.1 提取灰度区间：两个 compare 加一次 bitwise_and

compare()单个算子只能表达一个方向上的比较，比如“大于 100”或“小于 200”。但实际我们经常要提取“亮度在 100 到 200 之间”的区间，这时需要两个比较掩膜叠加：

cv::Mat gray = cv::imread("gray.png", cv::IMREAD_GRAYSCALE); cv::Mat maskLow, maskHigh, maskInterval; cv::compare(gray, 100, maskLow, cv::CMP_GT); // > 100 cv::compare(gray, 200, maskHigh, cv::CMP_LE); // <= 200 cv::bitwise_and(maskLow, maskHigh, maskInterval);

这里我刻意选了CMP_GT和CMP_LE，分别对应开区间左端和闭区间右端，你可以根据业务需求调整边界算子的选择。看起来很基础，但实际代码评审时发现不少同事喜欢用三次threshold再加一次逻辑操作，反而更绕。

5.2 用 compare + mask 实现动态 ROI

还有一种很有意思的用法：先用compare()生成一个覆盖“感兴趣区域”的掩膜，然后用cv::mean()统计这个区域内原始图的平均灰度。比如做文档扫描时，检测到某个局部区域颜色异常，可以用这种方法自动定位问题区域：

cv::Mat gray = cv::imread("doc.png", cv::IMREAD_GRAYSCALE); cv::Mat mask; cv::compare(gray, 200, mask, cv::CMP_GT); // 找高亮部分 cv::Scalar avg = cv::mean(gray, mask); // 只统计高亮区域 std::cout << "Highlight area mean: " << avg[0] << std::endl;

mask在这里既是比较结果，又是mean()函数的掩膜参数，一举两得。这种组合让代码不需要显式遍历任意形状的区域，性能和解耦性都更好。

5.3 二值掩膜与copyTo()结合做目标抽取

另一个高频场景是从原图中抽取满足条件的子区域：

cv::Mat img = cv::imread("color.png", cv::IMREAD_COLOR); cv::Mat gray; cv::cvtColor(img, gray, cv::COLOR_BGR2GRAY); cv::Mat mask; cv::compare(gray, 150, mask, cv::CMP_GT); cv::Mat result; img.copyTo(result, mask); // 背景区域保持为 0，前景区域保留原图

copyTo()的第二个参数就是掩膜，正好和compare()的输出格式无缝衔接。项目里很多“只处理感兴趣部分”的需求，本质上就是这句话背后的逻辑。

6. 性能、版本差异与我的调试习惯

6.1 实测过程中性能能提升多少

我手头一个老项目用的是 OpenCV 3.4.x，编译器是 MSVC 2015，实测 4000×3000 的灰度图像，用朴素循环做> 128的掩膜生成，耗时大约 40ms 到 60ms；换成cv::compare()后耗时在 2ms 到 3ms 左右。这中间除了算法本身的优化，还因为 OpenCV3 在高分辨图像上会启用多线程分块处理。如果你的项目里掩膜生成是流水线里的高频操作，这是一笔非常划算的优化。

6.2 OpenCV3 到 OpenCV4：几乎一样的接口，但小细节有差异

从 OpenCV3 到 OpenCV4，cv::compare()的核心接口基本没变，参数语义也一致。我注意到的小差异主要在头文件位置和部分文档说明的完善上，另外有些 Build 对Scalar的隐式类型转换处理更严格。如果你在 OpenCV4 里编译旧代码遇到报错，优先检查传入的标量类型是否和图像类型一致，尤其是整数和浮点的混用。时间充裕的话，建议直接用 OpenCV4 新写的代码，毕竟 OpenCV3 已经停止维护很久了；但如果你还在维护老项目，这篇内容仍然适用，因为核心函数行为没有变。

6.3 我的调试小习惯：把中间 mask 存出来看

最后分享一个使用compare()时的调试方法：凡是生成掩膜的关键节点，我都会先用cv::imwrite()把 mask 存成 PNG，再快速用看图软件扫一眼。因为掩膜只有 0 和 255 两种值，一旦某些像素在你预期之外被点亮，马上就能发现问题出在算子选错、阈值方向反了，还是图像通道没对齐。这个方法看起来原始，却帮我节省了大量断点调试时间。另一个习惯是打印mask的非零像素比例，用cv::countNonZero(mask)除以总像素数，可以快速验证你的业务阈值是否合理，避免闹出“整张图全是 255”这种笑话。

OpenCV3 的cv::compare()就是这样一个看起来过于简单、实际却能撬动许多功能的函数。你把六个算子、两种调用形态、掩膜组合逻辑这几板斧练熟，很多图像预处理任务都会顺手很多。真要用它做复杂业务，建议先把自己的图像类型、通道数和边界条件理清楚，再动手，比拿着示例代码硬改要省事得多。