Windows でスクリーンショットを作成しLockBits
、GDI+ の関数を使用してピクセル データを抽出し、ファイルに書き込みます。
パフォーマンスを最大化するために、私は次のことも行っています。
PixelFormat
フォーマット変換を避けるために、ソース ビットマップと同じものを使用する- フラグを使用し
ImageLockModeUserInputBuf
てピクセル データを事前に割り当てられたバッファに抽出する - この事前に割り当てられたバッファ ( が指す
BitmapData::Scan0
) は、メモリ マップト ファイルの一部です (ピクセル データの再コピーを避けるため)。
また、ファイルを読み取るコードを作成するので、任意の形式を使用 (または作成) できます。ただし、既存のプログラム (理想的には Web ブラウザー) が読み取ることができるよく知られた形式を使用することをお勧めします。これは、他のプログラム (画像を読み取るプログラム) のコードを記述する前に、画像が正しいことを視覚的に確認できるためです。 )
PixelFormat32bppRGB
32bpp BMP ファイルの形式に一致する形式でこれを正常に実装したので、ピクセル データを直接メモリ マップされた BMP ファイルに抽出し、プレフィックスとして BMP ヘッダーを付けると、有効な BMP イメージ ファイルを取得できます。ペイントおよびほとんどのブラウザで開くことができます。
残念ながら、私がテストしているマシンの 1 つは、PixelFormat64bppPARGB
フォーマットでピクセルを返します (おそらく、これはビデオ アダプター ドライバーの影響を受けます)。これに対応する BMP ピクセル フォーマットはありません。
16、24、または 32bpp の BMP 形式に変換すると、プログラムの速度が大幅に低下する (損失が大きくなる) ため、このピクセル形式を変換せずに使用できるファイル形式を探しているので、メモリマップ ファイルに直接抽出できます。私が 32bpp フォーマットで行ったように。
48bpp (BGR オーダー、リトル エンディアン) および/または 64bpp (BGRA オーダー、リトル エンディアン) をサポートするラスター イメージ ファイル形式は?
編集
これまでのところ、これらの形式を除外しました。
- BMP : 深度は <=32bpp に制限されます (それ以外の場合は完全に一致します)。
- PNG : サンプルの順序は RGBA のみです。
- TIFF : サンプルの順序は RGBA のみです。
考えられる部分的な解決策:
- OpenEXR : 48bpp のみ。サンプルの順序はチャンネル名のアルファベット順です。BGR は適合しますが、BGRA は適合しません。