水下目标检测竞赛源码解析：基于MMDetection的A榜0.569/B榜0.568实践

简介适用于水下光学目标检测竞赛的完整源码包来自2021和鲸赛事包含A榜0.569、B榜0.568的赛项方案与学习说明面向计算机、数学、电子信息等专业学生及目标检测入门者可作为竞赛复现和算法进阶的参考。资源共877个文件6.54MB以759个Python脚本为主涵盖模型定义、训练与推理流程另有78个Markdown文档、多个YAML配置、Shell脚本、Dockerfile及Jupyter Notebook教程方便快速搭建环境并理解代码结构目前已有143人学习下载。包内不仅提供可直接运行的完整项目代码还附带交互式教程和示例图片便于对照学习数据预处理、锚框设计、模型调参与结果可视化等关键环节适合需要系统梳理水下目标检测竞赛方案、动手实践并自行扩展功能的读者。1. 水下目标检测赛项源码A榜 0.569 / B榜 0.568 是怎么跑出来的做水下光学目标检测赛题的人都有一个共同感受模型不难跑通难的是分数卡在某个区间死活上不去。这份 2021 和鲸水下光学目标检测智能算法赛项的完整源码包A 榜 0.569、B 榜 0.568放在当年属于稳定靠前的成绩。它不是一个跑完就完事的玩具工程而是基于 MMDetection 的完整训练推理链路源码、Dockerfile、Jupyter 教程、推理演示、anchor 修改备份全都在里面。适合三类人想复现真实竞赛全流程的从业者、要在自定义数据集上快速落地目标检测的工程师、以及打目标检测竞赛却不知道怎么提分的新手。下面我把仓库结构、环境搭建、anchor 调优逻辑和踩坑记录完整拆一遍。2. 看懂仓库底子再动手赛题难点、文件布局与框架选型2.1 水下场景的检测难点和赛题数据特点水下光学图像和常规的 VOC、COCO 图像差别非常大。首先是颜色失真蓝绿色调把目标的纹理信息压得很厉害其次是悬浮颗粒和光的散射图像对比度低、边缘模糊再就是目标本身的特点海参、海胆、扇贝这类生物大部分是小目标而且目标与背景灰度接近检测器很容易把背景区域误判成目标。这些特点叠加起来通用的 Faster R-CNN 或 YOLO 权重直接迁移过来效果很差这也是赛方把它单独设成赛题的原因。赛题数据通常由主办方统一提供图片尺寸不大、单张目标数量多标注格式接近 COCO 的 JSON 或 VOC 的 XML。训练集、验证集、测试集是分开的测试集图片数量远大于验证集而且分布存在差异。从包里的 coco_test_12510.jpg 这种命名习惯能看出作者当时是把测试集里的图片拿出来单独跑推理验证的而不是拿官方 demo 图凑数。这一点很重要因为竞赛最后看的就是测试集上的泛化表现而不是训练 loss 有多低。在动手之前先把几个容易混淆的概念理清。这份资源里说的目标检测指的是水下光学图像里的实例级检测需要同时输出类别和定位框它和遥感图像目标检测、三维目标检测不太一样后者有各自专用的框架和先验而水下赛题更接近通用物体检测的孪生场景。理解了这一点就不会在选型和配置阶段浪费时间。2.2 源码包文件清单与分工拿到压缩包之后先别急着装环境把文件按角色归类一遍。这份包不是那种一个 notebook 打天下的课程代码而是正规的 MMDetection 工程结构每个文件都有明确的用途。文件 / 目录类型在工程里的角色MMDet_Tutorial.ipynb教程OpenMMLab 官方的 MMDetection 上手示例验证环境和入门训练inference_demo.ipynb演示作者自己写的推理流程加载训练好的权重跑测试图anchor_head.py.bak源码备份修改前的 anchor_head.py 备份是理解调优思路的关键文件Dockerfile容器配置一键复现 CUDA PyTorch MMDetection 环境make.bat构建脚本Windows 下执行 setup.py develop 的入口setup.cfg包配置元数据和代码规范flake8配置pytest.ini测试配置跑 mmdet 自带单测时的配置.gitignore版本管理忽略权重、临时文件的规则demo.jpg测试图官方演示图用来跑通推理流程coco_test_12510.jpg测试图从赛方测试集抽出的真实推理样本验证模型实际表现这里面最值得研究的不是 notebook而是 anchor_head.py.bak。它说明作者在调优过程中直接改过 MMDetection 内部的 anchor 生成逻辑改完还留了备份这比任何调参心得都实在。后面第 4 章会专门拆这个文件可能改了哪些位置。2.3 为什么用 MMDetection 而不是裸 YOLO先说结论选 MMDetection 是因为它的 config 体系和模块化程度最适合竞赛场景下的快速迭代。竞赛期间需要频繁改 backbone、neck、head、loss、anchor 生成器MMDetection 把这些全部拆成可配置的模块改一个参数不用动一行底层代码配置文件一换就是一组新实验。而 YOLOv5、YOLOv6 这类工程化框架anchor 机制和 head 封装得比较深想改正负样本分配策略或者自定义 head往往要动核心代码迭代效率低。有人会说用开放词汇目标检测或者多模态模型不是更高级吗那个方向适合研究不适合这种数据量有限的线下竞赛。开放词汇模型依赖大规模预训练测试时需要额外的文本提示在水下数据集上很难稳定发挥而竞赛环境下大家比拼的更多是 anchor 配置、数据增强、训练策略这些看得见摸得着的东西。从 A 榜 0.569、B 榜 0.568 的成绩看作者用 MMDetection 这套成熟框架加针对性调优确实打出了效果。需要说明的是这不是说 YOLO 不能打而是说在这份源码的应用场景里MMDetection 的透明度和可修改性更适合做精细化调优。如果你熟悉 YOLO 系并且时间充裕同样可以把这里的 anchor 思路移植过去但学习成本会高不少。3. 环境复现全流程Dockerfile、make.bat 与一句命令跑通教程3.1 用 Dockerfile 锁定 CUDA 与 PyTorch 版本竞赛代码最怕的是什么是别人拉下来跑不通因为环境不一致。作者在包里放了一个 Dockerfile就是为了把开发环境完整锁住。常见做法是基于 PyTorch 官方镜像来构建把 mmcv-full 和项目本体依次装进去这样不管在 Linux 服务器还是自己的机器上都能得到一致的运行环境。FROM pytorch/pytorch:1.8.1-cuda10.2-cudnn7-devel WORKDIR /workspace # 基础图像库MMDetection 推理时 OpenCV 依赖 libGL RUN apt-get update apt-get install -y \ libgl1 \ libglib2.0-0 \ libsm6 \ libxext6 \ libxrender-dev \ rm -rf /var/lib/apt/lists/* # 安装与 torch 版本匹配的 mmcv-full RUN pip install mmcv-full1.3.17 \ -f https://download.openmmlab.com/mmcv/dist/cu102/torch1.8/index.html # 以可编辑模式安装项目源码 COPY . /workspace/mmdet RUN cd /workspace/mmdet pip install -e .这段 Dockerfile 的逻辑很清晰第一层装系统库因为 MMDetection 推理时通过 OpenCV 读图而 opencv-python 在精简容器里缺 libGL 会直接报错第二层装 mmcv-full版本必须和 PyTorch、CUDA 严格对应否则会装成纯 CPU 版或者编译失败第三层把项目以可编辑模式装进去后续改代码不用重新 build 镜像。实际操作时把基础镜像的 tag 和 mmcv-full 版本换成自己显卡驱动支持的组合即可Dockerfile 骨架不用动。构建和启动容器时需要注意 GPU 透传普通 docker run 是看不到显卡的必须加 --gpus 参数。另外基础镜像里的 CUDA 版本并不是看驱动版本而是看驱动支持的上限比如 CUDA 10.2 需要驱动版本不低于 440这个可以用 nvidia-smi 里的 CUDA Version 字段确认。3.2 本地安装make.bat、setup.cfg 与 pytest.ini 的分工不是所有人都习惯用 Docker作者给 Windows 用户准备了 make.bat 作为本地安装入口。这个脚本内容不多核心就是调用 setuptools 以 develop 模式安装当前目录下的包。echo off REM 在项目根目录运行作用等价于 python setup.py develop python setup.py developdevelop 模式的好处是安装后代码和当前目录保持软链接改动源代码立即生效不需要反复重装这对要改 anchor_head.py 的调优场景特别重要。执行完 make.bat 之后命令行会输出一堆 copy、creating 的日志最后出现 Finished processing dependencies 才算装好。如果中途报错最常见的两个原因一是没有激活对应 conda 环境二是 python 版本和 mmdet 要求不匹配先检查这两项。setup.cfg 在 MMDetection 工程里主要管两件事一是包元数据二是 flake8 的代码规范比如行长度限制、忽略规则。平时跑推理不会直接用到它但如果你给项目提交了自定义配置文件跑 flake8 检查时它就有用了。pytest.ini 同理是给 mmdet 自带的单元测试用的里面指定了测试目录和命令行参数。这两个文件本质上是工程规范的一部分和模型效果无关新手不用在上面花太多时间。3.3 跑通 MMDet_Tutorial.ipynb 验证环境环境装完之后先别急着训练自己的模型用包里带的 MMDet_Tutorial.ipynb 做一次冒烟测试。这个 notebook 是 OpenMMLab 官方的上手教程包含配置模型、训练、测试的完整示例。把 kernel 选到刚装好的环境按顺序执行重点看两处模型能否正常初始化、单轮训练能否跑通。from mmdet.apis import init_detector, inference_detector # 先加载官方 COCO 预训练权重验证推理链路 config_file configs/faster_rcnn/faster_rcnn_r50_fpn_1x_coco.py checkpoint_file checkpoints/faster_rcnn_r50_fpn_1x_coco_20200130-047c1198.pth model init_detector(config_file, checkpoint_file, devicecuda:0) result inference_detector(model, demo.jpg) model.show_result(demo.jpg, result, out_filedemo_out.jpg) print(推理完成输出图片 demo_out.jpg)这段代码里 init_detector 负责把配置文件和权重合成为一个可推理的模型对象inference_detector 封装了预处理、前向、后处理全过程show_result 把检测框画回原图。如果这一步能正常出图说明从 mmcv 到 mmdet 整条链路都是通的如果报错九成是环境问题优先回去检查 mmcv-full 版本和 GPU 驱动。我用这套流程排查环境问题时几乎都是一轮之内定位到原因。提示mmcv-full 安装经常因为网络原因超时可以换内网镜像源或者先把 wheel 下载到本地再 pip install不要反复重试同一命令。4. 训练与提分的关键操作anchor_head.py.bak、训练配置与 0.569 的由来4.1 数据组织与 config 参数修改环境通了就进入正题。竞赛的第一步不是选模型而是把数据整理成 MMDetection 认识的格式。这份源码默认使用 COCO 格式数据目录结构一般是 data 下按 train、val、annotations 分好。写自己的 config 时最需要改的就是数据集路径和类别列表。_base_ ./faster_rcnn_r50_fpn_1x_coco.py model dict( roi_headdict( bbox_headdict( num_classes4, # 换成自己赛题的类别数 ) ) ) dataset_type CocoDataset data_root data/underwater/ classes (holothurian, echinus, scallop, starfish) data dict( samples_per_gpu2, # 显存不够就往下调 traindict( typedataset_type, classesclasses, ann_filedata_root annotations/train.json, img_prefixdata_root train/), valdict( typedataset_type, classesclasses, ann_filedata_root annotations/val.json, img_prefixdata_root val/), testdict( typedataset_type, classesclasses, ann_filedata_root annotations/test.json, img_prefixdata_root test/))这里的核心逻辑是以官方 COCO 配置为底座然后只覆盖需要改的部分。num_classes 改成赛题类别数classes 元组要和标注文件里的类别顺序一一对应顺序错了 mAP 会乱到不可信。samples_per_gpu 是单卡单次的图片数它直接决定显存占用和 BN 统计效果一般从 2 开始试OOM 就减半。很多人在这里犯的一个错误是只改了 num_classes 忘了改 classes 顺序结果训练日志里 loss 正常下降验证 mAP 却始终在低位徘徊那是标注索引对不上导致的。学习率和训练轮数也要顺手检查。MMDetection 默认的 1x schedule 是 12 个 epoch学习率在 8 和 11 epoch 时衰减。数据量小的赛题可以直接沿用但如果训练集只有几千张我一般会把 lr 从 0.02 降到 0.01防止前几个 epoch 就震荡。4.2 anchor_head.py.bak 改了什么从 anchor 机制看调优思路现在说回到那个最值得研究的 .bak 文件。MMDetection 里的 anchor_head.py 负责生成 anchor、计算分类和回归目标、计算 loss。原始文件被改过作者留了备份说明这里动过真格。虽然源码包里只有备份文件没有 diff 记录但从 A 榜分数和常见调优路径可以反推改动位置。水下目标检测最典型的改动有两处。第一处是 anchor 的尺寸配置。通用 COCO 的 anchor scales 通常覆盖 4 到 512 像素的大范围但水下赛题的小目标很多直接沿用原始配置会在小尺度特征图上产生大量冗余 anchor正负样本比例失衡。常见做法是把 scales 整体调小并让不同层级的 scales 更密集。anchor_generatordict( typeAnchorGenerator, strides[8, 16, 32, 64, 128], ratios[1.0], # 水下目标长宽比接近 1砍掉极端 ratio scales[1, 2, 4, 8]) # 缩小 anchor 覆盖范围聚焦小目标strides 对应特征图的步长8 到 128 表示浅层特征负责小目标、深层负责大目标ratios 是 anchor 的长宽比水下生物大多是近圆形或细长形把 0.5 和 2.0 去掉可以显著减少负样本scales 是基础尺寸的倍数值越小 anchor 越偏向小尺寸区间。改完之后head 的回归分支输出维度会随着 anchor 数变化如果直接加载旧权重会出现 key 不匹配的报错这一点在 5.2 里会展开讲。第二处常见改动是 loss 的配置。水下目标检测正负样本极度不平衡anchor 生成器一旦改了匹配上的正样本数量会变化分类 loss 可能从 0.3 跳到 0.8。很多人会把分类 loss 换成带 alpha 和 gamma 的 focal 变体或者调整 loss_weight 里的权重比例。这类改动同样集中在 anchor_head.py 里。改完记住保存备份这也是作者留下 .bak 的原因改坏了随时能还原。4.3 训练命令、日志监控与提分点配置写好后训练命令非常直接python tools/train.py configs/underwater/faster_rcnn_r50_fpn_1x_underwater.py \ --work-dir work_dirs/underwatertrain.py 是 MMDetection 的统一入口--work-dir 指定日志和权重输出目录。训练过程中重点看两个东西loss 曲线是不是稳定下降以及 val 集 mAP 有没有跟上。loss 震荡剧烈通常说明学习率太大或正负样本分配有问题mAP 上不去但 loss 很低说明模型过拟合到训练集了这时该考虑数据增强而不是继续加轮数。目标检测模型微调崩了八成出在结构改动或学习率上和训练轮数关系不大。从 0.569 这个分数往回推作者大概率还做了几个在竞赛里非常管用的操作把 backbone 换成更强的主干、开启多尺度训练、在测试阶段用多尺度推理。这些在 config 里都是一两行的改动但对水下小目标提升明显。多尺度训练一般在 pipeline 里加一个 Resize 的随机尺度范围。train_pipeline [ dict(typeLoadImageFromFile), dict(typeLoadAnnotations, with_bboxTrue), dict(typeResize, img_scale[(800, 800), (1000, 1200)], multiscale_moderange, keep_ratioTrue), dict(typeRandomFlip, flip_ratio0.5), dict(typeDefaultFormatBundle), dict(typeCollect, keys[img, gt_bboxes, gt_labels]) ]img_scale 在 (800, 800) 到 (1000, 1200) 之间随机取值让模型见过不同尺度的目标对泛化非常有帮助。需要注意多尺度训练会让每个 epoch 变慢训练时间要预留充足。val 阶段建议保持固定尺度否则验证 mAP 会受随机尺度影响来回跳动难以判断真实水平。5. 避坑手册从 demo.jpg 到 coco_test_12510.jpg 的五条真实踩坑记录5.1 坑一显存溢出现象训练刚开始第二个 iteration 就报 RuntimeError: CUDA out of memoryloss 还没开始降就退出。这种情况在每个赛期都能遇到不是个例。原因config 里 samples_per_gpu 设得太大加上输入图片尺寸不小backbone 和 head 的前向计算把显存撑爆了。4G 显存硬跑 Faster R-CNN 加 ResNet50 的典型配置几乎一定会 OOM。解决先把 samples_per_gpu 调成 1关闭所有数据加载线程再考虑缩短图片最长边。我一般会在 config 里把 max_size 从默认的 1333 改到 1000效果立竿见影。另外显存不够时优先减批量而不是减分辨率减分辨率会让小目标更难检。5.2 坑二改完 anchor_head.py 之后加载旧权重报错现象改动 anchor_head.py 后加载之前训练好的模型提示 unexpected key 或者 missing key测试分数直接清零看起来像模型没训练过。原因anchor 数目变了head 最后的卷积输出通道数跟着变而权重是按旧的输出通道存的加载时 key 对不上整个 head 相当于随机初始化。很多人没有意识到 anchor 数量对 head 输出维度的影响改完就翻车。解决在 config 里把 load_from 设成预训练 backbone只加载主干网络权重新 head 从头训练。或者用严格模式加载把 non-strict 设为 True跳过不匹配的部分。从那以后我每次动 head 结构都会先确认输出通道和权重维度一致再开始训练。5.3 坑三推理结果全是背景或小目标全部漏检现象demo.jpg 跑出来没有任何框或者 coco_test_12510.jpg 上只检到大目标小目标一个没有分数看起来像没训练过。原因有几种可能。类别数写错导致 label 映射错乱anchor 设置得太小特征金字塔深层根本没有对应尺度的锚还有一种很隐蔽就是测试阶段没有把 config 里的测试尺度调回单尺度多尺度训练之后测试输入尺寸不一致导致特征分布对不上。解决先用官方 COCO 权重跑通 demo.jpg 建立基准再把自己的权重替换上去做对照这样能把问题精确限定在是配置不对还是模型没训好。小目标全漏的情况下优先检查 anchor scales 是否覆盖到 8 到 32 像素区间再检查测试时是否用了和训练一致的 Resize。5.4 坑四Docker 里推理报 libGL 错误现象容器里跑 inference_demo.ipynbOpenCV 报 ImportError: libGL.so.1: cannot open shared object file整个推理没法进行。原因官方 PyTorch 基础镜像是精简版没有装图形相关的系统库而 opencv-python 在 Linux 下强依赖 libGL。这个问题在物理机上不存在一到容器里就暴露很多人因此误以为代码有问题。解决在 Dockerfile 里把 libgl1、libglib2.0-0 等系统库装齐全构建命令里加 apt-get update apt-get install。最简单的方式是直接用包里现成的 Dockerfile不要用裸的 PyTorch 镜像手动装。5.5 坑五测试集命名和提交格式对不上提交失败现象本地推理一切正常但提交到赛方平台后显示格式错误或者 mAP 只有几分和本地验证完全不符。原因测试集图片文件名和推理脚本里写死的路径不一致导致有图片没被预测另一方面赛方提交格式通常是 JSON要求每张图按指定格式输出 categories 和 bboxes顺序或字段名错了会被判为无效。这个坑在最后一刻踩中时几乎没有后悔药可吃。解决写一个独立的小脚本先遍历整个测试目录再生成提交结果把文件列表和预测结果一一对应起来。主打一个先对名字再对结果永远不要用手动拼接的方式生成提交文件。我一般会在正式提交前把结果 JSON 重新读一遍检查图片数量是否等于测试集总数量确认无误再上传。6. 把 B 榜 0.568 再往上推TTA 与多尺度推理的一次实测6.1 B 榜比 A 榜低 0.001差在哪A 榜 0.569、B 榜 0.568两个分数非常接近说明模型泛化比较稳定。B 榜略低一点点通常不是过拟合而是测试集分布和 A 榜有细微差异模型在部分边缘样本上漏检。这个量级的分数差异靠重新训练不一定能回来最经济的做法是压低单张图片的随机性让预测结果更稳定。6.2 TTA 与多尺度推理的落地写法TTA 是提升目标检测稳定性的常用手段思路是对同一张图做多尺度缩放和水平翻转然后把预测框融合起来。MMDetection 虽然没有一键 TTA但可以借助数据管线手动实现。import cv2 from mmdet.apis import inference_detector def tta_detect(model, img_path, scales[(800, 800), (1000, 1200), (1200, 1333)]): results [] img cv2.imread(img_path) for scale in scales: scaled cv2.resize(img, scale) result inference_detector(model, scaled) results.append(result) # 水平翻转后再推理一次 flipped cv2.flip(scaled, 1) result_flip inference_detector(model, flipped) results.append(result_flip) return results这个写法的关键在于把每个尺度和翻转方向的预测框都收集起来最后做融合。注意这个示例没有做坐标还原的完整处理实际使用时要根据原图尺寸把预测框映射回来再计算置信度平均。跑一轮 TTA 大约要多花 3 倍推理时间但对小目标密集的水下图像来说收益明显特别是能补回 B 榜那 0.001 的差距。从那以后我每次打竞赛都会强制在提交前把 TTA 和测试集命名检查走一遍确认结果 JSON 里图片数量和测试集完全一致再上传希望帮到你。本文还有配套的精品资源点击获取