模型选择与配置说明

模型选择与配置说明（Detection / Recognition / Classification）

本文系统说明本项目在“检测（det）/识别（rec）/分类（cls）”三条子任务上的模型选择思路、备选方案对比、输入尺寸与性能取舍、部署格式（ONNX/MNN）、以及在 GUI 与代码层面的配置方式。目标是让读者理解“为什么选它们、如何用、何时替换”，从而在不同算力与场景下做出稳健可复用的决策。

---

1. 任务拆分与评估指标

• 检测（Detection）：在任意场景中召回车牌，输出矩形框 + 关键点 + 单/双层属性，用于后续几何对齐与裁剪。指标优先级：召回率（Recall）> 精确度（Precision）> 速度（FPS）。
• 识别（Recognition）：从透视对齐后的车牌图块中预测文本序列。指标优先级：准确率（Acc）> 速度（FPS）。
• 分类（Classification）：对车牌颜色/类型进行判别（蓝/黄/绿、单双层等），在界面与后处理上增强可读性与业务判断。指标优先级：准确率 ≈ 速度。

评估采用图片与视频双路径：对图片数据计算 Precision/Recall/F1、对视频采用“内容变化触发”的快照策略观察稳定性与误触发；同时在 GUI 中统一中文可视化，便于比对不同方法（lock/test/rec2）的主客观效果。

---

2. 部署格式选择：ONNX 优先，MNN 作为移动端备选

• 统一推理引擎：PC 端与服务器端优先选择 ONNX Runtime（ORT），原因：
  • 跨平台与生态成熟（Windows/Linux/macOS），与 Python 生态适配好；
  • 工程集成简单、性能可接受，便于快速迭代与调试；
  • 本项目已有稳定的 ORT 封装（standalone_modules）。
• 移动端/嵌入式：保留 MNN 版本模型（见 ModelsPack 与 HyperLPR-master/resource/models），用于 Android/iOS 或 ARM 平台的轻量部署。
• 结论：PC 端主路径采用 ONNX；端侧或极限算力场景再迁移至 MNN。

---

3. 检测模型选择（det）

实际使用：~/.hyperlpr3/20230229/onnx/y5fu_320x_sim.onnx（在 GUI 中可覆盖）。输入尺寸默认为 (det_size, det_size)，默认 320。该模型是多任务头（Multi-Task）检测器，输出包含：

• BBox（x1,y1,x2,y2）用于粗定位；
• 关键点（四个角点）用于后续仿射/透视裁剪；
• 单/双层指示（layer）用于识别前的结构性判断。

选择理由：

• 端对端 vs 纯候选：相较“传统候选 + OCR”方案（lock/rec2），学习型检测器在复杂背景、夜间、斜视角、遮挡等场景的召回稳定性更强；
• 关键点直接输出：避免二次形态学或 Hough 估计，裁剪稳定性与可重复性更好；
• 小输入也可工作：320×320 兼顾精度与速度，在常见 CPU 上也能实时接近或达到可用；
• 与 CCPD/CCPD2020 数据分布契合：工程内置了 Hyper2/CCPD2020，该类模型经过相似分布微调，泛化表现较好。

备选方案评估：

• YOLOv5/YOLOv8/YOLOv10 等通用检测器：
  • 优点：训练生态成熟、工具链完整、速度快；
  • 局限：若不在 Head 中融入关键点与层属性，则需额外回归模块或后处理；端到端维护复杂度上升。
• PP-YOLO/YOLOX：
  • 优点：部署成熟、性能优秀；
  • 局限：与当前识别/裁剪接口对齐需要额外改造，工程耦合度增加。

最终取舍：采用多任务车牌专用检测器，缩短对齐链路，减少工程胶水代码；在需进一步追求极致 FPS 的 GPU 场景，再考虑 YOLO 家族替换并补齐关键点分支。

输入尺寸策略：

• 默认 320；对远距离/小目标场景可提升至 416/512 以增强召回；
• GUI 中提供 det_size 可调，便于在不同视频分辨率与算力下快速试错。

---

4. 识别模型选择（rec）

实际使用：~/.hyperlpr3/20230229/onnx/rpv3_mdict_160_r3.onnx，输入 (48,160)。模型为 CTC 序列识别范式，字符表覆盖中文省份简称与英数字符，兼容单双层结构。

选择理由：

• CTC 简洁稳健：无需显式对齐监督，端到端训练后推理简单、速度快、鲁棒性好；
• 字符表覆盖广：兼容汉字与英数，落地复杂度低，不需要额外语言模型即可达成良好效果；
• 与检测输出天然对齐：结合四点裁剪后，48×160 的标准化输入能在速度与精度之间取得稳健平衡。

备选方案评估：

• Attention/Seq2Seq（如 Transformer-based SAR）：
  • 优点：对长序列与上下文建模更强；
  • 局限：训练与推理复杂度更高，对端侧算力不友好，小样本域外泛化不一定稳定。
• PP-OCR 系列（CRNN/ABINet/SVTR 等）：
  • 优点：生态完善、开箱即用；
  • 局限：中文省份缩写、单双层混排等特征需要定制化字典与后处理，对现有工程替换成本较高。

最终取舍：在工程复杂度可控与稳定产出优先的前提下，CTC 模型是更稳妥的默认选型；未来若要处理极端模糊/遮挡或复杂上下文，可在实验分支引入注意力增强版模型。

输入与预处理：

