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

複数台のKinectV2の使い方