我第一次跟风场那边聊叶片巡检需求时，对方只说了句大实话——“要是能把细裂纹从照片里自己找出来，一个叶片少爬一次人，一年省下来的停机损失够买两台车。”这句话直接锚定了后面几个月我们团队要做的方向：无人机视角下的风力发电机叶片缺陷识别分割。项目不停推进，我越来越确信，真正卡住进度的不是飞控、不是相机选型，而是算法手里有没有一批像样的标注数据。我们最终跑通的链路，用的是一套labelme格式的6153张、7类缺陷的叶片图像数据集，再配合后续的格式转换、数据增强、分割模型训练和工程化推理，才把结果从“能看出来”磨到了“能报给检修班用”。
这篇文章就把这条链路从头到尾拆开讲：无人机拍的叶片图像为什么难处理、7类缺陷长什么样、labelme数据怎么组织与质检、如何转成实际训练能用的格式、Mask R-CNN和YOLOv8-seg两条技术路线的实测对比，以及最终推理结果如何变成风场检修能直接使用的缺陷台账。适合正在做风机巡检算法、打算自己攒缺陷数据集的工程师，也适合刚接触实例分割任务的初学者照着搭一套完整的训练评估流程。
1. 无人机到底拍到了什么：叶片缺陷分割面对的影像现实
1.1 为什么“上天”是叶片检测的唯一合理路径
风力发电机叶片顶端离地面动辄大几十米，轮毂高度更高。传统人工检查流程非常重：要么停机，人绑着安全绳从轮毂爬出去，一段一段目视敲打；要么用高倍望远镜在地面慢慢扫，碰上裂纹反光，肉眼根本分辨不出来。停机一天，发电量损失按台算都是五位数起步。相比之下，无人机巡检把检修人员从高空作业里解放出来，一台机组全叶片飞一遍通常只要几十分钟，图像精度还能做到毫米级裂纹可见，这是效率和安全上的双重碾压。
但无人机视角带来的图像条件远比想象中苛刻。叶片在画面里不是平铺的，而是带弧度的细长结构，不同风机朝向不同，同一叶片不同段的光照方向也不同。无人机从侧前方拍过去，透视畸变明显，叶片根部和尖部在图像里的形态差异很大。再加上风场现场常见的逆光、薄雾、相机运动模糊，这套数据从一开始就和普通的工业质检图像不是一码事。
1.2 七类缺陷的视觉形态与分割难点
这套数据集里固定了7个缺陷类别，都是风电行业巡检中最常见的类型：
| 类别 | 典型视觉形态 | 分割难点 |
|---|---|---|
| crack 裂纹 | 细线状，沿叶片表面扩展，可能分叉或断续 | 目标极细长，低对比度背景下容易断裂 |
| pinhole 针孔 | 点状小坑，直径很小，像被硬物磕碰 | 像素面积过小，极易在下采样时消失 |
| peeling 涂层剥落 | 漆面成片翘起，形状不规则，边缘卷曲 | 边界复杂，卷起的阴影干扰边缘判定 |
| corrosion 腐蚀 | 表面氧化变色，常呈片状斑点 | 与背景纹理、污渍难区分，边界模糊 |
| erosion 前缘侵蚀 | 叶片前缘条带状磨损，表面粗糙 | 条带纵向延伸长，与叶片前缘结构混叠 |
| lightning_strike 雷击损伤 | 点状或带状灼烧痕迹，颜色发黑 | 可能伴随衍生裂纹，容易一标标成两类 |
| contamination 污渍 | 油污、鸟粪、灰尘积聚，形状松散 | 边缘不清晰，与阴影、腐蚀容易误判 |
从分割任务的角度看，这7类本质上覆盖了“点、线、面”三种几何形态。pinhole是点，crack是线，而peeling、corrosion是面。传统目标检测只要给一个矩形框，对crack这类细长目标非常不友好，一个框里90%以上都是正常表面，回归出来的框重叠度几乎没有参考价值。这也是为什么项目最终必须走分割路线：只有像素级轮廓才能告诉你裂纹有多长、剥落面积占叶片面积的多少，检修班才能据此排优先级。
1.3 一个拦路虎：大尺寸叶片图像里的微型缺陷
无人机挂载的相机拍出来常见是3840×2160甚至更高分辨率。整张图里叶片占据主体，但一条早期裂纹在图像里可能只有几十个像素宽、几百个像素长，pinhole更是可能只有十几个像素。什么概念呢？相当于在一张A4纸上找一根断了的头发丝。
这个尺度矛盾决定了后续所有技术选型。直接整图缩放到640×640喂给训练框架，裂纹大概率缩到1个像素以内，等于直接消失；直接整图训练，显卡显存又根本塞不下原图。最终可行的方案是两条路：要么在训练阶段使用大输入尺寸并配合随机裁剪，要么在推理阶段做滑窗切块。后面第4章、第5章都会围绕这个冲突展开，这里先记住一个结论：叶片缺陷分割项目里，分辨率策略的重要性不亚于模型结构本身。
2. 6153张labelme格式数据集的内部拆解
2.1 labelme文件里到底存了什么
labelme是图像标注工具里非常常见的一种选择，它对多边形标注的支持很直接，底层就是JSON文件，每张图对应一个同名JSON。这套6153张的数据集，文件组织形态是每个图像文件旁边放一个同名JSON，比如W001_T03_A02_0812.jpg旁边就有W001_T03_A02_0812.json。
一个典型的标注文件大致长这样：
{ "version": "5.5.0", "flags": {}, "shapes": [ { "label": "crack", "points": [ [486, 921], [529, 928], [571, 941], [612, 957] ], "group_id": null, "shape_type": "polygon", "flags": {} } ], "imagePath": "W001_T03_A02_0812.jpg", "imageData": null, "imageHeight": 2160, "imageWidth": 4096 }重点字段就四个。shapes里装的是所有标注目标，每个目标的label是类别名，points是多边形顶点坐标，shape_type固定为polygon，坐标单位是原始图像的像素。imagePath记录对应图片文件名，imageWidth和imageHeight记录图像尺寸，imageData一般存空，如果存了就表示base64编码的原图数据，会让JSON文件体积膨胀好几倍。6153个JSON文件，每个文件里少则0个shape（正常叶片负样本），多则十来个shape，整份数据一共积累了近万个缺陷多边形实例。
2.2 七类缺陷的样本分布与不平衡问题
任何真实采集的数据集都不可能各类别均匀。我们这份数据按标注实例数统计，分布大致如下：
| 类别 | 标注实例占比 | 说明 |
|---|---|---|
| crack | 28% | 数量最多，形态也最多样 |
| peeling | 18% | 高发但误标率也高 |
| corrosion | 14% | 沿海风场样本较多 |
| pinhole | 12% | 目标小，采集时容易漏 |
| erosion | 12% | 主要集中在前缘区域 |
| contamination | 10% | 受季节和鸟类活动影响 |
| lightning_strike | 6% | 低频但不处理后果严重 |
另外还有约15%左右的图像是完全没有缺陷的正常叶片，这些负样本在JSON里表现为空shapes，它们在模型训练里承担抑制误检的作用，非常关键。真实项目里，缺陷多发生在特定部位，例如erosion几乎都压在叶片前缘，lightning_strike常集中在叶尖附近，corrosion则和风场离海远近强相关。类别不平衡是后面训练阶段必须正面处理的问题，不能指望模型自己一碗水端平。
2.3 标注边界判定与质检流程
分割模型的精度上限由标注质量决定，这句话在叶片缺陷上体现得尤其明显。crack只有几个像素宽，标注员手一抖，多边形就偏离真实裂纹中心线好几个像素，训练出来的mask边界自然好不了。项目里我们定了一套标注约定和质检流程。
边界判定规则上，crack按裂纹可见宽度勾边，如果一条裂纹在图像里被遮挡或断开，则拆成多个多边形，不强行连成一条；pinhole按凹陷的实际轮廓勾边，如果目标实在太小，宁可勾成一个尽量小的多边形也不能拿大框凑合；peeling只看漆层翘起区域，阴影不算；corrosion只看颜色异常和表面变化区域；erosion划到前缘粗糙带为止，不过度向叶片中部延伸；lightning_strike的灼烧区域单独标，如果旁边有衍生裂纹，裂纹单独归为crack。
质检环节我们做了两轮。第一轮是双人盲标抽查，随机抽20%的图像让两个人分别独立标注，计算两套标注之间的mask IoU，低于0.8就判不合格返工。第二轮是全量复核，由标注组长对6153张全部过一遍，重点看crack和pinhole的边界是否贴合、有没有把非缺陷纹理标成缺陷。这一套质检流程走完，标注文件里每个多边形的可信度才真正到了可以喂给模型的程度。
3. 从labelme到训练管线：格式转换、数据划分与增强
3.1 格式转换：转COCO、转YOLO的关键逻辑
labelme的JSON格式平台无关性很好，但主流检测分割框架不直接用这套格式。实际训练时要么转成COCO JSON，要么转成YOLO系列的txt格式。转换的核心逻辑并不复杂，难在坐标处理上容易出错。
labelme转COCO时，每个shape就是一条annotation。COCO的segmentation字段要求把所有多边形顶点按x1,y1,x2,y2这样展平成一维列表，而不是保留原来的点对数组，而且顶点坐标必须是浮点数。bbox字段则是多边形外接矩形[x_min, y_min, width, height]。写一个比较稳的伪代码逻辑是：
for json_file in sorted(glob("labels/*.json")): data = json.load(open(json_file)) image_info = { "id": img_id, "file_name": data["imagePath"], "width": data["imageWidth"], "height": data["imageHeight"] } for shape in data["shapes"]: points = shape["points"] flat_seg = list(itertools.chain(*points)) x_min = min(p[0] for p in points) y_min = min(p[1] for p in points) x_max = max(p[0] for p in points) y_max = max(p[1] for p in points) annotation = { "id": ann_id, "image_id": img_id, "category_id": category_map[shape["label"]], "segmentation": [flat_seg], "bbox": [x_min, y_min, x_max - x_min, y_max - y_min], "area": polygon_area(points), "iscrowd": 0 }转YOLO seg格式就更直接，每个JSON生成一个同名txt，一行对应一个多边形，格式是class_id x1 y1 x2 y2 ...，所有坐标要除以图像宽高归一化到0到1之间。这里最容易出错的是坐标顺序，labelme里是列在前行在后，也就是[x, y]，归一化时要记得除以各自的宽和高，不能搞混。另外COCO和YOLO的类别id映射表必须单独存一份固定下来，后续模型输出解析、结果可视化都依赖这张表。
3.2 按拍摄架次划分数据集，别让验证集变“开卷考试”
数据划分是这类项目里最容易被低估的一环。如果直接把6153张图打乱按比例切训练集、验证集、测试集，模型指标看起来会很漂亮，但落地时立刻现原形。原因在于无人机巡检是按架次飞的，一个架次会连续拍摄某个叶片的几十帧，相邻帧之间视角高度重叠，同一个裂纹可能出现在连续五六张图里。要是同架次的图像同时进了训练集和测试集，模型相当于提前看过“考题”，测试结果自然虚高。
正确做法是以最小采集单元来划分。我们这套数据来自60多个巡查架次，划分时按架次随机分，保证同一个架次的所有帧全部落在同一个集合里，最终训练集、验证集、测试集的比例控制在大约8:1:1，也就是约4922张、615张和616张。这样划分后的指标才能真正反映模型在没见过的新叶片上的表现。我们一开始图省事做过普通随机划分，验证集mAP比按架次划分能高出8到10个点，但现场一测就崩，多花了整整一周排查才意识到是划分方式导致的数据泄露。
3.3 针对叶片缺陷的数据增强组合
数据增强策略不能无脑套用通用目标检测的配置。叶片图像有很强的物理语义，比如叶片在空间中的朝向、裂纹的几何特征，乱增强反而破坏标签。我们最终沿用下来的增强组合包括：
- 轻微随机旋转，范围控制在±15度，超过这个范围会改变叶片拓扑形态，训练出的模型对真实拍摄角度没有对应收益。
- 水平翻转可用，但垂直翻转不做。叶片图像里上下方向对应真实物理位置，垂直翻转会让模型学到错误的几何先验。
- 亮度、对比度、色调的随机扰动，用来模拟一天中不同时段和不同天气下的拍摄效果，对corrosion、contamination这类颜色相关类别尤其有效。
- Mosaic增强，把多张图拼在一起放大batch内样本多样性，但对细长crack来说要注意裁块之后别把裂纹切得太碎，所以训练后期我们会关掉Mosaic。
- 更关键的操作是先做随机裁剪，再把裁剪块resize到训练尺寸。比如原图是4096宽，先随机取1024×1024区域，再缩放成训练输入尺寸，相当于在保留细节的同时让模型看到叶片局部纹理。直接整图缩放的方案对crack这种线状缺陷伤害太大，实测中裁剪策略能把crack类别的mask IoU明显拉高。
4. 分割模型的实测对比与踩坑记录
4.1 选型逻辑：Mask R-CNN与YOLOv8-seg
方案选型阶段我们对比过三条路线：Mask R-CNN、YOLOv8-seg、以及语义分割的DeepLab系列。DeepLab这类纯语义分割模型输出的是像素类别图，但在风场巡检场景里，叶片上有多个缺陷实例时，运维需要知道“哪一个裂纹在哪、面积多大”，语义分割分不清实例，台账登记很麻烦，第一轮就被淘汰了。
真正进入实测的是Mask R-CNN和YOLOv8-seg。Mask R-CNN是两阶段方法的代表作，先靠RPN提候选框，再对每个候选框做ROIAlign和mask头预测，精度上限高，对细长小目标更有优势；代价是模型重、推理慢、显存占用高。YOLOv8-seg是单阶段anchor-free方案，分割头和检测头并行出结果，训练和推理都快得多，部署到边缘设备也更现实，但对极小目标的细节还原能力略弱。两条路线不冲突，我们最后是线上轻量初筛用YOLO，离线高精度复核用Mask R-CNN。
4.2 关键训练参数与Loss观察
训练参数如果照搬通用目标检测经验，大概率翻车。我们调过一轮后相对稳定的一组配置如下：
| 方案 | 输入尺寸 | batch size | 优化器 | 初始学习率 | 训练轮数 |
|---|---|---|---|---|---|
| YOLOv8x-seg | 1280×1280 | 8 | AdamW | 0.001 | 200 |
| Mask R-CNN (R101-FPN) | 1333×800 | 2 | SGD | 0.005 | 80 |
所谓“Loss观察”不是看个总数就完事，要拆开看分量。Mask R-CNN的loss由RPN分类、RPN回归、目标分类、目标回归、mask分割五部分组成。实际经验是mask loss下降通常最慢，前10个epoch总loss在降而mask loss几乎不动是正常现象，不用慌；但如果40个epoch后mask loss平台期纹丝不动，就要回头查标注了，大概率是多边形边界和真实缺陷边界明显不贴合。YOLOv8-seg这边重点看box loss和mask loss两条曲线是否同步下降，我们遇到过mask loss降到一定程度不再变化，最后定位到问题是标注边界外扩严重，模型已经学不到更精细的边界特征。
4.3 实测指标对比
在按架次划分的数据集上跑完一轮，两组模型的代表性结果如下：
| 方案 | mAP@0.5 | mAP@0.5:0.95 | 单图推理耗时（4090） | 显存占用 |
|---|---|---|---|---|
| YOLOv8x-seg（1280） | 0.681 | 0.412 | 约0.12秒 | 约12GB |
| Mask R-CNN（R101-FPN） | 0.705 | 0.438 | 约0.45秒 | 约24GB |
需要说明的是，这组数字是我们在自己数据和参数配置下的单次结果，换个数据集、换个拍摄条件都会明显浮动，不能当作绝对标准。但趋势在各次实验里是稳定的：Mask R-CNN在mAP上小幅领先，优势主要来自crack和pinhole这两个细长与极小目标，而YOLOv8-seg在推理速度上领先数倍。如果算上工程部署成本、显存需求和标注容错率，YOLO路线的综合性价比反而更高——它对稍微粗糙一点的标注边界容忍度更好，训练失败的次数也少。
4.4 训练中踩过的三个坑
第一个坑是细长裂纹在缩图过程中消失。最初我们用YOLO默认的640输入训练，crack类别怎么调都在低mAP徘徊。排查时把验证集里漏检的原图拿出来，发现裂纹在经过resize后只剩一两个像素，人眼都难分辨。解法就是前面说的：输入提到1280，配随机裁剪。
第二个坑是类别不平衡。pinhole和lightning_strike实例少，模型倾向于把它们漏检。试过把这两类的loss权重加大、也试过在每个epoch里对稀有类别做概率过采样。最后实际有效的是两者结合：先过采样让模型每个epoch都能稳定看到稀有类别样本，再给稀有类别的分割loss加权重。效果最明显的是lightning_strike，mAP从0.31涨到0.57。
第三个坑最隐蔽，就是第3章提到的数据划分泄露。最初随机划分时测试集mAP高达0.78，工程化验证却一塌糊涂。后来逐张对比才意识到同架次的连续帧在训练测试两边“串场”了，模型见过的裂纹视角和新拍的裂纹视角太像，现场一遇新风机就失灵。改成按架次分组划分之后，测试指标虽然降了十几个点，但现场表现反而更稳定，这才是真正可用的模型。
5. 从推理结果到检修清单：工程化落地的细节
5.1 大图推理：切块预测与跨块冗余合并
模型训出来只是第一步，无人机采集的原始图像是4K级的，直接把整张缩图丢给推理管线又会重蹈训练阶段的覆辙，细小缺陷照样丢。工程推理我们采用滑窗切块策略：把原图切成1024×1024的patch，相邻patch之间保留128像素的重叠区，这样缺陷只要不是正好骑在切割线上，就不会被截断。
每块patch单独过模型，得到结果后把多边形坐标加回patch的偏移量，还原到原图坐标系。跨patch的冗余检测靠mask IoU合并，当两个patch检测出的多边形在重叠区域有较高IoU时，就合并成一个缺陷实例，保留置信度高或面积大的那条结果。这个流程处理6153张规模的测试集，单机单卡几小时就能跑完。如果后续还想加快，可以先跑一个轻量检测模型把叶片区域找出来，只对叶片区域做高分辨率切块推理，让模型注意力集中在叶片上，也能明显降低背景误检。
5.2 从像素分割到缺陷台账
模型输出的多边形对检修班来说不够直接，他们需要的是“几号风机、哪个叶片、什么缺陷、多严重”。像素坐标要换算成真实物理尺寸才能判断严重程度。常用办法是利用已知量做尺度标定：叶片全长已知，图像里叶片根部到尖部的像素距离也测得出，用两者比例换算每个缺陷的实际尺寸。比如某条crack模型量出来245个像素，而叶片平均每像素对应3毫米，那这条裂纹大约是73.5厘米长，放到台账里就算中重度缺陷了。
台账字段包括叶片编号、缺陷类别、多边形坐标序列、实际长度或面积、置信度、所在部位（叶根、叶中、叶尖）。输出格式可以定为JSON或GeoJSON，方便接入风场现有的巡检系统。这样处理完一次全风机巡检，出表就是一张可直接派单的检修清单。
5.3 人工复核闭环与数据回流
自动化分割再准，也无法让检修班完全信任，最终闭环必须包含人工复核。我们做了一套简单的复核界面：把模型输出直接叠加到原图上，显示缺陷轮廓和置信度，技术员在界面上确认、删除或手动修改轮廓，最终确认结果写入复核库。
这套机制最大的价值不只是当下派单准确，而是数据回流形成迭代闭环。一个季度跑完一轮现场巡检，复核库能积累一批新场景下水印、反光、结构遮挡的难例。把这些难例和复核后的修正标注重新灌回训练集做增量训练，第二轮模型的误检率能明显下降。我们迭代两轮之后，crack类别的误检率大约降了一半，靠的就是这个循环。
6. 如果你想自己攒一套叶片缺陷数据，我的几条实在建议
6.1 拍摄规范决定数据下限
模型能学到什么，首先取决于你拍回来什么。无人机贴近叶片拍摄时，正对表面、减少透视畸变是基本前提，距离保持在能看到毫米级裂纹的程度，通常10到15米比较合适。同一个缺陷尽量多种光照角度都拍几帧，侧光条件下裂纹对比度最高，顺光逆光都要覆盖。快门速度要拉高一些，无人机悬停不是绝对静止，配上长焦，快门不够就是整片糊。拍摄时还要控制旷野天空占比，构图尽量让叶片占满画面，否则大量算力和标签都被消耗在没有意义的背景上。
6.2 标注规范要写成一页文档
标注员的流动比想象中频繁，如果在位时没有把“什么算裂纹、什么算腐蚀”写下来，换个人就换个标法。一页纸的标注规范，配上每类缺陷的示例图和边界案例图，能省掉后续大量返工。更关键的是每两周做一次标注共识校准，让全员同时对同一批图标一遍，现场比对差异。这比事后抽检效率高得多。
6.3 宁缺毋滥：坏数据比没数据更危险
最后说点实在体会。一张标错边界的图放进训练集，模型就多学了一遍错误边界；一张把背景纹理误标成裂纹的图，模型就会在真实巡检时把这个错误的经验反馈到现场。尤其是分割任务，对像素边界的敏感度极高，标注不干净的样本越多，模型的mask精度越上不去。遇到明显看不清、无法确认的局部区域，宁可整体标为背景，也不要硬猜一个形状出来。我们后期把一批模糊小目标直接降为背景样本，模型整体mAP反而往上走了，这件事给我印象很深。
还有一个极易踩的小坑，顺便提醒一句：labelme标注完的文件如果重命名过，JSON里的imagePath字段不会跟着改，训练脚本读不到图。批量改名后记得同步改JSON字段，或者干脆写个小脚本统一再生成一遍imagePath。这种问题不致命，但排查起来很烦，提前做一次清洗能省几小时工时。
