LabVIEW车牌识别系统开发实战：从图像采集到界面联动的完整指南

车牌识别系统这东西你在搜索栏敲“labview 车牌识别”能翻出来一摞号称完整的源码包。我早年间也是这么入坑的——下载、解压、打开主VI、信心满满点运行然后前面板一片灰或者视频窗口永远显示“未检测到车牌”。后来在停车场和园区门禁项目里真刀真枪做了几套才琢磨明白一件事LabVIEW做车牌识别难点从来不在“识别”这两个字而在图像从相机走到界面的这条完整链路。这篇文章把我实际搭建车牌识别系统界面的思路、关键步骤、踩过的坑都摊开讲给正在做LabVIEW课程设计、毕业设计或者想给现有设备加车牌识别功能的工程师做个参考。1. 为什么用LabVIEW搭车牌识别系统选型逻辑和真实场景先说一个反直觉的结论纯从算法角度讲PythonOpenCV或者MATLAB确实比LabVIEW更顺手图像处理生态大网上现成的车牌识别代码一抓一大把。但如果你要的是一个能接到道闸、能写进数据库、能跑在工控机上长期不崩的完整系统情况就不一样了。LabVIEW的强项从来不是算法而是它能把相机采集、图像显示、串口通信、数据库访问、界面交互这些东西在一个图形化环境里捏合成一套可交付的程序。1.1 与Python/OpenCV/MATLAB方案的实际对比我把自己做技术选型时关注的几个维度列一下对比维度LabVIEW NI VisionPython OpenCVMATLAB开发速度快拖拽连线前面板直接调快代码简洁中等视觉工具链IMAQdx Vision Development Module和采集卡/相机无缝衔接OpenCV生态最强模型丰富有Image Processing Toolbox但算法落地一般硬件联动串口、网口、IO卡、运动控制都是原生生态桥接几乎零门槛需要自己写串口/GPIO/Modbus代码调试成本高工业通信支持弱部署麻烦界面开发前面板拖拽做现场操作界面很快PyQt/Tkinter代码量不小App Designer偏科研风格打包部署Application Builder一键生成exe可附加驱动安装器pyinstaller等工具依赖环境容易踩坑安装包体积大需要运行时组件算法生态OCR主要靠NI自带OCR或外部DLLPaddleOCR、Tesseract等非常丰富有算法但转向工程不顺手这里没有任何踩Python的意思——如果你要做的是高并发识别服务、云平台或者算法迭代为主的项目Python明显更合适。LabVIEW方案的价值在于“系统集成速度”从相机取流到串口发开闸指令别人可能要接一堆库、调两天接口LabVIEW这边一个VISA写串口函数就搞定而且是图形化的现场工程师也好维护。1.2 这套方案真正适合谁我接触过几类人和这个方案的匹配度完全不同。第一类是LabVIEW课程设计或毕业设计。这类任务通常要求“必须用LabVIEW实现一个完整的系统”那车牌识别就是个很好的题目——有图像采集、有界面、有通信、有数据库四要素都齐答辩时能讲的东西非常多。我用LabVIEW做过交通灯模拟、温室光强监测这类课设说实话车牌识别这种综合度更高的题目拿出去是能看出工程能力的。第二类是自动化产线和园区门禁集成商。现场已经有一套LabVIEW写的上位机程序想给它加个“看车牌”的功能又不想为了一个识别模块额外部署一套Python服务。这种情况下在现有工程里加一个视觉采集循环、调一个识别DLL是最平滑的扩展方式。第三类是实验室内部系统比如实验楼门禁、内部停车场车牌量不大识别率要求没那么苛刻但要求部署简单、换台电脑能跑。LabVIEW打包后在这类场景非常省心。反过来你要做的是大型商业停车场日均过车上千甚至上万对识别率有99.9%级别的硬要求那我建议直接采购专用的车牌识别一体机或者用C/Python做独立识别服务。LabVIEW不适合在这种场景冲锋陷阵它更适合做“控制中枢和业务联动层”。1.3 我推荐的“壳核”分工方式做了几套之后我个人的方案很明确LabVIEW负责一切图像采集、预处理、界面、通信、联动字符识别交给DLL或HTTP服务。LabVIEW是壳识别算法是核两边用标准的函数接口对接。这样分工有两个好处。一是识别准确率不锁死在NI Vision上——NI的OCR工具也能做字符识别但对中文字符集的训练样本收集比较痛苦而外挂的PaddleOCR/Tesseract在中文车牌识别上成熟得多。二是算法可以迭代今天用Tesseract明天换成更准的深度学习模型LabVIEW这边的接口不变只换DLL文件就行。2. 系统整体架构从相机取流到道闸联动的完整数据流确定了“壳核”方案后下一步就是把整个系统的数据流画清楚。这是我在实机上反复改过的部分建议你先在纸上走一遍再开始写VI能少走很多弯路。2.1 分层结构与数据流向一套完整的LabVIEW车牌识别系统我习惯分成五层图像采集层工业相机通过USB3.0或GigE接到工控机LabVIEW用IMAQdx驱动取流一帧一帧拿到原始图像。图像预处理层把原始彩色图转成灰度或HSL格式做直方图均衡、滤波、增强为后续定位提供干净输入。识别层先定位车牌候选区再切割字符最后调DLL或OCR接口输出字符串和置信度。业务逻辑层对识别结果做合法性校验车牌格式、置信度阈值、决定是否开闸、把记录写入MySQL、写本地日志。执行与表现层前面板实时显示视频流和识别结果串口发指令控制道闸/门禁数据库落库。数据流上最核心的一条链路是相机抓帧 → 图像入队 → 预处理 → 车牌定位 → 字符分割 → DLL识别 → 结果校验 → 数据库落库 → 串口开闸指令 → UI刷新。很多初学者写车牌识别程序喜欢在一个大While循环里把所有事情做完抓一帧、处理一帧、识别一帧、刷新一次界面。识别一帧要几百毫秒这期间界面就是卡死的操作员点按钮没反应摄像头的实时画面也断断续续。我后面会专门讲生产者-消费者架构怎么解决这个问题这里先把架构分层记牢它决定了你后面所有VI的组织方式。2.2 设备选型别在相机和补光灯上省钱图像质量是识别率的生死线这话我在现场验证过太多次了。选型时我按这套标准来工业相机优先USB3.0接口的工业相机比如海康MV-CA系列、大恒MER系列分辨率200万到500万像素就够。不要用普通USB摄像头它们的自动曝光、自动白平衡会严重影响识别稳定性。工业相机支持手动设置曝光、增益、白平衡这些参数对车牌识别太重要了。镜头焦距6mm到12mm之间视场要保证能看到2到3米宽的车道车牌在画面里占大约1/5到1/4的宽度。镜头选太大车一停偏就出画面选太小车牌太小识别不清。补光灯夜间识别离不开补光。白光LED常亮灯是一种方案最好是带光敏控制的晚上自动亮。另一个方案是由程序控制频闪配合相机硬触发效果更好但接线复杂。工控机别用低功耗嵌入式小主机识别算法虽然不重但图像处理和运行多个服务还是要吃CPU的。i5级别、8G内存、SSD硬盘是我的起步线。如果能留一块中端显卡以后换深度学习识别模型还有余量。触发方式如果要抓“车到即拍”用地感线圈或光电开关接一个数字IO通过计数器触发相机抓帧这样不会漏车也不会拍空。我早期用的是软件循环检测画面变化车辆低速时还行一快就丢帧后来老老实实装了地感。2.3 软件版本与工具包匹配LabVIEW版本我推荐2020以上的64位版本。64位的好处是能分配更多内存给图像缓存也不容易碰到内存爆掉的问题。需要搭配的工具包有这些Vision Development Module图像采集和处理的整套函数库包含IMAQdx驱动、NI Vision图像处理函数、OCR工具。注意你的LabVIEW版本和VDM版本要对应装错版本会找不到函数面板。VISA驱动串口通信、网口通信都靠它程序最后打包时要把VISA Runtime附加进去否则换台机器就报找不到VISA。Database Connectivity Toolkit或LabSQL连接MySQL的方案前者是NI的官方工具包后者是第三方开源包我两个都用过后面细说。识别DLL从C/C#封装的OCR识别库比如Tesseract、PaddleOCR的C接口版本或者你自己训练的TensorRT模型服务。版本这一个点我在第6章的踩坑记录里会展开说打包和启动相关的问题有八成和版本不匹配有关。3. 图像采集与预处理识别率的第一道生死线很多人把车牌识别率低归咎于算法不够强实际上我在现场的经验是七分靠图像三分靠算法。你给DLL的图像是模糊的、倾斜的、过曝的再好的模型也救不回来。图像采集和预处理才是真正决定系统上限的地方。3.1 相机安装与补光工程细节决定成败安装高度和角度是第一个容易被忽略的坑。车牌最好的拍摄位置是相机光轴和车牌平面大约呈10到15度的俯仰角安装高度2.5到3米车道中间偏右一点。角度太大车牌会形变字符投影被拉长识别率直线下降。这个经验值是我在车库里来回调了两天得出的一开始装得高拍得远结果识别时字符分割总出错后来降低到2.8米、俯仰角调到12度左右效果立竿见影。补光的原则是“均匀覆盖车牌区域”。我用的是LED白光常亮灯安装在相机下方约30厘米处角度稍微向下压避免直射反光牌造成过曝。现场如果阳光侧照形成强反光可以在镜头前加偏振镜实测能压掉大部分反光。还有一个容易被忽略的点相机白平衡一定要手动固定自动白平衡会让车牌颜色在不同时段漂移颜色阈值定位就会失灵。3.2 IMAQdx抓帧流程与图像转换在LabVIEW里用工业相机抓帧核心流程如下IMAQdx Open Session打开指定的相机接口配置分辨率和像素格式。IMAQdx Configure Grab启动连续采集模式让相机持续向内存推流。在循环里调用 IMAQdx Grab每次从缓冲区拿最新一帧。用 IMAQ Copy 复制图像Grab返回的是内部缓冲区的引用下一帧会覆盖它所以要复制出来再处理。转换为灰度或HSL图像IMAQ ExtractColorPlanes提取颜色平面或IMAQ CastImage转灰度。这里我栽过一次跟头一开始为了省时间没有复制图像直接在Grab返回的图像句柄上做处理结果画面一卡一卡的还出现了“上一帧和下一帧叠在一起”的诡异现象。后来查资料才明白是缓冲区覆盖的问题——Grab函数是轮转缓冲你不复制出来下次Grab就会把正在处理的图像给覆盖掉。3.3 预处理链增强、滤波、颜色阈值拿到原始彩色图后我不会直接送识别而是走一套固定的预处理链直方图均衡化增强对比度尤其是阴天和黄昏光线不足的时候能让车牌字符更锐利。中值滤波3x3去椒盐噪声和细小干扰点中值滤波对车牌这种边缘密集的图像比均值滤波友好边缘保留得更好。对比度拉伸把灰度范围拉满让字符和背景的边界更清晰。颜色阈值提取用HSL空间做阈值分割把蓝色/绿色/黄色车牌从背景里分出来。处理后的图像再交给定位模块去筛候选区。这一套链路的目的只有一个让车牌区域在图像里变成最显眼的、最容易提取的对象。背景里的树叶、建筑、行人、车灯通通在这一步被压掉或隔离。预处理的每一步都在为后续定位降低难度少一步都可能导致定位算法去“大海捞针”。4. 车牌定位、字符分割与识别核心算法的工程化落地图像预处理做完接下来是核心三连定位车牌区域、分割字符、识别字符。这部分我讲讲在LabVIEW里的工程化实现方式以及哪些环节最容易出问题。4.1 定位候选区颜色阈值法和边缘投影法的双保险车牌定位我常用两套思路根据现场情况选颜色阈值法适合固定场景、光照可控的情况。中国车牌有蓝底白字、绿底黑字新能源、黄底黑字等多种类型颜色是最直观的特征。在LabVIEW的NI Vision里我先把RGB图像转到HSL空间然后用ColorThreshold函数以蓝色为例H通道大致在160到200这个区间0到255标度S通道和L通道的范围需要现场标定。这一步会生成一个二值掩码蓝色像素为1其余为0。然后做形态学闭运算把车牌区域内部的字符间隙、边缘断裂都填起来让车牌变成一个完整的连通域。最后用Particle Filter筛选候选区域标准蓝牌尺寸是440mm×140mm宽高比约为3.14我一般把宽高比范围设在2.5到4.0之间面积范围按图像分辨率换算后设置上下限这样能把路牌、广告牌、蓝色车身等干扰项过滤掉不少。边缘投影法适合灰度图像和不能依赖颜色的场景。先做边缘检测Sobel算子得到边缘图然后在水平方向做投影找水平方向边缘密集的条带再在条带内做垂直投影找垂直方向边缘集中的区间两者交叉就是车牌候选区。这个方法对颜色失效的场合比如黑白相机、车牌褪色很有用。4.2 字符分割垂直投影法和粘连处理的实战经验车牌定位到之后把车牌区域裁出来二值化然后做字符分割。最经典的方法是垂直投影法把二值图像按列求和得到每一列的白色像素数量字符之间有间隙投影值会掉到零或接近零这些位置就是分割点。实际操作中有两个很烦人的问题汉字左右结构被拆开比如“京”字左边“亠”和右边“京”之间可能因为字体结构出现空白投影法会把它分成两段。这时候需要统计正常车牌的字符数——蓝牌应该是7个字符新能源是8个。如果分割结果比正常数量多就把相邻的连通域合并回去再重新检查。字符粘连某些字体下相邻字符会黏在一起投影值没有归零区间。这种情况我会先检查候选区域的宽度若宽度接近两个字符之和就尝试在垂直投影最弱的位置强行分割。这个方案不完美但能救回一部分图片。字符分割做得准不准直接决定后续识别的上限。我在这块花的时间比选OCR引擎还多。4.3 识别引擎选择NI OCR、DLL还是HTTP API分割出单个字符后有三种识别路线方案优点缺点适合场景NI Vision自带OCR全LabVIEW环境、部署简单中文字符集需要自己训练大量样本毕设演示、纯英数字识别DLL集成Tesseract/PaddleOCR中文识别成熟、准确率高、可替换算法需要C/C#封装、注意32/64位匹配工程落地推荐HTTP API调用识别服务模型可集中管理、支持复杂模型依赖网络、有响应延迟有内网服务器、多车道集中识别我最推荐的是DLL方案。LabVIEW端负责图像预处理、定位、分割把裁剪好的车牌图或字符图通过内存指针传给DLLDLL内部用OCR库识别最后返回字符串和置信度。这样算法升级不用碰LabVIEW代码非常干净。在LabVIEW里调用DLL用Call Library Function Node。第一次配置时有几个坑位数必须匹配LabVIEW是64位的DLL也必须是64位编译的否则加载直接报错。调用约定一般选stdcallWindows API默认或C调用约定要和DLL导出时一致选错会报内存访问错误或返回值乱码。数组传参图像数据最好用U8数组指针传入配置Parameter时选Array Data Pointer尺寸参数另外传Width和Height这样DLL端可以直接访问图像内存。4.4 识别后处理格式校验和置信度兜底识别结果出来后不要直接拿去做业务判断必须先过一道格式校验。中国车牌第一位是省份简称汉字京、津、沪、渝、冀、豫、云、辽、黑、湘、皖、鲁、新、苏、浙、赣、鄂、桂、甘、晋、蒙、陕、吉、闽、贵、粤、青、藏、川、宁、琼第二位是发牌机关字母A-Z不包含I和O后面是5位或6位数字字母。如果识别结果第二位是数字、或者长度不对基本可以判定识别有误这时应该触发重新识别或人工介入。还有一个实用技巧字符替换映射。OCR经常把字母O识别成数字0、把字母I识别成数字1。在车牌语境里第二位字母如果识别成0或1可以尝试映射回O和I而后面数字区域如果识别出O和I也可能要映射回0和1。这种规则不能死板要结合位置判断但加了这个映射之后我的系统识别准确率确实提升了。置信度阈值和重试机制也必须有。DLL返回置信度后低于某个阈值我常用0.75的识别结果我会让系统自动取下一帧重新识别连续三次失败才判定“无法识别”并报警。这个机制能有效过滤瞬时模糊、反光、遮挡造成的误判比单纯调高算法门槛要平滑得多。5. 界面设计与数据联动车牌识别系统不只是一个识别窗口前面4章讲的都是“怎么识出来”这一章讲“识出来之后”包括界面长什么样、数据怎么存、道闸怎么控制、日志怎么留。这些才是让一套系统真正能用的关键。5.1 前面板布局让现场操作员一眼看懂车牌识别系统的使用场景通常是岗亭操作员或者无人值守的自助通道。界面设计必须围绕“快速判断、能溯源”来做。我常用的布局是这样的左侧主区域实时视频流窗口画面里叠加识别框和车牌字符串。这里用的是IMAQ Image Display控件识别到车牌后直接在图像上画矩形框旁边写上识别结果。右侧信息区识别到的车牌号用大号字体显示至少48号下面是车牌类型、置信度、抓拍时间。车主的注意力通常就在这里字号小了现场看着费劲。顶部缩略图区保留最近一帧抓拍原图方便有争议时人工回看。下方通行记录表用Table控件或Listbox显示最近几十条车辆进出记录包括时间、车牌、放行状态。这个布局我调过三轮。最初我把识别结果放在表格里现场操作员说低头找半天后来改成大字显示他们才满意。界面UI的很多问题是“好不好用”的问题不是“有没有”的问题一定要站在操作员的角度调。5.2 生产者-消费者架构界面不卡的关键这是LabVIEW车牌识别程序能不能稳定运行的胜负手。识别一帧图像预处理加上DLL调用短则一两百毫秒长则半秒以上。如果你在一个While循环里同步做完“抓帧→识别→刷新UI”那界面刷新频率就被拖到了每秒2帧左右操作员看到的画面是跳帧的点按钮还要等识别完才响应。我用的是经典的生产者-消费者模型生产者循环只负责IMAQdx Grab、复制图像、做基础预处理然后把图像数据打包成簇用Queue函数入队。消费者循环从队列取出图像做精处理、定位、分割、DLL识别把识别结果再入一个结果队列。UI循环用事件结构处理按钮同时轮询结果队列拿到新结果后刷新视频显示和文字信息。队列可以缓冲若干帧图像我一般设10帧的缓冲深度这样偶发性的处理超时不会导致丢帧。这个架构在LabVIEW里不算复杂但初学者很容易忽略结果就是程序一跑起来CPU占用100%界面卡成PPT。改成分层结构后CPU占用降到30%左右界面流畅度完全不一样。5.3 MySQL落库LabSQL或ODBC连接实践识别结果要留下记录MySQL是性价比很高的选择。LabVIEW连接MySQL主要有两种方式LabSQL第三方工具包轻量支持通过ODBC访问MySQL自带一堆封装VI我早期项目用的就是它。Database Connectivity ToolkitNI官方工具包通过ODBC或ADO连接数据库函数更规范但需要正版授权。无论哪种方式第一步都是在Windows里配置ODBC数据源或者直接用连接字符串。用LabSQL时候连接字符串长这样Driver{MySQL ODBC 8.0 Unicode Driver};Server192.168.1.100;Databasecar_plate;Userroot;Passwordyour_pwd;Option3;建表我一般这样写CREATE TABLE vehicle_record ( id INT PRIMARY KEY AUTO_INCREMENT, plate VARCHAR(10) NOT NULL, plate_type VARCHAR(20), confidence FLOAT, pass_time DATETIME, image_path VARCHAR(255) );写库的时机是识别校验通过之后。注意LabVIEW里操作数据库要小心连接句柄的释放每次执行完SQL要关闭连接否则长时间运行会堆出一堆失效连接。我在系统里也做了开机自动重连逻辑启动时检测数据库连接失败就重试并先缓存到本地临时文件等连接恢复后再补写避免因为数据库短暂不可用丢记录。5.4 串口道闸控制帧格式、CRC16和大小端道闸、门禁这类设备最常见的是RS232/RS485串口通信。LabVIEW里用VISA函数VISA Configure Serial Port设置波特率、数据位、停止位然后VISA Write发指令VISA Read收返回。实际项目里我遇到过控制协议里带CRC校验的情况于是自己写了一套帧格式字段长度内容示例帧头2字节0xAA 0x55命令字1字节0x01 表示开闸数据长度1字节0x02数据N字节如车道编号CRC162字节校验码低字节在前帧尾2字节0x0D 0x0ACRC16在LabVIEW里实现我用的是查表法。多项式0x8005Modbus CRC-16常用查表法的核心逻辑可以写成公式节点里的几行代码crc (crc 8) ^ table[(crc ^ byte) 0xFF];每取一个字节做一次上述运算最后得到的crc就是校验值。查表法比逐位运算快得多而且代码量小维护起来也方便。大小端是另一个容易踩的坑。串口协议里很多整数是低字节在前小端LabVIEW的数值类型默认是高位在前发出去就反了。处理方法是先用Join Numbers这类函数把数值拆成字节再手动调换顺序。大端小端不一致这个问题我见过不少同行在联调时被坑到怀疑设备坏了。5.5 日志记录每天自动生成一个TXT系统运行日志非常重要尤其是无人值守的场景。我的日志做法很简单每天一个文本文件文件名用日期生成比如20250614.log。在LabVIEW里用Get Date/Time In Seconds拿到时间戳Format Date/Time String格式化然后拼接路径用File Open/Create/Replace File创建当天文件后面循环里每次写一行日志写完关闭文件。日志内容至少包括操作员动作开闸确认、手动放行、识别事件车牌、置信度、错误信息数据库连接失败、相机断流。这个看似不起眼的习惯帮我在现场排查问题时节省了大量时间——系统半夜出了个怪问题第二天翻日志就能定位到是哪一帧、哪个模块出了岔子。6. 实测中反复踩的坑从启动卡死到识别飘移的系统性排查最后这部分我把自己在多个项目中真实遇到、而且网上经常被问到的问题整理一下每一个都是拿实际调试时间换来的教训。6.1 LabVIEW启动卡死和安装路径问题我自己遇到过启动画面卡住不动的情况后来排查发现是机器上同时装了多个LabVIEW版本和多个不同年份的NI驱动启动时版本冲突导致界面卡死。处理办法是把旧的、冲突的NI软件全部卸干净再用NI Package Manager统一装同一年的全套工具包。另外杀毒软件拦截NI授权服务和驱动加载也会导致启动卡住把NI相关目录加白名单基本能解决。显卡驱动过旧也有可能导致界面刷新卡顿更新驱动后恢复正常。6.2 程序打包后找不到驱动的经典坑LabVIEW写的程序在自己电脑上跑得好好的用Application Builder打成exe换一台机器一启动就报错说找不到VISA、找不到相机驱动。这是因为打包时没有把运行时依赖附加上去。解决办法是在Build Specification的属性里找到“附加安装程序”相关选项勾选NI-VISA Runtime、Vision Runtime等组件这样生成的安装包在目标机器上会自动安装这些驱动运行时。位数也要确认如果程序用了64位DLL目标机器上的运行时也必须是64位版本32位程序去调用64位DLL会直接加载失败。6.3 识别率忽高忽低和内存不断增长识别率不稳定最常见的根源是固定阈值和光照变化。早上的低角度阳光、中午的强顶光、晚上的路灯都会让画面亮度、色温大幅变化。我后来把颜色阈值和亮度参数做成前面板控件让现场人员按时间段标定几组参数程序里根据当前时间自动切换识别率稳定多了。内存持续增长的问题多是因为图像句柄没有被正确释放。Grab循环里如果每次都新建图像对象、用完又不释放跑上几小时就会内存耗尽。解决方法是在循环外面创建好图像控件和图像句柄循环内用IMAQ Copy把帧复制到同一句柄上覆盖使用最后在程序退出前用IMAQ Dispose释放不再需要的图像。这个优化做完我那个系统连续跑了三天内存占用稳定在1.2G左右不再上涨。6.4 一张排查速查表我把常见问题整理成一张表现场调试时可以直接对着排查现象可能原因常用解决方法启动卡在NI LOGO多版本冲突、杀毒拦截、显卡驱动旧清理旧版本、白名单、更新驱动打开相机Session报错相机驱动没装、USB3带宽不够、设备被占用装官方SDK驱动、换USB3口、检查其他程序占用调用DLL报“无法加载”32/64位不匹配、依赖缺VC运行库统一位数、安装运行库、确认调用约定识别率夜间骤降补光不足、白平衡漂移加补光灯、固定白平衡、切换夜间参数CPU占用高、界面卡顿识别逻辑阻塞UI循环改生产者-消费者架构长时间运行内存涨图像句柄泄漏复用句柄、及时Dispose数据库写入失败连接未释放、MySQL服务中断启动重连、失败缓存机制如果让我重做一遍我第一天就会把生产者-消费者架构写死把相机句柄和图像句柄统一管理别让“先跑通再说”变成以后重构的债。识别率这件事宁可先放一个手动阈值控件在现场慢慢调也不要指望一套参数吃一年四季。这套系统上线后的三个月里我最大的体会是车牌识别系统界面的每一块布局都要为现场操作员考虑而识别核心的每一次改动都要先在历史抓拍图上回归测试一遍确认没有把之前调好的场景弄坏。系统稳定运行的核心从来不是某一个惊艳的算法而是每个环节都不掉链子。