简介基于YOLOv5的遥感图像目标识别项目资源包面向计算机视觉初学者、毕业设计学生和相关研究人员聚焦卫星图像中目标检测的工程落地与代码复现涵盖影像预处理、模型训练与识别评估等完整流程。压缩包共156个文件体量约242.81MB包含Python源码、YAML模型配置、PT权重文件、PNG训练曲线图、Shell脚本与Dockerfile可覆盖环境搭建、模型训练、精度评估和结果导出等常用环节。已有42人学习/下载项目曾作为高分答辩成果通过导师审核代码运行稳定可靠附有说明文档和清晰的目录结构便于按模块阅读和二次开发。适合用于课程设计、毕业设计、科研预研或初期项目展示也能帮助学习者理解YOLOv5的数据组织、训练流程与调参技巧在此基础上扩展至更多遥感目标识别场景。1. 遥感图像目标识别为什么选 YOLOv5从数据形态到模型选型做遥感图像目标识别的人第一次拿到卫星或无人机影像时多半会被两个问题卡住一是图太大动辄几千乘几千像素直接喂给检测网络基本跑不动二是目标太小车辆、船只、油罐在图上可能就十几个像素通用检测模型很容易漏检。YOLOv5 在这一场景里算是“性价比”很高的选择它在保持单阶段检测速度优势的同时通过多尺度预测和自适应锚框机制对中小目标有相对友好的表现。这份资源包我拆过之后确认它是一个完整可复现的工程不是只丢给你一堆训练日志。里面包含了训练过程中生成的 TensorFlow 事件文件说明还有对比实验的记录、Dockerfile容器化部署可以直接用以及完整的项目代码覆盖了从数据准备到训练、验证、部署的全流程。适合三类人做毕业设计需要出成果的学生、接了横向项目需要快速出原型的研究人员、以及想系统了解 YOLOv5 在遥感场景下如何调参的入门开发者。接下来我按实际拆解顺序把这套资源里的关键环节和踩过的坑逐一写清楚。2. 工程结构与时序数据先读懂资源包里有什么再动手改代码2.1 从文件清单反推项目脉络资源包开头列出的文件看着像一堆乱码其实是理解这个项目的最佳切入点。events.out.tfevents.1599910333.C-000015-GPU.31726.0和events.out.tfevents.1599909779.C-000015-GPU.24092.0是 TensorBoard 的训练日志时间戳 1599910333 和 1599909779 相差约 534 秒说明这是两次间隔不到 9 分钟的相邻训练记录。GPU字样表明训练在 GPU 上进行31726和24092是进程 PID。这两个文件的存在本身就是一个信号项目作者在调参迭代时保留了完整的过程记录你可以直接加载 TensorBoard 查看损失曲线和指标变化判断训练是否收敛而不是盲猜。.gitattributes的存在说明项目本身用 Git 管理文件里通常配置了 LFS 规则用于处理大文件。遥感影像和训练权重动辄几个 GB如果没有 LFS仓库很快就会膨胀到无法克隆。你拿到资源后第一件事我建议先看这个文件里面有没有对*.pt、*.pth、*.tfevents文件的跟踪规则确认大文件是否被正确管理。2.2 TensorBoard 日志的读取与训练节奏判断这两个事件文件是训练过程的“黑匣子记录仪”。加载方式很简单tensorboard --logdir./runs/train --port6006然后在浏览器打开http://localhost:6006你会看到box_loss、obj_loss、cls_loss三条曲线以及mAP_0.5、mAP_0.5:0.95两个核心指标。判断训练是否正常的标准很简单前几十个 epoch 损失快速下降之后进入平台期如果 mAP 还在缓步上升说明模型仍在学习如果损失下降但 mAP 停滞多半是正负样本不平衡或者锚框设置出了问题。两万多次迭代后如果还有多个事件文件通常意味着作者在对比不同 batch size 或学习率下的表现。C-000015可能是数据集的某个切块编号也可能是分块训练的策略——在大规模遥感场景下将整景影像切成若干块分别执行训练任务是释放 GPU 显存压力的常见做法。2.3 Dockerfile 的作用环境一致性不要靠嘴说资源包里的 Dockerfile 是容易被忽略但价值很高的部分。遥感图像训练最头疼的事情之一就是环境不一致——本机跑得好好的代码换台机器就报 CUDA 版本错误或依赖冲突。Dockerfile 的存在意味着作者已经帮你把环境固化了。构建命令是docker build -t yolo-remote-sensing .构建完成后你可以用一条命令把训练跑起来完全绕开本机的 Python 环境污染问题docker run --gpus all --shm-size8g \ -v $(pwd)/datasets:/app/datasets \ -v $(pwd)/runs:/app/runs \ yolo-remote-sensing python train.py --data remote.yaml --weights yolov5s.pt--shm-size8g在遥感数据处理中非常关键。DataLoader 的num_workers大于 0 时PyTorch 会通过共享内存传递数据批次默认 64MB 经常不够用导致报错Bus error或者DataLoader worker (pid) is killed by signal: Bus error。日志文件events.out.tfevents...能正常写入说明训练稳定跑通了而你在本地复现时如果遇到这类共享内存问题多半就是没按资源里的容器参数来启动。3. 数据准备与标注格式遥感图像不是直接灌进 YOLOv5 就能用的3.1 超大影像的切图策略遥感影像和自然图像最大的区别在分辨率和目标尺寸。COCO 数据集的图像通常 640×640 到 1280×1280而一张高分卫星影像可能是 5000×5000 甚至更大。直接把整张图缩放到 640×640小目标比如 30×30 像素的车辆缩放后就变成 34 个像素人的肉眼都很难辨认网络更是学不到特征。YOLOv5 官方的推理逻辑会把输入 resize 到设定的imgsz这显然不适用于遥感原图。这个资源里的做法是滑窗切图使用一个固定尺寸的窗口通常是 512×512 或 640×640按一定的重叠率overlap扫过全图把大图切成若干个小块。每个小块独立送入网络最后把检测结果按窗口坐标映射回原图再通过 NMS 去重。切图策略的简化实现如下def sliding_window_crop(image, window_size640, stride512): 滑窗切图返回每个窗口的左上角坐标和裁剪结果 h, w image.shape[:2] crops [] coords [] for y in range(0, h - window_size 1, stride): for x in range(0, w - window_size 1, stride): crop image[y:y window_size, x:x window_size] crops.append(crop) coords.append((x, y)) # 处理边缘残留区域最后一行/列如果不足窗口大小补零或镜像填充 if (h - window_size) % stride ! 0: for x in range(0, w - window_size 1, stride): crop image[h - window_size:h, x:x window_size] crops.append(crop) coords.append((x, h - window_size)) if (w - window_size) % stride ! 0: for y in range(0, h - window_size 1, stride): crop image[y:y window_size, w - window_size:w] crops.append(crop) coords.append((w - window_size, y)) return crops, coords参数设计的核心在于stride与window_size的配合。stride512配合window_size640意味着相邻窗口有 128 像素的重叠区域目标被切到边缘的概率下降代价是推理时间约增加 30%。我的习惯是先统计数据集中目标的尺寸分布如果绝大多数目标都在 2060 像素之间窗口大小可以适当缩小到 512 甚至 416反而有利于小目标检测。3.2 标注格式转换从 GeoJSON 到 YOLO txt遥感图像标注常见的来源有两个LabelMe 导出的 JSON或者 GIS 工具导出的 Shapefile/GeoJSON。YOLOv5 需要的是每张图对应一个同名的 txt 文件每行格式是class_id x_center y_center width height坐标是相对图片宽高的归一化值。如果从 GeoJSON 转换核心工作是坐标系的归一化处理import json import os def geojson_to_yolo(geojson_path, out_path, img_w, img_h): with open(geojson_path, r, encodingutf-8) as f: data json.load(f) lines [] for feature in data[features]: cls_id 0 # 自行映射到类别ID coords feature[geometry][coordinates] # 取外接矩形的四个顶点 xs [pt[0] for pt in coords[0]] ys [pt[1] for pt in coords[0]] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h width (x_max - x_min) / img_w height (y_max - y_min) / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) with open(out_path, w) as f: f.write(\n.join(lines))这里的坑在于 GeoJSON 的坐标顺序是 (经度, 纬度)而图像的像素坐标系是 (x, y) 即 (列, 行)。如果不做坐标翻转目标框会全部错位。另外遥感标注中经常出现一个目标被窗口边界切断的情况需要根据目标中心点决定它属于哪个窗口而不是只看它的任意一个顶点。4. 训练流程与参数调优YOLOv5s 起步按收敛曲线决定是否升级模型4.1 显存与精度的平衡模型尺寸怎么选遥感目标识别场景下计算资源通常是受限的。YOLOv5 官方提供了 n/s/m/l/x 五个尺寸我在这类项目里的选型顺序是先用yolov5s做 baseline跑通全流程确认数据没有标注错误、anchors 设置合理再根据指标决定是否升级到 m 或 l。这个资源包里的做法也比较务实用预训练权重做迁移学习而不是从零训练。遥感图像虽然和 COCO 数据集差异较大——目标视角、光谱特征、背景形态都不同——但底层的纹理、边缘、颜色特征仍然有可迁移性。YOLOv5 官方提供的yolov5s.pt在 COCO 上预训练过用它做初始权重能大幅缩短收敛时间。训练命令是标准写法python train.py \ --epochs 200 \ --batch-size 16 \ --data remote.yaml \ --cfg models/yolov5s.yaml \ --weights yolov5s.pt \ --img 640 \ --device 0参数含义--epochs 200是训练轮数遥感任务因为目标小、样本少通常比自然图像需要更多轮次才能充分收敛--batch-size 16受显存限制如果你的 GPU 是 8GB 显存建议降到 8--img 640是输入分辨率切图后子图以此分辨率送入网络--device 0指定使用第一块 GPU。训练完成后模型保存在runs/train/exp/weights/best.pt。这里有个细节最好同时保留last.pt因为best.pt是基于验证集 mAP 选出来的如果验证集和测试集分布有偏差遥感场景常有这种情况last.pt可能泛化性更好。4.2 超参数调整不盲目套默认值YOLOv5 自带的超参数文件data/hyps/hyp.scratch-low.yaml是针对自然图像调优的直接用在遥感图像上不一定是最优解。遥感图像的典型特点是背景占比高有时超过 90%、目标尺寸小、类别数通常较少310 类。我最常调的两个超参数是hsv_h和fliplr。遥感图像的颜色分布与自然图像差异很大——植被是近红外响应的水体是暗色调的建筑物呈几何矩形排布。fliplr: 0.5是水平翻转概率对大多数场景是安全的因为目标在翻转后语义不变但fliplr: 1.0就不建议尤其是卫星图像中道路走向、阴影方向有物理意义过度的翻转会引入语义混乱。另一个关键超参数是anchor_t控制锚框与真实框宽高比匹配的阈值。遥感目标通常长宽比极端——飞机跑道、桥梁可能是 1:10 甚至更夸张——默认阈值可能把这些目标过滤掉。训练时如果发现很多真实框没有匹配到合适的 anchor可以考虑手动修改模型配置文件models/yolov5s.yaml中的 anchors用 K-Means 在你的数据集上重新聚类python utils/anchors.py --data remote.yaml --img-size 640 --batch-size 8这个脚本会计算你的标注框中长宽比的分布重新生成适配你数据集的 anchors。我在一个车辆检测项目里跑过这个操作mAP 提升了约 3 个百分点代价是训练时间多花 20 分钟左右。4.3 训练过程中的监控指标训练时不要只看损失曲线还要关注验证集上的 mAP 曲线。YOLOv5 训练日志中P精确率、R召回率、mAP_0.5、mAP_0.5:0.95是核心指标。遥感场景下我的经验是mAP_0.5是硬指标决定目标有没有被框住mAP_0.5:0.95是软指标反映框的定位精度。如果你的mAP_0.5不错但是mAP_0.5:0.95偏低说明预测框虽然位置对但不够精细可以通过增大输入分辨率或者使用更高精度的模型如 m 而非 s来改善。训练到第 100 轮时如果box_loss还在明显下降就说明模型还没收敛可以继续训练如果mAP_0.5连续 20 轮没有提升就说明进入了平台期再等下去意义不大优先考虑调整数据或超参数。5. 避坑与排查遥感图像目标识别训练中最常见的五个问题5.1 显存不足OOM 之后被迫反复重启现象训练跑到中途进度条停住命令行报CUDA out of memory或者更隐蔽地报RuntimeError: CUDA error: out of memory。原因遥感切图后的子图虽然被 resize 到 640×640但一批次里如果有大量包含复杂纹理的图像块中间特征图的显存占用差异很大batch size 16 在某些批次可能超额。解决先按资源里的做法把 batch size 降到 8 或 4同时检查是否启用了--cache-images参数这个参数会把全部图片加载到内存释放显存部分压力。还不够的话开启梯度累积把--nbs 64名义 batch size设大让 YOLOv5 自动用--batch-size 8累积梯度模拟 batch size 64 的效果。检查是否确实生效看训练日志里显示的effective batch size是否为预期值。5.2 标注框错位所有预测框都偏离目标一段距离现象训练完成后在验证集上测试检测框整体偏左或偏右交并比很低但目标基本都被框住。原因遥感影像的坐标转换出现了系统偏差。GeoJSON 的经纬度坐标系转投影坐标系时不同分带的偏移量不一样或者标注时用了 UTM 而切图用的原始像素坐标没有同步修正。更常见的是裁剪时坐标没有对齐——图片被切块后标注坐标计算错误。解决打开一张验证图把预测框和标注框都画出来看偏移方向。如果偏移是常量写个脚本统一修正如果偏移不规律检查数据预处理代码里坐标缩放的比例因子是否与图像 resize 保持一致。YOLOv5 的标注坐标是归一化的如果你在切图后对子图做了旋转或翻转增强标注坐标也必须同步变换这类增强的随机性导致错误很难察觉建议先在没增强的干净数据上做一次完整训练确认无误后再打开增强开关。5.3 小目标漏检mAP 低明显目标也没有召回现象车辆、油罐这类目标在验证集上漏检率高精确率还行但召回率很低。原因小目标在原图中占比太小在 640×640 输入下只有 10×10 像素左右同时遥感图像中目标数量多、背景复杂正负样本比例失衡严重。解决检查数据集中小目标的占比如果超过一半目标边长小于 32 像素需要做两件事。第一把输入分辨率从 640 提升到 1280代价是训练时间约为原来的 3 倍显存翻倍第二检查 anchors 中最小尺寸的锚框是否与你的目标匹配如果不匹配则按前面说的重新聚类 anchors。另外可以尝试 SAHISlicing Aided Hyper Inference推理策略用切块推理代替整图推理这一策略在遥感目标检测中通常能稳定提升小目标 mAP不需要改动训练脚本。5.4 训练震荡损失曲线在 20 轮后反复跳跃现象前 20 轮损失正常下降20 轮之后损失不再平滑像锯齿一样上下波动mAP 也一直不稳定。原因学习率过大或 batch size 太小梯度方差大也可能是训练集里存在标注错误——个别错误标注的样本在每轮训练中都会造成较大梯度更新。解决降低初始学习率YOLOv5 的--lr0默认是 0.01对遥感小数据集建议调到 0.001 甚至 0.0005。同时排查是否有标注异常的样本用工具把训练集中每个类别的目标尺寸分布、长宽比分布打印出来找出偏离平均水平的异常值。肉眼检查标注建议用python utils/plots.py这类可视化工具把标注框画出来对比原图重点看那些面积特别大或特别小的框是否正确。5.5 切图后目标被截断预测框在窗口边界处被切断现象推理结果叠加回原图后目标跨窗口的部分出现两个不完整的检测框或者窗口边缘的目标完全没检测到。原因滑窗切图时目标正好位于窗口边缘大部分像素在同一窗口外或者推理时没有启用跨窗口 NMS导致同一个目标被相邻两个窗口重复检测。解决推理时把重叠区域的检测结果合并用跨窗口 NMS 消除重复框。合并时注意把框的坐标从窗口坐标换算回原图坐标后再做 NMS否则不同窗口的框没有可比性。另一个方案是提高重叠率从stride512改成stride320窗口 640虽然推理时间翻倍但边缘目标基本都能完整出现在至少一个窗口内。项目里已包含按此方案实现的推理脚本跑通了目前的 NMS 逻辑再自行调整 stride 即可。6. 从训练日志到部署TensorBoard 分析和 Docker 推理一把梭6.1 TensorBoard 深度体检不只图个好看的曲线训练结束后项目里的两个事件文件就是检验模型训练质量的最佳依据。启动 TensorBoard 之后我会重点关注三张图train/box_loss和val/box_loss的重合程度如果两者后期背离较大说明过拟合可以提前停止或加大数据增强metrics/mAP_0.5:0.95曲线的斜率如果它在末尾斜率仍然为正说明训练轮数不够建议加载last.pt继续训练images/train选项卡里可视化后的检测框能直观发现标注错误或数据不平衡问题。TensorBoard 导出的损失值可以顺手存成 CSVfrom tensorboard.backend.event_processing.event_accumulator import EventAccumulator acc EventAccumulator(runs/train/exp) acc.Reload() tags acc.Tags()[scalars] data [] for tag in [train/box_loss, metrics/mAP_0.5]: for event in acc.Scalars(tag): data.append({tag: tag, step: event.step, value: event.value}) # 转成 DataFrame 后可以绘图或直接对比两次实验的收敛曲线这在做消融实验或比较不同超参数组合时非常有用。我习惯把每次实验的 TensorBoard 日志放在独立的目录里实验结束后统一导出对比而不是凭记忆去猜哪次参数设置更好。6.2 Docker 推理接口把模型封装成可直接服务的状态项目里带 Dockerfile 意味着你可以把推理环境也容器化这比在宿主机上装一堆依赖要省心得多。训练完成后在runs/train/exp/weights/best.pt得到目标权重在inference.py中按如下思路封装调用import torch def detect_single_image(model, image, device): img letterbox(image, 640, stride32)[0] # 等比缩放补边到640 img torch.from_numpy(img.transpose(2, 0, 1)).float() / 255.0 img img.unsqueeze(0).to(device) with torch.no_grad(): pred model(img)[0] pred non_max_suppression(pred, conf_thres0.25, iou_thres0.45) return pred[0]推理完成后用 Docker 把服务封装起来接口加一个简单的 HTTP 封装就能对外提供检测能力。潜力点在于这套代码稍作改动即可在树莓派 5 上部署自己训练的 YOLOv5 模型——推理端到端用 PyTorch 转 ONNX 再走 NCNN 或 RKNN能在一台边缘设备上跑到 1015 FPS适用于实时监测场景。6.3 一以贯之的落地习惯拆完这套资源我最深的感受是作者把调试过程完整留下了——事件文件是经过验证的代码跑通后才封包。这提醒了我一个习惯从那以后我每次拿到类似的 YOLOv5 遥感项目都强制自己先走一遍完整流程TensorBoard 看收敛 → 切图推理可视化 → 跨窗口 NMS 验证 → Docker 环境复现四个步骤一个不落。这样能在半小时内判断一个项目值不值得深入调参而不是在环境配置和数据格式里消磨掉整个下午。把这份资源作为起点你完全可以在它的骨干上替换成自己的遥感数据集——换成可见光、多光谱甚至 SAR 图都行只要把数据预处理和 anchors 重新适配即可。真遇到问题也欢迎按你的实际情况在项目基础上迭代修改这套代码的扩展空间足够大。希望这些拆解过程能帮到你。本文还有配套的精品资源点击获取
