画像処理

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その５

myugaru (myugaru@wankuma.com) — Fri, 21 Mar 2008 15:53:00 GMT

●前回まで

[画像処理](x1,y1,x2,y2) vs (x,y,width,height)
[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その２
 [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その３
 [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その４

※以下PnPとPnSは私の造語です。
PnP・・・Point and Point。座標２つで矩形領域を表す方式
PnS・・・Point and Size。座標１つと領域のサイズで矩形領域を表す方式

前回はGDIとGDI+の矩形描画の仕組みを私なりに書いてみました。
しかし色々と調査してみるとGDIの「内接する矩形を描画している」という解釈はどうやら不正解のようです。
●線分描画アルゴリズムからの考察
説明のために縦の辺についてだけ抜き出します。
前回説明を省きましたが緑が仮想座標上の辺、
青が実際のディスプレイに表示されるピクセルです。

内接すると仮定すると図１（A)のようになります。

緑の線に対して青のピクセル位置を求めようとすると、
左右のそれぞれ別の（線分描画の）計算が必要となります。
果たして縦線を２通りの計算で求めるなどわざわざやるか？という問題です。
その可能性は０では無いでしょうが、どの縦線も同じ計算で求めていると考えた方が自然ではないでしょうか？
そしてその場合は図１（B)のようになります。
するとこれはRightは-1した値を用いて計算するという事になります。
あるいはLeftを+1する説も考えられますが数学の世界で上限を未満で表現する体系がありますのでRight-1という解釈の方が妥当だろうと思います。

ここにきて「GDIは右下座標を用いない。左上以上、右下未満で範囲指定する」
という俗説がやっぱり正解なんだなあとわかります。
なんとか別の説をひねり出したかったのですが今日の所はあきらめます。

●線幅について
前回の最後で考慮がもれていると書いたアレは線幅でした。
線幅をテストできるように実験プログラムを修正しました。
http://myugaru.wankuma.com/GDIvsGDIplus.zip
見やすいようにグリッドも表示しています。

GDIの矩形(塗潰し)Left=2,Top=2,Right=8,Bottom=8を線幅1～3で表示すると次のようになります。

こうしてみると線幅２の時は緑の線が青の中心を通っています。
線幅１や３の場合には中心がピクセル中央となってしまいますので、
誤差の０．５だけ右下方向へずらして描画しているようです。

すでにGDIの矩形は内接矩形の描画では無いだろうと書きましたが、
線幅２以上の矩形の図の説明を内接矩形でするとかなり無理が生じます。
そういう意味でもやはり内接矩形論は正しくないのだろうと考えられます。

●GDI+の線幅2以上はどうか
GDI+について線幅2以上で書くとGDIと全く同じ考え方になっているとわかります。
つまり線幅が偶数の場合は緑の線が青の中心を通り、
線幅が奇数の場合は緑の線の右下へ0.5ずれるという仕様です。
●まとめ
GDIもGDI+もどちらも上の緑の線で表現されるような仮想図形を想定しており、
ディスプレイのピクセルで表現する際に誤差が生じているのだとわかりました。
ディスプレイ主体で考えると色々な疑問が生じるのはそのせいです。
また矩形描画について実験した結果はGDIもGDI+もどうやら誤差の扱い方は同じだということもわかりました。
またGDIは右下を使用しないという仕様を再確認できました。
●次回
このシリーズは私は結構おもしろいと思ってやっていますが、
読んでる人はそろそろ飽きて来たのではないかと思っています。
昨日書いたリバースエンジニアリングの話にしてもいいかなと思ったり、
あるいはUMLの勉強で序章が終わりましたので、
ゲーム製作の方を進展させるのもいいかなと思っています。

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その４

myugaru (myugaru@wankuma.com) — Tue, 18 Mar 2008 12:39:00 GMT

●前回まで

[画像処理](x1,y1,x2,y2) vs (x,y,width,height)
[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その２
 [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その３

前エントリー最後に示した「横４ドット縦３ドットの矩形を表示する」について。

色々なコメントいただいたことも踏まえて、

GDIとGDI+で出てきた答えに私なりの解釈をつけてみます。

ご注意：私の解釈は本当に軽いものです。

いわば円周率とか年号を歌で丸暗記するのと同じく、

「こう考えたら頭に入りやすいかも～」くらいのすっごい軽い解釈です。

くれぐれも鵜呑みにして他の人に話しとかしないようにしてください。

きっと後悔しますよ＞＜

●GDIのRectangleの私の解釈
座標軸はピクセル間を通っており与えられた矩形領域に内接する矩形を描画していると解釈。

Rectangle(hdc,0,0,4,3)

●GDI+のGraphics.DrawRectangleの私の解釈
凪瀬さんがコメントしてくれたJAVAの仕組みそのままだと解釈します。

「座標軸は無限に細く、出力デバイスのピクセル間に存在します。
図形の輪郭を描く操作は、ピクセルサイズのペンをピクセル間の無限に細い輪郭線に沿って動かしていくことによって動作します。
ペンは、輪郭線のアンカーポイントにぶら下がり、かつ右側に位置しています。」

Graphics.DrawRectangle(pen, 0, 0, 3, 2)

●GDI+のGraphics.FillRectangleの私の解釈
DrawRectangleと矩形領域の定義までは同じで内接する矩形を塗りつぶしていると解釈。

Graphics.FillRectangle(pen, 0, 0, 4, 3)

●アレを考慮していない
何とか上手く誤魔化せたかな？とか思っていたんですが

「ん？アレを考慮してないぞ・・」

というアレに思い当たってしまいました。

実験してみなければわからないのですが、

場合によっては上の解釈は自分でいきなりぶっ壊してしまうかもです（汗。それは一体なんの事でしょう？

続きは次のエントリーへ引っ張ります・・・

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その３

myugaru (myugaru@wankuma.com) — Mon, 17 Mar 2008 17:22:00 GMT

●前回まで

[画像処理](x1,y1,x2,y2) vs (x,y,width,height)

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その２

(3/18 1:00 「長方形」という表現を「矩形」に改めました。恣意のさんご指摘ありがとうございました。)

前回までの私の書き方もまずかったのですが、
注意深く考えるとこの話には２つの問題が隠れています。

１．PnPとPnSの違いでミスをする、という話

つまりこれが一般的なPnPとPnSの話です。
まずPnPとPnSの違いは第３第４引数が座標か大きさかという違いです。
第３引数＝第１引数＋大きさ横、第４引数＝第２引数＋大きさ縦
なのか
第３引数＝大きさ横、第４引数＝大きさ縦
なのか。

サイズを先に頭に思い描いた時、PnPでは足し算という手間が発生しうっかりミスをする、という問題になるかと思います。

（逆に２点を先に思い描けばPnSで引き算が発生します。同じことです。）

VS2008環境なら引数リストはヒントで表示されますので、
よっぽど慌てなければ間違うことは少ないと思います。
ということは・・・この問題は「慣れればどっちでもよい」で解決！？（汗

２．実際の図形の大きさが分からないという話

一般的なPnPとPnSの比較で考察を進めようと思ったんですが、
あまりこの２つの間に対立している技術ってなさそうですね？？
なのでGDI vs GDI+の話に当面なりそうです。

そしてGDI vs GDI+の話になればPnPとPnSの違いよりも
ここで取り上げる描画ルーチンの特性の違いの話の方が問題は大きそうです。

まず最終目標を「横４ドット縦３ドットの矩形を表示する」とします。
第１第２引数が0であればPnPとPnSの違いによる足し算問題は
考慮しなくてすみますので左上は原点(0,0)としましょう。
矩形の描画はGDIに1種類、GDI+には2種類用意されています。（※１）

GDI：Rectangle(hdc, x1, y1, x2, y2)
GDI+：Graphics.DrawRectangle(pen, x, y, width, height)
GDI+：Graphics.FillRectangle(pen, x, y, width, height)

さてこれらにどういう引数を渡せば最終目標をディスプレーに実現できるでしょうか？
答えがすぐに分かる人は相当にGDI/GDI+に慣れ親しんだ方でしょう。

※１：
この種類数の違いは思想（発想）の違いにあります。
GDIに機能が少ないわけではありません。
ここではGDIのメソッドはGDI+の2つのメソッドの機能を
合わせ持っているという感じの理解でいいです。
（私はそれで困った事はないです）

答えは、

GDI：Rectangle(hdc, 0, 0, 4, 3)
GDI+：Graphics.DrawRectangle(pen, 0, 0, 3, 2)
GDI+：Graphics.FillRectangle(pen, 0, 0, 4, 3)

いつもの注意：
ここに書いている事柄は一度は必ず実物でご確認ください。
前エントリーに示したPnPPnSを使えば簡単に確認できます。
あるいは私のプログラムに頼らず自作するのも素敵だと思います。
確認せずに納得・推論を進める事は自己責任でお願いいたします。

さてこの結果を見ていくつか疑問が出てきませんか？

疑問１
GDIはPnPなので第３第４引数は右下座標のはず。どうして(・・・3,2)とならないのか？
疑問２
GDI+のDrawRectangleは第３第４引数は大きさのはず。どうして(・・・4,3)とならないのか？
疑問３
FillRectangleは”大きさ”という意味では(・・・4,3)で合っている。
しかしDrawRectangleと同じ数値でないのは変じゃないのか？

●疑問がでてしまうのは・・・

これは、そもそも画像処理ライブラリが「何を描画して」いるのかを理解していないために起きる疑問でした。

私は頭では色々と理解はしているつもりですよ。

でもやっぱりお手軽に画像処理を楽しみたいってのも私にはあります。

そこらへんをあえてブラックボックスとしてフィーリングで何とか理解できないかなあって思っていたりもします。

●続きは次のエントリーへ

全然進展してませんねえ。まあ今私UMLの勉強中であまり面白そうなことがおもいつかないのですよ。なのでしばらくこんなエントリーばっかりかもです（すみません）

●本日のアテにならないかも「知れない」

・GDI+はWindowなどのPnS思想にただ合わせただけかも知れない。
・GDI+はJavaの描画にただ合わせただけかも知れない。

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その２

myugaru (myugaru@wankuma.com) — Sun, 16 Mar 2008 20:07:00 GMT

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) の続きです。

色々確認用のプログラムを作りました。~~→PnPPnS.zip~~

~~23:22緊急追記~~

~~すみません先ほどのPnPPnSはバグがありました。~~

~~新しい方を申し訳ありませんが再度ダウンロードください。→PnPPnS_2.zip~~

3/17 7:40

コンボボックスの動作を少し変えました。→PnPPnS_3.zip

というか前に作ったShape確認プログラムをちょろっと改造しただけです。

(参考：Shape.zip - Shapeクラス（2007/12/12更新）
ブログ→http://d.hatena.ne.jp/myugaru/20071211）

とりあえず動かせる方は動かしてみてください。

~~なんか机上の空論はダメですね。~~

~~現実は私には意外な結果が出ました・・・。~~

23:25追記

すみません。バグを直したら予想通りの結果になりました。

意外なのはバグのせいでした＞＜；；；お騒がせしました。

・・・明日これらの結果はまとめます。

[画像処理](x1,y1,x2,y2) vs (x,y,width,height)

myugaru (myugaru@wankuma.com) — Sun, 16 Mar 2008 08:16:00 GMT

●私と画像処理～なぜか今頃まともな自己紹介？～

誰でもパソコンでプログラムを作っていると画像処理には興味を持ったりすると思う。
聞くところによればVisualじゃないBASIC世代な先輩たちはLINE文やCIRCLE文やPSET文などで手軽にお絵かきを楽しんだそうだ。でも最近の画像処理技術の向上は目覚しく、特にハードウェア(GPU)の急速な進歩もあって、一から画素を扱うようなプログラミングはちょっと手軽には手が出しにくいところまで来ているように思う。逆にツールは充実しているのでそういう意味からもプログラムで画像を作る意味は違ってきたのかもしれない。

さて私はといえば・・・実は私もLINE文やCIRCLE文は使ったことがある。
小学生の頃に学校にたった一つしかなかったパソコンを校長先生に無理に頼んで使わせてもらって遊んだ思い出がある。それから××年。今でもプログラムで線や円を書くのは大好きだ。
わんくま同盟のブログタイトルを考えたときにサブタイトルに速攻で画像処理を入れたくらいに愛している。

あの頃から今まで私の対象は主に２次元画像処理で当然GDIやGDI+には結構お世話になっている。でも、だからといって何か作品を作っているかと言えば・・・まともに人様にお見せできそうなやつはWindowsNT4.0+VC5.0時代に作った簡単なカードゲームくらいかも知れない。

私が特に興味を持って勉強していたのは画像ファイルフォーマットで、有名どころのBITMAPやJPEGはもちろん、ご存知の無い人が多そうなマイナーフォーマットまで多くの文献を読みあさった。そしてほとんどのフォーマットのSusieプラグインをVC6.0で自作してきた。この中には今でこそ著作権も切れて公言できるがGIFのデコーダも含まれている。

あと他には自作テキストエディタなどにも挑戦した。画像処理とは一見関係ないが一応USER DRAWでGUIを作っていたので多少は関係があるように思う。これはあまり出来が良くなくて・・・というか優秀なエディタはいくらでも世に出回っていたので中途半端に投げ出した。

人に説明しづらい物作りにかまけている間に気付くと世の流れに乗り遅れてしまい、今頃からやっとDirectXの勉強をしているしだいである。

なんだか今頃ちゃんと自己紹介している。
最近文章力が上がった（※嘘。上がってませんから）ので急にたくさん自分の事も書いてみたくなったのだ。

・・・では、さっさと本題に入ります。

●矩形領域を表す異なる2つの手段

GDIもGDI+も図形描画ルーチン呼び出しは必ず座標を必要とする。
その中でも特に矩形領域を表す４数値を渡す関数は少なくない。
４数値の使い道は以下の２パターンがある。

１．Point & Point（２つの点。以降P&P）
２．Point & Size（１つの点と領域の大きさ。以降P&S）

タイトルの意味するのは関数引数形式で２パターンを表現したものだ。

（※P&P、P&Sは私の造語です）

（修正9:30 「平面」という表現を「長方形の領域」に改めました. れいさんご指摘ありがとうございました）

（修正3/18 1:00 「長方形」という表現を「矩形」に改めました。恣意のさんご指摘ありがとうございました）

●なぜGDI+はGDIの方式をやめたのか

実際に数えたわけではないが私の使ってきた関数たちは経験的に、
GDIはP&Pが多くGDI+はP&Sが多いように思う。
私の画像処理人生ではGDIの占める割合は多くGDI+はつい最近の技術と感じている。
そのせいか私はGDI+を使っていて方式の差異によるミスをよく起こしてしまう。
GDI+から初めて使用している人や、ちゃんと引数を確認して使うような人にとってはGDIとの比較に意味もないのだろう。
そういう方たちには「やめた」という表現は色々語弊もあるだろう。
しかしGDIに結構慣らされてしまった私の目には十分「やめた」ようにしか見えず、多少なりとも被害も被っていると思っている。

同じMicrosoft社のライブラリであるGDIとGDI+。どうして両者は方式に違いが出来てしまったのだろう？

私の様なGDI漬けユーザーを切り捨ててまで実装方式を変える意味とは何だろう？

●とりあえず。

ここからですます調です（笑

私なりに

勝手にまとめて叩かれる(inspired R.Tanaka.Ichiro)

ってのもアリですが（汗。

せっかく盛り上がりそうな話題なので一回目は私は何も書かずに、

色々な人からコメントとかトラックバックとかを読ませてもらいたいなあと勝手に決めました（笑

特にGDIとGDI+の対決じゃなくてP&PとP&Sの対決でもいいので何かまとめられたら嬉しいなあって思っています。

でも反応が薄そうならば（泣）一応私の方ではそれなりに連載できるくらいの断片的推測を用意しています。

それをこれから時間を見つけてシリーズ化して書き出すのもアリなのかなあと思います。

（意外とあっさり結論が出たりするかも知れませんが、それはそれで助かります）

●本日の「知れない」
・０ベースvs１ベース問題もこっそり関係しているかも知れない。
よくわかるかも知れない図

■■■■
■■■■
■■■■
P&Pだと(0,0,3,2)
P&Sだと(0,0,4,3)

(。-｀ω´-)＜「勝手に見つけ出した先輩たちの0ベースvs1ベース問題エントリー」

囚人さん→0 ベース vs 1 ベース
επιστημηさん→どんだけ～?
やまださん→0 ベースなんだけど……
凪瀬さん→数の数え方

（いえ、特にお呼びたてするつもりではありませんが・・・）

・多くの要求を満足するのは突き詰めればP&Sかも知れない。
なぜならP&Pでは「完全に描画しない」を表現できない。

3/17こっそり追記

とても重要な注意：私の書いてることを鵜呑みにしてはいけません。私の書いていることを確認せずに推論を進めることは自己責任でお願いいたします。最後の方の「知れない」コーナーは特に信用なりません。

３．自分で必ず試す
重要です。人の書いてる事を鵜呑みにしてはいけません。

myugaru Google先生だけでがんばる（その１）投稿日時 : 2008年3月8日 10:08 より

です。

Pixel-to-Pixel速度比較（観点が不明確だった）

myugaru (myugaru@wankuma.com) — Sat, 15 Mar 2008 19:55:00 GMT

今日は「Pixel-to-Pixel速度比較」のまとめをしたかったのですが、

うっかり大変なことを忘れておりました。

家族でちょっとしたイベントのある夜だったのです。

・・・ということであまり綺麗にまとめる時間がなくなってしまいました。

でもざっくり書いてみます。（あとで修正するかもしれません）

25:00追記

前回「ある条件」って書いてたのでそれに即して書き記します。

私が目的にしていることはDirectXで背景画をリアルタイムで書き換える手段の検討でした。

目的から考えれば手段としてはGDI+に頼ること自体が方向性として微妙だったなと途中で気付いたのです。

つまり「私がやりたいことはライブラリImageUtilsで処理を書く必要があるかどうか」という条件だったわけです。

流れる星などのエフェクト効果はピクセルで描画できたら実装できそうに思いました。そこからGDI+へ考えを進めるのではなくてDirectXのピクセルレンダリングのパスへそういうピクセル単位でのドットON/OFFを設定できるのかという方向へ話をもっていくべきでした。この話の方向はいづれ考えてみようと思います。

そういうわけですが。

たとえ微妙方向性だとしても乗りかかってしまった船なので、とりあえずこのエントリーは決着は付けようと思っています。

●ColorMatrixが速いのはおかしい

私は実は計測する前からLockBits/UnlockBitsの方が速いと予想していました。

（追記：前回納得できていない、と書いたのは、上の追記に書いたとおり話が微妙だってたことに気付いたのもありますが、予想が外れていて納得できないという意味もありました）

前回ColorMatrixが速くなったような結論が出たのは、

速度重視思想だけでは無いImageUtilsを使用したためだと考えれば納得できます。

●作者junkiさんの記事

Bitmap の内部色データにアクセスする (1)

「このコードは、前回の配列コピーの場合より、さらに４倍以上速い。この方法は unsafe{} ブロックを含むが、もっとも高速なので以後はこの方法を使うことにする。」

この時点ではライブラリでunsafeを使用する事を考えていらっしゃいました。

Bitmap の内部色データにアクセスする (3)

「図は、今回つくったクラスをつかって画像のすべてのピクセルの R 成分と G 成分を入れ換えたものである。ここでテストしたように、前回の unsafe コードに比べると３－４割時間がかかって遅くなるが、なによりポインタをあらわに使わないで済むことは重要である。」

しかしunsafeを使用するデメリットなどをjunkiさんなりに考慮された上で最終的には時間がかかってもunsafe未使用方式を採用に到っておられます。

●まとめ

ライブラリImageUtilsの思想は「GDI+の描画処理で加工できないBitmap（具体的には８ビットのカラーパレット式ビットマップなど）を加工できる」という事を可能とするライブラリでした。

私がそのImageUtilsを使って処理を書きたいのであればColorMatrixでは処理を書けないということになります。

私が扱う画像がGDI+で加工する事をしたい＆unsafeは使いたくないのであればColorMatrixを使えばよいということになります。

私が扱う画像がGDI+で加工する事をしたい＆unsafeを使っても速くしたいのであればLockbits/UnlockBitsを使えばよいということになります。

つまり何の速度差を知りたかったのかを明確にしなければ議論することができない話だったとわかりました。

●次回？

ということでもうちょっと観点を明確にしてちゃんと実測してみたいと思います。

Pixel-to-Pixel速度比較

myugaru (myugaru@wankuma.com) — Thu, 13 Mar 2008 22:19:00 GMT

リフレクション

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

VC#Express2008で.NET Frameworkのライブラリ・ソースへステップイン

これらのエントリーは実はちょっと確認したいことがあった流れで書いてました。
確認したかったのはGDI+の処理速度です。
具体的には「同じ結果を導く異なる描画方法の処理速度差」になると思います。
もちろん速い方を選びたいのが人情でしょう。
今日は上の流れで見つけたある２つの同じ結果を導く違う描画方法の比較をしようと思います。

●比較対象処理
Pixel-to-Pixel処理の一種であるグレースケール化です。
方式１：Bitmap.LockBits/Bitmap.UnlockBitsで画像の画素情報に直接アクセス
方式２：System.Drawing.Imaging.ColorMatrixによる色の行列変換

●テストプログラム詳細

ダウンロード：C# - GrayScaleSpeedTest.zip

共通部分
・画像はjpg画像に限定し24bitピクセルフォーマットでの比較を行う。
・まずファイルオープンダイアログでjpgを選択
・フォームクラスのローカル変数originalBmpに画像を保管
・各方式はメニューで選択
・選択された方式にoriginalBmpを引き渡しピクチャボックスへ結果を描画させる

方式１部分
・junki氏の画像処理ライブラリ「ImageUtils」（※１）のGrayScale24()を使用（このメソッドは内部でBitmap.LockBits/Bitmap.UnlockBitsを使用してグレースケール化を行う）
・引数にBitmapの参照を渡し返値は参照に上書きして返ってくるので、方式１開始部分で一旦originalBmpのクローンを作ってGrayScale24()で処理し返値をピクチャボックスへ設定する。

※１：Image Processing Utilities for C#2.0 (VC# 2005) Copyright junki, Jan, 2006 -
junki氏 HP：http://junki.lix.jp/　ImageUtils：http://junki.lix.jp/archives2/ImageUtils.lzh

方式２部分
・ColorMatrixに次の行列を設定

[ 0.299, 0.299, 0.299, 0.0, 0.0 ]
[ 0.587, 0.587, 0.587, 0.0, 0.0 ]
[ 0.114, 0.114, 0.114, 0.0, 0.0 ]
[   0.0,   0.0,   0.0, 1.0, 0.0 ]
[   0.0,   0.0,   0.0, 0.0, 1.0 ]

・ImageAttributesを作成し行列を設定
・変換用にoriginalBmpと同サイズ、24bitピクセルフォーマットのビットマップ作成
・Graphics.DrawImageにImageAttributesを渡し変換用ビットマップに対してグレースケールで描画を行う。
・変換用ビットマップをピクチャボックスへ設定する。

●結果
フリー写真素材（※２）をお借りして方式１と方式２でそれぞれ１００回ずつ変換を行った。
以下はそれぞれの方式のかかった時間を５回ずつ表示させています

ColorMatrixを用いた方が速いという結果になりました。

※２：ren氏HP：http://sk-d.a-thera.jp/
ダウンロード：http://www.photolibrary.jp/profile/artist_244_1.html

●実は納得していなかった
私はこのテストではColorMatrixの優位を証明できていないと思っています。
jpgが悪いとか誤字とか行列の値が違ってるとかループ回数が少ないとか多いとかではありません。
このテストでもある条件下では私も十分に納得すると思います。
でも今回はその条件ではないので納得していないわけです。

ではある条件とは一体何のことでしょう？
＃うーーん。実は引っ張るほど大した話じゃないかもですが・・・

この続きは明日か・・・明後日かもです。
色々と考えて楽しみにしててください。

＃聞くと本当に大した事じゃないので怒らないでくださいね。

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

myugaru (myugaru@wankuma.com) — Sun, 09 Mar 2008 10:20:00 GMT

[C#,VB.NET]Graphics.DrawImage(image,0,0)の落とし穴

サブタイトル：単に女の子の画像を張りたかっ(ry

12:00 すみません若干認識がずれていたようですので赤で修正しました

Graphics.DrawImage(image,0,0)は等倍表示を意味します。しかしこの等倍表示には２通りの意味があります。

●確認プログラム
確認のために以下のプログラムをダウンロードして実行してください。

これはDrawImage(image,0,0)で実装された単なる画像ビュアーです。

C#とVB.NETを用意してます。
http://myugaru.wankuma.com/DrawImageCheck_src.zip

実行形式も用意しました。実行には.Net Framework3.5が必要です。
http://myugaru.wankuma.com/DrawImageCheck_bin.zip

●確認手順
プログラムを実行すると単なるフォームが表示されます。↓の画像をドラッグ＆ドロップしてみてください。

(c)elouai.com - Candybar 4 Doll Maker http://elouai.com/candybar4/dollmakergirl.php

ブラウザで表示されているものより拡大されましたか？手持ちの画像でもこの確認プログラムとブラウザにドラッグ＆ドロップして確認してみてください。両者で見た目のサイズが違っているものはありませんか？

●原因
DrawImage(イメージ, 0, 0)は「物理サイズで等倍表示する」事を意味しています。
ですから「論理サイズでの等倍表示」を期待する人にとっては等倍と見えません。

すなわち
確認プログラムは「物理サイズ等倍表示」
ブラウザなどは「論理サイズ等倍表示」だという違いがこの現象を起こしています。

●解説
１．解像度
イメージには解像度と呼ばれるプロパティが存在しています。
水平方向の解像度＝イメージ.HorizontalResolution
垂直方向の解像度＝イメージ.VerticalResolution
ディスプレイにも解像度があります。例えば私の17インチディスプレイで~~1024×768表示時には~~解像度96dpiになっています。解像度は1024×768などを800×600に変えても変わるものではなくディスプレイそのものの能力値として機能しているようです。

２．画像に解像度が設定されるタイミング
画像の解像度の決まるタイミングはブラウザのような画像解像度を無視するアプリによって画像ストリームとしてファイルに保存される瞬間です。
ほとんどの場合は使っているディスプレイの解像度がその画像に設定されます。

以下のリンクを右クリックから「対象をファイルに保存」でPCへ保存してください。
http://myugaru.wankuma.com/image/20080309_50.bmp
この場合は画像ではなく単にファイルとして保存されるので本来の画像に設定された解像度が維持されます。
保存した画像ファイルをExplorer上で右クリックしてプロパティを確認してみてください。
この画像が解像度50dpiで作成されているのだというのが確認できます。

次に先ほどの女の子の画像上を右クリックして「名前を付けて画像を保存」でPCへ保存してみてください。
お使いのディスプレイに合わせてその解像度が設定されるかと思います。
先ほど同様に保存した画像ファイルのプロパティを確認してみてください。
（ブラウザによっては50dpiのままのものもあるかもしれません。IEはディスプレイ解像度に変わりました）

※ディスプレイ解像度はコントロールパネルの画面などから確認ができます。

２．物理サイズでの等倍
物理サイズというのは画像のインチ数でのサイズの事を指します。

上の確認プログラムの動作はこの物理サイズを等倍とするプログラムになっています。

先ほどの女の子の画像の論理サイズ（ピクセルサイズ）は横150×縦290です。

物理サイズ横＝150÷50＝3インチ
物理サイズ縦＝290÷50＝5.8インチ

の画像だといえます。

それを96dpiのディスプレイに物理サイズで等倍表示するとどういう事が起こるかというと、

横ピクセル＝3×96＝288
縦ピクセル＝5.8×96＝556.8

つまりディスプレイ上で288×556ピクセルで表示される事を意味します。
これは論理サイズでは拡大表示となります。

~~物理サイズでの等倍のシンプルな確認方法はディスプレイ~~解像度を変えてみる事です。
試しにディスプレイを1024×768や800×600などに変えてみてください。
物理サイズでの等倍を行うプログラムではその見た目のサイズは変わりません。

ディスプレイの能力によって96dpiが決まるので1024×768を800×600にする行為はこの能力の変更には直結していません。したがってこの場合見た目のサイズも変わってしまうという結果になります。確認が不足しておりました。すみません。

３．論理サイズでの等倍
論理サイズというのは画像のピクセル数でのサイズの事を指します。
ブラウザの動作は論理サイズを等倍とするプログラムになっています。
DrawImageのサイズ指定バージョンは画像の解像度を無視しディスプレイ解像度で表示することを意味しています。
DrawImage(image,0,0,image.Width,image.Height)は論理サイズでの等倍に利用できます。（可能な人は先ほどのプログラムを修正して確認してください）
論理サイズでの等倍の場合はディスプレイ解像度で表示されるわけですから、当然ディスプレイの解像度を1024×768や800×600に変えるとその物理サイズであるインチ数でのサイズは変わる事になります。これは前述の通り論理サイズ等倍だけの話ではありませんでした。すみません。
先の画像のように意図的に50dpiを設定している画像だったなら50dpiのディスプレイというのは見かけませんので、ほとんどの場合は製作者の意図したサイズで表示されていないという事を意味しています。この意味は多少あっていると思われます。

●対策
１．画像の解像度を変更する方法
残念ながら通常のWindows付属ペイントだとこれは出来ません。
画像解像度を簡単に変えることが出来るフリーのペイントツールがあります。
http://www.getpaint.net/
以下のように解像度のみ修正できます。
・[イメージ]→[キャンバスサイズ]の解像度の数値をかえる

２．とりあえず論理サイズの方が一般的？
一般に普及しているブラウザやペイントツールの動作を見てもディスプレイへの表示時はほとんどが画像の解像度を無視しているようです。
なので画像を単純にブラウジングするような場合にはDrawImage(image,0,0,image.Width,image.Height)とサイズ指定して論理サイズ等倍を意識したつくりにする方が良いように思います。

あまり需要は無いのかもですが、何かのプログラムでディスプレイ解像度に依存しない（つまり物理サイズが必要な）局面が出てきた場合にはこのエントリーの事を思い出して欲しいと思います。

物理サイズ等倍というのは見た目での等倍実現に寄与していないようです。現在のディスプレイの能力に見合ったサイズとしてそのサイズを表現するという意味合いで使われているように思います。不確かな記述をしてしまい申し訳ありませんでした。

最後に・・・ここまで書いてからふっと見ると・・・ほとんどここに書いてました。ヘルプも空気も嫁てません。。→http://msdn2.microsoft.com/ja-jp/library/558kfzex(VS.80).aspx
・・・開き直って私なりにまとめたのはこれで良しとしときます。

リフレクション

myugaru (myugaru@wankuma.com) — Thu, 06 Mar 2008 06:53:00 GMT

今日はGraphics.DrawImageUnscaled()がGraphics.DrawImage()の何のひねりも無い単なるラッパーである検証をします。

使うのは↓コイツです。

http://www.aisto.com/roeder/dotnet/
Reflector for .NET

.Netアセンブリにはネイティブなら完全消滅するような変数名もそのまま入っているので、ほぼ完全にソースに復元可能です。
ただしリバースエンジニアリングを軽々しく行うのは諸々問題があるように思いますので、
あくまでも自己責任でお願いします。

追記3/11：Microsoftでライブラリソースの公開がされているそうです。

JZ5さんの記事が参考になりました。JZ5さん感謝いたします。

http://www.atmarkit.co.jp/fdotnet/insiderseye/20080222sourcecode/sourcecode.html

●では簡単な手順で検証：

と思ったのですがこれは各自で色々お試しください。

http://www.atmarkit.co.jp/fdotnet/tools/dotfuscator/dotfuscator_02.html

http://sonic64.com/2005-10-11.html

他にもぐぐれば丁寧な使い方をご指導くださっているページはネットにあふれかえっておりますのでよろしくお願いいたします。

●もっともっと使い倒す手順：

?自分の作ったプログラムは果たしてどういう風にコンパイルされているのか？本当に意図したとおりのコードに翻訳されてるか？ってのが気になることってありませんか？そういう時には、以下はVisual Studio C# 2008 Express Editionの話ですが他のエディション、言語も似た手順で簡単に調べられます。

1.ツール→外部ツールメニューを開きます

2.「追加」から↓のように設定します。Reflector本体の場所は自身の環境にあわせて適宜変更します。ちなみに引数の$(TargetPath)は三角ボタンから「ターゲットパス」を選べば簡単に入力できます。

3.では何でも良いので適当にC#でプロジェクトを作りコンパイルOKまで進めます。私は仮に下のコンソールアプリを使いました。（ちゅうい：ニコちゃんやハートに突っ込み入れないように願います。）

4.ツールメニューを開くと先ほど作ったRefrectorメニューがあるので選択します。自分の作ったプログラムを逆アセンブルできます。

5.ちなみにTools→Optionsから表示フォーマットを変えるとdelegateが実装されていないソースとしても翻訳してくれます。

↓Optimization=3.5

↓Optimization=None