1. 为什么是YOLOv5PPOCR这套组合拳1.1 车牌识别的选型纠结从传统图像处理聊到深度学习先聊个现象。很多做安防、停车系统、园区闸机的朋友一上来问我车牌识别怎么做脑子里第一反应往往是“车牌不就是个OCR问题吗找现成识别库不就完了”。结果真把通用OCR接进去发现根本跑不动——摄像头装在两三米高的立杆上画面里的车牌可能只有几十个像素高角度还有点歪反光、泥污、晚上灯光一打全是噪点。通用模型在文档扫描件上表现不错一到这种“野生场景”就直接露馅。所以真正的思路必须拆成两步先把车牌从整幅画面里找出来再把车牌区域里的字符认出来。前者是目标检测的活后者才是OCR的活。我试过不少检测方案传统图像处理里用边缘检测、颜色分割、形态学滤波做车牌定位晴天白天效果勉强能看一到阴天、树影、车灯直射就崩。后来直接切到YOLO系列稳定性和泛化能力完全不在一个量级。YOLOv5在这类任务里属于“战场老兵”级别的存在。模型不大、部署生态成熟、训练和推理资料多实测下来在车牌这种小目标检测上精度和速度的平衡确实很舒服。我见过有人用YOLOv8甚至更重的模型来做精度确实还能涨一点但代价是推理耗时上去了在只靠CPU或者边缘盒子跑的场景里帧率下滑很明显。所以回归到“一台普通工控机跑实时视频流”这种真实约束下YOLOv5依然是一个非常扎实的起点。至于OCR端我一开始其实试过几种方案包括Tesseract和一些自训练的小模型但最终稳定用的是PPOCR。PPOCR对中文和数字混排的支持好而且针对车牌这种字符密集、字体相对统一的场景只要把检测框做准、预处理做到位识别率能拉到很高。而且PPOCR的模型导出、推理部署也顺不会在落地环节卡你一道。1.2 PPOCR凭什么接得住车牌识别这种活这里多解释一句因为很多人会把“OCR”当单一能力去理解。PPOCR本质上是“检测识别”两条线组成的PPOCR自带的文本检测模型可以做全文检测但在我们的方案里这个检测步骤其实可以跳过——因为YOLOv5已经给了我们车牌的精确位置。我们直接用PPOCR的文本识别模型把车牌区域裁剪图送进去让它输出字符序列这就够了。它的好处是识别模型专门针对场景文字训练过对低分辨率、斜体、形近字比如数字0和字母O、数字1和字母I有自己的容错逻辑还有大量数据增强策略。而且车牌上的汉字省份简称像“京”“沪”“粤”“苏”这些普通通用OCR模型经常识别出错PPOCR的中文识别能力在里面反而是最省心的。我打个比方吧YOLOv5像是一个优秀的导购员人堆里一眼就能拽出“那个拎着车钥匙的人”车牌区域PPOCR则是柜台里的文字鉴定师只负责把已经递到眼前的几个字逐个认清楚。各管一段反而比一个人从头干到尾更可靠。1.3 一个直观的例子从原图到一串文本先来个完整的流程示意。假设摄像头传进来一帧1080P的画面里面有一辆停在闸机前的白色轿车图像先经过缩放、归一化送入YOLOv5模型模型输出若干个候选框及置信度按置信度过滤低分框再按类别筛选出“车牌”类别得到车牌的边界框坐标根据边界框从原图上裁出车牌区域小图必要时做透视摆正把裁剪图送入PPOCR识别接口返回类似“粤B12345”这样的字符串后处理去掉多余空格、校验字符长度、对照车牌规则做合法性检查最终输出结构化结果。这一条链路跑通之后业务侧不管是做道闸抬杆、停车计费还是做违停抓拍记录都只是对接一个结果的问题了。后续我会把每一步的实操细节和坑全部摊开讲。2. 检测到识别的工程链路把两张网络“缝”起来2.1 坐标系对齐与区域裁剪最容易翻车的第一层很多第一次上手的朋友会在这里懵YOLOv5输出的坐标到底是原图坐标还是缩放后的坐标如果预处理阶段把图像resize到640x640再喂给模型那输出的坐标怎么映射回1080P原图这里必须讲清楚YOLOv5的坐标处理逻辑。模型输出的x、y、w、h是归一化值0到1之间乘以输入图像的宽高才得到像素坐标。如果你在预处理时只resize了模型输入但推理之后忘了把结果映射回原图尺寸裁出来的区域就会偏移识别自然全错。我当时处理的标准做法是# 假设img为原始帧img_resized为送入网络的缩放图 # det.xywhn是归一化的检测框输出 scale_x img.shape[1] / img_resized.shape[1] scale_y img.shape[0] / img_resized.shape[0] x_center float(det.xywhn[0][0]) * img.shape[1] y_center float(det.xywhn[0][1]) * img.shape[0] w float(det.xywhn[0][2]) * img.shape[1] h float(det.xywhn[0][3]) * img.shape[0] x1 int(x_center - w / 2) y1 int(y_center - h / 2) x2 int(x_center w / 2) y2 int(y_center h / 2) # 裁剪时注意边界裁剪防止越界 x1, y1 max(0, x1), max(0, y1) x2, y2 min(img.shape[1], x2), min(img.shape[0], y2) plate_crop img[y1:y2, x1:x2]这里有个容易忽略的小坑摄像头在抓拍时往往会给车牌区域留一定余量检测框会比车牌本体稍微大一圈。裁剪图直接送进OCR其实问题不大因为PPOCR能处理一定程度的背景干扰。但如果检测框裁得太紧把车牌边缘的铆钉、边框也切掉一半反而会丢字符我建议在裁剪时把检测框外扩3%到5%的边距实测识别率更稳。2.2 透视校正倾斜车牌的“摆正”细节如果说坐标系对齐是第一层坑那透视变形就是第二层。现实中摄像头从侧面拍车头车牌在画面里经常是一个平行四边形而不是正矩形。字符本身是斜的倒还好PPOCR对轻微旋转有一定鲁棒性但如果倾斜角度太大比如超过15度直接硬送OCR识别率就会明显往下掉。所以我在链路里加了一道透视校正。具体做法是用YOLOv5的检测框做基础再在车牌区域内检测四个角点这一步我试过用PPOCR的文本检测模型辅助也试过直接用形态学算子找轮廓最终稳定用的是在裁剪图上做轮廓筛选得到四边形的四个顶点之后用OpenCV的getPerspectiveTransform加warpPerspective做投影变换把车牌区域映射成固定尺寸的矩形比如240x80再送进PPOCR。这一步的收益非常直接。我做过一组对比实验同一批倾斜角度在10度到20度之间的车牌图片不做校正直接识别准确率大概在70%上下做了校正之后直接提升到95%以上。倾斜越严重这道工序的收益越明显。代价是每个车牌多花大概3到5毫秒的CPU时间完全可接受。你可能担心四角点检测不稳定其实大多数标准车牌汽车蓝牌、新能源绿牌等在图像里都有一段连续的高对比度边缘轮廓筛选时按面积、长宽比、轮廓凸度三个条件过滤基本能把干扰轮廓剔干净。唯一要小心的是车身的装饰条、车标、倒影这些噪声轮廓过滤条件里加一条“轮廓最小外接矩形的长宽比大于2且小于5”实测能挡掉绝大多数干扰。2.3 双层车牌与多类型车牌的预处理差异车牌识别这类项目最容易忽视但坑最深的其实是车牌类型差异。很多人训练检测模型时标注样本全是大蓝牌上线之后遇到黄牌、绿牌、白牌、双层挂车牌照就各种出错。先说双层车牌。大型货车尾部的黄牌常常是上下两层结构上层是省简称加字母下层是一串数字。PPOCR直接整体识别时往往会因为字符排列不规整产生误识别。我的处理办法是检测到车牌区域后先分析车牌的宽高比如果h/w明显大于普通蓝牌就判定为双层结构然后把裁剪图沿水平中线切成上下两半分别送OCR最后按“上半结果下半结果”拼接。这个逻辑在车型分布比较平均的物流园区里非常有用。再说黄牌和绿牌。绿牌的字符是渐变色底加黑色文字黄牌是黄底黑字虽然PPOCR模型按灰度图也能处理但如果预处理时做了某些颜色通道的过滤效果反而会变差。我的建议是在送OCR之前先把裁剪图转为灰度图再做一遍轻度对比度增强避免颜色底纹干扰文字的纹理细节。另外港澳车牌的格式和内地车牌差异很大字符长度短、排列紧凑如果项目范围覆盖这类车辆建议单独再训练一个小分类器或者至少准备专门的OCR预处理分支。这个比较偏门但如果你的停车场在边境城市或者高端商业区还是要提前想到。2.4 识别结果的后处理与纠错模型输出的是原始字符序列但工程上不能让脏数据直接进业务系统。我会在OCR输出之后加一道规则校验按车牌法规格式过滤明显不合理的结果普通燃油车牌第一位必须是汉字省份简称第二位是字母后面五位是字母和数字混合总长7位新能源车牌总长8位第6位一般是字母D或F区分纯电和混动黄牌大车牌照规则类似蓝牌但允许挂车牌照等特殊格式警车白牌格式与普通车牌类似但第二位往往是“警”字。校验不通过时我不会立即放弃而是做两次约束修正尝试一是把容易混淆的字符做映射替换比如识别结果里的0变成O、1变成I再按车牌规则反向替换回去看哪种组合能通过校验二是把裁剪图做一次小角度旋转正负5度之内重新识别一次。双保险下来单帧的最终识别率能比单次识别高出3到5个百分点。注意后处理校验不是让你硬把错误结果“修”成合法格式而是利用车牌格式的强先验在置信度边缘的候选里挑出最可能正确的组合。如果OCR本身置信度已经很低强行替换字符反而会掩盖问题正确的做法是把该帧标记为低置信度走补拍或人工复核流程。3. 实地部署踩过的坑从仿真测试到真实环境的距离3.1 夜间与反光真实场景的“照妖镜”模型在实验室里跑得再好拿到现场也可能翻车而且翻得毫无预兆。我印象最深的一次是在某园区停车场试点白天测试时识别率接近98%大家都很满意。结果晚上一亮灯识别率直接掉到80%排查了一整天才找到原因。罪魁祸首是车牌区域的反光。夜间摄像头通常开启补光灯车牌表面有层反光膜补光灯打上去之后部分角度下字符会被高光完全吞掉灰度图上只剩下一片白板。PPOCR面对这种输入输出基本就是乱码。这个问题的解决方案不是调模型而是调图像采集策略。我最后用了三招组合摄像头开启HDR或宽动态模式让亮部和暗部的细节同时保留抓拍时连续拍三帧取其中车牌区域灰度直方图方差最大的一帧代表对比度最好作为识别帧预处理阶段若检测到车牌区域平均灰度高于某个阈值比如超过200先做一次局部直方图均衡化把反光区域的纹理拉回来。这三招加上之后夜间识别率恢复到96%左右。虽然还是比白天低一点但已经不影响业务使用了。要记住一个原则车牌识别系统的模型能力要占到七分但剩下三分里图像采集质量比模型微调更值钱。3.2 摄像头安装角度与画面畸变问题安装角度这件事属于典型的前期偷懒、后期还债。有些项目为了覆盖更多车道摄像头装得很高、角度很斜导致同一画面里近处的车牌巨大、远处的车牌极小或者侧面的车只能拍到斜45度的车牌。YOLOv5对这种多尺度场景其实有一定适应能力但PPOCR对过小的字符识别很差一般车牌区域宽度少于80像素时识别率就开始断崖式下降。所以我在项目验收标准里都会加一条目标车道内车牌的最短边不少于120像素如果光学焦距不够该升级镜头就升级镜头该调整机位就调整机位别指望软件端力挽狂澜。广角镜头还会带来桶形畸变画面边缘的文字会弯曲。这种畸变在车牌区域离画面中心较远时尤其明显。我的处理方法是在摄像头安装完成之后拍一张标准的棋盘格标定板用OpenCV的相机标定流程计算畸变系数然后接入实时视频流后先做一次去畸变再送入识别链路。这套流程本身不复杂但对识别率的提升是实打实的尤其对跨多车道的场景。3.3 数据标注与样本增强的细节最后聊一下最费人力但最不容回避的环节训练数据的质量。YOLOv5也好PPOCR也好模型的上限是被标注数据定义死的。我见过有人从公开数据集拉了两千张车牌图片就开始训练到了现场发现各种奇葩情况根本不认识。在标注阶段我坚持的是“宁可多一点边角料不要全是标准样本”。晴天、阴天、雨天、夜间、逆光、顺光、反光、泥污、遮挡、倾斜、双层、新能源、黄牌蓝牌绿牌白牌每一个维度都要保持一定量的样本。标注时不要只框正正的矩形要贴着车牌的实际边缘框包括倾斜状态下的四边形框。样本增强方面我试过很多方法最终保留并且强烈推荐的组合是随机亮度、对比度扰动模拟不同光照随机小角度旋转正负15度内随机透视畸变模拟侧拍角度高斯噪声和运动模糊模拟雨天和车牌运动随机亮斑叠加模拟反光。但有一点要特别注意增强不要把车牌内容变得不可辨识。增强的目的是“覆盖更多成像条件”而不是“制造一些模型永远学不会的极端例子”。增强比例我一般控制在30%到50%过了反而会拉低模型的正常识别精度。4. 性能优化实测从推理加速到业务接入4.1 模型导出与推理加速别让模型跑在“温吞水”速度上识别链路跑通之后下一步就是性能问题。一辆车从进入摄像头视野到闸机抬杆整个过程只有一两秒的时间预算。如果一帧一帧全链路处理YOLOv5推理加PPOCR识别加各种预处理在普通CPU上可能要跑到300到500毫秒一帧车稍微开快点就可能漏抓。我目前的实测方案是YOLOv5模型先导出为ONNX格式再用TensorRT做FP16精度转换在NVIDIA显卡上推理速度能从原始PyTorch的20多毫秒每帧降到8到10毫秒每帧。PPOCR识别端也用同样的方式做优化整个链路单帧总耗时可以压到80毫秒以内。如果部署环境没有独立显卡只有CPU工控机那就得用OpenVINO跑YOLOv5的IR模型再加ONNXRuntime跑PPOCR。实测下来在i5级别的处理器上单帧耗时大概在200毫秒上下勉强能应付单车道低速通行场景。再不行就只能降低视频流分辨率比如1080P降到720P同时把检测帧率从全帧改为隔帧检测比如每两帧检测一次这样能进一步压缩计算量。4.2 队列与异步处理识别别挡住视频流这是一个很多人踩过的性能陷阱同步处理模式下视频流读取线程、检测线程、识别线程全串在一起摄像头采集一帧等识别完了才能继续采下一帧。一旦画面里同时出现多辆车处理不过来视频流就开始掉帧严重的直接把采集任务卡死。我的做法是把链路改成生产者消费者模式。视频流线程只负责抓帧并放入一个带缓冲的队列检测线程从队列里取帧做YOLOv5推理把检测框信息放到另一个队列OCR识别线程拿检测框结果去裁剪和识别。三个环节之间用队列解耦速度由最慢的环节决定但不会再互相阻塞。这里还要处理一个实际需求连续多帧检测到同一辆车的同一个车牌不要重复识别。我会给检测结果加一个简单的IoU跟踪逻辑当相邻帧检测框的重叠度很高并且识别结果相同就直接跳过OCR步骤沿用上一次的识别结果。这一招在车辆排队通过闸机时特别有用能把OCR调用量降到原来的三分之一。4.3 精度和速度的平衡测试最后把训练后的模型做一个实际效果记录用一组我在现场整理的评测样本做参考。样本包含白天、夜间、逆光、反光、倾斜、双层牌等场景共500张图方案组合检测准确率字符识别准确率单帧耗时CPUYOLOv5s PPOCR原版98.2%91.5%约220msYOLOv5s 透视校正 灰度增强 规则校验98.2%96.3%约235msYOLOv5s 全套预处理 TensorRT加速98.2%96.5%约75msGPU从这组数据能直观看到一个问题检测准确率并不是主要瓶颈主瓶颈在OCR识别那一层。而把预处理、后处理和加速做完之后识别准确率能提升近5个百分点推理耗时能压缩到原来的三分之一。这也是为什么我一直强调“模型选型只是起点工程细节才是上限”的原因。在真实项目交付时我还会额外加一道“补帧重识别”逻辑如果某帧的识别结果置信度低就等该车辆下一帧进入视野时再识别一次最多允许连续三帧尝试。用这个方法最终交付版本的实战准确率可以稳定在98%以上基本能达到大多数道闸和停车系统的商用要求。最后分享一个我自己在多次部署中形成的习惯每次到一个新现场第一步不是调模型而是先架好摄像头拍一段真实场景视频离线跑一遍完整链路把识别失败的所有case截图归档。花一晚上研究这些失败案例往往比闷头在实验室调一周参数管用得多。车牌识别这套东西真正拉开差距的从来不是谁用了多么领先的网络结构而是谁更早看清了现场那道灯光打过来的时候车牌上的那串字符到底经历了什么。