BMPファイルのバイナリ構造の解説。

概要 †

BMPファイルのバイナリ構造は、データの先頭から順に以下のような構成要素を持つ。

1. ファイルヘッダ
2. 情報ヘッダ
3. ビットフィールド
4. カラーパレット
5. イメージデータ

このうち、ビットフィールドとカラーパレットについては情報ヘッダの内容次第で存在しないことがある。
また、イメージデータは情報ヘッダの内容によって形式が大きく変わる。

なお、BMPバイナリ中にある2バイト及び4バイトの整数値データのバイトオーダはリトルエンディアンであり、符号付き整数値の場合は最上位ビットを符号ビットとする2の補数表現を用いる。
Windows環境しか考慮しないのであればバイトオーダを気にする必要はないが、プラットフォームに依存しないコードを記述する際には留意すること*1。

ファイルヘッダ †

ファイルヘッダはBMPファイルのバイナリ構造において最初に現れる必要があり、以下の構成要素を持つ。

以下に各構成要素の詳細を述べる。

ファイルタイプ（2バイト）

ファイルがBMPファイルであることを示すもので、1バイト目が 'B' 、2バイト目が 'M' となる。
エンコーダは必ずこの値を格納するべきで、デコーダはこの値であるかをチェックするべきである。

ファイルサイズ（4バイト）

BMPファイル全体のバイト単位でのサイズが符号無し整数値で入る。
ただし、厳密でないエンコーダはこの値を計算せずに 0 を格納しても構わない。
デコーダはこの値を利用する必要はなく、また信用するべきでもない。

予約1（2バイト）
予約2（2バイト）

これら2要素は将来の拡張用に予約されており、エンコーダは 0 を格納するべきである。
デコーダはこれらの値を無視して構わない。

イメージデータオフセット（4バイト）

BMPファイルの最初からイメージデータの先頭までのバイト単位でのオフセットが符号無し整数値で入る。
ただし、厳密でないエンコーダは 0 を格納しても構わない。
デコーダは、この値が 0 以外であった場合は信用するべきである。

Win32 SDK環境では、これらの構成を定義した BITMAPFILEHEADER 構造体が存在する。

情報ヘッダ †

情報ヘッダはファイルヘッダのすぐ後に続いて現れる必要があり、以下の4種類が存在する。

• COREタイプ（12バイト）
• INFOタイプ（40バイト）
• V4タイプ（40〜108バイト）
• V5タイプ（40〜124バイト）

これらのうち、現在一般的なBMPファイルに使われているのはINFOタイプである。
エンコーダはこのタイプさえ書き出せるならば問題はなく、デコーダは最低でもこのタイプに対応する必要がある。

どの情報ヘッダタイプにおいても最初の4バイトは必ずヘッダサイズとなる。
よって複数のタイプに対応するデコーダは、まず最初の4バイトを読み取り、その数値で情報ヘッダタイプを判別する。

COREタイプ †

COREタイプはOS/2で使われていた情報ヘッダ形式で、以下の構成要素を持つ。

以下に各構成要素の詳細を述べる。

ヘッダサイズ（4バイト）

情報ヘッダのバイト単位でのサイズが符号無し整数値で入る。
COREタイプでは必ず 12 となる。
エンコーダは必ずこの値を格納するべきで、デコーダはこの値を用いて情報ヘッダを判別する。

幅（2バイト）
高さ（2バイト）

イメージのピクセル単位での幅と高さが符号無し整数値で入る。
値は 1 以上でなければならない。

プレーン数（2バイト）

イメージのプレーン数（チャンネル数）が符号無し整数値で入る。
BMPファイルでは必ず 1 となる。
エンコーダは必ずこの値を格納するべきで、厳密でないデコーダはこの値を無視しても構わない。

ピクセル毎のビット数（2バイト）

イメージデータにおいて1ピクセルを表現するのに必要なビット数が符号無し整数値で入る。
COREタイプでは 1 、 4 、 8 、 24 のいずれかとなる。
他のタイプと違い、 0 、 16 、 32 は無効である。

Win32 SDK環境では、これらの構成を定義した BITMAPCOREHEADER 構造体が存在する。

INFOタイプ †

INFOタイプは最も標準的な情報ヘッダ形式で、以下の構成要素を持つ。
なお、INFOタイプはV4タイプ及びV5タイプに内包されているため、これらのタイプに対応するデコーダはINFOタイプについて考慮する必要はない。

以下に各構成要素の詳細を述べる。

