2次元画像処理 BMP 新しいページはコチラ
提供: yonewiki
(→概要) |
|||
3行: | 3行: | ||
== '''概要''' == | == '''概要''' == | ||
− | + | BMP形式のファイルは比較的読み込み易い形式になってます。最初の54byteがHeader情報になっていて、この中に画像の高さpixelと横幅pixelの情報がありますので、これさえ抜き出せれば、あとはRGBの情報を読み込めば、表示できます。OS/2っていうん?の場合はBIDとか、圧縮方式を適用したRLEという拡張子のものもBMPの仲間っていうか、なんていうか同じものです。 | |
とは言いつつも、それだけでは特殊な形式のBitmapファイルもありますので読み込みエラーに遭遇する可能性がありますし、書き出す時も、もう少し情報をしっかりと最初の決まり事や各バイトの決まり事に従って付与しておかないと他のアプリでも画像を開くことができないというエラーになるようなアプリになってしまう可能性もあります。 | とは言いつつも、それだけでは特殊な形式のBitmapファイルもありますので読み込みエラーに遭遇する可能性がありますし、書き出す時も、もう少し情報をしっかりと最初の決まり事や各バイトの決まり事に従って付与しておかないと他のアプリでも画像を開くことができないというエラーになるようなアプリになってしまう可能性もあります。 | ||
− | [[ファイル:20161216 BitmapHeaderSample. | + | [[ファイル:20161216 BitmapHeaderSample.png?|600px|thumb|none|Bitmapのヘッダーのサンプル]] |
== '''ファイル構成''' == | == '''ファイル構成''' == | ||
21行: | 21行: | ||
※符号なし整数部はリトルエンディアン方式なので 10~13の情報は54ビットを表すためには0x00,0x00,0x00,0x36を逆順にならべて0x36,0x00,0x00,0x00になります。 | ※符号なし整数部はリトルエンディアン方式なので 10~13の情報は54ビットを表すためには0x00,0x00,0x00,0x36を逆順にならべて0x36,0x00,0x00,0x00になります。 | ||
− | *'''Bitmap情報ヘッダーWindows系''' | + | *'''Bitmap情報ヘッダーWindows系''' OS/2系の短いモノやV5 V6ヘッダーと呼ばれるモノも存在します。全部対応しないとビューワとしては不完全となります。 |
:14~17 4Byte:情報ヘッダのバイト数。24bitColorRGBファイルなら40byteなので、0x28です。0x28,0x00,0x00,0x00ですね。 | :14~17 4Byte:情報ヘッダのバイト数。24bitColorRGBファイルなら40byteなので、0x28です。0x28,0x00,0x00,0x00ですね。 | ||
:18~21 4Byte:'''画像の横幅pixel''' | :18~21 4Byte:'''画像の横幅pixel''' | ||
87行: | 87行: | ||
2017-01-11追記: | 2017-01-11追記: | ||
− | + | いやはや軽い気持ちで書き始めたBMP記事でしたが、奥が深いっす。BITFIELDSの部分までできました。カラーパレットヘッダの読み込みもWindows形式のみ対応です。結構疲れた、時間の無駄のような気がしつつも、一回やり始めたし、ちょこちょこ頑張って終わらせようと思います。こりゃJPEG記事はやめといた方がいいな。と思いました。ん~あとはOS/2対応 WindowsのV4,V5ヘッダ対応とカラーパレット方式の画像データ読み込みおよびRLE-4、RLE-8の画像データ読み込み処理か…あ~あとイメージの高さと横幅情報が負のときの反転処理もだな。メンドイ。で、今日になって、末恐ろしい真実をしってしまったのです。このBMP形式にはマイクロソフト独自のシステム的解釈も存在していて、なんとなく見たことはあったんですがシステムカラーとかっていう画面描画に関する扱いがあるみたいなんです。BMPとプログラムとWindows。複雑。BMPも相当なもんですね。決まりを考えた人たちってすごいなぁ。どんだけの時間を費やして決めたんだろうか…。システムカラーについて知る必要があるのかは、BMPとのこれからの関係性と重要性をよく考えてから記事にしたいと思います。あまり必要にならないことは書かないほうがいいよね。 | |
[[2次元画像処理]]の項目へ戻る | [[2次元画像処理]]の項目へ戻る |