改进Hough梯度与轮廓匹配的红外瞳孔检测（99.8%精度）

简介：面向图像处理与计算机视觉领域研究人员与工程师的一份算法研究文档，聚焦红外视频中瞳孔中心与直径的高精度检测难题。文件为单个 PDF（约1.04MB），完整呈现 Hough-Contour 算法的设计思路：先对每帧图像灰度化与滤波去噪，再用改进的 Hough 梯度法初步定位瞳孔，随后在瞳孔附近做位置与半径可变的圆轮廓匹配，从而精确求解中心坐标与直径。文中给出了关键实现细节与参数取值，如轮廓移动与伸缩范围取初始半径的1/10、点对数取40，精确匹配率由 OpenCV 圆变换的约10%提升至99.8%，并可借助累积值阈值自动剔除闭眼帧；低端设备处理320×240视频每帧约60ms，高端设备可实时处理640×480视频。已有170人学习，适合具备 Hough 变换基础、需要复现或改进瞳孔检测方案的读者参考。

1. 从「10% 精度」这个尴尬数字说起

红外视频瞳孔检测这件事，很多人第一反应是调 OpenCV 的HoughCircles，几行代码就能出圆心和半径，看上去挺省事。但真把红外视频跑起来，问题立刻暴露：同一段视频里瞳孔直径的抖动幅度能到真实值的十分之一量级，换算成精度只有 10% 左右，做心理健康研究或疲劳监测的课题根本不敢拿这个数写结论。这套基于 Hough 变换与轮廓匹配的瞳孔检测方案（Hough-Contour）要解决的正是这个问题：先用改进的 Hough 梯度法把瞳孔「框」到大概位置，再用受限范围的圆轮廓匹配把圆心和直径「精修」到位，把 10% 的精度拉到 99.8%，同时保证 320×240 的红外视频在低端机器上、640×480 在主流配置上都能跑进实时。它适合正在做图像处理方向毕设、课程设计，或者要给出一份能交付的瞳孔检测方案的读者参考——尤其是那种导师会追问「你这个精度怎么证明」的场合。

2. 算法总体设计：从一帧图像到瞳孔参数的六步流水线

整套方案的处理对象是红外眼动视频的连续帧，输入是一帧原始图像，输出是这一帧里瞳孔的圆心坐标 (x, y) 和直径 d。中间被拆成六个有明确职责的步骤，前后串行、单帧独立，不做跨帧的卡尔曼滤波之类的平滑，理由是跨帧耦合会让「闭眼帧排除」这类判据变得难以验证，出了问题不好定位。

这六步是：灰度化、滤波去噪、边缘提取、Hough 梯度初检、轮廓匹配精修、参数输出。前四步负责「找到瞳孔在哪」，第五步负责「瞳孔到底多大多准」，第六步把结果连同时间戳落盘。下面把每一步的设计取舍讲清楚，代码和参数放到后面的章节。

2.1 输入预处理：灰度化与滤波去噪的取舍

红外视频本身是近红外波段成像，颜色信息几乎为零，所以第一步毫不犹豫走灰度化。真正的取舍在滤波：滤波核太小压不住传感器噪声，核太大又会把瞳孔和虹膜之间的灰度跃变抹平，而后面轮廓匹配正是靠这一圈灰度跃变在做文章。

最终采用 5×5 的高斯平滑。这个尺寸在 320×240 帧上大概对应瞳孔半径的十分之一到五分之一，既能压掉红外相机那种椒盐感的噪点，又保留了边缘的梯度方向信息，不至于让后面的 Canny 把瞳孔边缘连成一片糊。滤波顺序上，先灰度化再滤波，而不是反过来，因为彩色图上做高斯会引入不必要的通道间耦合，耗时也多出两倍。

