Cluster 3D points into different segments - kinect

I'm asking if there are any ideas of how to cluster different body segments using the depth map from the Kinect device? There are two problems, the first one is how to identify different body parts from each other, for example: lower arm from upper arm. The second one is how to identify a body part if there is an occluded part?
I hope if anyone could guide me solve this.
Many Thanks for your kind assistance

You can use skeleton recognition middlewares (e.g. Nite) to get the coordinates of the joints of the body (such as shoulder, elbow, fingertip). After reading the Z (depth) value of the joints, you can consider only the points which has a Z value close to the body joints' Z values.
For example if the middleware tells you that the Z value of the hand is 2000mm, you can safely assume that all the pixels/points that are part of fingers and palm will have a Z value around 1900-2100mm, and the wall or desk behind or in front of the user will have a much different Z value. So you can just disregard any point outside 1900-2100mm.
You should also disregard any points that are far from the joints. For example there might be a book that is exactly 2000mm far from the camera, but located far from the user.

Related

Inflation layer not working in certain geometries in ANSYS meshing tool

I am trying to implement an inflation layer between two geometries in my mesh using ANSYS, and I am confused about the procedure.
I found online (see the answer from Gopinath N K on 1/17/22) that in the ANSYS meshing tool you cannot combine face meshing with inflation. So I tried to remove the face sizings thinking that was what was being referred to but it gave mixed results which I'll explain below.
Second, I saw here that to create inflation I might need to employ named selections instead of selecting the two geometries (a body and a face) but this also gave mixed results.
As to my mixed results, I successfully got an inflation layer to work for a cylindrical body inside another cylindrical one (see images below). The blue larger cylinder is the body (red arrow), and the green circles are the edges of the small cylinder inside (green arrows). I created this inflation layer successfully.
However, when I try to create an inflation layer between the Rotating Zone (larger cylinder) and the Stationary Zone the inflation layer fails. This occurs as soon as I select the rectangular larger body. I didn't bother to finish selecting the other faces since next to Active it says "No, Invalid Method". The same thing occurs if I select the Structured Zone (smallest cylinder) and the faces of the wing (angled plate subtracted from the Structured Zone). So I really no clue what is causing this since it seems to occur as soon as I select the outer larger body geometry. Maybe I'm not selecting the right set of faces, or there is something else that is leading to this.
Thank you
So it turns out that the message saying "No, Invalid Method" is referring to a Hex Dominant method I created. There are certain mesh methods that inflation does not like to work with, and I haven't been able to find any reason why. I hope anyone using the ANSYS Mesher finds this helpful.

Kinect HandPointer coordinates

I am making an application that will somewhat work like the Kinect's WebServer WPF sample. I am currently trying to map hand positions to screen coordinates so they can work like cursors. Seems all fine and dandy, so let's look at the InteractionHandPointer documentation:
Gets interaction-adjusted X-coordinate of hand pointer position. 0.0 corresponds to left edge of interaction region and 1.0 corresponds to right edge of interaction region, but values could be outside of this range.
And the same goes for Y. Wow, sounds good. If it's a value between 0 and 1 I can just multiply it by the screen resolution and get my coordinates, right?
Well, turns out it regularly returns values outside that range, going as low as -3 and as high as 4. I also checked out SkeletonPoint, but the usage of meters as scale makes it even harder to use reliably.
So, has anyone had any luck using the InteractionHandPointer? If so, what kind of adjustments did you do?
Best Regards,
João Fernandes
The interaction zone is an area for each hand where the users can comfortably interact. When the value is lower than 0 or greater than 1, the hand of the user is outside the interaction region and you should ignore the movement.
To those wondering, like kallocain said, if the value is greater than 1 or lower than 0 then tha hand of the user is outside the interaction region. The fact that the boundaries of this region aren't configurable is quite the bother.
When the values do go outside these values you can indeed choose to ignore them. Instead of doing that, I bounded them to the region in this manner:
Math.Max(0, Math.Min(hand.x, 1))
I hope this helps someone someday.

Optimize pattern of rotating holes for all combinations

