从零构建河道漂浮物分割数据集：采集、标注与训练实战

在河道环境治理的一线项目里，最让人头疼的往往不是巡检人员的责任心问题，而是“看得过来”和“看得清”这两个基本诉求之间的天然矛盾——尤其在汛期，上游冲下来的枯枝、生活垃圾、水生植物常常在某一个桥墩或弯道口聚集，形成一片片漂浮物带。人工盯监控屏，盯十分钟眼睛就花；无人机航拍巡检，拍回来几百张图还得靠人逐张判读。我这次想聊的，就是自己从零构建一套河道口水面漂浮物识别分割的完整过程：从目标定义、数据采集、labelme格式标注，到907张、2个类别的数据集最终成型，再到用这份数据去训练分割模型的实测心得。文中不会只摆结论，会把每一步的思考过程和踩过的坑都摊开，给同样在做水面漂浮物识别或者计划自建数据集的同行一个可以直接参考的路线。

这套数据集本身并不复杂，但恰恰因为“简单”，它对标注规范、类别边界、场景多样性的要求反而更高。如果你正打算做类似的水面目标识别，或者手里有一个自定义数据集需求却不知道怎么定规范、怎么保证labelme格式没有暗坑，这篇内容应该能帮你避开不少弯路。

1. 为什么非要做自己的漂浮物数据集

1.1 公开数据集和真实河道场景之间的错位

刚开始接到这个需求时，我的第一反应也是先找现成的公开数据集——节省时间，团队也省力气。真去找一圈就会发现一个尴尬的问题：做水面垃圾检测的公开数据不是没有，但绝大多数采集自开阔湖面、平静水库或标准化试验池，目标形态很“干净”，和真实河道口的漂浮物完全是两码事。

河道口是一个很特殊的物理位置：水流方向突然改变，流速下降，漂浮物会在这里聚集、旋转、堆叠。我实地踩点过几个典型的河道口，发现实际情况远比想象复杂——水葫芦带往往贴着岸边堆积，下面是深色根须，上面是绿色叶片；生活垃圾则呈现塑料袋、饭盒、瓶子混杂的状态，一部分半沉半浮，像素上跟水面波纹混在一起；还有被水流打散的枯枝，形态细碎，一只木棍能被分割成七八段。等于说，公开数据集里那种“完整、清晰、居中的目标”在真实场景里几乎不存在。

更重要的是，河道口水面有强烈的动态干扰：太阳反光、倒影、波纹、水流拖尾、岸边植物投影，这些在分割任务里都会被模型当成候选区域。公开数据集一般没有刻意采集这种复杂场景，拿它们的样本训练出来的模型，部署到现场往往第一轮就崩——误检满天飞，召回倒是不低，但根本不能用。

1.2 最终决定自建数据集的三个核心原因

综合评估下来，我确认自建数据集这件事必须做，原因也集中在三点，后面所有工作都围绕它们展开。

第一是场景契合度。模型最终要在真实河道口跑，训练数据就必须来自河道口。这一点没什么好商量的，分割模型尤其吃“域”，光照角度、水质颜色、河面宽度、岸边植被形态都会让特征分布偏移。与其指望模型迁移，不如一开始就让数据长在目标场景里。

第二是类别控制。任务定位是识别分割漂浮物，不是做精细垃圾分类。前期调研发现一线巡检最关心的是“哪里有漂浮物、覆盖面多大、面积在增长还是减少”。这决定了标注类别不能分得太碎，否则标注成本、模型难度都会上升，而现场并不需要区分“矿泉水瓶”和“食品包装袋”。两个类别是合理折中：一类是漂浮物整体，一类是背景中的干扰目标。

第三是标注格式的需要。项目交付涉及二次开发，团队后续会做模型部署、前后端联调，甚至会拿数据训练不同框架的分割模型。labelme格式作为中间标注格式是最稳妥的选择——它信息保留完整，支持多边形标注，转COCO、VOC、YOLO都很成熟。后面对接哪个框架都不至于被格式卡脖子。

2. 数据集设计的核心决策：907张、2个类别、一套可复现的采集方案

2.1 类别边界怎么划定才不会被标注员反复追问