需要注意的是，红外成像存在「暗瞳」和「亮瞳」两种模式：暗瞳下瞳孔比虹膜暗，亮瞳下因为视网膜反光，瞳孔中心反而是亮的，形成一圈亮环。这套方案的轮廓匹配部分默认按暗瞳写（外圈减内圈为正、取最大值），如果换到亮瞳数据，方向要反过来，这一点在第 4 章给代码的时候会重点标注，很多同学直接照抄然后发现结果全错，就是栽在这里。

2.2 改进 Hough 梯度法：把降序排序换成求最大值

Hough 梯度法（也就是 OpenCV 里HoughCircles背后的那套实现）本身的流程是：先算每个像素的 Sobel 梯度和梯度方向，沿梯度方向在参数空间里投票累积，得到一个候选圆心累积数组，再把候选圆心按累积值降序排一遍，从头往后逐个试算半径，试到合格的就返回。

这套流程在工程上有个很明显的浪费：排序的目的只是拿累积值最大的那个候选圆心，而这是典型的最大值查询，一次线性扫描就能拿到，根本不需要 O(n log n) 的排序。更关键的是，排序之后的半径试算也会被牵连——原来要对多个候选圆心分别算半径，现在只要对最大值那一个算，半径计算的次数直接掉下来。

这就是本方案在 Hough 阶段做的第一处改动，也是耗时能从「看着卡」压到 60ms 一帧的主要原因之一。改动本身不复杂，但它把「实时」这个指标从高端机专属变成了低端机也能吃到，这个差别在做课设答辩的时候很关键，因为实验室的机器普遍不是顶配。

2.3 轮廓匹配：位置与半径受限范围内的圆轮廓比对

Hough 给出的圆心和半径是「粗解」，误差往往集中在 ±若干个像素。轮廓匹配的任务是在这个粗解附近做一次精细搜索，把圆心和半径都往真实值上拉。

搜索空间被有意限制得很小：圆心 x、y 各在 ±d 范围内移动，半径 r 也在 ±d 范围内伸缩，d 取初始半径的十分之一。在这个小立方体里，对每一个候选 (x, y, r)，沿圆周均匀取 k 个角度，每个角度上取内外两个点——内点在半径 r-1 处，外点在半径 r+1 处，算它们的灰度差，把 k 个点的灰度差取平均，作为这个候选圆的匹配得分。暗瞳场景下，瞳孔内部暗、边缘外侧较亮，所以「外减内」的均值越大，说明这圈位置越贴合真实的瞳孔边界，得分最高的那个候选就是最终结果。

这个设计的巧妙之处在于它绕开了 Hough 变换的一个天生缺陷：Hough 在参数空间里投票，投票是离散的，半径的量化步长决定了它的精度上限，想把精度提上去就得加密参数空间，耗时指数级上升。轮廓匹配直接在原始灰度图上算灰度差，用的是连续量，精度不受量化步长限制，只要搜索步长够细、点数够多，就能把精度做上去。两段分工，一段管「在哪」，一段管「多准」，各干各擅长的事。

2.4 两段式分工为什么比一次检测更靠谱

有一种很自然的疑问：既然轮廓匹配这么准，为什么不直接用它，跳过 Hough？答案是搜索空间。轮廓匹配要在大范围里搜索圆心和半径，复杂度是 O(n³)，一帧算下来几十秒都不一定够；把 Hough 放在前面，相当于用很低的代价把搜索起点从「整张图」压缩到「初始圆心附近半径十分之一的小立方体」，轮廓匹配的搜索量直接降了三个数量级以上。

反过来也一样成立：只用 Hough，精度上不去；只用轮廓匹配，时间下不来。两段式不是把两个算法堆在一起凑工作量，而是各自补上对方的短板，这是这套方案在结构上最值得写进毕设第一章「算法设计」小节的地方。

提示：如果导师问「为什么不用深度学习直接回归瞳孔参数」，可以从数据量、可解释性、算力三方面回答——这套方案不依赖训练集，参数的物理含义明确，且能在低端机跑实时，这三点在课题场景下往往是硬约束。

