企业官网建设流程全解析

1. 为什么非得把WPI交通信号灯数据集“塞进”VOC2007这个老框架里？

我第一次看到“WPI交通信号灯数据集格式转换成VOC2007”这个需求时，心里其实是有点疑惑的——这年头谁还在用VOC2007？YOLOv8、YOLOv10、RT-DETR都跑得飞起，连MMDetection 3.0都默认支持COCO和自定义JSON了。但当我接手某高校实验室一个延续五年的交通感知教学项目时，才真正理解：不是技术落后，而是生态惯性太强。

这个项目用的是十年前搭建的一套完整教学实验链：从OpenCV图像预处理→VOC2007目录结构组织→Pascal VOC评估脚本（voc_eval.py）→Matlab可视化工具链→期末大作业自动评分系统。所有助教培训材料、学生实验手册、甚至考试题库里的代码截图，全是以JPEGImages/、Annotations/、ImageSets/Main/train.txt为基准写的。一旦改用COCO或YOLO格式，等于要重写整套教学基础设施——而他们只给了两周时间准备新学期开课。

WPI数据集本身质量很高：由某高校交通工程实验室在真实交叉路口部署多角度摄像头采集，包含红、黄、绿、左转箭头、直行箭头、行人信号灯六类目标，标注采用精确的像素级多边形（polygon），共12,486张图像，每张平均含3.2个信号灯实例。但它原生是JSON+PNG掩码格式，结构松散，没有train/val/test划分文件，更没有Pascal VOC要求的XML Schema校验机制。

所以，“转换”这件事的本质，不是简单地改个后缀名，而是完成一次跨范式的语义对齐：把WPI中“带几何属性的语义分割实例”，映射为VOC2007中“带边界框与类别标签的目标检测实例”。这个过程会丢失多边形精度，但换来的是整个教学系统的无缝兼容。我试过直接读取WPI原始JSON喂给PyTorch DataLoader，结果助教反馈：“学生跑通代码后，发现评估分数和实验报告模板对不上——因为voc_eval.py只认XML里的<bndbox>，不认JSON里的segmentation字段。”

提示：VOC2007不是一种“格式”，而是一套约定俗成的工程契约。它强制规定了目录结构、文件命名规则、XML Schema、甚至difficult和truncated字段的业务含义。转换的核心，是让WPI的数据“说VOC的语言”，而不是“长得像VOC”。

这个需求背后藏着三个刚性约束：第一，必须保留原始WPI的所有类别名称与ID映射（不能把“left_arrow”硬改成“arrow_left”）；第二，边界框必须严格包裹多边形最小外接矩形（min bounding rectangle），不能用近似拟合；第三，ImageSets/Main/下的train.txt、val.txt、test.txt必须与WPI官方发布的划分完全一致——他们用的是按采集日期分层抽样，不是随机打乱。

我后来在实验室服务器上跑了三次转换脚本，前两次都失败了：第一次生成的XML里<xmin>写成了负数（因为WPI原始坐标系原点在图像左上角，但某段代码误用了OpenCV的cv2.boundingRect()返回值顺序）；第二次<filename>字段漏写了.jpg后缀，导致voc_eval.py遍历JPEGImages/时找不到图——这些细节，文档里不会写，但会卡住每一个实操的人。

1.1 WPI与VOC2007的底层语义鸿沟：从多边形到矩形的不可逆压缩

WPI数据集的标注本质是实例分割（Instance Segmentation），每个信号灯实例用一组有序顶点坐标描述其精确轮廓。比如一个圆形红灯，在JSON里可能是这样：

{ "segmentation": [[124.5, 89.2, 128.7, 85.1, 133.2, 86.4, ...]], "category_id": 1, "image_id": "000123" }

而VOC2007是纯粹的目标检测（Object Detection）框架，它只要求一个轴对齐的矩形框（Axis-Aligned Bounding Box），用四个整数坐标定义：

<bndbox> <xmin>120</xmin> <ymin>83</ymin> <xmax>136</xmax> <ymax>92</ymax> </bndbox>

这两者之间存在天然的信息损失。WPI的多边形能表达倾斜箭头、椭圆倒计时器、被遮挡的半圆灯，但VOC的矩形框只能给出一个“保守包裹”。我在转换时做过对比测试：对同一张含左转箭头的图像，WPI原始多边形面积是217像素，而其最小外接矩形面积是342像素——膨胀率高达57.6%。这意味着训练时模型看到的“背景噪声”比真实目标还大。

