フルカラービットマップからグレースケールビットマップへの変換（２）--ビットマップのデータ構造

前エントリの最後に書いたバグの話です。

（１）に示したコードのバグ

前エントリで示したコードでは、壁紙サイズ等の無難なサイズの画像ではうまく動きますが、半端な画像サイズでは、以下のように、出力結果が不正となります。

実際にどのような画像で不具合が出るのかを知るためには、ビットマップのピクセルデータの構造を知る必要があります。
実際の構造は、

ビットマップデータ
このブロックは、イメージを各ピクセルごとに記述する。ピクセルは通常左から右へ、下から上に向かって保存されている。各ピクセルは1バイト以上で記述されている。もし水平方向のバイト数が4の倍数ではないときは、ヌル (0x00)で埋めて4の倍数にする。
Windows bitmap - Wikipedia

となっており、1行あたりのバイト数が4の倍数にならない場合、バグが発現することになります。

上記で示した画像のサイズは、222×628となっており、入力画像(24bitカラー)の1行あたりのバイト数は222×3＝666バイトとなります。これを4で割ると、144余り2となるため、入力画像が、1行あたり2バイトずつずれてしまうことになります。また、出力画像(8bitグレースケール)の1行あたりのバイト数は222×1＝222バイトとなり、これを4で割ると、55余り2となるため、出力画像も、1行あたり2バイトずつずれてしまうことになります。

これを改善するためには、1行あたりのずれを考慮し、ピクセルデータのインデックスにオフセット値を加える必要があります。
以下にコードを示します。


これにより、冒頭で示したバグが改善されます。