Lasse Munk

I'm would like to record the pointcloud generated by the dp.kinect's (5th) pointcloud outlet.

I have been searching into different possibilities, the easiest one i've found is to use jit.matrixset and then exporting the matrices to a .jxf file. Except for a 8 second animation I have 200mb of data for a 320*240, 3 plane matrix.

I also found the solution for using jit.coerce to have a 1 plane float32 matrix turned in to a 4 plane char, and then just export as a lossless .mov, except then I need to create 1 videofile pr. videoplane, and there is 3 videoplanes in the pointcloud from dp.kinect.

I was wondering if there is a way to have the dp.kinect just give me pointcloud, where the X Y coordinates, are the X Y of the matrix, and the value of each cellblock, is the value of the depth (meaning it goes from 3 planes --> 1 plane, but have the same info)?

I'm would like to record the pointcloud generated by the dp.kinect's (5th) pointcloud outlet. 

I have been searching into different possibilities, the easiest one i've found is to use jit.matrixset and then exporting the matrices to a .jxf file. Except for a 8 second animation I have 200mb of data for a 320*240, 3 plane matrix. 

record-dp-kinect-matrices

Hi. The answer to your last question is the output of the 1st outlet...a depthmap. Each cell of the depthmap has the real-world value of the depth at that grid point on the sensor. There is no meaning to the row and column index of a specific cell other than its position on the sensor. To get meaning from it, you can do a lookup which maps the X and Y cell position into real-world coordinates. This is done for you with the pointcloud outlet. You can also do it manually with the "pixeltoskel" message; though that will perform much slower than the bulk method used inside the pointcloud code.

If you are ok with some inaccuracies due to individual intrinsics/alignments in different Kinect sensors, can deal with slightly less performing code, and don't need alignment of colordepth... you could manually do math which takes the z depth data in the depthmap and calculates real-world x, y, z. Here is some pseudocode for a 320x240 depthmap:

// depthmap is 320x240 pixels, 1 plane, floating-point, and in meters

// i = column of the depthmap; visually left to right

// j = row of the depthmap; visually top to bottom

x = ((i/320) - 0.5) * 1.12033 * depthmap[i,j]

y = (0.5 - (j/240)) * 0.84025 * depthmap[i,j]

A quick google search and I found a lot of research papers on techniques to compress pointcloud streams. You could also seek techniques there.

If you are ok with some inaccuracies due to individual intrinsics/alignments in different Kinect sensors, can deal with slightly less performing code, and don't need alignment of colordepth... you could manually do math which takes the z depth data in the depthmap and calculates real-world x, y, z. Here is some pseudocode for a 320x240 depthmap:
// depthmap is 320x240 pixels, 1 plane, floating-point, and in meters
// i = column of the depthmap; visually left to right
// j = row of the depthmap; visually top to bottom
x = ((i/320) - 0.5) * 1.12033 * depthmap[i,j]
y = (0.5 - (j/240)) * 0.84025 * depthmap[i,j]

A quick google search and I found a lot of research papers on techniques to compress pointcloud streams. You could also seek techniques there.


Thank you for your reply, you are of course right with the 1st outlet, I don't remember why I thought that wasn't what I was looking for.

There is also the data compression 'build in', so that is what I am looking for, since it is a 1 plane float matrix.

Thank you for your reply, you are of course right with the 1st outlet, I don't remember why I thought that wasn't what I was looking for. 

There is also the data compression 'build in', so that is what I am looking for, since it is a 1 plane float matrix. 

Storing the raw single float, you will use four bytes plus overhead. If you can keep your overhead low, you can use only two bytes. The season will, at best, measure 8 meters. You can get mm precision (8000 mm) with a 16 bit integer. Or, if your needs allow, decrease your precision to only 256 "steps" of a byte by isolating only a range of meters and, perhaps, have only centimeter precision.

Then, if your storage mechanism requires data in 32 bit chunks, you can do bit shifting to put two 16 bit integers, or four single byte integers, into that 32 bit storage chunk.

It is a good question. No worries.
Storing the raw single float, you will use four bytes plus overhead. If you can keep your overhead low, you can use only two bytes. The season will,  at best, measure 8 meters. You can get mm precision (8000 mm)  with a 16 bit integer. Or,  if your needs allow, decrease your precision to only 256 "steps" of a byte by isolating only a range of meters and, perhaps, have only centimeter precision.
Then, if your storage mechanism requires data in 32 bit chunks, you can do bit shifting to put two 16 bit integers, or four single byte integers, into that 32 bit storage chunk.
Lots of fun ideas. :-)


record dp.kinect matrices