Rawデータの画面表示について

Question

Rawデータから読み込んだ画像を表示したいのですが、
なぜか斜めに表示されてしまいます。

Rawデータはfreadにて読み込んでいます。
その後、何の加工もしないまま「StretchDIBits」にて表示させると、右シフトしたような画像になります。

==================
□□□□□□□□□■□□
□□□□□□□□□■□□
□□□□□□□□□■□□
□□□□□□□□□■□□
□□□□□□□□□■□□
□□□□□□□□□■□□
□□□□□□□□□■□□

           ↓

==================
□□□□□□□□□■□□
□□□□□□□□■□□□
□□□□□□□■□□□□
□□□□□□■□□□□□
□□□□□■□□□□□□
□□□□■□□□□□□□
□□□■□□□□□□□□

バイナリエディタにて、読み込んだ後の画像を書き出し
ビットシフトなどをしていないことを確認しています。

StretchDIBitsの最後のパラメーターは、
DIB_RGB_COLORSとSRCCOPYです。

ざっくりとした情報で申し訳ありませんが、
助言をいただきたく、投稿させていただきます。

よろしくお願いいたします。

Answer 1

外しているかもしれませんが、ここで言われているRawデータというのがbmpフォーマットだとしたら、１ラインあたりの画素数が４で割り切れないためパディングデータが含まれているのではないでしょうか。
そのせいで位置計算が少しずつずれていくのではないかと思います。
bmpフォーマットについては下記のような参考サイトを確認してみてください。
参考サイト

Comments

[TEC_S]

コードも載せずに、すみません。

```ここに言語を入力
USHORT buff[h][w];

FILE *fp = fopen(Rawデータファイル, "rb");
if(fp != NULL)
{
for(i = 0; i < y_size; i++)
fread(buff[i], x_size * 2, 1, fp);
}

StretchDIBits( HAWN, 0, 0, x_size, y_size, 0, 0, x_size, y_size, buff, lpbuff, DIB_RGB_COLORS, SRCCOPY);
```

となっております。
image[3][h][w]にしても、特に変化はありませんでした。。

[TEC_S]

文章の追加漏れ

[KoichiSugiyama]

x_sizeの具体的な値はどうなっていますか？x_size * 2 が4で割り切れなかった場合、ファイルポインタを2つ進めて次の行を読み込ませるとうまくいくのではないかと思います。

[TEC_S]

ありがとうございます。
仰るとおり、割り切れないため起きていたのだと思います。

Answer 2

たしかGDIでは16bitグレイスケールはサポートしていなかったように思います。555または565の16bitRGBなら扱ったことがありますが……。

表示するだけであれば、以下のような感じでやった方が無難かと思われます。

USHORT buff[w];
FILE *fp = fopen(Rawデータファイル, "rb");
if(fp != NULL)
{
  for(y = 0; y < y_size; y++)
  {
    fread(buff, x_size * 2, 1, fp);
    for(x = 0; x < x_size; x++)
    {
      BYTE lvl = (BYTE)(buff[x] >> 8);
      ::SetPixel(HAWN, x, y, RGB(lvl, lvl, lvl));
    }
  }
}

もしパフォーマンスを気にするのであれば、やはり24bitまたは32bitRGB等のDIB形式への変換が必要になりますね。
「CreateDIBSection」という直接メモリ操作可能なビットマップを作成するAPIがあります。GDIでの描画処理では欠かせないテクニックです。

Comments

[TEC_S]

ご回答、ありがとうございます。
8bitへの変換、参考になりました。

Answer 3

こんにちは。

まず、このご質問の続きですね？

さて、そもそもWindowsってグレイスケール画像を直接はサポートしていなかったと思います。
8ビットグレイスケールの画像なら扱ったことがあるのですが、その時は、BITMAPINFOのbmiColorsを256個のRGBQUADの配列として、(0,0,0,0), (1,1,1,0), (2,2,2,0), ..., (255,255,255,0)を設定することで8ビット・グレイスケール画像を表現していました。
しかし、RGBQUAD配列がRGBをそれぞれ8ビットで表現するので、16ビット・グレイスケールを直接表示することはできないと思います。
なので、8ビット・グレイスケール画像に並び替えてから、bmiColorsを上記のように指定した上で他のBITMAPINFOも適切に設定すれば表示できるようになる筈です。

Windows標準のpaintで256色ビットマップ画像を保存してバイナリ・エディタ等でダンプ後、この辺を参考にBITMAPINFO構造体の設定方法を確認されると良いと思います。

WindowsのビットマップはWindowsが生まれた当初より存在するので歴史的な要因で複雑なのです。

Comments

[TEC_S]

こんにちは。
回答ありがとうございます。

そのとおりです。
その質問の続きになります。

他の方に頂いた内容と合わせると、、
16bitグレースケールから32bitのRGBタイプへの変換が必要という理解で合っていますか？？

そのため、
8bitで読み込み、並び替えてから、RGBへ変換、、、
ということをしなければいけないという事でしょうか。

申し訳ありませんが、ご教授ください。

[Chironian]

私からの提案は8ビット・グレイスケールにするものですが、32bits RGBへの変換でも良いと思います。どちらの場合でもそれなりに手間はかかりまので、TEC_SNさんがまず理解できた方法で行うのが良いです。

ちなみに、もし、lpbuff->bmiHeader.biBitCountを24にしているようでしたら、これを16へ変更するだけで取り敢えず線がまっすぐにはなるだろうと思います。色はめちゃくちゃですし、使い物にはなりませんが、動きが少し見えてくるかも。

> 8bitで読み込み、並び替えてから、RGBへ変換、、、

16bitのまま読み込んで、並び替えた方が楽と思いまよ。

[TEC_S]

lpbuff->bmiHeader.biBitCountを16にして、言われている事の理解が出来ました。
ありがとうございます。

ご提案通り、8bitへの変換を行いたいと思います。

Answer 4

あまり情報が無いので、正しい回答かどうかわかりませんが、
コピー元と、コピー先のビットマップの定義が違うのではないかと思います。

ソースの、RAWはどのようなビットマップでしょうか？
RGBRGBRGB・・・？

コピー先のデバイスコンテキスト(hdc)は何ビットで作成された物でしょうか？
私などは、便利なので32ビットビットマップをよく使います。その場合には、
RGBxRGBxRGBX・・・
となるので、上記のRAWのようなデータは書き込みと、ビットずれのような表示となります。

StretchDIBitsなのでビットマップ構造の影響を受けます。
※なお、StretchBltならビットマップ構造はあまり関係ありません。

・RAWのビット並びの確認
・StretchDIBitsの第一引数のhdcがどのようなビットマップかの確認
・あとは、dwRopのラスタオペレーションがSRCCOPYですが、この辺りの組み合わせも問題になります。
・そもそもソースがWindowsBitmapじゃないとか？MACのビットマップとか？

という所かと思います。
何かのヒントになれば。。。

Comments

[TEC_S]

早期ご回答、ありがとうございます。
また、情報不足、申し訳ありません。

コピー元は、16bitグレースケールです。
そのため、image[h][w]のような形で読み込んでいます。
ここを、image[3][h][w]のように読み込み、表示する必要があるということでしょうか。

少しコードをいじってみたいと思います。

[ItoTomonori]

コピー先の、hdcの形式によって、合わせていく必要があります。
StretchDIBitsの第一引数のhdcに合わせた形式にしてあげれば、素直に表示されるかと思います。そのあたりご確認いただければ。

[TEC_S]

すみません。コメント先を間違えました。