zoukankan      html  css  js  c++  java
  • 如何快速选择最合适的物体检测框架:一个基于深度学习物体检测算法的简单测评

    本文的主要内容来自于Google的一篇2017年的CVPR论文,“Speed/accuracy trade-offs for modern convolutional object detectors”,这篇文章从各种不同的角度比较了现今几大流行的深度学习检测算法,即Faster RCNN,SSD和R-FCN。研读下来,感觉受益匪浅,因此写了这篇论文笔记,结合自己的一些检测方面的经验,对学习过的几个检测算法做一下浅显的分析。

    Google这篇文章的厉害之处在于它把所有这些检测算法都在新出的TensorFlow Object Detection API中实现了一遍,所以整体比较起来才有公平性可言。我会参照这篇文章的思路从各个检测算法的结构,算法的性能,算法的视觉效果等三个方面对它们进行分析。有疏漏和错误的地方还望大家指正。

    各大物体检测算法的结构回顾

    1. Faster RCNN

    Faster RCNN具体可以分成两段(如图1所示),一段是所谓的Region Proposal Network (RPN),它可以接受一张任意size的图片作为输入,然后输出一组长方形的proposals,每个proposal都会有一个是否包含物体的score。另一段是最终的box classifier和box位置的refinement,它会使用第一段提供的box proposals的位置来在同样一张feature map上crop相应的features,这些features会作为最后神经网络判断出物体检测位置和可信度的输入。

    图1
    【Proposal Generator】
    具体RPN是如何生成这些region proposal的呢?

    1. 实际上还是老一辈物体检测系统的思路,用Sliding Window,但是是在conv feature map上使用,这里的conv feature map来自最后一层可以共享的conv layer,比如在VGG-16中就是第13层的输出feature map。
    2. 每个Sliding Window都是一个nxn的全连接window,比如说是3x3的window,然后把每个window映射到一个低维向量上去(VGG-16是512维),这里一个3x3的window可能在输入原图中代表了一块很大的区域(VGG-16是228个像素)。
    3. 第二步中的向量会作为两个全连接层的输入,即box-regression层和box-classification层。
    4. 在每个Sliding Window的位置,都会预测k个region proposals,所以box-regression layer会有4k个坐标的输出,而box-classification layer会有2k个输出(包含物体的score和不包含物体的score)。这里值得一提的是k个proposals实际上就是所谓的anchors,每个anchor都是以sliding window的中心为中心,在长宽比率上不同的reference box,faster rcnn采用的是9个不同比率的anchors。RPN整体的示意图见图2。

    图2
    【Box Classifier】 
    为何Faster RCNN的速度和box proposals的数量是正相关的?

    实际上从相同的feature map上crop所需要的box proposal的features已经很大程度上避免了重复计算,但是用于后续的卷积神经网络的预测的计算流程没有省略,因此有多少个proposal就得有多少次box classification和box refinement,所以直接影响整体的运行时间。

    2. SSD (Single Shot Detector)

    实际上SSD目前已经不单指某一篇文章的物体检测结构,而是指所有的利用单个卷积神经网络预测物体的类别和位置偏移量的物体检测框架,这些框架只需要走一次前向传播,不需要类似Faster RCNN的对每个Proposal的分类和预测,SSD整体的结构见图3所示。

    图3
    【SSD的一些特点】

    1. 针对不同尺度的物体,SSD设计了multi-scale的feature maps。
    2. 每一个新增的feature map都可以预测出一系列设定好的检测结果。
    3. 每一个设定好的检测都来自于默认大小和比例的anchor,只要预测出相应的物体类别score和位置相对于中心的偏移量就行了,见图4所示。

    图4
     
    3. YOLO (You Only Look Once)

    YOLO的整体结构如图5所示,相对于前两者YOLO的模型比较简单。

    图5
    【YOLO整体预测流程】

    1. 首先YOLO把输入图像分割成SxS的小块。
    2. 每个小块负责预测以它为中心的B个bounding boxes和相应的box是否包含物体的score。
    3. 同时,在另一条链路中每一个小块也负责预测出这个小块包含的某个具体物体类别的score。

    4. 综合前三步,在预测阶段只需要把2和3得到的score相乘就可以得到具体的bounding box位置和相应的某个物体的score。

    【YOLO存在的问题?】

    虽然YOLO的结构简单易懂,但它也面临着简单结构所带来的一系列弊端,比如对小物体的检测和相邻非常近的物体的检测效果糟糕,再者对于形状很不规则的物体无法很好的用小块去描摹。

    4. R-FCN (Region-based Fully Convolutional Networks)

    R-FCN更像是Faster RCNN的一个改进版(如图6所示),与其像Faster RCNN一样从相同的feature map上去crop proposals,再去进行回归和预测,不如直接让feature map向前传播到最后一层全连接层之前,然后在这上面crop features,这样大大减少了每个proposal需要进行的计算。

    图6
    【R-FCN的具体细节】

    1. 第一部分和Faster RCNN一样,还是RPN去产生proposals。
    2. 第二部分和Faster RCNN不同,直接经过卷积层产生k*k个position-sensitive score maps,每个score map包含了所有不同类别物体的scores。比较典型的是取3*3个类别,分别代表top-left,top-center,top-right,...,bottom-right(如图7所示)。
    3. 设置这样一种position-sensitive score map的原因,一是为了减少每个proposal需要的计算量,二是为了体现这样一个思想,即“每个box都必须产生一个能够衡量当前box和ground truth box重叠程度的score”(示意图见图8)。

    图7
    图8
     
    各大物体检测算法的性能以及效果分析

    这里文章里采用的feature extractor的配置主要是以下几种:

    1. VGG-16
    2. Resnet-101
    3. Inception V2
    4. Inception Resnet
    5. MobileNet

    我们将会从整体的Accuracy vs Time,各个feature extractor的影响,物体大小的影响,图片大小的影响,proposal数量的影响以及GPU / CPU memory的影响等等角度对第一部分详述的三种检测算法进行比较,YOLO暂时排除在外。

    【Accuracy vs Time】

    总体而言R-FCN和SSD要比Faster RCNN更快,而Faster RCNN整体而言要更准。从图9的左下角来看,SSD Inception和SSD MobileNet是最快速的两种配置,而从右上角来看,Faster RCNN Inception-Resnet是最准也最慢的配置。文章的作者也通过这张图发现了一个所谓的拐点,即R-FCN Resent和Faster RCNN Resnet取得了最好的速度和准确度的平衡(如图9)。

    图9
    【图片大小的影响】

    整体而言,图片越大,检测的速度越慢,效果也越好。这个结论也是很直观的,因为更大的图片意味着更多的小物体会有机会被检测到(如图10)。

    图10
    【物体大小的影响】

    基本上所有的物体检测算法都在大物体上表现的更好,而SSD会在小物体的检测上有明显的缺陷(如图11)。

    图11
    【不同Feature Extractor的影响】

    这里的结论也是很直观的,除了SSD比较特殊外,越复杂的,在分类领域效果越好的feature extractor,在检测任务上的表现也越好(如图12)。

    图12
    【Proposal数量的影响】

    作者通过图13发现,的确越少的proposal会带来越少的计算时间,但是相应的准确度确没有下降那么快,50个proposals相较100个proposals只带来了几个百分点的准确度下降,这一点是值得关注的,即实际场景中没必要设置过多的proposal数量(如图13)。

    图13
    【GPU/CPU Memory的影响】

    基本上越复杂的feature extractor加上越复杂的检测算法,会带来更多的memory消耗(如图14)。

    图14
     
    各大物体检测算法的视觉效果

    这里我提供两组比较图像,一组来自作者的论文(图15),另一组来自我自己的运行结果(图16),可以明显的发现SSD对于小物体的检测比较不理想,而R-FCN和Faster RCNN的Recall都是比较高的。

    图15
    图16
     
    总结

    Google那篇文章的作者和我的目的都是希望给大家在实际场景中选择检测算法提供一些参考,比如大物体如何选,小物体如何选,是选快的还是选慢的等等。当然出现疏漏和错误还是希望大家多指正。

    引用
    [1] J. Huang, V. Rathod, C. Sun, M. Zhu, A. Korattikara, A. Fathi, I. Fischer, Z. Wojna, Y. Song, S. Guadarrama, and K. Murphy. Speed/accuracy trade-offs for modern convolutional object detectors. In CVPR, 2017.
    [2] S. Ren, K. He, R. Girshick, and J. Sun. Faster r-cnn: Towards real-time object detection with region proposal networks. In Advances in neural information processing systems, pages 91–99, 2015.
    [3] W. Liu, D. Anguelov, D. Erhan, C. Szegedy, S. Reed, C.- Y. Fu, and A. C. Berg. Ssd: Single shot multibox detector. In European Conference on Computer Vision, pages 21–37. Springer, 2016.
    [4] J. Redmon, S. Divvala, R. Girshick, and A. Farhadi. You only look once: Unified, real-time object detection, 2015.
    [5] J. Dai, Y. Li, K. He, and J. Sun. R-fcn: Object detection via region-based fully convolutional networks, 2016.

  • 相关阅读:
    网络安全分析
    java实现 洛谷 P1464 Function
    java实现 洛谷 P1464 Function
    java实现 洛谷 P1014 Cantor表
    java实现 洛谷 P1014 Cantor表
    java实现 洛谷 P1014 Cantor表
    java实现 洛谷 P1014 Cantor表
    java实现 洛谷 P1014 Cantor表
    java实现 洛谷 P1540 机器
    java实现 洛谷 P1540 机器
  • 原文地址:https://www.cnblogs.com/alan-blog-TsingHua/p/10064960.html
Copyright © 2011-2022 走看看