Revision history [back]

It's probably worth pointing out that the Kinect itself does not output point clouds, but rather a depth map. That is, you can think of the Kinect output as being a 640x480 array (that's 307,200 entries) where each entry contains the Z-axis value of the point in the world corresponding to that entry. IIRC this Z-value is encoded with 11 bits but stored in 16 bits, so the size of the (depth, excluding colour) dataset coming off of the sensor is 307,200*2 = 614,400 bytes. At 30 fps that's about 18 MB/sec. However, when you project these depth values to 3D to get 3 floats per entry in the array the size of the dataset of course expands greatly.

The point is, depending on your application, you might not need all of the depth information projected to 3D coordinates, at the full 30 fps. I don't know what your application is but here's a made-up example. Say you want to grab 3d models of faces that are within the Kinect's view. Your first stage is to use the (RGB) camera data to detect bounding boxes of faces. Then you want to find out the 3D points that are associated with those bounding boxes. This means that you really only want to project the depth data that is associated with the bounding boxes, not all of it.

BTW with the openni_camera driver there is a way to do this; in the current (Diamondback) driver you can set the use_indices parameter, and then publish pcl/PointIndices messages to camera/depth/indices. The pointclouds output on camera/depth/points will then only contain projected points corresponding to the indices you asked for (i.e. the ones that correspond to the bounding boxes in the example above). This is what I did for my quadrotor kinect demo, to cut down the amount of 3D data to a reasonable level so that the onboard CPU could handle the calculations at the full 30 Hz.

The newer openni_camera driver (openni_camera_unstable) looks like it provides more flexibility still -- you can subscribe directly to the raw depth information and do whatever you want with it.