v002 Open Kinect + OSX Mountain Lion

Home Forums v002 v002 QC Plugins Support v002 Open Kinect + OSX Mountain Lion

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #6284
    zebradog
    Participant

    Hey all,

    I’m having some interesting/strange glitching on Mountain Lion. If I hook up the Kinect patch directly to an output source (Billboard/Sprite), everything is fine, but the moment I try to do anything to the Kinect’s image (flip-flop, core image filter, etc), the output starts flickering between the depth image and the color image. This happens seemingly regardless of which image is being used (depth v. color), and I’ve yet to find an image-modifying patch that doesn’t cause the issue.

    I’m using QC version 4..6 (framework version 5.1) on OSX 10.8.1 and the Beta 5 version of the Kinect plugin. Not sure if it’s relevant/helpful, but Kineme’s Kinect patch behaves normally (i.e. maybe they’re doing something we’re not?)

    Any thoughts/advice would be awesome. Thanks!

    #6285
    vade
    Keymaster

    Thanks for the report. Can you try a pull off of the github, and see if the latest commit fixes it?

    I was able to re-create (sorry about that), and think the fix is pretty easy.

    #6286
    zebradog
    Participant

    Hi vade,

    Looks like that cleared it up. Thanks!

    #6287
    vade
    Keymaster

    Awesome. I just realized I forgot to comment in a set of lines above the scrollback. Do one more pull, then you will have a bit of a performance boost (I commented out some texture submission optimizations, to see if they were causing an issue, and forgot to comment one set of those back in).

    Thanks for getting back to us that you are in the clear. Appreciated.

    #6433
    zebradog
    Participant

    Hey Vade,

    I’m working on doing some blob tracking with Kinect and I discovered something that seems a bit odd. After the patch, it looks as if the depth data isn’t coming through right. Everything within the scene shows as completely white (value of 1). Here’s a screenshot with the depth image, the color image, and the depth image from Kineme’s Kinect patch, for reference: http://img217.imageshack.us/img217/6817/quartz.png

    I’m not sure if it’s this update in particular that’s causing problems or what, but I know it certainly used to work when we first started working with this plugin a few months ago. I can try it on another machine for reference if you’d like. Let me know. Thanks!

    #6434
    vade
    Keymaster

    v002 Open Kinect uses 32 bit floating point data. Core Image clips values. See other posts in the forum regarding this.

    #6435
    zebradog
    Participant

    Right. I’ve read about that. What I’m talking about, and what the screenshot shows, is the raw data coming out of each of the Kinect patches. This is before any processing. There’s no actual depth data coming out of the v002 Open Kinect patch. It’s just white and black instead of being grayscale like it should.

    #6436
    vade
    Keymaster

    Does v002 Rutt Etra in XYZ mode render the scene properly? Perhaps your GPU doesn’t handle float 32 render texture targets.

    #6437
    vade
    Keymaster

    Additionally, drawing the depth image via a billboard or sprite is still going to clip, since, well, you are drawing it as a texture, not as a point in 3D space. This is because color values in the front buffer or an 8 bit buffer (FBO, etc) supports only 0 to 1 color values.

    #6438
    zebradog
    Participant

    Rendering with Rutt Etra is producing the same behavior. When in grayscale, all the “on” values are outputting 1 (white), and everything else is black. If using XYZ as RGB mode, there are more colors, but the depth data is still the same (uniformly blue for anything that’s “on” in the depth image).

    Re: graphics card – I’ve been using the same machine, and I’ve previously been able to get great depth data out of it (easier to work with/smoother than Kineme’s, etc.), so I was sad to discover this not working :/

    #6439
    vade
    Keymaster

    Interesting if this worked earlier. Are you compiling from GIT ? If so, can you tell what commit you are having issues with?

    • This reply was modified 8 years, 4 months ago by vade.
    #6441
    zebradog
    Participant

    I was wondering if there was an issue with versioning (10.8 vs 10.7.5, etc.), so I just pulled the most recent version from git (which I think is what I was working from before, but just to be sure) and re-built it in Xcode and it’s doing the same thing it was 🙁

    I can’t think of any other changes that’ve been made (we formatted the harddrive and reinstalled OSX and all that since this summer when I had it working, but I can’t imagine that would cause this), but it does seem odd that the little fix you made to clean the buffer would be causing this issue.

    #6442
    vade
    Keymaster

    Try rolling back to a previous commit, check out :

    https://github.com/v002/v002-Open-Kinect/tree/b411e4cb53ef4e39d4e899c74c9de3dcb6b41995

    And see if it fixes the issues with the depth (although it will revert core image issues).

    Remind me your GPU?

    #6443
    zebradog
    Participant

    Doesn’t look like that made any difference 🙁

    I’m on the Late 2009 iMac. ATI Radeon HD 4850. OS X 10.7.5. Core i5 2.66 GHz if that matters.

    Thanks for taking the time to look into this. I’m sure you have better/more exciting things to do, so if this is taking up time, we have a workaround using the Kineme Kinect patch that’s working.

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.