Q&A
AIアクセラレータ使うとか
https://qiita.com/PINTO/items/190daa4fddfd2a21f959
前提・実現したいこと
＜実現したいこと＞
webカメラを使って人(全身)をリアルタイム検出、検出したら矩形を描画するプログラムを
フレームの遅延なく滑らかにしたい。
＜前提＞
・raspberry pi4 model B メモリ4GBを使用
・python3.7、opencv4.5.1を使用
発生している問題・エラーメッセージ
＜発生している問題＞ ・矩形描画部分をマルチスレッドにすると逐次処理より格段に処理が早くなったが、 まだフレームの遅延がある ・マルチプロセスを試したが、処理速度は変わらない上、矩形が描画されない
該当のソースコード
python
試したこと
マルチプロセス(ソースコード中、コメントアウトの部分)を
試したが、処理速度が向上しない上、矩形が描画されない。
補足情報（FW/ツールのバージョンなど）
ここにより詳細な情報を記載してください。
ご教示いただきありがとうございます。
是非検討させていただきます。
ちなみにプログラム面でのこれ以上の高速化やマルチプロセスの適用は困難でしょうか？
一応今後ラズパイのメモリを8GBにしたり、SDを512GBにすることも検討していますが、高速化できるか未知数な状況です。
もしご存知であればご教示いただけますと幸いです。
Python実行中の、CPUの使用率や、メモリーの使用率をモニターしてみてください
メモリーに余裕があるなら、メモリーを増やしても、SDを高速なものに変えても、ほとんど効果ないと思います
メモリーに余裕が無くて、SDのスワップにデータ逃してるなら、メモリー増やしたらそれが無くなるので速くなる可能性はあります
あと、CPUをPythonがどれくらい占有できているか
Python以外のものがまあまあ動いているのなら、それがあまり動かないようにしてPythonの占有率を上げられたら、その分速くなります
>矩形描画部分をマルチスレッドにすると逐次処理より格段に処理が早くなったが、
確認したいことが一点。通常であれば、detectMultiScale が一番時間がかかりそうで、
矩形描画部分は一番処理が早く終わる部分だと思うのですが、
変更前・後でどれくらい早くなりましたか？
（もし、時間を計測してるなら、指数表記の見落としにも注意して見て下さい）
目的が「フレームの遅延」と「秒間フレーム数の確保」で、対処方法が変わってきます。
- detect～の処理にかかる時間を短くしたい → 並列化では改善しません
→ パラメータ調整や、opencv with CUDA、画質もしくは画像サイズを小さくする
遅延を改善することにより、結果としてFPSの改善も見込めます。
- 時間の掛かる処理をバックグラウンドで処理することで、FPSの改善は見込めますが
時間内に処理できるフレームの数が増えるだけで、遅延の時間自体は変わりません。
(ある程度滑らかに動くかもしれませんが、キャプチャから描画迄のラグは変わりません）
jbpb様
ご教示いただきありがとうございます。
ただ今raspberrypiのタスクマネージャーを見ましたところ、
pythonでCPU使用率がほぼ100％となっておりました。
(SDにデータがスワップしているかは見方が分かりませんでした…)
上記の状況の場合、メモリ8GBなどハード面で多少改善は見込めますでしょうか？？
知識が乏しい故申し訳ございません。
teamikl様
ご教示いただきありがとうございます。
時間計測を正確に行ってはおりませんが、
①逐次処理でトライ→ほぼ動かず固まっている
②どこかの処理をマルチスレッドにしてトライ
→試しに描画部分をマルチスレッドにしたら、まともに動くようになった。
(ただしまだ首振りなど、人間の動きに対して処理に遅延がある)
という感じで進めてきた次第です。
他の回答者様もパラメータのことについてアドバイスいただいているので
パラメータ調整はトライさせていただきたいと思いますが、その他最も
重い処理(detectmultiscale)をマルチスレッドにしても遅延は解決しない
という認識で間違いないでしょうか？？
(画像を640×480→320×240にすると検出して矩形描画というアクションが
ほぼ見られなくなりました。検出していないということでしょうか？)
大変申し訳ございませんが、今一度ご教示いただけますと幸いです。
よろしくお願い致します。
> パラメータ調整
大雑把に一まとめにしてしまいましたが、
他にも opencv 自体をビルドする時のオプション、cv2.set で設定可能なプロパティ等々。
ですが、先に問題点を明確にした方が良いと思います。
>重い処理(detectmultiscale)をマルチスレッドにしても遅延は解決しない
という認識で間違いないでしょうか？？
そのはずですが、事実として、固まっていた処理が動くようになったのなら、
私の想定している駆逐処理のコードと違ったか、何か前提に齟齬があるのかもしれません。
各処理毎に、時間を計測すると解ると思います。
補足: 対象の処理は CPU bounce な処理なので、
「マルチスレッド」と「マルチプロセス」の区別は重要ですが、
以下の説明は、マルチプロセスでも同様です。
何処の「遅延」を解決したいか次第ですが、仮に並列化したとして
例えば、１秒かかる処理を４つに振り分けると、全体で秒間４つ処理できますが、
一つ一つの処理を見ると１秒かかる処理は 0.25秒になったりするわけではありません。
フレームに置き換えると、秒間処理できるフレーム数は並列化で改善可ですが、← 再生が滑らかに
１つのフレームに掛かる時間(遅延)は、変わらず一定です ← 遅延には影響しない
並列化で detectmultiscaleの所要時間が高速化するわけではない
提示されてるコードと説明されている状況が一致しないので、
(疑問点: 検出処理detect～の方が時間かかるはずだが、矩形描画draw～の方で改善している）
先に確認を取った方が良いなと思いました。
細かい要素の確認ですが、試したコードと質問に掲載のコードで、
他に違いがあったりはしませんか？
SyntaxError ＞ if __name__ = '__main__':
----
A: 描画はリアルタイムだが、検出される枠の表示にラグがある
(表示されるフレームと、検出結果を描画するフレームの同期が取れていない状態)
B: 描画はスムーズに再生されるが、時間的に遅れて表示されている。(1秒前の映像が映ってるような状態）
C: 描画自体がされず固まっている、再生がコマ送りのような状態 （バッファが溜まったり、処理が追い付いてない状態）
動きに対して遅延があるだと、Aのようなケースでしょうか？
> SDにデータがスワップしているかは見方が分かりませんでした
topコマンドで、メモリーの使用状況の詳細を確認してみてください
https://www.denshi.club/make/2016/02/raspberry-pi12-top.html
https://milestone-of-se.nesuke.com/sv-basic/linux-basic/top-command/
teamikl様
お返事遅くなり、申し訳ございません。
ご丁寧にご教示いただき、ありがとうございました。
ご提示いただいたケースで言うとBのようなケース
(例：手を動かしてみると約1秒後に画像内の手が動くetc)
となっていました。
あとは、今まで画像のサイズ自体を640×480から320×240に落とすと
全身検出がされず、矩形がほぼ描画されない！と思い込んでいましたが、
他の質問者様がおっしゃるようにdetectMultiScaleのパラメータを調整すると
検出もされて、描画も遅延がなくなりました。
マルチスレッドへの知識が浅く、まだ解釈不足もあるかと思いますが、
回答を見てもう一度勉強させていただきたいと思います。
ありがとうございました。
jbpb0様
返信遅くなり申し訳ございません。
ご教示いただきありがとうございます。
topコマンドで確認できました。
ありがとうございました。
回答2件
0
ベストアンサー
話の方向性が違うかもしれませんが，
hog.detectMultiScale(frame, winStride = (8, 8), padding = (32, 32), scale = 1.05)
これの引数を変えてみたらどうでしょうか．
winStride や scale の値を大きくすれば，（検出率は悪くなる方向に向かうだろうけども）処理速度が向上するのではないでしょうか．
（padding についてはそもそも何の値なのかが謎なので影響がわかりません^^ ドキュメント見ても"padding" としか書かれてない…）
あと，（特に何も変わらないかもしれませんが）
cv2.waitKey(10)
ここの 10 は，とりあえず 1 にしておくとか．
投稿2021/06/30 07:41
編集2021/06/30 07:42
総合スコア11996
fana様
ご回答いただきありがとうございます。
私もdetectmultiscale部分につきましては下記のサイトを見て
書いた次第です。(マルチスレッド版の部分)
https://qiita.com/nonbiri15/items/89238c03b672c8f0579f
各パラメーターの意味をもう少し調べて調整してみたいと思います。
ありがとうございます。
あなたの回答
tips
プレビュー
