简介这是基于Python实现的数字图像处理课程大作业——疲劳检测完整方案面向计算机、人工智能、自动化等专业学生也适合作为课程设计、毕业设计或项目初期演示。方案覆盖眨眼、打哈欠、打电话、侧视等典型疲劳与分心状态识别代码可直接运行并输出检测结果。整个压缩包共254个文件以6个py源码为程序核心配240个avi检测过程录屏、png效果图、pdf与docx文档说明及md笔记压缩包整体约300MB目录结构便于按模块查阅。目前已有543人学习下载代码经过测试成功配合录屏可快速理解疲劳检测算法的实现思路也可在其基础上扩展其他视觉识别功能文档与样例覆盖完整适合作为数字图像处理项目的实践参考。1. 疲劳检测项目拆解一个能跑通的 Python 课设该有的样子做数字图像处理课程大作业的人多数卡在同一个地方算法听懂了但不知道怎么写成一个能演示、能答辩、能拿分的完整项目。这套基于 Python 的疲劳检测源码是我见过少数把检测链路走完整的课设资源——它不只做了人脸关键点提取而是把闭眼、打哈欠、转头这几个疲劳征兆都量化成指标最后还能输出带有红框和状态文字的标记视频。对正在选课设题目的在校生或者想快速搭一个疲劳检测 Demo 做前期验证的从业者这套代码能省掉至少两周的调试时间。你不用从零开始拼 OpenCV 和 dlib 的调用链也不用纠结眼睛闭合到底怎么判断才不算误报项目里已经给了一套能跑通的答案。2. 核心检测原理从人脸关键点到疲劳特征的三条量化路径这套项目能输出eye_closed_res_16.avi、yawn_res_25.avi这类带状态标记的视频靠的不是玄学而是把疲劳特征转换成了可计算的数值指标。要理解这份源码得先弄清楚它内部跑的三条检测链路。2.1 眼睛闭合检测EAR 值是怎么算出来的疲劳检测里最核心的指标是 EAREye Aspect Ratio眼睛纵横比。它的原理并不复杂通过 dlib 的 68 点人脸关键点模型定位出眼睛的 6 个关键点——左眼角 2 个、右眼角 2 个、上眼皮 1 个、下眼皮 1 个。当人睁眼时眼睛的垂直距离和水平距离的比值维持在一个较大的数值当人闭眼时垂直距离骤减这个比值就会明显下降。项目里计算 EAR 的代码通常长这样def eye_aspect_ratio(eye): # 计算眼睛垂直方向的两组欧氏距离 vert_1 dist.euclidean(eye[1], eye[5]) vert_2 dist.euclidean(eye[2], eye[4]) # 计算眼睛水平方向的欧氏距离 horiz dist.euclidean(eye[0], eye[3]) # EAR 计算公式垂直距离之和 / (2 * 水平距离) ear (vert_1 vert_2) / (2.0 * horiz) return ear这段代码的逻辑很直接eye是从 dlib 检测结果里按固定索引取出的 6 个关键点列表。dist.euclidean是scipy.spatial库里的距离计算函数分别算出眼睛上眼皮和下眼皮之间的两组垂直距离再除以 2 倍的水平眼角距离。这个比值在睁眼时大约在 0.25 到 0.35 之间闭眼时会掉到 0.1 以下。参数说明代码里取点的索引顺序不能乱。dlib 的 68 点模型中右眼关键点的索引范围是 36 到 41左眼是 42 到 47。如果你从自己的模型里取点必须先确认索引顺序和这里一致否则算出来的 EAR 值会是错的。项目里为了让结果更稳定通常会对连续几帧的 EAR 值取平均再和一个预设阈值比较判定是否闭眼。2.2 打哈欠检测MAR 与嘴巴张开程度的阈值判断打哈欠的检测思路和闭眼类似但用的指标是 MARMouth Aspect Ratio嘴巴纵横比)。人的嘴巴周围有 6 个关键点左右嘴角各 2 个、上嘴唇 1 个、下嘴唇 1 个。打哈欠时嘴巴张大的程度会拉开上下嘴唇的距离MAR 值随之上升。项目中 MAR 的计算代码和 EAR 几乎同构def mouth_aspect_ratio(mouth): # 计算嘴巴垂直方向的两组欧氏距离 vert_1 dist.euclidean(mouth[2], mouth[6]) vert_2 dist.euclidean(mouth[3], mouth[5]) # 计算嘴巴水平方向的欧氏距离 horiz dist.euclidean(mouth[0], mouth[4]) # MAR 计算公式垂直距离之和 / (2 * 水平距离) mar (vert_1 vert_2) / (2.0 * horiz) return mar注意这里mouth取的是 6 个点不是 4 个。dlib 模型里嘴部关键点的索引范围是 49 到 60其中用于计算 MAR 的取点是mouth[2]、mouth[6]、mouth[3]、mouth[5]这 4 个垂直方向点加上mouth[0]、mouth[4]两个嘴角点。垂直距离算的是上下嘴唇之间的实际张开量水平距离算的是嘴巴宽度。正常说话时 MAR 在 0.2 到 0.3 之间打哈欠时通常超过 0.5。阈值设定的逻辑是设定一个MAR_THRESH当连续多帧的 MAR 值超过这个阈值就判定为一次打哈欠。这套项目里把这个阈值和最小持续时间帧数写成了可配置参数方便不同场景下调。如果要调灵敏度关键不是只看 MAR 单帧值而是看连续帧的累积——一帧嘴张大了可能是说话连续 10 帧都是张大状态才可能是打哈欠。2.3 转头检测与打电话识别姿态估计和手部区域的补充除了闭眼和打哈欠项目文件里的Phoning_res_01.avi和look_sideway_res_06.avi说明它还做了打电话和转头检测。转头检测用的是人脸关键点的几何关系——通过鼻尖、下巴、左右脸颊的坐标变化计算人脸朝向的偏转角。实现上一般会做一个简易姿态估计或者直接比较左右眼区域宽度来判断脸是不是侧过去了。打电话检测更依赖图像分类思路先定位人脸区域再把人脸下方的区域作为 ROI判断是否存在手机遮挡。常见做法是把这块区域的 HOG 特征或颜色直方图送入一个简单的分类器。这块在课设里不要求做到高精度能对固定场景的视频产生稳定输出就够用了。原理部分的重点是整套项目的疲劳判定不是靠某一个指标单帧触发的而是靠连续帧累积 多阈值组合。单帧的 EAR 掉到 0.1 可能是用户眨了一下眼只有 EAR 持续低于阈值超过 0.4 秒才判定为疲劳闭眼。这个时间窗口就是参数调优的核心。我在跑这套代码的时候会先去数一下视频里真实闭眼的帧数再倒推代码里的阈值和持续帧数设置是否合理——这一步对答辩时的参数为什么这么设特别有用。3. 把项目跑起来环境配置、代码入口与运行链路拿到这套源码之后最急迫的问题是怎么让它立刻出结果。项目本身是给别人答辩用的说明文档和代码都齐全但运行步骤还得落到自己的机器上。这里我拆一下环境搭建和运行链路照着做基本一次能过。3.1 环境准备与依赖库版本选择疲劳检测项目对环境的敏感度很高尤其是 dlib 库的安装。先用requirements.txt或直接在终端安装核心依赖pip install opencv-python dlib numpy scipy imutils注意 dlib 库的版本兼容性。Python 3.8 以上环境装 dlib 时经常遇到编译失败我的建议是优先用conda install -c conda-forge dlib而不是pip install dlib。conda 会帮你处理 CMake 和 C 编译器的依赖pip 装的话Windows 上必须先装 Visual Studio Build Tools。另外imutils是方便做图像缩放和转动的工具库scipy提供euclidean距离计算这两个少一个都可能报ImportError。3.2 源码入口文件与检测主循环项目的核心入口通常是一个main.py或detect.py文件运行方式很简单python main.py --input video/eye_closed_res_16.avi --output output/主循环里做的事情是按照人脸检测 - 关键点定位 - 特征计算 - 状态判定 - 画框标记的顺序逐帧处理。代码结构大致是这样的# 初始化 dlib 的人脸检测器和关键点预测器 detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) # 打开输入视频 cap cv2.VideoCapture(args.input) while True: ret, frame cap.read() if not ret: break # 统一缩放帧尺寸提升检测速度 frame imutils.resize(frame, width600) gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 人脸检测第二个参数是向上采样次数 faces detector(gray, 0) for face in faces: # 获取 68 个关键点坐标 landmarks predictor(gray, face) # 提取左右眼的 6 个关键点 left_eye [landmarks.part(i) for i in range(42, 48)] right_eye [landmarks.part(i) for i in range(36, 42)] # 分别计算左右眼的 EAR 值并取平均 left_ear eye_aspect_ratio(left_eye) right_ear eye_aspect_ratio(right_eye) ear (left_ear right_ear) / 2.0 # 判定是否闭眼并在画面上标记 if ear EYE_THRESH: cv2.putText(frame, Eye Closed, (x, y - 10), ...)代码里的shape_predictor_68_face_landmarks.dat是关键点模型文件项目资源里一般会配套给出没有的话需要单独下载大约 90MB 的模型。运行时你会在终端看到逐帧打印的 EAR 值和判定结果如果你想让现场演示更直观可以把cv2.imshow加进来实时弹出画面窗口。参数说明detector(gray, 0)的第二个参数表示向上采样次数调成 1 能提高小脸的检测率但帧率会下降。imutils.resize(width600)是把画面压到 600 像素宽这一步能显著降低计算量。如果原视频是 1080p不做缩放直接跑 dlib慢的时候一秒钟只能处理一两帧——这也是我建议演示时先把视频分辨率调低的直接原因。3.3 输入的测试视频和输出文件的关系项目自带的视频文件命名其实已经透露了检测逻辑。eye_closed_res_16.avi对应闭眼检测的结果视频yawn_res_25.avi是打哈欠检测的结果Phoning_res_01.avi是打电话检测。这些res视频是用你下载的源码配合预置测试视频跑出来的演示结果。而对应的输入视频文件也就是检测前的原始视频你必须自己准备或从项目里找。我一般会这样梳理项目里至少包含两个目录source/放原始未处理的视频output/放检测后的标记视频。运行main.py时传入source/eye_closed_16.avi作为输入程序处理完会在output/下生成eye_closed_res_16.avi。如果你收到的资源里只有结果视频没有输入视频那说明作者只传了演示产物你可以用自己的手机录一段 10 秒的视频来测试——这反而是更稳妥的做法因为你能预判画面里什么位置会出现闭眼和哈欠验证代码判定准不准。4. 避坑与排查这个项目里最容易翻车的四个细节课设能跑通和能稳定复现是两回事。我把这套项目在学习和答辩阶段最常见的坑整理成排查记录每一条都是实际跑的时候会遇到的问题。4.1 dlib 编译失败一装库就报错现象pip install dlib执行到一半报CMake must be installed或error: command swig.exe failed。 原因Windows 环境下 dlib 需要从源码编译Python 环境缺少 C 编译器支持。 解决不要硬磕 pip。装conda后用conda install -c conda-forge dlib能在几秒内拉预编译好的二进制包。如果你已经把项目环境装在 venv 里就新建一个 conda 环境再装别在原有环境里反复折腾。这就花两分钟比源码编译省两个小时。4.2 程序跑起来但没有任何检测框现象视频播放正常画面里明明白白有人脸但终端输出的 EAR 值全是 0画面没有任何红框。 原因shape_predictor_68_face_landmarks.dat模型文件没有加载成功或者文件路径写错。代码里dlib.shape_predictor(shape_predictor_68_face_landmarks.dat)会相对当前工作目录找文件如果模型文件不在当前目录运行不报错但返回空结果。 解决用绝对路径加载模型或者启动前检查模型文件是否存在于运行目录。我习惯在代码开头加一个os.path.exists判断文件不存在就打印路径并退出避免跑到一半才发现问题。4.3 视频帧率很低一卡一卡的现象测试视频跑得很慢画面每 2 到 3 秒才会跳一下。 原因你没有对输入帧做缩放。1080p 的视频直接送进 dlib 检测器和 68 点关键点定位器单帧推理需要几百毫秒再加上画框和打印信息整体帧率只有 3 到 5 FPS。 解决强制在代码前部加frame imutils.resize(frame, width600)。如果你处理的视频里人脸比较小可以改为 800 宽度如果人脸占画面比例很大缩到 400 也不影响检测。这一步能把单帧处理时间砍掉 70%。4.4 闭眼判定有延迟眼睛闭上了 1 秒才提示现象视频里人物已经明显闭眼但画面上的疲劳提示要晚半秒到一秒才出现。 原因代码里对连续帧的持续时间做了累计。假设EYE_CLOSED_FRAMES 15视频 30 FPS那么要等 15 帧连续低于阈值才会触发闭眼标记这就是 0.5 秒的滞后来源。 解决这不是 bug是防误报设计。如果需要在答辩演示时反应更灵敏把EYE_CLOSED_FRAMES从 15 调到 8 或 5。注意帧率不同这个参数效果也不同30 FPS 下 15 帧是 0.5 秒60 FPS 下就是 0.25 秒调整前先确认视频帧率。5. 验证与二次开发让这个课设从 80 分变成 96 分跑通只是第一步。决定课设拿高分和答辩不露怯的是你能否讲清楚参数依据和展示验证过程。这个项目能延伸的空间不小。5.1 自己录制测试视频的验证流程我把项目的验证流程固定成了三步你照着做基本能应对答辩提问。第一步用手机横屏录一段 20 秒的测试视频内容包含连续 5 秒正常睁眼、5 秒闭眼、5 秒打哈欠、5 秒转头。第二步用ffprobe或者播放器查看视频帧率记住这个数值。第三步运行main.py把检测出的闭眼哈欠帧数和视频里实际帧数做对比。# 验证脚本统计 output 视频中检测到闭眼的帧数占比 import cv2 cap cv2.Capture(output/my_test_res.avi) total_frames 0 closed_frames 0 while True: ret, frame cap.read() if not ret: break total_frames 1 gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 这里是简化写法实际判断需要复用项目里的 EAR 计算函数 if ear EYE_THRESH: closed_frames 1 print(f闭眼帧占比: {closed_frames / total_frames * 100:.1f}%)这段脚本能帮你量化检测效果。假设你录制的视频里闭眼占 25% 的时间检测输出里闭眼帧占比在 22% 到 28% 之间说明阈值设置合理。如果占比低于 20%说明阈值偏高漏检了如果高于 35%可能是把眨眼误判成了闭眼。5.2 往课设里叠加一个新检测用 ROI 区域做打电话识别项目自带的打电话检测如果做得比较简单你有余力可以自己升级一版在答辩时能多讲一个改进点。常见做法是把人脸框下方 30% 的区域作为 ROI计算这块区域的 HOG 特征训练一个简单的 SVM 分类器判断有没有手机遮挡。from sklearn.svm import SVC # 假设已收集 phone_roi 和 no_phone_roi 两组样本特征 X_train np.vstack([phone_features, no_phone_features]) y_train np.hstack([np.ones(len(phone_features)), np.zeros(len(no_phone_features))]) # 训练分类器 clf SVC(kernellinear) clf.fit(X_train, y_train)新增这个模块时要保证拼接特征的维度一致。phone_features和no_phone_features必须都是相同数量的特征向量否则vstack会报错。这个改进本身还有提升空间但作为课设里在原代码基础上做的优化已经比单纯照搬源码的演示效果更丰富了。5.3 答辩时最值得讲透的三个技术点答辩时讲技术点与其面面俱到不如抓住三个能引起老师兴趣的细节。第一个是 EAR 的几何变换原理——为什么水平和垂直距离的比值能消除头部到摄像头的距离影响这是数字图像处理课上几何变换的最好应用案例。第二个是连续帧计数器的防误报机制——为什么单帧判断不可靠这体现你对工程稳定性的思考。第三个是帧率与阈值的联动关系——为什么 30 FPS 视频和 15 FPS 视频要用不同的EYE_CLOSED_FRAMES这证明你真的调过参数而不是背了一段答案。从那以后我每次做图像处理相关的课设都会先跑通一条最简单的检测链路再考虑加新的功能。这个项目的源码帮我建立了从检测到标记再到输出的完整流程感也让我学会了怎么用参数解释结果。希望这篇拆解能帮你把项目跑顺答辩时有底气讲清每一个数字的来历。本文还有配套的精品资源点击获取