但教学场景恰恰需要这种“保守性”。因为学生第一次写NMS（非极大值抑制）代码时，如果输入的是紧贴目标的多边形框，他们很难理解为什么IoU阈值设0.3就过滤掉大量重叠框；而用宽松矩形框，IoU计算结果更“钝感”，便于观察算法逻辑。这就像学骑自行车先用辅助轮——VOC2007的矩形框，是目标检测教学里的那副辅助轮。

关键在于，这个“压缩”必须可复现、可验证。我写了一个校验函数，对每个WPI实例：

1. 读取其多边形顶点，用Shapely库计算最小外接矩形（minimum_rotated_rectangle）；
2. 强制将其旋转至水平（即angle=0），得到轴对齐矩形；
3. 取整坐标并确保xmin < xmax且ymin < ymax；
4. 将结果与cv2.boundingRect(np.array(polygon).astype(int))输出对比——后者快但有舍入误差，前者准但慢。最终选了Shapely方案，因为教学代码必须零误差。

注意：WPI原始坐标是浮点数（如124.5），但VOC2007规范要求<xmin>等字段为整数。直接int(124.5)会截断为124，而round(124.5)是124还是125？Python 3的round()是“四舍六入五成双”，124.5会变成124。我统一改用math.floor(x + 0.5)，确保所有坐标向上取整，避免因舍入导致矩形缩进图像边界。

1.2 教学场景下的特殊妥协：difficult与truncated字段的“虚构”填充

VOC2007 XML里有两个常被忽略但教学必需的字段：<difficult>和<truncated>。它们在工业界几乎没人填（YOLO系列训练时直接忽略），但在教学评估中却是关键得分点。

• <difficult>：标记该目标是否难以识别（如小尺寸、严重遮挡、模糊）。WPI原始JSON里没有此字段。
• <truncated>：标记目标是否被图像边界截断。WPI多边形顶点若在图像内，truncated=0；若任一顶点坐标超出[0, width]×[0, height]，则truncated=1。

问题来了：WPI数据集虽有遮挡标注（如“occluded_by_pole”: true），但没提供“是否难识别”的主观判断。如果全填0，学生做实验时会发现所有样本difficult都是0，无法练习处理困难样本的技巧。

我的解决方案是设计一个可配置的启发式规则引擎：

• 若目标面积 < 120像素² →difficult=1（小目标）
• 若多边形顶点数 > 12 →difficult=1（复杂形状，如带锯齿的箭头）
• 若occluded_by_pole==true或occluded_by_tree==true→difficult=1
• 其余情况difficult=0

这个规则不是真理，而是教学脚手架。它让学生在voc_eval.py输出的AP（Average Precision）曲线里，能清晰看到difficult样本的召回率明显低于easy样本——从而理解“困难样本”在评估中的权重意义。

至于<truncated>，我写了个严谨的校验：遍历多边形每个顶点(x,y)，检查是否满足0 <= x <= img_width and 0 <= y <= img_height。但WPI有个坑：部分图像的EXIF信息里有旋转标记（Orientation=6），导致实际显示时图像顺时针转了90度，而多边形坐标仍是原始方向。我不得不先用PIL读取EXIF，对图像做transpose(Image.ROTATE_270)，再重新计算顶点坐标——否则truncated判断全错。

这说明：格式转换不是纯文本操作，而是图像-坐标联合空间的精密手术。你改一个XML字段，可能要动三处图像处理逻辑。

2. 转换流程的七步法：从原始WPI ZIP包到可直接训练的VOC目录

整个转换不是写一个脚本就完事，而是一个需人工介入、多轮校验的流水线。我把它拆成七个原子步骤，每步都有明确输入、输出、验证方式和失败回滚点。某次帮学生调试时，发现60%的问题出在第3步（图像重编码）和第5步（划分文件生成），所以这里我把每步的坑都摊开讲。

2.1 步骤1：解压与结构初筛——警惕WPI的“伪ZIP”陷阱

WPI官网提供的下载包名为wpi_traffic_light_dataset.zip，但解压后你会发现它根本不是标准ZIP：最外层没有dataset/根目录，而是直接平铺着annotations/、images/、splits/三个文件夹。更麻烦的是，images/里混着.png和.jpg两种格式，而VOC2007规范要求JPEGImages/下必须全是JPG（注意是大写JPEG，不是jpeg）。

