1

これらの配列は、実際には DICOM 画像からのピクセル データです。それらをピクセル配列（それぞれ約1MB）の配列（サイズ100）として送信すると、ブラウザが明らかに過負荷になります。プログラミングの初心者なので、大きなファイルを経済的にロードする作業を開始するための正しい方向性を示していただければ幸いです。つまり、イメージ スタックをブラウザ ウィンドウに、できれば動的にロードします。クエリが明確でない場合の謝罪

4

2 に答える 2

1

うーん...あなたのアプリケーションは両方同時にですか？DICOM サーバーと DICOM ビューア?

サーバーは query-retrieve SOP クラスに応答して画像を配信するように構成されており、ビューアーはそれらの要求を送信するシステムになります。

DICOM の概念では、サーバーは画像を提供するだけで、ビューアーはそれらを表示していると言うでしょう (ローカル ファイル管理などを含む)。

これはファット クライアント (たとえば、ビューアを Web ブラウザに表示させたい場合は JavaScript) になります。そうしないと、必要な速度で画像を操作できなくなります (スムーズなスクロール、おそらく 3D 再構築)。など）。

サーバーで画像のプレビュー機能を使用したいだけの場合は、最大 10 ～ 16 個のサムネイル画像を含むページを作成し、1 つまたは 2 つのフルサイズの画像に対して 1 つのビューを作成し、ユーザーが望む場合は要求ごとにそれらをロードすることをお勧めします。一連の画像または単一の画像をプレビューします。これにより、ロード時間が大幅に短縮され、ユーザーは完全なリクエストを送信する前に画像を事前に選択できます。

完全なビューアについては、クライアントでのローカル ソリューションを検討します。Web ベースにするかどうか (または混在させるかどうか) は、今後のアプリケーションによって異なります。

過去のプロジェクトでは、dcm4che などの既存のオープン ソース DICOM サーバーを使用してサーバー部分を処理し、そこからデータを取得しました。しかし、教育システムの場合は、サーバーを独自に構築して、概念のすべての部分を示すのも興味深いかもしれません。

お気軽にコメントしてください。投稿を更新して質問にお答えします。

于 2013-11-05T05:23:21.537 に答える
0

プレーンな html5 だけを使用してマルチフレーム dicom ビューアーを開発しようとすると、まったく同じ問題が発生しました。

このような大量の画像データをブラウザーにロードできるようにするために、クライアント側で Web ストレージ技術を使用してみることにしました。特に、 indexedDBでいくつかの初期テストを行うことを検討していました。

悲しいことに、私は現在別のタスクに携わっているため、Web ビューアーの開発は現在停止されており (再び!)、これらのテストはまだ元に戻されています。

とにかく、indexedDBで概念実証を試みます。

于 2013-10-31T07:03:48.620 に答える