最近从一张本地的16位位图读取像素颜色数据，并填充到ANDROID的BITMAP的数据中，发现使用CAVAS显示到界面时，图片显示颜色不对，找了很多资料，原来发现是两个原因：

         1.将位图的颜色分量掩码弄错了，当BITMAPINFOHEADER.biCompression是BI_BITFIELDS，此时位图才为565格式的位图，掩码存放在原来调色板的位置，而当前读取的这张位图BITMAPINFOHEADER.biCompression是BI_RGB，此时位图应该为555的位图，所以掩码应该采用RGB555的掩码数据。

        2.在把RGB555的位图颜色数据 转换为RGB888的数据时，首先将位图的数据像素值与颜色分量掩码进行与运算，然后由于RGB555是对颜色数据进行了有损的压缩编码，只剩下了5位数据，而当转换为8位的原始数据时，必须要进行数据补偿，可以默认使用0进行不足的位数补偿，以达到8位的原始颜色分量长度，也有种说法，是采用5位数据的低几位进行数据填充，据说效果更好，失真更少。

biBitCount=16 表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。

RGB565与RGB555位图文件格式的标志识别