简介这份PDF文档面向零售行业数据分析人员、计算机视觉初学者及目标检测工程实践者系统讲解如何用YOLOv11完成客流量统计中的轨迹跟踪与热力图生成。全文共43页支持目录章节跳转与阅读器左侧大纲快速定位内容完整、图表清晰。压缩包内仅含1个PDF文件大小约2.24MB轻量便于随时查阅。文档从YOLOv11网络结构、训练与推理讲起逐步展开轨迹跟踪算法分类、目标关联与轨迹更新、MOTA与MOTP等评估指标并深入核密度估计与网格计数法两种热力图生成方案最后落到系统整合、性能优化与超市、服装店、商场等真实案例分析。已有94人学习适合希望把检测、跟踪与可视化串成完整零售客流分析方案的读者参考可帮助快速理解从模型训练到业务决策的落地路径。1. 从一段门店监控视频说起YOLOv11 客流统计到底在解决什么一家 200 平的社区超市装了 6 路摄像头老板想知道三件事每天进店多少人、哪些货架前停留最久、周末和工作日的动线差在哪。红外客流计数器只能给出一个进出数字还经常被并排进门的两个人算成一次。换成基于 YOLOv11 的方案后同一段视频里能同时拿到检测框、跟踪 ID 和一张叠加在平面图上的热力图这才是零售场景真正需要的数据粒度。这份 43 页的文档把整条链路拆成了四块YOLOv11 目标检测、轨迹跟踪、热力图生成、系统整合。它适合两类人一类是想把 YOLOv11 从跑通 demo 推进到门店落地的算法工程师另一类是需要在店铺里部署客流分析、但不确定该选检测模型还是跟踪算法的 IT 负责人。文档本身是学习参考资料不涉及商业授权下面我按自己拆项目的顺序把里面能直接抄的部分和容易踩的坑讲清楚。2. YOLOv11 网络结构与训练自己的客流检测模型2.1 骨干网络、颈部与检测头各自在干什么YOLOv11 的骨干网络负责从 640×640 的输入里抽特征文档里给了一个简化实现用深度可分离卷积加残差连接。深度可分离卷积把标准卷积拆成 depthwise 和 pointwise 两步参数量和计算量都降下来这对门店边缘设备很关键——你不可能在每台 NVR 后面塞一张 A100。残差连接解决的是网络加深后的梯度消失让骨干能堆到足够深还不退化。颈部网络是 FPN 加 PAN 的组合。FPN 自顶向下把高层语义传给低层PAN 再自底向上补一次这样小目标远处货架边的顾客和大目标近处收银台前的人都能被检测头接住。检测头做多尺度预测每个尺度输出类别概率、边界框和置信度。提示文档里的骨干代码是教学简化版真实 YOLOv11 的 C3k2 模块和 SPPF 层没有展开。要训练自己的模型直接用 ultralytics 官方实现别照着简化版手搓。2.2 数据标注与数据集划分的实操参数零售客流检测的标注类别通常只有一个customer。文档建议用 LabelImg 或 LabelBox标注格式可以是 PASCAL VOC 的 XML也可以是 JSON。我一般统一转成 YOLO 的 txt 格式每行class_id cx cy w h坐标归一化到 0-1。数据集划分按 70% 训练、15% 验证、15% 测试。这里有个容易忽略的点如果视频是连续帧抽出来的同一顾客的相邻帧不能同时进训练集和验证集否则验证指标会虚高。正确做法是按视频片段划分而不是按帧随机划分。# 从视频按 2fps 抽帧避免相邻帧高度相似 ffmpeg -i store_cam01.mp4 -vf fps2 frames/cam01_%06d.jpg # 用 ultralytics 自带的划分脚本按 8:1:1 切分 python -c from ultralytics.data.utils import autosplit autosplit(datasets/retail/images, weights(0.8, 0.1, 0.1), annotated_onlyFalse) fps2是平衡数据量和冗余的常用值门店场景顾客移动慢2fps 足够覆盖。autosplit的weights对应训练/验证/测试比例annotated_onlyFalse表示没有标注的图也参与划分但训练时会被跳过。2.3 训练参数与数据增强配置文档给的训练参数是 lr0.001、batch16、epochs50优化器用 Adam。实际门店数据量通常在几千到几万张我一般用 SGD 配余弦退火初始 lr0.01warmup 3 个 epoch效果比固定 lr 的 Adam 稳。数据增强用 Albumentations文档里的 RandomCrop、HorizontalFlip、RandomBrightnessContrast 是基础三件套。零售场景要额外加两点一是RandomShadow模拟货架投影和灯光不均二是MotionBlur模拟顾客快速走过时的拖影。但 HorizontalFlip 要慎用如果店内有明显的左右不对称标识比如入口在左、出口在右翻转会引入错误的空间先验。import albumentations as A transform A.Compose([ A.RandomResizedCrop(size(640, 640), scale(0.6, 1.0)), A.HorizontalFlip(p0.3), # 降低概率避免破坏空间先验 A.RandomBrightnessContrast(p0.4), A.RandomShadow(p0.3), # 模拟货架投影 A.MotionBlur(blur_limit7, p0.2),# 模拟移动拖影 ], bbox_paramsA.BboxParams(formatyolo, label_fields[class_labels]))RandomResizedCrop的scale(0.6,1.0)让模型见到不同远近的顾客p值控制每种增强的触发概率太高会让训练不稳定太低起不到泛化作用。2.4 推理与保存结果的常见写法训练完推理时文档的流程是缩放、归一化、前向、NMS 后处理。这里有个热词叫「yolov11预测后保存」实际项目里通常要把检测结果存成 JSON 或 CSV方便后续跟踪和热力图模块读取。from ultralytics import YOLO import json model YOLO(runs/detect/train/weights/best.pt) results model.predict(sourceframes/, conf0.4, iou0.5, saveFalse) records [] for r in results: for box in r.boxes: records.append({ frame: r.path, bbox: box.xyxy[0].tolist(), conf: float(box.conf[0]), cls: int(box.cls[0]) }) with open(detections.json, w) as f: json.dump(records, f)conf0.4是门店场景的常用阈值太低会把货架上的模特误检成人太高会漏掉被遮挡的顾客。iou0.5控制 NMS 的合并力度人群密集时可以调到 0.6 减少误合并。3. 轨迹跟踪从检测框到顾客 ID 的关联逻辑3.1 为什么检测够用还要跟踪只做检测你拿到的是每一帧里一堆独立的框无法回答「这个人在店里待了多久」「他从入口走到生鲜区再走到收银台」这类问题。轨迹跟踪给每个顾客分配一个稳定 ID把跨帧的框串成轨迹客流量统计和热力图才有意义。文档里把跟踪算法分成基于特征匹配、基于运动模型、基于深度学习三类零售场景最常用的是运动模型加外观特征的混合方案。3.2 ByteTrack 与 BoT-SORT 的选型对比文档没有指定具体跟踪器但按零售场景的常见做法ByteTrack 和 BoT-SORT 是两个主流选择。ByteTrack 的核心思路是先用高置信度框匹配再用低置信度框补匹配对遮挡恢复很友好。BoT-SORT 在 ByteTrack 基础上加了 ReID 外观特征和相机运动补偿ID Switch 更少但计算量更大。跟踪器优势劣势适用场景ByteTrack速度快遮挡恢复好外观相似时易串 ID客流密度中等、算力有限BoT-SORTID 稳定性高需额外 ReID 模型顾客着装差异小、要求高精度OC-SORT对非线性运动鲁棒参数调优复杂顾客走动快、转向多我一般先用 ByteTrack 跑一版看 ID Switch 次数如果超过总轨迹数的 5%再换 BoT-SORT。3.3 轨迹初始化、更新与代码实现跟踪的核心是维护一个轨迹池新检测框如果和已有轨迹的预测位置 IoU 超过阈值就关联上并更新轨迹连续多帧没关联上的轨迹标记为丢失超过 max_age 后删除连续多帧匹配上的新检测才初始化为新轨迹避免噪声产生假 ID。from ultralytics import YOLO import numpy as np model YOLO(best.pt) # persistTrue 让跟踪器在视频流中保持状态 results model.track(sourcestore_cam01.mp4, trackerbytetrack.yaml, conf0.4, iou0.5, persistTrue, streamTrue) tracks {} for r in results: if r.boxes.id is None: continue for box, tid in zip(r.boxes.xyxy, r.boxes.id): tid int(tid) cx float((box[0] box[2]) / 2) cy float((box[1] box[3]) / 2) tracks.setdefault(tid, []).append((cx, cy))persistTrue是关键参数不加的话每帧都会重置跟踪状态ID 会乱跳。streamTrue让视频逐帧处理避免一次性加载占满内存。tracks字典里每个 ID 对应一串中心点坐标这就是后续热力图的原始数据。3.4 跟踪评估指标与遮挡处理文档列了 MOTA、MOTP、ID Switches 三个指标。MOTA 综合衡量漏检、误检和 ID 切换MOTP 衡量定位精度ID Switches 直接反映 ID 稳定性。零售场景最该盯的是 ID Switches因为它直接影响客流计数——一次 ID 切换可能把一个人算成两个。遮挡处理上常见做法是给轨迹加一个卡尔曼滤波预测即使检测框暂时消失也能用预测位置维持几帧。文档提到的「轨迹丢失与重新关联」就是这个思路。如果顾客被货架挡住超过 1 秒ByteTrack 的丢失轨迹池还能在重新出现时接上但超过 max_age默认 30 帧就彻底断了。4. 热力图生成核密度估计与网格计数怎么选4.1 热力图的数据来源与密度计算热力图的输入是跟踪输出的轨迹点集合每个点是一对 (x, y) 坐标。密度计算有两种主流方法核密度估计KDE和网格计数。KDE 在每个点周围放一个核函数通常是高斯核把所有核叠加起来得到连续密度面网格计数把画面切成固定大小的格子统计每个格子里的点数。4.2 核密度估计的实现与带宽选择KDE 的效果高度依赖带宽参数。带宽太小热力图变成一堆孤立亮点带宽太大所有区域糊成一片。零售场景的带宽通常取画面宽度的 3% 到 8%具体看店铺面积和摄像头高度。import numpy as np from scipy.stats import gaussian_kde import matplotlib.pyplot as plt # points 是 N×2 的轨迹点数组 points np.array(all_track_points).T # 转成 2×N kde gaussian_kde(points, bw_method0.05) # 带宽比例 # 在画面网格上求密度 xgrid np.linspace(0, 1920, 200) ygrid np.linspace(0, 1080, 120) X, Y np.meshgrid(xgrid, ygrid) positions np.vstack([X.ravel(), Y.ravel()]) Z kde(positions).reshape(X.shape) plt.imshow(Z, originlower, cmapjet, extent[0, 1920, 0, 1080]) plt.colorbar() plt.savefig(heatmap_kde.png, dpi150)bw_method0.05是带宽比例对应画面宽度的 5%。gaussian_kde的复杂度是 O(N×M)N 是轨迹点数、M 是网格点数点数上万时建议先对轨迹做下采样。4.3 网格计数法的参数与阈值网格计数更简单也更快适合实时出图。网格大小是关键参数太大丢失细节太小出现空洞。1920×1080 的画面网格取 32×32 像素比较合适对应 60×34 个格子。import numpy as np grid_size 32 H, W 1080, 1920 heat np.zeros((H // grid_size, W // grid_size)) for x, y in all_track_points: gx, gy int(x // grid_size), int(y // grid_size) if 0 gy heat.shape[0] and 0 gx heat.shape[1]: heat[gy, gx] 1 # 阈值过滤低于阈值的格子视为噪声 threshold np.percentile(heat, 70) # 只保留前 30% 高密度区 heat[heat threshold] 0np.percentile(heat, 70)是热词里提到的「相关热力图阈值」的常见做法用分位数而不是固定值能自适应不同客流量的时段。grid_size32是经验值店铺面积大、摄像头远时可以调到 48 或 64。4.4 两种方法的对比与选择维度核密度估计网格计数平滑度连续平滑有格子感计算速度慢O(N×M)快O(N)参数敏感度带宽影响大网格大小影响大实时性适合离线分析适合实时出图实现复杂度需 scipy纯 numpy 即可我一般离线分析用 KDE 出报告图实时看板用网格计数。如果要在前端做交互式热力图网格计数配合 canvas 渲染更流畅。5. 系统整合与落地时的几个硬骨头5.1 多路视频的推理调度门店通常有 4 到 8 路摄像头不可能每路都配一张 GPU。常见做法是用一个推理进程轮询多路视频或者用批处理把多路帧拼成一个 batch 送进模型。YOLOv11 的 batch 推理能显著提升 GPU 利用率但要注意不同路视频的帧率对齐否则跟踪 ID 会错乱。# 多路视频按帧号对齐后批推理 import cv2 from ultralytics import YOLO model YOLO(best.pt) caps [cv2.VideoCapture(fcam{i}.mp4) for i in range(4)] while True: frames [] for cap in caps: ret, frame cap.read() if not ret: break frames.append(frame) if len(frames) 4: break # 批量推理batch4 results model.predict(frames, conf0.4, verboseFalse) # 每路结果分别送入各自的跟踪器批推理的 batch 大小受显存限制1080p 输入下 4 路 batch 大约占 6-8GB 显存。如果显存不够降到 2 路或把输入缩到 640×384。5.2 光照变化与夜间场景的应对文档专门提了光照条件影响。门店白天有自然光、晚上只有人工照明同一路摄像头在不同时段的画面差异很大。常见做法是训练时加入亮度扰动增强推理时对暗光帧先做直方图均衡化。如果夜间客流少也可以直接降低夜间帧的处理频率比如白天 5fps、夜间 1fps省算力。5.3 隐私保护与数据存储零售客流分析涉及顾客影像落地时必须考虑隐私。常见做法有三层一是摄像头角度避开人脸正面只拍头顶和身体二是推理后只保留轨迹坐标和热力图原始视频定期删除三是存储的轨迹数据做匿名化ID 和任何个人信息不关联。文档里提到的「数据安全与隐私保护」就是这个层面具体合规要求按当地法规执行。5.4 热力图与平面图的坐标映射摄像头画面是透视的直接生成的热力图不能直接叠到店铺平面图上。需要做一次透视变换把画面坐标映射到平面图坐标。做法是在画面里选四个已知地面点比如四个货架角在平面图上找到对应点算单应性矩阵。import cv2 import numpy as np # 画面中的四个点像素坐标 src np.float32([[200, 800], [1700, 800], [1500, 400], [400, 400]]) # 平面图中对应的四个点厘米坐标 dst np.float32([[0, 0], [800, 0], [800, 600], [0, 600]]) H cv2.getPerspectiveTransform(src, dst) def to_floor(point): p np.array([point[0], point[1], 1.0]) q H p return q[0] / q[2], q[1] / q[2]getPerspectiveTransform需要至少四对点点选得越准映射越精确。映射后的轨迹点直接落在平面图坐标系里热力图就能和货架、收银台位置对齐老板一眼就能看出哪个货架前停留最多。5.5 一个容易被忽略的验证技巧系统上线前别只看 mAP 和 MOTA 这些离线指标。我一般会做一次「人工计数对照」选一段 10 分钟的客流高峰视频人工数进出人数再和系统输出对比。误差在 5% 以内才算可用。如果偏差大先查是不是入口区域的检测阈值太高导致漏检再查跟踪的 ID Switch 是不是集中在某个货架遮挡区。这个对照测试比任何离线指标都更能暴露真实问题。本文还有配套的精品资源点击获取
简介这份PDF文档面向零售行业数据分析人员、计算机视觉初学者及目标检测工程实践者系统讲解如何用YOLOv11完成客流量统计中的轨迹跟踪与热力图生成。全文共43页支持目录章节跳转与阅读器左侧大纲快速定位内容完整、图表清晰。压缩包内仅含1个PDF文件大小约2.24MB轻量便于随时查阅。文档从YOLOv11网络结构、训练与推理讲起逐步展开轨迹跟踪算法分类、目标关联与轨迹更新、MOTA与MOTP等评估指标并深入核密度估计与网格计数法两种热力图生成方案最后落到系统整合、性能优化与超市、服装店、商场等真实案例分析。已有94人学习适合希望把检测、跟踪与可视化串成完整零售客流分析方案的读者参考可帮助快速理解从模型训练到业务决策的落地路径。1. 从一段门店监控视频说起YOLOv11 客流统计到底在解决什么一家 200 平的社区超市装了 6 路摄像头老板想知道三件事每天进店多少人、哪些货架前停留最久、周末和工作日的动线差在哪。红外客流计数器只能给出一个进出数字还经常被并排进门的两个人算成一次。换成基于 YOLOv11 的方案后同一段视频里能同时拿到检测框、跟踪 ID 和一张叠加在平面图上的热力图这才是零售场景真正需要的数据粒度。这份 43 页的文档把整条链路拆成了四块YOLOv11 目标检测、轨迹跟踪、热力图生成、系统整合。它适合两类人一类是想把 YOLOv11 从跑通 demo 推进到门店落地的算法工程师另一类是需要在店铺里部署客流分析、但不确定该选检测模型还是跟踪算法的 IT 负责人。文档本身是学习参考资料不涉及商业授权下面我按自己拆项目的顺序把里面能直接抄的部分和容易踩的坑讲清楚。2. YOLOv11 网络结构与训练自己的客流检测模型2.1 骨干网络、颈部与检测头各自在干什么YOLOv11 的骨干网络负责从 640×640 的输入里抽特征文档里给了一个简化实现用深度可分离卷积加残差连接。深度可分离卷积把标准卷积拆成 depthwise 和 pointwise 两步参数量和计算量都降下来这对门店边缘设备很关键——你不可能在每台 NVR 后面塞一张 A100。残差连接解决的是网络加深后的梯度消失让骨干能堆到足够深还不退化。颈部网络是 FPN 加 PAN 的组合。FPN 自顶向下把高层语义传给低层PAN 再自底向上补一次这样小目标远处货架边的顾客和大目标近处收银台前的人都能被检测头接住。检测头做多尺度预测每个尺度输出类别概率、边界框和置信度。提示文档里的骨干代码是教学简化版真实 YOLOv11 的 C3k2 模块和 SPPF 层没有展开。要训练自己的模型直接用 ultralytics 官方实现别照着简化版手搓。2.2 数据标注与数据集划分的实操参数零售客流检测的标注类别通常只有一个customer。文档建议用 LabelImg 或 LabelBox标注格式可以是 PASCAL VOC 的 XML也可以是 JSON。我一般统一转成 YOLO 的 txt 格式每行class_id cx cy w h坐标归一化到 0-1。数据集划分按 70% 训练、15% 验证、15% 测试。这里有个容易忽略的点如果视频是连续帧抽出来的同一顾客的相邻帧不能同时进训练集和验证集否则验证指标会虚高。正确做法是按视频片段划分而不是按帧随机划分。# 从视频按 2fps 抽帧避免相邻帧高度相似 ffmpeg -i store_cam01.mp4 -vf fps2 frames/cam01_%06d.jpg # 用 ultralytics 自带的划分脚本按 8:1:1 切分 python -c from ultralytics.data.utils import autosplit autosplit(datasets/retail/images, weights(0.8, 0.1, 0.1), annotated_onlyFalse) fps2是平衡数据量和冗余的常用值门店场景顾客移动慢2fps 足够覆盖。autosplit的weights对应训练/验证/测试比例annotated_onlyFalse表示没有标注的图也参与划分但训练时会被跳过。2.3 训练参数与数据增强配置文档给的训练参数是 lr0.001、batch16、epochs50优化器用 Adam。实际门店数据量通常在几千到几万张我一般用 SGD 配余弦退火初始 lr0.01warmup 3 个 epoch效果比固定 lr 的 Adam 稳。数据增强用 Albumentations文档里的 RandomCrop、HorizontalFlip、RandomBrightnessContrast 是基础三件套。零售场景要额外加两点一是RandomShadow模拟货架投影和灯光不均二是MotionBlur模拟顾客快速走过时的拖影。但 HorizontalFlip 要慎用如果店内有明显的左右不对称标识比如入口在左、出口在右翻转会引入错误的空间先验。import albumentations as A transform A.Compose([ A.RandomResizedCrop(size(640, 640), scale(0.6, 1.0)), A.HorizontalFlip(p0.3), # 降低概率避免破坏空间先验 A.RandomBrightnessContrast(p0.4), A.RandomShadow(p0.3), # 模拟货架投影 A.MotionBlur(blur_limit7, p0.2),# 模拟移动拖影 ], bbox_paramsA.BboxParams(formatyolo, label_fields[class_labels]))RandomResizedCrop的scale(0.6,1.0)让模型见到不同远近的顾客p值控制每种增强的触发概率太高会让训练不稳定太低起不到泛化作用。2.4 推理与保存结果的常见写法训练完推理时文档的流程是缩放、归一化、前向、NMS 后处理。这里有个热词叫「yolov11预测后保存」实际项目里通常要把检测结果存成 JSON 或 CSV方便后续跟踪和热力图模块读取。from ultralytics import YOLO import json model YOLO(runs/detect/train/weights/best.pt) results model.predict(sourceframes/, conf0.4, iou0.5, saveFalse) records [] for r in results: for box in r.boxes: records.append({ frame: r.path, bbox: box.xyxy[0].tolist(), conf: float(box.conf[0]), cls: int(box.cls[0]) }) with open(detections.json, w) as f: json.dump(records, f)conf0.4是门店场景的常用阈值太低会把货架上的模特误检成人太高会漏掉被遮挡的顾客。iou0.5控制 NMS 的合并力度人群密集时可以调到 0.6 减少误合并。3. 轨迹跟踪从检测框到顾客 ID 的关联逻辑3.1 为什么检测够用还要跟踪只做检测你拿到的是每一帧里一堆独立的框无法回答「这个人在店里待了多久」「他从入口走到生鲜区再走到收银台」这类问题。轨迹跟踪给每个顾客分配一个稳定 ID把跨帧的框串成轨迹客流量统计和热力图才有意义。文档里把跟踪算法分成基于特征匹配、基于运动模型、基于深度学习三类零售场景最常用的是运动模型加外观特征的混合方案。3.2 ByteTrack 与 BoT-SORT 的选型对比文档没有指定具体跟踪器但按零售场景的常见做法ByteTrack 和 BoT-SORT 是两个主流选择。ByteTrack 的核心思路是先用高置信度框匹配再用低置信度框补匹配对遮挡恢复很友好。BoT-SORT 在 ByteTrack 基础上加了 ReID 外观特征和相机运动补偿ID Switch 更少但计算量更大。跟踪器优势劣势适用场景ByteTrack速度快遮挡恢复好外观相似时易串 ID客流密度中等、算力有限BoT-SORTID 稳定性高需额外 ReID 模型顾客着装差异小、要求高精度OC-SORT对非线性运动鲁棒参数调优复杂顾客走动快、转向多我一般先用 ByteTrack 跑一版看 ID Switch 次数如果超过总轨迹数的 5%再换 BoT-SORT。3.3 轨迹初始化、更新与代码实现跟踪的核心是维护一个轨迹池新检测框如果和已有轨迹的预测位置 IoU 超过阈值就关联上并更新轨迹连续多帧没关联上的轨迹标记为丢失超过 max_age 后删除连续多帧匹配上的新检测才初始化为新轨迹避免噪声产生假 ID。from ultralytics import YOLO import numpy as np model YOLO(best.pt) # persistTrue 让跟踪器在视频流中保持状态 results model.track(sourcestore_cam01.mp4, trackerbytetrack.yaml, conf0.4, iou0.5, persistTrue, streamTrue) tracks {} for r in results: if r.boxes.id is None: continue for box, tid in zip(r.boxes.xyxy, r.boxes.id): tid int(tid) cx float((box[0] box[2]) / 2) cy float((box[1] box[3]) / 2) tracks.setdefault(tid, []).append((cx, cy))persistTrue是关键参数不加的话每帧都会重置跟踪状态ID 会乱跳。streamTrue让视频逐帧处理避免一次性加载占满内存。tracks字典里每个 ID 对应一串中心点坐标这就是后续热力图的原始数据。3.4 跟踪评估指标与遮挡处理文档列了 MOTA、MOTP、ID Switches 三个指标。MOTA 综合衡量漏检、误检和 ID 切换MOTP 衡量定位精度ID Switches 直接反映 ID 稳定性。零售场景最该盯的是 ID Switches因为它直接影响客流计数——一次 ID 切换可能把一个人算成两个。遮挡处理上常见做法是给轨迹加一个卡尔曼滤波预测即使检测框暂时消失也能用预测位置维持几帧。文档提到的「轨迹丢失与重新关联」就是这个思路。如果顾客被货架挡住超过 1 秒ByteTrack 的丢失轨迹池还能在重新出现时接上但超过 max_age默认 30 帧就彻底断了。4. 热力图生成核密度估计与网格计数怎么选4.1 热力图的数据来源与密度计算热力图的输入是跟踪输出的轨迹点集合每个点是一对 (x, y) 坐标。密度计算有两种主流方法核密度估计KDE和网格计数。KDE 在每个点周围放一个核函数通常是高斯核把所有核叠加起来得到连续密度面网格计数把画面切成固定大小的格子统计每个格子里的点数。4.2 核密度估计的实现与带宽选择KDE 的效果高度依赖带宽参数。带宽太小热力图变成一堆孤立亮点带宽太大所有区域糊成一片。零售场景的带宽通常取画面宽度的 3% 到 8%具体看店铺面积和摄像头高度。import numpy as np from scipy.stats import gaussian_kde import matplotlib.pyplot as plt # points 是 N×2 的轨迹点数组 points np.array(all_track_points).T # 转成 2×N kde gaussian_kde(points, bw_method0.05) # 带宽比例 # 在画面网格上求密度 xgrid np.linspace(0, 1920, 200) ygrid np.linspace(0, 1080, 120) X, Y np.meshgrid(xgrid, ygrid) positions np.vstack([X.ravel(), Y.ravel()]) Z kde(positions).reshape(X.shape) plt.imshow(Z, originlower, cmapjet, extent[0, 1920, 0, 1080]) plt.colorbar() plt.savefig(heatmap_kde.png, dpi150)bw_method0.05是带宽比例对应画面宽度的 5%。gaussian_kde的复杂度是 O(N×M)N 是轨迹点数、M 是网格点数点数上万时建议先对轨迹做下采样。4.3 网格计数法的参数与阈值网格计数更简单也更快适合实时出图。网格大小是关键参数太大丢失细节太小出现空洞。1920×1080 的画面网格取 32×32 像素比较合适对应 60×34 个格子。import numpy as np grid_size 32 H, W 1080, 1920 heat np.zeros((H // grid_size, W // grid_size)) for x, y in all_track_points: gx, gy int(x // grid_size), int(y // grid_size) if 0 gy heat.shape[0] and 0 gx heat.shape[1]: heat[gy, gx] 1 # 阈值过滤低于阈值的格子视为噪声 threshold np.percentile(heat, 70) # 只保留前 30% 高密度区 heat[heat threshold] 0np.percentile(heat, 70)是热词里提到的「相关热力图阈值」的常见做法用分位数而不是固定值能自适应不同客流量的时段。grid_size32是经验值店铺面积大、摄像头远时可以调到 48 或 64。4.4 两种方法的对比与选择维度核密度估计网格计数平滑度连续平滑有格子感计算速度慢O(N×M)快O(N)参数敏感度带宽影响大网格大小影响大实时性适合离线分析适合实时出图实现复杂度需 scipy纯 numpy 即可我一般离线分析用 KDE 出报告图实时看板用网格计数。如果要在前端做交互式热力图网格计数配合 canvas 渲染更流畅。5. 系统整合与落地时的几个硬骨头5.1 多路视频的推理调度门店通常有 4 到 8 路摄像头不可能每路都配一张 GPU。常见做法是用一个推理进程轮询多路视频或者用批处理把多路帧拼成一个 batch 送进模型。YOLOv11 的 batch 推理能显著提升 GPU 利用率但要注意不同路视频的帧率对齐否则跟踪 ID 会错乱。# 多路视频按帧号对齐后批推理 import cv2 from ultralytics import YOLO model YOLO(best.pt) caps [cv2.VideoCapture(fcam{i}.mp4) for i in range(4)] while True: frames [] for cap in caps: ret, frame cap.read() if not ret: break frames.append(frame) if len(frames) 4: break # 批量推理batch4 results model.predict(frames, conf0.4, verboseFalse) # 每路结果分别送入各自的跟踪器批推理的 batch 大小受显存限制1080p 输入下 4 路 batch 大约占 6-8GB 显存。如果显存不够降到 2 路或把输入缩到 640×384。5.2 光照变化与夜间场景的应对文档专门提了光照条件影响。门店白天有自然光、晚上只有人工照明同一路摄像头在不同时段的画面差异很大。常见做法是训练时加入亮度扰动增强推理时对暗光帧先做直方图均衡化。如果夜间客流少也可以直接降低夜间帧的处理频率比如白天 5fps、夜间 1fps省算力。5.3 隐私保护与数据存储零售客流分析涉及顾客影像落地时必须考虑隐私。常见做法有三层一是摄像头角度避开人脸正面只拍头顶和身体二是推理后只保留轨迹坐标和热力图原始视频定期删除三是存储的轨迹数据做匿名化ID 和任何个人信息不关联。文档里提到的「数据安全与隐私保护」就是这个层面具体合规要求按当地法规执行。5.4 热力图与平面图的坐标映射摄像头画面是透视的直接生成的热力图不能直接叠到店铺平面图上。需要做一次透视变换把画面坐标映射到平面图坐标。做法是在画面里选四个已知地面点比如四个货架角在平面图上找到对应点算单应性矩阵。import cv2 import numpy as np # 画面中的四个点像素坐标 src np.float32([[200, 800], [1700, 800], [1500, 400], [400, 400]]) # 平面图中对应的四个点厘米坐标 dst np.float32([[0, 0], [800, 0], [800, 600], [0, 600]]) H cv2.getPerspectiveTransform(src, dst) def to_floor(point): p np.array([point[0], point[1], 1.0]) q H p return q[0] / q[2], q[1] / q[2]getPerspectiveTransform需要至少四对点点选得越准映射越精确。映射后的轨迹点直接落在平面图坐标系里热力图就能和货架、收银台位置对齐老板一眼就能看出哪个货架前停留最多。5.5 一个容易被忽略的验证技巧系统上线前别只看 mAP 和 MOTA 这些离线指标。我一般会做一次「人工计数对照」选一段 10 分钟的客流高峰视频人工数进出人数再和系统输出对比。误差在 5% 以内才算可用。如果偏差大先查是不是入口区域的检测阈值太高导致漏检再查跟踪的 ID Switch 是不是集中在某个货架遮挡区。这个对照测试比任何离线指标都更能暴露真实问题。本文还有配套的精品资源点击获取