3. 改进 Hough 梯度法：最大值查找、半径计算与闭眼帧排除

第 2 章讲了为什么改，这一章讲怎么改，代码给到能直接对着写的程度。Hough 梯度法这一段有三个交付点：候选圆心最大值查找、半径计算、以及借累积峰值顺手做掉的闭眼帧排除。

3.1 累积数组的最大值查找替代降序排序

原始实现对候选圆心的处理是「排序 → 遍历 → 逐个试半径」，改成「扫一遍找最大值 → 只对最大值算半径」之后，候选圆心的处理和半径计算这两块的时间一起掉下来。下面这段是替换后的核心逻辑，用的是 C 风格伪代码，套到 OpenCV 的IplImage或者cv::Mat上都行。

// 候选圆心累积数组的一次线性扫描：用最大值查找替换降序排序 int maxAccum = 0; int bestIdx = -1; for (int i = 0; i < centerCount; i++) { if (accum[i] > maxAccum) { // 累积值更大就更新，等价于取排序后的第一个 maxAccum = accum[i]; bestIdx = i; } } // 峰值为负或过小，说明这一帧根本没有明显的圆形结构，直接判为闭眼帧 if (bestIdx < 0 || maxAccum < MIN_ACCUM_THRESHOLD) { return FRAME_CLOSED_EYE; // 交给上层跳过，不进入轮廓匹配 } cx0 = centers[bestIdx].x; // 初始圆心 x cy0 = centers[bestIdx].y; // 初始圆心 y r0 = centers[bestIdx].r; // 初始半径随最大值圆心一并给出

accum是 Hough 累积数组里每个候选圆心对应的投票值，centerCount是候选数量，MIN_ACCUM_THRESHOLD是闭眼判据的阈值，取值通过实验扫出来（第 3.3 节给参考区间）。这段代码的价值不只在省了排序：它把「候选圆心的选择」和「半径的计算」两步合成一步，r0直接从最大值对应的候选里带出来，后面不再有第二次半径试算，等于同时砍掉了两段的耗时。

还有一点容易被忽略：排序会改变候选的顺序，如果后续逻辑依赖「第一个合格候选」这种语义，排序结果和最大值结果在极端情况下可能不一致。本方案直接取最大值，语义更干净，复现实验时也不会因为排序稳定性出现偶发的差异。

3.2 半径计算与闭眼帧排除的联动设计

闭眼帧的处理是红外瞳孔检测里绕不过去的现实问题。受试者一眨眼，瞳孔被眼睑盖住，边缘检测出来的是眼睑轮廓，Hough 照样能投出一堆票，如果不加判别，算法会一本正经地输出一个错误的直径，而且这个错误值往往很离谱，混在时间序列里非常扎眼。

这里的做法是利用 Hough 累积峰值天然带有的「置信度」含义：瞳孔是强圆形结构，累积峰值高；闭眼时圆形结构消失，峰值明显偏低。所以在最大值查找的同时顺手卡一个阈值，低于阈值就整帧丢弃，不进入轮廓匹配。这个判据几乎是零成本的，因为它复用了本来就要算的累积值。

// 闭眼判据：累积峰值低于阈值直接丢弃，避免输出离谱直径 #define MIN_ACCUM_THRESHOLD 30 // 经验值，320x240 与 640x480 分别标定 int isClosedEye(int maxAccum) { return (maxAccum < MIN_ACCUM_THRESHOLD) ? 1 : 0; }

阈值的标定方法在 3.3 节展开，这里先记住一个原则：阈值不要写死一个数跨分辨率用。320×240 和 640×480 的累积数组量级不一样，候选圆心数量差四倍，峰值分布也跟着变，两套分辨率各标一次是必须的。

3.3 参数标定与耗时实测

把这一段涉及的关键参数整理成表，方便对照着改。表里的数值来自 320×240 和 640×480 两种分辨率下的实测标定，换数据集要重新扫一遍，但量级可以参考。

