YOLOv5+PPOCR车牌识别实战：从目标检测到OCR的工程化部署

1. 为什么是YOLOv5+PPOCR这套组合拳

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的画面，里面有一辆停在闸机前的白色轿车：

1. 图像先经过缩放、归一化，送入YOLOv5模型，模型输出若干个候选框及置信度；
2. 按置信度过滤低分框，再按类别筛选出“车牌”类别，得到车牌的边界框坐标；
3. 根据边界框从原图上裁出车牌区域小图，必要时做透视摆正；
4. 把裁剪图送入PPOCR识别接口，返回类似“粤B12345”这样的字符串；
5. 后处理：去掉多余空格、校验字符长度、对照车牌规则做合法性检查，最终输出结构化结果。

这一条链路跑通之后，业务侧不管是做道闸抬杆、停车计费，还是做违停抓拍记录，都只是对接一个结果的问题了。后续我会把每一步的实操细节和坑全部摊开讲。

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面对这种输入，输出基本就是乱码。

这个问题的解决方案，不是调模型，而是调图像采集策略。我最后用了三招组合：

1. 摄像头开启HDR或宽动态模式，让亮部和暗部的细节同时保留；
2. 抓拍时连续拍三帧，取其中车牌区域灰度直方图方差最大的一帧（代表对比度最好）作为识别帧；
3. 预处理阶段，若检测到车牌区域平均灰度高于某个阈值（比如超过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张图：

从这组数据能直观看到一个问题：检测准确率并不是主要瓶颈，主瓶颈在OCR识别那一层。而把预处理、后处理和加速做完之后，识别准确率能提升近5个百分点，推理耗时能压缩到原来的三分之一。这也是为什么我一直强调“模型选型只是起点，工程细节才是上限”的原因。

在真实项目交付时，我还会额外加一道“补帧重识别”逻辑：如果某帧的识别结果置信度低，就等该车辆下一帧进入视野时再识别一次，最多允许连续三帧尝试。用这个方法，最终交付版本的实战准确率可以稳定在98%以上，基本能达到大多数道闸和停车系统的商用要求。

最后分享一个我自己在多次部署中形成的习惯：每次到一个新现场，第一步不是调模型，而是先架好摄像头拍一段真实场景视频，离线跑一遍完整链路，把识别失败的所有case截图归档。花一晚上研究这些失败案例，往往比闷头在实验室调一周参数管用得多。车牌识别这套东西，真正拉开差距的从来不是谁用了多么领先的网络结构，而是谁更早看清了现场那道灯光打过来的时候，车牌上的那串字符到底经历了什么。