基于TF对象检测API的城市交通标志无框或掩码检测

Question

我要感谢所有关于这方面的想法、技巧或链接：

使用TF 1.10和最近的对象检测-API (github，2018-08-18)，我可以使用PETS数据集以及我自己的概念数据集证明来进行盒和掩码预测：

​

但是，当我在城市景观交通标志(单班)上进行训练时，我很难取得任何成绩。我调整了锚，以尊重小得多的物体，似乎RPN正在做一些至少有用的事情：

​

无论如何，盒子预测器根本不起作用。这意味着我根本没有收到任何盒子

我的管道很大程度上甚至和样本吐露完全一样。因此，我预计数据的特定类型会出现问题，或者会出现错误。

你有什么技巧/链接如何(或者)

• 当使用2或3个阶段时，可视化RPN结果？(只使用一个阶段就能做到这一点，但一个阶段会如何迫使这一点呢？)
• 先训练RPN，然后再用箱子继续训练？
• 调查箱子在哪里/为什么丢了？(使用零分数进行预测，而评估则产生零分类错误)

Answer 1

最后，解决办法是将多个问题结合起来：

​

​

• 参数from_detection_checkpoint: true被折旧，并由fine_tune_checkpoint_type: 'detection'代替。但是，如果没有这些，框架似乎默认为'classification'，这似乎破坏了对象检测框架的整个思想。这次依赖默认值是没有什么好主意的。
• 我的数据准备得不够好。我有零宽度+/高度的盒子(不管是什么原因)。我还为断开连接的实例摘掉了掩码。
• 将keep_aspect_ratio_resizer与random_crop_image和random_coef: 0.0一起使用似乎不允许完全解析，因为调整大小似乎是在随机裁剪之前应用的。为了节省内存，我现在将输入图像分割成(垂直)条，并使用一个小的random_crop，这样它就不会跳过小特性了。此外，我现在可以允许一个max_area: 1和一个随机系数> 0，因为内存使用被处理。
• 一个潜在的问题也产生于这样一个事实:我只考虑了一个类(到目前为止)。这可能对框架或网络中的激活功能都是一个问题。然而，结合其他问题，这一变化似乎没有引起额外的问题--至少是这样。
• 最后，但并非最不重要的是，我更新了2018-10-02的来源，但没有经过详细的修改。

我希望别人能从我的发现中节省时间和麻烦。