做室内要素识别最烦的就是数据。目标检测也好、语义分割也罢模型能不能在真实场景里站稳脚跟大部分时候不取决于网络结构有多花哨而取决于喂进去的样本够不够扎实。尤其是建筑物内部的地面、墙壁、天花板这三类要素看着简单实际标注起来全是坑墙角线怎么算、天花板和墙壁的交界怎么切、不同楼层的采光差异要不要管。我最近整理了一套专门做这件事的标注数据集1031张图、3个类别、labelme格式这里把从数据设计到实际使用的完整思路拆开聊聊。1. 这套数据集的定位为什么是地面、墙壁、天花板三个类别室内要素识别的应用场景其实非常细。机器人自主导航要区分可通行区域和障碍边界装修设计软件要把户型结构自动重建出来安防监控系统要判断人员是否进入禁行地带施工进度管理要核对墙面、地面的完成度。表面上看需求五花八门但往底层一抽大家都要先回答同一个问题这张图里哪些像素是地面哪些是墙壁哪些是天花板。所以这套数据集的核心逻辑就是做减法只保留三个最基础、最稳定的结构类别。相比动不动就二三十个类别的室内全景分割数据集三分类的好处非常直接标注一致性高、模型容易收敛、评估指标干净。尤其是当你要做的是结构感知类任务而不是细粒度的家具识别时地面、墙壁、天花板这三者已经覆盖了大多数空间理解的硬需求。为什么不把门窗、柱子、家具也标进去因为那属于另一层任务。门窗是附着在墙壁上的子区域家具是独立物体它们的标注逻辑和评判标准完全不同。如果混在一个集里类别不平衡会非常明显模型会为了照顾少数类而牺牲主体类的边界质量。与其贪多嚼不烂不如先把三个基础结构类别做到极致。另外从标注格式上这套数据选择了labelme的JSON格式每个目标都是一个多边形顶点集合。这个选择我是支持的。labelme格式的好处在于它的开放性没有专有数据库的约束一个JSON文件配一张图顶点坐标一目了然用Python就能直接解析不需要额外装重型SDK。无论你是要转成COCO、VOC还是直接喂给自定义训练脚本都非常灵活。2. 数据采集与标注规范我拆解1031张图的构成逻辑说到数据集质量很多人第一反应是数量够不够。但以我做数据工作的经验比数量更要紧的是样本的覆盖结构和标注的一致性。1031张图说多不多说少不少关键看你怎么分配。2.1 场景覆盖的取舍这套数据在采集上明显做了场景分层。我建议所有做室内识别数据集的人至少在采集阶段就要想清楚你的数据要覆盖哪些环境变量。具体到这套数据我拆出来大概有这么几个维度房屋类型住宅、办公楼、商业空间、工业厂房、地下室光照条件自然光、日光灯、暖黄光灯、混合光、暗光拍摄角度平视、仰视、略微俯视、鱼眼畸变装修状态毛坯、简装、精装、半施工状态遮挡程度空旷、有家具、有人员走动、有施工器械1031张图摊到这些维度里实际上每个格子都不算多。但这里有个容易被忽视的坑如果你的训练集里全是精装客厅模型一见到毛坯房就会崩。所以宁可每类场景少收一点也要保证场景种类的多样性。从我实际测试的情况看这套数据里毛坯房和施工状态的比例控制得比较合适。因为地面、墙壁、天花板这三类要素在毛坯状态下边界最清晰、最没有歧义模型在这种图上更容易学到结构本身的特征而不是被装饰物带偏。等模型在这些干净样本上站稳了再用精装场景去微调泛化能力会好很多。2.2 labelme标注的三个核心规范我拿到这套数据后第一件事就是抽查标注多边形和图像边缘的贴合度。看完之后要做个总结的话标注规范大概可以归纳成三条第一个规范是遮挡处允许外推。地面被沙发挡住了一部分标注时不要把沙发的轮廓描进去而是按照地面可见部分的方向趋势把被遮挡区域直接连过去。这样做的好处是模型在训练时能学到遮挡物背后的结构是连续的这一先验推理时遇到新遮挡物也能脑补出来。这个规则对结构类标注尤其重要如果你把遮挡边界也当成真实边界去标模型就会被各种家具拐角带乱。第二个规范是墙地交线优先于墙脚视觉线。很多标注新手会把踢脚线、墙裙的装饰线条当作地墙分界。实际场景里这些装饰会严重干扰标注。正确的做法是忽略所有装饰物以结构上的90度转角为分界。哪怕踢脚线凸出来5厘米从空间几何上它仍然是墙面的一部分。我抽查了一下这套数据在这一点上做得比较干净墙角线基本都是对齐结构转角而不是装饰边缘。第三个规范是天花板内边界包含梁和管道区域。厂房、地下室这类场景天花板上经常走管道、风管、桥架而且有大量下翻的梁。这些凸出物按语义应该归入天花板而不是单列一类。标注时直接用多边形把整个顶部区域框进去包括梁的侧面、管道占据的区域全部算天花板。刚开始可能觉得这跟视觉上看着不一致但模型学习的是语义归类不是美学判断。3. 数据预处理与格式转换从labelme到训练脚本的必经之路labelme格式是好的中间格式但它不会是训练脚本直接吃的格式。大多数分割框架要么要PNG掩码要么要COCO的JSON所以拿到数据后的第一件事就是写转换脚本。这里我把踩过的坑和推荐的做法一起说清楚。3.1 labelme JSON的解析要点每一个labelme JSON文件核心结构就是shapes数组里面每一个元素对应一个标注对象包含label、points和shape_type三个字段。解析时最要注意的是points的坐标参照系。labelme保存的坐标默认是相对于原始图片像素尺寸的绝对坐标这一点没问题。但如果你在标注之前用labelme自带的图像编辑功能裁剪过图片那坐标原点是以裁剪后的图为准的这里一定要跟标注时的操作对齐。我处理这套数据时统一做了一个校验读每个JSON里的imageWidth和imageHeight跟实际图片尺寸比对一旦不一致就用OpenCV重新对齐坐标避免训练时出现mask整体偏移的灵异现象。另外一个常见的坑是shape_type。labelme支持多边形、矩形、圆、线等多种类型但多数标注工具导出的都是polygon。我在解析脚本里会做一个防御性判断如果遇到非polygon类型的shape直接跳过并打印警告。因为这种shape在转换到分割掩码时很容易产生非预期结果。3.2 多边形转掩码的实现思路多边形转掩码最简单的办法就是用cv2.fillPoly。先创建一张全零的单通道图然后把多边形的顶点坐标组织成numpy数组格式传入fillPoly填充像素值。这里有一个性能上的小建议如果图片分辨率很大比如4000x3000直接fill整张图会比较慢可以先把多边形顶点映射到目标掩码尺寸再填充。还有一点容易被忽略顶点坐标的精度。坐标本身是float但像素掩码是离散的所以在fillPoly之前必须先转成int32。这里如果直接round取整某些情况下会在多边形边缘产生一个像素左右的锯齿偏差。更稳妥的做法是先用np.int32截断再统一平移半个像素补偿但这种细节对大多数模型训练来说其实可以忽略不用太较真。3.3 转换脚本的目录组织我处理这类数据集一般会固定一套目录结构dataset/ ├── images/ │ ├── img_0001.jpg │ └── ... ├── annotations/ │ ├── img_0001.json │ └── ... ├── masks/ │ ├── img_0001.png │ └── ... └── splits/ ├── train.txt ├── val.txt └── test.txt其中masks目录下是转换好的三通道掩码或者单通道索引图。如果是单通道索引图每个像素的值代表类别ID比如0是背景、1是地面、2是墙壁、3是天花板。训练时配合一个调色板转成伪彩色可视化即可。划分train/val/test时我强烈建议按场景来源划分而不是简单随机划分。因为同一套房子拍的连续帧画面内容高度相似如果随机划分训练集和验证集之间会存在数据泄露评估分数虚高。正确的做法是把同一场景的图片全部归到同一个子集然后按场景比例划分。我检查了这套数据的划分情况整体是按场景隔离的这一点做得比较规范。4. 训练与评估实测过程中的关键心得数据准备妥当后模型训练其实反而没那么玄乎。这里我根据自己的实测经验把训练配置、损失函数取舍和评估指标的意义捋一遍。4.1 训练配置建议针对三分类结构分割任务输入尺寸不用一味求大。我做了一组对照实验512x512的输入和768x768的输入相比在最终mIoU上差别不超过1%但训练速度差了将近一倍。原因在于地面、墙壁、天花板都属于大面积连续结构不是细小物体不需要极高分辨率去保细节。所以除非你的推理场景里墙角线特别复杂否则512x512是一个性价比很高的选择。数据增强方面常规的随机翻转、随机缩放、随机裁剪就够用不建议用过于激进的颜色抖动。因为这套数据的核心结构信息在几何形状上不在纹理颜色上。颜色抖动太强反而可能让模型在推理时对光照变化过度敏感得不偿失。骨干网络我用过ResNet50和轻量级的MobileNetV3做对比。在1031张图这个量级下ResNet50的mIoU比MobileNetV3高大概2到3个点但参数量和推理时间也上去了。如果你的项目是跑在边缘设备或者实时系统里MobileNetV3完全够用如果是离线分析、精度优先那就上ResNet50甚至更大的backbone。4.2 损失函数的实际取舍三分类分割里最常用的就是交叉熵损失加上一个ignore_index参数把背景像素跳过去。但在实际训练里我遇到过一个问题地面、墙壁、天花板在画面中的面积占比非常不均衡。比如一个仰视视角的图天花板占了70%的像素地面只有10%。这种情况下直接上交叉熵模型会对少数类产生明显偏见。解决方式有两个思路。一个是用加权交叉熵按照类别像素占比的反比设置权重另一个是用Dice Loss跟交叉熵做组合。我实际试下来0.5 * CrossEntropy 0.5 * DiceLoss的组合最稳既保留了交叉熵的收敛速度又靠Dice Loss拉了一把少数类的边界质量。训练初期Dice Loss的波动会比较大但20个epoch之后会逐渐稳定不用太焦虑。4.3 评估指标怎么看语义分割大家都用mIoU但mIoU对大面积类别不敏感。天花板就算某张图里完全没被预测到如果其他图里天花板占大部分面积整体mIoU还是会被拉高。所以我额外建议看一下每个类别的IoU单独打印出来。在这套数据上我实测下来通常墙壁IoU最高因为墙壁在绝大多数图片里都有、形状又相对规整。地面次之天花板最容易翻车特别是仰视角度大、有横梁的区域。如果天花板IoU明显低于其他两类可以在数据增强里加一个随机纵向翻转的坑因为天花板和地面的语义在翻转后会被混淆加入后必须小心处理。更有效的办法是专门补充一点仰视角度的样本或者在损失函数里把天花板的类别权重稍微调高。5. 实际应用场景与扩展思考数据集的终点不是训练脚本跑完而是落到真实业务里。这里我把这套数据的几个典型用法铺开说一下也算给后来者一个选型参考。5.1 机器人导航中的可通行区域提取地面分割是机器人视觉导航里最常用的一步。拿到模型预测的ground mask之后通常还要做一轮后处理连通域分析去掉小噪点、形态学闭运算填补空洞、再用Hough变换或者RANSAC拟合出墙脚线。这套数据在毛坯房场景下的地面边界标得比较干净用来训练导航前端的结构感知模块很合适。5.2 装修设计里的户型结构重建自动化的户型图生成本质上就是从输入图片里把墙面轮廓、天花板边界和地面区域剥离出来再投影到俯视图平面上。这套三分类数据可以作为结构抽取模型的基础训练集之后用少量带户型标注的数据做微调。我自己试过用这套数据预训练后再微调收敛速度比从零训练快了一半左右最终结构还原度也更高。5.3 施工进度自动核验工地上每隔一段时间拍一张现场照片然后用分割模型判断哪些区域已经完成了墙面施工、哪些地面还没找平。这个场景里三个类别对应的就是施工状态的核心检查项。因为这套数据里有毛坯和半施工状态的样本所以用起来比纯精装数据集要顺手得多。需要注意的就是标注规范里的第三条——管道和梁归天花板如果施工验收标准里要把管线和顶板分开计算那需要在后续任务里再细分但作为基础分类已经够用了。5.4 从三分类扩展到多分类的路径如果后续业务要求识别门窗、柱子、家具完全可以在现有三分类基础上做增量标注。模型先加载这套数据预训练好的权重再在新类别的标注数据上继续训练比上来就做十几类要稳得多。这也是我坚持推荐基础结构三分类先行的原因——它是室内感知任务的一个稳定底座上面可以长很多东西。6. 数据使用的避坑指南与个人经验总结最后这部分写给那些准备直接拿这套数据训练的人。全文最核心的几句提醒都放在这。第一一定要先做数据清洗。标注数据再用心也难免有边缘瑕疵。我在第一次训练前抽查了大概200个JSON发现有几张图的墙壁多边形把窗户也算进去了。如果你要做的是结构分割这种错误会直接影响模型对墙面的理解。处理方式是写一个脚本把每个多边形的面积、顶点数、长宽比统计出来面积异常小或者形状明显不符合房屋结构的对象单独列出来人工复核。第二训练前统一做色彩空间对齐。这套数据的图片来源可能混合了手机拍摄、监控截图、相机原片它们的色温和对比度差异非常大。虽然结构分割对颜色不太敏感但极端情况下比如某张图严重过曝墙壁和天花板的边界会肉眼不可分。我建议在训练管线里加一个简单预处理把所有图片转为RGB后统一做直方图归一化至少能减少一部分光照干扰。第三推理时注意输入尺寸与标注尺寸的一致性。如果你的推理图是1920x1080而训练输入是512x512不要直接把原图resize后丢进网络最好用保持长宽比的letterbox方式处理把多余部分填充为固定值。否则墙面、地面的几何形状会在resize时被拉伸变形边界预测质量明显下降。我在实际使用中还有个体会这套数据最适合的是当冷启动底模而不是直接作为最终业务的训练集。你拿着它先把模型跑通、把评估流程搭起来确认结果合理之后再往里面补充自己业务场景的数据。这样既不会被原始数据的偏差锁死又能大幅缩短项目早期从零到一的时间。如果你打算做室内结构识别这套数据值得认真看一下。标注规范的细节、场景覆盖的思路、还有三分类这个设计决策都有不少可以借鉴的地方。
