★ FEATURED ARTICLE 第一次用 OpenCV 读图片的时候我做的最顺手的一件事就是把它丢给 matplotlib 去显示。结果原本正常的照片变成了“阿凡达”滤镜天空是橙红色的叶子是紫红色的人脸像是刚从煤堆里爬出来。我当时一度怀疑是自己的显卡出了问题折腾了很久才发现问题出在 BGR 和 RGB 两个通道顺序上。这个系列叫“OpenCV 从入门到入土”第零章我打算不急着写代码而是把这些年我总结出来的、教科书上确实写了但几乎没人会特意提醒你的视觉基础一次性讲透图片在内存里到底长什么样、颜色为什么会被 OpenCV 倒着存、视频里那一帧一帧到底是怎么回事。适合所有刚打开 OpenCV、或者已经被各种诡异颜色和报错坑到怀疑人生的朋友看完这一章后面踩坑的概率会小很多。1. 图片的真相一个藏在内存里的数字矩阵1.1 一张图片是怎么变成矩阵的OpenCV 眼里没有“图片”这个概念它只认矩阵。说得更直白一点一张彩色图片在内存里就是一个三维数组维度分别是高、宽、通道数。灰度图更简单就是一个二维矩阵矩阵里每个元素的值代表这个像素的亮度。举个例子一张 1920x1080 的彩色图片用 OpenCV 读进来之后它的 shape 是(1080, 1920, 3)。注意这个顺序第一个数字是高度行数第二个数字是宽度列数第三个是通道数。很多人一看(1080, 1920, 3)就以为是宽 1080、高 1920这会让后面的坐标计算全部乱套。我自己的习惯是每次读完图片第一时间在代码里打印img.shape和img.dtype。这两个值是后续所有操作的基石。dtype通常是uint8也就是无符号 8 位整数取值范围 0 到 255。为什么是 255因为一个字节有 8 个 bit能表示 2 的 8 次方也就是 256 个值从 0 数到 255。每个像素在每个通道上用一个字节来存一张 1080p 的三通道图片光原始数据就要 1080 * 1920 * 3 个字节大概 6MB。1.2 坐标方向先 y 后 x和数学课上的习惯正好相反这是初学者最容易懵的地方。在高中的坐标系里我们习惯用(x, y)表示一个点x 是水平方向y 是垂直方向。但 numpy 和 OpenCV 处理图像时高度在前、宽度在后所以访问像素的写法是img[y, x]。比如我想读取图像正中央那个像素的颜色应该写成img[img.shape[0] // 2, img.shape[1] // 2]而不是img[x, y]。写反了不会报错程序会正常运行但读出来的像素完全不是你想要的。这种错位 bug 是隐性的排查起来特别费时间因为代码看起来哪里都没问题。我曾经写过一个人脸检测程序用img[w, h]去修改像素画框结果画的框全都歪掉了原因就是我把w和h对调了。排查到最后的感受就是这两个字母的顺序真的能让人一夜回到解放前。1.3 用 numpy 造一张图从零开始搞定像素操作理解矩阵最快的方式是自己动手造一张图。下面这段代码可以生成一张纯黑色的图然后在中间区域画一个白色矩形import numpy as np import cv2 # 生成一张 300x400 的彩色图纯黑色三通道 img np.zeros((300, 400, 3), dtypenp.uint8) # 把 x100, y50 到 x300, y200 的区域填成白色 img[50:200, 100:300] [255, 255, 255]看到img[50:200, 100:300]了吗第一个切片是行方向也就是纵向范围对应 y 坐标第二个切片是列方向对应 x 坐标。我建议所有初学者都亲手跑一下这段代码然后打印img.shape再试试访问img[0, 0]看看返回的像素值。这个练习花不了两分钟但对理解“图像是矩阵”这件事比看十篇教程都管用。1.4 uint8 溢出255 加 1 等于多少很多人处理图像时会直接用 numpy 的算术运算比如img 50来提升亮度。这在视觉上可能没问题但对像素值本身来说已经埋下了隐患。uint8是有取值范围的当计算结果超过 255 时numpy 不会报错而是发生了取模溢出。255 加 1 会变成 0254 加 5 会变成 3。也就是说你越是想把图片调亮过亮的部分反而会变成黑色或出现奇怪的条纹。反过来0 减 1 会变成 255这同样不符合直觉。正确的做法是使用 OpenCV 提供的cv2.add()函数它在溢出时采用饱和处理超过 255 就固定为 255低于 0 就固定为 0。bright_img cv2.add(img, np.array([50, 50, 50])) # 饱和加法在刚开始学习阶段这个坑可能不那么明显因为视觉误差不容易被注意。但当你开始做图像差分、背景建模、直方图统计这类对数值敏感的算法时溢出的影响会瞬间放大。所以我现在只要涉及图像像素级的加减法一律用cv2.add和cv2.subtract而不是直接写和-。2. BGR 和 RGB为什么一张好好的照片换个显示方式就变成了“阴间配色”2.1 为什么 OpenCV 要把三个通道倒过来存提到颜色绕不开一个几乎每个新手都会撞上的大坑OpenCV 读入彩色图片后通道顺序是BGR也就是蓝、绿、红而不是我们熟悉的 RGB红、绿、蓝。先说结论如果你用cv2.imread()读图然后用cv2.imshow()显示颜色是正常的因为imshow按同样的 BGR 顺序解析数据。问题出在跨库协作时你把 OpenCV 的图直接交给 matplotlib 的plt.imshow()matplotlib 默认按 RGB 解析红色和蓝色通道被互换画面自然就变成蓝绿调了。至于 OpenCV 为什么用 BGR说法很多大体上和早期相机硬件、图像采集设备以及旧文件格式的字节序习惯有关。简单理解就是这个顺序是历史遗留约定大家用习惯了就成了事实标准。别纠结对错记住即可。2.2 症状识别哪些场景颜色会变成“阴间配色”为了让你快速判断自己是不是掉进了 BGR/RGB 陷阱我把常见症状整理成一张表你做了什么你看到了什么原因cv2.imread()后用plt.imshow()天空偏橙、草地偏紫像换了个星球matplotlib 按 RGB 解析了 BGR 数据从 PIL 读图直接交给 OpenCV 处理画面整体蓝绿异常PIL 默认 RGB 模式OpenCV 需要 BGR用cv2.imwrite()保存一张来自 matplotlib 的 RGB 图保存下来的图偏色保存接口默认数据是 BGR这个症状太典型了以至于现在我看到“图片颜色不对偏蓝偏紫”的提问第一个反应就是通道顺序问题。2.3 通道顺序的统一一套防呆的转换流程解决方案很简单用cv2.cvtColor()在两种通道顺序之间切换import cv2 import matplotlib.pyplot as plt img_bgr cv2.imread(photo.jpg) img_rgb cv2.cvtColor(img_bgr, cv2.COLOR_BGR2RGB) plt.imshow(img_rgb) plt.show()反过来如果你拿到的是 RGB 图要传给 OpenCV 处理就执行cv2.cvtColor(img, cv2.COLOR_RGB2BGR)。我的经验是在一个项目里通道顺序必须形成统一约定。比如我自己的习惯是所有图像处理全部在 BGR 下进行只有最后需要交给 matplotlib 或其他可视化库时才转成 RGB。这样整个流程只需要在“出口”处转换一次而不是到处来回切。2.4 其他被 BGR 坑到的地方摄像头、imshow 和深度学习预处理BGR 的影响不止在imread很多地方是隐性的摄像头读出的每一帧同样是 BGR 格式。用摄像头采集数据时显示正常是因为imshow按 BGR 解析但如果要把帧保存成数组喂给某个按 RGB 训练的模型就必须转一次。深度学习预处理环节很多框架默认输入是 RGB。如果你直接拿 BGR 帧进网络即使模型精度正常结果也会受到影响。最典型的表现是迁移学习中图像的颜色语义出现偏差。cv2.split()出来的三个通道顺序是 B、G、R不是 R、G、B。这一点我一开始也没注意等到调试通道统计时才被坑了一次。一个很实用的检查方法读一张人像照打印左上角第一个像素的值。如果是红色衣服或红色背景看看这个像素的第三个通道是不是明显大于第一个通道。如果是说明你的数据确实按 BGR 存储。3. 颜色空间想框出“红色”为什么 HSV 比 RGB 靠谱一百倍3.1 RGB 为什么不适合做颜色分割假设你要在一幅画面里把一辆红色汽车框出来最简单粗暴的想法是把 RGB 里红色通道值高、并且其他通道值低的像素归为“红色”。听起来很有道理实践起来会让你怀疑人生。原因在于RGB 的值受光照影响太大。同一辆红色汽车在阳光下和在阴影里它的 RGB 数值可能差出一大截。下午四点拍的红色车门数值可能比早上八点拍的红砖墙更像“标准红”。你辛辛苦苦调整的阈值换个场景就失效了。所以做颜色分割时更推荐把图像转换到 HSV 颜色空间再进行阈值筛选。3.2 HSV 的直觉理解选色、兑水、调明暗HSV 从人的感知方式来描述颜色拆成三个分量HHue色相决定颜色种类比如红、绿、蓝。SSaturation饱和度决定颜色浓不浓。饱和度越高越鲜艳越低越接近灰色。VValue明度决定亮不亮。明度越高越接近白色越低接近黑色。用画水彩来类比你先在调色盘上挑一种颜料这是色相再决定加多少水把它稀释这是饱和度最后看房间光线亮不亮这是明度。RGB 回答的是“屏幕怎么显示它”HSV 回答的是“人眼怎么看它”。3.3 实操用 inRange 抓出一大块红色假设我要在一张图片里提取所有红色物体流程是这样import cv2 import numpy as np img cv2.imread(scene.jpg) hsv cv2.cvtColor(img, cv2.COLOR_BGR2HSV) # 红色有两个区域H 在 0-10 附近以及 170-180 附近 lower_red1 np.array([0, 80, 50]) upper_red1 np.array([10, 255, 255]) lower_red2 np.array([170, 80, 50]) upper_red2 np.array([180, 255, 255]) mask1 cv2.inRange(hsv, lower_red1, upper_red1) mask2 cv2.inRange(hsv, lower_red2, upper_red2) mask cv2.bitwise_or(mask1, mask2) result cv2.bitwise_and(img, img, maskmask)cv2.inRange()的作用是输入一个数组返回一个只含 0 和 255 的掩膜图落在阈值范围内的像素变成白色255否则变成黑色0。之后用bitwise_and配合掩膜就能把原图中非红色区域“过滤”掉。3.4 OpenCV 里 HSV 的 H 只有 0-179以及红色分裂问题这里有一个专门为新手指路的细节在不少教程里H 范围是 0 到 360S 和 V 范围是 0 到 100。但 OpenCV 为了把 H 压缩进单个字节把角度减半保存所以H 的范围是 0 到 179S 和 V 在uint8下是 0 到 255。这会导致一个反直觉的现象红色在色相环里是 0 度位置在 OpenCV 的 H 里是 0但你把阈值从 0 设到 179 的时候会发现红色分布在两段0 到 10 附近以及 170 到 180 附近。所以提取红色时要么用两个区间分别做掩膜再合并要么把区间设计成 [170, 180] 和 [0, 10] 的组合。我第一次做红色提取时只写了[0, 10]结果漏掉了整片暗红色区域后来才知道是色相环首尾相接导致的。调 HSV 阈值时我强烈建议不要在代码里盲猜。我的做法是先写一个小窗口用鼠标点击图像上的目标区域打印出该像素的 HSV 值再根据这些值设计阈值区间。几次之后你就能找到合适的范围然后把阈值参数单独提取到配置文件里方便反复调。4. 帧与 read()视频处理里那些绕不开的循环和卡顿4.1 视频的本质一串带着时间属性的图片视频说白了就是一连串按顺序播放的图片每一张叫一帧。帧率fps表示每秒显示多少帧常见的是 24、30、60。OpenCV 处理视频的方式非常朴素循环读取每一帧对每一帧做图像处理处理完再显示或保存。也就是说前几章学的所有图像知识在视频帧上全都适用。用 OpenCV 读取视频或摄像头的标准流程是cap cv2.VideoCapture(0) # 0 表示摄像头传文件路径则打开视频文件 if not cap.isOpened(): print(无法打开视频源) exit() while True: ret, frame cap.read() if not ret: break # 在这里对 frame 做处理 cv2.imshow(frame, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()4.2 read() 的返回值为什么必须先判断 retcap.read()返回两个值ret是一个布尔值表示是否成功读到一帧frame是这一帧的图像数据。当视频播放到结尾或者摄像头断连时ret会变成False此时frame通常是None。很多人会在循环里跳过ret判断直接对frame做处理。一旦读到结尾frame是空值各种NoneType object has no attribute shape报错就会冒出来。这不是什么复杂问题但初学者经常被吓到。我的习惯是只要ret不为真立刻break绝不多做任何操作。4.3 摄像头卡顿和缓冲区read() 并不总是按你的想法工作文件视频是按顺序读的摄像头则是实时采集两者体验完全不同。摄像头模式下read()拿到的帧来自内部缓冲区。如果缓冲区满了新帧可能无法及时进入你读到的画面就会明显滞后。有时候你明明在移动摄像头屏幕上显示的还是两秒前的画面看起来就像“卡住了”。针对这个问题可以尝试调整缓冲区大小cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 减少缓冲帧数降低延迟这个设置在 Windows 上通常有效在其他平台上不一定生效但值得一试。另外降低分辨率也能有效缓解摄像头延迟毕竟每一帧要处理的数据量少了整体管线吞吐就快了。如果只是为了预览或简单检测把分辨率设到 640x480 足够用了。4.4 waitKey 与帧率控制窗口为什么“点一下才刷新”cv2.waitKey(n)是视频循环里另一个容易让人困惑的函数。它的作用是等待 n 毫秒同时让窗口事件循环处理键盘输入。没有这一步imshow出来的窗口可能会卡成静止状态看起来完全无响应。代码里常写的if cv2.waitKey(1) 0xFF ord(q): break有两点需要注意。第一waitKey(1)会让循环每帧停顿 1 毫秒这样才能让高帧率视频“慢下来”看起来正常播放。如果不加或参数太大要么画面飞闪要么明显卡顿。第二 0xFF的作用是提取返回值低 8 位的按键字符因为waitKey返回的可能是带高位标志的整型值。把按键值和ord(q)比较按下q键就退出循环。如果你要精确控制视频播放速度比如每帧停留 33 毫秒模拟 30fps直接用waitKey(33)就行。注意人眼对单个帧的细微延迟并不敏感所以几十毫秒的误差无伤大雅不用去精算每帧睡眠时间。5. 图像的内存与判等浅拷贝、视图和 np.array_equal 这些细碎却致命的坑5.1 等号不是复制视图、引用和 copy()Python 的赋值操作很多时候只是在变量之间传递引用对 numpy 数组来说尤其如此。看下面这段代码img1 cv2.imread(photo.jpg) img2 img1 img2[200:300, 200:300] [0, 0, 255]执行完img2的修改后img1对应区域也变成了红色。因为img2和img1指向的是同一块内存没有复制数据只是复制了引用。很多人在视频处理中会踩这个坑第一帧放进一个列表第二帧读到之后发现第一帧也跟着变了。原因就是列表里存的始终是同一个对象的引用后续帧把内存里的数据覆盖了。解决方法是在存帧时使用.copy()frame_copy frame.copy()另外numpy 的切片通常返回视图view而不是副本。比如roi img[100:200, 100:200]修改roi会直接影响img。这在某些场景下是优点比如想直接修改原图局部区域时很方便但如果你想把roi当作独立图像处理请先.copy()。5.2 判等不要用 np.array_equal 与全零判断图像本身就是数组判断两张图是否相同直接用会得到一个布尔数组而不是一个布尔值。如果你把它放到if条件里会报ValueError。更合理的方式是使用np.array_equal(img1, img2)它在结构、形状、数值完全一致时返回True。如果你只是想判断一张图是否全黑可以用cv2.countNonZero(gray_img) 0。如果是彩色图先转灰度再数量统计。这个小技巧在处理视频时很有用比如检测黑屏帧。在处理视频帧缓存时我还遇到过一个隐蔽问题比较帧和前一帧是否相同用np.array_equal确实能判断但速度较慢。追求实时性的话可以先用尺寸和hash粗筛减少高频比较的开销。不过这是后话先用对再说。5.3 不连续内存切片、ROI 和偶尔冒出来的报错对图像做切片之后数据的行之间在内存里可能不再连续。有些 OpenCV 函数对连续内存有要求遇到不连续数据时会直接报错。最常见的提示是“Image data is not contiguous”。解决办法有两条一是用roi.copy()把切片复制成连续数组二是用np.ascontiguousarray(roi)生成连续内存视图。我个人的习惯是一遇到这类报错优先加.copy()因为它语义明确而且能顺手避免前面提到的引用串改问题。5.4 帧循环里的内存陷阱上一帧被下一帧悄悄改掉最后分享一个我印象深刻的排错经历。写一段视频处理程序想在画面里检测一个运动物体并把物体的历史位置画在图上。我用一个列表保存每一帧的检测结果图像结果发现所有保存的图像最终都是最后一帧的样子列表里所有元素都指向了同一个最终状态。问题根源就在帧对象复用。cap.read()在每次循环时可能复用同一块内存存储新帧数据。如果我用frame_list.append(frame)而不是frame_list.append(frame.copy())那么所有列表项都指向被反复覆盖的同一块内存最后一帧自然覆盖了所有记录。从那以后我给自己定了一条规矩只要需要跨越循环保存任何图像数据立即.copy()不要偷懒。这条规矩让我后续再也没有被这类问题困扰过。最后再分享一点个人体会。很多人学 OpenCV 时喜欢直接冲深度学习或目标检测觉得图像基础枯燥。但事实证明90% 的诡异 bug 都出在这些基础细节上BGR 和 RGB 的转换漏了一次一张图就废了ret没判断视频一跑就崩copy()没加历史帧全被覆盖。这篇文章里提到的每个坑我都亲眼见过不下十次自己也都逐一踩过。如果你此刻正被某个“玄学”问题折磨不妨先回到这些基础上去排查大概率能省下好几个晚上。
阅读完成 · 觉得有帮助？
