ブラウザに DICOM 画像を表示する必要があるかどうかを知りたいのですが、どのアプローチに従うべきですか? 私のイメージ サーバーは、クラウド上の別の場所にあります。dicom 画像にアクセスし、キャンバスにペイントする必要があります。ユーザーが編集した場合は、編集した画像をサーバーにアップロードします。DICOM 画像はサイズが非常に大きい (~1GB) ため、優れたパフォーマンスも必要です。
3 に答える
1) 通常、DICOM 画像はユーザーによって変更されません。(おそらく注釈またはウィンドウ/センター値)ですが、それは異なります。
2) ほとんどの DICOM 画像は 1Mb 以下なので、あなたの画像は非常に特別です。ほとんどの標準的なビューアがそれらをロードするとは思えません。
3) 一度に 1Gb を表示できるディスプレイはないため、低解像度の画像 (最大 1mpx) を送信し、ズームされた領域の更新を送信するだけで十分です。
これらすべてを考えると、質問をよりよく説明する必要があります。
DICOM は、実際にはこのユース ケース用に設計されたものではありません。DICOM 画像が通常ユーザーによって変更されないというだけではありません (それは事実ですが)。ピクセル データを変更する場合、画像の識別子 (SOPInstanceUID) を変更するのが理にかなっている場合があり、画像のタイプを変更して、それが派生画像であることを示す必要があります。
ピクセル データを変更する場合、DICOM 画像は通常、患者の医療記録の一部である医療画像であるため、おそらく新しい画像を作成するのが最も安全です。変更しないでください。たとえば、元の画像に腫瘍の画像があり、最初の診断でこれらを見逃していた放射線科医に対する係争中の訴訟があったために削除された場合はどうなるでしょうか?
医療画像処理を行っていない場合は、DICOM を避ける必要があります。これは意図された用途では素晴らしいプロトコルですが、実際には一般的な分散画像編集プロトコルとして意図されたものではありません。
私が知っている 1GB に近づく医療画像は、病理画像だけです。その目的のために、画像を表示するために JPIP を検討することもできます (これは DICOM 仕様にもあります)。しかし、JPIP は画像を段階的に変更するのではなく、画像を消費するためのものであるため、編集部分には役立ちません。
ruslik が述べたように、DICOM 画像のサイズと性質により、これは難しい技術的問題になります。業界の人々が Web ビューアを作成するために使用している方法がいくつかあります。
- Flash、Silverlight、または Active X (昔) などのクライアント テクノロジを使用して、ほとんどの画像操作自体を実行できるクライアントを作成します。クライアントはサーバーから画像を受け取り、画像のクライアントである程度の操作を行います。ウィンドウ レベリング広告の注釈などは、クライアントで実行されます。
- サーバー側のレンダリングが行われるゼロフットプリントクライアントが使用され、ユーザーが画像を操作すると、オンデマンドで単純な JPEG 画像がクライアントに送信されます。クライアントはすべて Javascript および/または HTML5 で実行され、任意のブラウザーで実行できます。
- 最初の 2 つの組み合わせ。Flash や Silverlight などのクライアント テクノロジが使用されますが、クライアントを簡素化するためにサーバー側のレンダリングも行われます。JPEG または PNG 画像がクライアントに送信されます。
これらのソリューションのいずれかを選択する可能性が高いと思います。最後に 1 つ、これは新しいHealthcare IT Stack Exchange サイトがベータ版になったときに大きな問題になるでしょう。