BMPファイル形式

BMPファイル形式（ビットマップ）は、特にMicrosoft Windows ^[2]やOS/2 ^{[3]オペレーティングシステム上で、}ディスプレイデバイス（グラフィックスアダプタなど）に依存せずにビットマップ デジタル画像を保存するために使用されるラスターグラフィックス画像ファイル形式です。

BMPファイル形式は、さまざまな色深度で2次元デジタル画像を保存することができ、オプションでデータ圧縮、アルファチャンネル、カラープロファイルを使用できます。Windowsメタファイル（WMF）仕様はBMPファイル形式をカバーしています。^[4]

図1 – ビットマップ画像ファイルの構造

Microsoft は、さまざまな内部表現を持つデバイスとアプリケーション間でビットマップを交換するための補助として、異なる色深度のカラー ビットマップの特定の表現を定義しました。これらはデバイスに依存しないビットマップ (DIB) と呼ばれ、そのファイル形式は DIB ファイル形式または BMP イメージ ファイル形式と呼ばれます。

マイクロソフトのサポートによると: ^[5]

デバイス独立ビットマップ (DIB) は、さまざまな色解像度でデバイス独立ビットマップを定義するために使用される形式です。DIB の主な目的は、ビットマップをあるデバイスから別のデバイスに移動できるようにすることです (したがって、名前のデバイス独立部分はデバイス独立です)。DIB は、デバイス依存ビットマップとは対照的に、外部形式です。デバイス依存ビットマップは、システム内でビットマップ オブジェクト (アプリケーションによって作成) として表示されます。DIB は通常、メタファイル (通常は StretchDIBits() 関数を使用)、BMP ファイル、およびクリップボード ( CF_DIBデータ形式) で転送されます。

以下のセクションでは、BMP ファイルまたは DIB に保存されるデータについて詳しく説明します。これは標準の BMP ファイル形式です。^[5]一部のアプリケーションは、Microsoft のドキュメントに準拠していないビットマップ イメージ ファイルを作成します。また、すべてのフィールドが使用されるわけではなく、これらの未使用のフィールドには 0 の値が設定されます。

ビットマップ イメージ ファイルは、固定サイズの構造 (ヘッダー) と、所定の順序で表示される可変サイズの構造で構成されます。このファイル形式は長い進化を遂げてきたため、ファイルにはこれらの構造のさまざまなバージョンが多数含まれることがあります。

図 1 を参照すると、ビットマップ ファイルは次の順序の構造で構成されています。

メモリにロードされたビットマップ イメージ ファイルは、Windows GDI API の重要なコンポーネントである DIB データ構造になります。メモリ内の DIB データ構造は BMP ファイル形式とほぼ同じですが、14 バイトのビットマップ ファイル ヘッダーが含まれず、DIB ヘッダーで始まります。メモリにロードされた DIB の場合、カラー テーブルは、明示的な RGB カラー定義の代わりに、現在実現されているパレット^[8] (追加の間接レベル) へのインデックスを構成する 16 ビット エントリで構成することもできます。すべての場合において、ピクセル配列は 4 バイトの倍数のメモリ アドレスから始まる必要があります。メモリにロードされた非パック DIB では、オプションのカラー プロファイル データは、カラー テーブルの直後、gap1 とピクセル配列^[7]の前に配置する必要があります(図 1 とは異なります)。

ギャップ 1 とギャップ 2 のサイズが 0 の場合、メモリ内の DIB データ構造は慣例的に「パックされた DIB」と呼ばれ、DIB ヘッダーの先頭を指す単一のポインターで参照できます。すべての場合において、ピクセル配列は 4 バイトの倍数であるメモリ アドレスから開始する必要があります。場合によっては、ピクセル配列のメモリ アドレスを 4 バイトの倍数にするために、カラー テーブルのエントリ数を調整する必要があります。^[8] メモリにロードされた「パックされた DIB」の場合、図 1 (ギャップ 1 = 0、ギャップ 2 = 0) に示すように、オプションのカラー プロファイル データはピクセル配列の直後に続く必要があります。^{[7] 「パックされた DIB」は、} Windowsクリップボード API 関数だけでなく、一部の Windows パターン ブラシおよびリソース関数でも
必要です。 ^[9]

