human_pose_estimation_demo的再进一步研究

这次研究的主要是速度问题,后来还获得了其它方面的收获。

1、原始的抽帧
      对于这样一个问题,想提高速度,能够想到的最简单、最直接的方法就是“ 抽帧”。比如添加一个计数器
www.wityx.com
这里,只有当SumofFrames达到FRAMEBLOCK的时候,才进行下面的图像处理,否则只是显示图像本身而不处理。
但是这样做,得到的结果很诡异,就是这个人走走停停的。
这样想来,这个图像处理的过程,还是不能放到主线程中去,还是要独立出来。
www.wityx.com
就是起码要2个线程。这个时候Console程序的能力就不够了,所以开始修改GOMFCTemplate。
2、对human_pose_estimation_demo结构的进一步理解
当我开始移植 human_pose_estimation_demo到GOMfcTemplate中的时候,才发现它的结构化方法提供了非常多的便利:
www.wityx.com
引入它的文件
 
www.wityx.com
 
执行它的过程
www.wityx.com
就可以。
www.wityx.com当然看上去简单,细节还是很多的,这个放到第4个部分来讲。
3、Dshow提供的加成
当我花了一番心思把算法移植过来,准备开始搞“2线程”的时候,测试发现速度已经有了明显的提升:
www.wityx.com
注意,這里已经将视频设置成了1920*1080的原始大小。可以看到,最上面的VCam是虚拟摄像头,它比较流畅,而GOMfctemplate里面的算法处理也是比较快的, 并且DShow自动进行了抽帧处理!原理我还没有考证,但是结果看上去是这样的,这也是采用专业基础库的红利吧。
这样,我就不研究双线程了……等到后面有需要的时候再研究。这里实现的功能已经符合我的预期。
4、注意事项
a、因为OpenVINO的原因,所有的项目不要放在有中文和空格的地方;
b、正确设置分辨率进行测试,否则小分辨率测试不出来什么效果;
c、 matU8ToBlob  等函数在引用过来的时候会批量报错,需要改写。
 

猜你喜欢

转载自www.cnblogs.com/xyy2019/p/11778032.html