工业视觉采集与识别：从硬件、图像算法到客户交付

这是一项我长期投入、独立推进核心研发的工程项目：面向美术考试与画室阅卷，将工业相机、图像算法、Windows 客户端和后台业务连成完整流程。我同时负责整体硬件方案设计与软硬件集成，围绕不同客户的使用条件，持续打磨参数调校、识别、裁切、图片压缩、人工复核和交付维护。

项目已有客户现场交付，并做过千张级连续采集识别的稳定性验证。下面结合已交付能力与最新研发迭代展开：重点呈现图像处理中的关键取舍，以及让算法稳定服务于客户业务的工程方法。

先看全景：一套系统要接住完整业务

一次看似简单的“拍照并识别”，实际需要同时回答很多问题：画面有没有更新？纸张方向是否正确？身份码是否仍完整？分数是否需要人工确认？压缩后的图片是否就是这条记录对应的文件？文件已上传时，后台是否真的接收了这条业务？

我的工作覆盖这些环节之间的衔接。设备负责稳定提供画面，图像处理负责生成可用素材，识别负责提供候选结果，客户端负责操作与核对，上传流程负责确认业务完成。每一层都保留可以追踪的输入、状态和结果。

采集与参数：让调节真正作用于成像

参数设置不仅是几个滑块。相机侧需要处理曝光、增益、白平衡和饱和度，软件侧还要处理画面方向、镜像与预览。参数之间存在关联：拉高亮度可能掩盖浅色笔画，增益过高也可能引入噪声，不能只凭屏幕上“更亮了”判断效果。

把界面参数映射到设备能力

读取相机支持的参数范围，再将界面值映射到设备节点；曝光与增益按现场可用区间处理，白平衡区分自动与手动配置，记录实际写入结果，便于判断设置是否真正生效。支持预设复用、相机配置导入和读取驱动值，扫描间隔、镜像及画质配置可在本地恢复。

预览与抓拍共用图像变换规则

统一镜像、旋转和标准帧处理，配置变化后等待匹配的新帧，避免界面已经调整、抓拍却拿到旧画面或旧方向。

把连续作业作为采集设计的一部分

对初始化和抓拍做串行保护，处理暂停、恢复与连接异常。抓拍先写临时文件，重新解码并检查尺寸后再提交，避免半写入文件进入后续识别。

自动裁切：应对反光、亮边与纸张边界

自动裁切是我投入较多的一部分。纸张、台面、灯光和反光会共同影响边界：画面里的亮色区域不一定是纸张，触边的矩形也不一定能完整保留内容。单一阈值或“找到第一个矩形就裁”很容易在现场失效。

裁切流程结合黑底、白边、亮度和边缘检测四类策略生成候选，随后综合纸张比例、面积、边距、填充率及四边内外的亮度关系排序。对画面边缘的灯带、反光和台面亮边进行抑制，减少它们与纸张合并成错误外接矩形的情况。

处理分辨率也需要分工：用长边约 800 像素的工作图做粗定位，再把透视变换作用于完整输入图，兼顾搜索成本与成品细节。最新的边缘精修在原图边界窄带采样、拟合四边，减少为找边而创建整幅原图大小中间矩阵的需要。

在后续迭代中，我继续细化原图边界上的局部精修和裁切前后身份码一致性检查。这类改进需要同时通过样本回归与现场验收，不能只用几张裁切效果图判断是否完成。

图像分工：原图、处理图、缩略图各司其职

我把“拍到的图”“算法使用的图”和“业务提交的图”分开管理。保留原始采集图，识别与裁切在工作副本上进行，结果另存；列表使用独立缩略图，避免每次浏览都解码整张大图。这里的“原图”指最初保存的采集文件，不意味着相机 RAW 或无损编码。

原始文件与处理结果通过内容哈希关联，识别前后检查原图是否被改写。需要复核、重新裁切或排查历史问题时，可以回到明确的源图，而不是在已经处理过的图片上反复叠加修改。

对导入照片明确执行一次 EXIF 方向校正，避免解码器和后续处理重复旋转。人工四点裁切先验证四边形，再将归一化顶点映射回原图像素做透视变换；图像改变后清理旧分数区域、身份遮挡坐标与上传状态，重新生成关联数据，防止新图继续沿用旧坐标。

识别链路：定位、数字与身份分别校验

识别包含两条相互关联的任务：确认这是谁的试卷，以及读出需要提交的手写分数。身份侧支持二维码与条形码，结合配置位置、图像方向及名单校验；分数侧先定位区域，再组织图像预处理与数字识别。