耗时方面，在 1.86GHz 单核、1GB 内存这一档的低端机器上，320×240 的帧处理一帧约 60ms，640×480 翻倍还多；换到主流配置，640×480 也能压进实时线以内。这个数据在写毕设的「实验与分析」章节时非常有用，因为它同时说明了算法的时间复杂度和工程可用性，比单写「本算法效率较高」这种空话有说服力得多。

真正做的时候还有一处细节值得写进设计说明：Canny 的双阈值和 Hough 的半径范围是联动的。低阈值调低会让边缘变多，Hough 的候选圆心数量随之上升，最大值查找的循环次数增加，单帧耗时会爬上去；所以调参不能只看精度，要看「精度—耗时」这条曲线，找到拐点再定。

4. 轮廓匹配实现：d = r/10、k = 40 与 99.8% 的精度账

如果只能保留这套方案里的一个设计点写进答辩 PPT，我会选轮廓匹配的参数标定，因为它是精度从 10% 跳到 99.8% 的直接原因，也是导师最容易追问「你这个数怎么来的」的地方。这一章把点对采样、搜索循环、参数扫描三块讲透。

4.1 点对采样公式与灰度差的物理含义

在初始圆心 (x0, y0)、初始半径 r0 的基础上，对每个候选圆 (x, y, r)，沿圆周均匀取 k 个角度 θ，每个角度取一对点：内点落在半径 r-1 上，外点落在半径 r+1 上。用公式写出来是这样：

内点：p = (x + (r-1)·cosθ, y + (r-1)·sinθ)

外点：p' = (x + (r+1)·cosθ, y + (r+1)·sinθ)

