「Windows API/図形の描画」の版間の差分
削除された内容 追加された内容
機械語 2019年12月22日 (日) 12:13 の内容を、こちらに移動。画像ファイル作成方法で使いそうなので。 |
|||
345 行
安全のため、作業が終わったら、メモ帳を閉じてから、Visual Stuido 側でセーブ保存すると安全だろう。
== 画像ファイルを作成したい場合 ==
CreateDIBSection 関数を使うことになる。
[https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection MSDN公式] によると、シンタックスは
<pre>
HBITMAP CreateDIBSection(
HDC hdc,
const BITMAPINFO *pbmi,
UINT usage,
VOID **ppvBits,
HANDLE hSection,
DWORD offset
);
</pre>
である。
だが、実際はまず、作成しようとする画像を編集するためのプログラムが先に必要である。このため、下記のような、バイナリファイルの知識が必要になる。
== 画像ファイルのバイナリ ==
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|バイナリエディタで見た場合のビットマップの機械語の配置<br>バージョンによって少々異なる場合もあるが、おおむね、こういう感じである。]]
{{-}}
たとえばビットマップ画像を作りたい場合、
機械語で、いわゆる「ビットマップ構造体」の仕様で決められた様式で、機械語をファイルに書き込む。
すると、たいていのデスクトップ用OS（ウィンドウズも含む）では、ビットマップ形式の機械語をサポートしているので、その機械語を画像ファイルとして認識してくれるので、クリックなどをするとOSが画像表示などをしてくれる。
なお、ネットや専門書の解説では画像フォーマットの仕様を説明するためによくC言語の「構造体」の書式が説明されるが、しかし、その構造体を入力しても、画像は生成されない。
さて、たとえば何らかのビットマップ画像をバイナリエディタで読み込むと、ファイルの先頭は必ず「42 4D」という16進数である。この数字は、アスキーコードで翻訳すると「BM」になる。
この「42 4D」という冒頭の数字を識別子とすることで、ファイルの種類を認識している。
誤解しないでほしいが、けっして「BM」と機械語で書かれているのでなく（そもそも十六進数に「M」は無い）、書かれているのは あくまで「42 4D」である。
ネット検索で調べる場合は「42 4D」というキーワードを付け加えて「ビットマップ 42 4D」などで調べれば、ビットマップ画像のバイナリでの扱いに関する有益な情報が入手しやすいだろう。
たとえば、Windows用のフリーのバイナリエディタ stiring で3×5ピクセルの白色だけのビットマップファイルを見ると、下記のようになっている。
<pre>
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 05 00 00 00 03 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 0C 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00 ......ﾄ...ﾄ.....
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 FF FF F0 00 FF FF F0 00 FF FF ................
00000080 F0 00
</pre>
stiring に限らず一般にバイナリエディタの画面の構成は、上記のようになっている。（なお、「ファイル」→「ダンプイメージの保存」などの操作で、上記のような機械語のイメージをテキストエディタ（Windowsの場合は『ワードパッド』など）で見られる形式に変換して出力できる。）
機械語はそのままでは、テキスト表示できない。なので、それをテキスト化したり、見やすくするために書式を整えたりして、機械語の内容を出力したものをダンプ イメージという。
また、そのようなダンプイメージを出力することを、俗に（ぞくに）「ダンプする」などとIT業界では言う。
さて、このダンプイメージのうち、機械語の本体は、真ん中のブロックである、下記の
<pre>
42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00
00 00 05 00 00 00 03 00 00 00 01 00 04 00 00 00
00 00 0C 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80
00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80
00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF
00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF
00 00 FF FF FF 00 FF FF F0 00 FF FF F0 00 FF F
F0 00
</pre>
の部分である。
一番左のブロック、
<pre>
BM........v...(.
................
......ﾄ...ﾄ.....
................
................
......ﾀﾀﾀ.......
................
................
</pre>
は、ファイル内容の機械語をアスキーコードに変換して表示している。
このアスキーは、機械語のファイル内容ではなく、バイナリエディタ側がユーザーが内容を探しやすくする目的などのために表示している。
一番上の行の
<pre>
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
-------------------------------------------------------------------
</pre>
は、単に何バイト目かをあらわしているだけである。これは、機械語のファイル内容ではなく、バイナリエディタ側がユーザーが見やすくするために表示している。
また、一番左の列の
<pre>
ADDRESS
-----------
00000000
00000010
00000020
00000030
00000040
00000050
00000060
00000070
00000080
</pre>
は、アドレスをあらわしている。
;各ヘッダの名称
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|バイナリエディタで見た場合のビットマップの機械語の配置<br>バージョンによって少々異なる場合もあるが、おおむね、こういう感じである。]]
{{-}}
赤い背景色のブロックで表した部分を「BITMAP FILE HEADER」といい、これの長さは14バイトで固定である。「42 4D」で2バイト、同じように数えて12バイトの長さ。「BITMAP FILE HEADER」とは、つまり、「42 42」「画像のファイルサイズ」「予約領域」「予約領域」「画像の場所の指定」の部分である。
日本語では、「BITMAP FILE HEADER」のことを、ビットマップの「ファイルヘッダ」と言う場合もある。
つまり、ビットマップのファイルヘッダの長さは14バイトで固定である。
さて、青い背景色のブロックで表した部分を「BITMAP INFO HEADER」という。
つまり、「BITMAP INFO HEADER」とは、
:「ヘッダサイズ」
:「画像の横幅」「画像の高さ」「プレーン数」「色ビット数」「圧縮形式」
:「画像データのサイズ」「ヨコ方向の解像度」「タテ方向の解像度」「パレット数」
:「重要な色数」
の部分である。日本語では、「BITMAP INFO HEADER」のことを、ビットマップの「情報ヘッダ」と言う場合もある。
ビットマップ情報ヘッダの長さは40バイトで固定である。
機械語本体の右上にあるビットマップ情報ヘッダの「28 00」と次の段の「00 00」は、ヘッダサイズに相当するが、28は十進数に直すと40である（16×2+8＝40）。 リトルエンディアンなので、あとの00の3回くりかえしは無視していい。
;各部の内容
さて、ビットマップ構造体の図を、ダンプイメージと照らし合わせてみよう。
{{-}}
[[File:Bitmap structure on hex edit japanese.svg|thumb|900px|（再掲）バイナリエディタで見た場合のビットマップの機械語の配置]]
{{-}}
<pre>
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 05 00 00 00 03 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 0C 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00 ......ﾄ...ﾄ.....
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 FF FF F0 00 FF FF F0 00 FF FF ................
00000080 F0 00
</pre>
「42 4D」のあとに 「82 00 00 00」と4バイトぶんの数字が続くが、これはファイルサイズを表している。
なお、このファイルのサイズは130バイトである。16進数の「82」は 10進数で「130」である。算数で10進数の計算で 8×16＋2＝130 である。
読者のWindowsパソコンでもバージョンによるかもしれないが、『ペイント』などで3×5ピクセルの16色ビットマップ画像を作成すれば、おおむね、このあたりのファイルサイズになるだろう。
なお、ペイントのキャンバスサイズの変更は、左上のメニューアイコンから「プロパティ」を選ぶと「イメージのプロパティ」設定ウィンドウが開き、下のほうにキャンバス幅とキャンバス高さの指定欄があるので、そこで数値を入力してサイズを変形できる。
この「82 00 00 00」の意味は、10進数にすれば
:130 ＋ 256<sup>1</sup>×0 ＋ 256<sup>2</sup>×0 ＋ 256<sup>3</sup>×0
という意味である。こういう数え方を「リトル エンディアン」という。
なお「256」の由来は 16×16＝256 である。
けっして、8200万バイトでないし、130万バイトでもないので、勘違いしないように。
次の、2つの 予約領域 は、ゼロで埋める決まりになっており、なので「00 00 」「00 00」である。
1段目アドレスのABCDの部分にある「 76 00 00 00」は、まず意味は10進数で118である。7×16+6＝118 より。
で、「機械語の118バイト目から、画像データが始まります」と宣言している（ファイル先頭から画像デーマまでの「オフセット」という）。1バイトは256で、16×16＝256なので16進数では2ケタぶんです。画像データの先頭のバイトが118バイト目であると、を指し示している。
なお、数え方は左上の「42 4D」ですでに2バイトである。 この調子で118バイト目を探すと
:118÷16 ＝ 7 あまり 6
なので、8行目（商7にプラス1）の7列目（あまり「6」＋1）のバイト（6）目が、開始位置である。下図の太字にした部分のバイトである。
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 05 00 00 00 03 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 0C 00 00 00 C4 0E 00 00 C4 0E 00 00 00 00 ......ﾄ...ﾄ.....
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 '''FF''' FF F0 00 FF FF F0 00 FF FF ................
00000080 F0 00
よくみると、この太字の部分からFが5個続き、「000」というのが3回数くりかえすので、合計でFが15回繰り返される。これは、この画像が横5×3であることに対応している。
さて、「画像の横幅」「画像の縦幅」に対応するのは「05 00 00 00」「 03 00 00 00」である。これは、横5ピクセル×縦3ピクセルという意味である。数値の数え方はリトルエンディアンである。
ビットマップ情報ヘッダの終わりから画像の開始までは、カラーパレットが16個、続いています。
上ダンプの太字の直前の「FF FF FF 00」とは、16番目のビットマップのカラーパレットです。カラーパレットは合計で16個あります。また、この16番目パレットを呼び出すのに、画像データ部分のF5回の繰り返しの部分では「F」でパレットを呼び出しています。
その直前のパレットの「FF FF 00 00」が15番目のパレットです。このパレットは「E」で呼び出されますが、今回の画像データでは使われてないです。
「プレーン数」と「色ビット数」の「01 00 」「04 00」は。プレーン数が十進数で1で、色ビット数が十進数で4という意味である。
「圧縮形式」とあるが、無圧縮にする場合はゼロにする。つまり「00 00 00 00」で無圧縮である。ビットマップは、仕様上では、実は圧縮も可能な仕様である。
解像度「C4 0E 00 00」は、印刷などをする際の1メートルあたりのピクセル数ですが、今回は印刷をしないので、気にしないことにします。
「パレット数」は、仕様上は策定されていますが、実際には利用されていません。マイクロソフトの『ペイント』アプリで作ったファイルですらも、ここはゼロのままの「00 00 00 00」です。
「重要な色数」も、仕様上は策定されていますが、やはり実際には利用されていません。これまたマイクロソフトの『ペイント』アプリで作ったファイルですらも、ここはゼロのままの「00 00 00 00」です。
なお、ビットマップの仕様を策定した起業は、昔のIBMとマイクロソフトです。
なお、マイクロソフトのサイトでは
<pre>
typedef struct tagBITMAPINFOHEADER {
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER, *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;
</pre>
のようにC言語っぽいコードのようなモノが書いてあるが、これは単に構造を説明しているだけであり、このコードをコンパイラなどに入力しても何も起きない。
:外部リンク: MSDN [https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapinfoheader BITMAPINFOHEADER structure ]
=== 実例 ===
背景が白色だと分かりづらいので、黄色にしてみましょう。
それを横5×縦3ピクセルにしたファイルの機械語ダンプは、次のようになります。
<pre>
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 82 00 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 05 00 00 00 03 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 BB BB B0 00 BB BB B0 00 BB BB ......ｻｻｰ.ｻｻｰ.ｻｻ
00000080 B0 00
</pre>
「BB BB B0 00 」と3回繰り返すことで、パレットBでピクセルを塗るのを横5マスを3行続けていることが分かります。
末尾の「0」や「00」はおそらく改行のようなものでしょう。
また、キャンバスサイズを拡大し、横6×縦9ピクセルで黄色一色のビットマップ画像にすると、ダンプは下記のようになります。
<pre>
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 9A 00 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 06 00 00 00 09 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 ..$.............
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 FF 00 00 00 FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 BB BB BB 00 BB BB BB 00 BB BB ......ｻｻｻ.ｻｻｻ.ｻｻ
00000080 BB 00 BB BB BB 00 BB BB BB 00 BB BB BB 00 BB BB ｻ.ｻｻｻ.ｻｻｻ.ｻｻｻ.ｻｻ
00000090 BB 00 BB BB BB 00 BB BB BB 00 ｻ.ｻｻｻ.ｻｻｻ.
</pre>
よくみると後半「BB BB BB 00」が9回（※ この画像のタテのピクセル数が9である）、繰り返されています。
また、Bの個数も、6回ずつ（※ この画像の横幅は6である）です。
最後の「00」で、このことから、00バイトで改行を表すのだろう事が分かります。
とすると、パレット番号に「0」や「00」は使えないハズです。
なお、画像データの読み方は、機械語の情報が、画像では左下から右下に対応します。
なので、2色以上を使った画像で、調べてみましょう。
下記の画像は、ややサイズが大きい画像ですが（サイズが小さいとビューワーの性能によっては色ボケしたりして不正確になるので）、
幅30×高さ10 の画像です。白地を基調としておりますが、左上に赤い帯があります。下側に青い帯があります。右上に短く青い帯があります。
ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0123456789ABCDEF
------------------------------------------------------------------------------
00000000 42 4D 16 01 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 1E 00 00 00 0A 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 ''FF 00 00 00'' FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 '''CC''' CC CC CC CC CC CC CC CC CC ......ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
00000080 CC CC CC CC CC 00 6C CC CC CC CC CC CC CC CC CC ﾌﾌﾌﾌﾌ.lﾌﾌﾌﾌﾌﾌﾌﾌﾌ
00000090 CC CC CC CC C6 00 FF FF FF FF FF FF FF FF FF FF ﾌﾌﾌﾌﾆ...........
000000A0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000B0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000C0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000D0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000E0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000F0 FF FF FF FF FF 00 99 99 99 99 99 99 99 99 99 99 ......劔劔劔劔劔
00000100 9F FF CC CF FF 00 99 99 99 99 99 99 99 99 99 99 ..ﾌﾏ..劔劔劔劔劔
00000110 9F FF 6C CF FF 00 ..lﾏ..
太字にしたところから、画像の始まりです。ほぼパレット「C」が30回繰り返されています。2行目の最初が「6C」になってるのは、ペイントが勝手にそういう色に変えただけです。2行目は6のあと「C」が28回繰り返され、最後にパレット「6」番の色です。
パレットCは、斜線にした 「''FF 00 00 00''」の部分です。「赤色（256段階）, 緑色（256段階）, 青色（256段階）」の順番になっています。
なので、
:「FF 00 00 00」なら、真っ赤な赤色、
:「00 FF 00 00」なら、ま緑色、
:「00 00 FF 00」なら、完全な青色
です。
:「FF FF FF 00」なら、完全な白色、
:「00 00 00 00」なら、完全な黒色です。
さて、幅30×高さ10 の画像は、画像で見ると、青い帯は下側にあります。しかし機械語では、青い帯は、最初に書かれています。
このように、上下が反転しています。そういう仕様だからです。
;Linux のxxdコマンド
Linux だと、この機械語のテキスト形式のダンプ内容を、機械語のビットマップ画像形式に変換できるコマンドがある。
<code>xxd</code> というコマンドを使えばいい。Fedora 31 では標準では、この <code>xxd</code> がついていない。なのでFedoraにこのコマンドをインストールするために vim-common をインストールする必要がある。Fedora ではvim-common に <code>xxd</code> が含まれている。
xxdはもともと、機械語を16進ダンプするためのコマンドであるが、このソフトウェアには、さらに16進ダンプされた内容のテキストを機械語に戻す機能もある。
引数に -r をつける事により、16進ダンプを機械語に戻せる。
たとえば、なんらかのテキストエディタ（Fedora標準の gedit でもよい）に、下記のテキスト（これはstirringで出力したテキストから、上2行の見出しを除去しただけの物である）をそのままコピーペーストしてテキストエディタに貼り付けし、普通に「test」などの名前で保存しよう。この段階では、ファイル「test」は、まだ単なるテキストファイルである。
00000000 42 4D 16 01 00 00 00 00 00 00 76 00 00 00 28 00 BM........v...(.
00000010 00 00 1E 00 00 00 0A 00 00 00 01 00 04 00 00 00 ................
00000020 00 00 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 80 ................
00000040 00 00 00 80 80 00 80 00 00 00 80 00 80 00 80 80 ................
00000050 00 00 80 80 80 00 C0 C0 C0 00 00 00 FF 00 00 FF ......ﾀﾀﾀ.......
00000060 00 00 00 FF FF 00 ''FF 00 00 00'' FF 00 FF 00 FF FF ................
00000070 00 00 FF FF FF 00 '''CC''' CC CC CC CC CC CC CC CC CC ......ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
00000080 CC CC CC CC CC 00 6C CC CC CC CC CC CC CC CC CC ﾌﾌﾌﾌﾌ.lﾌﾌﾌﾌﾌﾌﾌﾌﾌ
00000090 CC CC CC CC C6 00 FF FF FF FF FF FF FF FF FF FF ﾌﾌﾌﾌﾆ...........
000000A0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000B0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000C0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000D0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000E0 FF FF FF FF FF 00 FF FF FF FF FF FF FF FF FF FF ................
000000F0 FF FF FF FF FF 00 99 99 99 99 99 99 99 99 99 99 ......劔劔劔劔劔
00000100 9F FF CC CF FF 00 99 99 99 99 99 99 99 99 99 99 ..ﾌﾏ..劔劔劔劔劔
00000110 9F FF 6C CF FF 00 ..lﾏ..
だが、コマンド端末で
xxd -r test > testout
と入力して実行すると、なんと『testout』というファイル名で、画像ファイルが新規作成されている。
| |||