Kinect: PykinectAzureで骨格情報を取得する

 近年の画像AI技術が発展により、Kinectとかあまり注目されなくなりましたが、おちラボではデプスカメラとしての性能の良さなどに魅力を感じていることから、懲りずに使ってます。

といっても久しぶりな面もあり、最近流行りのPythonでも利用できることから、数あるライブラリの中で、

• PyKinectAzure

というのが使いやすそうです。で、sampleがいくつかあるのですが、骨格情報を取得するsampleがなぜか見当たらなかったので、以下に掲載します。まあ確かにC#やるよりはラクですね。OpenCVに対応するために画像変換もさほど気にしなくて良さそうですし。。

Kinect2 にてFace APIを利用する際の注意事項

Kinect2 にて、Face APIを利用しようとしたら

•  kinect20.dll ....... access violation

というエラーを吐き出して強制終了する場合があります。ここで考えられるエラー原因は次の２点です。

• プラットフォームターゲットが統一されているか？（x86 or x64。もしかするとx64にしておかないとダメかも）
• NUIDatabaseを実行ディレクトリにコピーしておく

特に後者がクセモノですね。

Kinect v2でBodyIndexFrameを利用して人物画像（RGB）を抜き出す

Kinect v2　にて人物画像のみを表示するという初歩的なプログラムを、v1でもやっていたので練習がてらに試してみたのだが、初歩的なところで躓いたところとか、ネットをいろいろググってみて気づいたポイントをピックアップします。

解像度の違いに注意
v1では、Color画像とDepth画像の解像度が同じ（640 x 480）でしたから、Depthで人物領域に対応するColor画像のピクセルを描画するだけで表示できました。しかし、v2 では、Color画像の解像度が（1980×1080）、Depthが（512×424）と大幅に異なるため、描画サイズを気をつけないとおかしなことになります。

抜き出しサイズは512×424
人物領域のサイズが小さいわけですから、基本的にそれにあわせる必要があります。サンプルプログラムでクロマキー処理みたいなことをしてるのがあり、それは横長に写ってるんですが、実際に人物を特定できる領域は512×424と考えたほうがいいです。もちろん、アップスケーリングな処理を自前で実装できるのであればその限りではありません。

座標合わせにDepthFrameが必要
v2では、BodyIndexFrameという人物領域のマスク情報を持った新しいフレームが用意されました。しかし、座標合わせとして、CordinateMapperクラスにBodyIndexFrameに対応するメソッドが用意されていません。

coordinateMapper.MapDepthFrameToColorSpaceメソッド

を利用する必要があります。 つまり、座標合わせにDepthFrameを呼び出しておく必要があります。この辺りのAPIがまだ中途半端ですね。

上記以外はv1と特に変わらない
ネットでいろいろサンプルを調べてみると、ポインターの利用やunsafeな処理をするなど、何やら難しげなのを見かけましたが、基本的にv1でやっていたやり方でOKです（別にポインターの利用やunsafeな処理がダメと言うわけではありません）。v2に変わって何か特別な処理をしなければいけないというわけではないので、安心してください。

下記にサンプルを一部抜粋します。BodyIndexFrameのデータを走査しながら、ColorFrameの内容をコピーしているのがポイントです。

Kinect v2にてMultiSourceFrameを利用する

Kinectプログラミングでは、v1ではAllFrameReadyイベントを用いて各種フレームを一括で処理するのが便利ですが、v2でも同様のイベントがあります。が、名前が変わっており、処理の仕方やメソッド名も違うので注意が必要です。具体的には以下のようになります。

Kinect v2にて骨格情報を取ってくる

Kinect v2にて骨格情報を取ってくる方法です。クラス名に変更がありますが、やり方はほぼ同じですね。

Kinect v2にて人物領域を取得する