このバイト ブロックはファイルの先頭にあり、ファイルを識別するために使用されます。一般的なアプリケーションは、最初にこのブロックを読み取り、ファイルが実際に BMP ファイルであり、破損していないことを確認します。BMP ファイル形式の最初の 2 バイトは、ASCIIエンコードで文字「B」と文字「M」です。すべての整数値は、リトルエンディアン形式 (つまり、最下位バイトが先頭) で保存されます。

このバイト ブロックは、アプリケーションにイメージの詳細情報を伝えます。この情報は、画面にイメージを表示するために使用されます。このブロックは、Windows および OS/2 が内部的に使用するヘッダーとも一致し、いくつかの異なるバリアントがあります。これらのすべてには、サイズを指定する dword (32 ビット) フィールドが含まれているため、アプリケーションはイメージでどのヘッダーが使用されているかを簡単に判断できます。さまざまなヘッダーが存在する理由は、Microsoft が DIB 形式を何度も拡張したためです。新しい拡張ヘッダーは、古いヘッダーの代わりに一部の GDI 関数で使用でき、より多くの機能を提供します。GDI はビットマップ ファイルをロードする機能をサポートしているため、一般的な Windows アプリケーションはその機能を使用します。この結果、このようなアプリケーションでは、サポートされる BMP 形式が、実行されている Windows バージョンでサポートされている形式と一致します。詳細については、下の表を参照してください。

Windows 2.x BITMAPCOREHEADERは、画像の幅と高さのフィールドが符号なし整数ではなく符号付き整数であるという点で、OS/2 1.x BITMAPCOREHEADER（上の表を参照）と異なります。^[13]

BITMAPINFOHEADER以降のバージョンでは、以前のバージョンのヘッダーの末尾にのみフィールドが追加されます。たとえば、BITMAPV2INFOHEADER はBITMAPINFOHEADERにフィールドを追加し、BITMAPV3INFOHEADER はBITMAPV2INFOHEADERにフィールドを追加します。

統合アルファ チャネルは、文書化されていないBITMAPV3INFOHEADERと文書化されたBITMAPV4HEADER ( Windows 95以降) で導入され、Windows XP のログオンおよびテーマ システム、および Microsoft Office (バージョン 2000 以降)で使用されています。また、 Adobe Photoshopバージョン 7 以降やAdob​​e Flashバージョン MX 2004 (当時は Macromedia Flash と呼ばれていました)などの一部の画像編集ソフトウェアでサポートされています。また、 GIMP、Google Chrome、Microsoft PowerPoint、Microsoft Wordでもサポートされています。

互換性の理由から、ほとんどのアプリケーションは、ファイルの保存に古い DIB ヘッダーを使用します。Windows 2000 以降、OS/2 はサポートされなくなったため、現在のところ、一般的な Windows 形式はBITMAPINFOHEADERヘッダーです。説明については、次の表を参照してください。明示的に指定されていない限り、すべての値は符号なし整数として保存されます。

圧縮方法 (オフセット 30) は次のようになります。

OS/2 2.x OS22XBITMAPHEADER（ IBMのドキュメントではBITMAPINFOHEADER2）には24バイトの追加バイトが含まれています：^[3]

ハーフトーン化アルゴリズム (オフセット 60) は次のようになります。

カラー テーブル (パレット) は、BMP イメージ ファイル内で、BMP ファイル ヘッダー、DIB ヘッダーの直後、およびBI_BITFIELDS (12 バイト) または BI_ALPHABITFIELDS (16 バイト) オプション付きのBITMAPINFOHEADERヘッダーが使用されている場合はオプションの 3 ビット マスクまたは 4 ビット マスクの直後に出現します。したがって、そのオフセットは、 BITMAPFILEHEADERのサイズに DIB ヘッダーのサイズを加えたサイズ (および 3 ビット マスクまたは 4 ビット マスクのオプションの 12 ～ 16 バイト) です。注: Windows CEでは、 BITMAPINFOHEADERヘッダーは、biCompression メンバーのBI_ALPHABITFIELDS ^{[6]オプションとともに使用できます。}