“漂浮物”听起来很好理解，但落到具体标注上，边界问题就来了。根茎还扎在岸边的水葫芦算不算？只露出一个角的白色塑料袋算不算？漂浮在水面上但已经干枯发黑的树叶算不算？这些问题如果不提前定清楚，几个标注员能给你标出完全不一致的答案。

我们的最终定义是：物理上脱离河道底部或岸壁、整体悬浮或半悬浮于水面上、来自人类活动或水生植物生长的物体，统一归为“漂浮物”类别。岸边生长中的植物、河床水草、水下阴影、桥墩、船舶等一律不标。这个定义不完美，但足够可操作，保证了标注的一致性。

第二个类别定的是“水面背景”里的典型干扰目标，主要包含倒影、反光、波纹高光区。这个类别初看好像是凑出来的——实际训练时作用很大。分割模型如果没有这类负样本兜底，很容易把强反光区域预测成漂浮物边缘。单独设一个类别让模型专门学“这玩意儿像漂浮物但不是”，比单纯靠背景标签隐式地学，收敛效果好得多。

2.2 907张样本是怎么分布在不同场景下的

907张这个数量，坦白说对分割任务不算大，但合理设计后完全够用。关键在于每张图之间的差异度要足够大，而不是搞一堆“换了角度其实场景一样”的近重复图。

我采用的采集策略是：固定三个不同类型的河道口观测点，分别代表城市硬质河道段、半自然土坡河道段、闸口缓流区。每个点位在同一周内的不同时间段采集——早、中、晚各一批，阴天、晴天、雨后各一批。同时调整拍摄角度（俯拍为主、侧拍为辅，模拟不同安装位置的监控视角），这样907张图里包含了不同光照条件、不同水流速度、不同漂浮物聚集程度，多样性明显高于随机连拍。

因为涉及商业项目，具体点位信息不方便直接公开，但有一点可以分享：数据采集前一定先去目标现场摸排一遍光照变化规律，比如上午太阳在东侧，水面反光出现在什么区域；下午时反光位置怎么移。把这些问题摸透了再定拍摄时间表，远比事后靠增强硬扛有效。

2.3 一张图里到底标了多少东西才合理

标注密度也是一个需要拿捏的度。有段时间为了追求“全面”，每个漂浮物区域不管多小都标成一个独立多边形，结果一张图十几个标注对象，既增加标注工作量，也让训练变得不稳定——小块目标像素占比太低，模型很容易忽略。

后面我们定了规则：单块面积小于整图面积 0.3% 的漂浮物不标，多块碎片距离太近（间距小于两个物体最小外接宽度）时合并成一个大区域标注。这条规则看着简单，但让模型的预测目标和人类视觉感知在整体上一致了，训练收敛速度和指标都有提升。真正决定标注质量的不是最快的手速，而是事先定清楚的那几条规则。

3. labelme格式的细节：结构、陷阱、转换前必做的几件事

3.1 逐字段拆解：理解每一个节点在后续训练中的用途

labelme的格式，多数人只是把它当作一个“中转格式”——用labelme工具标完，直接转成COCO或VOC就开训。但我建议所有人标完第一版先别急着转，花半小时把JSON结构读明白，因为很多隐蔽问题就藏在里面。

一个标准的labelme JSON包含：version（版本号）、flags（位标记，通常为空）、shapes（标注记录数组）、imagePath（相对图片路径）、imageData（压缩后的base64图像数据）、imageHeight/imageWidth（图像尺寸）。其中shapes数组里每个元素又包含label（类别名）、points（多边形顶点坐标）、group_id（组ID）、shape_type（polygon、rectangle、line等）、flags等字段。

这里最容易翻车的是imagePath字段。标注时图片在A目录，标注完工程文件移到了B目录，如果imagePath记录的是绝对路径，转换脚本一跑就报路径错误。更隐蔽的是，labelme保存的JSON里通常会带imageData字段，也就是把整张图base64塞进去，如果对接的框架读取时优先解析imageData，但转换脚本只认imagePath，两张图的像素对不上，你的数据标签和图像就错位了——这个问题极难排查，因为整体看起来一切正常，但训练曲线诡异。解决方案是所有转换脚本统一以imagePath为准，并且全部转成相对路径。

