2

我正在研究一个适当的（或至少是简单的堆栈），以最终通过 OSX 平台上的 python api 从 kinect 获取骨架信息。我发现的大部分信息都非常分散且不连贯。

虽然基于 Windows 的堆栈似乎是微软在其 kinect SDK 之上的自己的 pykinect 似乎非常明显，但我似乎无法弄清楚什么在 OSX 环境中运行良好。

这是我到目前为止编译的信息：

  • libfreenect是低级驱动程序的明显来源（这部分工作得很好）
  • OpenNI提供框架 + NITE 中间件来提供识别。（不是蟒蛇）
  • PyOpenNI - OpenNI 的 python 绑定，支持骨架和其他高级功能。

我得出的结论是，这是迄今为止最推荐的堆栈。我想要实现的是简单的骨架数据，类似于 windows SDK python 包装器为您提供的开箱即用的数据。最终，我将在基于 PyQt 的应用程序中使用它来绘制显示，然后在 Maya 中应用数据。

我的问题分为两部分，如果是最合适的，我会接受任何一个方向的答案......

PyOpenNI 的构建问题

到目前为止，我无法在 OSX Snow Leopard (10.6.8) 或 Lion (10.7.4) 上成功构建 PyOpenNI。两个系统都更新了 xcode。我注意到源文件被硬编码为期望 python2.7，所以在雪豹上我必须确保它已安装并且是默认版本（也尝试了 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

是否有任何特定步骤可以在我缺少的 OSX 上构建它，例如环境变量以确保其指向正确的 python2.7 库？有没有人有这个平台的成功构建过程？

替代问题

这仍然是 OSX 最推荐的堆栈吗？

跟进

我已经接受我自己的答案作为临时工作解决方案。如果有人能提供更好的，我很乐意接受！

4

1 回答 1

3

更新

在我提交了一个补丁后（这里的信息） ，这个过程的一部分是不必要的。从那以后，我还写了一篇关于在 OSX 上安装整个堆栈的更详细的博客文章：在 OSX 上 使用 Xbox360 Kinect 入门

在对此进行了一番修改之后，我找到了一个有效的修复程序（尽管它没有解决构建级别的问题）。cmake 存在一个问题，它无法正确检测除系统框架之外的其他 python 框架（这会导致 python 二进制文件和库之间的不匹配）。

我首先通过自制软件重新安装了我的 python2.7 安装，添加了 --framework 标志

构建模块后，我通过 otool 注意到它仍然链接到我的系统 python，并且 Lion 上的系统 python 是 fat i386 和 x86_64。我还注意到链接到 openni.so 的 libboost（通过 homebrew 安装）也链接到系统 python 而不是 homebrew。所以我使用以下方法重新链接它们：

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

完成此操作后，我能够毫无错误地导入 openni。

以下是解决方法的摘要：

  1. python2.7作为框架，x86_64（不胖）
  2. libboost 链接到正确的 64 位 python
  3. export CPPFLAGS="-arch x86_64"
  4. cmake并像平常一样制作步骤
  5. 将 openni.so 重新链接到 64 位 python

理想情况下，有人会发布比这个更好的答案，展示如何在构建阶段使用环境变量修复此问题，而不必在最后进行重新链接修复。

于 2012-05-27T14:27:33.637 回答