メモです。
チラシの裏です。
表題の通りです。
opencv_traincascade.exeのソースコードを見たらTBBを生で使ってマルチスレッド処理をしてましたので、これだけのためにTBB込みのビルドをしたら、とてもはかどりました。
-precalcValBufSize と -precalcIdxBufSize もデフォルトですと1024なのですが、これを4096とかにすると、さらにはかどりました。
OpenCV3では、パラレルフレームワークはラップされており、特にWindowsでは、TBBはあんまり早くないということで、この頃はCMAKEオプションに入れませんし、デフォルトでOFFですが、こういうコードも残っているのですね。
しかしながら、コード修正したり、PRしたりする実力はないので、場当たり的にTBBを有効にして対処しました。
世の中3.3なのに、HAVE_TBBとかおくれてますねえ。
私が試した感じでは、正解1000枚、不正解230枚くらいで15ステージだと、メモリのサイズを大きくすると時間が半分くらいになり、さらにTBBを使うとその3/4くらいになります。
さらに場当たり的なことを思いつきました。opencv_traincascade.exeだけTBBを有効にしてコンパイルしたら良いかも！(ソースコードは触りたくない男！)
さらにJPEGをTurboJPEGに差し替えたり、ZLIBをアセンブラつかっているバージョンに差し替えればさらに幸せになれそう！
ということで、ZLIBとJPEGを差し替え、opencv_traincascade.exeだけTBBを有効にしてチャレンジしたら、また少し早くなりました。20ステージで32分だったのが24分になりました。
しかし、こんな場当たり的なやり方では、
・ZLIBを差し替えたからPNGの展開が早くなった
・LIBJPEGを差し替えたからJPEGの展開が早くなった
・OPENCVのライブラリは標準のパラレルが効いていて、かつopencv_traincascade.exeではTBBが効いているので早くなった
どれが効いたのか全くわかりませんね。。場当たり的で、なんとなく早くなったという、インドの究極奥義バータリーと言えます。
思いつきでなんとなくウマくいったという話です。
ご参考まで。