複数台の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

接続台数上限は１PCに1台に制限？

必要な大域幅は

(1920ｘ1080ｘ24bit + 512x424x16bit) x 30fps

=1.597Gbps※USB3.0は５Gbpsまで

対策 5

たくさん接続するために，PCクラスタを構築し

高速なネットワークと符号化をうまく使いましょう

• １０GbEのハブ 10万円

• １０GbEのNIC 5万円

• 安めのPC 5万

• 手間隙 プライスレス

※通信機器だけでも本体よりも高い

システム構成

圧縮・通信

キャリブレーション

目次 6

システム

7

システム構成イメージ 8

USB3.0 10GbE

RGB: JPEG 8bit

Depth:LZ4 16bit

ClientsServer

Imaged decode (CPU)

Rendering (GPU)

10GbE

Hub

Kinect V2(s)

PCクラスタ 9

システムは

カメラ付でアシンメトリックなPCクラスタ

複数台のクライアントと中央のサーバで

効率的な負荷分散！

• 重たい処理はクライアントで並列処理

• 符号化などの並列に不向きな処理はCPUで

• レンダリングはGPUで

符号化

10

Kinect V2の通信容量と制限（再掲） 11

デプスの符号量はたいしたことが無い？

必要な大域幅は

(1920ｘ1080ｘ24bit + 512x424x16bit) x 30fps

＝1.493 Gbps + 0.104 Gbps

=1.597Gbps ※USB3.0は５Gbpsまで

RGB画像非可逆圧縮でOK（JPEG，H.264/AVC，H.265/HEVC）人間の目にとって自然であればOK圧縮効率大

デプスマップ自然画像の非可逆圧縮は，符号化後に再変換するポストフィルタが必要なため実時間処理には向かない可逆圧縮が望ましい（ZIP，PNG）圧縮効率小

RGB画像とデプスマップの符号化特性 12

動画像の圧縮形式 13

Motion-JPEG：携帯

ＭＰＥＧ２：ＤＶＤ，テレビ

ＡＶＣ：ブルーレイ，ワンセグ

ＨＥＶＣ：次世代コーデック

モーション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

１２３４５６７８→１１２１３１４１５１６１７１８１

RLE の派生 20

Zero RLE：ゼロが何個連続するかで符号化

ゼロに集中する変換を施し，ゼロの符号長だけ短くすることで高い符号化効率を達成可能

Switched RLE：RLEを使うかどうかを切り替える

０が続かないときに得をする方法

OpenCVによる詳しいpng圧縮 21

void encodePNG(InputArray src, vector<uchar> buff){

vector<int> param(4);param[0]=IMWRITE_PNG_COMPRESSION;param[1]=9;//1-9param[2]=IMWRITE_PNG_STRATEGY;//DEFAULT, FILTERED, HUFFMAN_ONLY, FIXEDparam[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+Default356ms, 36.8%36.8 Mbps

PNG+RLE14ms, 37.7%36.8 Mbps

JPEG-LS9ms, 28.8％28.8bps

DPCM＋LZ42.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画像を用いて２台ののKinectをキャリブレーションし，マップされたデプスマップを使って反対側の画像へ射影

キャリブレーション環境 36

左カメラ（IR） 37

右カメラ（IR） 38

左カメラ（RGB） 39

右カメラ（RGB） 40

センサとキャリブレーション結果のずれ 41

y = 1.0261x + 2.5975

1000

1500

2000

2500

1000 1500 2000 2500

キャリブレーションのｚ値

センサのｚ値

オフセットと定数倍のずれ．

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 UpsamplingRGB画像の情報をガイドにしてエッジ保持をした拡大

アップサンプル 45

Joint Bilateral Upsampling 46

高解像度の色情報をガイド

にして補間する値を決定

処理速度 40ms（CPU）

RGB画像が57.2Mbps

デプスマップが66.7Mbps

１０００/（57.2+66.7）≒８台

1GbEで何台までいける？ 47

※１Gbpsの理論値に近いスペックがでるNICは非常に高い

ボトルネックは

デコードとアップサンプル時間

帯域は圧縮により，結構な台数を連結可能

RGB画像1枚：11.2ms

デプスマップ1枚：1.3ms+40msすべてシングルコア処理

8コアのマシンであれば，理想的に分割されるとしても5台までしか処理不可能

GPUでアップサンプラーを作る必要性クライアントで半分，サーバーで残りをアップサンプルするとか？

NN upsampleなら可能

計算時間見積もり 48

負荷をどこにかけるか考えよう圧縮アップサンプルレンダリング

キャリブレーションなんでずれてるんでしょう？

• TOFのデプス“値”のレンズディストーションって，どうなるのが正しいのでしょうか？

•エッジが歪むのはわかるのですが，値自体も曲がるのでしょうか？

まとめ 49

50

マウスとキーボードのネットワーク共有ソフトhttp://synergy-project.org/?hl=ja2画面ディスプレイのように複数台のマシンを使用可能隣の画面にマウスを持っていけば隣のマシンのウィンドウを操作可能いろんなOSを混ぜることも可能！

•クライアントWindows 8 サーバーLinuxな環境も

Synergy 51

左で右のマシン“も“操作可能LAN

そのままキャプチャすると左右反転 52