我写了个初筛脚本check_wpi_structure.py，它会：

• 统计images/下各扩展名数量：{'.png': 8231, '.jpg': 4255}
• 检查annotations/里JSON文件是否与图像文件名一一对应（WPI用img_000123.png配img_000123.json，但有17个JSON文件缺失对应图像）
• 验证splits/里train.txt的每一行是否在images/中存在（发现3个文件名大小写不一致：IMG_00123.JPGvsimg_00123.jpg）

提示：WPI数据集维护者用的是Mac系统，而Mac的HFS+文件系统默认不区分大小写。当他们在Mac上打包ZIP时，IMG_00123.JPG和img_00123.jpg被视为同一文件，导致Linux服务器解压后只剩一个。我不得不手动从备份里恢复这3个文件，并在脚本里加了大小写归一化处理：filename.lower().replace('.png', '.jpg')。

这一步的输出，是一个干净的wpi_clean/目录，里面只有images_jpg/（全转为JPG）、annotations_json/（补全缺失JSON）、splits_txt/（修正大小写）。任何一步失败，脚本就停住并打印错误行号——绝不让脏数据流入下一步。

2.2 步骤2：图像标准化——为什么必须重编码为RGB JPEG？

WPI原始PNG图像有两大隐患：一是部分PNG是灰度图（mode=L），二是PNG支持Alpha通道（透明度）。VOC2007的JPEGImages/要求所有图像是3通道RGB JPEG，且无透明通道。直接用cv2.imread()读PNG再cv2.imwrite()存JPG，看似可行，但会埋雷。

我做过实验：用PIL.Image.open('xxx.png').convert('RGB').save('xxx.jpg', quality=95)，和用cv2.imread('xxx.png')再cv2.cvtColor(..., cv2.COLOR_BGRA2BGR)再cv2.imwrite(...)，生成的JPG在直方图上有细微差异。而教学用的OpenCV基础实验，要求学生用cv2.imread()读图，如果JPG编码参数不一致，学生代码里cv2.imread()读出的像素值会和老师PPT里的示例不一致——导致“为什么我的代码和答案不一样”的经典问题。

所以，我强制统一用PIL处理：

from PIL import Image import numpy as np def png_to_jpg(png_path, jpg_path): # 1. 读取PNG，自动处理透明通道 img = Image.open(png_path) if img.mode in ('RGBA', 'LA', 'P'): # 创建白色背景，合成透明图 background = Image.new('RGB', img.size, (255, 255, 255)) if img.mode == 'P': img = img.convert('RGBA') background.paste(img, mask=img.split()[-1]) # 最后一个通道是alpha img = background elif img.mode == 'L': # 灰度图转RGB img = img.convert('RGB') else: # RGB or RGBA已处理 img = img.convert('RGB') # 2. 严格控制JPEG编码参数 img.save(jpg_path, 'JPEG', quality=95, optimize=True, progressive=False)

关键参数解释：

• quality=95：平衡文件大小与失真，低于90会导致边缘出现JPEG块效应，影响学生观察边缘检测效果；
• optimize=True：启用熵编码优化，减小文件体积（WPI总图像约12GB，优化后省1.2GB）；
• progressive=False：禁用渐进式JPEG，因为某些老旧OpenCV版本不支持。

这一步完成后，images_jpg/里所有图都是标准RGB JPEG，cv2.imread()读出的shape必为(h, w, 3)，dtype必为uint8——这是后续所有教学实验的基石。

2.3 步骤3：XML生成核心——Shapely与min_bounding_rect的精准实现

这是整个转换的心脏。WPI的JSON里segmentation字段是扁平化坐标数组（如[x1,y1,x2,y2,...]），需先重构为点列表，再用计算几何库求最小外接矩形。

我对比了三种方案：

• OpenCVcv2.boundingRect()：最快，但输入必须是int32类型点阵，且对浮点坐标舍入不一致；
• Scikit-imagemeasure.regionprops()：需先转为二值掩码，内存爆炸（12GB图像转掩码需48GB RAM）；
• ShapelyPolygon.minimum_rotated_rectangle：精度最高，支持浮点，但需手动转水平矩形。

最终选Shapely，代码如下：