3.2 多边形标注的质量底线：贴合度、顶点数与锯齿治理

做分割训练的人应该都有体会：多边形标得太粗糙，模型的边缘预测就跟着粗糙。边界明明是很平滑的轮廓，你拿十几个点一顿乱点，模型学到的就是一段“折线”，后续要再想提升边缘精细度就难了。

对于水面漂浮物这种不规则物体，我要求的标注贴合度是三档：整体轮廓不能有超过1-2个像素的明显偏离；凹陷和凸起必须保留，不能为了省事拉直；顶点数量控制在14-40个之间，边缘越平滑的物体点越少，轮廓越破碎的点越多——但不是说点越多越好，点太密了多边形退化成锯齿，模型学出来的边缘反而抖得厉害。

标注完成后的质量检查阶段，比较有效的一个手段是抽查叠加可视化：把标注多边形叠加在原图上，透明度调低，滚动检查边缘贴合情况。从放大视角看，主要检查两类问题——一类是顶点穿帮把旁边的岸线、护栏包了进来，另一类是漂浮物边缘的漏标（透明部分跟背景混在一起没盖住）。这两个问题会直接体现在模型的边界敏感度上，标者不察、练者受害。

3.3 2个类别里容易出现的干扰项与污染数据

开标之前我以为最花时间的会是复杂轮廓，实际标完发现，最花时间的是反复剔除干扰项。水面场景干扰太多：岸边装置的倒影在水里形成和漂浮物极其相似的形态，阳光在波纹上形成的条状反光，桥洞下的暗色阴影边缘，都能让标注结果变得不可控。

这里有一套务实的做法：标注阶段只标真实漂浮物，遇到干扰但不影响判断的画面正常给背景。但在审核阶段，把那些“疑似干扰”的事例单独汇总，在转换后把它当作负样本参与训练增强，而不是直接丢掉。等于把标注员的犹豫点转化成了模型的“错题本”，实测下来对降低误检非常有效。

另外，污染数据要警惕的另一类是“穿帮图”——比如岸上行人走过、有鸟飞过、水道清洁船入镜。这种目标如果没标，相当于给模型喂了不知道答案的素材。哪怕它不在标注定义的类别里，我也会单独建一个“其他无关目标”的临时标签过滤掉，确保任何出现在画面里的显眼目标都有归属。

4. 从labelme到模型训练：数据转换、划转与增强策略

4.1 JSON转PNG Mask的完整流程与容易忽略的坐标问题

labelme本身自带转换工具，但直接用原版脚本往往会遇到版本兼容问题。我的流程是：先统一JSON schema版本，再写脚本批量读取解析，生成灰度Mask和彩色Mask，最后按数据划转比例归档到训练、验证、测试目录。

坐标问题是这个地方的头号陷阱。labelme坐标系以图像左上角为原点，x向右、y向下，而大部分分割框架（比如PyTorch系）遵循相同的原点规则，但转VOC格式时采用的坐标表示方式不同，边界框计算要格外留心。建议转换后做一次可视化回读：把生成的PNG Mask和原始图透明度叠加，随机抽1%的样本人工核对。不要依赖那种“自动检查通过”的脚本，因为像素错位这种事，机器跑不出报警，只有人眼能看出来。

batch转换的流程里，还有一个容易被忽略的细节是类别索引从1开始映射前景，0留给背景。两个类别时，Mask像素值就是0、1、2三个取值，任何超出这个范围的像素值都说明标注有重叠或空值。转换脚本里加一行断言：断言Mask中唯一值集合等于{0,1,2}，这一步能提前抓住大部分标注交叉叠盖问题。

4.2 数据划转时怎么分配才能让两个类别的可靠性同时在线

907张图如果简单按8:1:1随机切分，很容易出现同一时段、同一视角的图同时出现在训练集和验证集里，导致验证分数虚高——模型其实是在“背答案”，不是真的泛化得好。

我的方案是按采集批组划分：早中晚各为一个批次组，每组内随机分配到训练/验证/测试，但训练集和验证集不共享任何同组数据。三个采集点位分别占训练集、验证集、测试集约70%、15%、15%。这样，验证集在“环境”上对模型是陌生的，分数更有说服力。

