简介目标检测是计算机视觉领域的基础任务但在遥感卫星影像中检测飞机却面临目标尺度极小、方向任意、密集排列以及背景干扰等特殊挑战。通用检测框架直接迁移到遥感场景时常因输入分辨率与目标尺寸失配而导致严重漏检和误检。理解影像地面分辨率、模型输入尺度和目标像素大小之间的关系是构建高效检测系统的前提。通过合理的滑动窗口切图、精细化标注规范、针对性的数据增强以及旋转框检测等关键技术能够显著提升模型在真实机场环境中的泛化表现。文章以高分辨率卫星图中的飞机检测项目为例系统梳理从公开数据集取舍、自建数据流程、模型选型对比到训练评估与推理部署的完整工程链路为遥感小目标检测与相关视觉工程的落地提供可复用的实践参考。 卫星图里的飞机检测做过的人都知道这不是一个“拿目标检测模型跑一下就行”的简单任务。我最早接这个方向时手头拿到的是一批高分辨率机场遥感影像想着直接套用经典的YOLO系列标注好了飞机目标就去训练结果推理出来全是误检——把油罐车顶、屋顶空调机组、甚至几栋造型奇特的厂房都当成了飞机。后来静下心一步步排查才发现问题出在任务认知上人工智能目标检测数据集飞机卫星图这个主题背后涉及的是一整套从数据采集、标注规范、切图策略、模型选型到评估部署的工程链路任何一个环节拍脑袋最终模型都会用效果“回报”你。这篇内容我打算围绕实际项目开发的顺序来写从数据集的构建思路、预处理细节到模型选型和训练配置再到评估与部署时的那些坑尽量把我在这个方向上踩过的雷和验证过的方法一次说清楚。适合正准备做卫星图小目标检测的学生、刚入行遥感视觉的工程师以及想把自己通用检测经验迁移到遥感场景的朋友参考。1. 卫星图飞机检测难的不是“检测”是任务认知很多人第一次拿到卫星图数据集第一反应是“这不就是目标检测嘛”然后直接下载一个YOLOv8开始标数据、训练。这种思路不能说全错但大概率会在后续某个环节撞墙。我建议先花时间把这类数据的特性拆透再决定后续每一步怎么做。1.1 为什么通用模型在遥感图上表现拉胯卫星图上的飞机检测和常规的COCO、VOC场景有一个本质差异目标尺度与图像幅面的比例极不匹配。一张标准的高分二号或者WorldView级别的卫星图长宽可能达到几千甚至上万像素而画面里的飞机尤其是停靠在停机坪上的小型通航飞机可能只有几十个像素。这个比例关系相当于你在一个篮球场上找一只鸡蛋而且还是俯视视角、颜色和地面很接近的鸡蛋。通用目标检测模型在训练时输入尺寸通常是640x640或者1024x1024直接把这种大图resize进去飞机目标会被压缩到几乎不可见特征图上的响应极弱。这就是为什么很多人在遥感图上直接推理通用模型小目标漏检率特别高。所以“目标检测”三个字听着简单落地到卫星图场景首先要解决的问题是“如何让模型在有限分辨率下看到目标”。1.2 卫星场景还有哪些隐藏难点除了尺度问题卫星图飞机检测还有几座绕不开的大山方向任意飞机在机场停靠时姿态各异有水平停放的有斜向停放的起飞的瞬间更是各种朝向都有。常规目标检测用水平矩形框HBB一个框里可能同时包进两架飞机或者把机头和旁边的登机桥算进同一个目标。密集排列枢纽机场的停机坪区域飞机一架挨着一架彼此间距可能只有几个像素。这个时候NMS后处理稍微激进一点就会把相邻目标合并稍微保守一点又会大量误检。易混目标油罐车、大型客机机身侧面阴影、地面涂装标志、甚至某些白色屋顶在俯视视角下和飞机的视觉特征非常接近。这类误检在测试集上不一定暴露但一上真实机场数据立刻原形毕露。光照与季节差异不同时相的影像中太阳高度角不同飞机阴影方向和长度完全不同冬季积雪覆盖地面时背景纹理也发生剧烈变化。如果数据集里没有覆盖足够多的时相模型的泛化能力会非常脆弱。我见过不少学生在项目报告里写“采用了YOLOv5进行飞机检测准确率达到95%”一问细节数据集是自己从网上随便爬的几十张图训练集和测试集还有重叠。这样的项目做完能通过答辩但绝对上不了真实业务。真正可用的模型必须从数据源头就开始较真。1.3 所以这个项目的正确打开方式是什么一句话总结我的经验先定义清楚输出需求和评估场景再倒推数据与模型方案。如果你的业务场景只需要判断某个机场区域“有没有飞机”“大概有多少架”那水平框检测器加合理的切图策略就够用了如果要做停机位管理、飞机型号识别、滑行冲突预警这类精细任务旋转框检测基本是刚需甚至需要更细粒度的关键点检测。这个决策必须在项目启动初期就跟需求方对齐否则做完一轮再推翻重来损失的是两个星期的标注时间和训练周期。我自己的习惯是先画一张简单的决策草图只用文字标注清楚链路即可把输入数据形态、输出形式、评估指标、误检容忍度写清楚再进入数据准备环节。2. 数据集从哪来公开数据集与自建数据集的实战取舍做卫星图飞机检测数据获取无非两条路用公开数据集或者自建数据集。这两条路我都走过各自有很明显的利弊这里把关键信息摊开讲。2.1 公开遥感数据集横向对比遥感目标检测领域经过这些年的发展已经沉淀了一批公开数据集对起步阶段的模型验证和基准测试很有用。数据集图像规模标注方式包含的航空类目标主要用途DIOR约2万张分辨率0.5m~30m水平框HBB飞机、机场、立交桥等20类通用遥感目标检测基准DOTA约2800张像素级标注旋转框OBB飞机、直升机、舰船等15类旋转框检测基准难度较大RSOD约976张水平框HBB飞机、油罐、操场、立交桥4类小数据量快速验证HRSC2016高分辨率舰船影像旋转框OBB舰船为主含少量飞机舰船/港口场景DIOR和DOTA是最常用的两个。我个人的建议是如果只是验证模型结构和训练流程是否通顺先用RSOD或者DIOR的飞机类数据跑通因为数据量小、类别单一迭代速度快如果要做正式实验或者发论文DOTA是绕不开的基准它包含旋转框标注数据复杂度更接近真实遥感场景。不过公开数据集也有一个容易被忽视的问题标注类别和真实业务需求往往对不上。DOTA里的飞机类别是统一标注的不区分客机、战斗机、直升机而实际业务里民航机场和军用机场的目标形态差异极大如果只训练“飞机”一个类部署时面对特定型号就会露出马脚需要自行补充标注。2.2 自建数据集的核心流程如果业务场景有特殊要求或者你想验证真实的机场数据自建数据集是无法回避的。自建流程看着不复杂但每一步都有讲究。第一步确定影像来源和分辨率。卫星影像的来源不外乎商业购买、开源影像如某些公开遥感影像服务、无人机航拍。务必确认影像分辨率与任务检测目标尺寸的匹配关系。一般来说要稳定检测出30x30像素以上的飞机目标影像地面分辨率至少需要在0.5米到1米之间再低的话飞机在影像上就只剩几个像素了检测意义不大。第二步选择标注工具。我目前用得比较多的是X-AnyLabeling和Roboflow的在线标注。X-AnyLabeling支持旋转框标注这对于后续训练OBB模型非常重要Roboflow的界面干净、支持多人协作导出的格式也齐全。但要注意在线工具对超大数据集的上传和加载速度是个瓶颈几千张高分图时推荐本地化处理。第三步制定标注规范。这是自建数据集最容易翻车的地方。我强烈建议在标注前写一份简单的规范文档明确以下几点飞机目标的最小像素尺寸小于多少像素不标、遮挡超过多少比例不标、是否区分具体型号、是否标注滑行中的飞机与停机位的飞机。没有规范的标注数据训练出来的模型会学到很多莫名其妙的“偏好”。第四步数据划分。划分时务必做到“按场景划分”即同一个机场的影像不能同时出现在训练集和验证集中否则模型会靠记忆背景来检测飞机验证集分数虚高真实场景一测就崩。2.3 数据量不够怎么办先做清点再做增强很多团队一开始拿不到大量真实卫星图标注人力也有限。这时候不要急着上数据增强先做一个“数据清点”统计目标总数、每张图的平均目标数、目标尺寸分布统计场景类型覆盖情况大型枢纽机场、支线机场、通用航空机场、停机坪、跑道、机库区统计时相覆盖情况是否有不同季节、不同光照的影像。清点完之后你会发现数据典型的缺陷是“场景单一”或“目标尺寸单一”。这时候数据增强才有明确的方向。比如场景单一就要重点用色彩抖动、光照模拟、阴影方向变化等目标尺寸单一就要用多尺度训练和复制粘贴增强把一个小目标区域复制到图像的多个位置来增加尺度和位置多样性。单纯的上下翻转、旋转90度这类几何增强对于方向任意的飞机目标帮助有限反而可能引入标注框与目标朝向不匹配的标注错误需要谨慎使用。3. 训练前的关键一步切图、格式转换与增强策略数据集整理好之后别急着开训练先过预处理这一关。这一步做得扎实训练能省很多事做得随意后续排查问题会让你怀疑人生。3.1 滑动窗口切图别让模型在“大象里找蚂蚁”由于深度学习模型输入尺寸有限卫星大图必须切分成小块。切图不是简单地用工具裁成几块就行而是要结合模型训练尺寸和目标尺寸来定策略。我常用的切图参数是训练尺寸设定为1024x1024切图窗口大小取1024x1024重叠率overlap设置为128到256像素。重叠的目的是防止目标恰好落在两块切图的边界上导致目标被切断。切成的小图里如果完全不包含飞机目标要么删除要么保留为负样本。我的建议是保留一小部分纯背景块作为负样本能显著降低误检率尤其是降低把屋顶、操场误判为飞机这类问题。重叠切图会带来一个问题一个小图里的目标可能被重复训练多次尤其是位于重叠区域的飞机。这个可以通过随机采样来缓解——每次训练时从候选切图集合中随机抽取而不是固定使用所有切图。如果使用Ultralytics YOLO框架可以直接在训练时打开随机裁剪和缩放增强框架内部会做动态预处理比离线切图更灵活。3.2 标注格式与代码示例从ArcGIS/Roboflow到YOLO切图之后标注文件要跟着图像一起变换坐标。这里最容易出错的是坐标系的换算。比如原始影像上标注了一个旋转框中心坐标为(x, y)宽高为(w, h)旋转角度为theta。切图后相对于新图左上角的坐标会变化同时如果目标被切图边界截断新的宽高和角度也需要重新计算。手动算容易出错我的做法是写一个Python脚本一次性处理这里给出一个简化版本的思路import math def rotate_point(x_center, y_center, w, h, theta): # 计算旋转框的四个角点相对于中心 dx [w/2, w/2, -w/2, -w/2] dy [h/2, -h/2, -h/2, h/2] corners [] theta_rad math.radians(theta) cos_t math.cos(theta_rad) sin_t math.sin(theta_rad) for i in range(4): x x_center dx[i] * cos_t - dy[i] * sin_t y y_center dx[i] * sin_t dy[i] * cos_t corners.append((x, y)) return corners def crop_and_convert(ann, crop_box, img_w, img_h): # ann: 原始标注信息, crop_box: (x1, y1, x2, y2) x1, y1, x2, y2 crop_box new_corners [] for cx, cy in rotate_point(ann[x_center], ann[y_center], ann[w], ann[h], ann[theta]): new_x cx - x1 new_y cy - y1 # 如果角点在裁剪区域外过滤掉 if 0 new_x img_w and 0 new_y img_h: new_corners.append((new_x, new_y)) # 如果剩余角点少于3个认为目标已严重截断丢弃 if len(new_corners) 3: return None # 根据新角点重新计算最小外接旋转框 # 这里省略具体最小外接矩形的实现可用OpenCV的cv2.minAreaRect在转换成YOLO格式时YOLOv8-OBB格式要求的是归一化的坐标序列按顺序排列的四个角点而水平框模型需要的是x_center, y_center, w, h这组归一化参数。不同框架的格式差异很大建议写一个统一的转换模块一次解析多格式输出后续换模型不会手忙脚乱。3.3 增强策略哪些对卫星图飞机检测真正有用数据增强不是越多越好选错了反而会让模型学到错误的特征。我实测下来针对卫星图飞机检测优先级比较高的增强有这几个尺度扰动Scale Jittering随机缩放输入图片让模型对不同大小飞机的敏感度更均衡旋转与90度翻转飞机的方向任意所以任意角度的旋转增强在水平框模型里尽量少用因为旋转后会引入大量背景误标但在旋转框模型里旋转增强是必须的颜色抖动与光照扰动遥感影像不同时相下色调差异很大适当加入亮度、对比度、饱和度的随机扰动能提升跨时相的泛化能力Mosaic增强YOLO系列自带的Mosaic增强把4张图拼接成一张对提升小目标检测效果很明显但要注意不要拼得太狠导致目标严重变形复制粘贴增强Copy-Paste把训练集中的飞机目标抠出来随机粘贴到其他背景图上同时生成对应标注。这种方法对增加小目标数量和位置多样性非常有效唯一需要注意的是粘贴时不能破坏目标原有的朝向和尺度比例。有一个增强是我建议关闭的就是MixUp混合增强。在遥感场景下MixUp会让飞机目标与背景产生强烈的纹理混合模型的检测置信度会变得紊乱训练出来的模型输出概率值不稳定部署时阈值很难调。4. 模型选型水平框、旋转框还是更高阶方案数据处理完进入模型选择阶段。这一步也要从业务需求倒推不能盲目追新。4.1 YOLOv8/v11系列适合快速验证与水平框任务如果你决定用水平框检测Ultralytics的YOLOv8或YOLOv11是目前最省心的选择。它们的生态完善训练脚本简单部署也有对应的导出工具。我早期用YOLOv8在DIOR数据集上做水平框飞机检测在1024输入尺寸下配合足够多的数据mAP50可以做到90%以上但mAP50-95相对较低因为水平框对密集停靠飞机的位置回归不够精确。用YOLO系列训练自己的数据集命令很简洁yolo detect train \ dataaircraft.yaml \ modelyolov8l.pt \ epochs120 \ imgsz1024 \ batch16 \ lr00.01 \ mosaic1.0 \ scale0.5这里的imgsz和batch要根据显卡显存调整如果显存只有12GB左右imgsz1024时batch通常只能设到8到16。lrf最终学习率建议保持默认的0.01配合cosine学习率调度收敛比较平稳。4.2 旋转框OBB方案mmrotate与YOLOv8-OBB如果场景里飞机密集停靠或者需要精确的朝向信息旋转框就是必选项。旋转框检测器的标准工具链是OpenMMLab的mmrotate里面实现了Rotated Faster R-CNN、Oriented R-CNN、Rotated RetinaNet等一系列算法。另一个更轻量的选择是Ultralytics YOLOv8-OBB训练体验几乎和水平框一样流畅。YOLOv8-OBB训练命令yolo obb train \ dataaircraft_obb.yaml \ modelyolov8l-obb.pt \ epochs150 \ imgsz1024 \ batch16需要注意OBB标注格式和水平框完全不同每个目标不是一个矩形框而是四个归一化角点坐标顺序必须一致通常是顺时针或逆时针。任何标注顺序的不一致都会导致训练损失震荡、mAP异常低。my personal experience如果追求极致精度、能接受更长的训练时间mmrotate里的Oriented R-CNN在DOTA这类复杂数据上通常比YOLO-OBB更稳尤其是在目标密集、背景复杂的情况下。而YOLOv8-OBB的优势是部署简单推理速度快适合工程落地。4.3 要不要上更复杂的模型或Transformer方案近几年DINO、DETR类端到端检测器也有遥感方向的应用它们没有NMS后处理理论上可以避免密集目标的NMS误杀问题。但这类模型训练成本高、小目标优化难度大对数据质量的要求也苛刻我在实际项目里用得比较少。对于大多数飞机检测需求YOLO系列配合旋转框已经足够不需要为了“新技术”强行上Transformer。5. 训练、评估与部署实测mAP高不等于能上线模型训练完成后评估和部署阶段的坑比训练阶段还多。这一节把我在这个环节遇到的问题和排查思路整理出来希望你能少走弯路。5.1 指标怎么看才对mAP50、mAP50-95与置信度分布评估时最重要的不是只看一个mAP而是看多组指标的组合mAP50IoU阈值0.5下的平均精度反映模型“大致找到目标”的能力mAP50-95IoU阈值从0.5到0.95的平均精度对目标位置回归精度更敏感置信度分布曲线正样本和负样本在置信度上的分布是否可分。我的经验是如果mAP50很高但mAP50-95很低说明模型虽然能找到目标但框的位置精度差这在密集场景下很致命——多个目标可能会互相干扰NMS直接把相邻目标过滤掉。这时候优先检查标注框是否精细以及是否使用了旋转框方案。部署前一定要统计验证集上“最佳置信度阈值”。许多框架默认的置信度阈值是0.25但在卫星图场景下这个阈值往往偏低会产生大量误检。我习惯在验证集上跑一遍绘制置信度-精确率曲线取精确率和召回率平衡点作为实际部署阈值而不是用默认值。5.2 推理端最容易翻车的三个细节部署时很多人会直接把训练好的模型扔进推理脚本然后发现结果惨不忍睹。我总结了三个高频翻车点推理尺寸与训练尺寸不一致训练时用了1024x1024推理时为了省时间用了640x640目标尺度特征完全错位检测率断崖式下跌。如果推理速度受限必须用相同的预处理流水线重训一个低分辨率模型而不是直接改推理参数。没有对大图做滑动窗口推理把一张5000x5000的大图直接resize到1024x1024飞机目标全部缩成像素点。正确做法是推理时也用滑窗方式依次推理每个1024x1024窗口再将结果映射回原图坐标最后对大图上的重叠检测框做一次全局NMS。后处理NMS参数不匹配旋转框的NMS和水平框的NMS不是一回事。如果你用的是水平框模型NMS的IoU阈值建议设低一点0.3~0.4因为飞机目标距离近阈值高了会合并相邻目标。如果用的是OBB模型需要用支持旋转框的NMS实现不能用普通NMS。5.3 实测案例从验证集到真实机场数据的落差我做一个支线机场飞机检测项目时训练集DOTA验证集mAP50达到93.6%mAP50-95有67.2%实验室里看指标很漂亮但一换到真实机场的高分影像问题立刻暴露机库阴影下的飞机完全没检测出来停机坪上白色小型通用飞机被反复漏检。排查后发现两个原因。第一训练数据里飞机的背景大多是灰色水泥地面而真实机场的停机坪旁边有大片绿色草坪和暗色沥青区域背景分布没覆盖到。解决办法是从真实影像里手动采集了300张草坪和沥青背景块加入训练集作为纯背景负样本额外标注了200架阴影下的飞机。第二模型对低对比度目标响应弱加入“亮度降低”和“雾化模拟”数据增强后漏检情况明显改善。这个案例也印证了前文反复强调的一句话模型的泛化能力取决于数据对真实场景的覆盖程度而不是验证集上的数字好看。做遥感目标检测跑通离线指标只是第一步持续迭代真实测试数据才是工程常态。6. 把项目写成可复现的工程目录规范与迭代记录最后分享一个我在多个项目中养成的习惯把数据集、训练、评估、部署每个环节都做成结构化目录并为每次实验记录完整参数。这个习惯在项目早期看起来费时间但在模型迭代到第三版、第四版时能帮你节省大量“这个模型当时怎么训出来的”的回忆成本。我常用的目录结构大致如下aircraft-detection/ ├── data/ │ ├── raw/ # 原始影像 │ ├── labels/ # 原始标注 │ ├── crops/ # 切图结果 │ ├── train/val/test/ # 划分后的训练数据 │ └── augment/ # 增强后的数据 ├── configs/ │ ├── aircraft.yaml # 数据集配置 │ └── train_params.json # 训练参数记录 ├── scripts/ │ ├── preprocess_crop.py │ ├── convert_format.py │ ├── train_obb.py │ └── infer_sliding.py └── weights/ ├── yolov8l-obb_baseline.pt ├── yolov8l-obb_finetune_realistic.pt └── ...训练参数记录文件看似不起眼却特别重要。我建议至少记录以下信息数据来源与版本、切图尺寸与重叠率、输入分辨率、模型权重与结构、增强配置、学习率与batch size、训练轮数、优化器与调度器、验证集指标、部署阈值。有了这份记录任何模型出了问题都能回溯到具体环节。数据集版本管理也不容忽视。标注人员更新了一版标注、你增加了一批负样本、或者修改了切图策略都建议把数据集的版本号记录下来。国内很多团队用网盘共享数据集文件夹名字经常是“最终版2_final2”时间一长谁也分不清哪个是真实最终版。这个习惯越早养成后续越省心。如果你想在项目报告或者复盘文章里把效果讲清楚建议附上几张典型的检测结果图——包括密集停机位场景、单机大图场景、不同光照条件下的预测结果同时给出每张图的置信度阈值和NMS参数。这样比单纯贴一个mAP数据更有说服力也方便其他人复现和对比。本文还有配套的精品资源点击获取
简介目标检测是计算机视觉领域的基础任务但在遥感卫星影像中检测飞机却面临目标尺度极小、方向任意、密集排列以及背景干扰等特殊挑战。通用检测框架直接迁移到遥感场景时常因输入分辨率与目标尺寸失配而导致严重漏检和误检。理解影像地面分辨率、模型输入尺度和目标像素大小之间的关系是构建高效检测系统的前提。通过合理的滑动窗口切图、精细化标注规范、针对性的数据增强以及旋转框检测等关键技术能够显著提升模型在真实机场环境中的泛化表现。文章以高分辨率卫星图中的飞机检测项目为例系统梳理从公开数据集取舍、自建数据流程、模型选型对比到训练评估与推理部署的完整工程链路为遥感小目标检测与相关视觉工程的落地提供可复用的实践参考。 卫星图里的飞机检测做过的人都知道这不是一个“拿目标检测模型跑一下就行”的简单任务。我最早接这个方向时手头拿到的是一批高分辨率机场遥感影像想着直接套用经典的YOLO系列标注好了飞机目标就去训练结果推理出来全是误检——把油罐车顶、屋顶空调机组、甚至几栋造型奇特的厂房都当成了飞机。后来静下心一步步排查才发现问题出在任务认知上人工智能目标检测数据集飞机卫星图这个主题背后涉及的是一整套从数据采集、标注规范、切图策略、模型选型到评估部署的工程链路任何一个环节拍脑袋最终模型都会用效果“回报”你。这篇内容我打算围绕实际项目开发的顺序来写从数据集的构建思路、预处理细节到模型选型和训练配置再到评估与部署时的那些坑尽量把我在这个方向上踩过的雷和验证过的方法一次说清楚。适合正准备做卫星图小目标检测的学生、刚入行遥感视觉的工程师以及想把自己通用检测经验迁移到遥感场景的朋友参考。1. 卫星图飞机检测难的不是“检测”是任务认知很多人第一次拿到卫星图数据集第一反应是“这不就是目标检测嘛”然后直接下载一个YOLOv8开始标数据、训练。这种思路不能说全错但大概率会在后续某个环节撞墙。我建议先花时间把这类数据的特性拆透再决定后续每一步怎么做。1.1 为什么通用模型在遥感图上表现拉胯卫星图上的飞机检测和常规的COCO、VOC场景有一个本质差异目标尺度与图像幅面的比例极不匹配。一张标准的高分二号或者WorldView级别的卫星图长宽可能达到几千甚至上万像素而画面里的飞机尤其是停靠在停机坪上的小型通航飞机可能只有几十个像素。这个比例关系相当于你在一个篮球场上找一只鸡蛋而且还是俯视视角、颜色和地面很接近的鸡蛋。通用目标检测模型在训练时输入尺寸通常是640x640或者1024x1024直接把这种大图resize进去飞机目标会被压缩到几乎不可见特征图上的响应极弱。这就是为什么很多人在遥感图上直接推理通用模型小目标漏检率特别高。所以“目标检测”三个字听着简单落地到卫星图场景首先要解决的问题是“如何让模型在有限分辨率下看到目标”。1.2 卫星场景还有哪些隐藏难点除了尺度问题卫星图飞机检测还有几座绕不开的大山方向任意飞机在机场停靠时姿态各异有水平停放的有斜向停放的起飞的瞬间更是各种朝向都有。常规目标检测用水平矩形框HBB一个框里可能同时包进两架飞机或者把机头和旁边的登机桥算进同一个目标。密集排列枢纽机场的停机坪区域飞机一架挨着一架彼此间距可能只有几个像素。这个时候NMS后处理稍微激进一点就会把相邻目标合并稍微保守一点又会大量误检。易混目标油罐车、大型客机机身侧面阴影、地面涂装标志、甚至某些白色屋顶在俯视视角下和飞机的视觉特征非常接近。这类误检在测试集上不一定暴露但一上真实机场数据立刻原形毕露。光照与季节差异不同时相的影像中太阳高度角不同飞机阴影方向和长度完全不同冬季积雪覆盖地面时背景纹理也发生剧烈变化。如果数据集里没有覆盖足够多的时相模型的泛化能力会非常脆弱。我见过不少学生在项目报告里写“采用了YOLOv5进行飞机检测准确率达到95%”一问细节数据集是自己从网上随便爬的几十张图训练集和测试集还有重叠。这样的项目做完能通过答辩但绝对上不了真实业务。真正可用的模型必须从数据源头就开始较真。1.3 所以这个项目的正确打开方式是什么一句话总结我的经验先定义清楚输出需求和评估场景再倒推数据与模型方案。如果你的业务场景只需要判断某个机场区域“有没有飞机”“大概有多少架”那水平框检测器加合理的切图策略就够用了如果要做停机位管理、飞机型号识别、滑行冲突预警这类精细任务旋转框检测基本是刚需甚至需要更细粒度的关键点检测。这个决策必须在项目启动初期就跟需求方对齐否则做完一轮再推翻重来损失的是两个星期的标注时间和训练周期。我自己的习惯是先画一张简单的决策草图只用文字标注清楚链路即可把输入数据形态、输出形式、评估指标、误检容忍度写清楚再进入数据准备环节。2. 数据集从哪来公开数据集与自建数据集的实战取舍做卫星图飞机检测数据获取无非两条路用公开数据集或者自建数据集。这两条路我都走过各自有很明显的利弊这里把关键信息摊开讲。2.1 公开遥感数据集横向对比遥感目标检测领域经过这些年的发展已经沉淀了一批公开数据集对起步阶段的模型验证和基准测试很有用。数据集图像规模标注方式包含的航空类目标主要用途DIOR约2万张分辨率0.5m~30m水平框HBB飞机、机场、立交桥等20类通用遥感目标检测基准DOTA约2800张像素级标注旋转框OBB飞机、直升机、舰船等15类旋转框检测基准难度较大RSOD约976张水平框HBB飞机、油罐、操场、立交桥4类小数据量快速验证HRSC2016高分辨率舰船影像旋转框OBB舰船为主含少量飞机舰船/港口场景DIOR和DOTA是最常用的两个。我个人的建议是如果只是验证模型结构和训练流程是否通顺先用RSOD或者DIOR的飞机类数据跑通因为数据量小、类别单一迭代速度快如果要做正式实验或者发论文DOTA是绕不开的基准它包含旋转框标注数据复杂度更接近真实遥感场景。不过公开数据集也有一个容易被忽视的问题标注类别和真实业务需求往往对不上。DOTA里的飞机类别是统一标注的不区分客机、战斗机、直升机而实际业务里民航机场和军用机场的目标形态差异极大如果只训练“飞机”一个类部署时面对特定型号就会露出马脚需要自行补充标注。2.2 自建数据集的核心流程如果业务场景有特殊要求或者你想验证真实的机场数据自建数据集是无法回避的。自建流程看着不复杂但每一步都有讲究。第一步确定影像来源和分辨率。卫星影像的来源不外乎商业购买、开源影像如某些公开遥感影像服务、无人机航拍。务必确认影像分辨率与任务检测目标尺寸的匹配关系。一般来说要稳定检测出30x30像素以上的飞机目标影像地面分辨率至少需要在0.5米到1米之间再低的话飞机在影像上就只剩几个像素了检测意义不大。第二步选择标注工具。我目前用得比较多的是X-AnyLabeling和Roboflow的在线标注。X-AnyLabeling支持旋转框标注这对于后续训练OBB模型非常重要Roboflow的界面干净、支持多人协作导出的格式也齐全。但要注意在线工具对超大数据集的上传和加载速度是个瓶颈几千张高分图时推荐本地化处理。第三步制定标注规范。这是自建数据集最容易翻车的地方。我强烈建议在标注前写一份简单的规范文档明确以下几点飞机目标的最小像素尺寸小于多少像素不标、遮挡超过多少比例不标、是否区分具体型号、是否标注滑行中的飞机与停机位的飞机。没有规范的标注数据训练出来的模型会学到很多莫名其妙的“偏好”。第四步数据划分。划分时务必做到“按场景划分”即同一个机场的影像不能同时出现在训练集和验证集中否则模型会靠记忆背景来检测飞机验证集分数虚高真实场景一测就崩。2.3 数据量不够怎么办先做清点再做增强很多团队一开始拿不到大量真实卫星图标注人力也有限。这时候不要急着上数据增强先做一个“数据清点”统计目标总数、每张图的平均目标数、目标尺寸分布统计场景类型覆盖情况大型枢纽机场、支线机场、通用航空机场、停机坪、跑道、机库区统计时相覆盖情况是否有不同季节、不同光照的影像。清点完之后你会发现数据典型的缺陷是“场景单一”或“目标尺寸单一”。这时候数据增强才有明确的方向。比如场景单一就要重点用色彩抖动、光照模拟、阴影方向变化等目标尺寸单一就要用多尺度训练和复制粘贴增强把一个小目标区域复制到图像的多个位置来增加尺度和位置多样性。单纯的上下翻转、旋转90度这类几何增强对于方向任意的飞机目标帮助有限反而可能引入标注框与目标朝向不匹配的标注错误需要谨慎使用。3. 训练前的关键一步切图、格式转换与增强策略数据集整理好之后别急着开训练先过预处理这一关。这一步做得扎实训练能省很多事做得随意后续排查问题会让你怀疑人生。3.1 滑动窗口切图别让模型在“大象里找蚂蚁”由于深度学习模型输入尺寸有限卫星大图必须切分成小块。切图不是简单地用工具裁成几块就行而是要结合模型训练尺寸和目标尺寸来定策略。我常用的切图参数是训练尺寸设定为1024x1024切图窗口大小取1024x1024重叠率overlap设置为128到256像素。重叠的目的是防止目标恰好落在两块切图的边界上导致目标被切断。切成的小图里如果完全不包含飞机目标要么删除要么保留为负样本。我的建议是保留一小部分纯背景块作为负样本能显著降低误检率尤其是降低把屋顶、操场误判为飞机这类问题。重叠切图会带来一个问题一个小图里的目标可能被重复训练多次尤其是位于重叠区域的飞机。这个可以通过随机采样来缓解——每次训练时从候选切图集合中随机抽取而不是固定使用所有切图。如果使用Ultralytics YOLO框架可以直接在训练时打开随机裁剪和缩放增强框架内部会做动态预处理比离线切图更灵活。3.2 标注格式与代码示例从ArcGIS/Roboflow到YOLO切图之后标注文件要跟着图像一起变换坐标。这里最容易出错的是坐标系的换算。比如原始影像上标注了一个旋转框中心坐标为(x, y)宽高为(w, h)旋转角度为theta。切图后相对于新图左上角的坐标会变化同时如果目标被切图边界截断新的宽高和角度也需要重新计算。手动算容易出错我的做法是写一个Python脚本一次性处理这里给出一个简化版本的思路import math def rotate_point(x_center, y_center, w, h, theta): # 计算旋转框的四个角点相对于中心 dx [w/2, w/2, -w/2, -w/2] dy [h/2, -h/2, -h/2, h/2] corners [] theta_rad math.radians(theta) cos_t math.cos(theta_rad) sin_t math.sin(theta_rad) for i in range(4): x x_center dx[i] * cos_t - dy[i] * sin_t y y_center dx[i] * sin_t dy[i] * cos_t corners.append((x, y)) return corners def crop_and_convert(ann, crop_box, img_w, img_h): # ann: 原始标注信息, crop_box: (x1, y1, x2, y2) x1, y1, x2, y2 crop_box new_corners [] for cx, cy in rotate_point(ann[x_center], ann[y_center], ann[w], ann[h], ann[theta]): new_x cx - x1 new_y cy - y1 # 如果角点在裁剪区域外过滤掉 if 0 new_x img_w and 0 new_y img_h: new_corners.append((new_x, new_y)) # 如果剩余角点少于3个认为目标已严重截断丢弃 if len(new_corners) 3: return None # 根据新角点重新计算最小外接旋转框 # 这里省略具体最小外接矩形的实现可用OpenCV的cv2.minAreaRect在转换成YOLO格式时YOLOv8-OBB格式要求的是归一化的坐标序列按顺序排列的四个角点而水平框模型需要的是x_center, y_center, w, h这组归一化参数。不同框架的格式差异很大建议写一个统一的转换模块一次解析多格式输出后续换模型不会手忙脚乱。3.3 增强策略哪些对卫星图飞机检测真正有用数据增强不是越多越好选错了反而会让模型学到错误的特征。我实测下来针对卫星图飞机检测优先级比较高的增强有这几个尺度扰动Scale Jittering随机缩放输入图片让模型对不同大小飞机的敏感度更均衡旋转与90度翻转飞机的方向任意所以任意角度的旋转增强在水平框模型里尽量少用因为旋转后会引入大量背景误标但在旋转框模型里旋转增强是必须的颜色抖动与光照扰动遥感影像不同时相下色调差异很大适当加入亮度、对比度、饱和度的随机扰动能提升跨时相的泛化能力Mosaic增强YOLO系列自带的Mosaic增强把4张图拼接成一张对提升小目标检测效果很明显但要注意不要拼得太狠导致目标严重变形复制粘贴增强Copy-Paste把训练集中的飞机目标抠出来随机粘贴到其他背景图上同时生成对应标注。这种方法对增加小目标数量和位置多样性非常有效唯一需要注意的是粘贴时不能破坏目标原有的朝向和尺度比例。有一个增强是我建议关闭的就是MixUp混合增强。在遥感场景下MixUp会让飞机目标与背景产生强烈的纹理混合模型的检测置信度会变得紊乱训练出来的模型输出概率值不稳定部署时阈值很难调。4. 模型选型水平框、旋转框还是更高阶方案数据处理完进入模型选择阶段。这一步也要从业务需求倒推不能盲目追新。4.1 YOLOv8/v11系列适合快速验证与水平框任务如果你决定用水平框检测Ultralytics的YOLOv8或YOLOv11是目前最省心的选择。它们的生态完善训练脚本简单部署也有对应的导出工具。我早期用YOLOv8在DIOR数据集上做水平框飞机检测在1024输入尺寸下配合足够多的数据mAP50可以做到90%以上但mAP50-95相对较低因为水平框对密集停靠飞机的位置回归不够精确。用YOLO系列训练自己的数据集命令很简洁yolo detect train \ dataaircraft.yaml \ modelyolov8l.pt \ epochs120 \ imgsz1024 \ batch16 \ lr00.01 \ mosaic1.0 \ scale0.5这里的imgsz和batch要根据显卡显存调整如果显存只有12GB左右imgsz1024时batch通常只能设到8到16。lrf最终学习率建议保持默认的0.01配合cosine学习率调度收敛比较平稳。4.2 旋转框OBB方案mmrotate与YOLOv8-OBB如果场景里飞机密集停靠或者需要精确的朝向信息旋转框就是必选项。旋转框检测器的标准工具链是OpenMMLab的mmrotate里面实现了Rotated Faster R-CNN、Oriented R-CNN、Rotated RetinaNet等一系列算法。另一个更轻量的选择是Ultralytics YOLOv8-OBB训练体验几乎和水平框一样流畅。YOLOv8-OBB训练命令yolo obb train \ dataaircraft_obb.yaml \ modelyolov8l-obb.pt \ epochs150 \ imgsz1024 \ batch16需要注意OBB标注格式和水平框完全不同每个目标不是一个矩形框而是四个归一化角点坐标顺序必须一致通常是顺时针或逆时针。任何标注顺序的不一致都会导致训练损失震荡、mAP异常低。my personal experience如果追求极致精度、能接受更长的训练时间mmrotate里的Oriented R-CNN在DOTA这类复杂数据上通常比YOLO-OBB更稳尤其是在目标密集、背景复杂的情况下。而YOLOv8-OBB的优势是部署简单推理速度快适合工程落地。4.3 要不要上更复杂的模型或Transformer方案近几年DINO、DETR类端到端检测器也有遥感方向的应用它们没有NMS后处理理论上可以避免密集目标的NMS误杀问题。但这类模型训练成本高、小目标优化难度大对数据质量的要求也苛刻我在实际项目里用得比较少。对于大多数飞机检测需求YOLO系列配合旋转框已经足够不需要为了“新技术”强行上Transformer。5. 训练、评估与部署实测mAP高不等于能上线模型训练完成后评估和部署阶段的坑比训练阶段还多。这一节把我在这个环节遇到的问题和排查思路整理出来希望你能少走弯路。5.1 指标怎么看才对mAP50、mAP50-95与置信度分布评估时最重要的不是只看一个mAP而是看多组指标的组合mAP50IoU阈值0.5下的平均精度反映模型“大致找到目标”的能力mAP50-95IoU阈值从0.5到0.95的平均精度对目标位置回归精度更敏感置信度分布曲线正样本和负样本在置信度上的分布是否可分。我的经验是如果mAP50很高但mAP50-95很低说明模型虽然能找到目标但框的位置精度差这在密集场景下很致命——多个目标可能会互相干扰NMS直接把相邻目标过滤掉。这时候优先检查标注框是否精细以及是否使用了旋转框方案。部署前一定要统计验证集上“最佳置信度阈值”。许多框架默认的置信度阈值是0.25但在卫星图场景下这个阈值往往偏低会产生大量误检。我习惯在验证集上跑一遍绘制置信度-精确率曲线取精确率和召回率平衡点作为实际部署阈值而不是用默认值。5.2 推理端最容易翻车的三个细节部署时很多人会直接把训练好的模型扔进推理脚本然后发现结果惨不忍睹。我总结了三个高频翻车点推理尺寸与训练尺寸不一致训练时用了1024x1024推理时为了省时间用了640x640目标尺度特征完全错位检测率断崖式下跌。如果推理速度受限必须用相同的预处理流水线重训一个低分辨率模型而不是直接改推理参数。没有对大图做滑动窗口推理把一张5000x5000的大图直接resize到1024x1024飞机目标全部缩成像素点。正确做法是推理时也用滑窗方式依次推理每个1024x1024窗口再将结果映射回原图坐标最后对大图上的重叠检测框做一次全局NMS。后处理NMS参数不匹配旋转框的NMS和水平框的NMS不是一回事。如果你用的是水平框模型NMS的IoU阈值建议设低一点0.3~0.4因为飞机目标距离近阈值高了会合并相邻目标。如果用的是OBB模型需要用支持旋转框的NMS实现不能用普通NMS。5.3 实测案例从验证集到真实机场数据的落差我做一个支线机场飞机检测项目时训练集DOTA验证集mAP50达到93.6%mAP50-95有67.2%实验室里看指标很漂亮但一换到真实机场的高分影像问题立刻暴露机库阴影下的飞机完全没检测出来停机坪上白色小型通用飞机被反复漏检。排查后发现两个原因。第一训练数据里飞机的背景大多是灰色水泥地面而真实机场的停机坪旁边有大片绿色草坪和暗色沥青区域背景分布没覆盖到。解决办法是从真实影像里手动采集了300张草坪和沥青背景块加入训练集作为纯背景负样本额外标注了200架阴影下的飞机。第二模型对低对比度目标响应弱加入“亮度降低”和“雾化模拟”数据增强后漏检情况明显改善。这个案例也印证了前文反复强调的一句话模型的泛化能力取决于数据对真实场景的覆盖程度而不是验证集上的数字好看。做遥感目标检测跑通离线指标只是第一步持续迭代真实测试数据才是工程常态。6. 把项目写成可复现的工程目录规范与迭代记录最后分享一个我在多个项目中养成的习惯把数据集、训练、评估、部署每个环节都做成结构化目录并为每次实验记录完整参数。这个习惯在项目早期看起来费时间但在模型迭代到第三版、第四版时能帮你节省大量“这个模型当时怎么训出来的”的回忆成本。我常用的目录结构大致如下aircraft-detection/ ├── data/ │ ├── raw/ # 原始影像 │ ├── labels/ # 原始标注 │ ├── crops/ # 切图结果 │ ├── train/val/test/ # 划分后的训练数据 │ └── augment/ # 增强后的数据 ├── configs/ │ ├── aircraft.yaml # 数据集配置 │ └── train_params.json # 训练参数记录 ├── scripts/ │ ├── preprocess_crop.py │ ├── convert_format.py │ ├── train_obb.py │ └── infer_sliding.py └── weights/ ├── yolov8l-obb_baseline.pt ├── yolov8l-obb_finetune_realistic.pt └── ...训练参数记录文件看似不起眼却特别重要。我建议至少记录以下信息数据来源与版本、切图尺寸与重叠率、输入分辨率、模型权重与结构、增强配置、学习率与batch size、训练轮数、优化器与调度器、验证集指标、部署阈值。有了这份记录任何模型出了问题都能回溯到具体环节。数据集版本管理也不容忽视。标注人员更新了一版标注、你增加了一批负样本、或者修改了切图策略都建议把数据集的版本号记录下来。国内很多团队用网盘共享数据集文件夹名字经常是“最终版2_final2”时间一长谁也分不清哪个是真实最终版。这个习惯越早养成后续越省心。如果你想在项目报告或者复盘文章里把效果讲清楚建议附上几张典型的检测结果图——包括密集停机位场景、单机大图场景、不同光照条件下的预测结果同时给出每张图的置信度阈值和NMS参数。这样比单纯贴一个mAP数据更有说服力也方便其他人复现和对比。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
