近日从本地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系统中，则没有格式限制。仅仅只是要求掩码之间不能有重叠。（注：这样的格式的图像使用起来是比較麻烦的，只是由于它的显示效果接近于真彩。而图像数据又比真彩图像小的多，所以，它很多其它的被用于游戏软件）。
版权声明：本文博客原创文章。博客，未经同意，不得转载。