Kinect v2ではv1よりフレームワークが変わっているところが所々あります。今回の話は、BodyFrame（人物領域）の取得について。v2からは人物領域だけを格納するBodyFrameというのが新たに用意されました。v1ではDepthFrameからその情報の一部として取得していました。人物だけを表示するには、今までは自前のプログラミングが必要でしたが、その手間がなくなりますね。

kinect v2セットアップ ～PCが対応しているか確認しよう～

ずいぶんネタが古くなりましたがKinect v2のセットアップについてです。製品版がでてずいぶん時間も経ったので、インストールも楽になったかな～とかよくわからん期待をしたのですが甘かったです。。。かなり手間取りました。以下、注意事項です。

マシンの準備
下記のスペックのPCが必要です。

• Windows8.1以上
• CPU：2.66 GHz 以上のデュアルコア、64 ビット (x64) プロセッサ
• GPU：DirectX 11 対応グラフィックス カード
• 接続ポート：USB 3.0
• メモリ：2GB RAM

メモリとCPUのスペックはα版と比べると下がりました。しかし、問題は残る２つ。USB3.0と：DirectX 11 対応グラフィックス カードが厄介でした。

マシンスペックの確認方法
USB3.0というのは、USBの口が青色になっていると思います。これで確認できます。しかし、DirectX 11 対応グラフィックス カードというのがわからない。。。これを確認するには、

1. Kinect v2 SDKをインストール
2. SDK Browser2.0を起動（SDKに同梱されインストールされてます）
3. Kinect Configuration Verifier を起動する

というように、まずはSDKをインストールし、Kinect Configuration Verifier で確認するのが一番です。

Browserの最初のメニューにあります。

チェックがすべて入っていればOK（KinectをつなげてないのでConnectedは×でOK）。

ここでよく、USBとかGraphic Processorが×になるんですよね～。そうなったら残念。ボードを追加購入しましょう。

P.S

なお、上記がクリアしていても、Face系のプログラムが動かない事象が起きました。その際は、Graphic カードのドライバを最新にして解決しました。

Kinect v2にてRGBカメラを表示する

先行して入手したものの、全く手をつけていなかったKinect v2での開発をはじめました。とりあえずRGBカメラの表示です。噂通り、書き方が変わっているとことが多いですね。ただ、最終的にbyte[]に格納してWriteablebitmapにすればいいというのは従来通りなので、全面修正にはならないでしょう。なお、RGBカメラを表示後、数秒後にプログラムが落ちる事象が置きましたが、win8.1のバグのようです。とりあえず、ガーベージコレクションを強制実行することで回避できます。

KinectにてColorFrameに対応するDepthFrameのPlayer情報を入手する方法

KinectではDepthカメラとColorカメラに座標のズレが有るため、v1.6から下記の座標変換系のメソッドがあります。（Kinect.CoordinateMapperクラスより）

• MapColorFrameToDepthFrame 
• MapColorFrameToSkeletonFrame 
• MapDepthFrameToColorFrame 
• MapDepthFrameToSkeletonFrame
• MapDepthPointToColorPoint 
• MapDepthPointToSkeletonPoint  
• MapSkeletonPointToColorPoint 
• MapSkeletonPointToDepthPoint

しかしこれはよく見ると、ColorPointから変換するメソッドがありません。つまり、Colorイメージのある座標をとることができない？実は、MapColorFrameToDepthFrameを利用すれば変換できるんですが、このメソッドで出力されるDepthImagePointについては、

•  DepthImagePointクラスではPlayerIndexがとれない。（Depthはとれる）

という訳の分からない仕様になっています。ですので、一般的にはPlayer情報を取ってくるには、DepthImageのループから該当する箇所のColorImage座標を取ってくるという手法が取られてます。しかし、逆のことがしたいことってあるはずです。

解決策は、前記事にヒントがあります

• Kinectにてユーザ領域のマスク（WriteableBitmap）を生成する

