热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

pytorchyolov3代码详解_6.YOLOv3与RFSong在人手检测数据集的对比

前言:上一篇文章说到了自己最近学习的YOLO剪枝项目,自己的复现效果不是很理想,水平太菜了,还得多学学相关知识再去调调看&#

前言:

上一篇文章说到了自己最近学习的YOLO剪枝项目,自己的复现效果不是很理想,水平太菜了,还得多学学相关知识再去调调看:

Lam1360/YOLOv3-model-pruning​github.com
73cf79c7291fbf3aeae97ac4a8a99db3.png

之前自己将YOLO架构放到SSD上进行了实验比较,这一篇文章则是直接对比YOLOv3及其剪枝与自己行人检测文章改进的RFSong,看看YOLO进行剪枝之后的效果与RFSong相比究竟如何。

数据准备:

首先还是看看网络输入为448GT框的分布情况:

2a8ebf78f45a2ea444c62ab6a3c1b47f.png

分析可得:

  1. 主要是中小目标,,因此可以适当减少检测层数目,适当增大网络的输入分辨率。这里我就去掉最后两个检测层了,实现了下采样64倍,因此输入分辨率可以设置为64的倍数,这里为了方便跟yolo416进行比较,网络输入分辨率设置为了448.
  2. 比例变化较大,从0.3-3都有,因此比例得稍微多设置一些

具体配置如下:

ee274dbd7ecf70e51e076543a99e0529.png

自己还利用kmeans聚类进行了SSD的anchor设置尝试

lars76/kmeans-anchor-boxes​github.com
2e0d4d327859d2d7e4814282aff3f0e1.png

聚类出来后的设置如下,感觉聚类出来的anchor尺度变化更小一些了,而且好像不太能体现SSD的多尺度检测了。效果也大打折扣,降了1.2个点,还不如自己根据GT框分布自己大概设置。

VOC_Config = {'feature_maps' : [56, 28, 14, 7],'min_dim' : 448,'steps' : [8, 16, 32, 64],'anchor_sizes' : [[12.1, 15.8, 20.7, 22.3],[26.2, 26.6, 32.0, 33.2],[34.4, 40.7, 42.9, 50.9],[59.9, 65.4, 86.1, 127.3]],'aspect_ratios' : [[0.64, 0.74, 0.65, 1.22],[0.53, 0.80, 1.34, 0.81],[0.55, 0.74, 1.27, 0.69],[1.34, 0.73, 0.98, 0.83]],'variance' : [0.1, 0.2],'clip' : True,
}

RFSong网络:

c73eb69719517b7f9e0c63d995d2f0d6.png
只有四个检测层,下采样了64倍,因此支持64倍的输入

网络在行人检测代码RFSong7993上进行了修改,因为发现0.99MB版本与这个版本速度测出来都是200FPS(发现是推理时间0.99MB版本稍快一点点,但是由于精度下降,NMS处理的时间增加了),这也说明通道减少有时候对模型的加速还是有限的:

songwsx/RFSong-7993​github.com
5866c6090096b2b04970a76fd1daa4f4.png

这里由于还去掉了最后的一些卷积层,虽然输入分辨率从300变为了448,速度应该也还是非常快的。

这里调参的一个重要的地方就是匹配的iou阈值调低,这样对于小目标更加友好,匹配更多小目标进行训练:

f0e69cdfaf970d7700b70600f6fbddd9.png

实验结果:

速度对比:

YOLO v3剪枝项目的介绍:

用 YOLOv3 模型在一个开源的人手检测数据集oxford hand上做人手检测,并在此基础上做模型剪枝。对于该数据集,对 YOLOv3 进行 channel pruning 之后,模型的参数量、模型大小减少 80% ,FLOPs 降低 70%,前向推断的速度可以达到原来的 200%,同时可以保持 mAP 基本不变。

需要注意的是,项目代码的速度均是直接随机产生数据进行模拟输入,这样得到的推理速度不是真正的速度。因此前向推理速度达到两倍的话,速度上肯定还是RFSong胜出。

精度对比:

ea40a19e42e6465844e5c5c732b4a9aa.png

作者达到的精度是77.5,自己经过多次调参,终于从一开始的72达到了77.7,不过非常不稳定,也就出现一次77.7。不过群里朋友有经过剪枝达到79.1的,虽然剪的比较少一些。因此,YOLO的最好成绩是79.1。

利用自己修改的的RFSong,则比较稳定的能达到79.5,精度上也还是RFSong略高一点。

c6eda0284d79537414c15198e8394052.png

train from scratch对比:

自己对YOLO适当删减通道后进行了从头训练,最高只能达到50的AP,感觉YOLO从头训难度比RFBNet大,不是很方便自己设计,可能得先去coco数据集或者其他检测数据集进行一些预训练。当然这个剪枝的思路也是非常好的,非常感谢作者的开源。

RFSong还是train from scratch的,因此进行修改设计非常的方便,并且在这种比较小的数据集表现依旧很好,就是训练的epoch数目多很多,这里我训练了140个epoch,花了三四个小时。

总结:

YOLOv3效果不如修改的RFSongt好,原因也可能是本身这个Pytorch的YOLO实现精度没有那么好, kevinCK大佬说是没有达到指标。

KevinCK:目标检测——YOLO V3简介及代码注释(附github代码——已跑通)​zhuanlan.zhihu.com
988d7c173918c4d2615b0cc95ae3afd8.png

不过综合来看,RFBNet还是很优秀啊!!自己稍加修改的RFSong在其他数据集上表现也都非常好,还是比较实用的。

本人水平较菜,欢迎大家批评指正,也非常欢迎进群一起交流:云深不知处-目标检测 763679865(代码和模型权重都放在群文件了)

更新:

对下面这个版本的yolov3源码进行了阅读,发现这个源码实现不够完备,不过非常简洁易懂,适合学习:

eriklindernoren/PyTorch-YOLOv3​github.com
4f1efe319a3f7bdc0f6ed8977b07b073.png

实验结果(开启多尺度):78.0

279e98cbca51232c8483801d8cd93de3.png

这个实现之所以没有达到非常好的表现,可能有以下原因:

  1. 数据增广太少,不完整,并且多尺度训练的尺度变化也较小一些(320-512)
  2. 学习率直接默认,没有warm up和decay
  3. loss的加权处理不符合,有些甚至没有设置
  4. anchor匹配策略,这里对应每个yolo层都去匹配一个iou最大的

自己又采用了下面这个yolo实现,这个实现效果更好,推荐使用:

https://github.com/ultralytics/yolov3​github.com

实验结果(开启多尺度):81.5

e90147da08462780139a071ffcda2ee1.png

ultralytics/yolov3实现更加完备一些,效果也比之前的提高了3.5个点,相比RFSong也高了两个点。这也更加符合一般认识,小目标iou0.5下YOLO效果更好一些。



推荐阅读
author-avatar
童T-Aurora
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有