尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

DeepFace 人脸对齐性能调优:从超时到秒回的三个层级改法

DeepFace 人脸对齐性能调优:从超时到秒回的三个层级改法 DeepFace 人脸对齐性能调优从超时到秒回的三个层级改法【免费下载链接】deepfaceA Lightweight Face Recognition and Facial Attribute Analysis (Age, Gender, Emotion and Race) Library for Python项目地址: https://gitcode.com/GitHub_Trending/de/deepface上周我接了个考勤接口500 张工牌照丢给DeepFace.find()API 网关 5 秒超时直接被踢改成实时摄像头预览更惨每帧都走检测、对齐、embedding帧率掉到个位数预览窗口像在看幻灯片。查下来发现瓶颈基本都卡在人脸对齐这条链路上而不是识别模型本身。DeepFace 是一个 Python 轻量人脸识别库支持人脸验证、年龄/性别/情绪/种族分析、以图搜人。它的所有入口函数verify、analyze、find、extract_faces都默认alignTrue也就是默认做人脸对齐。这篇只聊一件事DeepFace 人脸对齐慢的时候怎么分层拆开逐层还债。DeepFace 支持的检测后端全家福速度档位差很多是性能优化里最大的变量先拆问题慢在三个互相独立的环节对着deepface/modules/detection.py源码看alignTrue时一条调用链上实际发生三件费钱的事环节源码行为开销来源① 垫黑边再检测对齐前用copyMakeBorder给原图上下左右各垫 0.5 倍边距检测器在4 倍像素量的画布上跑一张 1000×1000 变成 3000×3000② 逐张人脸三次方插值旋转align_img_wrt_eyes里cv2.warpAffine(..., INTER_CUBIC)每多检测出一张脸就多一次旋转③ 眼点兜底二次检测ssd 等后端不输出眼点会按脸再调一次opencv.find_eyes多脸图片上开销翻倍外加一个独立变量检测器选型。默认opencvHOG速度最快但偏弱mtcnn、retinaface更准但慢一个量级。四笔账互不耦合可以单独处理、单独验证。配置层不改一行逻辑只动三个参数detector_backend→ 按场景选档位一行改动# 考勤核验场景默认 opencv 检测 保持对齐 res DeepFace.verify(a.jpg, b.jpg, detector_backendopencv)opencv默认值就是速度档要兼顾速度和多人脸稳定性用mediapipeyolov11n自带眼点、不需要眼点兜底retinaface/mtcnn留给离线跑精度基准别用在实时链路上。具体数值视场景而定但慢后端用在实时路径上这个组合本身就不成立。align→ 照片本身端正的场景直接关掉# 证件照、工牌照本来就摆正关掉 align 跳过垫边放大 旋转 res DeepFace.verify(id1.jpg, id2.jpg, alignFalse)为什么敢关关掉后环节①②整体消失检测器退回原图尺寸工作代价是歪头照片的 embedding 质量下降。倾斜自拍、监控抓拍这类场景别关。expand_percentage→ 保持默认 0只有检测框切边时才给 5# 默认 0 就是最省的做法只有框裁掉耳朵/下巴时再加 5 faces DeepFace.extract_faces(photo.jpg, detector_backendopencv)取值逻辑它只扩大裁剪区域扩大后的裁剪照样要过对齐旋转再喂给识别模型而识别模型内部本来就会 resizepad 到目标尺寸所以加大的裁剪基本是白算。调用层refresh_database 和 batched 两个开关DeepFace.find()的refresh_database默认True——每次调用都会把 db 目录和 pkl 缓存做一遍同步500 张的库没变也照跑。这是很多人没改任何模型却突然变慢的原因# 修改前每次调用都重新同步数据库缓存 hits DeepFace.find(new.jpg, db/, refresh_databaseTrue) # 修改后库不变时吃缓存只有入库新数据那一次才传 True hits DeepFace.find(new.jpg, db/, refresh_databaseFalse)缓存 pkl 就躺在 db 目录里文件名编码了模型、检测器、是否对齐等全部参数——改任何一项参数都会生成一份新缓存首跑反而更慢测性能时注意把首跑时间排除掉。大库几千张以上再加一个开关# 大库场景 batchedTrue 走批量路径少构造 pandas 表格 hits DeepFace.find(new.jpg, db/, refresh_databaseFalse, batchedTrue)环境层先把输入图缩下来检测器耗时基本随像素数走4000×3000 的原图直接喂进去光检测就要吃掉大半预算# 长边压到 1024 以内再交给 DeepFace检测开销直接降一个量级 img cv2.imread(raw.jpg) scale 1024 / max(img.shape[:2]) if scale 1: img cv2.resize(img, None, fxscale, fyscale) res DeepFace.analyze(img, actions(age, gender))识别模型输入固定尺寸小脸够用的前提下这一步对准确率影响很小。至于 GPU识别模型走 TensorFlowGPU 可用时确实能省时间但检测端是 OpenCV/ultralytics 的 CPU 实现居多cv2.cuda能用的编译版很少别把希望押在这一层。验证闭环一个 10 行脚本确认钱花在哪from deepface import DeepFace t {} t[align_on] DeepFace.verify(a.jpg, b.jpg, alignTrue, silentTrue)[time] t[align_off] DeepFace.verify(a.jpg, b.jpg, alignFalse, silentTrue)[time] t[opencv] DeepFace.verify(a.jpg, b.jpg, silentTrue)[time] t[mediapipe] DeepFace.verify(a.jpg, b.jpg, detector_backendmediapipe, silentTrue)[time] for k, v in t.items(): print(k, f{v:.3f}s)verify返回值自带time字段不用自己计时。判断标准align_off比align_on少 30% 以上说明大头在环节①②且你的照片场景允许关对齐——就关。mediapipe与opencv差距不大但多人脸场景更稳且识别抽查没有明显误判就换后端。两者都没改善回到调用层查refresh_database是不是在空转。选型速查参数组合一张表场景detector_backendalignrefresh_database离线高精度核验retinafaceTrueFalse考勤/证件核验opencvFalseFalse实时视频流mediapipe 或 yolov11nFalse不适用不用 find大库以图搜人opencv按照片质量False batchedTrue核心动作就三件关掉不必要的 align、把检测后端换到速度档、让数据库缓存别空转。clone 下来先跑一遍上面的验证脚本再决定动哪一层git clone https://gitcode.com/GitHub_Trending/de/deepface【免费下载链接】deepfaceA Lightweight Face Recognition and Facial Attribute Analysis (Age, Gender, Emotion and Race) Library for Python项目地址: https://gitcode.com/GitHub_Trending/de/deepface创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表