つまり、ColorImageに合わせたマスクをあらかじめ作っておくことで、任意の座標からPlayer情報の有無を呼び出すことが可能です。実は前記事は、画像のマスクとした扱えるように２値化してますが、もっとシンプルな形式で保存しても構わないと思います。

Kinectにてユーザ領域のマスク（WriteableBitmap）を生成する

よくあるテキスト等で書かれている処理ですが、ユーザ領域のマスクを作っておくと、後々便利なことがあったりしますので、、、、

Kinect for Windows v2センサー（オープンベータ）を入手しました

事実上の製品版であろうKinect2 のオープンベータを入手しました。アルファ版との外見的な違いをざっと報告。

本体は同じ
アルファ版には悪趣味なシールが貼ってある点を除いて、同じと思われます。ベータ版にはKINECTの刻印があります。おそらく、アルファ版ではネーミングが未定だったのでシールを貼っていたのだと思われます。

付属ケーブルが小型化
アルファ版では、大げさなデカイ変換器だったのですが、以下の写真のように小型化されました。



ただ、初代はこういったものがなかったわけですから、ちょっと残念なところです。初代からアダプターが増えている理由は、

• 本体への電力供給量の増加

が一番の要因と予測できます。TOFでリアルタイムにレーザで奥行きをとるわけですから、より大きな電力が必要になったのでしょう。現状ではこれ以上の小型化は期待できないですね。

というわけで、ボチボチとうちのゼミでもKinect2に移行していきます。

Kinectプログラミングをする時は、WPFプロジェクト がお勧めです

Windowsプログラミング（.NETフレームワーク）において、GUIアプリの開発アプローチとしては、歴史的に

• Formアプリケーション
• WPFアプリケーション

の2つに分けられます。前者は従来のWindowsGUIプログラムの流れです。後者はVista以降に標準搭載された.NETフレームワーク3.0に最適化されたもので、GUI定義がXAMLと呼ばれるXMLで書かれたファイルで表現されるだけでなく、2Dや3Dを含めた各種GUI処理を統一的に扱えるフレームワークを持つという特徴があります。

ラボでは過去の実装ノウハウを活かすこととWPFに関する資料が少なかったことから、現在まで原則前者を使ってきており、Kinect のプログラミングでもそうしてました。しかし、画面描画処理のパフォーマンスをあげるなら、WPFの方が良いということに今更気づいたのと、さすがにWPFを無視することができなくなりましたので、以後、KinectプログラミングについてはWPFに乗り換えることにします。

WritableBitmapを利用するのがポイント
KinectのColorFrameをWPFで表示する際は、

• PictureBoxクラスではなくImageクラスに表示
• BitmapではなくBitmapSourceを割り当てるのが基本
• WritableBitmapを割り当てると表示処理が高速化

という点が変わります。ポイントは3つめです。下記のサンプルを見てもらえばわかりますが、WritableBitmapを作成しImageクラスのSourceに１度だけ割り当てるだけで、あとはWritableBitmapの内容を更新するだけで更新されます。Formでは各フレーム画像ごとに毎回Bitmap変換して貼り付けていましたから、プログラムのスッキリしますし速度の向上も期待できます。

BackGroundWorkerを利用してKinectのイベントを別スレッドで実装する

～　一部間違いがありましたので訂正します（2014/3/7)　～

Kinectのプログラミングが進んでくると、データ処理部分が肥大化してきます。それは仕方がないことですが、システム全体のパフォーマンスが落ちることになるので、マルチスレッドにより処理する必要が出てきます。この際のマルチスレッド化ですが、具体的には

• Kinectから得たデータの処理を別スレッドに回す
• KinectのReady系イベントを別スレッドに回す

という２つのアプローチがあります。前者はよくされていると思いますが、後者は意外に知られてないかもしれません。確かに、普通はKinectの各種イベントはFormスレッド内に記述することが多いと思いますが、UI周りの処理が複雑化するとシステム全体のパフォーマンスが落ちる可能性があるのでしょう。

