轉轉大師PDF轉換器
支持40多種格式轉換,高效辦公
寬泛來說,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圖像時一般從最后一行開始讀取,然后讀倒數第二行,以此類推,然后將讀取到的數據依次刷新到顯存,這樣才能正確顯示圖像,否則圖片看起來是反的。