Windows API/画像の操作
:
※ 直線や長方形など簡単な図名の描画についてはwikibooks『Windows API/図形の描画』で説明してある。
画像の操作

Win32APIには、SetPixel 関数という、座標と(点の)色を指定して、ウィンドウ内に点を描画する関数がある。
画像の操作

理論的には、これさえあれば、ウィンドウ内なら、どんな描画もできるので、自分で画像ファイルのファイル形式を設計することすら可能である。
画像の操作

なぜなら、ビットマップやJPEGなどの画像の集まりは、(中学校などで習うように)所詮は画素という点の集まりであるから。
画像の操作

しかし、すでに存在する画像ファイル規格などを再度設計するのは時間の無駄だから、通常は、既存の規格であるビットマップ形式画像などを活用する。
画像の操作

なお、点のほか、線を描ける LineTo 関数や、円を描ける Ellipse 関数、長方形を描ける Rectangle 関数など、いくつかの基本図形には描画の関数が用意されている。
画像の操作

線などの簡単な図形を表示するだけなら、わざわざビットマップで作成する必要は無い。
画像の操作

Win32APIで扱える画像は、標準設定のままでは ビットマップ画像(.bmp)しか扱えない。
画像の操作

もしPNG画像などを扱いたい場合には、GDI+をインクルードする必要がある。
画像の操作

また、ビットマップには、画像の透明化の機能がないため、初等的な方法ではWin32APIで画像を透明化できない。例えば、矢印型マウスカーソル画像のように、矢印画像の外側を透明化するような機能は、ビットマップには無い。
画像の操作

どうしてもWin32APIで画像の透明化を行いたい場合には、MaskBlt 関数などを利用して、透明化の機能を自作する必要が生じてしまう。
画像の操作

しかし、透明化の自作はメンドウだし、せっかく自作しても互換性が悪いから、普通はそういうことはせず、GDI+のインクルードなどをして、PNG画像など透明化の機能をもった画像形式を活用するのが一般的である。
画像の操作

まず、GDI+をインクルードしてない状態での操作を説明する。当然、ビットマップ形式しか、画像ファイルは扱えない。
画像の操作

なお、表示したいビットマップ画像そのものの作成は、アクセサリ「ペイント」で先にすませておく必要がある。
画像の操作

さて、Win32 API では LoadImage という関数で、ビットマップ画像の読み込みができる。
画像の操作

しかし、事前に、画像操作用のハンドルをHBITMAP 型を使って宣言しないといけない。「ハンドル」とは、なにやら正体が不明だが、ウィンドウプログラミングでファイル操作をするときとかに、宣言する必要になることになる、何かである。
画像の操作

マイクロソフト社の人が、こういう仕様で作ってしまったので、ユーザーは従うしかない。
画像の操作

おそらく、きっとファイル操作などに必要なメモリ領域やハードディスク領域の確保でも、たぶん宣言しているのだろう。画像のハンドルなら、きっと画像ファイルの操作に必要な領域の確保でもしているのだろう。
画像の操作

とにかくコードは、
画像の操作

のようになる。このような順序で、宣言することになる。上のコードでは、「yomikomitai_gazou」という名前のビットマップ画像を読み込む。
画像の操作

さて、Win32 API では、ウィンドウ内での画像の表示と、画像データの作成は、別の関数になる。当然だが、ウィンドウ外部には画像を表示できない。
画像の操作

ウィンドウ内への画像の表示には、BitBlt 関数を使う。
画像の操作

さらに、表示先の画面と、画像編集用の仮想的な画面とが、Win32APIでは概念が分かれている。
画像の操作

Win32APIでも表示先の画面上で、直接、画像を編集することも可能であるが、説明の簡単のため、本書では、画像編集用の仮想画面で編集をしてから、その編集結果を、表示先の画面に転送するという仕組みで説明する。
画像の操作