Sort of a programming question, sort of a general logic question. Imagine a circular base with a pattern of circles:
And another circle, mounted above and able to rotate, with holes that expose the colored circles below:
There must be an optimal pattern of either the colored circles or the openings (or both) that will allow for all N possible combinations of colors... but I have no idea how to attack the problem! At this point, combinations of 2 seem probably the easiest and would be fine as a starting point (red/blue, red/green, red/white, etc).
I would imagine there will need to be gaps in the colors, unlike the example above. Any suggestions welcome!
Edit: clarified the question (hopefully!) thanks to feedback from Robert Harvey
For two holes, you could look for a perfect matching in a bipartite graph, each permutation described by two nodes, one in each partition. Nodes would be connected if they share one element, i.e. the (blue,red) node from the first partition connected to the (red,green) node of the second. The circles arranged in the same distance would allow for both of these patterns. A perfect matching in that graph would correspond to chains or cycles of permutations where two of them always share a single color. A bit like dominoes. If you had a set of cycles of the same length, you could interleave them to form the pattern on the lower disk. I'm not sure how easy it will be to obtain these same length cycles, though, and I also don't know how to generalize this to more than two elements in each permutation.

transform a path along an arc

Im trying to transform a path along an arc.
My project is running on osX 10.8.2 and the painting is done via CoreAnimation in CALayers.
There is a waveform in my project which will be painted by a path. There are about 200 sample points which are mirrored to the bottom side. These are painted 60 times per second and updated to a song postion.
Please ignore the white line, it is just a rotation indicator.
What i am trying to achieve is drawing a waveform along an arc. "Up" should point to the middle. It does not need to go all the way around. The waveform should be painted along the green circle. Please take a look at the sketch provided below.
Im not sure how to achieve this in a performant manner. There are many points per second that need coordinate correction.
I tried coming up with some ideas of my own:
1) There is the possibility to add linear transformations to paths, which, i think, will not help me here. The only thing i can think of is adding a point, rotating the path with a transformation, adding another point, rotating and so on. But this would be very slow i think
2) Drawing the path into an image and bending it would surely lead to image-artifacts.
3) Maybe the best idea would be to precompute sample points on an arc, then save save a vector to the center. Taking the y-coordinates of the waveform, placing them on the sample points and moving them along the vector to the center.
But maybe i am just not seeing some kind of easy solution to this problem. Help is really appreciated and fresh ideas very welcome. Thank you in advance!
IMHO, the most efficient way to go (in terms of CPU usage) would be to use some form of pre-computed approach that would take into account the resolution of the display.
Cleverly precomputed values
I would go for the mathematical transformation (from linear to polar) and combine two facts:
There is no need to perform expansive mathematical computation
There is no need to render two points that are too close from each other
I have no ready-made algorithm for you, but you could use a pre-computed sin or cos table, and match the data range to the display size in order to work with integers.
For instance imagine we have some data ranging from 0 to 1E6 and we need to display the sin value of each point in a 100 pix height rectangle. We can use a pre-computed sin table and work with integers. This way displaying the sin value of a point would be much quicker. This concept can be refined to get a nicer result.
Also, there are some ways to retain only significant points of a curve so that the displayed curve actually looks like the original (see the Ramer–Douglas–Peucker algorithm on wikipedia). But I found it to be inefficient for quickly displaying ever-changing data.
Using multicore rendering
You could compute different areas of the curve using multiple cores (can be tricky)
Or you could use pre-computing using several cores, and one core to do finish the job.

Algorithm for reducing GPS track data to discard redundant data?

We're building a GIS interface to display GPS track data, e.g. imagine the raw data set from a guy wandering around a neighborhood on a bike for an hour. A set of data like this with perhaps a new point recorded every 5 seconds, will be large and displaying it in a browser or a handheld device will be challenging. Also, displaying every single point is usually not necessary since a user can't visually resolve that much data anyway.
So for performance reasons we are looking for algorithms that are good at 'reducing' data like this so that the number of points being displayed is reduced significantly but in such a way that it doesn't risk data mis-interpretation. For example, if our fictional bike rider stops for a drink, we certainly don't want to draw 100 lat/lon points in a cluster around the 7-Eleven.
We are aware of clustering, which is good for when looking at a bunch of disconnected points, however what we need is something that applies to tracks as described above. Thanks.
A more scientific and perhaps more math heavy solution is to use the Ramer-Douglas-Peucker algorithm to generalize your path. I used it when I studied for my Master of Surveying so it's a proven thing. :-)
Giving your path and the minimum angle you can tolerate in your path, it simplifies the path by reducing the number of points.
Typically the best way of doing that is:
Determine the minimum number of screen pixels you want between GPS points displayed.
Determine the distance represented by each pixel in the current zoom level.
Multiply answer 1 by answer 2 to get the minimum distance between coordinates you want to display.
starting from the first coordinate in the journey path, read each next coordinate until you've reached the required minimum distance from the current point. Repeat.