ヘッダサイズ（4バイト）

情報ヘッダのバイト単位でのサイズが符号無し整数値で入る。
INFOタイプでは必ず 40 となる。
エンコーダは必ずこの値を格納するべきで、デコーダはこの値を用いて情報ヘッダを判別する。

幅（4バイト）

イメージのピクセル単位での幅が符号付き整数値で入る。
値は 1 以上でなければならない。

高さ（4バイト）

イメージのピクセル単位での高さが符号付き整数値で入る。
値は 0 であってはならない。
また、トップダウン形式の場合は高さの値にマイナスの符号を付ける。

プレーン数（2バイト）

イメージのプレーン数（チャンネル数）が符号無し整数値で入る。
BMPファイルでは必ず 1 となる。
エンコーダは必ずこの値を格納するべきで、厳密でないデコーダはこの値を無視しても構わない。

ピクセル毎のビット数（2バイト）

イメージデータにおいて1ピクセルを表現するのに必要なビット数が符号無し整数値で入る。
値は 0 、 1 、 4 、 8 、 16 、 24 、 32 のいずれかとなり、この値によって圧縮タイプの取りうる値が変わる。

圧縮タイプ（4バイト）

イメージデータの形式を表す符号無し整数値で、以下のいずれかの値が入る。

0 （Win32 SDK環境では定数 BI_RGB と同値）

標準の非圧縮形式であることを示す。
ピクセル毎のビット数は 0 であってはならない。

1 （Win32 SDK環境では定数 BI_RLE8 と同値）

8ビットのRLE形式であることを示す。
ピクセル毎のビット数は 8 でなければならない。

2 （Win32 SDK環境では定数 BI_RLE4 と同値）

4ビットのRLE形式であることを示す。
ピクセル毎のビット数は 4 でなければならない。

3 （Win32 SDK環境では定数 BI_BITFIELDS と同値）

ビットフィールドを持つ非圧縮形式であることを示す。
ピクセル毎のビット数は 16 か 32 でなければならない。

4 （Win32 SDK環境では定数 BI_JPEG と同値）

JPEG形式であることを示す。
ピクセル毎のビット数は 0 でなければならない。

5 （Win32 SDK環境では定数 BI_PNG と同値）

PNG形式であることを示す。
ピクセル毎のビット数は 0 でなければならない。

イメージデータサイズ（4バイト）

イメージデータのバイト単位でのサイズが符号無し整数値で入る。
エンコーダは、圧縮タイプが 0 か 3 である場合、この値を 0 にしても構わない。
デコーダはこの値を利用する必要はなく、また信用するべきでもない。

水平解像度（4バイト）
垂直解像度（4バイト）

イメージの横方向及び縦方向の1メートル当たりのピクセル数が符号無し整数値で入る。
エンコーダはこれらの情報が不要ならば 0 を格納しても構わず、厳密でないデコーダはこれらの値を無視しても構わない。

カラーインデックス数（4バイト）

カラーパレットに格納される色数が符号無し整数値で入る。
この値が 0 でピクセル毎のビット数が 8 以下の場合、色数は2をピクセル毎のビット数の値で累乗した数になる。
すなわち1ビットならば2色、4ビットならば16色、8ビットならば256色となる。

重要インデックス数（4バイト）

カラーパレットに格納されている色のうち、正確に表示すべき重要色の数が符号無し整数値で入る。
先頭から数えてこの値の分の色が重要色として定義される。
この値が 0 である場合、全ての色が重要色となる。
厳密でないデコーダはこの値を無視しても構わない。

Win32 SDK環境では、これらの構成を定義した BITMAPINFOHEADER 構造体が存在する。

V4タイプ †

V4タイプはINFOタイプを拡張した情報ヘッダ形式で、以下の構成要素を持つ。
なお、V4タイプはV5タイプに内包されているため、V5タイプに対応するデコーダはV4タイプについて考慮する必要はない。

以下に各構成要素の詳細を述べる。

ヘッダサイズ（4バイト）

情報ヘッダのバイト単位でのサイズが符号無し整数値で入る。
V4タイプでは 40 、 52 、 56 、 60 、 96 、 108 のいずれかの値となり、 108 よりも小さい場合は情報ヘッダの後半部分が切り捨てられる。
ただし、エンコーダはこの値を 108 として全構成要素を書き出すことが望ましいと思われる。
デコーダはこの値を用いて情報ヘッダを判別し、この値のサイズ分だけデータを読み込んで解析するようにする。

