Tagged: kinect mountain lion
August 29, 2012 at 11:20 am #6284
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!August 29, 2012 at 2:09 pm #6285
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.August 29, 2012 at 3:13 pm #6286
Looks like that cleared it up. Thanks!August 29, 2012 at 3:47 pm #6287
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.October 30, 2012 at 2:32 pm #6433
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!October 31, 2012 at 10:40 am #6434
v002 Open Kinect uses 32 bit floating point data. Core Image clips values. See other posts in the forum regarding this.October 31, 2012 at 10:54 am #6435
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.October 31, 2012 at 11:33 am #6436
Does v002 Rutt Etra in XYZ mode render the scene properly? Perhaps your GPU doesn’t handle float 32 render texture targets.October 31, 2012 at 11:35 am #6437
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.November 1, 2012 at 8:51 am #6438
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 :/November 1, 2012 at 9:23 am #6439
Interesting if this worked earlier. Are you compiling from GIT ? If so, can you tell what commit you are having issues with?
November 1, 2012 at 9:29 am #6441
- This reply was modified 8 years, 1 month ago by vade.
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.November 1, 2012 at 10:40 am #6442
Try rolling back to a previous commit, check out :
And see if it fixes the issues with the depth (although it will revert core image issues).
Remind me your GPU?November 1, 2012 at 12:21 pm #6443
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.
- You must be logged in to reply to this topic.