匹配得分是这 k 对点的灰度差均值：S = (1/k) · Σ [f(p') - f(p)]。

为什么是 ±1 像素而不是 ±2 或 ±3？因为瞳孔边界本身在红外图里就是一到两个像素宽的灰度跃变带，取 ±1 正好跨在这条带的两侧，能拿到最大的灰度差；取太远会跨到虹膜纹理或者眼睑上，灰度差反而被稀释。这个 ±1 不是随便定的，它和预处理的高斯核尺寸也有关系——5×5 的高斯会把跃变带撑宽一点，±1 刚好够。

为什么用均值而不是总和？因为边缘附近的点可能越界（超出图像范围），越界的点对要丢弃，留下来的点对数 k 在不同候选之间可能不一样，用总和会让点对多的候选占便宜，用均值才公平。这一点在写代码时很容易翻车，第 5 章会作为避坑点展开。

4.2 三层搜索循环与提前剪枝

搜索空间是圆心 x、y 各 ±d，半径 r 也是 ±d，d 取 r0/10。三层循环套起来，最内层再做 k 次点对采样，这是整套算法里计算量最大的一段，也是耗时的主要来源。代码骨架如下：

const double PI = 3.14159265358979; const double thetaStep = 2 * PI / k; // 圆周采样步长，k 为采样点数 const int d = r0 / 10; // 搜索范围：初始半径的十分之一 double bestScore = -1e9; int bx = cx0, by = cy0, br = r0; for (int r = r0 - d; r <= r0 + d; r++) { // 半径伸缩 if (r < 1) continue; // 半径必须为正 for (int x = cx0 - d; x <= cx0 + d; x++) { // 圆心横向移动 for (int y = cy0 - d; y <= cy0 + d; y++) {// 圆心纵向移动 double sum = 0.0; int cnt = 0; for (double th = 0; th < 2 * PI; th += thetaStep) { int xin = (int)(x + (r - 1) * cos(th)); int yin = (int)(y + (r - 1) * sin(th)); int xout = (int)(x + (r + 1) * cos(th)); int yout = (int)(y + (r + 1) * sin(th)); // 任一点越界，这一对点整体丢弃 if (xin < 0 || yin < 0 || xout < 0 || yout < 0) continue; if (xin >= w || yin >= h || xout >= w || yout >= h) continue; sum += (double)pix(xout, yout) - pix(xin, yin); // 暗瞳：外减内 cnt++; } if (cnt <= 200) continue; // 有效点对太少，候选作废 double avg = sum / cnt; // 用均值消除点数差异 if (avg > bestScore) { // 暗瞳取最大，亮瞳改取最小 bestScore = avg; bx = x; by = y; br = r; } } } }

几个参数要点拆开说。thetaStep由 k 决定，k 越大采样越密，得分越稳，但耗时线性上升；cnt <= 200这个剪枝条件是针对 320×240 以下的小图，作用是把圆心靠近图像边缘、大量点对越界的候选提前踢掉，避免它们的得分把最优点带偏；bestScore初始化为负无穷，因为暗瞳场景下灰度差均值可以接近零甚至为负，用 0 初始化会漏掉真正的最优解。

暗瞳与亮瞳的方向问题在这里必须再强调一次：上面写的是外减内、取最大值，对应暗瞳（瞳孔内部暗、外侧亮）。如果换成亮瞳数据，同一段代码要把比较方向改成取最小值，或者把被减数和减数对调，否则算法会稳定地收敛到虹膜外沿而不是瞳孔边缘，结果看上去「有输出」但全错，排查起来极其痛苦。

4.3 参数扫描：k 和 d 是怎么定下来的

这套方案里最有说服力的部分，是参数不是拍脑袋定的，而是扫出来的。实验思路很直接：保持 d 不变，让 k 从 10 开始以 10 为步长往上扫，记录精确匹配率；再固定 k，让 d 从 r0/40 一路变到 r0/2，记录匹配率和耗时。

结果呈现出很清晰的两个结论。第一，k 到 40 之后匹配率基本饱和，再往上加只是白白增加耗时，所以 k 取 40 是性价比拐点。第二，d 取 r0/10 时匹配率已经逼近上限，继续放大 d 匹配率不再提升，但搜索体积按三次方膨胀，耗时暴涨；d 太小又盖不住 Hough 初检的偏差，匹配率反而掉下去。r0/10 正好卡在「覆盖初检误差」和「不浪费搜索量」之间。

这张表是答辩时最有用的东西，因为它回答了「为什么是 40 和 r0/10」这个一定会被问到的问题：不是因为文献这么写，而是因为扫出来就是这个拐点。做课设的时候，把这张表换成自己数据集上重跑的版本，说服力会更强。

5. 避坑与常见问题排查：五个最容易翻车的地方

这一章按「现象 → 原因 → 解决」的方式写，都是我在这类项目里真实见过的翻车现场。有些坑不写出来，照着前面的代码抄也能跑，但结果就是不对，而且不对得很隐蔽。

5.1 闭眼帧输出离谱直径

现象：时间序列里隔一段冒出一个明显偏离的直径值，肉眼看原始帧明明是闭眼。原因：MIN_ACCUM_THRESHOLD用了 640×480 标定的值去跑 320×240 的数据，累积数组量级对不上，闭眼帧根本没被判出来；或者阈值定得太低，闭眼时眼睑轮廓也能凑出足够的票数。解决：两种分辨率各标一次阈值，标定方法是拿一段包含明显眨眼的视频，手工标注闭眼帧，统计闭眼帧和正常帧的累积峰值分布，阈值取两条分布的交叠区偏保守一侧。

5.2 轮廓匹配收敛到虹膜外沿

现象：输出的直径系统性地偏大，而且偏得很稳定，不是随机抖动。原因：亮瞳数据用了暗瞳的比较方向，算法把所有「外亮内暗」的强边缘都当成了瞳孔边界，虹膜外沿恰好符合这个特征。解决：先确认数据的瞳孔极性——看瞳孔中心比周围亮还是暗，暗瞳用外减内取最大，亮瞳用内减外取最大，或者统一改成取灰度差绝对值的最大值，代价是可能被眉毛、睫毛的强边缘干扰，所以更推荐按极性分开处理。

5.3 点对越界导致得分失真

现象：瞳孔靠近图像边缘时，匹配结果明显往图像中心偏。原因：内层循环里越界点没有正确处理，有的是直接跳过但没减cnt，有的是把越界坐标截断到边界上继续算，两种都会让得分偏向「点对多」的候选。解决：严格按照 4.2 的写法，越界就continue，不累加sum也不累加cnt，最后用sum / cnt的均值；再补一个cnt <= 200的剪枝，把有效点对太少的候选整体作废。

5.4 耗时忽高忽低

现象：同样分辨率的视频，有的段 40ms 一帧，有的段 200ms 一帧。原因：Hough 的候选圆心数量和图像内容强相关，画面纹理复杂（比如受试者戴眼镜、有反光）时候选数量暴涨，最大值查找的循环变长；另外 Canny 低阈值调得太低也会让边缘数量失控。解决：先看候选数量这个中间量，把它打印出来做监控；再考虑给候选数量设上限，或者按帧内容动态调 Canny 阈值。别一上来就怀疑代码写错了，多半是输入数据的统计特性变了。

5.5 精度复现不出来

现象：论文里的 99.8% 自己怎么跑都是 90% 出头。原因：精确匹配率的定义没对齐——是「圆心误差小于 1 像素且直径误差小于 1 像素」的帧占比，还是「相对误差小于 1%」的帧占比，两种定义差很多；另外测试集里闭眼帧算不算进分母，也会显著影响结果。解决：先把评价口径写死在代码里，用同一份标注数据跑，跑之前把口径写进实验记录；复现别人的数字之前，先复现别人的口径。

注意：这五条里，第 5.2 和第 5.5 是最容易在答辩现场被追问的，前者关系到算法正确性，后者关系到实验严谨性，提前准备好解释。

6. 验收与答辩：怎么证明 99.8% 不是编的

验收这件事，最忌讳只报一个数字。我的做法是把验收拆成三层，每层都有可复现的产出物，答辩时按层往外拿。

第一层是精度验收。准备一份人工标注的小测试集，至少覆盖正常帧、闭眼帧、瞳孔靠近边缘帧三类，每类不少于 50 帧。标注只需要圆心和直径，用任意图像工具点两下就行，工作量可控。然后写一个对比脚本，同时跑「纯 OpenCV Hough 圆变换」和「Hough-Contour」，输出两条误差曲线。这一步的产出是精度对比表，能直接回答「提升多少」这个必问题。

第二层是时间验收。别用「感觉挺快」这种描述，直接在代码里插计时点，用系统级的高精度计时接口取每帧耗时，输出均值、95 分位、最大值三个统计量。均值好看不代表体验好，95 分位才是用户真正感受到的卡顿。这一步的产出是耗时分布表，配合分辨率写清楚测试机器的配置档位。

第三层是鲁棒性验收。故意构造几段「坏数据」：闭眼占比高的、有镜片反光的、瞳孔部分出画的，看算法是崩掉还是优雅降级。合格的表现是闭眼帧被正确丢弃、反光帧精度下降但不发散、出画帧返回无效标记而不是瞎猜一个值。这一步的产出是异常帧处理记录，答辩时最能体现工程思维。

有一个细节我踩过：计时一定要在「读帧之后、写结果之前」这段区间内取，不要把视频解码和文件 IO 算进去，否则数字会被 IO 噪声污染，答辩时被问一句「你这个时间包不包含解码」就露馅了。从那以后我每次做这类算法验收，都强制把计时点打在算法入口和出口，并且把这段代码单独抽成一个可复用的计时宏，再也不靠临时加printf凑数。希望这套验收思路能帮到你，把方案从「能跑」推到「能交付」。

本文还有配套的精品资源，点击获取