from shapely.geometry import Polygon, Point import numpy as np def polygon_to_voc_bbox(segmentation, img_width, img_height): # 1. 解析WPI的扁平化坐标 points = [] for i in range(0, len(segmentation), 2): x = float(segmentation[i]) y = float(segmentation[i+1]) # 边界裁剪：防止坐标溢出（WPI有少量坐标在图像外） x = max(0, min(img_width - 1, x)) y = max(0, min(img_height - 1, y)) points.append((x, y)) if len(points) < 3: return None # 无效多边形 # 2. 构建Shapely Polygon poly = Polygon(points) if not poly.is_valid: poly = poly.buffer(0) # 自动修复无效几何 # 3. 获取最小外接矩形（旋转版） rect = poly.minimum_rotated_rectangle # 4. 转为轴对齐矩形：取rect的四个顶点，计算包围盒 x_coords = [point.x for point in rect.exterior.coords] y_coords = [point.y for point in rect.exterior.coords] xmin = max(0, int(np.floor(min(x_coords)))) ymin = max(0, int(np.floor(min(y_coords)))) xmax = min(img_width - 1, int(np.ceil(max(x_coords)))) ymax = min(img_height - 1, int(np.ceil(max(y_coords)))) # 5. 确保bbox有效 if xmin >= xmax or ymin >= ymax: return None return [xmin, ymin, xmax, ymax]

这里有个关键细节：poly.buffer(0)。WPI的多边形标注偶尔有自相交（self-intersection）或顶点重合，导致Polygon对象is_valid=False。直接报错会让整个转换中断，而buffer(0)是Shapely推荐的修复方法——它会自动移除自交、合并重合点，生成一个拓扑有效的多边形。

我统计过：12,486个WPI实例中，有37个需要buffer(0)修复，占比0.3%。虽然少，但若不处理，脚本会在第37个文件崩溃，而学生只会看到“Error in file xxx.json”，根本不知道原因。

2.4 步骤4：类别映射表——如何让WPI的6类完美对齐VOC的“语义字典”

WPI原始类别ID是1~6，对应：

• 1: red
• 2: yellow
• 3: green
• 4: left_arrow
• 5: straight_arrow
• 6: pedestrian

而VOC2007没有预定义类别，需在XML里写<name>red</name>。表面看直接映射就行，但有两个深坑：

坑一：类别名称的“空格”与“下划线”之争
WPI用left_arrow，但某届学生实验报告里写成left arrow（空格），导致voc_eval.py统计时把left_arrow和left当成两个类别。我强制在映射表里用下划线，并在脚本里加校验：if ' ' in class_name: raise ValueError(f"Class name '{class_name}' contains space")。

坑二：pedestrian类别的歧义
WPI的pedestrian指人行横道信号灯（红绿小人），但VOC2007的person类别是通用人体检测。如果映射为person，学生用VOC预训练模型微调时，会把真实行人也当成信号灯——造成概念混淆。所以我创建了一个新类别pedestrian_light，并在ImageSets/Main/里单独建pedestrian_light.txt，确保教学评估时只算信号灯，不算路人。

最终的classes.txt长这样：

red yellow green left_arrow straight_arrow pedestrian_light

这个文件不仅是转换脚本的输入，更是整个教学系统的“语义字典”。助教用它生成PPT里的类别颜色图例，学生用它写label_map.pbtxt，voc_eval.py用它排序AP曲线。一个字符的差异，会导致整个评估链路错位。

2.5 步骤5：划分文件生成——复现WPI官方split的“时间戳指纹”

WPI的splits/文件夹里有train.txt、val.txt、test.txt，但内容不是文件名列表，而是每行一个JSON对象，含image_id和timestamp字段。例如：

{"image_id": "000123", "timestamp": "2022-03-15T08:23:41Z"}

而VOC2007的ImageSets/Main/要求纯文件名列表，如：

000123 000124 ...

问题在于：WPI的image_id是6位数字字符串（000123），但图像文件名是img_000123.jpg。如果直接去掉img_和.jpg，会得到000123，看似正确。但WPI有12个image_id重复（同一时刻多视角拍摄），而文件名是唯一的（img_000123_a.jpg,img_000123_b.jpg）。官方split只列了image_id，没指定视角。

我翻遍WPI论文和GitHub Issues，终于找到线索：作者在issue#42里说“split按最早采集的时间戳排序，取前70%为train”。于是我做了三件事：

