夜间行人检测数据集解析：5000张图搞定YOLO11训练与格式转换

简介面向夜间行人检测项目的开发者与算法学习者这份PDF资料系统整理了夜间低光行人检测数据集的完整信息可帮助快速搭建基于YOLO等模型的训练流程。数据集包含5000张真实场景图片覆盖夜间街景、道路、遮挡及严重遮挡行人适用于公共场所监控场景下的行人检测也可作为通用行人检测数据集的夜间补充场景多样、贴近真实部署需求。标注采用labelimg完成质量高提供VOC(xml)、COCO(json)、YOLO(txt)三种标准格式方便直接接入常见目标检测框架能够减少手动格式转换成本。附赠YOLO11一键训练脚本支持GPU(GPUs)、CPU、Mac(M芯片)多平台运行并配有博主训练结果日志供参考能有效降低环境配置门槛。资源共1个PDF文件约6.07MB已有611人学习内附数据集介绍及百度网盘获取方式适合需要快速上手夜间行人检测实战的读者。1. 夜间行人检测为什么 5000 张夜间图比 5 万张白天图更值钱白天跑得好好的 YOLO 模型一到夜间监控场景就掉点这几乎是做安防项目的人都会撞上的事。原因不复杂——公开行人数据集里夜间样本占比太低模型见过的大多是光照充足、轮廓清晰的日间行人到了夜间低光、过曝、遮挡叠加的监控画面里特征分布直接漂移。这篇笔记拆的资源是一个夜间行人检测数据集5000 张真实夜间场景图标注成 VOC、COCO、YOLO 三种格式还附了一份 YOLO11 的多平台一键训练脚本。适合两类人一是要做公共场所夜间行人检测项目的工程师二是拿它当通用行人检测数据集的夜间补充来用。先说结论这资源的价值不在数量而在场景针对性外加省掉你三天格式转换和训练脚本调试的时间。2. 数据集拆解5000 张图里到底有什么标注是怎么做的2.1 场景构成四类夜间行人覆盖监控项目的主要难点这个数据集标注的重点不是「有人」而是「人在什么条件下出现」。从资源描述看图片内容分为四类夜间街景行人、夜间道路行人、夜间遮挡行人和夜间严重遮挡行人。做监控项目的人一眼就能看出来这四类对应的是实际场景里的典型难题——街景行人往往背景杂乱道路行人可能出现强光车灯干扰遮挡和严重遮挡则是行人被栏杆、树木、车辆或其他行人挡住半边身体甚至只露出头部和上肢。严重遮挡这类样本在公开数据集里尤其稀缺。因为标注成本高、容易标错很多数据集的遮挡样本占比很低但监控场景里遮挡几乎是常态人群一密集行人互相遮挡就成了检测器的主要漏检来源。把这类样本单独规划进数据集至少说明标注方对实际项目痛点是有认知的。用的时候建议按场景拆分验证集不要随机切分。随机切分会导致同一时段、同一场景的图片同时出现在训练集和验证集里模型在这个场景上的表现会被高估。我一般会按拍摄时段或场景目录来划分比如前三个场景的训练图第四个场景做验证这样测试的是泛化能力而不是记忆能力。2.2 标注方式labelimg 与 VOC 源格式标注工具用的是 labelimg这是目标检测领域最常见的图形化标注工具输出的是 PASCAL VOC 格式的 XML 文件。每个 XML 文件对应一张图片里面记录了图片尺寸、标注目标的类别名和 bounding box 坐标。annotation foldernight_images/folder filenamenight_001.jpg/filename size width1920/width height1080/height depth3/depth /size object nameperson/name poseUnspecified/pose truncated1/truncated difficult0/difficult bndbox xmin526/xmin ymin284/ymin xmax674/xmax ymax781/ymax /bndbox /object /annotation这个 XML 结构是 VOC 格式的标准模板。标注质量高的标准之一是truncated和difficult字段没有被全部填成 0——truncated1表示目标被截断出画面或被遮挡difficult1表示该目标难以辨认训练时通常会被跳过。如果下载后看到这两个字段有实际值分布说明标注方对遮挡和截断情况做了区分不只是画框了事。2.3 三种格式的目录组织资源直接提供 VOC、COCO、YOLO 三种格式的组织好的数据集典型目录结构如下night_pedestrian/ ├── VOC/ # VOC 格式 │ ├── Annotations/ # XML 标签 │ │ ├── night_001.xml │ │ └── ... │ ├── JPEGImages/ # 原图 │ │ ├── night_001.jpg │ │ └── ... │ └── ImageSets/Main/ # 训练/验证集划分 │ ├── train.txt │ └── val.txt ├── COCO/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── annotations/ │ ├── instances_train.json │ └── instances_val.json └── YOLO/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ │ ├── night_001.txt │ │ └── ... │ └── val/ └── dataset.yaml # YOLO 训练配置文件拿到手先不要急着训练按这个顺序做三件事第一统计totol_labels数量和数据集的类别是否只有person一类看清楚类别 id 是 0 还是从 1 开始第二随机抽取 20 张图把 XML 或 TXT 里的 bbox 坐标画回到图上肉眼检查框和行人是否对齐——这一步很快但能帮你判断标注质量是不是真的如描述所说第三确认ImageSets/Main/train.txt和val.txt的划分比例看训练集与验证集有没有图片重叠。3. 三种标签格式对齐VOC/COCO/YOLO 的坐标体系与转换校验3.1 三种格式的本质区别绝对坐标 vs 归一化坐标VOC、COCO、YOLO 三种格式描述的是同一个标注框但存储方式完全不同。VOC 的 XML 存的是像素绝对坐标xmin, ymin, xmax, ymaxCOCO 的 JSON 存的是像素绝对坐标加宽高x, y, width, height而 YOLO 的 TXT 存的是归一化的中心点坐标加宽高cx, cy, w, h数值范围在 0 到 1 之间。这个区别是踩坑重灾区。把 YOLO 的归一化坐标误当成像素坐标直接用或者把 COCO 的 (x, y, w, h) 当成 VOC 的 (xmin, ymin, xmax, ymax) 用都会导致训练时模型看到的标签全部错位loss 居高不下却查不出原因。我见过的最典型问题是把 COCO 格式的 json 直接喂给 YOLO 训练脚本结果所有目标的中心点都集中在画面左上角——因为 (x, y) 被当成了左上角坐标而实际上 (x, y) 是左上角坐标加上 w 和 h 之后才是右下角。好在资源本身带了三种格式不需要自己转换。但要做一次格式正确性校验——一份数据经过格式转换后坐标信息应该完全等价。3.2 用脚本校验三种格式的坐标一致性拿到资源后我建议先做一次三格式对齐校验。写一个简单的 Python 脚本读同一张图的三种格式标签解析出 bbox 后在原图上画出来对比。import cv2 import json import xml.etree.ElementTree as ET def parse_voc(xml_path): tree ET.parse(xml_path) boxes [] for obj in tree.findall(object): name obj.find(name).text bndbox obj.find(bndbox) xmin int(bndbox.find(xmin).text) ymin int(bndbox.find(ymin).text) xmax int(bndbox.find(xmax).text) ymax int(bndbox.find(ymax).text) boxes.append([name, xmin, ymin, xmax, ymax]) return boxes def parse_yolo(txt_path, img_w, img_h): boxes [] with open(txt_path, r) as f: for line in f.readlines(): parts line.strip().split() cls_id, cx, cy, w, h int(parts[0]), float(parts[1]), float(parts[2]), float(parts[3]), float(parts[4]) xmin int((cx - w / 2) * img_w) ymin int((cy - h / 2) * img_h) xmax int((cx w / 2) * img_w) ymax int((cy h / 2) * img_h) boxes.append([cls_id, xmin, ymin, xmax, ymax]) return boxes img_path night_001.jpg img_w, img_h 1920, 1080 voc_boxes parse_voc(night_001.xml) yolo_boxes parse_yolo(night_001.txt, img_w, img_h) print(VOC boxes:, voc_boxes) print(YOLO boxes:, yolo_boxes)这段代码的核心逻辑是从 VOC 和 YOLO 两种格式里分别解析出 bbox 的像素坐标然后打印对比。解析 YOLO 格式时要注意乘以图片宽高做反归一化。如果两种格式坐标完全一致说明标签对齐没问题可以放心用如果对不上就需要检查是不是图片被 resize 过导致坐标偏移。校验 COCO 格式时需要额外注意 JSON 里images和annotations两个字段的 ID 关联。COCO 的annotations里每条标注通过image_id关联到某张图片bbox 字段存的是[x, y, width, height]格式。常见的问题是图片的高宽在 JSON 里存的顺序和在磁盘上不一致导致坐标解析错位。3.3 类别一致性检查三格式数据集最隐蔽的问题是类别定义不一致。VOC 里类别叫personYOLO 的类别 id 对应personCOCO 的 categories 列表里id1也对应person看起来没问题。但如果 COCO 的类别 id 从 0 开始而 YOLO 的也从 0 开始两者对得上一旦某次转换时 COCO 从 1 开始计 id而 YOLO 从 0 开始所有标签的类别全部错位模型会认为 person 是背景或另一个不存在的类。推荐的做法是先确认dataset.yaml里的类别定义path: night_pedestrian/YOLO train: images/train val: images/val nc: 1 names: 0: person这个 yaml 是 YOLO 训练时的灵魂配置。path是数据集根目录train和val是相对于根目录的训练、验证图片路径nc是类别总数names是类别 id 到类别名的映射。训练前确认这个文件里的nc和你实际标签里的最大类别 id 1 一致这个检查只需要一条命令——遍历所有 txt 标签文件找到最大的类别 id确保它等于nc - 1。4. YOLO11 一键训练脚本GPU/CPU/Mac 三平台的运行方式4.1 脚本设计思路一套代码覆盖三平台资源附带的 YOLO11 训练脚本核心价值在于把平台差异封装掉了。YOLO 的训练在底层调用 PyTorch而 PyTorch 在不同设备上的加速方式完全不同——NVIDIA GPU 走 CUDAMac 的 M 系列芯片走 MPSMetal Performance ShadersCPU 则走原生的 CPU 计算。脚本要做的就是在启动训练时自动检测可用设备然后选择对应的训练后端。常见的做法是优先检测 NVIDIA GPU用torch.cuda.is_available()判断检测不到 GPU 时再检测 Mac 的 MPS用torch.backends.mps.is_available()判断两者都没有才落到 CPU。这个检测顺序很重要——Mac 上也可能装了一些 CUDA 相关的环境变量如果不先检测 MPS 可能误判。YOLO11 基于 ultralytics 框架在train()方法里传入不同的device参数即可。4.2 三平台启动命令与参数说明# NVIDIA GPU 环境单卡或多卡 python train.py --data dataset.yaml --epochs 100 --batch 16 --imgsz 640 --device 0 # 多卡 GPUdevice 指定多个卡号 python train.py --data dataset.yaml --epochs 100 --batch 32 --imgsz 640 --device 0,1 # 纯 CPU 环境 python train.py --data dataset.yaml --epochs 50 --batch 8 --imgsz 640 --device cpu # MacM 系列芯片 python train.py --data dataset.yaml --epochs 50 --batch 8 --imgsz 640 --device mps四条命令的核心区别在--device参数。单卡 GPU 填卡号 0或者省略不填时 ultralytics 也会自动检测。--batch是批大小GPU 显存不够时优先调小它——16G 显存跑 640 分辨率、YOLO11m 模型batch 32 比较稳8G 显存建议直接降到 8 或 16。CPU 和 Mac 的 MPS 因为算力有限batch 一般不超过 8epochs 也可以适当减半先跑通流程再考虑提升精度。--imgsz是训练时输入图片的分辨率。原图如果是 1920x1080不一定非要填 1920——YOLO 训练时会自动做 letterbox 缩放填 640 是精度和速度的平衡点。夜间行人普遍偏小如果检测目标在画面中占比小可以试试 768 或 896但训练时间会相应变长。4.3 训练脚本里的关键超参如何调除了命令行参数训练脚本里还有几个直接影响夜间检测效果的参数--lr0初始学习率、--mosaic是否启用马赛克增强、--patience早停耐心值。夜间数据集普遍比白天数据集样本量小5000 张图在目标检测领域不算大训练时学率率过大会导致 loss 震荡甚至发散常见做法是把默认的 0.01 调低到 0.005 左右。mosaic增强是 ultralytics 框架默认开启的把四张图拼成一张训练可以有效提升模型对遮挡和小目标的鲁棒性。但注意最后 10 个 epoch 框架会自动关闭 mosaic让模型适应正常的图片分布。这是框架内置行为不需要手动干预。如果训练过程中 loss 不下降或者验证集 mAP 始终上不去第一步不是改模型结构而是回头看数据集。用上面提到的校验脚本重新画一遍 bbox重点看验证集的标签是否准确——验证集标签错了mAP 指标本身就是脏的模型训得再好也体现不出来。5. 训练避坑指南夜间数据的四个高发问题与排查5.1 现象训练初期 loss 剧烈震荡不收敛原因标注数据里有坐标越界的框。labelimg 标注时偶尔会把框拖出图片边界YOLO 格式要求 cx、cy、w、h 都在 0 到 1 之间越界值导致计算 loss 时出现异常。解决训练前用脚本清洗标签。对所有 txt 做一次边界检查把 w 或 h 大于 1、cx 或 cy 不在 0 到 1 区间的标注行删除或裁剪到边界内。这个脚本不用写复杂遍历一遍即可。5.2 现象训练正常但 mAP 只有 0.3 左右仔细看是漏检了远处的行人原因imgsz 太小。夜间行人数据集里行人往往是远距离的、在画面中只占 20x40 像素的小目标。640 分辨率输入下这些小目标被缩放后只有十几个像素特征完全丢失。解决把--imgsz从 640 提高到 896 或 1024。代价是训练时间约增加一倍显存占用也会升高。如果显存不够优先降低 batch 而不是降 imgsz——小目标检测场景下分辨率比 batch 更重要。5.3 现象Mac 上训练时提示 MPS 内存不足或者直接崩掉原因MPS 后端对显存的管理比 CUDA 激进batch 稍大就容易越界另外某些算子在 MPS 上不支持会触发 fallback 导致性能骤降或者直接报错。解决把 batch 降到 4同时加一行环境变量PYTORCH_ENABLE_MPS_FALLBACK1让不支持的算子自动回退到 CPU 计算。这样训练速度会略降但至少不会崩。我一般会在 Mac 上先跑 5 个 epoch 验证全流程没问题再切到 GPU 服务器上跑完整训练。5.4 现象验证集 AP 很高但实际跑监控视频时大量误检原因训练时验证集用的是随机切分同一场景的图片同时进了训练集和验证集模型相当于「见过」验证场景。夜间光照变化剧烈换个摄像头角度整个场景分布就变了。解决按场景而不是按图片切分数据集。如果资源自带的划分是随机切分建议自己重新组织——把某一组夜间街景的全部图片拿出来单独做验证集训练集用其余场景。牺牲一点指标数字换的是模型在新场景下的真实表现。5.5 现象加载预训练权重后训练前几个 epoch loss 反而比不用预训练更高原因预训练权重是在 COCO 数据集上学的特征COCO 类别里 person 是很常见的类模型对白天行人特征有很强的先验。到夜间低光数据上这种先验反而成为一种干扰特征分布差异大时模型需要重新调整底层特征。解决这不是 bug不用管。一般前 5 个 epoch loss 会先上升后下降这是模型在「忘掉」白天特征、学习夜间特征的正常过程。如果 20 个 epoch 后 loss 还没有下降趋势才需要检查学习率是否过大。6. 复现之后怎么验证从训练日志到 PR 曲线判断模型能不能上线训练结束后ultralytics 会在runs/detect/train/目录下输出results.png、confusion_matrix.png、PR_curve.png等可视化文件。第一眼先看results.png里的val/box_loss和val/cls_loss两条曲线——如果它们在训练后期还在明显下降说明欠拟合应该加大 epoch 数如果已经走平甚至微升说明模型收敛了。夜间行人检测场景下val/box_loss走平的值如果明显高于日间模型不要急着调参——低光场景的标注框本身就有更大的定位不确定性这是数据固有属性不是模型缺陷。PR_curve.png是判断能否上线的关键依据。这张图画的是不同置信度阈值下 precision 和 recall 的权衡曲线曲线越靠近右上角越好。看曲线时要关注两个点第一曲线与坐标轴围成的面积AP是否达标这个资源场景下 AP50 跑到 0.6 以上就具备可用性第二曲线在 recall 高位的表现——监控场景下漏检一个行人的代价远高于误检所以要在高 recall 区间0.8 左右看 precision 还有多少。如果 recall 到 0.8 时 precision 已经掉到 0.3 以下说明模型靠「宁错杀不放过」拉高召回误检会淹没真正的告警。置信度阈值也值得单独调。YOLO 默认的置信度门槛是 0.25推理时可以用--conf-thres参数调整。安防监控场景我有自己的习惯做实时告警时不调整阈值保证 recall 优先宁可多报几个误检靠后端逻辑过滤做离线视频分析时把阈值拉到 0.4 以上减少人工看误检图的成本。跑一次验证集的 PR 曲线后把曲线在拐点处对应的置信度作为你的默认阈值比拍脑袋填 0.25 或 0.5 靠谱得多。还有一个容易忽略的验证技巧从训练日志里找模型在严重遮挡样本上的单类 AP。如果你的验证集是按场景组织的可以直接单独跑一次验证脚本只看遮挡场景那部分图片的检测结果。方法是在results目录里找到labels.jpg和predictions.jpg做视觉对比——前者是标注框可视化后者是模型预测框可视化。两相对比能直观看出模型是把遮挡行人当成了行人还是当成了背景。有些模型在遮挡样本上会持续漏检头部以下被挡住的半边身体这通常是训练数据里遮挡样本还是不够。真遇到这种问题可以用数据集配套的严重遮挡样本做二次微调把学习率降到 0.001 再训 30 个 epoch。6.1 夜间场景推理增强让训练好的模型跑得更稳模型训练好后推理侧的预处理能再拉一点效果。夜间图像普遍对比度低、亮部过曝常用的做法是在推理时先做自适应直方图均衡化CLAHE增强把暗部细节拉出来再送进模型。这个操作对低光行人检测的提升通常是 2 到 5 个点的 mAP代价是每张图多几毫秒预处理时间。import cv2 from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) def infer_night(model, img_path): img cv2.imread(img_path) lab cv2.cvtColor(img, cv2.COLOR_BGR2LAB) l, a, b cv2.split(lab) clahe cv2.createCLAHE(clipLimit3.0, tileGridSize(8, 8)) l_enhanced clahe.apply(l) enhanced cv2.merge((l_enhanced, a, b)) enhanced cv2.cvtColor(enhanced, cv2.COLOR_LAB2BGR) results model(enhanced, conf0.25, imgsz896) return results, img这段代码把 BGR 图转到 LAB 色彩空间只对亮度通道 L 做 CLAHE 增强然后合并回原图。只增强亮度通道很关键——直接对 BGR 三个通道都做增强会破坏颜色分布行人衣着颜色特征会被扭曲。clipLimit3.0是对比度限制参数值越大增强越激进夜间场景光照太暗可以适当调到 4.0 或 5.0但过强会放大噪点、引入大量误检。imgsz这里我填了 896 而不是训练时的 640。推理时可以用比训练更高的分辨率因为模型对输入尺寸的容忍度远高于训练精度。这也是常见做法之一一种用「训练用小图、推理用大图」的 trick能明显提升小目标召回。6.2 训练日志里值得长期养成的习惯做目标检测项目这几年我养成了一个固定流程每次拿到新数据集第一件事不是训练而是花半小时跑格式校验和标签可视化。这半小时看起来「浪费」了实际是省时间——标签错了再训三天也是白训不如一开始就把脏数据揪出来。数据集里如果出现difficult1的标注我一般会在训练时直接过滤掉因为它们会让模型学到模糊的特征边界。这个夜间行人数据集里我最看重的不是那 5000 张图本身而是它配套的三格式标签给了一个很标准的数据组织范本。后续自己扩数据时完全照着这个目录结构来组织就能无缝接进同一套训练流程。从那以后我每次做新项目的数据准备工作都强制走一遍「画框回验」的流程——随机抽图把标签画回图上肉眼扫一遍再进训练队列。希望这个过程记录和踩坑经验能帮你少走几段夜路。数据集的完整内容和标注文件在 PDF 里包含数据集缩略图、labelimg 标注截图和博主训练结果日志。获取方式是按文末指引在公众号「极智视界」回复专属凭证mFUzfFioeIhK即可拿到下载方式。本文还有配套的精品资源点击获取