简介面向深度学习初学者的疲劳驾驶监测数据集精选人在疲劳状态下的面部照片可用来训练打哈欠、闭眼等状态的图像识别模型适合作为目标检测或图像分类方向的新手练习项目。压缩包内包含2915张jpg图片与2914份xml标注文件总大小约256.28MB标注采用VOC格式可直接用于YOLO、SSD等常见目标检测框架资源整体以图像和标注文件为主结构简洁便于快速搭建实验流程。已有4742人浏览学习受到计算机视觉入门者的关注。数据集中打哈欠张嘴状态与闭眼状态可作为关键疲劳判定特征资源描述还给出了图片与标注匹配性的检查思路帮助初学者在训练前剔除不匹配样本从而更顺畅地完成数据清洗、模型训练和疲劳检测小项目的全流程实践。1. 疲劳驾驶监测数据集训练时图片与 XML 标注对不上的翻车现场做深度学习图像识别项目的人十有八九都栽过这个坑数据集下载下来结构看着挺规整图片一摞、标注文件一摞训练脚本一跑报错提示找不到对应的 XML或者 DataLoader 里两个文件名死活对不上。这类问题在疲劳驾驶监测数据集也就是检测打哈欠、闭眼状态的那种数据集里尤其常见。照片是人在车内不同状态下拍的标注文件是一个个单独的 XML训练前如果没做文件名匹配检查轻则训练进程突然中断重则整个训练集被污染、模型学了一堆错误标签等跑完几个小时后才发现结果完全不能用。我先提醒你一句拿到这类数据集的第一个动作不是看模型结构不是调超参数而是先老老实实做一轮数据与标注的配对核对否则后面全是返工。这里说的“配对核对”是指每一张 JPEG 图片都要有一条同名的 XML 标注。只要图片比标注多了或少了一条训练集里就有样本是“无监督”的模型的损失函数也会跟着算错。下面我把排查思路和一套直接可用的脚本挨个讲清楚按步骤操作就能处理干净。2. 先看清数据集结构JPEGImages 与 Annotations 的对应关系2.1 文件清单怎么看不是数个数而是逐名对比拿到“疲劳驾驶监测数据集”之后解压完你会发现典型的 VOC 风格目录Dataset/dataset/JPEGImages里是.jpg或.jpeg图片Dataset/dataset/Annotations里是.xml标注文件。理论上每个图片文件名去掉扩展名后都能在 Annotations 目录里找到同名 XML。比如894.xml对应894.jpg1429.xml对应1429.jpg。常见做法是先把两个目录的文件名列出来分别查看开头和结尾部分确认没有隐藏文件或损坏文件。不少新手图省事直接对比“文件总数”发现两边数量接近就开训。但实际上数量一致也不代表配对正确比如有三个图片文件名相同但位于不同子目录或者其中某个 XML 是空文件都会导致后续读取失败。我一般会先把目录列表输出到文本文件再写一小段脚本做逐名匹配只看数量和文件名开头几个是看不出隐藏差异的。2.2 匹配失败的典型现象缺失的 XML 与多余的图片在一个实际项目里我遇到过这样的情况JPEGImages目录里有 2300 多张图片Annotations目录里也有 2300 多个 XML但真正能一一配上的只有 2280 对。多出来的图片要么是模型测试时拍的要么是标注员漏标了直接没生成 XML要么是文件命名时写了空格或大小写差异比如IMG_001.JPG和img_001.xml。这种不匹配如果不清理深度学习框架读取数据时就会产生“有图片没有标签”的边缘情况部分框架会直接抛异常中断部分框架则会跳过这些样本导致训练集实际用的图片数比预想少精度评估也会失真。我建议先别急着写模型代码先用下面这段脚本做一次基线核对把“孤儿图片”和“孤儿 XML”都找出来。之后再做清理或补标心里就有底了。3. 数据与标注不匹配的根因命名规则、标注遗漏与手工收集的坑3.1 根因一命名不一致同一张图出现两个写法疲劳驾驶监测数据集中图片和标注的命名规则本应是“图片主名 扩展名分别不同”。但实际处理时经常遇到同一样本同时存在xxx.jpg和xxx.jpeg或者有的图片文件名是1234(1).jpg对应的 XML 却叫1234.xml。这种不一致会直接导致anno_name not in anno_list条件成立图片就被当成多余数据删除。另外还要警惕 Windows 系统下不区分大小写的文件系统图片叫1010.JPG而标注叫1010.xml在 Windows 上测试没问题一放到 Linux 服务器上训练就报找不到文件。我遇到过不止一次这种“本地跑得好好的上服务器就崩”的情况。处理时建议统一转成小写命名并统一用.jpg扩展名再做一次全量匹配。3.2 根因二标注遗漏或误删XML 缺失但图片还在标注员在标注过程中可能出现漏标或者某张图片因为模糊、遮挡被暂时搁置最后忘记补标这就导致图片比 XML 多。也有相反的情况某张图片被误删但 XML 还在这样在训练或验证时如果按 XML 列表去读对应图片也会报错。对于疲劳驾驶检测这类任务闭眼和打哈欠的姿态是训练重点如果这些样本恰好缺失模型对疲劳状态的识别能力就会明显下降。处理逻辑无非两条路第一条把没有对应 XML 的图片删掉或移动到另一个目录备份摘要里的代码就是这条思路第二条把没有对应图片的 XML 也删掉或隔离保证两边严格一一对应。不要只处理其中一边否则训练时如果代码是从 XML 列表驱动读图片残余的孤儿 XML 还是会触发报错。3.3 根因三目录路径配置错误DataLoader 拼接时找错位置有的项目不是直接写在训练脚本里而是通过配置文件指向数据目录配置里写的是Dataset/dataset/JPEGImages但实际解压出来的路径是Dataset/Dataset/JPEGImages多了一个层级。这类路径问题表面看起来像数据集不匹配实际是项目里大小写或相对路径没对齐。新手排查时容易往“图片和标注不匹配”方向使劲折腾很久才发现只是字符串路径错了。所以定位时要先区分是文件系统层面不匹配还是代码层面路径错误。加两行打印就能判断别一上来就删数据。4. 解决方案用 Python 脚本清理不匹配数据保留有效样本4.1 核心脚本删除无对应 XML 的 JPEG 图片摘要描述里已经给出了一段参考代码我把它扩展成更完整、适合直接落地的版本。脚本做的事是遍历JPEGImages目录对每张图片检查同主名的 XML 是否存在如果不存在则删除这张图片或先移动备份。下面是可以直接使用的版本import os import shutil # 路径按你的实际目录结构调整 jpeg_dir Dataset/dataset/JPEGImages anno_dir Dataset/dataset/Annotations # 备份目录不直接删除先挪过去观察一轮 backup_dir Dataset/unmatched_images os.makedirs(backup_dir, exist_okTrue) jpeg_list os.listdir(jpeg_dir) anno_list os.listdir(anno_dir) anno_set set(anno_list) # 转成集合匹配速度更快 removed_count 0 kept_count 0 for pic in jpeg_list: # 跳过非 jpg / jpeg 文件避免误删 if not pic.lower().endswith((.jpg, .jpeg)): continue name os.path.splitext(pic)[0] # 去掉扩展名 anno_name name .xml if anno_name not in anno_set: # 先备份再删除避免手滑 src os.path.join(jpeg_dir, pic) dst os.path.join(backup_dir, pic) shutil.move(src, dst) removed_count 1 else: kept_count 1 print(f匹配的图片数量: {kept_count}) print(f已移动/删除的无标注图片数量: {removed_count})这段代码的核心用途是在不改动原始标注文件的前提下把没有配对 XML 的图片隔离出去。用shutil.move而不是os.remove是给自己留后悔药万一某些图片后续手动补标还能找回。参数说明jpeg_list是图片目录全部文件名anno_set是标注文件名的集合用集合判断成员比逐个遍历列表快得多文件数量到两三千时差距就很明显。os.path.splitext(pic)[0]的作用是安全地去掉扩展名——不要用字符串里的split(.)[0]因为有的文件名本身可能包含点号比如2024.05.03_001.jpg用字符串split(.)只会截到第一个点而splitext是专门处理扩展名的更可靠。4.2 补充脚本同步清理无图片的 XML 文件只清理图片还不够如果 Annotations 目录里也残留了没有对应图片的 XML要在训练时严格按 XML 索引去读图片同样会触发FileNotFoundError。我习惯再写一个对侧检查import os jpeg_dir Dataset/dataset/JPEGImages anno_dir Dataset/dataset/Annotations jpeg_list [f for f in os.listdir(jpeg_dir) if f.lower().endswith((.jpg, .jpeg))] jpeg_names set(os.path.splitext(f)[0] for f in jpeg_list) anno_list os.listdir(anno_dir) orphan_xml_count 0 for xml_file in anno_list: if not xml_file.lower().endswith(.xml): continue name os.path.splitext(xml_file)[0] if name not in jpeg_names: orphan_xml_count 1 # 备份或删除按需选择 print(f孤儿标注文件: {xml_file}) print(f孤儿 XML 数量: {orphan_xml_count})这段脚本判断依据是XML 主名必须能在图片文件名集合中找到。找不到者就是孤儿 XML可以单独移动到备份目录。参数上要注意xml_file.lower().endswith(.xml)是为了兼容XML大写扩展名同理图片也做了扩展名过滤这样可以避免把Thumbs.db、DS_Store这类系统文件当样本处理。跑完后两边目录就干净了。4.3 替换官方代码里的 split 写法避开文件名点号陷阱摘要描述里的参考代码用的是name pic.split(.)[0]这在绝大多数情况下没问题但遇到2024.05.03_001.jpg这类文件名时会得到2024匹配必然失败图片被误删。我建议一律换成os.path.splitext(pic)[0]这是标准库专门处理扩展名的函数语义清晰且不会踩点号坑。对于“疲劳驾驶监测数据集”这种图片数量多、命名来源复杂的项目这种细节能救回不少样本。如果是在 Windows 上开发、Linux 上训练还需要先检查环境变量中的大小写敏感设置或统一将文件名和 XML 主名转成小写再匹配。4.4 清理后的验证步骤清理完不匹配数据不要急着训练。我一般先做三步验证第一步重新统计两个目录的文件数量确认完全一致第二步随机抽查 10 张图片用mimetype或图形软件打开确认图片没损坏第三步用一个简单的 DataLoader 加载一遍打印出返回的第一对图片和标注路径确保实际驱动训练的代码能正常读到。这里最容易翻车的地方是目录清理干净了但 DataLoader 内部还拼接了额外的前缀路径比如os.path.join(anno_dir, name .xml)里的anno_dir写错了。所以验证时别只在本地测最好在训练环境里做一次真实加载。5. 避坑与常见问题数据清理环节最容易被忽视的细节5.1 现象删了图片后XML 文件也莫名“损坏”了原因部分 XML 文件本身是空文件或格式不完整但文件名匹配成功清理脚本删掉了无标注的图片却没检查 XML 内容有效性。解决用ElementTree.parse()对每个 XML 做解析测试捕获ParseError把无法解析的 XML 和不匹配图片一起隔离。可以参考下面这段验证逻辑import xml.etree.ElementTree as ET for xml_file in os.listdir(anno_dir): if not xml_file.lower().endswith(.xml): continue xml_path os.path.join(anno_dir, xml_file) try: ET.parse(xml_path) except ET.ParseError as e: print(fXML 解析失败: {xml_file}, 错误: {e})这样做才能在进入训练前真正排除“坏样本”不只是排除“无配对样本”。5.2 现象脚本运行完图片和 XML 数量还是一致但训练损失不下降原因数量一致只能说明两边都能对上号但可能存在多张图片文件名相同、放在不同子目录里的情况——比如JPEGImages目录下还有一层按状态分的子目录open_eyes、yawning而脚本只遍历了顶层深层图片和 XML 的对应关系没被检查到。解决用os.walk递归遍历子目录或者先把所有图片移动到顶层目录再做匹配。对于疲劳驾驶监测数据集如果目录被整理成多级结构优先统一目录格式再清理不要只处理单一层级。5.3 现象清理后图片数量骤减感觉数据集“少了一半”原因可能是原数据集中大量图片本身就缺少标注或者是脚本把扩展名过滤写得太严比如只检查.jpg却漏了.jpeg导致真实图片没被纳入匹配范围误删、误移了一大批。解决先打印jpeg_list的前 50 个文件名确认扩展名和命名风格再调整endswith元组参数把要删除的图片移动到一个备份目录而不是直接删除这样即使删多了也可以恢复。对于训练集过小的情况建议优先检视是否有其他标注来源比如另一份 JSON 标注而不是直接降低训练标准。5.4 现象在本地 Windows 上清理正确提交到 Linux 服务器后却报错原因Windows 文件系统不区分大小写Linux 区分。本地匹配用的IMG_001.jpg和img_001.xml能通过测试Linux 上IMG_001.jpg对应img_001.xml就会失败。解决在脚本里先把所有文件名主名统一转为小写做匹配或者运行前用rename批量把图片和 XML 主名都转成小写。这是跨平台项目最容易忽略的坑绝大多数“数据集不匹配”报错其实都是大小写问题。5.5 现象删掉无标注图片后突然不知道该怎样调整训练集分布原因删除数据会改变类别分布特别是疲劳驾驶监测场景中“闭眼”和“打哈欠”这两类本身可能只占少数删除操作如果集中在这些类别上模型学习不到疲劳特征精度会明显下滑。解决清理后再做一次标注统计按类别统计闭眼、打哈欠、正常状态的样本数量如果某类太少可以考虑对该类图片做数据增强翻转、亮度调整来补充。不要只关注总量类别分布更直接地影响疲劳检测模型的最终效果。6. 快速定位与验证三步把“数据不匹配”这类问题锁定住遇到“图片与标注对不上”的困扰时与其反复猜测不如建立一个固定的排查习惯。我通常按下面的顺序走一遍最多五分钟就能定位到根因所在第一步打印两目录的文件数量和前五个文件名从名字长相判断是否存在明显的命名风格差异。这里常用的排查手段是写一个组合式统计脚本ls Dataset/dataset/JPEGImages | wc -l ls Dataset/dataset/Annotations | wc -l ls Dataset/dataset/JPEGImages | head -5 ls Dataset/dataset/Annotations | head -5第二步用字符串匹配脚本把“两张不同扩展名但主名相同”的文件找出来。这种案例最隐蔽比如894.jpg和894.jpeg同时存在于目录里但标注只有一个。第三步才是执行删除或移动操作——一定要先备份我通常备份到单独目录观察模型训练一轮之后再决定是否彻底删除。验证方法不复杂直接跑通一个能够真实加载数据的 DataLoader打印其返回的image.shape和xml_path字符串。如果这两项都能正确输出说明所有配对与路径配置都正常。从那以后我每次拿到新的疲劳驾驶监测数据集或类似 VOC 风格数据都会强制走一遍这个流程——列出文件名 → 检查配对 → 清理不匹配 → 验证加载。不再像第一次那样急着训练结果训了几个小时才发现数据根本是脏的。希望这篇文章能帮你在处理数据集报错时少走一段弯路少烧一点本来没必要烧的显卡时间。本文还有配套的精品资源点击获取