? ? ? ?最近從一張本地的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位图文件格式的标志识别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。