幅（4バイト）
高さ（4バイト）
プレーン数（2バイト）
ピクセル毎のビット数（2バイト）
圧縮タイプ（4バイト）
イメージデータサイズ（4バイト）
水平解像度（4バイト）
垂直解像度（4バイト）
カラーインデックス数（4バイト）
重要インデックス数（4バイト）

これらの値はINFOタイプの対応する値と同様の意味を持つ。
詳しくはINFOタイプを参照のこと。

赤成分のカラーマスク（4バイト）
緑成分のカラーマスク（4バイト）
青成分のカラーマスク（4バイト）

これらの値は圧縮タイプが 3 の場合のみ意味を持ち、各色成分のカラーマスク値が入る。
データの意味はビットフィールドと同様であるため、詳しくはそちらを参照のこと。

α成分のカラーマスク（4バイト）

α成分（透明度情報）のカラーマスク値が入る。
データの意味はビットフィールドと同様であるため、詳しくはそちらを参照のこと。
α成分自体は値が小さいほど透明度が上がり、 0 で完全に背景を透過する。
透明度情報を扱わないデコーダはこの値を無視しても構わない。

色空間タイプ（4バイト）

色空間タイプを示す定数が符号無し整数値で入る。
V4タイプの場合、この値は必ず 0 （Win32 SDK環境では定数 LCS_CALIBRATED_RGB と同値）となる。
この値が 0 以外であった場合、この情報ヘッダはV5タイプである可能性がある。

赤成分に対するCIEXYZのX座標（4バイト）
赤成分に対するCIEXYZのY座標（4バイト）
赤成分に対するCIEXYZのZ座標（4バイト）
緑成分に対するCIEXYZのX座標（4バイト）
緑成分に対するCIEXYZのY座標（4バイト）
緑成分に対するCIEXYZのZ座標（4バイト）
青成分に対するCIEXYZのX座標（4バイト）
青成分に対するCIEXYZのY座標（4バイト）
青成分に対するCIEXYZのZ座標（4バイト）

これらの値は色空間タイプの値が 0 の場合のみ意味を持ち、各色成分に対応したCIEXYZカラーモデルの各座標（三刺激値）が符号付き整数値で入る。
出力デバイス（ディスプレイ等）にRGB値を渡す際に、これらの値を用いることができる。
よって、デバイスに依存しないデコーダはこれらの値を無視して構わない。

CIEXYZカラーモデルについての詳細はAdobe SystemsによるCIEXYZカラーモデルの解説等を参照のこと。
X, Y, Z の各値を X, Y, Z の合計値で割ることで、色度座標 x, y, z を求めることができる。
Win32 SDKにおける実装に関してはMASAPICO'S PageのColor Management のメモ書き等が参考になる。

赤成分に対するガンマ値（4バイト）
緑成分に対するガンマ値（4バイト）
青成分に対するガンマ値（4バイト）

これらの値は色空間タイプの値が 0 の場合のみ意味を持ち、各色成分に対応したガンマ値が入る。
データの形式はMSDN Libraryの LOGCOLORSPACE 構造体の解説によると、8〜15ビットが整数部、16〜23ビットが小数部の固定小数点数とのこと*2。
CIEのxyY色度空間における Y を表しており、最小値は 0.0 、最大値は 100.0 と思われるが、正確な情報は不明。
デバイスに依存しないデコーダはこれらの値を無視して構わない。

Win32 SDK環境では、これらの構成を定義した BITMAPV4HEADER 構造体が存在する。

V5タイプ †

V5タイプはV4タイプを更に拡張した情報ヘッダ形式で、以下の構成要素を持つ。
なお、V5タイプに対応することでINFOタイプ及びV4タイプにも対応できる。

以下に各構成要素の詳細を述べる。

ヘッダサイズ（4バイト）

情報ヘッダのバイト単位でのサイズが符号無し整数値で入る。
V5タイプでは 40 、 52 、 56 、 60 、 96 、 108 、 112 、 120 、 124 のいずれかの値となり、 124 よりも小さい場合は情報ヘッダの後半部分が切り捨てられる。
ただし、エンコーダはこの値を 124 として全構成要素を書き出すことが望ましいと思われる。
デコーダはこの値を用いて情報ヘッダを判別し、この値のサイズ分だけデータを読み込んで解析するようにする。

幅（4バイト）
高さ（4バイト）
プレーン数（2バイト）
ピクセル毎のビット数（2バイト）
圧縮タイプ（4バイト）
イメージデータサイズ（4バイト）
水平解像度（4バイト）
垂直解像度（4バイト）
カラーインデックス数（4バイト）
重要インデックス数（4バイト）

