简介面向计算机视觉初学者与自动驾驶相关开发者的 OpenCV 车道实时检测示例代码完整演示了从视频逐帧读取、按文件名排序、灰度化到创建多边形掩码并提取感兴趣区域再到二值阈值化和霍夫线变换检测直线的典型处理流程。文档重点解释了 cv2.bitwise_and 掩码运算、cv2.threshold 阈值设置、cv2.HoughLinesP 的 rho、theta、threshold、maxLineGap 等参数含义并说明如何通过 cv2.VideoWriter 将标注后的帧重新合成视频最终获得带实时车道标记的输出结果。代码中利用 tqdm 显示进度、使用 try 语句容错也体现了实际工程中的处理细节。资源为单个 PDF 文档共 194KB内容直观适合边读边动手实现。目前已有 307 人学习下载是快速入门 OpenCV 车道线识别的实用材料。文中还提到可引入 Canny 边缘检测或卷积神经网络进一步提升检测精度并在原代码基础上预留了改进空间适合在此基础上继续做算法优化或移植到自己的项目中。1. 车道实时检测没有想象中神秘一份能直接跑通的OpenCV示例代码问OpenCV车道实时检测怎么做的人一半是准备毕设一半是刚进自动驾驶或ADAS相关岗位。听到“车道检测”第一反应是上深度学习YOLO、语义分割一套组合拳其实在固定机位的行车记录仪场景里OpenCV传统的图像处理链路——灰度化、掩码提取、阈值二值化、霍夫线变换——就够用了。这份示例代码正是这么一套完全不依赖GPU的方案输入道路视频的拆帧图片输出画好车道线的标注视频每一步都有可视化中间结果适合在地面跑通第一个视觉闭环。适合刚接触视觉处理的学生也适合想快速验证霍夫变换和ROI掩码工程效果的工程师。动手前先确认环境命令行执行pip list | grep opencv能看到opencv-python版本再往下走省得import cv2第一步就翻车。2. 预处理链路先把路“框”出来帧读取、灰度化与ROI掩码2.1 视频帧读取与文件名排序先拿到能处理的图片序列这段代码把frames/文件夹下的所有图片读进来按帧名里的数字排序顺序不能乱。import os import re import cv2 import numpy as np from tqdm import notebook import matplotlib.pyplot as plt col_frames os.listdir(frames/) col_frames.sort(keylambda f: int(re.sub(\D, , f))) col_images [] for i in notebook.tqdm(col_frames): img cv2.imread(frames/ i) col_images.append(img)os.listdir返回的文件名顺序是不固定的直接 sort 会按字典序排frame_100.jpg会排到frame_2.jpg前面。这里的sort用了一个关键处理re.sub(\D, , f)把文件名里所有非数字字符删掉[frame_002.jpg, frame_100.jpg]变成[002, 100]再int()转成数字排序保证视频帧按真实拍摄顺序排列。tqdm.notebook用来显示读取进度图片在 Jupyter 里处理时能直观看到还剩多少张。cv2.imread默认按彩色三通道读入所以col_images里每张图都是一个(height, width, 3)的 uint8 数组后续取灰度通道用[:,:,0]就行。2.2 创建掩码为什么ROI用梯形而不是矩形车道在图像里是近宽远窄的梯形直接画矩形会把路肩、对向车道和天空都包进来后面阈值化和霍夫变换会检出一堆干扰线。所以掩码区域用多边形框定。idx 457 stencil np.zeros_like(col_images[idx][:,:,0]) polygon np.array([[50,270], [220,160], [360,160], [480,270]]) cv2.fillConvexPoly(stencil, polygon, 1)col_images[idx][:,:,0]取出第 457 帧的灰度通道np.zeros_like生成一张和它尺寸完全相同的全 0 矩阵作为掩码底图。polygon里四个顶点是图像坐标系下的坐标(50,270)是左下角梯形左底(480,270)是右下角梯形右底中间两个点(220,160)和(360,160)是梯形上边对应远处车道变窄的位置。cv2.fillConvexPoly用 1 填充这个梯形内部于是stencil里车道区域全是 1其余区域是 0。注意这四个坐标是针对示例视频的分辨率手工标定出来的换视频必须重新标。我一般把第一帧截图到画图工具里把车道两侧边界线的交点记下来再填进去直接照抄别人的坐标大概率跑偏。2.3 bitwise_and把ROI抠出来一次看懂掩码运算掩码建好后用按位与把车道区域从整帧图里抠出来这是整个预处理里最核心的一步。masked cv2.bitwise_and(col_images[idx][:,:,0], col_images[idx][:,:,0], maskstencil)cv2.bitwise_and对两个输入逐像素做按位与。同一张图传两次是 OpenCV 里的习惯写法相当于只保留自己真正的关键在mask参数——它指定哪些位置的像素参与运算。stencil里为 1 的像素保留原灰度值为 0 的像素输出直接清零。于是掩码外的路肩、天空、对面车道全部变黑只剩梯形车道区域后续检测的干扰范围大幅缩小。参数上有一点容易踩坑mask必须和输入图同尺寸、单通道、值只能是 0 或 1。如果传进去的是一张普通灰度图而不是严格二值掩码按位与会按二进制位逐位计算产生意料之外的暗化效果画面会变成一片灰蒙蒙。2.4 阈值化把车道线从灰度里“拉”出来掩码之后是阈值化目的是让车道线像素和路面背景彻底分开。ret, thresh cv2.threshold(masked, 130, 145, cv2.THRESH_BINARY)THRESH_BINARY的规则是像素值大于 130 的置为 145小于等于 130 的置为 0。车道线比路面亮经过这一步变成亮线暗背景被清掉输出是单通道二值图。这里要特别说清一点第三个参数是maxval不是区间上界别理解成“只保留 130 到 145 之间的像素”——它是“比阈值大的所有像素都变成 145”。ret返回实际使用的阈值这里就是 130调试时可以打印出来确认。为什么用 145 而不是常用的 255对霍夫变换来说非零像素的具体数值不影响直线检测结果只要和背景有区分度就行255 和 145 效果一样。真正需要重新标定的是 130 这个阈值强光照下路面灰度经常超过 130就调到 150160阴天或隧道里调低到 100110。我一般会把掩码后的灰度图用plt.imshow看一眼再决定阈值往哪个方向调。3. 核心检测HoughLinesP六个参数逐个说清再动手画线3.1 HoughLinesP的六个参数每个参数都在控制什么霍夫线变换是整个检测链路的引擎代码里所有可调参数都在这一行lines cv2.HoughLinesP(thresh, 1.0, np.pi/180, 30, maxLineGap200)HoughLinesP是概率霍夫变换它不遍历所有边缘点而是随机采样一部分点投票效率比标准霍夫高适合实时场景。六个参数含义如下参数示例代码取值含义调大后的影响rho1.0线段距离精度单位像素精度变粗短线段可能检不到thetanp.pi/180角度精度单位弧度约 1 度角度分辨率变粗斜线拟合变差threshold30累加器投票阈值线段至少得到 30 票只保留更长更明显的线段线段数变少minLineLength未传默认 None线段最小长度None 表示不限制过滤短碎线但可能丢掉弯道处的短段maxLineGap200同方向线段合并的最大间隙单位像素把断开的同一条线连起来过大则误连相邻车道注意minLineLength在示例代码里没有传用的默认值 None也就是不限制线段最短长度。这会让一些碎石边缘、路面裂缝被当成直线检出来后面画线时会发现多了不少短横线。如果视频里这种噪声明显建议显式传minLineLength30先过滤一波短碎线。3.2 从参数到策略怎么调出稳定车道线而不是满屏短线调霍夫参数确实有点玄学但本质是投票数、线段长度、间隙容忍度三者之间的平衡。常见现象是threshold从 30 调到 10路面裂缝、阴影边缘都满足投票条件画面上全是碎线maxLineGap从 200 调到 50车道中间因为磨损断线被识别成多段画出来是虚线效果。我一般按这个顺序调先固定rho1.0、thetanp.pi/180不动只调threshold观察检测出的线段是否稳定再调maxLineGap让同一侧车道线连成完整长线最后才考虑minLineLength过滤噪声。一次只动一个参数并且用连续几十帧验证不要盯着一帧调到完美换一帧就废。车道线检测最忌讳单帧调参那叫过拟合画面不叫参数可用。3.3 把检测结果画出来坐标提取与画布选择检测到线段后要把它们画到图像上做可视化。这里有个容易忽略的细节画到灰度图上和画到彩色图上颜色表现完全不同。dmy col_images[idx][:,:,0].copy() for line in lines: x1, y1, x2, y2 line[0] cv2.line(dmy, (x1, y1), (x2, y2), (255, 0, 0), 3)HoughLinesP的返回值是三维矩阵shape 是(m, 1, 4)m是线段条数最内层四个值就是线段端点坐标。line[0]取出这条线段的x1, y1, x2, y2再交给cv2.line画线。dmy是灰度图的副本cv2.line在单通道图上画线时颜色只取 BGR 三元组第一个分量 255显示为白色线宽 3 像素。如果画到彩色帧上(255, 0, 0)就是蓝色粗线——最终合成视频时用的就是彩色版本。提示为什么先copy()再画因为HoughLinesP返回的是像素坐标直接画在原图上会污染原始帧后面想重新调参又得重新读图。调试期养成在副本上画线的习惯能省很多重读图的时间。4. 合成为视频VideoWriter的编码、尺寸与逐帧写盘4.1 VideoWriter编码格式、尺寸和帧率怎么配对所有帧处理完后要合成视频文件VideoWriter是 OpenCV 的输出出口。参数不多但尺寸和编码的坑不少。pathOut roads_v2.mp4 fps 30.0 height, width img.shape[:2] size (width, height) out cv2.VideoWriter(pathOut, cv2.VideoWriter_fourcc(*DIVX), fps, size)VideoWriter四个参数依次是输出路径、编码格式、帧率、帧尺寸。size必须写成(width, height)而 OpenCV 图像shape返回的是(height, width)正好反着。img.shape[:2]只取前两个值避开彩色图第三通道维度的干扰。编码格式由cv2.VideoWriter_fourcc决定常见组合fourcc容器扩展名特点DIVX.avi老牌组合兼容性最好示例代码默认mp4v.mp4通用 MP4大多数播放器能放XVID.avi压缩率适中调试常用MJPG.avi几乎不压缩文件大但任何环境都能写示例代码里DIVX写进.mp4在部分平台能跑在另一些平台上文件打不开或只有 0 字节。我的习惯是调试阶段用MJPG .avi确认检测效果没问题再换成mp4v .mp4出正式结果省得一路调参一路处理输出文件打不开的玄学问题。4.2 逐帧处理循环从单帧验证到批量生产单帧流程验证通过后把同样的操作套到所有帧上循环体内就是完整的检测链路。for img in notebook.tqdm(col_images): masked cv2.bitwise_and(img[:,:,0], img[:,:,0], maskstencil) ret, thresh cv2.threshold(masked, 130, 145, cv2.THRESH_BINARY) lines cv2.HoughLinesP(thresh, 1, np.pi/180, 30, maxLineGap200) dmy img.copy() try: for line in lines: x1, y1, x2, y2 line[0] cv2.line(dmy, (x1, y1), (x2, y2), (255, 0, 0), 3) out.write(dmy) except TypeError: out.write(img) out.release()循环里每帧重复掩码、阈值化、霍夫变换、画线、写盘的流程。这里dmy img.copy()用的是彩色原图副本所以最终视频里车道线是蓝色的和第 3 章灰度图上画线表现不一样。try/except TypeError是关键容错当画面里没有满足条件的直线时HoughLinesP返回Nonefor line in lines直接抛 TypeError。捕获后写入原始帧这一帧就没有车道线标注但整个视频输出不会中断。mask全程用同一个stencil隐含假设是摄像头在整个视频过程中位置固定、视角不变。如果设备有震动或位移这个假设失效掩码区域会偏离实际车道检测结果会飘。try/except不是吞异常偷懒而是“这一帧检测不到就原样写出”的容错策略——丢掉一帧的标注比中断整个视频合理得多。4.3 完整代码修正后的可运行版本把上面所有串起来就是一份可以直接运行的完整脚本import os import re import cv2 import numpy as np from tqdm import notebook import matplotlib.pyplot as plt col_frames os.listdir(frames/) col_frames.sort(keylambda f: int(re.sub(\D, , f))) col_images [] for i in notebook.tqdm(col_frames): img cv2.imread(frames/ i) col_images.append(img) # 创建固定ROI掩码 stencil np.zeros_like(col_images[0][:,:,0]) polygon np.array([[50,270], [220,160], [360,160], [480,270]]) cv2.fillConvexPoly(stencil, polygon, 1) # 输出视频参数 pathOut roads_v2.mp4 fps 30.0 height, width img.shape[:2] # 用shape[:2]而不是直接解包避免ValueError size (width, height) out cv2.VideoWriter(pathOut, cv2.VideoWriter_fourcc(*DIVX), fps, size) # 逐帧处理 for img in notebook.tqdm(col_images): masked cv2.bitwise_and(img[:,:,0], img[:,:,0], maskstencil) ret, thresh cv2.threshold(masked, 130, 145, cv2.THRESH_BINARY) lines cv2.HoughLinesP(thresh, 1, np.pi/180, 30, maxLineGap200) dmy img.copy() try: for line in lines: x1, y1, x2, y2 line[0] cv2.line(dmy, (x1, y1), (x2, y2), (255, 0, 0), 3) out.write(dmy) except TypeError: out.write(img) out.release() print(done, check roads_v2.mp4)相比网上流传的版本这里做了一个必要修正height, width img.shape[:2]。原因是加载帧循环结束后img是最后一次cv2.imread的结果彩色图 shape 是三元组(height, width, 3)直接解包给两个变量会抛ValueError: too many values to unpack——这个问题在避坑章节还会细说。运行前确认frames/文件夹有拆好的帧图片帧数最好 100 张以上fps 按实际拍摄帧率设置不要一律填 30。输出roads_v2.mp4后用播放器多拖几段进度条看效果别只看开头几秒就下结论。5. 避坑手册帧排序、空检测、数组解包与视频编码四个坑5.1 帧文件名排序翻车字母排序会让画面倒着跑现象处理完的视频里车道线位置跳变车辆前进方向混乱严重时看起来像倒放。原因os.listdir返回的文件名顺序本身不确定直接调用sort()按字符串排frame_100.jpg会排在frame_2.jpg前面——因为字符1比2小。帧顺序一乱合成的视频画面就乱跳。解决sort的key必须用int(re.sub(\D, , f))把所有非数字字符删掉后再转整型排序。如果文件名里没有数字正则提取不到内容int()会抛异常所以拆帧时命名务必带连续数字编号比如frame_001.jpg、frame_002.jpg。顺带说一句环境问题如果import cv2直接报ModuleNotFoundError: No module named cv2多半是环境里压根没装 OpenCVpip install opencv-python装完就行。如果是“装了 OpenCV 但找不到 cv2”通常是 pip 装到了 user 目录而解释器路径不对用python -m pip install --force-reinstall opencv-python重装最省事。5.2 HoughLinesP返回None直接崩TypeError的真相现象循环跑到某一帧突然抛TypeError: argument of type NoneType is not iterable程序中断前面的白跑了。原因画面里完全没有满足条件的直线时HoughLinesP返回None而for line in lines会尝试迭代None。解决代码里已经用try/except TypeError把写帧操作包住检测不到就写原始帧。更显式的写法是if lines is not None:再迭代逻辑一目了然。try/except的优点是代码短缺点是如果画线时其他位置也抛了 TypeError也会被误吞导致输出帧没有标注还看不出原因。调试期建议先把lines打印出来确认是不是None。5.3 完整代码直接跑报ValueError: too many values to unpack现象把网上流传的完整版代码存下来直接运行在height, width img.shape这一行崩溃错误是ValueError: too many values to unpack。原因img此时是最后一次cv2.imread读进来的彩色帧shape 是(height, width, 3)三个值用两个变量接不住。网上不少转载版本没改这个位置能跑通是因为原作者在 Jupyter 里按分段执行前面把img重新赋值为灰度图了shape 只有两个值才解包成功。直接跑完整脚本的人几乎都会踩这一脚。解决一律写height, width img.shape[:2]或者在定义size时直接用(col_images[0].shape[1], col_images[0].shape[0])不依赖循环结束后遗留的img变量。5.4 视频文件0字节或打不开编码和尺寸在捣乱现象程序正常跑完输出文件只有几 KB或者播放器直接报错无法打开。原因DIVX编码写进.mp4容器在部分平台上兼容性差size写反把 height 放到 width 位置和实际帧尺寸不一致时VideoWriter可能根本不写数据。解决先确认size (width, height)width取shape[1]、height取shape[0]。还不行就换编码fourcc cv2.VideoWriter_fourcc(*MJPG)、输出路径改成.aviMJPG 在几乎所有平台上都能写动缺点是文件大。最直接的检查是处理完打印out.isOpened()返回True才说明初始化成功否则参数必然有问题。5.5 单帧效果很好但连续视频抖动固定掩码遇上光照变化现象截某一帧看车道线画得又直又准合成出来的视频里线却时断时续、忽左忽右。原因polygon是固定的假设相机位置和角度全程不变阈值 130 也是全局固定早晚光照、树影会让部分帧的车道线灰度跌破阈值检测直接失效。解决先确认摄像头确实固定如果有震动就要做帧间配准或动态 ROI。阈值层面把全局阈值换成 Canny 边缘检测或自适应阈值具体做法在下一章。验证时别只看一帧连续看几十帧检测成功率到八成以上才算参数基本可用。单帧完美不能说明任何问题连续稳定才能交给下一个环节。6. 让检测更稳Canny边缘检测替代阈值化再用抽帧批处理验证参数6.1 升级一Canny HoughLinesP减少光照干扰固定阈值对光照变化极其敏感一个简单的升级是把cv2.threshold换成cv2.Canny霍夫部分完全不用改edge cv2.Canny(masked, 50, 150) lines cv2.HoughLinesP(edge, 1, np.pi/180, 30, maxLineGap200)Canny 先算梯度再双阈值滞后50 和 150 分别是低阈值和高阈值。边缘强度在两者之间、且连接到高阈值边缘的像素会被保留。和全局阈值相比Canny 是局部梯度响应不是绝对灰度所以对光照渐变更鲁棒。车道线在画面里是比较强的边缘低阈值设 4060、高阈值取低阈值的 23 倍是一个合理的起手区间。低阈值设太低会把路面裂缝全检出来设太高虚线车道线会断成碎段这个参数需要按自己的视频再磨一下。6.2 验证方法抽帧跑批处理别对着单帧调参调参最怕只盯一帧换一帧就废。我的习惯是从整段视频里随机抽 10 帧跑一遍完整链路统计每帧检出的线段数import random random.seed(42) sample_idx random.sample(range(len(col_images)), 10) for idx in sample_idx: frame col_images[idx][:,:,0] masked cv2.bitwise_and(frame, frame, maskstencil) edge cv2.Canny(masked, 50, 150) lines cv2.HoughLinesP(edge, 1, np.pi/180, 30, maxLineGap200) count 0 if lines is None else len(lines) print(fframe {idx}: {count} lines)随机抽帧能覆盖白天、阴影、弯道等不同情况。如果某几帧是 0说明参数在这些场景失效。我一般要求 10 帧里至少 8 帧能检出超过 2 条线段再合视频看效果。批处理的好处是把“看起来行”变成“统计上行”比单帧调参靠谱得多。那段固定polygon的掩码在摄像头震动或车身颠簸时会偏出真实车道线区域典型表现是弯道时画出的线飞出去。最简单的补救是把多边形整体往外扩一圈给误差留余量更完整的做法是每隔 N 帧重新检测画面里的强边界自动更新梯形顶点。这份示例代码是固定 ROI 版本够覆盖固定机位的大部分场景接真实行车记录仪时建议先标定相机再决定要不要上动态 ROI。我最早跑车道检测时被那个polygon坐标坑过——以为自己拿到的视频和示例是同一类机位直接照抄四个顶点结果检出的“车道线”全在路肩上。后来我养成一个习惯每换一段视频第一件事是截第一帧在画图工具里把车道边界描一遍得出新的polygon再调阈值最后用随机抽帧批处理验证。这个顺序看着啰嗦但能省掉大量来回试参的时间。到现在我处理固定机位的视觉任务还是先框 ROI、再谈检测这套起手式。希望帮到你。本文还有配套的精品资源点击获取