パレットのエントリ数は 2 ⁿ (n はピクセルあたりのビット数) またはヘッダーで指定されたより小さい数です (OS/2 BITMAPCOREHEADERヘッダー形式では、フルサイズのパレットのみがサポートされます)。^{[3] [5]ほとんどの場合、カラーテーブルの各エントリは、青、緑、赤、0x00 の順序で 4 バイトを占めます (例外については以下を参照)。これは、} BITMAPINFOHEADERの構造体メンバー biBitCountでインデックス付けされます。

カラー テーブルは、イメージで使用される色をリストするバイト ブロック (テーブル) です。インデックス付きカラー イメージの各ピクセルは、このテーブルで説明される単一の色のインデックスであるビット数 (1、4、または 8) で説明されます。インデックス付きカラー ビットマップのカラー パレットの目的は、これらの各インデックス値が対応する実際の色をアプリケーションに通知することです。インデックスなし (パレット化されていない) ビットマップのカラー テーブルの目的は、ビットマップで使用される色をリストして、色の表示機能が制限されているデバイスでの最適化を行い、将来的に異なるピクセル形式やパレット化への変換を容易にすることです。

カラーテーブル内の色は通常、エントリあたり4バイトのRGBA32形式で指定されます。OS/2 BITMAPCOREHEADERで使用されるカラーテーブルは、エントリあたり3バイトのRGB24形式を使用します。^{[3] [5]} メモリにロードされたDIBの場合、カラーテーブルはオプションで2バイトのエントリで構成できます。これらのエントリは、明示的なRGBカラー定義ではなく、現在実現されているパレット^[8]へのインデックスを構成します。

Microsoft は、1bpp、4bpp、8bpp のインデックス付きカラー イメージのBITMAPV4HEADERおよびBITMAPV5HEADERに有効なアルファ チャネル ビット マスク^{[15]が存在することを禁止していません。これは、カラー テーブル エントリが RGBQUAD.rgbReserved [16]}メンバーを介して8.8.8.[0-8].[0-8]形式を使用してアルファ コンポーネントを指定できることを示しています。ただし、Microsoft のドキュメントの一部のバージョンでは、RGBQUAD.rgbReserved メンバーは「ゼロでなければならない」と記載してこの機能を禁止しています。

前述のように、ピクセルが 16 ビット/ピクセル (16bpp) 形式 (およびそれ以上) の場合、カラー テーブルは通常使用されません。これらのビットマップ イメージ ファイルには、通常、カラー テーブル エントリはありません。ただし、Microsoft のドキュメント (2010 年 11 月 16 日現在、MSDN Web サイト^[17]上) では、16bpp (およびそれ以上) の場合、カラー表示機能が制限されたデバイスでの最適化を目的とした色のリストを格納するためにカラー テーブルが存在する可能性があると指定されていますが、そのような場合には、このカラー テーブルにインデックス付きパレット エントリは存在しないとも指定されています。必須のパレット エントリとオプションのカラー リストを区別しないと、矛盾しているように見えるかもしれません。

ビットマップピクセルを表すビットは行（ストライドまたはスキャンラインとも呼ばれる）にパックされています。各行のサイズはパディングによって4バイト（32ビットDWORD）の倍数に切り上げられます。^[18]

高さが 1 を超える画像の場合、複数のパディングされた行が連続して保存され、ピクセル配列が形成されます。

1 行のピクセルを格納するために必要な合計バイト数は次のように計算できます。 $${\displaystyle {\text{RowSize}}=\left\lceil {\frac {{\text{BitsPerPixel}}\cdot {\text{ImageWidth}}}{32}}\right\rceil \cdot 4=\left\lfloor {\frac {{\text{BitsPerPixel}}\cdot {\text{ImageWidth}}+31}{32}}\right\rfloor \cdot 4,}$$

2 ⁿ色のnビット/ピクセル (bpp) イメージのピクセル配列を格納するために必要な合計バイト数は、各行のサイズを 4 バイトの倍数に切り上げる効果を考慮して、次のように計算できます。

$${\displaystyle {\text{PixelArraySize}}={\text{RowSize}}\cdot |{\text{ImageHeight}}|}$$

ピクセル配列は、32 ビット DWORD のブロックで、画像をピクセルごとに記述します。通常、ピクセルは「下から上へ」格納されます。つまり、左下隅から始めて、左から右へ、そして画像の下部から上部へ 1 行ずつ格納されます。^[5] BITMAPCOREHEADERを使用しない限り、圧縮されていない Windows ビットマップも、画像の高さの値が負の場合、上から下へ格納できます。

