# What is the true range of InfraredResolution640x480Fps30 pixel values?

• ### Question

• I'm using InfraredResolution640x480Fps30, which is documented (at http://msdn.microsoft.com/en-us/library/microsoft.kinect.colorimageformat.aspx) to provide two bytes per pixel, where the most significant 6 bits are set to zero.  This definition implies that the maximum value will fit in 10 bits.  But in looking at the actual data coming back from the stream, I'm seeing a much broader range.  For example, in a specific frame of IR data, I see a maximum in the first byte of 192 (requiring 8 bits) and a maximum in the second byte of 254 (requiring 8 bits).  Clearly, the most significant 6 bits are not always zero.

Which leads to my primary question: What is the true range of IR values returned?

And a secondary question: What is the byte order of the 16-bit values returned?  It looks like the second byte in the sequence is probably the most significant byte, but since both return up to 8-bit values, it's not completely clear which is which.

Thanks.

• Edited by Monday, November 12, 2012 4:51 PM correct typo
Monday, November 12, 2012 4:46 PM

### Answers

• I have been able to confirm this is a bug in the documentation. The correct information is the 6 least significant bits are 0 and the data is the 10 most bits. This will provide values from 0x0000 to 0xffc0(1111 1111 1100 0000).

Infrared Stream
http://msdn.microsoft.com/en-us/library/jj663793.aspx

Given a sample set of data, the values would be as follows, little endian: 40 03 80 06 c0 05 00 09 c0 1e ...

0x0340, 0x0680, 0x05c0, 0x0900, 0x1ec0

Hope this helps.

Wednesday, November 14, 2012 12:59 AM

### All replies

• I have been able to confirm this is a bug in the documentation. The correct information is the 6 least significant bits are 0 and the data is the 10 most bits. This will provide values from 0x0000 to 0xffc0(1111 1111 1100 0000).

Infrared Stream
http://msdn.microsoft.com/en-us/library/jj663793.aspx

Given a sample set of data, the values would be as follows, little endian: 40 03 80 06 c0 05 00 09 c0 1e ...

0x0340, 0x0680, 0x05c0, 0x0900, 0x1ec0

Hope this helps.

Wednesday, November 14, 2012 12:59 AM
• Thanks for the answer.  The documentation bug explains a lot.   The behavior makes complete sense now.
• Edited by Wednesday, November 14, 2012 2:02 AM
Wednesday, November 14, 2012 2:00 AM