2

私は、OSX プラットフォーム上の Python API を介して、最終的に kinect からスケルトン情報を取得するための適切な (または少なくとも単純なスタック) を研究しています。私が見つけた情報のほとんどは、かなり散らばっており、バラバラです。

Windows ベースのスタックが kinect SDK の上にある Microsoft 独自の pykinect であることは明らかですが、OSX 環境で何がうまく機能するかはわかりません。

これまでにまとめた情報は次のとおりです。

  • libfreenectは、低レベル ドライバーの明らかなソースです (この部分は問題なく動作しています)。
  • OpenNIは、フレームワーク + NITE ミドルウェアを提供して、認識を提供します。(ないパイソン)
  • PyOpenNI - スケルトンやその他の高度な機能をサポートする OpenNI の Python バインディング.

これは、これまでで最も推奨されるスタックであると結論付けました。私が達成したいのは、Windows SDK python ラッパーがすぐに提供するものと同様の単純なスケルトン データです。最終的には、これを PyQt ベースのアプリで使用してディスプレイを描画し、Maya にデータを適用します。

私の質問は 2 つの部分で構成されています。どちらの方向の回答も、それが最も適切であれば受け入れます...

PyOpenNI のビルドの問題

これまでのところ、OSX Snow Leopard (10.6.8) または Lion (10.7.4) で PyOpenNI を正常にビルドできませんでした。両方のシステムで xcode が更新されました。ソースファイルがpython2.7を期待するようにハードコードされていることに気付いたので、Snow Leopardでは、それがインストールされ、デフォルトバージョンであることを確認する必要がありました（virtualenvも試しました）。

Snow Leopard では、cmake プロセスがさまざまなライブラリ、ヘッダー、python の bin を見つけ、最終的に make が .so を生成し、それが「不一致のインタープリター」でクラッシュするのを見ていました。

Lion では、不一致のインタープリター クラッシュも発生しました。しかし、自作でpython2.7をインストールした後、新しいエラーが発生しました：

ImportError: dlopen(./openni.so, 2): Symbol not found: _environ
  Referenced from: /usr/local/lib/libpython2.7.dylib
  Expected in: dynamic lookup

正しいpython2.7ライブラリを指すようにするための環境変数など、OSXでこれを構築するための特定の手順はありますか? このプラットフォームのビルドプロセスを成功させた人はいますか?

別の質問

これはまだ OSX の最も推奨されるスタックですか?

ファローアップ

私は自分の答えを一時的な解決策として受け入れました。誰かがより良いものを提供できるなら、私は喜んでそれを受け入れます！

4

1 に答える 1

3

Update

Part of this process isn't necessary after a patch I submitted (information here). Since then I have also written up a more detailed blog post about installing the entire stack on OSX: Getting Started With Xbox360 Kinect On OSX

After hacking around on this a bit, I have found a working fix (though it doesn't address the issue at the build level). There is an existing issue with cmake, where it does not properly detect other python frameworks besides the system framework (which causes the mismatch between the python binary and the libs).

I first reinstalled my python2.7 install via homebrew, adding the --framework flag

After building the module, I noticed via otool that it was still linking to my system python, and the system python on Lion is fat i386 and x86_64. I also noticed that the libboost (boost installed via homebrew) which was linked to openni.so was also linked against the system python instead of homebrew. So I used the following to relink them:

install_name_tool -change \
    /System/Library/Frameworks/Python.framework/Versions/2.7/Python \
    /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python \
    openni.so 

install_name_tool -change \
    /System/Library/Frameworks/Python.framework/Versions/2.7/Python \
    /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python \
    /usr/local/Cellar/boost/1.49.0/lib/libboost_python-mt.dylib

After doing this, I was able to import openni without any errors.

Here is the summary of the workaround:

  1. python2.7 as framework, x86_64 (not fat)
  2. libboost linked to the proper 64bit python
  3. export CPPFLAGS="-arch x86_64"
  4. cmake and make steps like normal
  5. relink openni.so to the 64bit python

Ideally, someone would post a better answer than this one showing how to fix this during the build phase with environment variables, and not have to do a relink fix at the end.

于 2012-05-27T14:27:33.637 に答える