High Road - Kinect mounted high, pointed down (glview)

Low Road - Kinected mounted low - pointed straight (glview)

Mounted low and box pushed closer - since it blended withthe wall.  GLView is nice in that it has "black" where there is "unknown" depth, while mrl dutifully paints it as "green" depth.  I update this soon.  GLView is also nice that you can change the angle of the kinect using keys.  A big challege would be to do the same thing using JavaCv's FrameGrabber ? ..  heh, that would be a funny update for JavaCV 

Ahoy ! - there be my tush, desk, stool - but most importantly you can see a lovely smooth color gradient starting from the bottom of the frame gradually going up.  Now, I'll be working on the depth navigation filter to determine if "something" interferes with the smooth rainbow.  if it does, then "smooth green fields of floor" do not exist going forward, and it becomes an obstacle to avoid.

Oh, and in this frame you can clearly see the band of 12 pixels on the right edge.  This is an artifact (blind spot) of the kinect's structured light sensor implementation works.

FIXED !!  WAHOOO ! - now we can see "all" the data - the gradation as it cycles through the color spectrum.  I finally decoded what needed to be done to display it.  One part was not to forget the size of the pixel values, and the last one was to swap bytes in the depth (msb/lsb were previously in the wrong place).

Update - no missing depth data .. Yay ! - The problem of the recycling gradient is a Java display issue.  A BufferedImage is created with the "correct" information telling its a GRAY_USHORT unsigned short single channel 16 bit depth image, but it's displayed as a 8 bit grayscale.

My idea is to convert it to a HSV value where H (hue) is an index which can represent depth. I'm pretty sure this is what some of the other common viewers are doing (such as the freenect-glview).  Above you can see my first attempt of it, which iterates through all the bytes of lpImage.  

You may be thinking "why not just fix the display vs iterate through all the pixel values and go through the work of translating it"?  The reason primarily is, I'm interested in work-e navigating around, and I'll need the depth values of the image anyway.  An extremely simple way is to avoid "stuff in the way" is check values at the bottom and  if there is something which is above the ground plane ... avoid it.

Current problem is making the gray 1 channel 16 bit depth correctly translate into a rgb hsv 3 channel 8 bit image :P ... Don't have it yet .. :)

Here's a smooth floor looking from Work-E's eye - it should be a smooth gradient, but the gradient cycles at least 3 times.  I remember looking at this a long time ago .. I think perhaps the data frame of the kinect framegrabber in javacv/opencv might be missing data ? 

I'll look into this soon because I want a smooth change of depth for Work-E to understand what is close and what is far away ... hopefully its just an artifact of the display.  Maybe if we have a gradient of colors too we can get "full depth"