human_pose_estimation_demo的再进一步研讨

此次研讨的主如果速率题目，厥后还获得了别的方面的收成。

1、原始的抽帧       关于如许一个题目，想进步速率，能够想到的最简朴、最直接的要领就是“ 抽帧”。比方增加一个计数器 这里，只有当SumofFrames到达FRAMEBLOCK的时刻，才举行下面的图象处置惩罚，不然只是显现图象自身而不处置惩罚。 然则如许做，获得的结果很诡异，就是这个人走走停停的。 如许想来，这个图象处置惩罚的历程，照样不能放到主线程中去，照样要自力出来。 就是最少要2个线程。这个时刻Console顺序的才能就不够了，所以最先修正GOMFCTemplate。 2、对human_pose_estimation_demo构造的进一步明白 当我最先移植 human_pose_estimation_demo到GOMfcTemplate中的时刻，才发明它的构造化要领供应了异常多的方便： 引入它的文件     实行它的历程 就能够。 固然看上去简朴，细节照样许多的，这个放到第4个部份来说。 3、Dshow供应的加成 当我花了一番心机把算法移植过来，预备最先搞“2线程”的时刻，测试发明速率已有了显著的提拔： 注重，這里已将视频设置成了1920*1080的原始大小。能够看到，最上面的VCam是假造摄像头，它比较流通，而GOMfctemplate内里的算法处置惩罚也是比较快的， 而且DShow自动举行了抽帧处置惩罚！道理我还没有考据，然则结果看上去是如许的，这也是采纳专业基本库的盈余吧。 如许，我就不研讨双线程了……比及背面有须要的时刻再研讨。这里完成的功用已相符我的预期。 4、注重事项 a、由于OpenVINO的缘由，一切的项目不要放在有中文和空格的处所； b、准确设置分辨率举行测试，不然小分辨率测试不出来什么结果； c、 matU8ToBlob  等函数在援用过来的时刻会批量报错，须要改写。