これらの値はINFOタイプの対応する値と同様の意味を持つ。
詳しくはINFOタイプを参照のこと。

赤成分のカラーマスク（4バイト）
緑成分のカラーマスク（4バイト）
青成分のカラーマスク（4バイト）
α成分のカラーマスク（4バイト）

これらの値はV4タイプの対応する値と同様の意味を持つ。
詳しくはV4タイプを参照のこと。

色空間タイプ（4バイト）

色空間タイプを示す符号無し整数値で、以下のいずれかの値が入る。

0 （Win32 SDK環境では定数 LCS_CALIBRATED_RGB と同値）

V4タイプと同様の色空間情報を持つことを示す。

0x73524742 または 'sRGB' （Win32 SDK環境では定数 LCS_sRGB と同値）

sRGB色空間情報を持つことを示す。

0x57696E20 または 'Win ' （Win32 SDK環境では定数 LCS_WINDOWS_COLOR_SPACE と同値）

Windows標準の色空間であることを示す。

0x4C494E4B または 'LINK' （Win32 SDK環境では定数 PROFILE_LINKED と同値）

色空間プロフィールファイルのパスがBMPファイル中に含まれていることを示す。

0x4D424544 または 'MBED' （Win32 SDK環境では定数 PROFILE_EMBEDDED と同値）

色空間プロフィールがBMPファイル中に含まれていることを示す。

赤成分に対するCIEXYZのX座標（4バイト）
赤成分に対するCIEXYZのY座標（4バイト）
赤成分に対するCIEXYZのZ座標（4バイト）
緑成分に対するCIEXYZのX座標（4バイト）
緑成分に対するCIEXYZのY座標（4バイト）
緑成分に対するCIEXYZのZ座標（4バイト）
青成分に対するCIEXYZのX座標（4バイト）
青成分に対するCIEXYZのY座標（4バイト）
青成分に対するCIEXYZのZ座標（4バイト）
赤成分に対するガンマ値（4バイト）
緑成分に対するガンマ値（4バイト）
青成分に対するガンマ値（4バイト）

これらの値は、色空間タイプの値が 0 の場合のみ、V4タイプの対応する値と同様の意味を持つ。
詳しくはV4タイプを参照のこと。

sRGB色空間タイプ（4バイト）

sRGB色空間を示す符号無し整数値で、以下のいずれかの値が入る。
これらの値は全てICCによって定義された国際色彩協会標準（ICC32）に基づいている。
厳密でないデコーダはこの値を無視しても構わない。

1 （Win32 SDK環境では定数 LCS_GM_BUSINESS と同値）

例えば図やグラフといった、色相や明度の保存に重点を置いたイメージであることを示す。
国際色彩協会標準の対応する名称は"Saturation"である。

2 （Win32 SDK環境では定数 LCS_GM_GRAPHICS と同値）

例えばロゴやデザイン画といった、カラーアピアランスの一致に重点を置いたイメージであることを示す。
国際色彩協会標準の対応する名称は"Relative Colorimetric"である。

4 （Win32 SDK環境では定数 LCS_GM_IMAGES と同値）

例えば写真や風景画といった、比色分析の正確さに重点を置いたイメージであることを示す。
国際色彩協会標準の対応する名称は"Perceptual"である。

8 （Win32 SDK環境では定数 LCS_GM_ABS_COLORIMETRIC と同値）

例えばプレビューといった、比色の絶対値の保存が必要なイメージであることを示す。
国際色彩協会標準の対応する名称は"Absolute Colorimetric"である。

色空間プロフィールオフセット（4バイト）

この値は色空間タイプの値が 'LINK' あるいは 'MBED' の場合のみ意味を持ち、色空間プロフィールデータの格納位置が情報ヘッダの先頭からのバイト単位でのオフセットとして符号無し整数値で入る。
各色空間タイプにおける色空間プロフィールデータの内容を以下に示す。
厳密でないデコーダはこの値を無視しても構わない。

色空間タイプが 'LINK' の場合

プロフィールデータは色空間プロフィールファイルのパスを表す '\0' （ヌル文字）で終わる文字列である。

色空間タイプが 'MBED' の場合

プロフィールデータは色空間プロフィールサイズ分の埋め込みデータである。

色空間プロフィールサイズ（4バイト）

