6

画像ビューアを高速化する必要があります。そのために、独自のDirectXコントロールを作成することを検討する必要があるかどうか疑問に思っています。

私の画像ビューアは医用画像を表示します。それらはかなり大きくなる可能性があります。マンモグラフィに関しては55mbです。ピクセルデータは、ushort配列に格納された16ビットグレースケールです。厄介な詳細に立ち入ることなく、私の現在のアプローチは、ピクセルデータをImageSourceにロードし、WPFImageコントロールを使用することです。

DirectXで何もしたことがありません。それに飛び込む価値はありますか?ネイティブのWPFのものよりも高速でしょうか?もしそうなら、どのくらい重要ですか?または、DirectXを忘れて、現在のアプローチを改善できる領域を調べる必要がありますか?

誰かがそう言う前に、私はWPFがDirectXを利用していることを知っています。WPFレイヤーを削除してDirectXを自分で作成すると、パフォーマンスが向上するのではないかと思います。

4

2 に答える 2

3

私は、数ギガバイトの衛星画像とチャート画像を描いた経験があります。55MB 前後の画像で作業する場合は、あまり最適化を試みなくても、おそらく問題なく動作するはずです。ある選択肢を他の選択肢よりも推奨するのに十分な詳細を実際に提供していないので、長所と短所について私の意見を述べます.

2D ウィンドウ API を使用するのが最も簡単に実装でき、回転する必要がなく、単に画像を表示し、ズームとパンを行いたい場合は、常に十分に高速である必要があります。それを 1 つの大きな画像として扱うと、滑らかな画像にするためにハーフトーンで描画している場合、ズームアウトしたときにパフォーマンスが低下します。これは、描画するたびに 55 MB の画像すべてを効果的に読み取る必要があるためです。

このパフォーマンスの問題を回避するには、複数のビットマップを作成して、画像を効果的にミップマッピングします。縮小すると、描画しようとしている解像度に最も近い低解像度の画像を選択できます。ミップマッピングに慣れていない場合は、ウィキペディアのリンクを次に示します。

http://en.wikipedia.org/wiki/Mipmap

DirectX で実装するのは 10 倍難しくなります。グラフィックス ハードウェアが異なれば、テクスチャの最大サイズも異なります。ほとんどの場合、描画するために画像を複数のテクスチャに分割する必要があり、また、レンダリング ステートや表示マトリックスなどを追跡する必要があります。

ただし、DirectX を使用する場合は、多くのリアルタイムの写真調整を実装できます。ビュー マトリックスを調整するだけで、リアルタイムの回転を行うことができます。ピクセル シェーダーでは、リアルタイムのコントラスト、明るさ、ガンマ、およびシャープネスを簡単に実行できます。

他に 2 つの API をお勧めします。Vista 以降に限定したい場合は、Direct2D の方が Direct3D よりも少し単純です。また、Windows 以外のプラットフォームで実装する必要がある場合は、代わりに OpenGL を使用することをお勧めします。私の現在のプロジェクトは Direct3D です。数年前に開始したとき、OpenGL は遅れをとっていたので、Android デバイスの普及を予測していませんでした。代わりに OpenGL を使用していればよかったのにと思います。

于 2012-09-22T04:46:15.297 に答える
1

プロファイリングを試して、WPF がどこで時間を費やしているかを確認してください。ネイティブ解像度で画像を表示していますか? そうでない場合は、前処理を行って 1/2 解像度のバージョンを作成する価値があるかもしれません。

于 2012-08-24T02:50:51.410 に答える