|
|
Find point closest to Kinect Hiya! A lot of the Kinect demos reduce the area of interest to be a pre-selected, thin slice of z-space. That is, the slice is constant and optimized for the guy sitting in front of the Kinect. In a public setting with a big display, it would be nice to dynamically identify the closest z-space where movement occurs. I can see from a bunch of Kinect videos that passers-by instincly raise their hand and point towards the display. So the voxel(s) closest to the Kinect would be interesting for interaction. Does anyone have an algorithm that can search the Kinect's z-space for the closest point? Ideally, I would like to write an OpenCL implementation for speed. All the best -R
|
Have a look at the Image PixelS plugin/openCL code from Oosterik,
http://kineme.net/forum/Discussion/Programming/ImagePixelS2
It outputs the given input image as a structure (array) of per pixel intensities. That could get you started.
I've tried to make a quick&dirty example, where I sort the structure that ImagePixelS outputs, so that it generates a Image histogram. From that I take the average value and the current max value. In a clean environment without any objects in front of the camera it should work best. Else some-kind of image differencing method could be added.
This won't give you the closest point, but it'll give you the distance. Use the 'area maximum' patch (assuming white = closest, otherwise use minimum).
This gives you a single-pixel image, containing the colour of the brightest pixel - you can then use the 'image pixel' patch to get the colour/distance of the closest point, and use that to define your range.
Ah yeah, you're right. I've updated the file with a switch for max/average distance. The area maximum patch is a nice way to go as well.
Interesting. This wouldn't tell you where the brightest/darkest pixel was found though. It might be more useful to find the location of the brightest/darkest pixel, rather than its colour...
a|x
Someone could probably use the centroid tracker to find an area x/y, and then use that to sample the area maximum for that region. Transforming QC coords back to pixel coords is kind of weird sometimes though.
Also, CI has less resolution than the kinect depth output and can't deal with intensity images... so one would have to RII first to have everything be sane.
this patch does something close to what your describing. it tracks z depth not as smooth as the centroid reduction methods described here but has variable depth tracking so your sort of setting the z distance. i suppose maybe tracking the motion velocities in the depth image to dynamically set the range to be tracked would be possible.
i think thats how the x box works you wave at the screen to pull up cursor ? either way it would be something like adding a before and after frame images to get the distance between to the colors then take the position where the colors are farthest apart meaning the most motion then use that position to sample the pixels to get a depth. once you have that depth then you could set the depth to track and make your blob map to be tracked.
i suppose a simplified version of the algorithm would look like.
if (depth_frame_a - depth_frame_b / delta_time) is greater than your motion threshold then set depth_frame_b's (color.r + color.g + color.b)/3 to your tracking threshold. this would be similar if ( color.r + color .g + color.b )/3 is less than tracking threshold then set all pixels to white and all others to black. thats how i would try cant say this works.
http://kineme.net/composition/dust/cldepthblobtrackingwithkinect
Wow, great ideas --
Buried in work right now, but will have a go at it this weekend.
Thanks, everyone :-)
-R
Alright - here we go.
The Area Maximum -> Image Pixel approach is perfect. Thanks!
The value is passed into a highpass filter with a buffer value. For some reason, buffering to 0.25-0.3 seems ideal.
The results look good for blob tracking.
All the best -R