Kinect Development Notes (issue summary)

Today, with the Kinect development project, however, the following problems have arisen, which are summarized as follows:

Problem one, an error occurred while calling the function: Nuiimagestreamreleaseframe (Depth_stream, &d_frame) (pictured below)

After debugging, the problem appears in the D_frame variable, which is used all the time and has not been found. When you look carefully at the items you've done and refer to the code in someone else's blog, you find suspicious places:

The way I get the next frame is: HRESULT hr = Kinect->nuiimagestreamgetnextframe (depth_stream, 1000, &d_frame); The function is encapsulated in a class Kinectsensor inside, not the free function: Nuiimagestreamgetnextframe (). The second parameter type of the first function is: nui_image_frame*, and the second parameter type of the second function is: nui_image_frame * *. If you open the next frame by using a free function, you will not get an error (you would, of course, initialize the Kinect with a natural function and open the stream). The initial suspicion is that the variable d_frame is defined in the stack, and the Free Method Nuiimagestreamgetnextframe () attempts to delete the error caused by the &d_frame, so I changed the D_frame type to Nui_image_ frame*, but the call free function still has an exception when it releases the frame.

Solution: Invoke the function below Kinectsensor kinectsensor::nuiimagestreamreleaseframe (Depth_stream, &d_frame) Rather than the free function nuiimagestreamreleaseframe (Depth_stream, &d_frame). These functions must match the use.

Question two: With respect to the structure: Nui_depth_image_pixel, the type of the structure body is:

typedef struct _NUI_DEPTH_IMAGE_PIXEL
{
USHORT Playerindex;
USHORT depth;
} Nui_depth_image_pixel;

Encapsulates two USHORT for four bytes, as seen in Microsoft's sample code, where the use of the example defines a nui_depth_image_pixel* type of variable pointing to the first byte of the depth data, then traversing the depth data, obtaining the depth value and the user ID. But the depth data occupies a total of two bytes per pixel, so it doesn't make sense to why. Try it yourself and find that the Playerindex value is the same as the depth value, and if the depth image pixel is: 640*480 rect. Pitch = 640*2 = 1280,rect.size = 614400, easily two bytes per pixel. Why is this. What the hell went wrong. To figure out the truth, I compared the code of two programs and found that we used different methods to generate Nui_rocked_rect data, as follows:

My Code: Depth_frame.pframetexture->lockrect (0, &d_data, NULL, 0);

Sample code: hr = M_pnuisensor->nuiimageframegetdepthimagepixelframetexture (M_hstreamhandle, &imageFrame, & Nearmode, &ptexture);

It turns out that if you manipulate the structure directly, you get the original data, each pixel is stored in two bytes, a height of 13 bytes is depth, the low is the user ID, and if the method of the example is used, the data is converted by row, the depth value and the user ID are separated, two bytes represent the depth value, and two bytes represent the user ID.

Thus, if it is convenient to handle, you can take advantage of the example's approach, but it will sacrifice speed and space, and if you use the original method, it will be more complex (involving the operation in place), but faster and less space consuming.

Welcome advice ...

Cond...