まず、表示先の画面は、通常の設定では「hdc」という名前である。
画像の操作

のように、通常の設定では「hdc」という名前の画面が、ウィンドウ内の画像表示用の画面である。
画像の操作

さて、画像作成用の仮想的な画面は、自分で宣言する必要がある。
画像の操作

例えば、もし画像作成用の画面の名前を hbackDC にするなら、下記のように宣言する。
画像の操作

こうすることで、 hdc と互換性のある、画像作成用の領域が確保される。
画像の操作

なお、大文字のHDCは型名である。小文字の hdc とは意味が違うので、区別するように。
画像の操作

そして、 hbackDC で作成した画像を表示するには、例えば
画像の操作

のように、hdcに転写しなければならない。
画像の操作

実は、いちいち hbackDCなどの画像作成用の画面を作成しなくとも、直接的にhdcの上で作成・表示もまとめて出きる。
画像の操作

しかし、hdc上で直接作成した場合には、表示する画像の数が多いと、画像の貼り付け中の画面もそのまま表示されてしまう場合がある。
画像の操作

もし、画像の貼り付け中の過程を隠したい場合などには、hbacKDCのように作成画面を別途用意する必要がある。
画像の操作

使い終わった画像操作用ハンドルは、
画像の操作

で削除しなければならない。(そういう仕様になっている。削除しないと、一例として、画像描画の関数ブロックを2回目以降に利用するときに、前回の画像描画で使用した画像がメモリ内に残ってたりして、画像がバグったりする。)
画像の操作

しかし、使用中のほかの画面や画像と関連づけてると削除できない(そういう仕様)ので、
画像の操作

のように、NULLを入れてから削除すると、確実に削除できる。
画像の操作

使い終わった、画像作成用の画面を削除する場合は、DeleteDC を使う。これまた、使用中のほかのハンドルと関連づけていると削除できない(そういう仕様)ので、
画像の操作

のように、NULLと関連づけさせてから、削除することで、確実に削除できる。
GDI+

PNG画像やJPEG画像を描画したい場合、GDI+をインクルードすると、比較的に簡便なコードで済むようになる。
GDI+

単に
GDI+

と冒頭に書くだけで、GDI+をインクルードできる。
GDI+

なお、原理的には
GDI+

だけでもインクルードできるが、しかしMSDN『Image::RemovePropertyItem method』 にあるGDI+のサンプルコードにある関数のいくつかを使う際に、上述の #pragma comment(lib,"Gdiplus.lib") や using namespace Gdiplus; が必要になる。
GDI+

なお、先に ole2.h をインクルードしないと、コンパイルがエラーになってしまい、識別子 IStreamが定義されていないとか警告を出されてしまう。
GDI+

なので、上述コードの順序どおりに、先に ole2.h をインクルードしてから、あとに gdiplus.h をインクルードする必要がある。
GDI+

あらかじめ「test.png」などのPNG画像を用意しておき、それを実行ファイルのソースコードのcppファイルのあるフォルダに入れておく必要がある。(けっしてソリューションファイル(拡張子 .sln )のあるフォルダ階層ではない。cppファイル(拡張子 .cpp)のあるフォルダ階層のほうに入れること。)
GDI+

そして、 WM_PAINT: を下記のように書き換える。
GDI+

書き換えることになるだろう箇所は、
GDI+

である。
GDI+

単に、下記のように、繰り返しで、
GDI+

の部分を必要な画像の枚数と同じ回数だけ、繰り返せばいい。
GDI+

つまり、コード例は、
GDI+

のようになる。
GDI+

あらかじめ、半透明にさせたい側の画像を、画像編集ソフトで半透明にしておけば、コマンド ○○.DrawImage のときに自動で半透明にしてくれる。
GDI+

たとえば、もしも、不透明の背景 background.png に、半透明の黒フィルター filter.png を載せたい場合、
GDI+