BackgroudWorkerを利用してみる

某サイト（最下部参照）にそのことが書かれていたのですが、そのサイトはThreadクラスを使って検証していたようなので、今回はBackgroudWorkerとの合わせ技で別プロセスでの処理が可能かどうか検証してみました。BackgroundWorkerの利便性は前記事で述べたとおりです(C#：BackGroundWorkerコンポーネントを利用したマルチスレッド処理)。

で、結論から言えば成功です。実装のポイントは

• DoWorkイベント内で初期設定からstart()までを記述する（EventHandlerの登録処理は必須）
• スレッドを維持する必要はなし（ループ処理は不要）
• UIコンポーネントへの操作も普通にできる（ProgressChangedイベントさえ不要）
• ColorFrameReadyでのPictureBoxへの描画は普通に可能

という感じです。UIコンポーネントへの操作はいつものようにFrameReady系のメソッドで書けばいいので、従来との互換性も高いです。 

（訂正です）UIへの操作について、Labelの値を変えようとしたらエラーになってしまいました。すべてのUIが操作可能というわけではないようですね。とりあえずInvokerで操作はできます。

本当に別スレッドなのか？

しかし、本当に別スレッドになってるのかどうか、すこし心配になったので、

• System.Threading.Thread.CurrentThread.ManagedThreadId

を各イベント内でコールして確認してみました。具体的には

• Form_Load()
• backgroundWorker1_DoWork()
• kinect_ColorFrameReady()
• kinect_SkeltonFrameReady()
• Button_Click()

の４つのイベント系関数でコールして、従来の手法と今回の手法で、IDに違いがでてくるのかを確認しました。結論を言うと上記イベントでの各IDを横に並べてみると

• 従来： 9,10,9,9,9
• 今回：9,10,11,11,9

という感じになりました（数字はIDの例で、数字自体に意味はありません）。つまり、従来の方法だとFormのスレッドとKinectのスレッドは同じスレッドで動いていたことがわかります。今回の手法だと、Formのスレッドとは異なり、またBackgroundWorkerのスレッドとも異なるスレッドで処理されているようです。

このことから言えるのは、従来の方法だとFormの描画もUIのイベント（例えばボタンクリック）もKinectの処理もすべてシングルスレッドで処理していたことになりますので、本手法の効果は大きいと思います。

Ready系イベントをそれぞれ独立にスレッド化はできない

もしかして、Ready系の各イベントを別スレッド化するってこともできるんじゃないか？と思い、BackgroundWorkerを増やして試してましたが、残念ながらそれは無理でした。これらのイベントは１つのスレッドで処理されるようです。

以上、プログラムが肥大化した人は参考にしてください。

参考サイト

Kinect SDK C# FrameReady系イベントの実行スレッドについて

Kinect: Facetrackerを利用する際の初期設定

KinectのFacetrackingの初期設定でちょっとハマったのでメモ書き。

要求スペック

• Kinect SDK 1.5以上
• Kinect Developer Toolkit 1.5以上
• Kinect for Windows本体（XBOX360版でも可。ただし、nearモードが使えない点に注意）

SDK類はバージョンに注意。特に、Developer Toolkitは忘れないように。

利用する（参照する）ライブラリ

• Microsoft.Kinect
• Microsoft.Kinect.Toolkit.FaceTracking
• Microsoft.Kinect.Toolkit

この３つだけでOK。最初のライブラリはKinectSDKのものです。残りの2つはToolkitのディレクトリに入っていますが、下記に紹介するように各ライブラリはコンパイルして作成し直すことをオススメします。

ライブラリのプラットフォームに注意

Visual Studioで開発する際には

• x86(32bit)
• v64(64bit)
• Any CPU

というようにビルド時のターゲットが選べます。ここで問題になってくるのは、利用するライブラリがどのターゲットでコンパイルされているかです。Kinectのサンプルプログラムの場合、この当たりがちょっと不明で、適当に選んだりすると、

• BadImageFormatException のエラーが発生

ということになります。

ライブラリの再コンパイルと実行の手順

詳細は書きませんが、だいたい以下のようになります。

（１）Developer Tool Kitから各ライブラリのプロジェクトをインストール

• スタートメニューからKinect for Windows Developer Toolkitの画面を起動
• Componentsを選択
• Microsoft.Kinect.Toolkit.FaceTrackingとMicrosoft.Kinect.Toolkitをインストール（Visual Studioのプロジェクトが保存されます）

（２）現在開発しているソリューションに保存した各プロジェクトを追加

（３）プラットフォームを共通にする

各プロジェクトのプロパティ→ビルドで x86 または x64にしてください。どちらが良いかは、他に利用するライブラリによっても変わってきます。

（４）参照設定にてプロジェクトを追加

これで動くはずです。Facetrackingのクラスが呼び出せないのは、まずプラットフォーム（x86,x64,anyCPU）の違いであると考えていいと思います。

Kinect2ファーストインプレッション（3）〜Depthカメラを試してみる〜

Kinect2で一番気になるのは、Depthカメラの精度でしょう。深度の取り方がTOFに変わりましたので、精度は格段に良くなることが期待できますのでね。。早速試してみました。参考までに、現Kinectと比較してみます。

違いは明らか、、、？？？と言いたいところですが、どちらがKinect2かわかりますか？実は、前者がKinect2。近距離については意外と現Kinectも頑張っているようです。ただ、実際に目にすると、Kinect2の方が明らかに精細です。両写真の撮影場所（背景）は違うんですが、Kinect2のほうが後ろにある本棚の各本の境界（エッジ）が、明らかにわかると思います。

それと、現Kinectの仕様上存在する深度の死角（影）については、Kinect2のほうでは完全に消えていますね。これは嬉しいです。

実はKinectの処理については、ソフトウェアの部分で結構改善・改良されているところがあるようで、マイクロソフトの人も、現行のKinectでもKinect2と同じことができると言ってます（精度は違うでしょうけど）。

以上で、ファーストインプレッションは終わりです。今後は、実装する上で、どこが変わったのかなど、調査していきたいと思います。

注意書き

This is preliminary software and/or hardware and APIs are preliminary and subject to change. (この記事は、暫定的なソフトウェアやハードウェア、APIについて述べており、今後変更される可能性があります)

Kinect2 ファーストインプレッション（２） ～初期設定～

前回に続いて、Kinect2 Dev版についての続きです。α版だからかもしれませんが、セットアップが意外と面倒でした。

マシンの準備

下記の仕様を満たすPCが必要です。

• Windows 8.1
• メモリ4GB以上
• i7@ 2.5GHz以上
• USB 3.0 port (Intel or Renesas chipset)
• DX11 capable graphics adapter

これは事前にメールで書かれていたので候補のマシンを確保していたのですが、うっかりしていて、Windows8.1にするのを忘れてました。OSアップデートに時間を費やしてしまいました。

Microsoft Connectの認証を受けておく

SDK関係は同梱されていません。Microsoft Connectからダウンロードする必要があるのですが、ユーザは限定されていますので、認証されたアカウントからしかダウンロードできません。認証方法は、既にメールで届いているはずです。ボクはうっかり見逃してました。注意しましょう。

SDKダウンロード＆インストール

認証を受けた後、Microsoft Connectにアクセスしダウンロードしてインストールしましょう。サンプルプログラムも入ってます。

初期設定

現Kinectなら、SDKインストールして接続すればすぐ動くはずですが、実はそうはいきません。おかしいなぁ、、、ドライバが認識できてないのかな、、もしかして初期不良？ってよくマニュアルを読むと、

• ファームウェアの更新
• Kinect Serviceの起動

という2つのおまじないが必要です。ファームウェア更新は、もちろんKinectを接続してからです。更新中は絶対に本体から抜かないで下さい。で、最後に、Kinect Serviceというのを起動しておく必要があります。これはスタートメニューから実行できます。

以上の作業が終わり、晴れてKinect2が利用できます。まあ製品版ではもっとラクになるかとは思います。

注意書き

This is preliminary software and/or hardware and APIs are preliminary and subject to change. (この記事は、暫定的なソフトウェアやハードウェア、APIについて述べており、今後変更される可能性があります)

Kinect2 ファーストインプレッション（１）

BLOGでは書いてなかったですが、7月にマイクロソフトが募集していた次世代Kinect（Kinext2）の先行取得プログラムに申し込んでいて、昨日、本体（アルファ版）が届きましたので、ファーストインプレッションの報告です。

怪しげなカラーリングがポイントです。

ちょっと図体がでかい？
現バージョンのKinectと比べるとちょっと本体が大きい？？かと思いきや、意外とそうでもないです。

横幅は以前より短いかも？

高さは低いです。角度調整はできます（ソフト的にできるかは未確認）

縦幅はほぼ同じ。

背面にはなんとファンがあります（いつも動いているわけではないです）。

電源周り



バカでかくて面倒なことになってます。右がACアダプター、左がUSB変換コネクタです。まあ、正式版では改良されるのではないでしょうか？


注意書き
This is preliminary software and/or hardware and APIs are preliminary and subject to change. (この記事は、暫定的なソフトウェアやハードウェア、APIについて述べており、今後変更される可能­性があります)

Kinect + OpenCV(OpenCVSharp)は32bitでの実装が無難？

64bitでも問題なく動くので、この記事は古く無視して下さい。

KinectとOpenCVを利用したシステムのデモ準備をするためにノートPCで準備をしていたところ、他のマシンで動いていたはずのプログラムが動かないという事象が発生。具体的には、起動はするのだが、途中で固まってしまうという状況。スペックにはさほど違いはなく、スペック不足の可能性は低い。ちなみに、OpenCV(OpenCVSharp)は64bitでも単体では動いている環境です。

で、結論は表題にもあるように、

Kinect + OpenCV(OpenCVSharp)を動かす時は、32bitの環境にしておく

ということで、とりあえず解決。プロジェクト、OpenCV, OpenCVSharpはいずれも32bit版を利用するのが無難でしょう。

Kinect Interactionsのグリップ情報（HandEventType）を検知する

Kinect for Windows SDK1.7には、

• Kinect Fusion　・・・リアルタイム３Dモデリング
• Kinect Interactions

という2大新機能が実装されました。今日は後者の話です。Kinect Interactionsでは、手のひらの状態を検出できるようになりました。具体的にはグー(Grip)とパー（GripRelease）の状態を検知できます。そのために、stream_InteractionFrameReadyというイベントメソッドが新たに用意され、この中で手の状態(HandEventType)を調べることで、状態を検出できます。具体的には下記のような記述になります。

オープンキャンパスで研究室公開

今年も昨年度と同様にオープンキャンパスで研究室公開をしました。画像処理技術を利用したカメラ制御システムの話と、新ネタとしてKinectを利用したシステムを紹介しました。上の写真は昨年度と同様に指示棒認識のシステムなんですが、今回のデモではなぜか認識精度がよくなく苦労しました。環境に左右されやすい欠点があるので改良が必要ですね。

この写真は新ネタのKinectを利用したシステムです。まだ研究的なシステムは出来上がってないので今回は紹介程度にゲーム的なシステムを用意しました。４年生が作ったもので、ランダムに出現するボールを手でタッチするというシンプルなゲームですが、完成度が高いこともありウケがよかったですね。このシステムのデモのために、院生には何度もチャレンジしてもらいました。いい運動になったでしょう。

昨年も書きましたが、こういうイベントをきっかけにシステム開発を進めるというのは我ながらいい戦略だと思います。来年もやる可能性は大です。