Transcript

• 1. 複数台のKinectV2の使い方 福嶋 慶繁 名古屋工業大学 1 2015/3/21 第35回 名古屋CV/PRML勉強会
• 2. 注意事項 2 Kinectは「ナチュラルユーザーインターフェース」 しかし，主な機能である • ジャスチャー認識したり • 人を検出したり • ボーンとったり といった代表的な機能に私は 触ったことがほぼありません（笑）
• 3. Kinect V2 3  RGB 1920x1080  Depth 512x424  FPS 30  接続端子 USB3.0 TOF形式の安価なデプスセンサー
• 4. Kinect V2の通信容量と制限 4 接続台数上限は１PCに1台に制限？ 必要な大域幅は (1920ｘ1080ｘ24bit + 512x424x16bit) x 30fps =1.597Gbps ※USB3.0は５Gbpsまで
• 5. 対策 5 たくさん接続するために，PCクラスタを構築し 高速なネットワークと符号化をうまく使いましょう • １０GbEのハブ 10万円 • １０GbEのNIC 5万円 • 安めのPC 5万 • 手間隙 プライスレス ※通信機器だけでも本体よりも高い
• 6. システム構成 圧縮・通信 キャリブレーション 目次 6
• 7. システム 7
• 8. システム構成イメージ 8 USB3.0 10GbE RGB: JPEG 8bit Depth:LZ4 16bit Clients Server Imaged decode (CPU) Rendering (GPU) 10GbE Hub Kinect V2(s)
• 9. PCクラスタ 9 システムは カメラ付でアシンメトリックなPCクラスタ 複数台のクライアントと中央のサーバで 効率的な負荷分散！ • 重たい処理はクライアントで並列処理 • 符号化などの並列に不向きな処理はCPUで • レンダリングはGPUで
• 10. 符号化 10
• 11. Kinect V2の通信容量と制限（再掲） 11 デプスの符号量はたいしたことが無い？ 必要な大域幅は (1920ｘ1080ｘ24bit + 512x424x16bit) x 30fps ＝1.493 Gbps + 0.104 Gbps =1.597Gbps ※USB3.0は５Gbpsまで
• 12. RGB画像 非可逆圧縮でOK（JPEG，H.264/AVC，H.265/HEVC） 人間の目にとって自然であればOK 圧縮効率大 デプスマップ 自然画像の非可逆圧縮は，符号化後に再変換するポス トフィルタが必要なため実時間処理には向かない 可逆圧縮が望ましい（ZIP，PNG） 圧縮効率小 RGB画像とデプスマップの符号化特性 12
• 13. 動画像の圧縮形式 13  Motion-JPEG：携帯  ＭＰＥＧ２：ＤＶＤ，テレビ  ＡＶＣ：ブルーレイ，ワンセグ  ＨＥＶＣ：次世代コーデック
• 14. モーションJPEG 高効率な非可逆圧縮 FullHDを13msでエンコード，11.2msでデコード 圧縮率 3.83％（品質80） 1493 Mbps → 57.2 Mbps デプスマップは非圧縮で104Mbps RGB画像のM-JPEG圧縮 14
• 15. 可逆圧縮は基本的には重たい 軽くて早いのを！ 候補一覧 RAW PNG(RLE) JPEG-LS DPCM+LZ4 デプスマップの可逆圧縮 15
• 16. 圧縮しない形式 104Mbpsで通信しても問題ないならこれでOK 計算の負荷は最小 RAW 16
• 17. 代表的な画像の可逆圧縮フォーマット 予測変換（フィルタ）＋zip圧縮（RLE） フィルタの種類 • Sub：左，Up：上，Average：左と上の平均， Peath：左，上，左上との差分，None：なし 圧縮の種類（zipのオプション，OpenCVでも選択可能） • DEFAULT→Deflate • FILTERED • HUFFMAN_ONLY • RLE • FIXED PNG 17 http://optipng.sourceforge.net/pngtech/z_rle.html
• 18. Run Length Encoding (RLE) 18 A A A A A B B B B B B B B B A A A A 5 B 9 A 3 何個連続するかで短く符号化する方法 Run Length Encoding（ランレングス符号化）
• 19. RLEの特徴 19  FAXなどで使われる符号化方式  速い  必ずしも短くなるとは限らない （全く連続していない文字列は2倍の長さになる） ex １２３４５６７８→１１２１３１４１５１６１７１８１
• 20. RLE の派生 20  Zero RLE：ゼロが何個連続するかで符号化  ゼロに集中する変換を施し，ゼロの符号長だけ短く することで高い符号化効率を達成可能  Switched RLE：RLEを使うかどうかを切り替える  ０が続かないときに得をする方法
• 21. OpenCVによる詳しいpng圧縮 21 void encodePNG(InputArray src, vector<uchar> buff) { vector<int> param(4); param[0]=IMWRITE_PNG_COMPRESSION; param[1]=9;//1-9 param[2]=IMWRITE_PNG_STRATEGY; //DEFAULT, FILTERED, HUFFMAN_ONLY, FIXED param[3]=IMWRITE_PNG_STRATEGY_RLE; imencode(".png", src, buff, param); }
• 22. マイナーな可逆圧縮方式 LOCO-I で予測 ゴロム・ライス符号＋スイッチトRLEで圧縮 CharLSの実装が速い http://charls.codeplex.com/ JPEG-LS（ Lossless JPEG） 22
• 23. JPEG2000 23 マイナーな（略)
• 24. WebP 24 マイ（略)
• 25. LZ4 -Extremely fast compression- 25 https://code.google.com/p/lz4/ 極限まで高速な可逆圧縮符号化方式 zipよりも圧縮効率が少し悪いが，とにかく速い DPCM（前方予測）と組み合わせることで かなり高速な符号化が可能
• 26. PNG+Default 356ms, 36.8% 36.8 Mbps PNG+RLE 14ms, 37.7% 36.8 Mbps JPEG-LS 9ms, 28.8％ 28.8bps DPCM＋LZ4 2.4ms, 66.7% 66.7 Mbps 可逆符号化まとめ 26
• 27. 通信 27
• 28. TCP パケット落ちない パケットの順番が変わらない 速度が可変かつ遅い（様々な制御を含むため ） UDP パケット落ちる パケットの順番が変わる 最速（全力） TCPとUDP 28
• 29. ローカル環境とUDP 29 ローカル環境ではパケットは ほぼ落ちない＆ほぼ順序も入れ代えも無い UDP＋自分で簡単な制御 （バッファにためて順序制御など）
• 30. キャリブレーション 30
• 31. カメラの内部パラメータ，外部パラメータを求め る方法 焦点距離，光学中心，レンズ歪 位置，姿勢 OpenCVに実装あり カメラキャリブレーション 31
• 32. RGB，IRカメラの内部パラメータ 焦点距離，光学中心，レンズ歪 外部パラメータ RGBカメラ-IRカメラ間 多視点カメラ間（RGB-RGB間） • RGBーIR間，多視点間は，ステレオキャリブレーション関数を使 えばOK IRカメラ，デプスマップ間 • キャリブレーションで得たIRカメラのXYZ座標とデプスマップの XYZ座標は異なる． キャリブレーションすべきパラメータ 32
• 33. GetDepthCameraIntrinsics 内部パラメータを取得 GetDepthFrameToCameraSpaceTable デプスをRGB画像へ飛ばす Kinect for Windowsの関数群 33
• 34. 実は簡単？ 34 理想的には，すてべのKinectにおいて，RGBカメラに デプスマップをマップした後，RGBカメラ間の多視点 カメラキャリブレーションをすれば，完了． ※ただし，誤差がひどい（なんで？）
• 35. Camera Setup 35
• 36. IR画像を用いて2台のKinectをキャリブレーション し，デプスマップを使って反対側の画像へ射影 RGB画像上にデプスマップをKinectの関数を使って マップし，RGB画像を用いて２台ののKinectをキャ リブレーションし，マップされたデプスマップを 使って反対側の画像へ射影 キャリブレーション環境 36
• 37. 左カメラ（IR） 37
• 38. 右カメラ（IR） 38
• 39. 左カメラ（RGB） 39
• 40. 右カメラ（RGB） 40
• 41. センサとキャリブレーション結果のずれ 41 y = 1.0261x + 2.5975 1000 1500 2000 2500 1000 1500 2000 2500 キャリブレーションのｚ値 センサのｚ値 オフセットと定数倍のずれ．
• 42. XYZとRGBの値を持つ点群データ 画像上にRGB-Dのデータがあれば変換可能 デプスマップをRGB画像の座標系へレジストレーション する必要性 解像度変換：512x424 →FullHD 位置あわせ：視点位置を合わせる ー懸念事項ー レジストレーション＆アップサンプルは いつするの？ ポイントクラウド 42
• 43. 取得直後にレジストレーション XYZRGBを圧縮（24bit（色）+96bit（座標）の情報） • 符号化効率は最悪といって良い • PCLの圧縮はただのサブサンプル 通信後にレジストレーションとアップサンプル RGB画像とデプスマップを圧縮 • 符号化効率は最大 • サーバでレジストレーションとアップサンプルをする必要性 取得後にレジストレーションだけ レジストレーション＋穴埋めをして符号化 サーバ側でアップサンプル • 上記よりも負荷分散に優れ符号化効率も問題ない レジストレーションと符号化効率 43
• 44. RGB画像 モーションJPEGで圧縮 デプスマップ 1. RGB視点にレジストレーション（後述） 2. 穴埋め 3. DPCM＋LZ4で圧縮 4. 高解像度ガイド情報付のアップサンプル ポイントクラウド符号化の手順 44
• 45. デプスマップの解像度をRGB画像の大きさに拡大 デプスマップの特性を失わないように拡大 輪郭がぼけない RGBの輪郭はエッジと一致 NN Upsampling ただの最近傍法．2ms．KinectV2のマッピングはこれ． Joint Bilateral Upsampling RGB画像の情報をガイドにしてエッジ保持をした拡大 アップサンプル 45
• 46. Joint Bilateral Upsampling 46 高解像度の色情報をガイド にして補間する値を決定 処理速度 40ms（CPU）
• 47.  RGB画像が57.2Mbps デプスマップが66.7Mbps １０００/（57.2+66.7）≒８台 1GbEで何台までいける？ 47 ※１Gbpsの理論値に近いスペックがでるNICは非常に高い ボトルネックは デコードとアップサンプル時間 帯域は圧縮により，結構な台数を連結可能
• 48. RGB画像1枚：11.2ms デプスマップ1枚：1.3ms+40ms すべてシングルコア処理 8コアのマシンであれば，理想的に分割されるとしても5 台までしか処理不可能 GPUでアップサンプラーを作る必要性 クライアントで半分，サーバーで残りをアップサンプル するとか？ NN upsampleなら可能 計算時間見積もり 48
• 49. 負荷をどこにかけるか考えよう 圧縮 アップサンプル レンダリング キャリブレーション なんでずれてるんでしょう？ • TOFのデプス“値”のレンズディストーションって，どうなる のが正しいのでしょうか？ • エッジが歪むのはわかるのですが，値自体も曲がるのでしょ うか？ まとめ 49
• 50. 50
• 51. マウスとキーボードのネットワーク共有ソフト http://synergy-project.org/?hl=ja 2画面ディスプレイのように複数台のマシンを使用可能 隣の画面にマウスを持っていけば隣のマシンのウィン ドウを操作可能 いろんなOSを混ぜることも可能！ • クライアントWindows 8 サーバーLinuxな環境も Synergy 51 左で右のマシン“も“操作可能 LAN
• 52. そのままキャプチャすると左右反転 52