この値は色空間タイプの値が 'LINK' あるいは 'MBED' の場合のみ意味を持ち、色空間プロフィールデータのバイト単位でのサイズが符号無し整数値で入る。
色空間プロフィールデータを利用しないデコーダはこの値を無視して構わない。

予約（4バイト）

将来の拡張用に予約されており、エンコーダは 0 を格納するべきである。
デコーダはこの値を無視して構わない。

Win32 SDK環境では、これらの構成を定義した BITMAPV5HEADER 構造体が存在する。

ビットフィールド †

ビットフィールドは、以下の条件をすべて満たす場合のみ存在する。

• 情報ヘッダがINFOタイプ、V4タイプ、V5タイプのいずれかである。
• ヘッダサイズが 40 である。
• ピクセル毎のビット数が 16 または 32 である。
• 圧縮タイプが 3 である。

なお、V4タイプ及びV5タイプにおいてヘッダサイズが 52 以上の場合、ビットフィールドは情報ヘッダに内包される。

ビットフィールドは、存在するならば情報ヘッダのすぐ後に続いて現れる必要があり、以下の構成要素を持つ。

なお、ピクセル毎のビット数が 16 または 32 ではあるが圧縮タイプが 0 でありビットフィールドが存在しない場合、デコーダは以下の値を既定のビットフィールドとして読み込みを続ける。
エンコーダは、以下の値をビットフィールドとして用いる場合、圧縮タイプを 0 としてビットフィールドを省略できる。

ピクセル毎のビット数が 16 の場合

要素	値
赤成分のカラーマスク	0x00007C00
緑成分のカラーマスク	0x000003E0
青成分のカラーマスク	0x0000001F

1ピクセルあたりのビット数が16であるため、下位16ビットのみが用いられ、上位16ビットは無視される。
なお、この値を持つビットフィールドをRGB555と呼ぶ。

ピクセル毎のビット数が 32 の場合

要素	値
赤成分のカラーマスク	0x00FF0000
緑成分のカラーマスク	0x0000FF00
青成分のカラーマスク	0x000000FF

なお、この値を持つビットフィールドをRGB888と呼ぶ。

値の詳細については、ビットフィールドのページを参照のこと。

カラーパレット †

カラーパレットは、以下の条件の片方、もしくは両方を満たす場合のみ存在する。

• 情報ヘッダのピクセル毎のビット数が 1 、 4 、 8 のいずれかの値である場合。
• INFOタイプ、V4タイプ、V5タイプのカラーインデックス数が 1 以上である場合。

ピクセル毎のビット数が 16 以上であってもカラーインデックス数が 1 以上ならばカラーパレットは存在することに注意すること。
その場合のカラーパレットは主に減色時の色の指針をデコーダに与えるものであるが、定義はされておらず、デコーダはその内容を無視しても構わない。

カラーパレットは、存在するならば情報ヘッダのすぐ後に続いて現れる必要があり、情報ヘッダのタイプによって以下の2種類のどちらかが色数分だけ列挙される。
なお、ビットフィールドが存在する場合、情報ヘッダではなくビットフィールドのすぐ後に続いて現れる必要がある。

TRIPLEタイプ

情報ヘッダがCOREタイプの場合の形式で、以下の構成要素が列挙される。

要素	バイト数
青成分値	1
緑成分値	1
赤成分値	1

Win32 SDK環境では、これらの構成を定義した RGBTRIPLE 構造体が存在する。

1 2 3 4 5

- | | | !

typedef struct tagRGBTRIPLE { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; } RGBTRIPLE;

QUADタイプ

情報ヘッダがINFOタイプ、V4タイプ、V5タイプの場合の形式で、以下の構成要素が列挙される。

要素	バイト数
青成分値	1
緑成分値	1
赤成分値	1
予約	1

Win32 SDK環境では、これらの構成を定義した RGBQUAD 構造体が存在する。

1 2 3 4 5 6

- | | | | !

typedef struct tagRGBQUAD { BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; BYTE rgbReserved; } RGBQUAD;

列挙なので、例えばQUADタイプの場合は次の図のようなバイト並びになる。

色数は、情報ヘッダがINFOタイプ、V4タイプ、V5タイプで、かつカラーインデックス数が 1 以上ならばその値分の数になる。
そうでなければ、2をピクセル毎のビット数で乗算した数になる。
すなわち、ピクセル毎のビット数が 1 ならば2色、 4 ならば16色、 8 ならば256色になる。

構成要素である各色成分値は 0 から 255 までの値をとり、その色要素がどれだけ強いかを表す。
これら色要素は光の三原色を表し、全てが 0 ならば黒、全てが 255 ならば白となる。

