简介：介绍一个面向计算机视觉学习者与自动驾驶初学者的OpenCV车道实时检测实现示例。资源以PDF文档形式给出完整工程思路，从将视频各帧读取为图片、创建多边形掩码并应用、执行图像阈值化，到通过霍夫线变换检测车道线段、逐帧绘制标记并合并写出结果视频，步骤拆解细致，关键函数与参数均有解释，便于对照代码复现。文档中还特别展示了掩码区域如何设定、二值化阈值如何选择以及HoughLinesP的距离与角度精度设置，帮助读者理解传统视觉方案的核心细节。压缩包仅包含1个PDF文件，大小约194KB，轻量便携，适合快速下载后离线查阅。目前已有307人学习，适合作为OpenCV图像处理或智能驾驶感知模块的入门参考资料，也可作为进一步完善车道检测算法的基础，例如再引入边缘检测、滑动窗口搜索或深度学习模型来提升鲁棒性。
1. 实时车道检测：OpenCV能不能扛住真实路面
车道检测是计算机视觉里最经典的落地场景之一，而用OpenCV做车道线的实时检测，往往是很多人踏入视觉工程的第一步。这篇文章要解决的不只是“怎么把线画出来”，而是用最小可运行的示例代码，串出完整链路——灰度化、高斯模糊、Canny边缘检测、ROI裁切、霍夫直线变换，再到视频流的逐帧处理。整个过程不上深度学习，不依赖GPU，纯CPU就能跑到实时帧率。适合刚装好OpenCV、想跑通第一个完整项目的开发者，也适合正在做辅助驾驶、行车记录仪或仿真实验、需要快速验证车道线检测方案的工程师。
2. 车道检测的技术选型：为什么经典OpenCV链路仍然值得跑
2.1 经典图像处理 vs 深度学习：怎么选不纠结
车道检测目前有两条主流技术路线。一条是以深度卷积网络为核心的端到端方案，输入图像直接输出车道线实例或分割掩膜，典型的如Ultra-Fast-Lane-Detection这类模型。另一条则是OpenCV经典图像处理管线，灰度化、边缘提取、霍夫变换，一套手工设计的链路走到底。不少入门者上来就认定深度学习才是正路，反而忽略了一个工程现实：深度方案的成本大头在数据标注、训练迭代、推理部署和模型漂移之后的持续维护，而OpenCV方案的全部成本集中在图像预处理和几个阈值参数上。
我判断该不该用OpenCV去做，就看三个条件：画面里车道线和路面的灰度对比是否清晰；白天光照是否相对稳定；弯道曲率是否不大。三个条件同时成立，经典链路是远比深度方案划算的选择。这也是很多低成本车道偏离预警、行车记录仪辅助功能背后的真实技术方案——先用OpenCV稳住帧率和功耗，再谈识别精度。反过来，雨天积水反光、老旧路面车道线磨损、大曲率匝道这三种场景，经典链路确实会有心无力，这部分在第2.3节展开。
2.2 车道检测pipeline全拆解：从灰度图到霍夫变换
单帧图像进入OpenCV检测流程后，顺序经过五步处理，任何一步的参数偏差都会直接反映到最终画线上。
第一步是灰度化，把BGR三通道降成单通道。车道检测关注的是车道线和路面之间的明度梯度，颜色信息在这个环节不但没有增益，反而会把彩色路牌、红色车尾灯等强彩色边缘引入干扰。OpenCV里cv2.cvtColor一行就能完成。第二步是高斯模糊，通常用5x5卷积核，目的是抑制传感器和路面纹理带来的随机噪声。模糊核太大，车道线边缘会被抹平；太小，噪声会在后续Canny算子里变成假边缘。第三步是Canny边缘检测，双阈值迟滞机制找出图像中灰度突变的位置。车道线在高对比路面上形成稳定的强边缘，而路面裂缝、轮胎印在适当阈值下会被抑制。第四步是ROI遮罩，把画面下半部的一个梯形区域保留，其余全部置零。这一步是人工先验最重的一环，直接决定了检测的有效范围。第五步是概率霍夫变换HoughLinesP，在边缘图上对像素投票，输出直线段的端点坐标。
这五步不是孤立的。灰度化没做，Canny会被颜色梯度误导；高斯模糊Kernel改到11x11，细车道线直接消失；Canny低阈值降到20，路面颗粒全变成边缘；ROI上边界留太高，护栏和天空云层边缘混进检测区域；霍夫threshold设太低，像素噪点就能聚出一条假线。把这组参数联动关系理解透，后面调参才有方向，而不是靠玄学。
顺手给一个观察中间结果的习惯做法：在每一小步后面接cv2.imshow把中间图弹出来，而不是直接跳到最后看结果。灰度图检查有没有把黄色车道线压成和路面相近的灰色；边缘图检查车道线是否连续、路面噪点是否被滤掉；ROI之后的边缘图检查梯形区域有没有把车头、路肩这些无关物体圈进来。我几乎每次调参都靠这套中间可视化排查，比盯着最终输出猜参数高效得多。
cv2.imshow("gray", gray) cv2.imshow("edges", edges) cv2.imshow("masked", masked_edges) cv2.waitKey(0) cv2.destroyAllWindows()这三个弹窗各看各的问题。edges窗口里，车道线应呈现为两条清晰的连续亮线，如果亮线断成虚线，先别动霍夫参数，回查Canny阈值；如果edges里到处是细碎亮点，说明高斯模糊核太小或者Canny低阈值太低。
2.3 经典方案的边界：什么场景下必须放弃
诚实说结论：OpenCV图像处理链路有明确的适用边界，至少三类场景建议直接换方案或做混合增强。
第一类是夜间和隧道光照。车道线在暗光下与路面的灰度差急剧缩小，Canny双阈值很难找到一个能同时保留车道线、滤掉路面噪点的区间。夜间车灯照射区域会形成局部高光，同一张图里不同区域的对比度差异极大，固定阈值必然顾此失彼。第二类是雨天积水路面，车道线涂料上的水膜产生镜面反射，车道线在灰度图里呈现为破碎的高光条，边缘提取后断成大量小段，霍夫变换的maxLineGap参数调到200也很难拼回完整线段。第三类是大曲率弯道，霍夫变换输出的本质是直线段，它假设检测目标在局部是直的，遇到高速匝道那种连续大角度弯，车道线的弯曲程度超出直线近似的承载力，检测结果会频繁丢线或跳变。
判断要不要继续用OpenCV，有一个很实际的检测方法：把你手头最恶劣的一段视频连续跑50帧，统计有多少帧输出结果完全且正确地覆盖了两条车道线。覆盖率低于70%，说明当前场景超出这个链路的边界，要么做图像增强预处理，比如夜间加CLAHE对比度增强，要么直接切到深度模型。我自己的习惯是，先用OpenCV验证思路和控制成本，发现边界条件撑不住就用同一套ROI和预处理逻辑去对接模型输入，这样迁移成本也可控。
3. 最小可运行代码：单张图片把车道线画出来
3.1 环境准备：cv2安装与版本冲突排查
这里的代码基于OpenCV 4.x和Python 3.8+。先把环境问题解决掉，因为这是新手遇到的第一道坎——装好了却发现import cv2直接报ModuleNotFoundError: No module named 'cv2'。我见过太多人卡在这一步，原因无非两种：pip装到了系统Python而IDE用的是venv里的解释器；或者同时装了opencv-python和opencv-contrib-python两个包，两个包的核心模块重名，互相覆盖造成import失败。
# 先卸载可能冲突的两个包 pip uninstall opencv-python opencv-contrib-python -y # 装上contrib版，涵盖扩展模块，省得后面补装 pip install opencv-contrib-python # 验证安装结果 python -c "import cv2; print(cv2.__version__)"为什么推荐opencv-contrib-python而不是opencv-python？车道检测的HoughLinesP和Canny这两个核心函数属于标准模块，两个包都有，但contrib包额外包含SIFT、Aruco、xfeatures2d等扩展模块。同一个环境里一次装到位，后续做特征匹配、相机标定、AR标记检测时不用重复装环境。卸载时-y参数是自动确认，避免交互中断。验证打印4.x.x就是安装成功。如果打印还是报ModuleNotFoundError，检查当前终端里python指向的解释器路径，和pip安装时用的是不是同一个。
3.2 图像预处理：灰度化、高斯模糊、Canny阈值
先准备一张含清晰车道线的图片，比如行车记录仪的截帧，保存为road.jpg放在代码同目录。下面这段是预处理部分的完整函数：
import cv2 import numpy as np def preprocess_image(image): # BGR转灰度：通道从3降到1，车道线检测只用明度梯度 gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) # 高斯模糊：5x5卷积核削弱传感器噪声 blur = cv2.GaussianBlur(gray, (5, 5), 0) # Canny双阈值：50/150，弱边缘滤掉，强边缘保留 edges = cv2.Canny(blur, 50, 150) return edges灰度化的转换权重由OpenCV内置的BT.601公式决定，不需要手动干预。高斯模糊的卷积核必须是正奇数，5x5是车道检测的常见起点。3x3压不住单像素椒盐噪声，7x7会把弯曲车道的边缘细节磨掉。Canny双阈值ratio在1:2到1:3之间，50/150对应1:3，晴天高对比路面的保守配比。低于这个ratio，边缘断裂严重；高于1:3，阴影处的弱车道线会被当作噪声滤掉。这个阈值在第5章会展开讲动态调整方案。
3.3 ROI遮罩：梯形区域顶点怎么定
车道线只出现在画面的中下部分，天空、护栏、对向车道都在ROI之外。梯形遮罩是这套代码里人工先验最集中的地方，但也是最好调的。下面这个实现按图像宽高的比例计算顶点，不依赖固定分辨率：
def get_roi_vertices(height, width): # 梯形顶点顺序：左下、左上、右上、右下 # 坐标系原点在左上角，y轴向下 vertices = np.array([[ (int(width * 0.05), height), # 左下 (int(width * 0.45), int(height * 0.62)), # 左上 (int(width * 0.55), int(height * 0.62)), # 右上 (int(width * 0.95), height) # 右下 ]], dtype=np.int32) return vertices def apply_roi(edges, vertices): mask = np.zeros_like(edges) cv2.fillPoly(mask, vertices, 255) masked = cv2.bitwise_and(edges, mask) return masked梯形顶边的y坐标0.62h大约对应车前15到30米地面，这个取值依据的是前视摄像头安装高度和俯仰角的常见组合。安装位置偏高，顶边往下移到0.65h；安装位置偏低，顶边上移到0.55h。左右顶点内收比例0.45/0.55为标准车道宽度设计，外扩到0.4/0.6会让护栏和路肩闯入，内收到0.47/0.53会把弯道切线部分切掉。fillPoly用多边形填充生成掩膜，全部像素设255，bitwise_and把梯形区域之外的边缘像素清零。
3.4 霍夫直线检测：HoughLinesP六个参数全解释
ROI处理后的边缘图进入概率霍夫变换，输出线段的坐标：
def detect_lines(masked_edges): lines = cv2.HoughLinesP( masked_edges, rho=1, # 像素步长，精度控制在1px theta=np.pi / 180, # 角度步长1度 threshold=60, # 投票阈值，低于60的线段丢弃 minLineLength=40, # 最短线段40像素，过滤碎边 maxLineGap=150 # 同一直线断点间距150内拼成一条 ) return linesrho和theta决定参数空间的离散化精度。rho=1表示在霍夫空间里以1像素为单位投票，theta=pi/180表示角度步长1度。这两个值组合起来，检测精度足够且计算量可控。rho改成2，远处小幅弯曲的车道线会被拉直；theta步长改大，检测角度分辨率下降，斜向车道线容易漏检。
threshold是投票数下限，也是参数里最敏感的一个。晴天高对比路面，threshold设60甚至80都能稳定出线；城市道路车道线磨损，threshold降到30才有输出。判断标准是：threshold高了丢线，低了出一堆横七竖八的短线段。minLineLength过滤短小噪声，路面裂缝也会被霍夫投出短线，40像素以下的绝大多数是噪声。maxLineGap处理车道线被树影或前车遮挡的断点，同一方向150像素内两端补齐成同一条线。这个值设太大，会把两条平行且接近的车道线错误拼到一起。
3.5 画线与结果输出
检测到线段之后，把它们画在一张透明图层上，再与原图混合输出：
def draw_detected_lines(image, lines, color=(0, 255, 0), thickness=5): line_canvas = np.zeros_like(image) if lines is not None: for line in lines: x1, y1, x2, y2 = line[0] cv2.line(line_canvas, (x1, y1), (x2, y2), color, thickness) result = cv2.addWeighted(image, 1.0, line_canvas, 0.8, 0) return result image = cv2.imread("road.jpg") edge_map = preprocess_image(image) vertices = get_roi_vertices(*image.shape[:2]) masked_edges = apply_roi(edge_map, vertices) lane_lines = detect_lines(masked_edges) final = draw_detected_lines(image, lane_lines) cv2.imshow("Lane Detection Result", final) cv2.waitKey(0) cv2.destroyAllWindows()先创建一张和原图等尺寸的全零画布，把霍夫找到的线段画上去，再用addWeighted按权重叠加到原图。不直接画原图的原因，是保留line_canvas做后续处理——比如按斜率分成左右车道分别染色、或者擦除部分异常线段。叠加权重0.8是经验值，线太淡看不清，太满盖住路面细节。
4. 实时视频流处理：让单帧逻辑跑在连续帧上
4.1 VideoCapture逐帧处理框架
单张图片能出结果，实时检测的差异就是把处理逻辑搬进读取循环。OpenCV的VideoCapture统一处理摄像头和视频文件，打开方式完全相同。下面是一份最精简的实时处理框架：
def process_video(video_path): cap = cv2.VideoCapture(video_path) if not cap.isOpened(): print("视频打开失败，先检查文件路径和编码器") return while True: ret, frame = cap.read() if not ret: break # 缩放处理：1080p缩一半，Canny和霍夫耗时下降约4倍 height, width = frame.shape[:2] frame = cv2.resize(frame, (int(width * 0.5), int(height * 0.5))) edge_map = preprocess_image(frame) vertices = get_roi_vertices(*frame.shape[:2]) masked_edges = apply_roi(edge_map, vertices) lane_lines = detect_lines(masked_edges) output = draw_detected_lines(frame, lane_lines) cv2.imshow("Real-time Lane Detection", output) # waitKey(1)配合循环刷新；写成0会卡死在第一帧 if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release() cv2.destroyAllWindows()这段代码里有四个地方必须说明。第一个是resize缩小分辨率，1080p原图跑Canny加霍夫的单帧开销大约15到20毫秒，缩放一半之后降到5毫秒上下，帧率提升明显。车道检测依赖的是边缘梯度信息，不需要超高分辨率细节。第二个是waitKey(1)，参数1表示每帧等待1毫秒并刷新窗口，配合视频自然帧率节奏。写成0会让窗口卡在第一帧不刷新。第三个是ret检查，摄像头掉线或视频读到末尾都会返回False，不检查直接处理frame会在最后一帧触发空指针。第四个是统一通过q键退出循环，最后释放摄像头资源和窗口。
4.2 性能瓶颈定位：先优化再跳帧
低级算力平台跑不满30fps时，很多人的第一反应是跳帧，每两帧处理一帧。这个思路的问题在于，跳帧降低的是检测频率，不是单帧耗时。检测频率从30Hz降到15Hz，车辆高速行驶时车道线在帧间位移变大，画出来的线会明显滞后。我更推荐先把单帧耗时里的可优化项一一排掉，再决定要不要跳帧。
常见的性能优化有四处。一是把resize后的BGR图像直接转灰度，灰度高斯的模糊处理也提前，因为输入是单通道可以减少约40%的像素计算量。二是ROI遮罩的mask和fillPoly不需要每帧重建，可以在循环外按分辨率生成好固定的mask数组。三是霍夫变换前检查masked_edges是否全零——画面里完全没有边缘时不需要跑霍夫变换，直接跳过。四是用灰度直方图统计跳过Canny的低对比帧，这个稍微走得更远，但在隧道进出场景很有效。
# 循环外预生成mask height, width = 360, 640 precomputed_mask = np.zeros((height, width), dtype=np.uint8) precomputed_vertices = get_roi_vertices(height, width) cv2.fillPoly(precomputed_mask, [precomputed_vertices], 255)这份预生成遮罩的好处是，每一帧的apply_roi只需要做一次bitwise_and，省略了zeros_like和fillPoly的重复分配。单次节省的耗时在1毫秒量级，但一整段视频跑下来，累积的收益非常明显。
4.3 车道线抖动：滑动平均与指数加权平滑
实时检测跑通之后，下一个视觉感观问题是抖动。霍夫变换逐帧独立工作，上一帧检测到左车道线起点是(110, 400)，这一帧因为路面反光变成了(112, 402)，几像素的跳动在连续视频里会被放大成视觉噪声。
一个常用的处理思路是维护最近几帧结果做平均，或者做指数加权。指数加权实现更简单，而且可以通过alpha参数控制平滑力度和响应速度的平衡：
def exponential_smoothing(new_points, history, alpha=0.6): # new_points: (x1, y1, x2, y2) # alpha: 当前帧权重，越大响应越快，越小越平滑 if history is None: return new_points, new_points smoothed = [] for current, prev in zip(new_points, history): value = alpha * current + (1 - alpha) * prev smoothed.append(int(value)) return tuple(smoothed), tuple(smoothed)alpha=0.6表示当前帧的权重占六成，历史占四成。这个值对车道检测比较平衡：能跟上车辆正常变线时的横向位移，也能滤掉高频的像素抖动。alpha调到0.9，响应快但抖动几乎原样保留；调到0.3，画线稳定但变道时严重滞后。调用时把上一帧的平滑结果传回这一帧做历史输入。要更长时间尺度平滑，用collections.deque维护多帧数据稍微复杂，但思想一样。
5. 车道线检测的五个高频翻车场景与排查思路
5.1 路面裂缝和轮胎印全被画成线
跑在粗糙路面上，最终视频里的绿色线段杂乱无章，大量短线横七竖八，车道方向之外全是噪声。
原因是Canny低阈值设得太低，路面沥青的颗粒纹理在边缘图里成片出现，minLineLength又太短，短碎边缘全部被霍夫拟合成线段。这个现象在逆光路面上格外明显，低角度日照让路面上每处凹凸都投出影子。
排查路径分两步走：先把minLineLength从40调到60，碎边长度不达标直接丢弃；再把Canny高阈值从150提到200，弱边缘全体被滤掉，路面凹凸影子和裂缝从边缘图上大面积消失。我一般会同时改这两个参数，然后检查edges中间图确认路面纹理是否已经消失。如果画面里仍然有横斜长短线，就需要回看ROI之外是不是混入了护栏反光等强梯度区域。
5.2 画出的线落在车道线边缘而不是中心
线和车道线平行，但始终压在线的一个边沿上，看起来整体偏左或偏右一些。
车道白线本身有宽度，Canny检测会把一条白线的左右两个边缘同时提取成一对内平行边缘。霍夫在两个边缘上都会投票，画线时只能选择其中一个，结果就落在线的边沿而不是中心线上。
解决方案有两种。预处理方向是做一次形态学闭运算，把白线内部的空洞填充，让Canny输出只产生一条单边；后处理方向是霍夫之后做聚类合并，把斜率接近、间距在20像素以内的平行线段合并成中位线作为最终输出。后者改动的代码量更小，用np.mean对匹配线段坐标求均值即可。
5.3 阴天或云遮挡瞬间，检测线整段消失
视频一直正常跑，某一帧开始画线消失，但没有报错，窗口还在刷新。
云层遮住阳光的瞬间，路面光照突降，灰度图整体对比度变小。Canny固定高阈值150在这个光照水平下偏大，弱化的车道线边缘被当作噪声滤掉，边缘图近似全黑，霍夫没有输入自然没有输出。
解决思路是把Canny的静态阈值改成动态阈值。常见做法是用灰度图的高分位数值替代固定高阈值，让阈值跟随光照变化自动调整：
def adaptive_canny(blur): p90 = np.percentile(blur, 90) # 取灰度第90百分位参考光照水平 low = int(p90 * 0.33) high = int(p90 * 0.8) return cv2.Canny(blur, low, high)p90代表当前帧最高亮的10%像素的灰度水平，强光场景值高、阴天值低，Canny阈值随之缩放。low按0.33倍计算保持1:2.4左右的比值。这个方案能把阴天丢线的概率降低不少，但也不是万能——弯道里出现大面积阴影时，单帧全局阈值仍可能失效。极端方案是按左右车道区域分块计算阈值，但实时性会受损失。
5.4 录制成视频后帧率暴跌
实时显示流畅，一旦用VideoWriter录制输出视频，帧率掉到个位数。
编码器拖慢了主循环。VideoWriter用H.264或MPEG4编码时，软编码在当前CPU上吃掉了大量算力，每写一帧都阻塞处理循环。另外写入分辨率不匹配时，VideoWriter内部会自动做一次隐式转码，比正常处理耗时更高。
调试阶段不要录文件，直接imshow加waitKey显示。需要保存输出视频时，用MJPG编码和较低比特率，控制写入耗时：
fourcc = cv2.VideoWriter_fourcc(*'MJPG') writer = cv2.VideoWriter('output.avi', fourcc, 30.0, (640, 360)) writer.write(output) writer.release()MKPG编码的写入速度远快于H.264，代价是输出文件大。等需要成片交付时再交给硬件编码器压缩，OpenCV里做软编码基本得不偿失。
5.5 车道线在线上下跳变但实际路面没变
车道线位置看原图完全稳定，但检测画线在相邻帧之间大幅上下跳动，每次跳几像素到十几像素。
霍夫变换的线段端点检测每次进入或退出某个像素都会影响整数坐标输出，maxLineGap设大了之后，同一条车道线在不同帧里被拼接成不同长度的线段，端点的整数舍入差异被放大。
处理方法是把线段坐标转换成浮点数存储和参与运算，不要在每帧直接拿整数端点画线。浮点坐标配合指数平滑，亚像素抖动会在滤波里被吸收掉。另一个隐藏收益是，浮点坐标在后续做多项式拟合时数值更稳定，不会因为整数舍入导致重复点排列异常。
6. 从直线到曲线：透视变换与多项式拟合的进阶思路
6.1 透视变换把车道拉成鸟瞰图
霍夫变换只能检测直线段，弯道场景里直线近似拟合不够精确。先用透视变换把梯形视野映射成鸟瞰矩形，车道线从汇聚关系变成平行关系，再做拟合和曲率计算：
def perspective_transform(frame): h, w = frame.shape[:2] # 源点：原始图像里的车道梯形区域 src = np.float32([ [int(0.45*w), int(0.62*h)], # 左上 [int(0.55*w), int(0.62*h)], # 右上 [int(0.95*w), h], # 右下 [int(0.05*w), h] # 左下 ]) # 目标点：鸟瞰图中的矩形位置 dst = np.float32([ [int(0.35*w), 0], [int(0.65*w), 0], [int(0.65*w), h], [int(0.35*w), h] ]) M = cv2.getPerspectiveTransform(src, dst) bird_eye = cv2.warpPerspective(frame, M, (w, h)) return bird_eyegetPerspectiveTransform要求源点和目标点按左上、右上、右下、左下的顺序给出，四点确定唯一单应矩阵。鸟瞰图里车道线横向间距在整个画面内接近常数，后续多项式拟合不再受近大远小的透视干扰。用不了三个以上的锚点时多输出问题或干扰的暂时用不到，四点就足够。
6.2 多项式拟合车道线与曲率输出
鸟瞰图里提取车道线像素坐标，然后做二阶多项式拟合。np.polyfit用最小二乘法拟合系数，二次多项式和正常弯道的形状匹配较好：
def fit_lane_poly(left_pts, right_pts, image_h): left_x, left_y = left_pts.T right_x, right_y = right_pts.T left_fit = np.polyfit(left_x, left_y, 2) right_fit = np.polyfit(right_x, right_y, 2) plot_y = np.linspace(0, image_h - 1, image_h) left_fit_x = left_fit[0] * plot_y**2 + left_fit[1] * plot_y + left_fit[2] right_fit_x = right_fit[0] * plot_y**2 + right_fit[1] * plot_y + right_fit[2] return left_fit_x, right_fit_xdegree=2对应抛物线的车道线模型，兼顾拟合能力和稳定性。degree提高到3能表达更复杂的S弯，但远处点位的轻微噪声会被放大导致曲线剧烈摆动。拟合完成后用曲率半径公式可以输出当前车道的弯曲程度，对辅助驾驶的预警逻辑有实际参考价值。
6.3 同一段素材反复回填参数
进阶功能做完，最后分享一个我自己的习惯验收方法。找一段包含直道、弯道、树影、桥洞的10秒行车视频作为标准测试素材，每次只改一个参数，记录该参数在三种场景下的丢线和误检帧数。输出图层上车道线和实际车道边缘的贴合度低于95%，就是该场景的参数不合格。所有参数的最终版本，必须在这三段场景里都不翻车才算通过。
OpenCV车道检测做到这里，基本已经踩到经典图像处理路线的能力边界：直线检测只给结构、不给语义，强光照突变下鲁棒性注定有限。但作为第一个完整跑通的视觉检测项目，它能让你把边缘提取、ROI、霍夫变换、性能优化这些核心概念全部落到实处。我吃了很多次亏之后养成的习惯是改完参数先在最关键的那几帧上逐帧翻看，而不是直接跑全程——翻车往往就出在最不起眼的一帧阴影里。希望这篇能帮你在跑通车道检测的路上少踩几个坑。
本文还有配套的精品资源，点击获取