オリジナルのOS/2 DIBでは、色深度の有効な値は1、4、8、24ビット/ピクセル（bpp）の4つだけでした。^[5] 現代のDIBヘッダーでは、1、2、4、8、16、24、32ビット/ピクセル（bpp）のピクセル形式が許可されています。^[19] GDI+では、64ビット/ピクセルも許可されています。^[20]

行の長さを 4 バイトの倍数にするために、行の末尾にパディング バイト (必ずしも 0 とは限らない) を追加する必要があります。ピクセル配列がメモリにロードされるとき、各行は 4 の倍数のメモリ アドレスから始まる必要があります。このアドレス/オフセットの制限は、メモリにロードされるピクセル配列に対してのみ必須です。ファイル ストレージの目的では、各行のサイズのみが 4 バイトの倍数である必要があり、ファイル オフセットは任意にすることができます。^[5]幅 = 1 の 24 ビット ビットマップには、行ごとに 3 バイトのデータ (青、緑、赤) と 1 バイトのパディングが含まれます。幅 = 2 には 6 バイトのデータと 2 バイトのパディングが含まれます。幅 = 3 には 9 バイトのデータと 3 バイトのパディングが含まれます。幅 = 4 には 12 バイトのデータとパディングなしが含まれます。

• インデックス付きカラー画像は、4 ビットまたは 8 ビットのRLEまたはハフマン1D アルゴリズムを使用して圧縮できます。
• OS/2 BITMAPCOREHEADER 2 24bpp画像は 24 ビット RLE アルゴリズムで圧縮できます。
• 16bppおよび32bpp の画像は常に圧縮されずに保存されます。
• 必要に応じて、すべての色深度の画像を圧縮せずに保存できることに注意してください。

• 1 ビット/ピクセル (1bpp) 形式は、2 つの異なる色 (たとえば、黒と白) をサポートします。ピクセル値は各ビットに格納され、最初の (左端の) ピクセルは最初のバイトの最上位ビットに格納されます。^[5]各ビットは 2 色のテーブルへのインデックスです。設定されていないビットは最初のカラー テーブル エントリを参照し、設定されているビットは最後の (2 番目の) カラー テーブル エントリを参照します。
• 2ビット/ピクセル（2bpp）形式は4つの異なる色をサポートし、1バイトあたり4つのピクセルを格納します。左端のピクセルは最上位2ビットになります（Windows CEのみ：^[21]）。各ピクセル値は、最大4色のテーブルへの2ビットのインデックスです。
• 4ビット/ピクセル（4bpp）形式は16の異なる色をサポートし、1バイトあたり2ピクセルを格納します。左端のピクセルはより重要なニブルにあります。^[5] 各ピクセル値は、最大16色のテーブルへの4ビットのインデックスです。
• 8 ビット/ピクセル (8bpp) 形式は、256 の異なる色をサポートし、1 バイトあたり 1 ピクセルを格納します。各バイトは、最大 256 色のテーブルへのインデックスです。
• 1 ピクセルあたり 16 ビット (16bpp) 形式は、65536 の異なる色をサポートし、2 バイトの WORD ごとに 1 ピクセルを格納します。各 WORD は、ピクセルのアルファ、赤、緑、青のサンプルを定義できます。
• 24ビット/ピクセル（24bpp）形式は、16,777,216の異なる色をサポートし、3バイトごとに1つのピクセル値を保存します。各ピクセル値は、ピクセルの赤、緑、青のサンプルを定義します（RGBAX表記では8.8.8.0.0）。具体的には、青、緑、赤の順です（サンプルごとに8ビット）。^[5]
• 32 ビット/ピクセル (32bpp) 形式は、4,294,967,296 の異なる色をサポートし、4 バイトの DWORD ごとに 1 ピクセルを格納します。各 DWORD は、ピクセルのアルファ、赤、緑、青のサンプルを定義できます。

どのビットがどのサンプルを定義するかという曖昧さを解決するために、DIB ヘッダーは特定のデフォルトと特定の BITFIELDS を提供します。BITFIELDS は、ピクセル内の特定のビット グループの特定のチャネルへのメンバーシップを定義するビット マスクです。次の図は、このメカニズムを定義しています。