QUADタイプの予約要素には通常 0 が入るが、この値をα成分値（透明度情報）として利用するデコーダも存在する。

イメージデータ †

イメージデータは、ファイルヘッダのイメージデータオフセットが 0 の場合は上述した構成要素群のすぐ後に続いて現れる必要があり、 1 以上の場合はその値に従った位置に現れる必要がある。
ただし、イメージデータオフセットの示す位置が上述の構成要素群の格納位置と被る場合、厳密なデコーダは例外として扱い、厳密でないデコーダはその値が 0 であるものとして扱う。

イメージデータは、情報ヘッダがINFOタイプ、V4タイプ、V5タイプのいずれかで、圧縮タイプが 1 または 2 である場合、RLEを用いて圧縮されている。
その場合のイメージデータの内容はRLEによる圧縮のページを参照のこと。
また、圧縮タイプが 4 または 5 である場合、イメージデータはJPEG形式及びPNG形式のデータそのものである。
JPEG形式及びPNG形式の詳細については本文書の範疇を超えるため解説しない。
このセクションでは、圧縮タイプが 0 または 3 の非圧縮イメージデータについて解説する。

イメージデータは行データの羅列から成り、行データはピクセルデータの羅列から成る。
そして各々のピクセルデータは、情報ヘッダのピクセル毎のビット数が示すビット単位のサイズになる。

イメージデータ内における行データの整列順は、イメージ表示時に下に来る行ほど最初に格納されるボトムアップ形式である。
例えば、次のイメージの様に表示されるBMPファイルがあるとする。

この時、行データの格納順は、最下行の黒が一番最初になり、最上行の白が一番最後になる。
ただし、情報ヘッダがINFOタイプ、V4タイプ、V5タイプのいずれかで、その高さの値がマイナスである場合、イメージの高さはその値の絶対値となり、行データの整列順は上に来る行ほど先に格納されるトップダウン形式となる。

行データ及びピクセルデータの詳細を以下に述べる。

行データ †

行データは、文字通りイメージの横1行を表すデータで、上述の通りピクセルデータの羅列である。

更に、行データは必ず4バイトの整数倍のサイズでなければならない。
エンコーダは、行内の全ピクセルデータの合計サイズが4バイトの整数倍サイズではない場合、4バイトの整数倍サイズになるように0を追加する必要がある。
例えば、幅が5ピクセルの8ビットBMP（1ピクセルが1バイト）の場合、行内の全ピクセルデータの合計サイズは5バイトであるため、4バイトの整数倍である8バイトにするために、次の図のようにする必要がある。

情報ヘッダの幅の値が Width 、ピクセル毎のビット数の値が BitCount のとき、行データのサイズ LineSize は次の式により求まる。
なお、この式中の [] はガウス記号であり、 [N] は N を超えない最大の整数を表す。

LineSize＝[(Width×BitCount＋31)÷32]×4

この式により求まった LineSize に情報ヘッダの高さの値の絶対値を掛けることでイメージデータのサイズが求まる。
デコーダはそのようにして求めたイメージデータのサイズを信用して読み込み用のメモリを確保すべきである。

ピクセルデータ †

ピクセルデータは、イメージ中の1ピクセル（別の言い方をするなら1ドット）を表すデータで、情報ヘッダのピクセル毎のビット数によって以下の形式が存在する。

パレットタイプ

ピクセル毎のビット数が 1 、 4 、 8 のいずれかの場合の形式。
ピクセルデータは、カラーパレット内の1色を指し示す、0から始まるインデックス値となる。

ビットフィールドタイプ

ピクセル毎のビット数が 16 または 32 の場合の形式。
ピクセルデータはビットフィールドの各カラーマスク値を基に算出された色となる。
情報ヘッダがV4タイプまたはV5タイプの場合、α成分のカラーマスクも考慮する。
算出方法の詳細についてはビットフィールドのページを参照のこと。

カラータイプ

ピクセル毎のビット数が 24 の場合の形式で、ピクセルデータは以下の構成になる。

要素	バイト数
青成分値	1
緑成分値	1
赤成分値	1

各色成分値のとりうる値とその意味は、カラーパレットの各色成分値と同義である。

Now place: プログラミング/BMPファイル仕様/バイナリ構造

PukiWiki 1.5.0 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji.
Skin "GS2" is designed by yiza.
Powered by PHP 5.6.40. HTML convert time: 0.050 sec.