搞遥感和海上监控的兄弟应该都懂从卫星图、无人机航拍或者岸基摄像头画面里把船一只只框出来再判断它是货船、渔船、客船还是工程船这活儿要纯靠人眼一张张过一天下来眼睛基本报废而且漏检、误检全看当天精神状态。我前阵子接手的一个海事监管辅助需求核心就是这套基于 YOLOv8 深度学习的舰船目标分类检测系统配套PyQt5可视化界面、完整数据集和训练代码。它做的事很直接输入一张舰船图像或一段视频输出每艘船的位置框、类别标签和置信度支持批量处理和结果导出。这套东西适合三类人参考——刚入门目标检测、想找一个完整可跑通项目的学生需要快速搭一个舰船识别原型验证想法的工程人员以及想学深度学习项目从数据到界面全流程落地的自学者。下面我按真实开发顺序,把设计思路、环境、数据集、训练、界面和踩过的坑一次讲透。1. 项目整体设计与技术选型思路1.1 舰船检测这个场景到底难在哪很多人以为目标检测就是框东西,把通用模型拿来跑舰船图就能用,实际上一上手就会发现坑比想象中多。舰船目标的特殊性在于三点。第一是尺度跨度极大,同一张港口遥感图里,近处的大型货轮可能占几百像素,远处的小渔船只有十几个像素,这种极端多尺度对检测头的感受野要求很高。第二是背景干扰强,海面反光、浪花、云层阴影、码头设施都容易和船体混淆,尤其是白浪和白色船体在某些波段下灰度接近。第三是类间差异小,货船和散货船、渔船和工程船的轮廓在远距离下几乎一样,细粒度分类难度上来了。我最初拿一个通用 COCO 预训练模型直接推理,结果小目标漏检率非常高,近岸密集停泊的船还会被合并成一个框。这就是为什么这个项目不能简单套用,必须在数据、模型尺度和后处理上针对舰船做适配。理解这些难点之后,后面的每一个技术选择才有依据,而不是拍脑袋。注意舰船场景里小目标是主要矛盾。如果你的应用主要是港口近景,尺度问题会轻很多;如果是卫星遥感,小目标优化就是重中之重,选型和数据策略要区别对待。1.2 检测框架为什么锁定 YOLOv8选 YOLOv8 不是因为它最火,而是这个场景下它几个特性刚好对口。首先是Anchor-Free 设计,相比 YOLOv5 的锚框机制,免去了针对舰船长宽比重新聚类锚框的麻烦,舰船长宽比从 1:1 到 1:8 都有,锚框调起来很痛苦,Anchor-Free 直接绕开了这个问题。其次是多尺度特征融合做得比较成熟,PAF-FPN 结构对大小船共存的情况比较友好。第三是工程生态完整,Ultralytics 一套 API 把训练、验证、导出、推理全包了,部署到 ONNX、TensorRT 都有一键脚本,对做原型验证非常省事。我对比过 Faster R-CNN 和 YOLOv8,在同样数据集上 Faster R-CNN 精度可能略高一点点,但推理速度差了一个数量级,做实时或准实时的监控系统,速度是硬指标。而 YOLOv8 的 n/s/m/l/x 五个尺度给了很大的灵活空间,可以在精度和速度之间挑,这个项目里我最终用的是YOLOv8s,在消费级显卡上能跑到实时,精度也够用。1.3 界面层为什么选 PyQt5 而不是 Web做可视化,很多人第一反应是搞个 Web 页面。但这个项目我坚持用PyQt5,理由很实在。第一是离线部署需求,海事、港口这类环境经常是内网或者无外网的生产机,Web 方案要拖一堆服务,部署重;PyQt5 打包成一个 exe 双击就跑。第二是和 Python 生态无缝,YOLOv8 本身就是 Python 的,推理直接在同一个进程里调用,不用搞前后端通信。第三是处理本地大图和视频流方便,OpenCV 读帧、渲染 QImage,延迟低。代价是界面开发比 Web 麻烦一点,布局要手写,但换来的是部署简单、稳定。如果你做的是给别人演示或者内网工具,PyQt5 是个很务实的选择。1.4 整个系统的模块划分系统拆成四大模块,边界清晰,方便单独调试。数据模块负责数据集构建、标注格式转换和增强;训练模块封装 YOLOv8 的训练、验证和模型导出;推理模块负责单图、批量、视频的检测逻辑;界面模块是 PyQt5 的主窗口、控件和结果渲染。四个模块之间通过明确的接口通信,比如推理模块对外只暴露一个detect(image)方法,界面只管调用和展示,这样任何一块改动都不会牵一发动全身。这种分层还有个好处,后期想把 PyQt5 换成别的界面框架,推理代码原封不动。2. 数据集构建与环境搭建2.1 环境配置的版本坑环境这块我用的是Python 3.9 PyTorch 2.0 CUDA 11.8 Ultralytics 8.x这套组合,实测比较稳。装的时候有几点必须留意。第一,CUDA 版本要和 PyTorch 版本对齐,别装了个 CUDA 12 的驱动却按 CUDA 11.8 的教程装 torch,那必然报CUDA error: no kernel image is available。第二,PyQt5 不要和 PyQt5-tools 混装,pip install pyqt5-tools这种老包经常和新的 PyQt5 冲突,导致 Designer 打不开。第三,opencv-python 用 headless 版本还是普通版要想清楚,如果你在服务器上无显示环境跑,装opencv-python-headless,否则会在导入时因为找不到显示设备报错。# 我实测稳的一套安装顺序 (Windows/Linux 通用) conda create -n ship python3.9 -y conda activate ship # 先装 PyTorch,注意和你的 CUDA 驱动匹配 pip install torch2.0.1 torchvision0.15.2 --index-url https://download.pytorch.org/whl/cu118 # 再装 ultralytics 和其他依赖 pip install ultralytics8.0.196 pip install PyQt55.15.9 opencv-python4.8.1.78 numpy pandas matplotlib装完之后跑一句from ultralytics import YOLO; import torch; print(torch.cuda.is_available()),返回True才算环境通了。这一步看着简单,但我见过太多人卡在这里,后面所有报错都是这个根子上的问题。2.2 舰船数据集从哪里来数据集是这个项目的地基。公开遥感舰船数据集我推荐几个:HRSC2016适合做旋转框和精细分类,DOTA里的舰船子集覆盖场景广,ShipRSImageNet类别更细但要自己筛。如果做岸基或无人机近景,公开数据就不太够,得自己采或者用标注工具圈。项目里我采用的是公开数据集打底 自采数据补充的混合策略,公开数据保证基础泛化,自采数据针对实际部署场景。从公开数据到能训练,中间要做格式转换。绝大多数公开数据集是 XML 或者 DOTA 格式,需要转成 YOLO 的TXT 格式(每行class_id cx cy w h,坐标归一化到 0-1)。这个转换我写了个脚本批量处理,DOTA 的oriented bounding box要转成水平框(取四点的外接矩形),旋转框转水平框会损失精度,对细长船体框会变大一点,这个误差在小目标上要特别注意。# DOTA/XML 转 YOLO 格式的核心逻辑示意 import os from xml.etree import ElementTree as ET def convert(xml_path, img_w, img_h, class_map, out_txt): tree ET.parse(xml_path) root tree.getroot() lines [] for obj in root.findall(object): name obj.find(name).text if name not in class_map: continue bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) xmax float(bbox.find(xmax).text) ymin float(bbox.find(ymin).text) ymax float(bbox.find(ymax).text) # 转成中心点宽高, 并归一化 cx (xmin xmax) / 2.0 / img_w cy (ymin ymax) / 2.0 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h lines.append(f{class_map[name]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_txt, w) as f: f.write(\n.join(lines))2.3 标注规范与类别定义类别定义要克制,别一上来就分十几类,不然数据每类都不够,训练出来全乱。我建议先分大类: 货船(cargo)、渔船(fishing)、客船(passenger)、工程船(engineering)、军舰类这种敏感的就不要放民用项目里,换成其它船(other)兜底。类别太多会导致模型在小样本类上过拟合,而且实际应用里用户往往也只关心几类。标注规范上,有几个经验:框要贴紧船体轮廓,不要把水面反光框进去,但船体本身是细长的,倾斜停泊时框会有大片背景,这时候水平框的劣势就暴露了;密集停泊的船要一船一框,不要因为挨得近就合并;遮挡超过一半的目标,如果训练阶段能用旋转框最好,用水平框的话这类样本建议标注但降权,别直接扔,否则模型在密集场景会崩。标注工具我用的是 labelImg 和 X-AnyLabeling,后者在遥感和小目标上体验更好。2.4 数据增强与训练/验证集划分舰船数据增强要选对方法。常规的水平翻转、mosaic、mixup都能用,但要注意:垂直翻转要慎用,真实海面场景里船很少倒过来,垂直翻转会引入不自然的分布;随机旋转在遥感图里是有意义的,因为船朝向随机,可以开;色彩抖动适度开,能提升对不同光照的鲁棒性。YOLOv8 默认自带 mosaic 和 HSV 增强,我实测在舰船数据上把 mosaic 关掉一部分比例(接近训练后期)反而对收敛有帮助。划分上按8:1:1或者7:2:1分训练/验证/测试。关键点是按场景划分而不是随机划分,如果同一片海域的图既有训练又有验证,验证精度会虚高,因为模型其实见过这片场景。要尽可能按不同港口、不同拍摄时段、不同传感器划分,这样验证指标才真实。这个细节很多人不注意,结果线上一部署精度掉一半。3. 模型训练与调参实战3.1 训练配置文件逐项拆解YOLOv8 训练用命令行或 Python API 都行,核心参数我一个个说。imgsz我设的640,如果你的小目标特别多,可以考虑 1024,代价是显存和速度;epochs一般 100-300,舰船数据集不大,100 左右往往就收敛了;batch在 8G 显存的卡上设 16,不够就调 8,配合nbs梯度累积;lr0初始学习率 0.01,配合余弦退火;optimizer用默认的auto或者 SGD。这些看着是常规操作,但每一项对结果都有影响。yolo taskdetect modetrain modelyolov8s.pt dataship.yaml \ epochs150 imgsz640 batch16 lr00.01 lrf0.01 \ degrees15 fliplr0.5 mosaic1.0 close_mosaic10 \ projectruns/ship nameexp1 device0close_mosaic10这个参数很实用,表示最后 10 个 epoch 关闭 mosaic 增强,让模型在接近真实分布的数据上收尾,实测 mAP 会稳一点。degrees15开了小角度旋转,适配船朝向多样的场景。3.2 冻结训练与迁移学习的取舍热词里有人搜 yolov8训练参数 freeze,这个参数确实值得讲讲。freeze用来冻结主干网络的前 N 层,配合迁移学习时非常有用。什么场景用?数据量少的时候,比如你只有两三千张标注图,直接全量微调容易过拟合,这时候freeze10冻结主干前 10 层,只训练检测头和解冻的部分,能显著减少过拟合。数据量够大(上万张)且场景和预训练差异大时,就不冻结,全量微调效果更好。我自己的策略是两阶段训练: 第一阶段freeze10训练 30-50 epoch,让检测头先适应舰船类别;第二阶段解冻全部,用较低学习率再训 50-100 epoch,精调整个网络。这套下来比一步到位的训练 mAP 通常能高 1-3 个点。代价是训练时间翻倍,但值得。提示freeze不是万能的。如果你的舰船数据和 COCO 差异极大(比如全是遥感俯视图),预训练权重本身帮助有限,这时候冻结反而限制模型学习,应该放开。3.3 损失曲线与评估指标的解读训练跑起来后,results.csv会记录 loss 和 mAP,YOLOv8 也能自动画曲线。看损失曲线有几个门道:box_loss反映定位精度,cls_loss反映分类精度,dfl_loss是分布焦点损失。如果 box_loss 降不下去,通常是标注质量或者部分目标太小的问题; 如果 cls_loss 震荡大,可能是类别不平衡或者学习率偏高。评估指标里最重要的是mAP0.5和mAP0.5:0.95。前者宽松,后者严格。舰船这种小目标,mAP0.5:0.95通常比较低,因为定位精度难做高。别只盯着一个数,要分尺度看—— 用yolo val输出的各类别 AP,如果小船 AP 很低而大船很高,那就是尺度问题,该去优化数据增强(比如加小目标过采样)或者换更大输入尺寸。我踩过的一个坑是:训练时 mAP 一路涨,验证集也很好,但一测实际场景就拉胯,后来发现是验证集没按场景划分,同一个港口的图泄露了。所以看指标前先确认划分干净。3.4 模型导出与推理加速训练完的.pt模型直接推理也行,但部署要考虑加速。YOLOv8 支持导出ONNX、TensorRT、OpenVINO等多种格式。GPU 环境推荐导 TensorRT,速度能提升 2-3 倍,但有个坑:TensorRT 版本和 CUDA、驱动要严格匹配,不匹配会导出失败或者推理结果错误。CPU 环境导 OpenVINO 比较好。导出命令一行搞定:from ultralytics import YOLO model YOLO(runs/ship/exp1/weights/best.pt) # 导出 ONNX (兼容性最好, 跨平台) model.export(formatonnx, opset12, simplifyTrue) # 导出 TensorRT (需要 tensorrt 环境, 速度最快) # model.export(formatengine, halfTrue, device0)导出 ONNX 时记得simplifyTrue,能去掉冗余节点。halfTrue开启 FP16 半精度,速度更快显存更省,但精度会有极小损失,舰船这种任务通常可以接受。导出后一定要验证导出模型的推理结果和原始 pt 模型一致,我遇到过导出后框偏移的问题,最后定位是 opset 版本和 simplify 的交互导致的,换 opset12 就正常了。4. PyQt5 界面开发与推理集成4.1 界面布局与交互设计界面我按输入区—控制区—结果区三段式设计。输入区支持单图、批量文件夹、视频三种模式,顶部放一个模式切换;控制区有置信度阈值滑块、类别筛选复选框、开始/停止按钮;结果区左边原图右边检测图,底部是检测结果列表(类别、置信度、坐标)。这种布局上手快,演示时领导一眼能看懂。布局用QVBoxLayout 和 QHBoxLayout 嵌套,左侧预览区用 QLabel 配合 scaled pixmap 自适应。有个细节:大图直接塞进 QLabel 会撑爆窗口,必须按控件尺寸等比缩放,再维护一个坐标映射关系,否则你在图上画的检测框坐标和原图对不上。这个映射关系是新手最容易翻车的地方,建议单独封装一个ImageCanvas类专门管坐标转换。界面美化可以用 QSS 样式表,写起来像 CSS,把按钮、滑块统一风格,比默认的灰色控件好看得多。4.2 多线程推理避免界面假死这是 PyQt5 做检测工具的核心坑。如果你直接在按钮的槽函数里跑model.predict(),推理期间界面完全卡死,进度条不动,用户点关闭都没反应,体验极差。正确做法是把推理放在QThread里,主线程只管界面刷新,通过信号槽传递结果。from PyQt5.QtCore import QThread, pyqtSignal import cv2 from ultralytics import YOLO class InferThread(QThread): # 定义信号: 传回带框图像和结果列表 finished_one pyqtSignal(object, list) def __init__(self, model_path, source, conf0.25): super().__init__() self.model YOLO(model_path) self.source source self.conf conf self._running True def run(self): # 单图或视频统一处理, 视频按帧循环 results self.model.predict(self.source, confself.conf, streamTrue) for r in results: if not self._running: break img r.plot() # 画好框的 numpy 图 boxes r.boxes det_list [] for b in boxes: cls_id int(b.cls[0]) conf float(b.conf[0]) xyxy b.xyxy[0].tolist() det_list.append((cls_id, conf, xyxy)) self.finished_one.emit(img, det_list) def stop(self): self._running False主线程里把finished_one信号连到刷新槽函数,收到图就转成 QImage 显示。这样即使推理慢,界面也始终响应,停止按钮能实时打断。视频场景用streamTrue逐帧返回,避免一次性占满内存。4.3 结果渲染与数据导出渲染检测框我直接用results.plot()返回的图,省事且风格统一,但如果你想自定义颜色和线宽,也可以自己用 OpenCV 的cv2.rectangle和cv2.putText画。类别颜色建议做个映射表,不同船型用不同颜色,一眼区分。置信度显示到两位小数就够了。导出功能是实用加分项,支持把检测结果导出成CSV(每行一张图的检测项)或者带框的图片。CSV 用 pandas 写就行,字段包含文件名、类别、置信度、x1y1x2y2。这里有个注意点:导出的坐标要还原到原图尺寸,如果渲染时图像被缩放过,坐标就得按缩放比例反算回去,不然导出的坐标全是错的。我一开始就栽在这,导出后一核对发现坐标全飘了,排查半天才发现是缩放映射没还原。注意视频导出时用cv2.VideoWriter,记得帧率、编码器、分辨率要和源视频一致,否则导出的视频会快放或慢放。MP4 用mp4v编码器,想兼容性好就avc1,但后者依赖系统编解码库。5. 常见问题排查与避坑实录5.1 训练阶段典型问题速查训练阶段问题多,我整理成速查表,方便对照定位。现象可能原因解决思路loss 一直不下降学习率过大 / 标注错乱降 lr,检查标注坐标是否越界mAP 虚高但实测差训练验证同场景泄露按场景重划分数据集小目标几乎检不出输入尺寸太小 / 小样本不足提到 1024,mosaic 增广小目标显存溢出 OOMbatch 太大 / imgsz 太大降 batch,开 amp 混合精度类别混淆严重类别定义过细 / 数据不平衡合并相近类,过采样小类训练后期剧烈震荡学习率没退火开余弦退火,调 lrf这里面最花时间的其实是标注问题。我遇到过训练正常但个别船永远检不出,后来发现是那批图的标注坐标归一化时用错了图像尺寸(有些图有 EXIF 旋转信息,读取尺寸和实际显示不一致)。所以转换格式后一定要可视化抽查,把 TXT 里的框画回图上,肉眼看一遍,能提前发现 90% 的标注问题。5.2 界面与部署阶段典型问题速查界面和部署这块,热词里提到的 opengl 导致 pyqt5 界面无显示 是个真实高频问题。原因是某些显卡驱动或远程桌面环境下,Qt 默认用 OpenGL 渲染,结果黑屏或者闪退。解决办法是强制用软件渲染,在程序入口设置环境变量:import os # 放在所有 Qt 导入之前! os.environ[QT_OPENGL] software # 或者禁用硬件加速的组合 os.environ[QT_QUICK_BACKEND] software from PyQt5.QtWidgets import QApplication注意这个环境变量必须在导入 PyQt5 之前设置,放在后面是无效的。远程桌面、虚拟机、老显卡环境尤其容易触发这个问题。现象可能原因解决思路界面黑屏/闪退OpenGL 渲染冲突设 QT_OPENGLsoftware界面无响应卡死推理跑在主线程移到 QThread打包后缺 dll依赖没收集全用 pyinstaller 加 --collect-all大图显示错位缩放坐标没还原封装坐标映射类视频播放卡顿逐帧阻塞主线程stream 信号刷新中文路径报错OpenCV 不支持中文先用 imdecode 读字节流打包这块补一句:用PyInstaller打包时,ultralytics 和 torch 的隐式依赖很多,直接打容易漏文件。建议加--collect-all ultralytics和--collect-all torch,再把.pt权重和配置文件一起打进去,否则用户那边一运行就报找不到模型。打包完一定要在没有 Python 环境的干净机器上测,开发者机器上因为有全局依赖,经常我这里能跑。5.3 精度与速度优化的实战经验最后说说调优。精度上不去,先别急着换大模型,按这个顺序排查: 数据质量 数据量 输入尺寸 模型尺度。很多时候是数据问题,不是模型问题。加了几百张难例(小目标、密集场景、遮挡场景)进去,比换 yolov8l 提升更明显。速度上不去,优先导 TensorRT 或 ONNX,其次降输入尺寸,再考虑换更小的模型尺度(n/s)。还有一招是跳帧推理,视频场景里每 2-3 帧推理一次,中间帧复用上一帧结果,视觉上几乎看不出来,速度直接翻倍。这招在监控类应用里特别实用。关于模型尺度选择,yolov8n速度快但小目标差,yolov8x精度高但慢。我一般用yolov8s 或者 yolov8m起步,实测够用。如果你显卡是 1660ti 这种 6G 显存的,建议 n 或 s,imgsz 别超 640,否则 OOM。有条件上 3060 12G 或者更高,batch 和 imgsz 都能放宽。# 视频流跳帧推理的小技巧 import cv2 from ultralytics import YOLO model YOLO(best.onnx, taskdetect) cap cv2.VideoCapture(harbor.mp4) frame_id 0 last_boxes [] while cap.isOpened(): ret, frame cap.read() if not ret: break # 每 3 帧推理一次, 其余帧复用结果 if frame_id % 3 0: results model.predict(frame, conf0.3, verboseFalse) last_boxes results[0].boxes # 用 last_boxes 在当前帧上画框 for b in last_boxes: x1, y1, x2, y2 map(int, b.xyxy[0].tolist()) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.imshow(ship, frame) if cv2.waitKey(1) 0xFF 27: break frame_id 1 cap.release() cv2.destroyAllWindows()我在实际落地这套系统时最大的体会是:模型本身只占 30% 的工作量,剩下 70% 是数据工程和工程化。一个能跑的 demo 和一套能用的系统之间,隔着数据清洗、场景划分、多线程、打包部署这一整套东西。尤其是数据,舰船场景下小目标和密集场景的难例,你往里加多少,系统就稳多少,这个投入回报比远高于折腾模型结构。另外提醒一句,如果你要做遥感大图,别直接把整张大图喂给模型,先切图 重叠裁剪再推理,最后把结果拼回去,否则分辨率一压小目标就没了。切图重叠率设 20%-30%,拼接时用 NMS 去重,这套流程走下来,大图检测才真正可用。