1. 读取所有JSON标注文件，提取timestamp字段；
2. 用datetime.fromisoformat()解析时间戳，转为Unix时间戳整数；
3. 按时间戳升序排列所有图像，取前70%（8740张）为train，中间15%（1873张）为val，最后15%（1873张）为test。

这样生成的train.txt，和WPI官方train.txt的image_id集合完全一致（用set(train_official) == set(train_generated)验证）。但文件名列表是img_000123_a.jpg这样的，所以最终ImageSets/Main/train.txt里写的是：

img_000123_a img_000123_b ...

注意：VOC2007的train.txt里不能有扩展名，也不能有路径。我写了个正则替换：re.sub(r'^(img_\d+_[a-z])\..*$', r'\1', filename)，确保只留img_000123_a。

这一步耗时最长（读12,486个JSON解析时间戳），但必须做。因为教学实验要求“复现WPI论文的mAP”，而论文的mAP是基于这个时间戳划分算的。用随机划分，结果差0.8%，学生会质疑“为什么我的结果和论文不一样”。

2.6 步骤6：XML Schema校验——让每个文件都通过voc_eval.py的“面试”

VOC2007的XML不是随便写的，它有一套隐含Schema。voc_eval.py在解析时会做这些检查：

• <size>里的<width>和<height>必须与图像实际尺寸一致；
• <bndbox>的<xmin>必须 ≥ 0，<xmax>必须 ≤<width>；
• <object>必须有<name>、<pose>、<truncated>、<difficult>、<bndbox>五个子元素；
• <pose>必须是Unspecified、Left、Right、Frontal、Rear之一（教学用Unspecified）。

我写了个validate_voc_xml.py，对每个生成的XML执行：

import xml.etree.ElementTree as ET from PIL import Image def validate_xml(xml_path, img_dir): tree = ET.parse(xml_path) root = tree.getroot() # 检查size size = root.find('size') width = int(size.find('width').text) height = int(size.find('height').text) img_path = os.path.join(img_dir, root.find('filename').text) with Image.open(img_path) as img: if img.width != width or img.height != height: raise ValueError(f"Size mismatch: {img_path} is {img.size}, XML says {width}x{height}") # 检查bndbox范围 for obj in root.findall('object'): bbox = obj.find('bndbox') xmin = int(bbox.find('xmin').text) ymin = int(bbox.find('ymin').text) xmax = int(bbox.find('xmax').text) ymax = int(bbox.find('ymax').text) if xmin < 0 or ymin < 0 or xmax > width or ymax > height: raise ValueError(f"BBox out of bounds in {xml_path}: {xmin},{ymin},{xmax},{ymax}")

这个校验脚本不是可选的，而是发布前的强制门禁。某次我跳过这步，直接让学生用生成的VOC数据集训练，结果voc_eval.py在计算AP时抛出IndexError: list index out of range——因为一个XML里<xmax>写成了1921，而图像宽度是1920，导致IoU计算时数组越界。这种错误不会在训练时暴露，只在评估时崩，极其难调试。

2.7 步骤7：最终打包与MD5校验——交付物的“数字指纹”

当JPEGImages/、Annotations/、ImageSets/Main/全部就绪，最后一步是生成交付包。但教学场景要求“零差异交付”：助教A和助教B解压同一个ZIP，得到的文件必须字节级一致。

我用tar -cf wpi_voc2007.tar JPEGImages Annotations ImageSets，而非zip，因为tar在Linux/macOS下更稳定，且tar -cf默认按文件名字典序打包，确保可重现。然后计算MD5：

md5sum wpi_voc2007.tar > wpi_voc2007.tar.md5

这个.md5文件和ZIP一起发给助教。助教收到后运行：

md5sum -c wpi_voc2007.tar.md5 # 输出 "wpi_voc2007.tar: OK" tar -xf wpi_voc2007.tar

为什么不用zip？因为zip的文件时间戳在不同系统上可能不同，导致MD5不一致。而tar的-cf不存时间戳，只存内容，100%可重现。

这个交付包就是学生实验的“圣杯”。它不包含任何代码，只有标准VOC2007结构。学生用torchvision.datasets.VOCDetection(root='wpi_voc2007', year='2007', image_set='train')就能直接加载，和加载原始VOC2007数据集体验完全一致——这才是转换成功的终极标志。

3. 实测对比：转换前后在经典模型上的性能基线