png画像を編集できるなんらかの画像編集ソフトで、そのまま半透明の画像を作成しておけば、あとは上記のコードを実行するだけで、半透明フィルターを載せてくれる。
GDI+

あとから描画された画像のほうが画像レイヤーでは上層に来るので、載せるフタ側の画像(例の場合ではfilter.png)をあとから描画関数をする必要がある。
GDI+

WM_PAINT を毎回読み込む場合にGDIの設定プログラムを起動するのは無駄なので、
GDI+

初回起動にまとめて処理する場合には、wWinMain 関数 のほうで処理する。
GDI+

いっぽう、 WM_CREATE で処理しようとしても、なぜかコンパイルエラーになる。
GDI+

つまり、コードの下記のようになる。
画像ファイル出力

画像を、表示画像ではなく、外部ファイルとして受け渡しできるようにファイル出力したい場合、CImage.Save で可能です。つまり CImage クラスのsave メソッドという機能を使います。
画像ファイル出力

GDI+を使った画像ファイル出力の方法もあるらしいが、しかしC++の場合、ファイル容量の計算やピクセル位置の計算などが必要になるようでコードが難解でやや長く、初心者にとって簡便な方法は知られていない。あったとしても、少なくとも日本のネットで検索した限りはGDI+による画像ファイルの簡便な見つからない。なので、CImageによる方法が良いだろう。
画像ファイル出力

CImageを使うには、"MFC"というものをインストールする必要がある。標準では、MFCはインストールされていないので、Visual Studioのインスト-ラでMFCビルドツールを追加インストールする必要がある。もし
画像ファイル出力

を書いてエラーになるようならMFCがインストールされていないので、プログラミングにおけるCImageの利用のためにはMFCビルドツールをインストールしなければならない。
MFC

あらかじめVisual Studio を最新版に更新しておく必要がある(最新版でないと、MFCのインストールを開始できない) 。更新に長い時間が掛かる場合があるので、帰宅前や就寝前にでも更新を行っておく。
MFC

Visual Studio を最新版にしたあと、Visual Studioインスト-ラで「C++によるデスクトップ開発」をチェックすると表れるインストールメニューの一覧から「最新の v142 ビルドツール用 C++ MFC (x86 および x64)」にチェックを入れ(バージョンは時期によって異なる)、「変更」ボタンをクリックすることで、MFCのビルドツールのインストールが開始する。これもインストールに長い時間が掛かるので、あらかじめ時間の段取りを工夫しておこう。
MFC

Visual studioで「MFCアプリ」の開発を起動した場合と、既存のwindowsデスクトップアプリケーションにMFC関連の関数を組み込むための方法とは異なる。
MFC

この単元では、既存のwindowsデスクトップアプリケーションにMFC関連の関数を組み込むための方法を説明する。
MFC

さてMFCのインストールが完了したとします。プログラミング方法については、MFCをどういう方法で使うかによってinclude方法が異なる可能性はありますが、おおむね冒頭のinclude文で、まずは
MFC

のように宣言する必要が生じるかと思います。Windowsの実装上の都合により、_AFXDLL という定数のdefine関数が必要になります。
MFC

このほか、ソリューションのプロパティ設定により、
MFC

する必要があるかもしれません。
MFC

どうプロパティ設定するかは用途によって個々人で違う可能性があるので、コンパイラのエラーメッセージなどを参考に都度、ネット検索などで調べてください。
MFC

MFCは元来、今まで習ってきた「Windowsデスクトップアプリケーション」でプログラミングするようにはできておらず、このため、「Windowsデスクトップアプリケーション」で扱う際に必要になる設定がなかなか難しいのが難点です。
MFC

ビルド時に windows.h が 2回読み込まれてエラーになってコンパイルができない場合があるので、その場合は作成プロジェクトの framework.h ファイルにある #include <windows.h> を、コメントアウトして
MFC

のようにする必要があるかもしれません。