简介这份数据集面向计算机视觉目标检测开发者聚焦安全帽佩戴检测场景包含蓝、红、白、黄及未佩戴安全帽五个类别可用于训练施工现场人员安全装备监测模型。压缩包共约两千个文件以Pascal VOC格式的XML标注和YOLO格式的TXT标注为主整体大小约444MB数据内含7574张640×640分辨率的JPG图片总标注框数达45113个其中蓝色6098框、红色10623框、白色8815框、未佩戴10456框、黄色9121框类别间样本量相对均衡且图像尺寸统一便于批处理与迁移学习。目前已有707人学习/下载适合智慧工地、安全巡检等场景的目标检测算法验证与落地。数据集内约三分之二为增强样本可有效提升模型泛化表现标注由labelImg完成VOC与YOLO双格式可直接接入主流训练框架省去自行采集、清洗与格式转换时间开箱即用。1. 安全帽颜色检测为什么先喂给模型的是一套 VOCYOLO 双格式数据集做工地安全监管或者道路施工 AI 监控的人都会有个直觉安全帽检测没什么难度难的是“检测出来之后帽子的颜色分类全乱”。黄帽、白帽、红帽、蓝帽、黑帽这五类在不同工地语义不同但是计算机只要一次曝光不准就能把红帽识别成黑帽。这套安全帽颜色检测数据集给的是 7574 张已经标注好的图片同时输出 VOC 和 YOLO 两种格式覆盖蓝、黄、红、白、黑五个类别目的就是让你从“训练数据”这一步开始绕开标注工具转换格式的消耗直接进入模型训练。新手拿到它能省一个多月标注返工的时间熟手拿它能快速验证新网络结构在颜色分类任务上的上限。对于要做岗位识别、人员定位、违规行为分析的安防项目这套数据的价值在于它把“检测框”和“颜色语义”绑定在了一起模型学会的不只是“有一顶帽子”而是“这顶帽子属于谁”。2. 数据格式拆解VOC 的 XML 与 YOLO 的 txt 如何换算2.1 解压后的目录结构先说 labels 和 Annotations这类双格式数据集解压之后通常是两套目录并存。一边是 Pascal VOC 的经典布局JPEGImages 放原图Annotations 放 XMLImageSets/Main 里放 train.txt、val.txt 这类文件列表另一边是 YOLO 工程目录images 和 labels 两个文件夹图片和同名 txt 一一对应。如果解压后你看到的目录结构和上面说的不完全一致也不用慌YOLO 格式只要求图片和标签文件名相同、扩展名不同就够了。我需要提醒你的是不要只盯着 JPEGImages 里有多少张图真正决定训练能不能跑起来的是 labels 目录下的 txt。很多新手犯的第一个错是直接把 VOC 的 XML 拿去找标注工具转 YOLO结果转出来的 txt 行数和图片对不上。拿到这套数据集后我建议你先花十分钟确认一件事labels 目录里的 txt 数量和 JPEGImages 里的图片数量是否完全一致有没有孤立的空标签文件。这一步做好了后面所有训练流程都稳。2.2 用脚本把 XML 重算成 YOLO 文本确认映射关系即使数据集已经提供了 YOLO 格式的 txt我也建议你手动用 XML 重算一遍标签确认自己理解类别索引的映射关系。VOC 的 XML 里标签存的是左上角和右下角坐标YOLO 需要的则是中心点坐标加宽高并且全部用图像宽高做归一化。下面这个函数就是最常用的换算逻辑import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_names): tree ET.parse(xml_path) root tree.getroot() size root.find(size) width int(size.find(width).text) height int(size.find(height).text) with open(out_path, w, encodingutf-8) as f: for obj in root.findall(object): name obj.find(name).text if name not in class_names: continue cls_id class_names.index(name) bndbox obj.find(bndbox) xmin float(bndbox.find(xmin).text) ymin float(bndbox.find(ymin).text) xmax float(bndbox.find(xmax).text) ymax float(bndbox.find(ymax).text) x_center (xmin xmax) / 2.0 / width y_center (ymin ymax) / 2.0 / height box_width (xmax - xmin) / width box_height (ymax - ymin) / height f.write(f{cls_id} {x_center:.6f} {y_center:.6f} f{box_width:.6f} {box_height:.6f}\n)这个脚本的核心是把name字符串映射成数字索引用class_names.index(name)保证 VOC 里的颜色文本和 YOLO 里的类别编号严格对齐。我一般会随机抽十几张图把 txt 内容还原成像素坐标画到原图上肉眼看一遍框的位置对不对。做这一遍的意义不是转换而是校验数据集本身的标注质量很多数据集看着整齐实际上有大量框的右边超出了图片边界这种脏数据直接进训练会让损失函数在初期震荡。2.3 用一段校验脚本跑完 7574 张图定位越界和空标注数据量到了七千多张就不能靠肉眼全部看一遍了。我习惯写一个简单的扫描脚本把每个 txt 里的坐标读出来检查是否越界、类别索引是否在合法范围内、宽高是否为正数。这一步能过滤掉绝大多数因为标注工具 bug 产生的脏标签。import os from PIL import Image IMG_DIR JPEGImages LABEL_DIR labels CLASS_COUNT 5 for txt_name in os.listdir(LABEL_DIR): if not txt_name.endswith(.txt): continue txt_path os.path.join(LABEL_DIR, txt_name) img_name txt_name.replace(.txt, .jpg) img_path os.path.join(IMG_DIR, img_name) if not os.path.exists(img_path): print(fmissing image: {img_name}) continue w, h Image.open(img_path).size with open(txt_path, r) as f: lines f.readlines() if len(lines) 0: print(fempty label: {txt_name}) continue for line in lines: parts line.strip().split() cls_id int(parts[0]) cx, cy, bw, bh map(float, parts[1:]) if cls_id 0 or cls_id CLASS_COUNT: print(fclass out of range: {txt_name} - {cls_id}) if not (0 cx 1 and 0 cy 1): print(fcenter out of bounds: {txt_name}) if bw 0 or bh 0 or bw 1.5 or bh 1.5: print(fbox size abnormal: {txt_name} - {bw} {bh})这段脚本里我特意用了bw 1.5这个看似宽松的阈值因为某些特写镜头里安全帽的框确实可能接近原图三分之一但不能超过 1.5超过了就是异常框。检查中心点坐标越界比检查宽高越界更重要因为 YOLO 训练时如果中心点在图像外数据增强里的 mosaic 操作会产生大量无效梯度模型收敛速度明显变慢。3. 用 YOLOv8 训练自己的安全帽颜色模型划分、yaml 与训练参数3.1 不要直接全读进内存先按 9:1 生成干净的文件列表拿到双格式数据集最忌讳的就是直接拿官方 voc2yolo 脚本一顿转换然后立刻开训。无论数据集的划分有多合理我仍然建议你自己重新划分一次因为训练集和验证集里如果混入了同一段视频里几乎相同的帧mAP 虚高到 0.95 以上换到真实现场立刻掉到 0.6。按 9:1 的比例随机划分通常比较稳别用 8:2颜色检测任务里验证集小一点反而能避免重复帧造成的评估失真。import os import random import shutil random.seed(42) IMG_SRC images TXT_SRC labels TRAIN_RATIO 0.9 image_files [f for f in os.listdir(IMG_SRC) if f.endswith(.jpg)] random.shuffle(image_files) split int(len(image_files) * TRAIN_RATIO) train_files image_files[:split] val_files image_files[split:] os.makedirs(f{IMG_SRC}/train, exist_okTrue) os.makedirs(f{IMG_SRC}/val, exist_okTrue) os.makedirs(f{TXT_SRC}/train, exist_okTrue) os.makedirs(f{TXT_SRC}/val, exist_okTrue) for f in train_files: shutil.move(f{IMG_SRC}/{f}, f{IMG_SRC}/train/{f}) txt f.replace(.jpg, .txt) shutil.move(f{TXT_SRC}/{txt}, f{TXT_SRC}/train/{txt}) for f in val_files: shutil.move(f{IMG_SRC}/{f}, f{IMG_SRC}/val/{f}) txt f.replace(.jpg, .txt) shutil.move(f{TXT_SRC}/{txt}, f{TXT_SRC}/val/{txt})我用的是move而不是copy因为七千多张图全量复制会浪费几百 MB 磁盘空间。random.seed(42)的作用是让每次划分结果可复现这样几个人协同调参时对比的是同一个验证集否则每次训练 mAP 的差异都说不清楚是数据划分造成的还是模型改动造成的。3.2 data.yaml 的关键参数names顺序为什么不能动YOLOv8 训练读的 data.yaml 是项目的地基里面有个致命细节names列表的顺序必须和 labels txt 里的类别索引完全一致。如果你拿到手的数据集里 txt 的第一列是 2那它就对应names[2]不管 2 这个位置写的是 blue 还是 yellow都不能按照你的直觉去改。path: /data/helmet_color train: images/train val: images/val nc: 5 names: 0: blue 1: yellow 2: red 3: white 4: blackpath建议写成绝对路径因为 YOLO 在相对路径上踩过很多坑尤其是你在不同机器之间拷贝项目时相对路径解析出的根目录会和训练时的 workdir 混在一起。nc是类别总数和names的长度必须一致否则启动训练时会直接报错。3.3 训练命令与关键参数yolov8s 是性价比最高的起点颜色检测任务不需要一上来就上 yolov8x我自己做安全帽颜色分类的经验是yolov8s 配合默认的 COCO 预训练权重已经能在大部分工地上达到可用水平。真正影响训练结果的是imgsz和batch的配合。yolo detect train \ datahelmet_color.yaml \ modelyolov8s.pt \ epochs100 \ imgsz640 \ batch16 \ lr00.01 \ device0 \ projectruns \ namehelmet_color_trainepochs100对于七千多张图来说够用再往上收益不大而且颜色识别任务比一般的目标检测更容易过拟合。lr00.01是 YOLOv8 的默认初始学习率如果你的显卡显存小被迫把 batch 降到 8我建议等比降到 0.005 左右否则大学习率配小 batch 会让损失曲线像过山车。imgsz640在大多数监控场景下是合理的但如果你的原图是 1080p 以上并且安全帽在画面里占比很小后文会专门说怎么处理。3.4 用 mAP50-95 和混淆矩阵判断模型质量而不是只看 loss训练结束后YOLOv8 在验证集上输出的指标里mAP50反映的是“框找得准不准”mAP50-95反映的是“框和真实目标的贴合程度”。对安全帽颜色检测来说我更关注的是每类单独 recall 和混淆矩阵。红色和橙色在 HSV 空间距离很近如果验证集里 red 的 recall 明显低于其他类说明色调区分能力不够需要回到数据增强层面去解决问题。训练日志里如果出现某个 epoch 的 val loss 突然升高然后恢复不用太担心那是数据增强里 mosaic 和 mixup 在特定 batch 上造成的正常波动。真正需要警惕的是 mAP50-95 在最后二十个 epoch 里持续下降这说明模型开始过拟合到训练集的背景纹理上了。4. 避坑排查类别错位、坐标越界与颜色误检的实战记录4.1 类别映射错位导致所有颜色识别全乱现象训练了 50 轮loss 降到很低但是把黄帽识别成了蓝帽而且置信度还很高。原因这个坑几乎每个项目都会踩一次。数据集的 labels txt 里类别索引和生产代码里的names顺序不一致。最常见的是标注工具生成 txt 时把类别按字母序排blue 是 0red 是 1yellow 是 2你在 data.yaml 里却按工地习惯写成了 yellow 是 1于是整个类别语义整体平移。解决不要在训练完之后回头看类别名而是在训练前就用 2.2 节的重算脚本建立一次“txt 里的索引 → XML 里的文本字符串 → data.yaml 里的 names” 三者的对照关系把这个对照表存下来每次换机器换数据集都重新核对一遍。4.2 归一化坐标越界导致验证损失出现 NaN现象训练到第 30 轮左右val loss 突然变成 NaN训练直接崩溃看日志时前面的数据看起来都很正常。原因数据集中某些框的坐标在转换时没有做裁剪x_max超出了图像宽度换算成归一化坐标后中心点落在图像外。YOLO 的损失函数在计算 IoU 时遇到这种越界框会出问题特别是开启 mosaic 增强后多个图像拼接会让越界情况被放大。解决拿 2.3 节的校验脚本强制跑一遍把所有越界的 txt 行单独打印出来判断这些框是标签标错了还是可以从数据集中剔除。如果只是少数几张图的边缘框直接删掉这几个标注不会影响模型精度不用为了几根毛而破坏整个锚点分布。4.3 强光和背光下红色安全帽被识别成白色现象晴天下午四点的工地逆光拍摄时红帽全部变成了伪白色模型类别置信度只有 0.4 左右。原因YOLOv8 默认的 HSV 增强里hsv_v对亮度扰动范围到了 0.4这个数值在绝大多数目标检测任务里没问题但对颜色敏感的细粒度分类来说太激进了。亮度被拉高之后红色帽子的饱和度下降视觉上接近白色。解决把训练参数里的增强项单独调一下颜色检测任务不要直接用默认的增强配置。hsv_h: 0.015 hsv_s: 0.3 hsv_v: 0.1hsv_v从 0.4 降到 0.1 之后模型在逆光场景下的稳定性会明显提升。但同时你需要在训练数据里主动加入一些逆光样本否则模型会过拟合到正常光照。我用的是自动曝光补偿把原图通过 Gamma 校正生成一版暗背景样本放进训练集这一招比单纯降低增强参数更有效。4.4 小目标远程漏检后排工人帽子全部没有被框出来现象画面里远处一排工人只有最前面那两顶帽子被检测出来后面三四顶全部漏检而且漏检的帽子在画面里确实很小。原因imgsz640时一个 1080p 画面里距离镜头 20 米的安全帽可能只有 12×12 像素这个尺寸的特征在 YOLOv8s 的 P3 层只有一个特征点响应很容易被背景抑制掉。解决不要增加模型参数量直接用推理时缩放把imgsz提到 1280或者在预处理阶段把原图切成四块瓦片分别推理再合并结果。我一般用瓦片切分而不是单纯提高 imgsz因为 1280 的输入会让显存占用翻倍批量推理吞吐量下降得厉害。瓦片切分时注意重叠区域至少留 20 像素否则帽子正好落在切缝上时两边都检测不到。4.5 红色横幅和红色砖墙被误检成红帽现象工地围挡上挂的红色横幅模型给了 0.82 的置信度认为是 red helmet横幅高度和帽子宽度比例完全不符。原因颜色检测数据集容易出现这种误检因为红色横幅的颜色分布和红色安全帽在 RGB 空间里高度重合模型学到的是“红色小块 边缘清晰”而不是“红色 圆弧轮廓 头部上下文”。单靠检测网络本身很难区分这两者。解决在推理阶段加宽高比过滤安全帽检测框的宽高比通常在 0.7 到 1.4 之间横幅那种细长条框宽高比超过 2.5直接滤掉。另一个更有效的方案是加一个人头关键点做上下文约束检测框下半部分必须跟身体区域有重叠才保留。这需要额外的人体检测模型但对安防项目来说值得做因为靠颜色做判断本身就容易被场景干扰。5. 导出 ONNX 再转 TensorRT部署阶段省显存的两个习惯5.1 用 dynamicTrue 导出 ONNX避免固定分辨率吃死显存训练完的best.pt不能直接拿到项目里去跑我在实际工地上习惯先把 PyTorch 权重转成 ONNX再转成 TensorRT engine。这一步最大的价值在于显存占用能省下近一半尤其在T4 1080p25这种实际场景下用 TensorRT 跑 YOLO 640 分辨率能支持的路数明显比原始 PyTorch 推理高关键就在 batch 维度和输入尺寸的灵活性。yolo export modelruns/helmet_color_train/weights/best.pt formatonnx dynamicTrue imgsz640导出 ONNX 时我习惯加dynamicTrue这样输入尺寸不需要在导出时定死。有人担心动态 shape 会影响 TensorRT 的优化效果实际测下来在yolov8s这个规模上差距很小但部署端能省去“不同分辨率现场就得重新导出一次模型”的痛苦。5.2 转 TensorRT 用 FP16精度损失在安全帽场景可以忽略ONNX 导出之后用 ultralytics 自带命令转 engine 是最省事的方式yolo export modelbest.pt formatengine device0 halfTrue imgsz640halfTrue会把权重和中间特征切成 FP16显存占用直接减半。安全帽颜色检测这种任务FP16 带来的精度损失基本在 0.5% 以内mAP50 几乎不掉而推理速度能提升 40% 上下。做出来的 engine 文件最好保留一份放到目标机器上直接加载不要在每次启动时现转因为 TensorRT 的引擎构建过程耗时几十秒到几分钟不能让这个时间出现在项目的启动流程里。有一次在项目联调现场我发现推理卡顿不在模型本身而是在图片预处理环节输入图像从 BGR 到 RGB 的转换加 resize 占用了一半耗时。从那以后我每次部署都会先跑一遍完整的视频流测延迟而不是只测模型前向时间用 Nsight 看一眼每个算子耗时。希望这套流程能帮你少走我之前走过的弯路部署时心态更稳。本文还有配套的精品资源点击获取