前言
本文简单的对FewX-Fsod的工程结构进行分析，源码地址点击此处，该工程整体上都是基于Detectron2开发，所以建议先了解Detectron2的大致使用。
不多写markdown语法，不太会用这里面的目录，我用大写代表主文件夹，·代表子文件夹，最小加粗标题代表里面的源码名字，太深的目录直接用源码路径表示了。
一、datasets文件夹
按照作者readme的介绍，要运行此工程需要先执行datasets文件夹下的generate_support_data.sh，打开此文档可以看到里面是按照顺序以此执行datasets/coco文件夹下的各个脚本。（已注释的语句暂时不分析，后补）
1_split_filter
将coco标注文档分为voc类别和非voc类别的两个标注文档，此代码用于将整个coco数据集进行划分，便于后续使用
3_gen_support_pool
根据coco的标注文件将每个数据进行crop操作，然后转换为320*320的样本，用0填充，得到support data，将bbox进行相应的缩放和重新映射坐标，得到support_box。下面这个博主介绍的很详细，可以对着这段讲解去阅读源码，很清晰。
首先根据要查询的物体找到其对应的gt框，这时候并不是直接crop gt框内的内容，而是在gt框外面额外扩充16个像素（上下左右四个方向），并且还要进行0值padding，为什么要进行padding呢，原因很简单，因为我们最终需要保证输入的support image是一个正方形图片，在本文中是320X320，如果你需要查询的物体外形是一个长方形，那么直接crop之后resize到正方形，会造成形状形变，为了保证物体形状不变，所以需要使用0值填充，将刚才选定的gt+16个像素的区域根据长边填充到正方形，再进行resize，这样物体形状就不会变啦。
————————————————
版权声明：本文为CSDN博主「Wanderer001」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_36670529/article/details/115053697
4_gen_support_pool_10_shot
根据10-shot的标注文件进行操作，流程同上
总结一下，此文件夹主要目的就是为了将coco数据集预处理，同时生成支持集和查询集（小样本数据集）用于后续的finetune过程
二、configs文件夹
存放yaml格式的配置文件，该配置文件为detectron2专用的配置文件，可以通过写自己的yaml文件，将自己的模型、数据集、加载器、优化器等注册入detectron2容器中进行使用。通常写一个训练文档都要对应写自己的配置文件。
R_50_C4_1x.yaml
finetune_R50_C4_1x.yaml
Base-FSOD-C4.yaml
三、fewx文件夹
-
data文件夹
datasets/builtin
注册两个数据集，一个叫coco_non_voc，一个叫coco_voc，返回为字典形式。这两个数据集刚好对应了前面datasets中分好的两个标注json文件。builtin里用一个循环分别对多个数据集进行注册，其中每个数据集注册的时候调用了register_coco.py
datasets/register_coco
被builtin调用，就是用于注册数据集，具体函数内容请直接看源码注释，非常清晰。
build
包含build_detection_train_loader和build_detection_test_loader，将外部传入的dataset_mapper调用，并创建为对应的数据加载器
dataset_mapper
里面定义了迭代时对每一张图片的数据转换，将普通图片的信息（通常为一个dict，里面包含图片路径，大小，标注信息）转换为模型需要的形式（为一个dict，里面包含原始信息（即输入的dict里的内容），和处理后的tensor内容（包含图片本身，支持集，标注信息，类别等））。在这个类中进行了对support数据的处理，将support图片处理为支持集，添加入该dict中。
简单来讲，dataset_mapper负责将每张图片处理为模型需要的格式，里面有模型训练时用到的信息。
-
config文件夹
defaults
这个文件就是用来将作者自己定义的一些参数赋于默认值。这个操作方便通过配置文件进行修改。
config
这个文件将作者定义的参数载入
-
modeling/fsod文件夹
fsod_rcnn
初始化整个fsod网络，里面根据配置文件初始化出了backbone模块，rpn模块，roi_head模块；在forward中，实现了训练和验证两大分支的功能：1、训练分支：先构造查询图片和支持集，分别通过骨干网络得到查询图片特征和支持集特征（似乎这个代码只支持2-way-N-shot），然后通过rpn、roi_head（均是自己实现的模块）进行预测和计算损失函数并回传；2、验证分支：通过init_model将支持集进行处理，得到支持集的特征，然后通过inference函数进行推理，得到结果。
总的来讲，作者注册了FsodRCNN（见base-fsod-c4.yaml）作为网络，训练和验证均是先处理支持集，再和查询图片进行后续的处理。
fsod_roi_heads
注册ROI_HEADS的FsodRes5ROIHeads模块（见base-fsod-c4.yaml），在fsod_rcnn中被调用初始化。
这几个模块的编写思路都是一致的，首先写一个类，可以继承原先detectron2中提供的一些类，比如FsodRes5ROIHeads继承的detectron2.modeling.roi_heads.roi_heads 的 ROIHeads类，也可以继承nn.module；然后编写模块内部的一些函数，最基本的有init，forward函数，根据需求自己编写其他的函数；最后加上register的注解，将模块注册进detectron2容器中，编写build函数提供接口通过配置文件进行创建。
fsod_rpn
编写并注册RPN网络，作者注册了FsodRPN（见base-fsod-c4.yaml），根据前面得到的feature实现了proposal的预测。（具体的参数列表和返回列表见源码注释）
fsod_faster_rcnn
此类是被fsod网络初始化时调用，主要负责对feature和support feature进行进一步处理，提供了一些工具函数，如loss、predict_probs，predict_boses等。并且文章的后半部分提到的Multi-Relation Detector，即三种相关检测器，就是在这个类中实现的。
总结一下，modeling文件夹里就是整个网络的核心内容，所有的模块定义、传播方式均在里面实现，理解论文的关键也在这里的源码中。
-
solver文件夹
build
主要负责创建优化器。
-
utils文件夹
里面是一些工具函数，负责计算的封装
-
evaluation文件夹
coco_evaluation
负责评估，里面定义了各种指标ap的计算和输出
-
layers文件夹（待编辑）
四、log文件夹
里面存放每次训练和验证的日志
五、output文件夹
里面存放训练后的权重文件(.pth)和对应的日志文件以及输出结果
六、support_dir文件夹
里面存放支持集的特征，以pkl形式存放，如果没有此文件夹会报错，在没有pkl文件时，执行eval的时候会执行到
=========== Offline support features are generated. ===========
============ Few-shot object detetion will start. =============
就停止了，这是因为在eval中，如果没有检测到pkl，会认为支持集特征还没有被处理过，因此会执行支持集的处理，最终保存到pkl文件中，见源码(fsod_rcnn.py init_model()函数)：
if(没找到pkl)：
# 上面生成了support_dict
# support dict 结构：
# {"res4_avg":{{类别id：tensor(1*1024*1*1)},{},{},{}..类别个..{}}
# "res5_avg":{同上}}
with open(support_file_name, 'wb') as f:
pickle.dump(support_dict, f)
self.logger.info("=========== Offline support features are generated. ===========")
self.logger.info("============ Few-shot object detetion will start. =============")
sys.exit(0) #这里直接跳出了
else:# 找到了
# 执行后续。。。。。。。。。。。。。。
七、其他
all.sh里面有执行训练和验证的代码，fsod_train_net.py为训练的主函数。
总结
主要分析了一下FewX的工程组成，方便阅读源码和学习detectron2的运作方式。
