OpenCV行人检测实战：HOG+SVM参数调优与DNN进阶指南

简介这是一份基于OpenCV内置方法的行人检测实战项目资源面向需要快速上手物体检测的初学者或正在完成相关课程设计的开发者能够帮助理解如何利用传统计算机视觉手段实现行人的识别与定位无需依赖深度学习框架即可入门。压缩文件共包含5个文件1个PDF说明文档用于讲解检测原理与代码结构1个Python可直接运行的检测脚本以及3张JPG测试图片用于检验和对比检测效果整体包大小约1.03MB轻量且便于下载。目前已有1340人学习该资源口碑和可读性初步得到验证。使用这份资源时读者可以从零开始搭建一个行人检测示例先通过PDF掌握OpenCV内置方法的基本流程与参数含义再运行Python脚本观察实际输出并借助多张测试图片分析不同场景下的检测表现。整个过程能帮助读者同时积累代码调试经验和目标检测的基础实践能力适合作为后续学习更复杂检测算法或深度模型的过渡参考。1. 物体检测实战OpenCV 内置方法做行人检测为什么不建议直接跑默认参数「物体检测实战使用OpenCV内置方法实现行人检测.zip」——这个标题把三件事说清楚了检测对象是行人技术栈锁定在 OpenCV 自带能力交付物是可以直接落地的代码包。用 OpenCV 做行人检测最快三行就能出效果加载官方默认行人检测器、绑定到 HOGDescriptor、detectMultiScale 扫一遍图。但真把这套默认参数扔到园区监控或者店门口的视频里大多数人第一反应是「这什么玩意儿」——框乱飘、树影当人、漏检严重帧率还掉到个位数。这个方案的价值恰恰在这里它是理解检测原理最好的入门素材也是做原型最快的一条路不需要训练、不需要深度学习环境CPU 就能跑。下面从原理到参数、从避坑到 DNN 进阶把它一次讲透。2. HOG 特征与 SVM 分类OpenCV 内置行人检测的原理与最小代码2.1 为什么说 HOGSVM 是「内置方法」的标准答案OpenCV 里的行人检测「内置方法」标准答案是 HOG 线性 SVM不是深度学习。HOG 全称方向梯度直方图思路很朴素把图像切成小块统计每一块里梯度方向的分布用这种统计特征描述人的轮廓。行人通常直立行走头肩和四肢的梯度分布有共性一个训练好的线性 SVM 就能把「像人的窗口」和「背景窗口」分开。OpenCV 在发布包里直接内置了一个在 INRIA Person 数据集上训练好的 SVM 系数向量不需要你自己训练、不需要权重文件cv2.HOGDescriptor_getDefaultPeopleDetector()一行取出来就能用。这个设计让行人检测在 OpenCV 里几乎没有门槛也正因为门槛低很多人拿默认参数跑完就开始怀疑人生。判断一个场景适不适合用内置方法就看两点检测对象是否姿态相对固定以及能不能容忍一定比例的误检。行人正好介于「固定」和「不固定」之间所以 HOG 能跑但需要调参数。在 opencv4.2 的环境里这套接口的命名已经非常稳定Python 和 C 行为一致下面的代码都是基于 4.x 写的。2.2 跑通第一张图detectMultiScale 最小代码与返回值的坑先让代码跑起来再聊调参。新建一个hog_detect_image.py把下面这段贴进去import cv2 # 创建 HOG 描述符并加载内置的行人检测 SVM 系数 hog cv2.HOGDescriptor() hog.setSVMDetector(cv2.HOGDescriptor_getDefaultPeopleDetector()) # 读图灰度化不是必须的但能省一点内存带宽 img cv2.imread(street.jpg) if img is None: raise IOError(图片读取失败检查路径) # 多尺度检测返回矩形框列表和对应的权重列表 rects, weights hog.detectMultiScale( img, winStride(4, 4), padding(8, 8), scale1.05, ) for (x, y, w, h) in rects: cv2.rectangle(img, (x, y), (x w, y h), (0, 255, 0), 2) cv2.imwrite(result.jpg, img) print(f检测到 {len(rects)} 个行人)逻辑说明cv2.HOGDescriptor()创建一个默认参数的 HOG 描述符setSVMDetector把官方训练好的 SVM 系数灌进去之后detectMultiScale在图像金字塔上滑动窗口逐一打分。返回的两个值分别是矩形框(x, y, w, h)列表和置信度权重列表权重越高代表越像人。这里有个新手必踩的坑detectMultiScale返回两个值如果你只写rects hog.detectMultiScale(...)会直接报ValueError: too many values to unpack。倒不是说 Python 不能接收多余返回值而是这个 API 在 OpenCV 4.x 里固定返回二元组习惯只接一个值的人十有八九会翻车。detectMultiScale 的核心参数语义如下表这些参数到视频阶段还要继续调参数默认值作用调参方向winStride(4, 4)滑窗步长越小检测越密越慢追求速度调到 (8, 8)padding(8, 8)窗口边缘填充缓解目标贴边问题一般不动scale1.05图像金字塔缩放系数越接近 1 层数越多越慢1.03~1.1 之间试finalThreshold2.0重叠框合并阈值相当于内置 NMS误检多时调大第一次跑通后建议做的事把scale改成 1.1 再跑一遍框的数量会有肉眼可见的变化这是感受金字塔缩放系数最直接的方式。2.3 认识 HOGDescriptor 的构造参数知道在哪调但先别动很多人查 OpenCV 文档时会看到 HOGDescriptor 有一大堆构造参数以为调它们能提升精度。实际上项目实战里这些参数很少动因为它们是 HOG 特征的骨架改了特征维度就变了原本训练好的 SVM 系数可能直接失效。# 默认参数显式写出来是这样的实际项目中很少手动改 win_size (64, 128) # 检测窗口尺寸行人默认 64x128 block_size (16, 16) # 归一化块大小 block_stride (8, 8) # 块滑动步长 cell_size (8, 8) # 胞元大小梯度直方图统计单位 n_bins 9 # 每个胞元的梯度方向分箱数 hog_custom cv2.HOGDescriptor( win_size, block_size, block_stride, cell_size, n_bins, )参数说明win_size决定了检测窗口最小尺寸如果你在 2.2 节用默认构造win_size就是 (64, 128)这也是为什么视频流里minSize一般不设小于这个值——窗口本身就那么大。block_stride和cell_size共同决定特征向量的长度改动任意一个SVM 系数维度就对不上了。所以我的建议是构造参数保持默认要调的是detectMultiScale的参数。如果真的需要更精细的特征比如检测远距离小目标优先考虑缩小输入图像而不是改 HOG 内部参数。内置检测器是「黑匣子」我们拿到的只是 SVM 系数不是训练代码改特征结构等于自己重新训练那就脱离「内置方法」的范畴了。3. 把检测搬到视频流摄像头与视频文件的行人检测实战骨架3.1 逐帧检测 跳帧 缩放的标准骨架静态图跑通之后下一个诉求几乎必然是「能不能跑视频」。直接对每一帧调用detectMultiScale不是不行而是大概率撑不住实时性。HOG 在 640×480 分辨率下单帧耗时通常在 50~150ms 之间也就是纯 CPU 上大约 7~20 FPS这还是在没有做其他图像处理的前提下。所以视频流的第一个实战动作是「跳帧」每 N 帧选一帧做检测中间的帧直接复用上一帧结果。对行人这种低速目标跳 1~2 帧完全够用。import cv2 cap cv2.VideoCapture(street.mp4) if not cap.isOpened(): raise IOError(无法打开视频检查路径和编码器) # 初始化 HOG 检测器 hog cv2.HOGDescriptor() hog.setSVMDetector(cv2.HOGDescriptor_getDefaultPeopleDetector()) skip 2 # 每 2 帧处理 1 帧 frame_idx 0 out cv2.VideoWriter( result.mp4, cv2.VideoWriter_fourcc(*mp4v), 15, (640, 480), ) while True: ret, frame cap.read() if not ret: break frame_idx 1 if frame_idx % skip ! 0: continue # 统一缩放HOG 对输入尺寸不敏感但缩放能显著降低耗时 frame cv2.resize(frame, (640, 480)) rects, weights hog.detectMultiScale( frame, winStride(4, 4), padding(8, 8), scale1.05, ) for (x, y, w, h) in rects: cv2.rectangle(frame, (x, y), (x w, y h), (0, 255, 0), 2) out.write(frame) cv2.imshow(pedestrian, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() out.release() cv2.destroyAllWindows()逻辑说明VideoCapture支持视频文件和摄像头索引video.mp4换成0就是读取默认摄像头。frame_idx % skip控制跳帧节奏skip2表示每两帧取一帧处理能把有效 FPS 感知提升一倍。resize到 640×480 是把推理耗时压到可控范围的关键一步HOG 的耗时和图像面积近似成正比分辨率减半耗时能降到原来的四分之一左右。这里有个容易忽略的点VideoWriter的输出分辨率和写入帧的分辨率必须一致否则合成的视频打不开。代码里把帧先 resize 再写入正好规避了这个问题。3.2 detectMultiScale 三个必调参数scale、winStride、minNeighbors视频骨架跑起来后紧接着就是调参。HOG 行人检测真正值得反复调的只有三个参数scale、winStride、minNeighbors。等等minNeighbors哪来的detectMultiScale在推理阶段没有这个参数它是cv2.HOGDescriptor.detectMultiScale内部通过finalThreshold做分组合并时隐含的逻辑。真正需要你手动调的是finalThreshold和上面两个参数。先看scale。它控制图像金字塔的缩放系数。scale1.05表示每层缩小到上一层的 95%行人越大需要的层数越多耗时越高。调节规律是目标在画面里普遍偏小时用 1.03~1.05目标离镜头近、占比大时用 1.1。一个经验值是scale从 1.05 改成 1.1耗时能下降 30%~50%但小目标漏检率会上升。再看winStride。它控制滑窗步长(4, 4)表示窗口每次移动 4 像素。步长越小窗口位置越密检测越细致但计算量成倍上涨。对于 640×480 的输入(8, 8)是一个速度与精度都比较平衡的起点。如果冷静评估后发现漏检不多但很卡先把winStride调大比调scale见效快。finalThreshold是重叠框合并阈值可以理解成内置的非极大值抑制强度。值越大越多的重叠框会被合并成一个误检会减少但两个人挨得太近时有可能被并成一个框。默认 2.0 在人群稀疏的场景够用密度大时建议保持默认通过置信度权重过滤见第 4 章而不是靠调大这个值来压误检。调参的顺序建议是先定winStride(8, 8)把速度稳住再根据漏检情况调scale最后用权重过滤处理误检而不是一上来三个参数一起改——那样出了问题根本不知道是谁的锅。3.3 让检测框跟得住人minSize、ROI 与框过滤的组合用法调完上面三个参数检测框基本能跟住人但还有一个高频问题远处的行人太小近处的行人太大总有一端是漏的。HOG 的检测窗口是固定 64×128输入图像里的人和这个尺寸差太多就会检测不到所以需要手动框定合适的尺寸范围。rects, weights hog.detectMultiScale( frame, winStride(8, 8), padding(8, 8), scale1.05, finalThreshold2.0, ) filtered [] for (x, y, w, h), weight in zip(rects, weights): # 权重太低说明只是有点像人过滤掉 if weight 0.5: continue # 尺寸明显不合理的人为框太扁、太大、太小都排除 if w 40 or h 100 or w 400 or h 500: continue # 长宽比在 0.3~0.8 之间才像直立行人 aspect w / h if aspect 0.8 or aspect 0.3: continue filtered.append((x, y, w, h))逻辑说明minSize和maxSize虽然可以直接传给detectMultiScale但在真实场景里固定尺寸上限会漏掉走近的近距离行人所以更稳的做法是检测完之后再做一轮过滤。weight是每个框的置信度zip(rects, weights)把它们配对遍历逐条判断是否保留。这套过滤条件里最实用的是长宽比判断行人直立时高宽比通常在 0.3~0.8 之间树影、垃圾桶、车窗反光的框往往高宽比离谱一个aspect判断能干掉一多半误检。镜头固定的话还可以再加 ROI 屏蔽把不可能出现行人的区域比如天空、树冠用黑色掩码盖住再送进检测器既能减少误检又能省时间。ROI 的做法很简单用cv2.fillPoly画个多边形区域置黑就行。4. 行人检测避坑5 个高频问题与排查路径4.1 No module named cv2anaconda prompt 里装完 opencv-python 还是报错现象在 anaconda prompt 里执行pip install opencv-python成功后运行脚本仍然报ModuleNotFoundError: No module named cv2。原因几乎都是环境错位。anaconda prompt 默认进的是base环境你 pip 装的包进了 base但运行脚本用的解释器是另一个虚拟环境或者机器上有多个 Pythonpip 装到了 A 版本命令行跑的是 B 版本。还有一种情况是包名和导入名不一致——安装包叫opencv-python导入名是cv2网上很多教程混着写新手容易以为自己装错了包。解决先确认当前环境再装包。conda activate your_env pip install opencv-python python -c import cv2; print(cv2.__version__)最后一行能打印版本号说明环境没问题。如果下载慢可以加国内 pip 镜像源pip install opencv-python -i https://pypi.tuna.tsinghua.edu.cn/simple。注意装完不要关闭当前 prompt 窗口另开新窗口会导致环境变量重新加载偶尔会出现「明明装了却 import 不到」的假象。4.2 detectMultiScale 返回值解包失败ValueError: too many values to unpack现象单独接收rects hog.detectMultiScale(img)时代码直接抛异常提示返回值太多。原因detectMultiScale在 OpenCV 4.x 的 Python 绑定里始终返回(rects, weights)二元组这是 API 设计决定的不是代码写错。解决用rects, weights hog.detectMultiScale(img)接收如果不需要权重就写rects, _ ...。这里有个细节权重虽然叫 weight但数值能到 0.6~2.0 以上不是 0~1 的概率值所以第 3.3 节里用weight 0.5做过滤是安全的不会误伤正常的检测框。4.3 误检框乱飞树影、招牌当成行人怎么压下来现象固定机位视频里树的晃动、路牌、空调外机被反复框出来而且框的位置每帧都跳。原因HOG 特征描述的是梯度分布很多竖条状物体的梯度分布和行人轮廓高度相似线性 SVM 打不出足够高的置信度差异。默认参数下finalThreshold2.0只做了框合并没有做置信度筛选所以「有点人样」的物体全被放出来了。解决在detectMultiScale返回值上叠加两层过滤。第一层按置信度权重过滤第二层按几何约束过滤长宽比、面积上下限。分步骤操作先打印所有rects和weights看看误检框的权重普遍落在哪个区间再决定阈值。常见做法是权重阈值的初始值取 0.5然后根据打印结果上下微调。如果误检还是压不下去基本可以断定是场景本身太杂HOG 的上限到了直接跳到第 5 章换 DNN 模型。4.4 视频流卡成 PPT单帧耗时的估算与跳帧策略现象跑视频时 FPS 只有个位数画面严重卡顿甚至跟不上实时画面。原因HOG 单帧 640×480 推理耗时随场景复杂度变化很大行人多、背景纹理丰富时能达到 150ms逐帧处理当然卡。另一个隐蔽因素是scale和winStride太激进等于把计算量全砸在金字塔和密集滑窗上。解决先量化再优化。写一段测速代码看看你的机器和场景下真实耗时是多少import time start time.perf_counter() rects, weights hog.detectMultiScale(frame, winStride(8, 8), scale1.05) elapsed_ms (time.perf_counter() - start) * 1000 print(f单帧推理耗时: {elapsed_ms:.1f} ms) # 目标实时率假设是 15 FPS每帧预算 66ms budget 1000.0 / 15 max_skip max(1, int(elapsed_ms / budget)) print(f建议跳帧数: {max_skip})逻辑说明先测出单帧耗时的量级再用耗时除以目标帧预算得到跳帧数。比如单帧 120ms目标 15 FPS那就是 66ms/帧的预算120 / 66 ≈ 2跳 2 帧可以达到感知上的实时。这里算的是「处理节奏」不是把每帧的处理时间压进预算因为跳帧意味着中间帧直接复用上一帧的检测结果CPU 占用率是下降的。如果测出来单帧超过 300ms说明你的场景不适合继续调 HOG 了考虑缩小输入分辨率到 480×360或者直接换 DNN 方案。4.5 Linux 装 CUDA 版 OpenCV 太折腾HOG 加速到底值不值现象网上教程说用 CUDA 版本 OpenCV 能给 HOG 加速结果装的时候发现pip install opencv-python只有 CPU 版本要 GPU 加速就得从头 cmake 编译步骤繁琐还容易编译失败。原因官方 pip 包的约定就是 CPU 版本CUDA 支持需要自己在 Linux 源码编译。cmake 编译步骤本身不难难的是 CUDA、cuDNN、OpenCV 三者版本要匹配任何一个对不上就白跑几个小时。解决我的建议是先把第 4.4 节的测速结果拿出来算笔账。如果你只是做原型验证或者小规模部署HOG 在 CPU 上跑到 10 FPS 配合跳帧已经够用犯不着为它上 CUDA。如果确实有低延迟需求更值的路径是直接上第 5 章的 DNN 模型配合 OpenVINO 推理同等硬件条件下效果比 HOG 好得多而且 OpenVINO 的安装比从源码编译 OpenCV 省心得多。真要编译先确认你的 CMake 版本和 CUDA 版本在 OpenCV 官方支持矩阵里这个排查过程一次就能磨掉你半天耐心。5. 内置方法的天花板与 DNN 转进用 OpenCV DNN 模块加载预训练行人检测模型5.1 HOG 的边界在哪什么场景必须转 DNN调参调得再精细HOG SVM 的检测精度也有天花板这个天花板来自两个设计选择特征是手工设计的、分类器是线性的。手工特征意味着它对遮挡、姿态变化、光照突变的表达力有限线性分类器意味着它无法捕捉特征之间的复杂交互。当场景出现以下任一种情况时HOG 基本就跪了行人互相遮挡只露出半个身子行人姿态夸张跑步、弯腰、骑电动车夜间红外画面梯度信息被噪声淹没密集人流大量重叠框合并后只剩一团所以实战项目里HOG 适合做「野外初步筛选」或「资源受限的轻量逻辑」一旦涉及稳定交付DNN 几乎是必经之路。OpenCV 的 DNN 模块不需要你搭建深度学习训练环境只需要一个预训练模型文件和加载代码推理时仍然调用 OpenCV 的接口这也算「OpenCV 内置」的一种延伸只不过模型权重不再是打包在库里的那套 SVM 系数。对比一下两条路线的选型依据维度HOG SVMDNN MobileNet SSD模型来源OpenCV 内置零额外文件需要单独的模型文件CPU 单帧耗时50~150ms640×480100~200ms300×300 输入遮挡/密集场景明显吃力明显更好部署体积极小模型文件约 20MB 级调参复杂度低核心参数少低主要调置信度阈值5.2 用 Caffe 模型在 DNN 模块里跑行人检测的最小代码DNN 模块加载模型的常见做法是readNetFromCaffe需要两个文件网络结构的 prototxt 和训练好的 caffemodel。这里用 MobileNet SSD 的 VOC 版本它检测的 20 类里 index15 对应 person。模型文件如果压缩包里没有去 Caffe 模型仓库或 OpenCV 模型 zoo 按名字找即可。import cv2 import numpy as np # 加载网络prototxt 是网络结构caffemodel 是训练好的权重 net cv2.dnn.readNetFromCaffe(deploy.prototxt, mobilenet_iter_24000.caffemodel) img cv2.imread(street.jpg) h, w img.shape[:2] # 转成网络输入的 blob缩放系数、均值、通道顺序三个要素 blob cv2.dnn.blobFromImage( img, 0.007843, # 像素缩放系数 (300, 300), # 网络输入尺寸 (127.5, 127.5, 127.5), # 均值Caffe 风格减均值 swapRBTrue, ) net.setInput(blob) detections net.forward() # 形状: (1, 1, N, 7) for i in range(detections.shape[2]): conf detections[0, 0, i, 2] # 置信度 class_id int(detections[0, 0, i, 1]) # 类别索引 if conf 0.5 and class_id 15: # person 类 box detections[0, 0, i, 3:7] * np.array([w, h, w, h]) x1, y1, x2, y2 box.astype(int) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.imwrite(result_dnn.jpg, img)逻辑说明blobFromImage的四个参数是固定套路(300, 300)是网络输入过大过小都会导致性能或精度问题swapRBTrue是因为 Caffe 模型按 BGR 训练OpenCV 读入的图片默认 BGR要保持一致。detections的四维数组里第三维N是一张图上检测出的候选框总量每个候选框是 7 个值批次索引、类别索引、置信度、归一化坐标 x1/y1/x2/y2。需要注意conf阈值MobileNet SSD 的输出置信度分布比 HOG 的权重更「像概率」0.5 是常用起点。如果误检多就提到 0.6漏检多就降到 0.4这是一个纯粹由场景决定的参数。类别的陷阱也要当心不同数据集的类别索引不一样VOC 里 person 是 15COCO 里 person 是 1如果换了模型文件记得核对类别列表这是 DNN 方案里最容易翻车的地方。5.3 从 HOG 换到 DNN视频骨架要改什么DNN 方案和 HOG 的视频骨架基本相同差异集中在三个地方第一detectMultiScale换成net.setInputnet.forward()。第二DNN 的输出是一组原始候选框没有像finalThreshold那样的内置合并逻辑需要自己调cv2.dnn.NMSBoxes去掉重叠框boxes [] confs [] for i in range(detections.shape[2]): conf detections[0, 0, i, 2] if conf 0.5 and int(detections[0, 0, i, 1]) 15: box detections[0, 0, i, 3:7] * np.array([w, h, w, h]) x1, y1, x2, y2 box.astype(int) boxes.append([x1, y1, x2 - x1, y2 - y1]) confs.append(float(conf)) # NMS 过滤重叠框nms_threshold 越大保留的重叠框越多 keep cv2.dnn.NMSBoxes(boxes, confs, score_threshold0.5, nms_threshold0.4) for idx in keep: x, y, bw, bh boxes[idx] cv2.rectangle(frame, (x, y), (x bw, y bh), (0, 255, 0), 2)参数说明NMSBoxes接收框列表和置信度列表score_threshold在这里再过滤一次低置信度框nms_threshold0.4表示两个框的 IoU 超过 0.4 就合并。这个值调小能压重叠误检调大能保留密集场景下的独立行人比如两个人并排走时0.3可能把两个框并成一个0.5一般能分开。第三DNN 推理耗时比 HOG 高一个档跳帧策略从skip2起步实测后按第 4.4 节的方法重新计算。DNN 模型在 300×300 输入下的耗时相对稳定不像 HOG 那样受图像内容影响大预算估算反而更简单。6. 把检测接入业务FPS 预算、跨线计数与三个值得投入的优化方向检测跑通、坑也踩平之后下一步是把行人检测变成业务功能最常见的是统计某个区域的人流量。这里分享一个我常用的最小跨线计数逻辑取检测框底边中心点坐标判断它是否从预设线的一侧移动到另一侧。核心代码只需要几行centroid_y y h # 框底边中心比框中心更贴近脚底位置 if prev_side 0 and centroid_y line_y: count 1 prev_side 1 if centroid_y line_y else 0逻辑说明只用当前帧的检测框坐标不够还要记住上一帧的目标位置。用框底边而不是框中心是因为行人上身会前后摆动底边相对稳定误触发的概率更低。这个逻辑简单到没有调参空间但也正因如此它能不能跑对完全取决于上游检测框的质量。业务上线前还要做一次严肃的性能压测算法上能不能跑和业务上能不能扛是两个问题。按路数算预算一路摄像头的处理预算 1000ms / 目标 FPS如果目标 15 FPS每路每帧 66ms。你有 4 路摄像头就是 264ms 的计算载荷单 CPU 扛不住就得考虑串行转并行或者降低每路的输入分辨率。「配置参数时先从minNeighbors类参数起步」这段话我经常对同事说但 HOG 里没有这个参数我真正想强调的是先用最简单的参数组合跑通测耗时再谈优化。我现在的习惯是固定摄像头场景先用 HOG 权重过滤做一版跑一周收集误检样本如果误检率超过业务容忍线直接把 DNN 模型换成自己场景微调过的版本。换句话说HOG 是判断项目值不值得做的低成本探针DNN 是稳定交付的保底方案前者花的半天时间绝对不会白费。如果要在这个方向继续投入三个优化方向按性价比排序一是把模型切成 OpenVINO 的 IR 格式推理同样的 CPU 能快 2~4 倍二是用公开的行人检测数据集做预训练往自己的场景里标几百张图微调一个小模型三是给固定场景加背景减除或深度信息做前置过滤把「非人区域」直接拦住。三个方向不用全做按你实际部署的硬件选一个先落地。希望这些参数和踩坑记录能帮你少走一段弯路也希望你能从这套内置方法出发真正把一个行人检测项目落到自己的场景里。本文还有配套的精品资源点击获取