我使用 YOLO 定位分数区域，以 ResNet18 作为自动分数来源，使用 OpenCV 处理识别所需的图像输入，并通过 ONNX Runtime 在客户端本地执行。CRNN/CTC 则用于训练实验与旁路诊断，和生产自动接收分数保持区别。

分数候选、身份匹配、裁切风险和人工确认是不同状态。针对不确定结果提供复核入口，并为提交设置明确规则。在不需要识别分数的流程中，复用已经成功解析的身份结果，减少同一张图的重复处理；缩略图生成也复用已有哈希，减少不必要的大图读取。

这些优化的目标是减少重复计算，并保留可解释的结果。系统完成千张级连续运行验证，说明持续作业经过检验；识别准确率仍需要按真实样本分布独立评估。

图片压缩：在细节、体积与传输之间做取舍

图片编码质量会影响文件体积，也会影响细小笔画与纸面细节。我的实现把画质档位接入抓拍保存时的 JPEG 编码链路，使用明确的质量参数，而不是只改变界面标签。当前实现包含 75、85、90、95、100 等质量档位，供不同使用条件下选择。

这组数字是编码配置，不是压缩率或识别效果。实际文件体积还受到画面内容和分辨率影响。我把原始素材留存、工作副本处理和缩略图展示分别考虑，在查看流畅度、传输成本与后续复核所需的细节之间做平衡。

更重要的是，图片被重新处理后，旧上传记录不能继续代表新文件。压缩与裁切不只是图像算法问题，也会影响后续业务数据是否一致。

上传闭环：文件成功与业务成功分开确认

上传流程分为对象存储上传和后台业务确认两个阶段。文件进入云端之后，如果后台没有确认，记录仍然不能简单显示为完成；发生重试时，也不能把整套操作无条件再做一遍。

用内容身份确定能否复用上传进度

结合图片 SHA-256、记录身份与确定性的对象标识检查提交点。文件未变化时，可衔接后续后台确认；裁切或重新处理导致内容变化时，拒绝复用旧文件的进度。

处理批量任务中的局部成功

区分已成功、被拒绝、待确认与可重试记录。遇到批量名单错误时拆分定位，保留已得到确认的结果，避免一条异常记录让整批进度变得不可判断。

让取消与恢复保留已发生的事实

用户取消后，已经确认的成功或拒绝结果仍然落盘。本地记录、上传状态与会话恢复共同决定下次从哪里继续，减少重复提交和半完成状态。

硬件与客户：把完整方案带到实际使用中

我负责的不止客户端软件，也包括整体硬件方案设计与系统集成。设计时将成像条件、采集装置布局、设备连接、操作流程和维护便利性放在一起考虑，让硬件采集与软件识别服务于同一个业务目标。

面对多个客户的使用需求，我围绕现场条件开展方案适配、参数调试、软件部署与问题定位。客户关心的是连续作业是否顺畅、异常能否处理、结果能否核对，以及出现问题后是否有人能把整条链路查清楚。

因此，交付过程也反过来推动研发：从现场反馈中区分成像、裁切、识别、操作与网络问题，回看源图和对应日志，再决定调整参数、优化算法、修改交互还是补充验证。硬件、算法、客户端与运维由此形成一套持续改进的工作方式。

持续迭代：让现场问题进入可验证的改进

客户端使用 C#、.NET、WPF、MVVM 与分层架构，将设备接入、识别、存储、后台适配和界面分开。日志与诊断信息关联关键步骤；更新流程检查版本、包结构与文件散列，使后续维护能找到具体对象。

配套训练工作覆盖标注整理、数据版本、样本来源与重复组隔离、冻结测试集、PyTorch 训练、ONNX 导出和目标运行时复验。现场问题经过复盘与样本整理进入下一轮验证，模型与软件更新再按各自流程验收。这是由人工判断和工程检查串起的迭代闭环，不是无人审核的自动训练与发布。

在持续研发中，我也推进同源码的双产品隔离，拆分产品身份、会话、本地数据和更新通道。已有画室场景交付与新的产品适配分别验收，避免把完成构建当成已经完成现场交付。

本文按项目实现、迭代记录及本人交付经历整理；图示为工程流程或功能重绘。客户与硬件信息作概括描述，不披露客户名称、具体数量或设备型号。最新裁切精修与双产品适配仍按各自验证、验收进度推进。