• 统一将裁剪块按长边对齐到 160，短边填充或缩放至 48，保持字符纵向几何比例；
• 对对比度低与强反光样本，可在裁剪后做轻量增强（Gamma/CLAHE），但默认关闭以保证可复现性。

---

5. 分类模型选择（cls）

实际使用：~/.hyperlpr3/20230229/onnx/litemodel_cls_96x_r1.onnx，输入 (96,96)，为轻量 CNN 分类器，任务包括但不限于：颜色（蓝/黄/绿/白等）、结构（单双层）与特殊类型（新能源等）。

选择理由：

• 可解释性增强：在 GUI 可直接叠加“类型/颜色”标签，便于质检与业务侧确认；
• 低耦合：与识别结果相互独立，出现识别不确定时，分类可作为辅助筛选信号；
• 轻量快速：CPU 端实时开销小，对整体延迟影响有限。

备选方案评估：

• 将“类型/颜色”融入检测头（多任务检测）：
  • 优点：一次前向获得全部属性；
  • 局限：检测头学习任务过多时可能互相牵制，且替换识别模块时易产生联动影响。
• 文本后验规则替代：
  • 优点：无需新模型；
  • 局限：在照度/白平衡变化大时，规则稳定性差，易出现错分。

最终取舍：保持独立轻量分类器，降低联动风险；必要时可以在“多任务检测”与“独立分类”之间做 A/B 实验。

---

6. 默认路径与 GUI/代码层配置

默认路径（代码位于 Hyper2/app.py::default_paths）：

from os.path import expanduser, join
home = expanduser('~')
det = join(home, '.hyperlpr3', '20230229', 'onnx', 'y5fu_320x_sim.onnx')
rec = join(home, '.hyperlpr3', '20230229', 'onnx', 'rpv3_mdict_160_r3.onnx')
cls = join(home, '.hyperlpr3', '20230229', 'onnx', 'litemodel_cls_96x_r1.onnx')

• GUI 覆盖：在 Hyper2/gui.py 中的“test 方法选项”可直接填写 det/rec/cls 路径与 det_size；
• 代码调用：method_test_on_image(..., det_path=..., rec_path=..., cls_path=..., det_size=...)；
• 回退机制：若 rec2 在本机缺失识别模型，则仅输出候选可视化（不阻塞流程）。

---

7. 数据与泛化：为何与 CCPD/CCPD2020 协同

项目目录中包含 Hyper2/CCPD2020 样本（train/val/test），这与我国道路场景分布高度相关：

• 牌照样式多样：蓝/黄/绿、新能源、单双层等并存；
• 环境变化显著：白天/夜晚、雨雾、逆光与强反射；
• 视角/尺度差异大：路口监控、车载、行人视角混合。

因此，我们在模型选择上优先选用对上述变化稳定的架构：

• 检测器具备关键点回归能力，裁剪鲁棒；
• 识别器采用 CTC，抗轻微错位与形变；
• 分类器独立轻量，减少耦合与误差传播。

这套组合在样本域内与相邻域上都较稳健，后续若接入外部数据（如高速收费站、地库入口等），建议：

• 微调检测器以提升远距小目标召回；
• 在识别端加入更丰富的字符表或专门处理特殊字符（使馆牌、武警牌等）；
• 扩充分类标签并引入代价敏感训练应对类别不均衡。

---

8. 速度/精度/开销的工程取舍

• CPU 实时性：det_size=320 + 轻量 CTC + 轻量分类，单图处理常见 PC 能够流畅；
• 提升精度：将 det_size 提升到 416/512，但注意推理时间线性增加；
• 视频节流：通过 frame_stride/snapshot_stride/snapshot_on_change 减少冗余计算与存储；
• 批处理与多进程：在批量图片或多视频时，可在上层封装多进程/线程以充分利用多核；
• 量化与蒸馏（可选）：
  • ONNX Q/DQ 量化可在 CPU 上提升吞吐，但需关注精度回退；
  • 知识蒸馏用于将更大识别模型的能力迁移到轻量学生模型。

---

9. 何时替换/升级模型

建议在以下情形评估替换：

• 场景移植导致召回下降（远距、广角、小目标）：优先升级检测器或提升 det_size；
• 频繁出现字符粘连/断裂：尝试更高分辨率裁剪或引入注意力增强识别模型；
• 新增业务标签（颜色/类型）：优先扩充分类器并做少量迁移学习；
• 移动端部署：切换到 MNN/NCNN 并导出相应格式模型。

替换步骤要点：

• 保持接口一致（输入尺寸、输出字段），避免改动 GUI 与业务层；
• 若输出字段有变化（例如新增关键点格式），先在 crop_plate_by_landmarks 或适配层做转换；
• 在 runs/{method} 下做 A/B 对比，确保新模型在关键场景不退化。

---

10. 小结

本项目在“检测-识别-分类”三段链路上选择了“多任务检测 + CTC 识别 + 轻量分类”的组合，并以 ONNX 作为主部署格式：

• 这套搭配兼顾精度、速度与工程可维护性，特别适合通用 PC/服务器侧的快速落地；
• 通过 GUI 参数化与默认路径回退，降低使用门槛；
• 在移动端或极限算力场景，保留 MNN 作为替代路径；
• 随着数据域扩张，可逐步引入更强识别模型或增加分类维度，同时保持接口稳定。

依托统一的中文可视化与视频节流策略，我们能够在不改变使用体验的前提下，对不同模型与参数进行快速对比与切换，形成“可解释、可复现实验 → 稳定部署”的闭环。