Since each pixel is represented as 16 bits, it may be more convenient from a programming perspective to represent the byte[]
as a ushort[]
of half the length, but it is not required.
The best solution depends on how you want to consume the buffer.
You could just as easily define a helper method
ushort GetImageDataAtLocation(int x, int y)
{
offset = y * HEIGHT + x;
return BitConverter.ToUInt16(buffer, offset);
}
that uses the input coordinates to determine the offset in the original byte[]
and returns a ushort
composed of the appropriate bytes.
If the TIFF stores data big-endian and your system is little-endian, you would have to reverse the order of the bytes prior to conversion. One way to do that is:
ushort GetImageDataAtLocation(int x, int y)
{
offset = y * HEIGHT + x;
// Switch endianness e.g. TIFF is big-endian, host system is little-endian
ushort result = ((ushort)buffer[0]) << 8 + buffer[1];
return result;
}
If your code might ever run on platforms with different endianness (Intel and AMD are both little-endian) you can determine the endianness at runtime using
For details on BitConverter, see http://msdn.microsoft.com/en-us/library/system.bitconverter.touint16.aspx