図 2 – RGBAX サンプル長表記で表現された 32 ビット ピクセルの BITFIELDS メカニズム

BITFIELDS ビット マスクによって定義されるサンプル フィールドは連続していて重複してはいけませんが、サンプル フィールドの順序は任意です。最も一般的なフィールド順序は、アルファ、青、緑、赤 (MSB から LSB) です。赤、緑、青のビット マスクは、DIB ヘッダーの圧縮メンバーが BI_BITFIELDS に設定されている場合にのみ有効です。アルファ ビット マスクは、DIB ヘッダー内に存在する場合、または DIB ヘッダーの圧縮メンバーが BI_ALPHABITFIELDS ^[6]に設定されている場合に有効です( Windows CEのみ)。

図3 – Adob​​e Photoshopで実際に生成された16ビットピクセルのアルファチャンネル付きピクセルフォーマット（RGBAXサンプル長表記）^[22]

DIB で可能なすべてのピクセル形式

上で説明したBITFIELDメカニズムでは、数万種類の異なるピクセルフォーマットの定義が可能ですが、実際に使用されるのはそのうちのいくつかだけです。^[22]パレット化されたフォーマットはすべてRGB8、RGB4、RGB1です（上記の表で黄色でマークされ、dshow.h.MEDIASUBTYPE名で定義されています）。

バージョン2.1.4のFFmpegは（独自の用語で）BMPピクセル形式bgra、bgr24、rgb565le、rgb555le、rgb444le、rgb8、bgr8、rgb4_byte、bgr4_byte、gray、pal8、およびmonobをサポートしていました。つまり、透明度のあるピクセル形式としてサポートされているのはbgraのみでした。 ^[24]

以下は、ピクセル形式が RGB24 である 2×2 ピクセル、24 ビット ビットマップ (Windows DIB ヘッダーBITMAPINFOHEADER )の例です。

以下は、ピクセル形式が ARGB32 で 、アルファ チャネルに不透明度値を持つ 4×2 ピクセルの 32 ビット ビットマップ (Windows DIB ヘッダーBITMAPV4HEADER )の例です。

ビットマップ データは画像の左下隅から始まることに注意してください。

BMP ファイル形式はシンプルで、Windows やその他の環境で広く普及しており、また、この形式は比較的よく文書化されており、オープン形式であるため、BMP は多くのオペレーティング システムの画像処理プログラムで読み取りおよび書き込みが可能な非常に一般的な形式となっています。ICOファイルと CUR ファイルには、BITMAPINFOHEADER で始まるビットマップが含まれています。

多くの古いグラフィカルユーザーインターフェースは、組み込みのグラフィックスサブシステムでビットマップを使用していました。^[25]たとえば、Microsoft WindowsとOS/2プラットフォームのGDIサブシステムでは、 WindowsとOS/2のビットマップファイル形式が特定の形式として使用され、通常はファイル拡張子が付けられています.BMP。^[26]

ほとんどの BMP ファイルは圧縮されていない (またはパレット化された画像では通常低比率のランレングス エンコーディングが使用されている) ためファイル サイズが比較的大きいですが、多くの BMP ファイルは冗長データを含んでいるため、 ZIPなどのロスレス データ圧縮アルゴリズムを使用して大幅に圧縮できます。RAR などの一部の形式には、このようなデータの効率的な圧縮に特化したルーチンも含まれています。

X Window System では、白黒画像には同様のXBM形式を使用し、カラー画像にはXPM (ピクセルマップ) を使用します。また、他の情報なしで生データを保存するさまざまな「raw」形式もあります。Portable Pixmap (PPM) 形式やTruevision TGA形式も存在しますが、あまり使用されず、特殊な目的にのみ使用されます。たとえば、TGA には透明度情報を含めることができます。

• ビットマップ ファイル構造 (digicamsoft.com)
• DIB (デバイス独立ビットマップ) の紹介 (herdsoft.com)
• kalytta.com のシンプルなビットマップ ローダー C++ クラス (A2R10G10B10 はまだ^{[アップデート]}サポートされていません)
• BMP ファイル形式、パート 1、David Charlap 著、Dr. Dobb's journal of software tools (drdobbs.com)、1995 年 3 月