BMPの画素行は下端または上端から始まります。高さの符号とヘッダーを調べ、上下が明確な試験画像を使い、手動反転で不具合を隠さず変換後のPNGとJPGを確認します。
BMP → PNG
BMPにある二つの行方向を理解する
Windowsのデバイス非依存ビットマップでは、画面上の最上行から順に画素が保存されるとは限りません。一般的なBITMAPINFOHEADERでは、高さが正なら画素配列が最下行から始まるボトムアップ、高さが負なら最上行から始まるトップダウンを示せます。デコーダーは符号を読み、保存順を表示座標へ並べ直す必要があります。すべてをトップダウンとして読む実装では、変換結果が上下反転します。
まず、上端にTOP、下端にBOTTOMと書き、片側だけに図形を置いた非対称の試験画像を用意します。幅、高さの符号、ビット深度、圧縮方式をヘッダーから記録し、元BMPを複数のビューアーで開きます。一つのアプリだけが反転するならデコーダーを疑えます。すべてで同じなら、作成元が画素の並びと高さの符号を不一致のまま書いた可能性があります。表示のスクリーンショットだけで判断せず、読み込んだファイル名とハッシュも残せば、別版を見比べた事故を避けられます。
- 高さの符号を確認する
- 非対称の向き確認画像を使う
- 複数のBMPデコーダーで比べる
高さの符号は絶対的な画素数だけでなく、画素行の方向を伝えることがあります。
行順序と別の向き問題を切り分ける
行順序による上下反転は、カメラ画像の回転やExif Orientationの問題とは別です。BMPの不具合をJPEGと同じ前提で診断しないでください。文字が左右正しく読めるまま上と下だけが入れ替わるなら、まず行順序を調べます。90度回転、左右反転、複合的な変形なら、撮影・取り込みアプリ、以前の変換、または表示時に追加された処理を追跡します。
画面キャプチャAPIや古いアプリがDIBメモリーをBMPへ書く際、行配列と高さの符号を誤って組み合わせることがあります。拡張子の変更や完成画像の手動反転は一件の見た目を直すだけで、生成経路の問題を残します。作成アプリ、中間処理、最終コンバーターを記録し、各段階の画像を比較してください。同じ試験画像から正常例と異常例を作れるなら、ヘッダーと先頭付近の行を並べて差を確認します。問題が特定の端末だけで出る場合は、ライブラリやコーデックの版も記録し、再現条件を固定します。
- 反転と回転を区別する
- 生成と変換の各段階を追う
- 正常例と異常例のヘッダーを比べる
行パディングと画素オフセットも調べる
BMPの走査行には、境界をそろえるためのパディングが含まれる場合があります。デコーダーが正しいパディング後の行幅ではなく、見える画素のバイト数だけ進むと、単純な上下反転ではなく、斜めのずれ、色の帯、途中で切れた行が現れます。画素データのオフセット、ビット深度、幅、計算上の一行バイト数を確認します。格納境界に自然に一致しない幅の画像は、都合のよい幅よりパディングの誤りを見つけやすくなります。
パレット形式や圧縮BMPには追加条件があります。非圧縮24ビットの一例が成功しても、すべてのBMP対応を証明しません。実運用に1、4、8ビットのパレット、16または32ビット画素、アルファに似たチャンネル、圧縮形式が含まれるなら、種類ごとに試験します。ヘッダーの位置を推測してバイトを直接書き換えず、保存した原本を仕様に沿うデコーダーで読み、新しい標準出力を書き出す方が安全です。幅が一画素違うだけで症状が変わるなら、行の境界計算を優先して調べます。
- パディング後の行幅を計算する
- 端数の出る画像幅で試す
- 実際に扱うビット深度とパレットを網羅する
斜めのずれや色付きの行は、行方向だけでなくパディングやオフセットの誤りを示します。
PNGとJPGの出力を用途に合わせて比較する
BMPからPNGへの変換は可逆の基準を作れるため、向き、鋭い境界、正確な色の診断に向きます。JPGは非可逆圧縮を使い、アルファチャンネルを持たないので、小さな文字や境界画素の調査には不利です。最初にPNGで行順序と画素を確認し、納品先が必要とする場合だけJPGを作り、JPEG品質や背景合成を別の判断項目として評価します。
元BMP、PNG、JPGを同じ表示寸法で並べ、四隅、最上行、最下行、向き表示を比較します。画像が正立しているかだけでなく、行の欠落、パディング由来の色ずれ、透明度の変化も探します。コンバーターが不整合な元BMPを自動補正した場合は、その事実を記録してください。一つの出力が正しく見えても、別のツールは同じ原本を異なる向きに解釈する可能性があります。縮小プレビューだけでなく100%表示でも確認し、端の一画素を見落とさないようにします。
- PNGを診断用の基準にする
- 最初と最後の行を比較する
- 自動補正の有無を記録する
代表的なBMPを実際の工程で承認する
トップダウンとボトムアップ、複数の幅、パレット画像、実運用の24または32ビット形式を含む試験セットを作ります。実際のBMP→PNGまたはBMP→JPGツールを通し、納品先アプリと独立したビューアーで結果を開きます。上下、寸法、色、アルファ処理、端の行が完全であることを確認します。古い画像キャッシュを見ないよう、新しいファイル名とチェックサムも使います。
元ヘッダー値、作成アプリ、コンバーター版、出力設定、試験環境を記録します。失敗した派生画像を反転して上書きせず、原本へ戻って正しく復号します。最後の実用確認では、向き表示付き試験画像と実際の業務画像を納品サービスへアップロードし、配信された版をダウンロードして端まで比較します。必要なBMPの種類がすべて通過してから一括変換を開始します。
- 両方の行方向を試す
- 古いプレビューキャッシュを避ける
- ダウンロードした配信ファイルを検査する
向き確認画像と実際の業務BMPの両方が通過してから、一括変換を始めます。
要点まとめ
- 一般的なDIBでは、正の高さがボトムアップ、負の高さがトップダウンの行配列を示す場合があります。
- 高さの符号を無視するデコーダーは、画像を上下反転させたり、アプリごとに異なる結果を出したりします。
- 非対称で上下表示のある試験画像とヘッダー値を使い、行順序の問題を回転や撮影時の問題から分離します。
- 変換後は実際の受け取り環境で、向き、寸法、色、行パディング、上下端の行を確認します。
よくある質問
BMPはなぜ最下行から保存できるのですか？
従来のDIBでは正の高さとボトムアップ配列を使え、デコーダーが表示時に上から下の順へ再構成するためです。
BMPの高さが負なら破損していますか？
いいえ。対応するヘッダー形式では、負の高さがトップダウンBMPを意図的に示す場合があります。
変換後に編集ソフトで上下反転すれば十分ですか？
一つの見た目は直せても、デコーダーや生成元の不整合は残るため、後続ファイルで再発する可能性があります。
斜めの画像ずれも行順序の問題ですか？
多くの場合はパディング後の行幅や画素オフセットの計算ミスなので、幅とビット深度も確認します。
変換前の最終確認は何ですか？
向き表示付き画像と実際のBMPを変換し、配信されたファイルで方向、端の行、寸法、色を比較します。