相机都调麻了，缺陷还是漏检，问题到底卡在哪？
产线一开，缺陷开始漏。
相机参数调到手麻，画面还是糊。
老板站在旁边问：“能不能再快一点？”
现场最怕这种局面。
设备在跑，客户在等，产线不可能陪你慢慢试错。
工程师盯着屏幕看了半天，第一反应往往是：
“是不是帧率不够？”
“是不是相机不行？”
“要不要换个更高端的？”
别急。
很多视觉项目翻车，不是因为相机太差，也不是因为算法太菜。
而是从一开始，大家就没搞清楚一个基础问题：
你的相机节拍，到底有没有跟上产线节拍？
1. 先别急着调参数，帧率到底是啥？
现场一说“帧率”，很多人脑子里就两个字：
快点。
但机器视觉里，“快”也分对象。
面阵相机，看的是一张一张图。
它一拍，就是一整张图。
所以面阵相机的帧率，也就是 FPS，意思很直白：
每秒最多能拍多少张。
比如 15 FPS，就是一秒最多拍 15 张。
这个逻辑很像拍照：
来一个产品，咔嚓一张。
再来一个，再咔嚓一张。
但线阵相机就不一样了。
线阵相机，一次只拍一行像素。
很多行不断拼起来，最后才变成一张长图。
所以线阵相机不主要看 FPS，而是看：
行频，Line Rate。
也就是每秒能扫多少行。
工程上经常用 kHz 表示。
比如 50 kHz，大约就是每秒 50,000 行。
注意，现场有时有人口头说“50 赫兹就是 5 万行每秒”，这句话严格讲不准。
他实际想表达的，一般是50 kHz。
一句话记住：
面阵看“张数”，线阵看“行数”。
别把两套逻辑混在一起。
混了，后面选型就容易一路跑偏。
2. 帧率不是越高越好，而是要跟上速度
视觉项目里有个特别朴素的原则：
相机的拍摄速度，要大于等于被检物的到达速度或移动速度。
听起来像废话。
但现场很多坑，就死在这句“废话”上。
面阵：一件来一张，FPS要跟上件数
如果是按件触发，产品一个一个过来。
那就很简单：
FPS ≥ 件/秒。
比如一秒来 3 个产品，相机至少要能稳定拍 3 张。
但项目现场不能只看“刚刚够”。
因为产线有抖动，触发有波动，节拍有峰值。
所以一般最好留余量，常见做法是乘上1.2～2的系数。
别把系统压在极限边缘跑。
现场不会因为你公式算得刚刚好，就对你温柔一点。
线阵：皮带一直走，行频要跟上线速度
如果是皮带、辊道、卷材这种连续移动场景，就要看行频。
公式很好用：
行频（行/秒）=线速度（mm/s）物方像素尺寸（mm/像素） \text{行频（行/秒）}=\frac{\text{线速度（mm/s）}}{\text{物方像素尺寸（mm/像素）}}行频（行/秒）=物方像素尺寸（mm/像素）线速度（mm/s）
举个现场常见的算例：
皮带速度是2000 mm/s。
物方像素尺寸是0.05 mm/px。
那么：
2000/0.05=40,000 2000 / 0.05 = 40,0002000/0.05=40,000
也就是需要40 kHz的行频。
这时候你再去问“相机 FPS 多少”，方向就有点歪了。
线阵项目真正要盯住的是：
线速度、物方像素尺寸、行频三者有没有匹配。
3. “FPS够了还糊”？多半要查曝光
有些项目更气人。
工程师一查，帧率够。
触发也正常。
图像还是糊。
这时候别急着怀疑人生。
要看另一个关键变量：
曝光时间。
运动模糊，通常不是“拍得不够快”，而是“曝光太久”。
物体在曝光期间还在动。
它一边动，相机一边收光。
最后图像自然被拖成一片。
想把运动“冻住”，曝光时间TeT_eTe要足够短。
条件可以这样估：
Te≤b×物方像素尺寸线速度 T_e \le \frac{b \times \text{物方像素尺寸}}{\text{线速度}}Te≤线速度b×物方像素尺寸
这里的bbb，就是你能接受的模糊像素数。
想拍得越清楚，曝光时间就要越短。
但问题来了：
曝光越短，进光越少。
这就会把另一个问题拽出来：
光不够。
所以很多现场会出现这种经典对话：
“我把曝光降下来了。”
“图像清楚了吗？”
“清楚一点，但黑了。”
“那加增益？”
“噪声上来了。”
这就是视觉项目的真实世界。
参数不是孤立的。
你动一个，另外几个马上来找你聊天。
解决方向也很明确：
更亮的光源。
更合适的镜头和相机。
必要时用频闪，并且和触发同步。
4. 帧率、分辨率、接口带宽：一根绳上的蚂蚱
现场还有一种常见翻车：
相机参数看起来都对。
软件里一跑，掉帧。
分辨率一拉高，图像开始卡。
帧率一提，接口直接吃不消。
这时候锅可能不在算法，也不在镜头。
而在数据吞吐。
同一台相机里：
分辨率越高，位深越大，帧率越高，数据率就越大。
数据一大，接口就可能“呛住”。
面阵相机可以这样粗算：
数据率（B/s）≈宽×高×位深（Byte）×FPS \text{数据率（B/s）} \approx \text{宽} \times \text{高} \times \text{位深（Byte）} \times \text{FPS}数据率（B/s）≈宽×高×位深（Byte）×FPS
线阵相机可以这样粗算：
数据率（B/s）≈行宽（像素）×位深（Byte）×行频 \text{数据率（B/s）} \approx \text{行宽（像素）} \times \text{位深（Byte）} \times \text{行频}数据率（B/s）≈行宽（像素）×位深（Byte）×行频
别忘了，实际项目里还要加上10%～30%的协议和系统开销。
举个面阵例子：
1920×1080，8-bit，60 FPS
数据率大约是：
2,073,600 px/帧×1 B×60≈124 MB/s 2,073,600 \text{ px/帧} \times 1 \text{ B} \times 60 \approx 124 \text{ MB/s}2,073,600px/帧×1B×60≈124MB/s
看上去不夸张。
但1 GigE实际可用吞吐常在约 100 MB/s左右。
这就已经开始吃紧了。
这时候还想稳定跑，USB3、5 GigE、10 GigE 会更稳。
现场可以先用这组经验值快速估算：
- GigE≈ 100 MB/s
- 2.5/5/10 GigE≈ 250/500/1000 MB/s
- USB3.0/3.2 Gen2≈ 350–400 / 800–900 MB/s
- Camera Link/CoaXPress：每通道数百 MB/s 到 1 GB/s 级，适合“高分辨率 × 高帧率”
所以，别一上来就喊“我要高分辨率，还要高帧率”。
可以。
但接口、主机、写盘、算法都得跟上。
不然相机在前面拼命吐数据，后面系统接不住。
最后现场看到的，就是掉帧、卡顿、延迟和一堆不稳定。
如果既要高分辨率，又要高帧率，通常有几条路：
上更大带宽接口。
用多通道。
降低分辨率或 ROI。
降低位深。
必要时做压缩。
别硬扛。
视觉项目最怕的不是难，而是方向错了。
5. 真正靠谱的选帧率流程
别靠感觉选相机。
也别靠“别人项目这么用过”来套。
现场最稳的方式，是按流程一步步算。
第一步：定目标清晰度
先明确你要看清什么。
最小缺陷多大？
需要多少像素表达？
物方像素尺寸是多少？
也就是先确定mm/px。
没有这个，后面谈帧率和行频都容易飘。
第二步：看运动参数
面阵项目，看件/秒。
线阵项目，看线速度 mm/s。
别把“产线很快”这种描述当参数。
项目要落地，必须变成数字。
第三步：面阵按件算
如果一件一拍：
FPS≥件/秒×余量系数(1.2–2) \text{FPS} \ge \text{件/秒} \times \text{余量系数(1.2–2)}FPS≥件/秒×余量系数(1.2–2)
如果每件要连拍多张，那就再乘以每件所需张数。
第四步：线阵按行频算
线阵就用这句：
行频=线速度物方像素尺寸 \text{行频}=\frac{\text{线速度}}{\text{物方像素尺寸}}行频=物方像素尺寸线速度
算出来就是你需要的行频，通常换算成 kHz 来看。
第五步：算数据率
别只看相机标称能跑多快。
要把数据率算出来。
再加10%～30%的余量。
第六步：选接口
数据率别把接口卡死。
该上 USB3 就上 USB3。
该上高速以太网就上高速以太网。
高分辨率高帧率项目，该考虑 Camera Link 或 CoaXPress 就别犹豫。
第七步：验光照
短曝光一定要更强光。
优先考虑可频闪光源，并且和触发同步。
第八步：上触发和编码器
面阵用外触发，保证拍摄节拍。
线阵用编码器，让扫描和皮带“步步对齐”。
尤其线阵项目，不用编码器闭环，很容易出现图像被拉伸或压缩。
6. 高帧率不是免费午餐
高帧率听起来很香。
但项目现场会提醒你：
所有性能，最后都要付成本。
光要更亮
曝光时间短，单位时间收集的光就少。
你要么加更亮的光源。
要么提高增益。
但增益一上来，噪声也跟着上来。
数据更大
帧率越高，数据越猛。
主机能不能吃下？
SSD 写得动吗？
算法跑得过来吗？
驱动缓存够不够？
必要时，可以考虑边缘侧前处理、ROI，或者把位深从12-bit 降到 8-bit。
发热和稳定性要盯住
高帧率长期运行，会带来温升问题。
温度一上来，稳定性就要关注。
掉帧监控、散热设计，别等现场出问题再补。
快门类型别选错
运动场景优先考虑全局快门。
滚动快门要小心“歪楼”，也就是常说的果冻效应。
看着像图像变形，其实是成像时序在捣乱。
7. 面阵还是线阵？别拿锤子找钉子
相机选型，也别只盯着价格和参数表。
要看场景。
面阵相机：一张定胜负
面阵适合离散件。
比如一个产品过来，拍一张或几张。
它对姿态变化大的目标更友好。
触发也比较简单。
灯光布置相对直观。
线阵相机：连续表面更有优势
线阵适合连续场景。
比如布匹、箔材、管道、超宽幅表面。
只要线速度和行频匹配，就能拼出“无限长”的高分辨率图像。
但前提是：
编码器闭环要做好。
否则图像拉伸、挤压、比例不准，都会找上门。
8. 现场常见坑，逐个排查
下面这些问题，都是视觉项目里经常能见到的。
“FPS够了，但还是糊”
先查曝光时间是否超过允许值。
该补光补光。
该开频闪开频闪。
运动场景优先看全局快门。
“标称帧率达不到”
别只怪相机。
可能是接口带宽不够。
也可能是主机写盘跟不上。
还可能是驱动缓存太小。
可以尝试关后台软件、开 jumbo frame、直连，或者换更大带宽接口。
“线阵图像被拉伸或挤压”
重点查编码器。
编码器分辨率对不对？
齿轮比对不对？
线速度标定准不准？
线阵图像不是只靠相机扫出来的。
它要和运动系统配合。
“光源频闪干扰”
工频照明可能会拍出条纹。
这时候可以用直流供电，或者同步频闪。
“分辨率一调高就掉帧”
别只调一个参数。
ROI、位深、触发模式、驱动缓冲要一起看。
视觉项目不是单点参数游戏，而是系统工程。
9. 两个30秒心算例子，现场够用
面阵例子
产线速度是90 件/分钟。
换算一下：
90/60=1.5 件/秒 90 / 60 = 1.5 \text{ 件/秒}90/60=1.5件/秒
如果一件一拍，取余量系数 1.5：
1.5×1.5≈2.3 1.5 \times 1.5 \approx 2.31.5×1.5≈2.3
也就是说，约 2.3 FPS就够用。
如果每件要拍 3 张，那就至少要：
2.3×3≈7 2.3 \times 3 \approx 72.3×3≈7
也就是≥7 FPS。
线阵例子
行宽4096 px。
位深8-bit。
行频50 kHz。
数据率大约是：
4096×1×50,000≈205 MB/s 4096 \times 1 \times 50,000 \approx 205 \text{ MB/s}4096×1×50,000≈205MB/s
这个量级，就该考虑 USB3、高速以太网或 CoaXPress 了。
10. 最后一句：帧率不是参数，是节拍
帧率和行频，本质上就是相机吞吐的节拍。
它必须跟上你的产线节拍。
也必须满足你的清晰度要求。
同时还不能忘了两个“副本”：
带宽。
光照。
很多视觉项目，不是败在不会调参数。
而是败在一开始没有把这几件事算清楚：
产品跑多快？
要看多细？
曝光能不能压下来？
光够不够？
接口扛不扛得住？
主机和算法吃不吃得下？
最后，再把几个名词对齐：
- 帧率 = FPS，主要看面阵相机
- 行频 = Line Rate，主要看线阵相机，常用 kHz
- 面阵相机 = Area Scan
- 线阵相机 = Line Scan
视觉项目最怕的不是问题难。
而是大家在现场忙了一天，最后才发现：
根因根本不在算法，也不在相机，而在最开始的节拍和系统匹配没算清。
下次再遇到“拍不清、掉帧、漏检”的现场，先别急着狂调参数。
先问一句：
我们的相机节拍，真的跟上产线了吗？
你在视觉项目里遇到过最离谱的帧率、曝光或带宽问题是什么？评论区聊聊。
