human_pose_estimation_demo的再進一步研究

此次研究的主要是速度問題，後來還得到了其它方面的收穫。

一、原始的抽幀

      對於這樣一個問題，想提升速度，可以想到的最簡單、最直接的方法就是「 抽幀」。好比添加一個計數器

這裏，只有當SumofFrames達到FRAMEBLOCK的時候，才進行下面的圖像處理，不然只是顯示圖像自己而不處理。

可是這樣作，獲得的結果很詭異，就是這我的走走停停的。

這樣想來，這個圖像處理的過程，仍是不能放到主線程中去，仍是要獨立出來。

就是起碼要2個線程。這個時候Console程序的能力就不夠了，因此開始修改GOMFCTemplate。

二、對human_pose_estimation_demo結構的進一步理解

當我開始移植 human_pose_estimation_demo到GOMfcTemplate中的時候，才發現它的結構化方法提供了很是多的便利：

引入它的文件

 

 

執行它的過程

就能夠。

固然看上去簡單，細節仍是不少的，這個放到第4個部分來說。

三、Dshow提供的加成

當我花了一番心思把算法移植過來，準備開始搞「2線程」的時候，測試發現速度已經有了明顯的提高：

注意，這裏已經將視頻設置成了1920*1080的原始大小。能夠看到，最上面的VCam是虛擬攝像頭，它比較流暢，而GOMfctemplate裏面的算法處理也是比較快的， 而且DShow自動進行了抽幀處理！原理我尚未考證，可是結果看上去是這樣的，這也是採用專業基礎庫的紅利吧。

這樣，我就不研究雙線程了……等到後面有須要的時候再研究。這裏實現的功能已經符合個人預期。

四、注意事項

a、由於OpenVINO的緣由，全部的項目不要放在有中文和空格的地方；

b、正確設置分辨率進行測試，不然小分辨率測試不出來什麼效果；

c、 matU8ToBlob  等函數在引用過來的時候會批量報錯，須要改寫。