前段时间整理了一个带标注信息的交通信号灯识别数据集核心能力是识别左转灯、红绿黄灯实测识别率82.88%并且同步导出了YOLO、COCO JSON、Pascal VOC XML三种标注格式。这个数字不是拍脑袋报的是我在自己环境里完整跑训练和验证跑出来的结果三种格式也不是为了凑数而是为了让你拿到手之后不管用哪个主流目标检测框架都能直接开跑不用在格式转换上浪费时间。这篇文章就把这个数据集的构成、三类标注格式怎么选、82.88%到底是怎么来的、训练复现流程以及我实际踩过的坑一次说清楚。适合谁看正在做交通灯识别、辅助驾驶感知、智能交通方向的同学在学校做目标检测课题、想找个干净数据集快速验证模型的学生还有想拿一个带标注数据集横向对比YOLO、Faster R-CNN、DETR等不同模型的开发者。看完你应该能把“标注格式选哪个”“82.88%是准确率还是mAP”“怎么在自己环境里复现”这几个问题全弄明白。1. 带标注数据集到底解决了什么问题1.1 交通信号灯识别为什么比普通目标检测难很多人以为信号灯识别就是“找红绿灯”跟检测猫狗差不多实际上难度差的不是一星半点。信号灯在画面里通常是小目标一辆1080P画面的公交车占几百个像素一个信号灯灯芯可能只有二三十个像素检测网络一层层下采样之后特征图上的灯可能只剩一两个像素点很容易被背景吃掉。更麻烦的是灯是发光的白天逆光时灯芯和天空融为一体晚上又会有光晕、反光、过曝颜色特征极不稳定。这个数据集里的图像来源比较杂白天、夜间、晴天、雨天、逆光、顺光都有这也是我把它整理成带标注数据集的核心原因——交通信号灯检测的难点不只是算法更多是数据分布。很多团队自己采集数据拍了一堆视频标注时发现光是“框住灯”这个动作就够累的更别说还要区分左转箭头灯和圆盘灯。数据集的本质是把采集和标注这件事替你做了你拿到的直接是可用于训练的图片和标签。1.2 “左转灯、红绿黄灯”这几个类别怎么理解标题里说的“可识别左转灯红绿黄灯”在实际标注里拆开看是几类红灯、绿灯、黄灯这三类针对圆形灯盘左转灯又分左转红灯、左转绿灯、左转黄灯。严格说类别集合是6类而不是只有左转灯一类。为什么要单独把左转灯拆出来因为城市路口很多是分相位控制直行和左转的放行时间不一样如果模型只告诉你“有个红灯”但看不出是圆盘红灯还是左转箭头红灯决策层根本没法判断能不能进入待转区。把左转灯拆成独立类别相当于把“灯的颜色”和“灯的功能”两个信息同时交给模型这是从单纯目标检测走向实际应用的关键一步。1.3 82.88%这个数字的真实含义先泼一盆冷水这个82.88%不是单纯看颜色识别的准确率而是验证集上的mAP0.5IoU阈值取0.5时的平均精度均值。如果你只做颜色分类准确率能到95%以上因为颜色特征太明显了但目标检测除了“分得清颜色”还得“框得准位置”框偏差一点、把相邻的灯串进去、小目标漏检都会拉低mAP。我自己的判断是82.88%这个水平适合做辅助判断、预警系统、数据集基线对比不适合直接作为自动驾驶唯一决策依据。因为实际路口场景太复杂遮挡、晚霞、灯杆反光都会干扰检测工程落地时还需要加跟踪、时序滤波、多视角融合等手段。作为基线模型它足够说明数据和标注的有效性。2. 数据集构成与标注规则拆解2.1 类别设计与标注字段拿到这个数据集第一个要搞清楚的就是每类到底是什么。我按标识符说明一下red圆形红灯yellow圆形黄灯green圆形绿灯left_red左转箭头红灯left_yellow左转箭头黄灯left_green左转箭头绿灯每个标注框都包含类别名和边界框坐标具体的坐标存储方式跟格式有关后面会展开。图像尺寸不统一有1920×1080也有1280×720和标清图做训练时一般建议统一缩放到640×640或者1280×1280。这里有个特别要提醒的事如果你只用YOLO格式类别名的顺序不是“看起来应该这样”就行的。YOLO的txt标注文件里每行开头是一个数字类别ID这个ID对应你训练配置里names列表的下标。比如我的names是[red,yellow,green,left_red,left_yellow,left_green]那red对应0left_green对应5。很多人后面跑模型发现框的位置对但类别全错多半就是这里没对齐。2.2 场景多样性与标注质量数据集的图像来源覆盖了典型城市路口包括直行车道视角、左转车道视角、远距离全路口视角。图像里除了单独的灯也有多个灯组同时入画的情况比如一个画面里有圆形红灯和左转绿灯同时亮这种情况标注时就要各自单独框出来不能只框一个。夜间图像的处理我多说一句。灯是自发光物体夜间长曝光或者高ISO下红色灯的边缘会出现明显光晕灯芯中心泛白饱和度下降。早期标注版本里有人把光晕也框进去了训练出来的模型在夜间很容易把路灯、刹车灯、广告牌红色部分误检成红灯。后来重新做了清洗框的边界贴着灯壳内缘不算光晕夜间误检率明显下降。这种细节就是“标注质量”的体现也是拿到数据集后值得先看一眼的地方。2.3 为什么要单独讲“左转灯”这一能力很多公开交通灯数据集只标注了常规红绿灯左转箭头灯要么归到“灯”一个大类里要么干脆漏标。实际开车场景里左转灯和直行灯经常同时出现在同一根杆上形状相似但相位不同。如果你的模型只会检测“灯”不会区分“左转”和“直行”那么左转绿灯亮了、直行红灯也亮着的路口系统给出来的结果就是自相矛盾的。把左转灯单独识别价值在于决策层面可以拿到更细的信息。哪怕只是做一个预警系统当检测到左转红灯时提示“不可左转”也比单纯显示“红灯”要实用得多。这也是我整理这个数据集时坚持把左转灯独立成类的原因。3. 格式转换与训练实操3.1 三种标注格式的本质区别在开始训练前先把YOLO、COCO JSON、Pascal VOC XML这仨格式搞清楚。它们只是同一批标注数据的不同“存法”YOLO txt格式每个图像对应一个同名txt文件每行一个目标内容是class_id x_center y_center width height注意这四个值都是归一化到0~1的相对坐标不是像素坐标。COCO JSON格式整个数据集打包成一个JSON文件包含images、annotations、categories三块bbox是像素坐标格式是[x, y, width, height]其中x, y是框左上角坐标。Pascal VOC XML格式每张图像对应一个XML文件解析出filename、size、object节点下的bndbox坐标是像素坐标的绝对xmin, ymin, xmax, ymax。一句话总结YOLO适合直接给YOLO系列训练工具用COCO JSON适合Detectron2、MMDetection这类框架VOC XML适合老牌工具链和部分自研平台。数据本身没有区别只是格式不同。3.2 格式转换的核心逻辑我自己用的时候不依赖现成的转换工具因为工具的类别映射不一定跟你的一致写个小脚本更可控。核心逻辑其实就几句话从VOC XML转YOLO时读size拿到图像宽高把xmin, ymin, xmax, ymax转成中心点坐标再归一化。从COCO JSON转YOLO时要注意COCO的bbox存的是[x, y, w, h]而且annotations里的image_id要在images里找到对应的宽高同样归一化。下面是简化版参考代码import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, classes, img_width, img_height): tree ET.parse(xml_path) root tree.getroot() results [] for obj in root.findall(object): name obj.find(name).text if name not in classes: continue class_id classes.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) / img_width y_center ((ymin ymax) / 2) / img_height width (xmax - xmin) / img_width height (ymax - ymin) / img_height results.append(f{class_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) return results这段代码的意图很简单框出目标算中心点和宽高除以全图尺寸归一化。注意我没有把类别名写死在代码里而是通过classes列表传入这样可以保证YOLO的类别ID和你的names顺序完全一致。3.3 用YOLO系列工具跑一遍完整流程这个数据集最常见的用法就是直接训练YOLO系列模型。假设你已经解压了数据集目录结构大概是这样dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamldata.yaml里按自己的路径写train: dataset/images/train val: dataset/images/val nc: 6 names: [red, yellow, green, left_red, left_yellow, left_green]然后选一个YOLO训练工具。以常见YOLO系列的CLI为例训练命令大致是yolo detect train datadata.yaml modelyolov8s.pt epochs100 imgsz640 batch16这里我只列了最基本的参数。想复现82.88%的基线关键参数是输入尺寸imgsz640epoch一般在100左右batch根据显存自己调整。我实测超过100 epoch之后mAP提升非常有限反而有轻微过拟合风险验证集上的最佳模型通常出现在70到90 epoch之间。训练完看评价指标yolo detect val datadata.yaml modelruns/detect/train/weights/best.pt出来的mAP50就是你的最终指标。如果你跑出来在0.8左右浮动先别急模型初始化、GPU浮点运算差异、数据增强随机性都会带来2到3个百分点的波动。我的82.88%也是多次训练后取的平均水平。3.4 复现82.88%时值得注意的细节第一类别不平衡。黄灯在真实路口的出现频率远低于红灯和绿灯整个数据集里黄灯样本占比可能不到10%。训练时不建议直接按原始比例喂数据可以给黄灯类别的损失加权或者做简单重采样让每个batch里每个类别都尽量出现。第二小目标策略。灯芯像素太少时640的输入尺寸可能不够我试过把imgsz提到1280mAP能涨2个点左右但训练时间翻倍。如果你显卡还扛得住优先试1280否则就依赖YOLO的多尺度训练让模型在不同尺寸下都见过信号灯。第三数据增强别开太狠。默认增强里有随机裁剪、翻转、颜色抖动对于信号灯这种颜色敏感的物体颜色抖动会把红色改成偏橙色反而让模型误判。建议关掉或者调低色相和饱和度的增强强度保留轻度亮度和对比度扰动就行。4. 常见问题与排查技巧实录4.1 格式转换时的典型坑格式转换这个环节看起来简单实际操作中踩坑最多。COCO转YOLO时最容易错的是坐标相对化。COCO里bbox的宽高是像素值如果图像尺寸是1920×1080某个灯的width可能是25像素你必须除以1920得到约0.013的归一化宽度而不是除以你的输入尺寸640否则训练时框就飞到奇怪的地方去了。VOC XML转YOLO时容易出问题的点是width和height标签。有些XML不用size节点而是直接写width、height解析逻辑要适配两种写法。另外要注意XML里可能存在未标记类别的object节点比如difficult1的样本转换时要决定是保留还是丢弃。还有一个隐蔽问题文件名大小写。Linux环境下读取图像和标签时Train001.jpg和train001.jpg是两个文件。如果标签文件用了train001.txt图像名是Train001.jpg训练时会报找不到标签。遇到这种情况先做一轮统一命名的清洗再进训练环节。4.2 模型训练里的疑难杂症如果训练出来的模型总是把红灯和刹车灯混在一起多半是负样本不够。数据集里没有大量包含车尾灯、刹车灯、红色招牌的背景图模型对“红色发光物”泛化过头了。一个简单有效的做法是从已有图像里截取不含信号灯的区域作为背景图或者用公开的负样本图混合训练。如果夜间表现差画面里的灯芯和光晕让模型框出两三个重叠框可以在后处理里加大NMS的阈值或者对夜间图像做去光晕预处理。我试过左侧的“光晕内缩”策略——把标注框向内缩5%再训练夜间定位稳定性会好一些。还有个很多人忽略的点类别名的顺序。我把names定义成[red,yellow,green,left_red,left_yellow,left_green]如果你的YOLO txt里第一行是数字5训练脚本会认为它是left_green。如果跑出来发现“红灯被识别成黄灯但位置很准”九成是类别ID错位。4.3 问题排查速查表现象常见原因解决办法训练时报标签文件缺失图像名和标签文件名大小写不一致统一转换为小写文件名或按图像列表逐个核对框的位置偏到画面角落YOLO txt用了像素坐标但没归一化检查转换脚本确保除以图像宽高类别错乱但框的位置基本准确names顺序和类别ID没对齐优先检查data.yaml的names列表夜间把车尾灯误检成红灯负样本不足或标注框包含光晕增加背景负样本标注内缩黄灯完全不上分黄灯样本占比太低重采样、类别加权、降低黄灯的置信度阈值mAP50在0.6附近上不去输入尺寸过小或数据增强破坏颜色尝试imgsz1280降低颜色增强强度5. 怎么把它用到实际项目里5.1 不同场景下的格式选择如果你只是想快速验证一个想法比如比较YOLO和Faster R-CNN在这个任务上的差异直接用YOLO txt YOLO训练工具5分钟就能跑起来同时可以写个COCO格式导出给Detectron2用。这个数据集三种格式都给了实测下来优势就在这里不用自己维护两套转换代码。如果你做的是科研实验需要严格统一的评价方式建议用COCO JSON格式因为COCO的mAP标准包括mAP0.5:0.95是学术界公认的评价代码也成熟。用这个数据集跑出来的结果可以直接和其他公开结果放在同一标准下对比。如果你用的是传统视觉流程或者边缘设备推理平台VOC XML格式更友好因为很多老平台内置了VOC数据读取器改改路径就能加载。5.2 从82.88%往上走的几条实际路线说完了“能用”再说“怎么用得更好”。第一做时序跟踪。把单帧检测结果连起来用卡尔曼滤波或者简单的IOU追踪可以消除单帧误检。我实测加了跟踪之后连续视频里的误检率能降一半以上因为静态灯是持续出现的偶然闪出来的误检框会被时间维度滤掉。第二拆分类别粒度。现在左转灯分左红、左黄、左绿三类如果项目需要可以继续拆出“右转箭头灯”和“直行箭头灯”。数据集的标注体系是开放的你在这个基础上补标注比从零开始采集省太多时间。第三颜色域和亮度域做归一化。信号灯有一个别人不太注意的特性颜色主要由灯芯的色相决定而亮度变化剧烈。可以在输入前加一个轻量的白平衡校准或者归一化层减少不同相机、不同曝光下的颜色偏差。这个预处理在跨设备部署时特别有效。我自己实际走的路线是先用这个数据集把基线和评估流程固定下来再逐步加入自采的夜间和逆光样本做增量训练。这样每一步的效果都可以量化不会出现“模型越调越复杂但效果说不清”的问题。最后分享一个心得数据集的价值不在数量在标注质量和场景覆盖。很多团队花了几周时间标注最后发现类别不统一、坐标不归一、夜间框得乱七八糟训练效果还不如直接用一份整理好的数据跑个基线。带标注的交通信号灯识别数据集本质上就是帮你跳过最磨人的脏活把精力留给网络结构设计、策略融合和工程部署这些更有意义的事情上。你要是手头正好缺一批干净的信号灯数据从这个数据集起步是当下最省时间的选择。
前段时间整理了一个带标注信息的交通信号灯识别数据集核心能力是识别左转灯、红绿黄灯实测识别率82.88%并且同步导出了YOLO、COCO JSON、Pascal VOC XML三种标注格式。这个数字不是拍脑袋报的是我在自己环境里完整跑训练和验证跑出来的结果三种格式也不是为了凑数而是为了让你拿到手之后不管用哪个主流目标检测框架都能直接开跑不用在格式转换上浪费时间。这篇文章就把这个数据集的构成、三类标注格式怎么选、82.88%到底是怎么来的、训练复现流程以及我实际踩过的坑一次说清楚。适合谁看正在做交通灯识别、辅助驾驶感知、智能交通方向的同学在学校做目标检测课题、想找个干净数据集快速验证模型的学生还有想拿一个带标注数据集横向对比YOLO、Faster R-CNN、DETR等不同模型的开发者。看完你应该能把“标注格式选哪个”“82.88%是准确率还是mAP”“怎么在自己环境里复现”这几个问题全弄明白。1. 带标注数据集到底解决了什么问题1.1 交通信号灯识别为什么比普通目标检测难很多人以为信号灯识别就是“找红绿灯”跟检测猫狗差不多实际上难度差的不是一星半点。信号灯在画面里通常是小目标一辆1080P画面的公交车占几百个像素一个信号灯灯芯可能只有二三十个像素检测网络一层层下采样之后特征图上的灯可能只剩一两个像素点很容易被背景吃掉。更麻烦的是灯是发光的白天逆光时灯芯和天空融为一体晚上又会有光晕、反光、过曝颜色特征极不稳定。这个数据集里的图像来源比较杂白天、夜间、晴天、雨天、逆光、顺光都有这也是我把它整理成带标注数据集的核心原因——交通信号灯检测的难点不只是算法更多是数据分布。很多团队自己采集数据拍了一堆视频标注时发现光是“框住灯”这个动作就够累的更别说还要区分左转箭头灯和圆盘灯。数据集的本质是把采集和标注这件事替你做了你拿到的直接是可用于训练的图片和标签。1.2 “左转灯、红绿黄灯”这几个类别怎么理解标题里说的“可识别左转灯红绿黄灯”在实际标注里拆开看是几类红灯、绿灯、黄灯这三类针对圆形灯盘左转灯又分左转红灯、左转绿灯、左转黄灯。严格说类别集合是6类而不是只有左转灯一类。为什么要单独把左转灯拆出来因为城市路口很多是分相位控制直行和左转的放行时间不一样如果模型只告诉你“有个红灯”但看不出是圆盘红灯还是左转箭头红灯决策层根本没法判断能不能进入待转区。把左转灯拆成独立类别相当于把“灯的颜色”和“灯的功能”两个信息同时交给模型这是从单纯目标检测走向实际应用的关键一步。1.3 82.88%这个数字的真实含义先泼一盆冷水这个82.88%不是单纯看颜色识别的准确率而是验证集上的mAP0.5IoU阈值取0.5时的平均精度均值。如果你只做颜色分类准确率能到95%以上因为颜色特征太明显了但目标检测除了“分得清颜色”还得“框得准位置”框偏差一点、把相邻的灯串进去、小目标漏检都会拉低mAP。我自己的判断是82.88%这个水平适合做辅助判断、预警系统、数据集基线对比不适合直接作为自动驾驶唯一决策依据。因为实际路口场景太复杂遮挡、晚霞、灯杆反光都会干扰检测工程落地时还需要加跟踪、时序滤波、多视角融合等手段。作为基线模型它足够说明数据和标注的有效性。2. 数据集构成与标注规则拆解2.1 类别设计与标注字段拿到这个数据集第一个要搞清楚的就是每类到底是什么。我按标识符说明一下red圆形红灯yellow圆形黄灯green圆形绿灯left_red左转箭头红灯left_yellow左转箭头黄灯left_green左转箭头绿灯每个标注框都包含类别名和边界框坐标具体的坐标存储方式跟格式有关后面会展开。图像尺寸不统一有1920×1080也有1280×720和标清图做训练时一般建议统一缩放到640×640或者1280×1280。这里有个特别要提醒的事如果你只用YOLO格式类别名的顺序不是“看起来应该这样”就行的。YOLO的txt标注文件里每行开头是一个数字类别ID这个ID对应你训练配置里names列表的下标。比如我的names是[red,yellow,green,left_red,left_yellow,left_green]那red对应0left_green对应5。很多人后面跑模型发现框的位置对但类别全错多半就是这里没对齐。2.2 场景多样性与标注质量数据集的图像来源覆盖了典型城市路口包括直行车道视角、左转车道视角、远距离全路口视角。图像里除了单独的灯也有多个灯组同时入画的情况比如一个画面里有圆形红灯和左转绿灯同时亮这种情况标注时就要各自单独框出来不能只框一个。夜间图像的处理我多说一句。灯是自发光物体夜间长曝光或者高ISO下红色灯的边缘会出现明显光晕灯芯中心泛白饱和度下降。早期标注版本里有人把光晕也框进去了训练出来的模型在夜间很容易把路灯、刹车灯、广告牌红色部分误检成红灯。后来重新做了清洗框的边界贴着灯壳内缘不算光晕夜间误检率明显下降。这种细节就是“标注质量”的体现也是拿到数据集后值得先看一眼的地方。2.3 为什么要单独讲“左转灯”这一能力很多公开交通灯数据集只标注了常规红绿灯左转箭头灯要么归到“灯”一个大类里要么干脆漏标。实际开车场景里左转灯和直行灯经常同时出现在同一根杆上形状相似但相位不同。如果你的模型只会检测“灯”不会区分“左转”和“直行”那么左转绿灯亮了、直行红灯也亮着的路口系统给出来的结果就是自相矛盾的。把左转灯单独识别价值在于决策层面可以拿到更细的信息。哪怕只是做一个预警系统当检测到左转红灯时提示“不可左转”也比单纯显示“红灯”要实用得多。这也是我整理这个数据集时坚持把左转灯独立成类的原因。3. 格式转换与训练实操3.1 三种标注格式的本质区别在开始训练前先把YOLO、COCO JSON、Pascal VOC XML这仨格式搞清楚。它们只是同一批标注数据的不同“存法”YOLO txt格式每个图像对应一个同名txt文件每行一个目标内容是class_id x_center y_center width height注意这四个值都是归一化到0~1的相对坐标不是像素坐标。COCO JSON格式整个数据集打包成一个JSON文件包含images、annotations、categories三块bbox是像素坐标格式是[x, y, width, height]其中x, y是框左上角坐标。Pascal VOC XML格式每张图像对应一个XML文件解析出filename、size、object节点下的bndbox坐标是像素坐标的绝对xmin, ymin, xmax, ymax。一句话总结YOLO适合直接给YOLO系列训练工具用COCO JSON适合Detectron2、MMDetection这类框架VOC XML适合老牌工具链和部分自研平台。数据本身没有区别只是格式不同。3.2 格式转换的核心逻辑我自己用的时候不依赖现成的转换工具因为工具的类别映射不一定跟你的一致写个小脚本更可控。核心逻辑其实就几句话从VOC XML转YOLO时读size拿到图像宽高把xmin, ymin, xmax, ymax转成中心点坐标再归一化。从COCO JSON转YOLO时要注意COCO的bbox存的是[x, y, w, h]而且annotations里的image_id要在images里找到对应的宽高同样归一化。下面是简化版参考代码import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, classes, img_width, img_height): tree ET.parse(xml_path) root tree.getroot() results [] for obj in root.findall(object): name obj.find(name).text if name not in classes: continue class_id classes.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) / img_width y_center ((ymin ymax) / 2) / img_height width (xmax - xmin) / img_width height (ymax - ymin) / img_height results.append(f{class_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) return results这段代码的意图很简单框出目标算中心点和宽高除以全图尺寸归一化。注意我没有把类别名写死在代码里而是通过classes列表传入这样可以保证YOLO的类别ID和你的names顺序完全一致。3.3 用YOLO系列工具跑一遍完整流程这个数据集最常见的用法就是直接训练YOLO系列模型。假设你已经解压了数据集目录结构大概是这样dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamldata.yaml里按自己的路径写train: dataset/images/train val: dataset/images/val nc: 6 names: [red, yellow, green, left_red, left_yellow, left_green]然后选一个YOLO训练工具。以常见YOLO系列的CLI为例训练命令大致是yolo detect train datadata.yaml modelyolov8s.pt epochs100 imgsz640 batch16这里我只列了最基本的参数。想复现82.88%的基线关键参数是输入尺寸imgsz640epoch一般在100左右batch根据显存自己调整。我实测超过100 epoch之后mAP提升非常有限反而有轻微过拟合风险验证集上的最佳模型通常出现在70到90 epoch之间。训练完看评价指标yolo detect val datadata.yaml modelruns/detect/train/weights/best.pt出来的mAP50就是你的最终指标。如果你跑出来在0.8左右浮动先别急模型初始化、GPU浮点运算差异、数据增强随机性都会带来2到3个百分点的波动。我的82.88%也是多次训练后取的平均水平。3.4 复现82.88%时值得注意的细节第一类别不平衡。黄灯在真实路口的出现频率远低于红灯和绿灯整个数据集里黄灯样本占比可能不到10%。训练时不建议直接按原始比例喂数据可以给黄灯类别的损失加权或者做简单重采样让每个batch里每个类别都尽量出现。第二小目标策略。灯芯像素太少时640的输入尺寸可能不够我试过把imgsz提到1280mAP能涨2个点左右但训练时间翻倍。如果你显卡还扛得住优先试1280否则就依赖YOLO的多尺度训练让模型在不同尺寸下都见过信号灯。第三数据增强别开太狠。默认增强里有随机裁剪、翻转、颜色抖动对于信号灯这种颜色敏感的物体颜色抖动会把红色改成偏橙色反而让模型误判。建议关掉或者调低色相和饱和度的增强强度保留轻度亮度和对比度扰动就行。4. 常见问题与排查技巧实录4.1 格式转换时的典型坑格式转换这个环节看起来简单实际操作中踩坑最多。COCO转YOLO时最容易错的是坐标相对化。COCO里bbox的宽高是像素值如果图像尺寸是1920×1080某个灯的width可能是25像素你必须除以1920得到约0.013的归一化宽度而不是除以你的输入尺寸640否则训练时框就飞到奇怪的地方去了。VOC XML转YOLO时容易出问题的点是width和height标签。有些XML不用size节点而是直接写width、height解析逻辑要适配两种写法。另外要注意XML里可能存在未标记类别的object节点比如difficult1的样本转换时要决定是保留还是丢弃。还有一个隐蔽问题文件名大小写。Linux环境下读取图像和标签时Train001.jpg和train001.jpg是两个文件。如果标签文件用了train001.txt图像名是Train001.jpg训练时会报找不到标签。遇到这种情况先做一轮统一命名的清洗再进训练环节。4.2 模型训练里的疑难杂症如果训练出来的模型总是把红灯和刹车灯混在一起多半是负样本不够。数据集里没有大量包含车尾灯、刹车灯、红色招牌的背景图模型对“红色发光物”泛化过头了。一个简单有效的做法是从已有图像里截取不含信号灯的区域作为背景图或者用公开的负样本图混合训练。如果夜间表现差画面里的灯芯和光晕让模型框出两三个重叠框可以在后处理里加大NMS的阈值或者对夜间图像做去光晕预处理。我试过左侧的“光晕内缩”策略——把标注框向内缩5%再训练夜间定位稳定性会好一些。还有个很多人忽略的点类别名的顺序。我把names定义成[red,yellow,green,left_red,left_yellow,left_green]如果你的YOLO txt里第一行是数字5训练脚本会认为它是left_green。如果跑出来发现“红灯被识别成黄灯但位置很准”九成是类别ID错位。4.3 问题排查速查表现象常见原因解决办法训练时报标签文件缺失图像名和标签文件名大小写不一致统一转换为小写文件名或按图像列表逐个核对框的位置偏到画面角落YOLO txt用了像素坐标但没归一化检查转换脚本确保除以图像宽高类别错乱但框的位置基本准确names顺序和类别ID没对齐优先检查data.yaml的names列表夜间把车尾灯误检成红灯负样本不足或标注框包含光晕增加背景负样本标注内缩黄灯完全不上分黄灯样本占比太低重采样、类别加权、降低黄灯的置信度阈值mAP50在0.6附近上不去输入尺寸过小或数据增强破坏颜色尝试imgsz1280降低颜色增强强度5. 怎么把它用到实际项目里5.1 不同场景下的格式选择如果你只是想快速验证一个想法比如比较YOLO和Faster R-CNN在这个任务上的差异直接用YOLO txt YOLO训练工具5分钟就能跑起来同时可以写个COCO格式导出给Detectron2用。这个数据集三种格式都给了实测下来优势就在这里不用自己维护两套转换代码。如果你做的是科研实验需要严格统一的评价方式建议用COCO JSON格式因为COCO的mAP标准包括mAP0.5:0.95是学术界公认的评价代码也成熟。用这个数据集跑出来的结果可以直接和其他公开结果放在同一标准下对比。如果你用的是传统视觉流程或者边缘设备推理平台VOC XML格式更友好因为很多老平台内置了VOC数据读取器改改路径就能加载。5.2 从82.88%往上走的几条实际路线说完了“能用”再说“怎么用得更好”。第一做时序跟踪。把单帧检测结果连起来用卡尔曼滤波或者简单的IOU追踪可以消除单帧误检。我实测加了跟踪之后连续视频里的误检率能降一半以上因为静态灯是持续出现的偶然闪出来的误检框会被时间维度滤掉。第二拆分类别粒度。现在左转灯分左红、左黄、左绿三类如果项目需要可以继续拆出“右转箭头灯”和“直行箭头灯”。数据集的标注体系是开放的你在这个基础上补标注比从零开始采集省太多时间。第三颜色域和亮度域做归一化。信号灯有一个别人不太注意的特性颜色主要由灯芯的色相决定而亮度变化剧烈。可以在输入前加一个轻量的白平衡校准或者归一化层减少不同相机、不同曝光下的颜色偏差。这个预处理在跨设备部署时特别有效。我自己实际走的路线是先用这个数据集把基线和评估流程固定下来再逐步加入自采的夜间和逆光样本做增量训练。这样每一步的效果都可以量化不会出现“模型越调越复杂但效果说不清”的问题。最后分享一个心得数据集的价值不在数量在标注质量和场景覆盖。很多团队花了几周时间标注最后发现类别不统一、坐标不归一、夜间框得乱七八糟训练效果还不如直接用一份整理好的数据跑个基线。带标注的交通信号灯识别数据集本质上就是帮你跳过最磨人的脏活把精力留给网络结构设计、策略融合和工程部署这些更有意义的事情上。你要是手头正好缺一批干净的信号灯数据从这个数据集起步是当下最省时间的选择。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
