1. 先弄明白 Apollo Scape 到底是个什么量级的东西第一次接触 Apollo Scape 的人多半是被它那个夸张的分辨率劝退的——3384×2710 的单帧图像光是打开一张就要等两三秒更别说动辄十几万帧的体量。这个数据集是百度 Apollo 自动驾驶平台对外开放的一套多模态数据覆盖语义分割、车道线、3D 车辆实例、点云配准、双目、轨迹预测等好几个方向在国内自动驾驶圈子里属于绕不过去的一块基础素材。它的价值不在于新而在于它把中国城市道路的真实面貌完整地拍下来并标注了高架桥、隧道口、多车道环线、电动车混行、逆光加雾霾这些在国外数据集里往往是边缘样本在 Apollo Scape 里却是常态。我自己是两年前做城市道路语义分割的时候被它意外收留的。当时用的公开集在城市快速路场景上一直掉点尤其是匝道汇入区和桥下阴影后来换成 Apollo Scape 的 Road03 子集重新训同一条主干道上的分割一致性肉眼可见地稳了。这套数据适合谁我的判断是三类人正在做语义分割或者车道线检测、想要中国道路场景样本的算法同学做多传感器融合、需要图像和点云对齐数据的研究者以及拿它当练手素材做课程设计或者论文复现的学生。不需要顶配显卡也能玩只要有耐心把下载和预处理这一关过了。1.1 它不是单一数据集而是一个数据家族很多人第一次搜 Apollo Scape 数据集 的时候会懵因为搜出来的结果五花八门有人说是语义分割有人说是点云配准还有人贴的是车辆检测。原因很简单Apollo Scape 从来就不是单一数据集它是一整套按任务拆分的子集集合。官方把它拆成了 Scene Parsing场景解析/语义分割、Lane Segmentation车道线分割、Self-Localization自定位点云与图像配准、3D Car Instance三维车辆实例、Stereo双目立体、Trajectory轨迹、Detection目标检测等几个主要方向。这种拆分逻辑其实非常务实。自动驾驶落地从来不是靠一个模型打天下感知前端要分割、要检测、要测距定位模块要配准预测模块要轨迹。把不同任务的数据拆开发布好处是每个子集都能针对性地把标注做深做透而不是做成一锅什么都有但什么都不精的大杂烩。代价就是下载和整理的工作量上去了你得先想清楚自己要解决哪个问题再去拿对应的那一份。1.2 和 KITTI、nuScenes 摆一起它的位置在哪做数据集选型的时候免不了横向比较。KITTI 是绕不开的老前辈传感器标定极其规范、评测榜单成熟但它的场景基本是德国小城的郊区道路车流量小、道路结构简单拿到国内复杂路况上迁移域偏移相当明显。nuScenes 则是另一条路子主打多传感器全包围雷达和相机配置豪华但它同样以欧美城市为采集地雨雾天气样本占比不高。Apollo Scape 的差异化定位就在中国城市复杂场景这几个字上。多车道、立体交叉、非机动车混行、大车遮挡、逆光、隧道明暗突变这些在 KITTI 里算是难例的东西在 Apollo Scape 里属于日常。它的像素级标注相当细致语义类别覆盖了道路、人行道、建筑、植被、天空、各类车辆、行人、非机动车、交通设施等近三十类对于想研究细粒度类别区分的人来说这个粒度是够用的。短板也要说清楚它的传感器标定文档不如 KITTI 那么事无巨细社区工具链也没有 nuScenes 那么成熟很多东西得自己动手啃。1.3 哪些任务拿它练手最合适我的经验是拿 Apollo Scape 做下面这几件事性价比最高。第一是城市道路语义分割尤其是你想验证模型在复杂背景下的鲁棒性这个数据集给你的是最硬的考题。第二是车道线检测Scene Parsing 里有专门的车道线类别Lane Segmentation 子集更是把车道线单独拎出来做了像素级标注几十段视频序列连续帧之间的车道线变化很自然做时序车道线跟踪也顺手。第三是图像与点云的联合任务Self-Localization 子集提供了点云和对应图像用来验证配准或者做跨模态特征对齐都是不错的起点。反过来如果你要做的是高速场景的远距离检测或者需要毫米波雷达数据那这个数据集就未必合适。它没有雷达通道场景也偏城市。选数据集最忌讳的就是手上有什么就用什么先把自己的任务需求写清楚再去对号入座这个顺序不能反。2. 数据集整体架构一张表看清子集划分与规模理解了它是个数据家族之后第二步就是把每个子集的定位、规模、采集方式弄清楚。这一步做扎实了后面下载和预处理才不会走弯路。我见过太多人一上来就把整个几十 GB 的包拖下来解压完发现里面一半数据自己用不上白白占了几百 GB 硬盘。下面这张表是我自己整理过的数据规模一栏以官方公布为准不同版本之间会有出入。子集名称主要任务数据形态参考规模采集特点Scene Parsing像素级语义分割高分辨率图像 单通道标签图约十万量级帧近三十类中国城市主干道、环线、桥隧Lane Segmentation车道线检测/跟踪图像 车道线像素标注约十万量级帧数十段序列连续视频帧车道线变化自然Self-Localization点云与图像配准激光点云 对应图像数千帧含外参适合跨模态研究3D Car Instance三维目标框点云 图像 3D 框数千帧车辆实例级标注Stereo双目立体匹配双目图像对 视差数万张立体视觉基线Trajectory轨迹预测目标轨迹序列不定时序预测素材2.1 Scene Parsing这套数据的主菜Scene Parsing 是 Apollo Scape 里被引用最多的一个子集也是我建议新手第一个上手的目标。它的基本单位是一帧图像 一张标签图标签图是单通道 PNG每个像素的值就是类别编号。这种编码方式非常朴素读取的时候几乎不需要额外的解析逻辑用 OpenCV 或者 PIL 读进来就是一个二维整型矩阵做 one-hot 也好做交叉熵也好都很直接。它的坑在于分辨率。3384×2710 这个尺寸直接塞进网络里训练会非常吃力显存瞬间爆掉。实际训练时几乎所有人都要做下采样常见做法是缩放到原图的四分之一甚至八分之一或者干脆用滑窗切块。这个取舍很关键缩得太小细小的行人、非机动车、车道线就糊成一片了标注本身没问题但模型学不到细节缩得不够小训练成本又下不来。我的经验是如果目标是主干道分割缩到 1/4 通常够用如果要在意车道线和行人这一类小目标那就得考虑切块训练或者保留更高分辨率。2.2 Lane Segmentation单独为车道线做的加餐Lane Segmentation 这个子集容易被忽略因为它和 Scene Parsing 在视觉上很像都是道路场景。但它的标注目标完全不同它只关心车道线本身而且是按序列组织的。官方把它切成若干段连续视频每段几百帧帧与帧之间的运动连续这对做车道线跟踪、时序平滑、甚至车道线预测的人来说是很好的素材。为什么单独做这个子集逻辑也很清楚。语义分割模型通常会把车道线当成一个细长小目标在整体损失里占比极低模型很容易学会放弃它反正不预测车道线整体 mIoU 也就掉那么零点几个百分点。但车道线对下游的路径规划来说是性命攸关的。把它单独拎出来做成一个子集等于强制模型把注意力集中到这一类上效果往往比在通用分割里顺带预测要好得多。我自己试过用同一个 backbone 分别训通用分割和车道线专项专项车道线的召回率明显更高。2.3 下载顺序建议先小后大先单后多如果你时间有限或者带宽和硬盘都不宽裕我的建议是按先小后大、先单模态后多模态的顺序来。先下一个体量小的子集比如 Self-Localization 或者 3D Car Instance把整套流程跑通——注册、下载、校验、解压、读标签、可视化——然后再去啃 Scene Parsing 这种大块头。这套流程本身要踩的坑不少用小数据集试错成本低得多。顺序上还有一层考虑先单模态、后多模态。单模态处理起来简单图像就是图像标签就是标签出问题容易定位。多模态涉及标定参数、坐标系变换、时间戳对齐一旦出错排查起来要绕好几个弯。先把手感建立起来再去做融合效率高得多。3. 标注体系拆解标签怎么读类别怎么对号入座数据集用得顺不顺八成取决于你对标注体系的理解到位不到位。Apollo Scape 的标注体系有几个特点需要提前心里有数类别粒度细、标签格式朴素、类别编号需要对着官方说明看。这几个特点决定了它的上手门槛不在于难而在于细节多不看说明会踩坑。3.1 语义标签的编码格式与读取方式Scene Parsing 的标签图是单通道 PNG这一点前面提过。读取代码非常简单一个 OpenCV 调用就够了import cv2 import numpy as np label cv2.imread(label/170927_000073_00179.png, cv2.IMREAD_UNCHANGED) print(label.shape, label.dtype, np.unique(label)[:20])注意这里必须加IMREAD_UNCHANGED这个标志否则 OpenCV 默认会把三通道读成 BGR把单通道灰度按某种规则转换读出来的数值就不是原始类别编号了。这个坑非常隐蔽因为读出来的形状可能还是对的只是数值被悄悄改过了训练的时候 loss 不收敛你还以为是网络结构的问题。我自己当初就在这上面卡过大半天最后是靠np.unique打出来的类别值跟官方文档对不上才发现。注意标签图一定要用IMREAD_UNCHANGED或者 PIL 的modeL来读任何默认的色彩空间转换都会污染类别编号。3.2 类别编号不能凭感觉猜得对着文档核Apollo Scape 的语义类别接近三十类每一类对应一个整数编号。这些编号是官方定的不是按字母顺序也不是按常用程度排的凭直觉猜基本必错。我见过有人把植被和建筑搞反训了半天 mIoU 死活上不去最后发现是类别映射表写错了白白浪费一张显卡的机时。正确的做法是先把官方给的类别说明整理成一张映射表写进配置里训练和评估都从同一张表读避免多处维护不一致。表格化之后还有一个好处可视化的时候可以按类别配色一眼就能看出模型把哪类认错了。这个习惯我强烈建议养成尤其是在类别数量超过十类之后靠肉眼看灰度图区分类别是不现实的。编号段位对应内容常见混淆对象道路及附属主路、人行道、非机动车道施工区域、路缘建筑与自然建筑、植被、天空、山体植被与建筑阴影车辆类轿车、客车、卡车、其他车辆客车与卡车、远处车辆行人与两轮行人、自行车、摩托车骑行者远距离行人与两轮交通设施车道线、交通标志、护栏车道线与路面标线这张表是个经验性的归纳具体编号务必以官方文档为准我这里想强调的是提前建表这个习惯本身。3.3 多模态子集的坐标对齐要格外小心Self-Localization 和 3D Car Instance 这类子集涉及点云和图像的对应关系坐标对齐是绕不过去的坎。激光雷达和相机各有自己的坐标系两者之间的刚体变换参数外参决定了点云投影到图像上是否严丝合缝。这个参数在数据集里是给出来的但怎么用是另一回事你得搞清楚它定义的是从雷达到相机还是从相机到雷达旋转和平移的先后顺序是什么单位是米还是毫米。我的建议是拿到数据之后第一件事就是做一次投影可视化把点云按外参投影到图像上看看轮廓对不对得上。对得上说明你理解正确对不上大概率是变换方向搞反了把矩阵求个逆再试。这一步花不了十分钟但能省掉后面几天的排查。做融合研究的人这一步绝对不能跳。4. 下载流程与本地目录组织实操下载这关是很多人放弃 Apollo Scape 的地方。数据体量大、下载脚本需要账号、解压之后目录层级深任何一个环节卡住都会让人烦躁。我把整个流程拆成注册取凭证、分批下载、整理目录三步按这个顺序来基本不会乱。4.1 注册账号与获取下载凭证Apollo Scape 的数据托管在官方平台上网址是apolloscape.auto以官方最新地址为准。你需要先在平台上注册一个账号登录之后进入数据集页面每个子集都有自己的入口。官方通常会提供一个下载脚本脚本里需要填入你的账号凭证运行之后它会自行验证并拉取数据。这里的操作要点有两个。第一账号凭证不要硬编码进脚本然后传到公开仓库这个错误每年都有人犯一旦泄露别人用你的账号去下数据你还莫名其妙。第二下载脚本在不同时期可能有不同版本参数名和调用方式会变拿到脚本之后先跑一次--help看看当前支持哪些参数别照着老教程硬套。我见过有人拿着一份两年前的教程操作结果参数名早就改了卡了一下午。# 示例流程参数名以官方脚本实际输出为准 python download_apolloscape.py --help python download_apolloscape.py \ --dataset scene_parsing \ --save_dir ./apollo_data \ --username your_account \ --password your_password4.2 分批下载与断点续传大子集动辄几十上百 GB一次性下完风险很高网络稍微抖一下就可能前功尽弃。我的做法是分批下载先把训练集拉下来验证集和测试集稍后再说或者干脆先只下一部分序列把流程跑通再补齐。下载工具层面优先选支持断点续传的方式。如果官方脚本本身不支持可以在它拿到真实下载地址之后改用wget -c或者类似的续传工具去拉。注意很多平台的下载地址是带时效签名的过期之后就得重新生成所以断点续传要在签名有效期内完成否则续不上。这一点我是实打实踩过坑的一个 40 GB 的包下到 80% 断了签名过期只能重新申请地址从头来。注意下载地址通常带时效长时间挂机下载前先确认签名有效期或者分块下载缩短单次时长。4.3 解压后的目录结构与我推荐的整理方式解压之后你会发现目录层级相当深而且不同子集的命名习惯不完全一致有的用日期时间戳命名有的用序列编号。原始结构大致是子集名/划分train/val/test/图像与标签分目录这样的形式。直接拿原始结构去训练不是不行但一旦你同时处理多个子集就会乱。我习惯的做法是建一个统一的数据根目录下面按子集名分文件夹每个子集里再统一成images/和labels/两个子目录划分信息单独用一个文本文件维护每行一个样本的相对路径。这样做的最大好处是训练代码只认这一套结构换数据集、换子集代码不用改划分换一下也只是改文本文件的事。数据整理这一步花的时间一定会在后面反复调试里赚回来。data_root/ scene_parsing/ images/ labels/ splits/ train.txt val.txt class_map.json lane_segmentation/ images/ labels/ splits/5. 常见问题与踩坑记录前面讲的是应该怎么做这一段讲实际会怎么翻车。这些都是我和身边人真金白银换来的教训写出来能帮你省下不少时间。5.1 磁盘、内存与解压的连环坑第一个坑是磁盘空间。几十 GB 的压缩包解压之后往往膨胀两三倍你以为准备了 200 GB 够用实际解压到一半提示空间不足那是真的难受。我的经验法则是压缩包体积乘以三再加上训练时要用的缓存空间这才是你应该准备的余量。而且解压过程中最好盯着点有些压缩工具遇到个别损坏文件会卡住不报错你以为在下其实已经停了。第二个坑是内存。高分辨率图像在数据加载阶段如果一次性全读进内存做缓存很容易把内存吃满。用 PyTorch 的DataLoader时num_workers和缓存策略要配合着调worker 开太多每个 worker 又缓存大图内存直接爆掉。我的做法是对大图只缓存路径读取时再做下采样牺牲一点速度换稳定。问题现象可能原因处理方向解压中途报错磁盘空间不足 / 包损坏检查剩余空间重新校验包训练时内存飙满缓存策略过于激进只缓存路径读取时下采样下载中断无法续传地址签名过期重新获取下载地址标签值异常读取时发生色彩转换用 IMREAD_UNCHANGED 读取5.2 标签读取异常的系统排查思路标签读出来数值不对这个问题的排查顺序我总结成三步。第一步打印np.unique看数值范围。如果范围是 0 到 255 的连续分布说明可能被当成灰度图做了拉伸如果范围集中在几个整数上说明读的是对的。第二步看 dtype正常的类别标签应该是整数型如果读出来是浮点多半是被转换过了。第三步拿一张标签图去可视化成彩色肉眼看是否符合场景比如天空应该在最上方道路在下方如果颜色分布明显错乱那就是映射表写错了。这三步走下来基本能定位问题。关键是不要跳过第一步就直接改代码很多人的习惯是读不对就换库OpenCV 换 PILPIL 换 skimage换来换去问题还在因为根源没找到。5.3 训练阶段的几点个人体会最后分享几个训练阶段的体会。第一别一上来就追求 SOTA 结构先用一个小模型把这个数据集跑通确认数据管道没问题这一步比调结构重要得多。第二学习率的设置要配合分辨率图像下采样之后等效感受野变了原来的学习率可能偏大我一般会先做几轮学习率扫描。第三评估阶段一定要分开看类别整体 mIoU 好看不代表小目标类好看把每一类的 IoU 单独打出来你会发现问题往往集中在几个小类别上。这个数据集后续还能怎么扩展我自己的思路是往时序方向走。单帧分割已经做得比较充分了但连续帧之间的一致性、车道线的时序跟踪、跨帧的目标关联这些方向还有不少空间。官网现在也在陆续放出更多子集值得持续关注。如果你手上正好有项目需要中国城市道路场景的数据Apollo Scape 值得花时间认真啃一遍前期投入的整理成本后面都会以更稳的实验结果还回来。