2次元画像処理 BMP 新しいページはコチラ
提供: yonewiki
(→サンプルプログラム創作前の愚痴'17-12-29～'17-01-xx継続中) |
|||
| 3行: | 3行: | ||
== '''概要''' == | == '''概要''' == | ||
| − | + | BMP形式のファイルは比較的読み込み易い形式になってます。最初の54byteがHeader情報になっていて、この中に画像の高さpixelと横幅pixelの情報がありますので、これさえ抜き出せれば、あとはRGBの情報を読み込めば、表示できます。OS/2っていうん？の場合はBIDとか、圧縮方式を適用したRLEという拡張子のものもBMPの仲間っていうか、なんていうか同じものです。 | |
とは言いつつも、それだけでは特殊な形式のBitmapファイルもありますので読み込みエラーに遭遇する可能性がありますし、書き出す時も、もう少し情報をしっかりと最初の決まり事や各バイトの決まり事に従って付与しておかないと他のアプリでも画像を開くことができないというエラーになるようなアプリになってしまう可能性もあります。 | とは言いつつも、それだけでは特殊な形式のBitmapファイルもありますので読み込みエラーに遭遇する可能性がありますし、書き出す時も、もう少し情報をしっかりと最初の決まり事や各バイトの決まり事に従って付与しておかないと他のアプリでも画像を開くことができないというエラーになるようなアプリになってしまう可能性もあります。 | ||
| − | [[ファイル:20161216 BitmapHeaderSample. | + | [[ファイル:20161216 BitmapHeaderSample.png|600px|thumb|none|Bitmapのヘッダーのサンプル]] |
| − | + | ||
== '''ファイル構成''' == | == '''ファイル構成''' == | ||
| 22行: | 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系の短いモノやV4 V5ヘッダーと呼ばれるモノも存在します。全部対応しないとビューワとしては不完全となります。 |
: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''' | ||
| 29行: | 28行: | ||
| − | :28～29 2Byte:カラービット数。24bitColorRGBなら24です。0x18です。0x18,0x00ですね。HTMLの色を#000000～# | + | :28～29 2Byte:カラービット数。24bitColorRGBなら24です。0x18です。0x18,0x00ですね。HTMLの色を#000000～#FFFFFFであらわすあれと同じ表現方法です。ほかにもモノクロの1bitや16色4bit、256色8bit、65535色16bit法(BITFIELDS利用によるRGBをそれぞれ5bitで表現する方法、RGB555やRGB565、RGB655、RGB556)があります。 |
| 49行: | 48行: | ||
:46～49 4Byte:パレット数:色番号1から順番に格納される色情報を画像データとヘッダ情報の間にいれることができます。その色数。正しい情報が入っていない場合もあるみたいです。その場合は28～29で指定される色数情報が優先されて読み込むようになっています。 | :46～49 4Byte:パレット数:色番号1から順番に格納される色情報を画像データとヘッダ情報の間にいれることができます。その色数。正しい情報が入っていない場合もあるみたいです。その場合は28～29で指定される色数情報が優先されて読み込むようになっています。 | ||
:50～53 4byte:重要色数。これが正確に指定されていることも少ない情報です。 | :50～53 4byte:重要色数。これが正確に指定されていることも少ない情報です。 | ||
| + | |||
| + | |||
| + | *'''BitFieldマスク値''' | ||
| + | 30～33 4Byte:圧縮方式が3のBitFieldの場合に使われるヘッダ情報です。それ以外の場合、このヘッダー部分は省略される部分です。省略されない場合は情報量は12byteになります。 | ||
*'''Bitmapパレット''' | *'''Bitmapパレット''' | ||
| − | + | 28～29の部分で、色表現ビット数が8より小さい場合に利用する部分で、それ以外の場合、このヘッダー部分は省略される部分です。 | |
| + | |||
| + | 46～49のインデックス数の指定を信じてよいと思いますが、厳密には全ファイルサイズ n[byte] - ( ヘッダー情報サイズ[byte] + ビットフィールド12[byte]) の情報量の値が指定のパレットサイズと一致していたら、指定の値を採用し、一致していなかったら、論理演算で 1 << (カラービット数(28～29で指定される値))の大きさと考えてよいでしょう。インデックス番号は0番から始まります。最大値は(大きさ - 1)ですね。つまり、8bit/pxなら、論理演算1<<8で求められるパレットの大きさ256で0～255番までのパレットが存在し、WindowsフォーマットならRGBQUADという方式のパレットになり1つのパレットに2バイトづつ、B青,G緑,R赤,予約領域、の値が格納されてビットストリームが連続して記述されています。番号は振られていませんので、順番にパレットの大きさ分だけ読み込んでいきます。8bit/pxの場合が最大で256x4の1024バイトが使われます。1bit/pxの場合は2x4で8バイトっすね。4bit/pxの場合は16x4で64バイトになります。この情報以降はbitmapデータになります。境目はよくわからないのがバイナリー形式です。1つが狂えば、姿カタチは消えてしまうのですから、なんとなく恐ろしいことだと感じてしまいます。 | ||
| 61行: | 66行: | ||
上記のようなビットマップ仕様からすると横幅5ピクセルのビットマップなら、1行のデータを16バイトづつ表示するようなバイナリーエディタでその形を想像することができるような表示がなされます。下から上にデータがつまっているため、像は逆さになりますね。ちなみに縦幅をヘッダー部で負の値として登録すると上から下に像の情報が格納されているとしてデータのつまりかたと実際の描画情報の縦の向きが同じになります。横方向についても同じ法則を持っていますので、左からではなく右から左に描画がなされます。 | 上記のようなビットマップ仕様からすると横幅5ピクセルのビットマップなら、1行のデータを16バイトづつ表示するようなバイナリーエディタでその形を想像することができるような表示がなされます。下から上にデータがつまっているため、像は逆さになりますね。ちなみに縦幅をヘッダー部で負の値として登録すると上から下に像の情報が格納されているとしてデータのつまりかたと実際の描画情報の縦の向きが同じになります。横方向についても同じ法則を持っていますので、左からではなく右から左に描画がなされます。 | ||
| + | == '''BMPファイル 読み込み・書き込みプログラム''' == | ||
| + | === '''サンプルプログラム創作前の愚痴'17-12-29～'17-01-xx継続中''' === | ||
| + | ちょちょっとすればできると思ったんですけど、BMPも実際、プログラムサンプルを作るとなると意外と大変っすね。かれこれ1週間近くしょうもないプログラム組んでる気がする。しょうもないのに時間かかる。Win32/64 おそるべし。やっと24bitと32bitビットマップを24Bit/px32Bit/pxのカラー表示モードのPCでひらけるようになったところです。ちかれた。そのうちサンプルプログラムが出来上がるでしょう。このネットのあちらこちらにあるサンプルなので、それを使う方が早いかもね。ようするにオープンソースでBMPとJPEGとPNGとGIFとTIFFが開けるやつ探せばいいんでしょ。GIMPとかのソースを解読すればええんでしょうか？あとはLibere Officeだっけ、Office.orgの後釜のやつ。ああいうのを解読すれば、読み込む方法と書き込む方法がわかるかもしれない。まぁ、ああいうプロジェクトのはソースの可読性がかなり難しい構造になってるから、簡単には理解できないでしょうけど。何が重要なところかがわかりづらいと思うし、説明もないっすからね。アレを理解できる人は、こういうページには来ないよね。 | ||
| + | |||
| + | |||
| + | まぁ気長に待っていてください。私なりの解説記事を頑張って作ります。ランレングス圧縮BMP、通称RLEと8bitパレット16bitパレットのBMPの読み書きのプログラムができていないっす。LoadImageっていう関数で済むことをちまちま理解しようとすると大変です。JPEGの解説で右往左往すると思ってましたが、ここで1st右往左往っす。 | ||
| + | |||
| + | |||
| + | [[ファイル:201612291218 BitmapOpenProgram.png|600px|thumb|none|Bitmapを開くプログラム開発途中]] | ||
| + | |||
| + | |||
| + | こんな感じですね。自分のPCのデスクトップの状態を惜しげもなく公開です。[[Dynapad N72 N72TGP-NWA (東芝)|Dynapad N72]]は画面が1920x1080というFullHD表示ですが、分解能が細かすぎるため拡大機能が使われています。自分は100%のままでもいいかなとはおもうのですが、125%拡大で使っています。でも、プログラムの方は、なんか違う倍率の表示になってますね。なんじゃこれ？なんか調べなきゃいけないこと増えてるなorz。Live2ch、FL Studio12、ClipStudioPaintEx、MicrosoftOffice Excel2010/Word2010、Chrome、Adobe Creative Cloud/Acrobat DCを追加でインストールしてますね。 | ||
| + | |||
| + | |||
| + | Live2chは基本読むだけですね。書き込むと議論にキリがないということを悟ったのは10年前ごろです。教えても教えても次から次へと質問してくるし、話しても話しても理解してくれない人はいるし、反論する人はいる。反論がないときは、多くの人に読まれてないだけですね。つまり、わかりあえることはほとんどないといって過言でもない。世界平和に挑戦するようなものだ。2chのような場所での議論が好きな人はたくさんいるようです。そういう人に任せることにしました。やっぱねネットのこれからの時代は基本、一方通行これだね。リアル世界で双方向しましょ。 | ||
| + | |||
| + | |||
| + | FLはDAWっすけど、作曲は最近してません。バンドのギターが実際はどんな演奏をしているのか、譜面から入れてみて確認したりという感じです。Clipで絵をかくのは最近のブームです。Officeはやっぱプログラムするのには、あった方が連携するアプリの動作の確認が楽です。あとは、最初から入ってるアプリが優秀なのでソコソコ楽です。このパソコンのおかげで気楽にPCで作業できるのです。いいね♪ | ||
| + | |||
| + | |||
| + | 2017-01-11追記: | ||
| + | |||
| + | いやはや軽い気持ちで書き始めたBMP記事でしたが、奥が深いっす。BITFIELDSの部分までできました。カラーパレットヘッダの読み込みもWindows形式のみ対応です。結構疲れた、時間の無駄のような気がしつつも、一回やり始めたし、ちょこちょこ頑張って終わらせようと思います。こりゃJPEG記事はやめといた方がいいな。と思いました。ん～あとはOS/2対応 WindowsのV4,V5ヘッダ対応とカラーパレット方式の画像データ読み込みおよびRLE-4、RLE-8の画像データ読み込み処理か…あ～あとイメージの高さと横幅情報が負のときの反転処理もだな。メンドイ。で、今日になって、末恐ろしい真実をしってしまったのです。このBMP形式にはマイクロソフト独自のシステム的解釈も存在していて、なんとなく見たことはあったんですがシステムカラーとかっていう画面描画に関する扱いがあるみたいなんです。BMPとプログラムとWindows。複雑。BMPも相当なもんですね。決まりを考えた人たちってすごいなぁ。どんだけの時間を費やして決めたんだろうか…。システムカラーについて知る必要があるのかは、BMPとのこれからの関係性と重要性をよく考えてから記事にしたいと思います。あまり必要にならないことは書かないほうがいいよね。 | ||
| + | |||
| + | |||
| + | 2017-01-14追記: | ||
| + | |||
| + | あとは、OS/2対応 WindowsのV4,V5,反転…あとちょい。 | ||
| + | |||
| + | 2017-01-19追記: | ||
| + | |||
| + | できた。と思ったけど、これから、バグだし作業です。一回もテストせずにプログラムを作ってしまった。愚かよのう。うまく動いたら、すぐに記事を更新できるだろうし、動かなければ、泣いて寝る日々だな。これだけ壮大なプログラムが動作するとはとても思えない。 | ||
| + | |||
| + | |||
| + | 2017-02-27追記: | ||
| + | |||
| + | RLE4の読み込みさえできていない。画像表示が全然、元の画像と異なる！やべぇ。まじでやべぇ。意味わからん。元に戻らない。おかしい。おちつけオレ。なんつうか、ほど遠い、仕様どおり展開してるつもりだけど、うまくいっていない。ややこし過ぎる。JPEGなんて夢のまた夢。orz。無能過ぎるオレ。つうか、あんまりやる気が沸いていないのが正直なところ。こういう時は直すより、いちからやり直した方が早いとも聞く。どうしたもんやろ… | ||
[[2次元画像処理]]の項目へ戻る | [[2次元画像処理]]の項目へ戻る | ||