同时保证两个类别像素占比的平衡性。我统计过，真实场景里水面反光类别的像素占比远大于漂浮物——比例大约是三比一。如果直接端到端训练，模型会倾向于把漂浮物边界“吞”掉。所以我在划转时做了简单的像素加权：漂浮物类别loss权重设为反光类别的1.5倍，这个调整比削尖脑袋去挖更多数据更立竿见影。

4.3 增强策略里的“有用”和“有害”

水面漂浮物分割的增强，直接套用普通分割任务那套随机翻转、随机旋转会出问题——水面有方向性和重力感，你把它旋转90度生成出来的训练样本，在物理规律上是诡异且极难发生的，模型学到这种“不可能的场景”反而会降低真实场景的表现。

我实际使用的有效增强组合是三件套：轻微随机缩放（0.8-1.2倍）、水平随机翻转、颜色扰动（亮度±15%、对比度±10%、饱和度±8%）。前两个保持物体的物理合理性，第三个模拟不同天气光线下水面颜色的变化。此外加了一个其他场景不太会用的策略：随机遮挡模拟。在漂浮物区域随机放置矩形遮挡块，逼迫模型不能只靠局部纹理猜类别，必须要结合周边上下文来判断——这个策略对河道口这种目标部分沉没的场景帮助很大，实测能把分割边界准确度拉高两三个点。

需要避免的是过度增强。水面反光这类目标本身形态就千变万化，你再给它加上粗颗粒噪声、极端的透视变换，模型学出来的特征就漂了。增强的目的是弥补样本不足，而不是制造失真。每次调完增强策略，都应该在验证集上回测一个增量，数字说话，不要凭感觉堆叠。

5. 用这份907张数据集训练分割模型的真实反馈

5.1 基准模型选择与训练配置：为什么不用最新最大

现在的分割模型选项很多，从U-Net到DeepLabv3+再到各类Transformer结构，但在项目场景里，最终被选中上线的往往是那个在精度、速度、部署复杂度上折中最稳的选手。

最终我选的是DeepLabv3+系列作为基准主干，原因有几个：一是结构经典，社区方案成熟，遇到问题容易找到对照；二是配备MobileNet类轻量主干时，在嵌入式设备上跑实时推理不费劲；三是这类模型对局部细节和全局语义的平衡做得比较好，比较适配水面这种“强纹理背景+弱目标”的场景。Transformer类模型不是不好，是在只有907张训练图的情况下，它学不出足够强的泛化能力。数据量决定模型复杂度，这个判断不要动摇。

训练配置上，输入分辨率我用640x640——再高的话，小尺寸的漂浮物区域细节是清晰了，但显存开销上升非常快，而且现场部署时若是CCTV低分辨率视频流，模型在高分辨率上学的特征用不上。初始学习率0.001，用多尺度训练加输出步长调优，前50轮用高学习率快速拟合，后50轮衰减精修边缘。

5.2 训练过程的loss曲线里看到了什么

第一次训练时，loss曲线下降速度看起来正常，但验证集mIoU一直卡在0.7上下上不去。这是一个典型的“看起来还行、实际有隐患”的信号。我去翻了几批验证样本的预测输出，发现模型在标注质量较高的图片上表现优秀，但凡遇到反光强、遮挡多的图就开始乱猜。

进一步排查，发现问题根源是增强策略里把随机遮挡加得太猛，导致模型在训练时太依赖“部分可见”的周边信息，在真正完整目标出现时反而犹豫。调低随机遮挡比例后，验证mIoU提升了约4个百分点，曲线平滑度也好了。这类调试经历说明一个事实：那张漂亮的训练曲线只是必要条件，真正需要盯的是验证集上的坏例，要反复翻预测样本找共性问题，而不是看指标涨了就以为完工。

另外一个值得关注的信号是两类别的分IoU差距。刚开始漂浮物类别的IoU明显低于背景类，这是类别不平衡的正常体现，但差距如果持续扩大，就要怀疑是不是标注一致性问题。比如我在第一轮训练时发现漂浮物IoU在验证集某些图片上极低，抽检后发现这些图的漂浮物被标注员标成了背景——因为部分枯枝颜色太暗，肉眼难以和湿暗的岸壁区分。重新审核修正了这批样本后，指标立刻回归正常。

