画像の読み込みとサイズ変更の最速の方法は何ですか？

Question

特定のディレクトリ内の画像のサムネイルを表示する必要があります。 TFileStreamを使用して、画像を画像コンポーネントに読み込む前に画像ファイルを読み取ります。その後、ビットマップはサムネイルサイズにサイズ変更され、TScrollBoxのTImageコンポーネントに割り当てられます。

大丈夫のようですが、画像が大きくなるとかなり遅くなります。

ディスクから（イメージ）ファイルをロードしてサイズを変更するより速い方法はありますか？

ありがとう、ピーター

Answer 1

そうでもない。バックグラウンドスレッドでサイズを変更し、「プレースホルダー」を使用してください。画像のサイズ変更が完了するまで。その後、これらのサイズ変更された画像を、後で処理するために何らかのキャッシュファイルに保存します（Windowsはこれを行い、現在のディレクトリでキャッシュthumbs.dbを呼び出します）。

スレッドアーキテクチャ自体にはいくつかのオプションがあります。すべてのイメージを実行する単一のスレッド、またはスレッドが単一のイメージの処理方法のみを知っているスレッドプール。 AsyncCalls ライブラリは別の方法であり、非常にシンプルに保つことができます。

Answer 2

私はskamradtの答えを、できるだけ速くなるように設計する試みで補完します。このためには

• I / Oの最適化
• 複数のスレッドを使用して複数のCPUコアを使用し、ファイルの読み取り（または書き込み）中に単一のCPUコアでさえ動作し続ける

複数のスレッドを使用することは、VCLがスレッドセーフではないため、サイズ変更にVCLクラスを使用しても機能しないことを意味し、すべてのハッキングはうまくスケーリングしません。 efgのコンピューターラボには、画像処理コードへのリンクがあります。

複数のスレッドを使用する場合、複数の同時I / O操作を行わないことが重要です。サムネイル画像をファイルに書き戻すことを選択した場合、ファイルの読み取りを開始したら完全に読み取る必要があり、ファイルの書き込みを開始したら完全に書き込む必要があります。両方の操作をインターリーブすると、I / Oが強制終了されます。これは、ハードディスクヘッドのシーク操作が大量に発生する可能性があるためです。

最良の結果を得るには、アプリケーションのメイン（GUI）スレッドでファイルの読み取り（および書き込み）を行わないでください。これは、次の設計を提案します。

• 1つのスレッドにファイルをTGraphicオブジェクトに読み込ませ、これらをスレッドセーフリストに入れます。
• 元のサイズのファイルのリストでスレッドプールを待機させ、1つのスレッドで1つのTGraphicオブジェクトを処理し、別のTGraphicオブジェクトにサイズ変更して、これを別のスレッドセーフリストに追加します。
• リストに追加された各サムネイル画像のGUIスレッドに通知して、表示できるようにします。
• サムネイルをファイルに書き込む場合は、読み取りスレッドでも同様に行います（説明については上記を参照）。

編集：

質問を読み直すと、たった1つの画像のサイズを変更するだけでよいことに気付きました。この場合、当然、単一の背景スレッドで十分です。とにかく私の答えをそのままにしておきます。おそらく誰かの役に立つかもしれません。これは、最新のプロジェクトの1つから学んだことです。最終プログラムではもう少し速度が必要だったかもしれませんが、ピーク時にクアッドコアマシンの約75％しか使用していませんでした。 I / Oを処理から分離すると、違いが生じます。

Answer 3

Scale：= jsEighth（Delphi 7）でTJPEGImageをよく使用します。 JPEG解凍では多くのデータをスキップして、幅と高さの8分の1のビットマップを埋めることができるため、これは非常に高速です。

もう1つのオプションは、シェルのメソッドを使用してサムネイルを抽出することです。まあ

Answer 4

私はビジョンビジネスに携わっており、OpenGLを使用してGPUに画像をアップロードするだけです。 （通常20x 2048x2000x8bpp /秒）、テクスチャごとのbmp、ビデオカードのスケーリング（win32、Mike Lischkeのopenglヘッダー）

このような画像のアップロードは、ビデオカードの種類によって異なりますが、5〜10ミリ秒かかります（統合されていない場合、nvidia 7300シリーズ以降。ごく最近の統合GPUも実行可能です）。スケーリングと表示のコストは300usです。つまり、顧客はアプリに触れることなく、狂ったようにパンおよびズームできます。その上にオーバーレイ（tmetafileでしたが、現在は独自の形式です）を描画します。

私の最大の画像は4096x7000x8bppで、30ミリ秒未満で表示およびスケーリングされます。 （GF 8600）

このテクノロジーの制限は、最大テクスチャサイズです。画像を複数のテクスチャに断片化することで解決できますが、ソフトウェアをシステムに提供するため、まだ気にしません。

（いくつかの典型的なサイズ： nv6x00シリーズ：2k * 2kが、アップロードはGDIと比較してほぼ途切れない nv7x00シリーズ：4k * 4k私にとってはベースラインカード。 GF7300は20〜40ドル程度 nv8x00シリーズ：8k * 8k ）

これはすべての人に当てはまるわけではないことに注意してください。ただし、ハードウェアの制限を指定するために幸運な状況にある場合は、動作する可能性があります。主な問題は、Thinkpadsのようなラップトップであり、そのGPUはavgラップトップよりも古いため、多くの場合デスクトップの1世代後です。

DirectXよりもOpenGLを選択したのは、時間がより静的であり、ゲームに関連しないサンプルを見つけやすいためです。

Answer 5

Graphics32ライブラリを見てみてください。物や作品を描くのに非常に優れています >すばらしいビットマップ。彼らはスレッドです-良い例で安全であり、それは完全に無料です。

Answer 6

サムネイルを作成するためにウィンドウの容量を活用します。画像を含むフォルダー内の非表示のThumbs.dbファイルを覚えていますか？

この機能のようなものをVBで実装しました。私のソフトウェアは約10秒で100ファイル（混合サイズ）のサムネイルを作成できます。

しかし、Delphiに変換することはできません。