寬泛來說，BMP圖像是支持壓縮的，他甚至支持jpeg壓縮算法，但更一般的情況是，BMP用來存儲所謂的真彩色影像，即24位的BitMap（位圖），本文并不想刨BMP的祖墳，將它所有的細節抽絲剝繭一一展現，本文只想針對其最常見 的存儲模式做個總結，備忘。

先來看BMP格式圖像的文件總體結構：

從上到下，分別是三個結構體，代碼表示如下（重要的成員已標注為紅色）：

struct header

{

    int16_t type;

    int32_t size; // 圖像文件大小

    int16_t reserved1;

    int16_t reserved2;

    int32_t offbits; // bmp圖像數據偏移量

}__attribute__((packed));

struct info

{

    int32_t size; // 本結構大小    

    int32_t width; // 圖像寬度（單位像素）

    int32_t height; // 圖像高度（單位像素）

    int16_t planes; // 總為零

    int16_t bit_count; // 色深

    int32_t compression; // 是否壓縮

    int32_t size_img;

    int32_t X_pel;

    int32_t Y_pel;

    int32_t clrused;

    int32_t clrImportant;

}__attribute__((packed));

struct quad

{

    int8_t blue;

    int8_t green;

    int8_t red;

    int8_t reserved;

}__attribute__((packed));

看代碼總是很無聊的，尤其是看不懂的代碼！但是如果真要處理BMP圖像數據，那就必須搞清楚以上代碼了，挑幾個重點說一下：

第一，定義了這三個結構體之后，一定要使用__attribute__((packed));來去除系統的地址對齊，否則讀到的格式頭會發生錯誤。

第二，header.size就是圖像文件的大小（即文件總大小減去格式頭大小）。

第三，header.offbits就是格式頭的大小（可能是前兩個結構體，也可能是三個結構體，因為第三個結構體quad可能有也可能沒有）

第四，info.compression決定了格式頭中是否含有quad結構體。

最后，要正確處理BMP圖像還必須牢記在心的幾個要點：

1，圖像每一行所包含的字節數，必須是4的倍數，如果不夠則會湊齊補足到夠為止。比如某BMP圖像色深為24bits，寬度為65像素，算下來一行的字節數是65乘以3等于195個字節，那在文件中將會增加一個額外的字節湊夠196個字節來表示一行的數據量。

2，最后一行數據是圖像的第一行，換句話說BMP是反著存儲的。因此在讀取BMP圖像時一般從最后一行開始讀取，然后讀倒數第二行，以此類推，然后將讀取到的數據依次刷新到顯存，這樣才能正確顯示圖像，否則圖片看起來是反的。