5.3 实测效果与“907张够不够”的真实答案

在测试集上的最终结果：漂浮物类别的mIoU约0.83，背景类别mIoU约0.92，两者综合mIoU约0.89。这个数字放到学术数据集上不算出彩，但放到真实河道口的复杂场景里，已经是一套可用的检测能力。

把模型部署到一段从未参与训练的监控视频流上，连续回放模拟现场画面，主观感受是：大块成片的漂浮物带基本稳定检出；小块碎片偶尔漏检，尤其当碎片和波纹高光重叠时；阴天和雨后的画面检测稳定性优于晴天的强反光时段；傍晚低照度情况下效果退化明显。对于需要量化漂浮物覆盖面积的业务来说，这套精度已经能满足日常巡检需求——面积估算的误差主要来自边缘分割的不完全精确，而非漏检或误检。

所以回到“907张够不够”这个问题：如果数据和场景高度一致、标注严格规范、增强策略合理，够用。但够用是有上限的，如果想进一步把边界精细度和低照度场景的鲁棒性做上去，补充高难度时段样本是绕不开的路。

6. 部署到真实河道口之前必须处理的三个工程问题

6.1 视频流抽帧与模型推理频率的不匹配

模型训练完了，不等于工程落地。现实场景里输入往往是监控视频流，每秒钟25帧，但模型推理速度可能只有每秒5-10帧，直接把所有帧都送去推理是不现实的。这里的工程策略是抽帧+连续帧结果融合。

河道漂浮物移动速度不快，水流平稳时十几秒内形态变化很小，所以2-3秒抽一帧推理一次完全够用。但到了汛期流速快，漂浮物移动速度快，抽帧间隔要缩到1秒左右。另外，单帧检测结果不能直接作为最终结论——需要一个时间窗口内的投票机制，比如连续5帧里至少3帧检出才算确认目标，避免单帧误检触发告警。部署前记得根据实际水流速度调节抽帧间隔，不要用一个参数套全年。

6.2 类别不均衡带来的误检如何用后处理压制

模型在训练时有像素加权，但部署后仍会有一定误检，最常见的误检类型是把靠近岸边的强反光区域预测成漂浮物。为了工程可用，我在推理链路里加了两道后处理：第一道是置信度阈值分离，漂浮物类别的置信度阈值调高到0.72，背景类别维持较低阈值，压掉低置信的零散误检；第二道是基于连通域的尺寸过滤，像素面积小于设定阈值（按图像分辨率换算成实际约0.5平方米）的预测区域直接置为背景。

这两道后处理完全是工程经验累积出来的，理论上说模型应该自己学会区分弱特征目标，但在样本有限、场景多变的情况下，把后处理规则设计好，实际上比强行增加训练数据更快见效。代价是特定场景下可能漏掉小块漂浮物，但对业务而言，“少误报”比“少漏报”更重要。河道巡检告警的容错偏好，一线人员更受不了误报带来的疲劳。

6.3 用于迭代的数据回流闭环

数据集的交付不是终点，模型上线后的持续迭代才是整个方案能长期有效的关键。我把每两周一线的告警截图和人工复核结果保存下来，重新走一轮标注、审核、增量训练。这个闭环的关键不在于数据量增长多少，而在于新数据里是否包含训练集没覆盖的场景——比如汛期水位上涨后水流带来的特殊漂浮物形态。

在我这个项目里，第一次回流补充的样本数只有120张左右，但就是因为包含了多日连阴雨后水体变浑浊后的状态，模型的低照度鲁棒性提升非常明显。这说明了一个朴素但容易被忽略的事实：干净的数据集框架是起点，持续的数据回流才是把模型养熟最快的方式。

最后一件事想单独提醒：标注规范的版本控制。随着项目推进，标注规则会变，但历史数据的标注版本和规则版本要对得上。最好在数据集目录里单独存一份标注规范说明文档，每次规则调整都更新版本号和变更记录。如果这一点做不到，后面每迭代一版数据集，都可能因为规范不一致引入来自不同“标注时代”的冲突样本，让模型性能原地踏步甚至倒退。