光说“能用”不够，得证明转换没引入偏差。我用YOLOv5s（PyTorch Hub版）在原始WPI JSON格式和转换后的VOC2007格式上，分别训练了3个epoch，固定随机种子，对比关键指标。环境：RTX 3090，CUDA 11.3，PyTorch 1.12。

3.1 训练配置一致性保障：消除一切干扰变量

为了公平对比，我做了极致的配置对齐：

• 数据增强：都用Albumentations的Compose([HorizontalFlip(p=0.5), RandomBrightnessContrast(p=0.2)])，但WPI JSON训练时，增强作用于多边形顶点；VOC训练时，增强作用于矩形框——这是唯一无法对齐的点，也是转换的代价。
• 学习率：都用OneCycleLR，峰值学习率0.01，周期3 epoch。
• Batch Size：都设为32（显存刚好够）。
• 评估方式：都用voc_eval.py计算mAP@0.5，且只评估red、yellow、green三类（排除箭头类，因它们形状差异大，矩形框压缩更严重）。

关键控制点：WPI JSON训练时，我用mmdetection的CocoDataset，但强制将ann_file里的segmentation字段丢弃，只用bbox字段——这个bbox是我用和VOC转换同一套Shapely代码生成的。这样，两者的输入bbox完全一致，唯一区别是：WPI训练时模型看到的是JSON+bbox，VOC训练时模型看到的是XML+bbox。这排除了“bbox生成算法差异”这个变量。

3.2 性能对比表格：矩形框压缩的真实代价

这个-3.2%不是bug，而是格式转换的固有代价。它量化了“用矩形框替代多边形”的信息损失。教学中，我会把这个表格投影到教室屏幕上，告诉学生：“你们现在用的VOC数据集，比原始WPI精度低3.2%。但它的价值在于，让你能用一行代码VOCDetection(...)加载数据，而不用自己写JSON解析器——这就是工程权衡。”

有趣的是，在small object（面积<32×32）子集上，VOC的mAP比WPI低6.8%，印证了小目标对矩形框更敏感。这反而成了教学案例：我让学生修改YOLOv5的anchor_generator，把最小anchor从10x10调到6x6，结果VOC的small mAP提升到74.2%，接近WPI的75.1%——说明转换后的数据集，依然能支撑进阶实验。

3.3 推理速度与内存占用：VOC格式的意外优势

很多人以为VOC是“老古董”，性能一定差。但实测发现，在推理阶段，VOC格式有显著优势：

这个优势在教学演示中很关键。助教用VOC数据集做实时演示时，能稳定维持23 FPS（cv2.VideoCapture+ YOLOv5s），而用WPI JSON只能到17 FPS。学生看到流畅的检测效果，更容易建立信心。

提示：VOC2007的“古老”，恰恰是它的鲁棒性来源。它没有复杂的嵌套结构、没有动态字段、没有版本兼容问题。一个2007年的XML，今天用Python 3.11的xml.etree.ElementTree依然能秒级解析——这种确定性，在快速迭代的AI教学中，比追求0.1%的mAP提升更重要。

4. 常见故障排查手册：那些让我熬夜到凌晨三点的坑

转换脚本写完只是开始，真正考验功力的是排错。我把过去半年遇到的12个高频问题，按发生频率排序，每个都附上现象、根因、定位命令、修复方案。这些不是理论，是血泪教训。

4.1 问题1：voc_eval.py报错“KeyError: 'red'”，但XML里明明有<name>red</name>

现象：运行python voc_eval.py --voc-dir wpi_voc2007 --year 2007 --image-set train，报错KeyError: 'red'，而打开任意XML，<name>字段确实是red。

根因：voc_eval.py默认从wpi_voc2007/ImageSets/Main/下读red.txt、yellow.txt等文件，但WPI转换时我只生成了train.txt、val.txt、test.txt，没生成按类别分的red.txt。voc_eval.py找不到red.txt，就把red当不存在。

定位命令：

ls wpi_voc2007/ImageSets/Main/red.txt # 返回"No such file" grep -r "<name>red</name>" wpi_voc2007/Annotations/ | head -n 1 # 确认XML里有red

修复方案：生成类别文件。我写了个脚本gen_class_files.py：

import os from collections import defaultdict # 读取所有XML，统计每个类别出现在哪些图像 class_to_images = defaultdict(set) for xml_file in os.listdir('