医用画像の分散画像処理
【課題】分散型網の全体にわたって医用画像処理タスクを効率的に割り当てる。分散型医用イメージング・システムの利用者に柔軟性及び制御を提供する。
【解決手段】サーバ３０２、クライアント３１２及び通信経路３０５に関連するシステム資源３０８、３１６を含んでいる分散型網で通信を行ない、監視データを生成するように、少なくとも一つの工程モニタ３１０、３１４でシステム資源３０８、３１６及び帯域幅を監視し、クライアント３１２に表示可能な二次元画像データを形成するように三次元画像データを処理するためのシステム資源３０８、３１６の少なくとも一部の割当てを、監視データに少なくとも部分的に基づいて推奨する。
【解決手段】サーバ３０２、クライアント３１２及び通信経路３０５に関連するシステム資源３０８、３１６を含んでいる分散型網で通信を行ない、監視データを生成するように、少なくとも一つの工程モニタ３１０、３１４でシステム資源３０８、３１６及び帯域幅を監視し、クライアント３１２に表示可能な二次元画像データを形成するように三次元画像データを処理するためのシステム資源３０８、３１６の少なくとも一部の割当てを、監視データに少なくとも部分的に基づいて推奨する。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願の実施形態は一般的には、分散処理に関する。具体的には、幾つかの実施形態は、クライアントに画像を表示するためにクライアントとサーバとの間で医用画像データ処理を割り当てることに関する。
【背景技術】
【０００２】
現代のコンピュータの急増に伴って、コンピュータ網（ネットワーク）も急増している。コンピュータ網には、構内網（ＬＡＮ）、広域網（ＷＡＮ）、有線網、無線網及び光網等、又はこれらの任意の組み合わせがある。ネットワークは、ネットワーク上の個々のコンピュータの間の通信を可能にする。
【０００３】
データを共有することに加え、コンピュータ網はまた、コンピュータ資源の共有を容易にする。資源を共有したネットワークでは、個々のコンピュータが利用可能な全資源量が増強される。資源を共有したネットワークを分散型網とも呼ぶことができる。というのは、ネットワークで利用可能な全資源がネットワークの全体に分散しているからである。
【０００４】
分散型網との用語は広い意味であり、広範なネットワーク・モデルを包含している。例えば、分散型網はサーバ中心型網であってもよいし、クライアント中心型網であってもよい。サーバ中心型網は、何らかの重要資源がサーバによって供給されるように設計され得る。このことは、例えば相対的に安価なクライアント又は処理能力をあまり有しないクライアントが求められる場合に有利であり得る。対照的に、クライアント中心型網は、何らかの重要資源の供給についてクライアントの方により多く頼る場合がある。
【０００５】
ネットワークに影響を及ぼし得る要因の一つに、帯域幅がある。比較的低い帯域幅の分散型網では、網通信量を低減する設計を選択すると望ましい場合がある。例えば、低帯域幅ネットワークでは、サーバ中心型網を提供すると望ましい場合がある。対照的に、相対的に高い帯域幅の分散型網は、アーキテクチャの柔軟性を高めることができる。
【０００６】
合成モデル撮像のための分散型網は公知である。例えば、米国特許第６，３７７，２５７号「METHODS AND APPARATUS FOR DELIVERING 3D GRAPHICS IN A NETWORKED ENVIRONMENT」（以下「Borrel特許」と呼ぶ。特許文献１）は、クライアント及びサーバの両方で合成モデルをレンダリングする方法を議論している。Borrel特許の示すところによれば、従来技術の諸方式は、合成モデルをその構成部分（例えば前景物体及び背景）に分解して、サーバに構成部分の幾つかをレンダリングさせ、クライアントに残りの構成部分をレンダリングさせることにより動作するとして公知である。
【０００７】
加えて、合成モデリング・システムは、クライアントからのフィードバックに基づいて分散型撮像手法を適応構成するとして公知である。Borrel特許は、クライアントからフィードバックを供給する方式について議論している。かかるフィードバックは、誤差補正、利用者定義によるフィードバック及び画質から成る。サーバは、フィードバックを処理し、次いで、効率的な解に到達するために分散型工程に調節を加えるように試みなければならない。
【０００８】
しかしながら、合成モデリングに適用可能な解は、医療撮像には実用的でないことが判明する場合がある。モデリングとは異なり、医用画像は有機的でありすなわち一元的である傾向がある。換言すると、医用画像は、構成部分に容易に分解し得ない場合がある。例えば、人体の脊椎の合成モデルは、該モデルを生成して、各々の椎骨、各々の椎間板、各々の椎骨の表面テクスチャ生成、及び各々の椎間板の表面テクスチャ生成等を含めて多様な構成部分に基づいて記憶することができる。対照的に、人体の脊椎の医用画像（例えばＸ線によって撮影したもの）はかかる成分的構成要素を含んでいない場合がある。その代わりに、人体の脊椎の医用画像は、成分的構成要素には容易に分解しない一元的な画像であり得る。このように、分解という解が医用画像の分散型撮像に実用的でない場合がある。
【０００９】
加えて、フィードバック依存型の適応型手法では、処理タスクの開始時に分散型資源の効率的な割当てに失敗する場合がある。換言すると、フィードバック依存型のシステムは最終的には、効率的な解に引き付けられ得るが、タスクの開始時に資源を効率的に割り当てない場合がある。さらに、フィードバックは資源の効率的な割当てを決定する大まかな尺度であり得る。例えば、公知の形式のフィードバックは、タイム・スタンプを用いてクライアントがどの程度高速にタスク又はその一部を実行するかを測定する。かかるフィードバック情報は、ネットワーク帯域幅、クライアントの中央処理ユニット（「ＣＰＵ」）の速度及び負荷、クライアントのランダム・アクセス・メモリの空き容量、クライアントのビデオ・メモリの空き容量、並びにサーバのＣＰＵ速度及び負荷等を含めた広範な要因に基づいて変化し得る。このように、いずれの特定のファクタがフィードバック情報に影響を与え得るかを効率的に決定するのが不可能な場合がある。
【００１０】
医用画像を表示するためには、医用イメージング・システムの利用を介して取得された医用画像データを処理することができる。計算機式断層写真法（ＣＴ）走査システムのような医用イメージング・システムは、画像データをスライスとして得ることができる。スライスは二次元（２Ｄ）スライスであってよい。１枚のスライスは第三の次元については比較的小さい厚みを有し得るが、スライスを２Ｄとして参照する方が概念的には好都合であろう。関心のある３Ｄ空間の様々な断面に対応する多数の２Ｄスライスを得ることができる。複数の２Ｄ画像データ・スライスを処理して３Ｄ画像データ空間とすることができる。１又は複数の相対的に大きいデータ・ファイルが、３Ｄ医用画像データ空間を記憶し且つ／又は処理することができる。
【００１１】
医師は、さらなる処理を行なわなければ３Ｄ医用画像データ空間を観察することができない場合がある。フラット・パネル液晶ダイオード表示器又は陰極線管表示器のような表示器は、２Ｄ画像を表示することができるに留まる場合がある。但し、２Ｄ画像は観察者にとって３Ｄとして見えるようにすることができる。このように、表示器に医用画像を表示するために、３Ｄデータを処理して２Ｄデータを形成することができる。
【００１２】
３Ｄ画像データを処理して２Ｄ画像データとする多様な手法が公知である。これらの手法には、多断面再構成（ＭＰＲ）、最大（又は最小）強度投影（ＭＩＰ）及びボリューム・レンダリング（ＶＲ）等がある。ＭＰＲ処理では、３Ｄ空間を処理して２Ｄスライスを得ることができ、この２Ｄスライスを医用イメージング・システムによって得られたスライスとは異なるものにすることができる。例えば、ＭＰＲ機能を組み入れたアプリケーションは、利用者が空間内の任意の位置を中心として表示画像を任意の角度で回転させることを可能にすることができる。このように、ＭＰＲは、医師が多様な位置及び角度の任意のものから解剖学的構造を観察することを可能にする。
【００１３】
ＭＩＰ処理では、３Ｄ空間を処理して、観察者が３Ｄであるものと認知し得る２Ｄスライスを得ることができる。ＭＩＰ処理は、複数の２Ｄスライスの積層の結合である２Ｄ画像を作成することができる。各々の２Ｄスライスのピクセルを結合して２Ｄ画像を形成する幾つかの方法が存在する。例えば、最終的な２Ｄ画像の各々のピクセルを、２Ｄスライスの積層の対応するピクセルの中で最も明るいピクセル又は最も暗いピクセルとすることができる。もう一つの例では、最終的な２Ｄ画像の各々のピクセルを、２Ｄスライスの積層の対応するピクセルの平均としてもよい。
【００１４】
ＶＲ処理は、３Ｄ空間を２Ｄで表示するもう一つの方法である。ＶＲ処理は、対象の表面及び／又は内部をレンダリングして、対象の表面が中実、透明及び／又は半透明に見えるようにする。関心のある空間（器官、血管及び骨等）の内部の対象も、中実、透明及び／又は半透明に見えるようにすることができる。
【特許文献１】米国特許第６，３７７，２５７号
【発明の開示】
【発明が解決しようとする課題】
【００１５】
３ＤデータをＭＰＲ、ＭＩＰ及びＶＲのような２Ｄ表示可能な画像へ変換する手法は、医師にとって有用であろう。加えて、かかる手法はまた、データの容量を大幅に減少させることができる。２Ｄ表示可能な画像は、３Ｄデータ空間の容量の小部分となり得る。しかしながら、ＭＰＲ、ＭＩＰ及びＶＲのような手法は、かなりの処理資源量を消費し得る。処理資源が直ちに利用可能でない場合には、撮像能力は低速化し又は劣化し得る。同様に、ネットワークが比較的低い帯域幅を有する場合には、ネットワークを横断して３Ｄ画像データを転送するのに比較的長い時間が掛かる可能性がある。さらに、３Ｄデータ及び処理後の２Ｄデータの両方についての画質のような他の要因が画像表示システムの能力に影響を及ぼす可能性もある。
【００１６】
このように、分散型網で医用画像データを効率的に処理する方法及びシステムが求められている。加えて、分散型網の全体にわたって医用画像処理タスクを効率的に割り当てる方法及びシステムが求められている。また、分散型医用イメージング・システムの利用者に柔軟性及び制御を提供する方法及びシステムが求められている。
【課題を解決するための手段】
【００１７】
本発明の幾つかの実施形態は、分散型網での医用画像処理の方法を提供し、この方法は、サーバ、クライアント及び所定の帯域幅を有する通信経路を備えており、サーバ、クライアント及び通信経路に関連するシステム資源を含んでいる分散型網で通信を行なうステップと、監視データを生成するように、少なくとも一つの工程モニタでシステム資源及び帯域幅を監視するステップと、クライアントに表示可能な二次元画像データを形成するように三次元画像データを処理するためのシステム資源の少なくとも一部の割当てを、監視データに少なくとも部分的に基づいて推奨するステップと、を含んでいる。一実施形態では、二次元画像データを形成するように三次元画像データを処理する処理は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つを含んでいる。一実施形態では、二次元画像データを形成するように三次元画像データを処理する処理は、回転、ズーム、パン、コントラスト調節、輝度調節及び濃淡調節の少なくとも一つを含んでいる。一実施形態では、画像は医用画像データに対応している。一実施形態では、少なくとも一つの工程モニタは、クライアント側モニタ及びサーバ側モニタを含んでいる。一実施形態では、割当ては、サーバ及びクライアントの少なくとも一方によって自動的に受け入れられる。一実施形態では、システム資源は、サーバの処理負荷及びクライアントの処理速度を含んでいる。一実施形態では、システム資源はさらに、クライアントの処理能力を含んでいる。一実施形態では、この方法はさらに、監視データに少なくとも部分的に基づいて画像の画質を推奨するステップを含んでいる。
【００１８】
本発明の幾つかの実施形態は、医用画像処理のシステムを提供し、このシステムは、資源を処理するサーバを含んでおり、三次元画像データを記憶することが可能なサーバと、所定の帯域幅を有する通信経路を介したサーバとの通信が可能であり、資源を処理するクライアントを含んでおり、三次元画像データから形成された二次元画像を表示することが可能なクライアントと、資源を処理するクライアント、資源を処理するサーバ及び帯域幅に少なくとも部分的に基づいて、クライアントに画像を表示するために資源を処理するサーバの少なくとも一部及び資源を処理するクライアントの少なくとも一部を割り当てることが可能な構成制御と、を含んでいる。一実施形態では、構成制御は、資源を処理するクライアント、資源を処理するサーバ及び帯域幅に少なくとも部分的に基づいて、クライアントとサーバとの間での画像処理の配分についての推奨を供給する推奨供給器と相互作用することが可能である。一実施形態では、二次元画像は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つによって三次元画像データから形成可能である。一実施形態では、構成制御は、利用者によって調節可能である。一実施形態では、構成制御はさらに、画像の画質を制御することが可能である。一実施形態では、構成制御は、帯域幅、資源を処理するサーバ及び資源を処理するクライアントに対応する情報を受け取ることが可能である。一実施形態では、構成制御は、推奨供給器の推奨を無視することが可能である。一実施形態では、構成制御は、画質の事前指定の無視を帰結することが可能である。
【００１９】
本発明の幾つかの実施形態は、クライアントとサーバとの間で画像処理を配分するシステムを提供し、このシステムは、資源を処理するサーバを含んでおり、三次元医用画像データを記憶することが可能なサーバと、資源を処理するクライアントを含んでおり、二次元画像を表示することが可能なクライアントと、クライアントとサーバとの間に設けられており、所定の帯域幅を含む通信路と、監視データを生成するように、帯域幅、資源を処理するクライアント及びサーバ資源を監視する少なくとも一つの工程モニタと、二次元画像を形成するように三次元画像データを処理するために、監視データに少なくとも部分的に基づいてクライアントとサーバとの間での処理の配分を含む推奨を供給する推奨供給器と、を含んでいる。一実施形態では、三次元画像データは、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つで二次元画像を形成するように処理可能である。一実施形態では、モニタはさらに、監視データを形成するためにクライアントの処理能力を監視する。一実施形態では、少なくとも一つの工程モニタは、サーバ側工程モニタ及びクライアント側工程モニタを含んでいる。一実施形態では、推奨の少なくとも一部は、サーバ及びクライアントの少なくとも一方によって自動的に受け入れられる。一実施形態では、推奨はさらに、画像の画質を含んでいる。
【００２０】
本発明の幾つかの実施形態は、コンピュータ用の命令セットを含むコンピュータ読み取り可能な記憶媒体を提供し、命令セットは、クライアント及びサーバ、並びにクライアント及びサーバを結合する所定の帯域幅の通信路を含む分散型網のシステム資源を監視して、監視データを生成する監視ルーチンと、サーバに記憶可能な三次元画像データを処理することにより形成可能な二次元画像のクライアントでの表示を要求する要求ルーチンと、監視データに少なくとも基づいて、二次元画像をクライアントにおいて表示するために二次元画像の画質及び分散型網でのシステム資源の割当てを推奨する推奨ルーチンと、を含んでいる。一実施形態では、システム資源は、サーバの処理負荷及びクライアントの処理速度を含んでいる。一実施形態では、システム資源の割当ては、３Ｄ画像処理及び２Ｄ画像処理のためのサーバに対応するシステム資源の割当て、３Ｄ画像処理及び２Ｄ画像処理のためのクライアントに対応するシステム資源の割当て、並びにシステムの割当ての少なくとも一つを含んでいる。一実施形態では、サーバに対応する資源を３Ｄ画像処理のためのものとし、クライアントに対応するシステム資源を２Ｄ画像処理のためのものとする。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられていないことを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理及び２Ｄ画像処理のためにサーバに対応するシステム資源の割当てを推奨する。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられており、通信路の帯域幅が実質的な遅延を伴わずにサーバからクライアントへ三次元画像データを通信することが可能であることを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理及び２Ｄ画像処理のためにクライアントに対応するシステム資源の割当てを推奨する。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられており、通信路の帯域幅が実質的な遅延を伴ってサーバからクライアントへ三次元画像データを通信することが可能であることを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理のためにサーバに対応するシステム資源及び２Ｄ画像処理のためにクライアントに対応するシステム資源という割当てを推奨する。
【発明を実施するための最良の形態】
【００２１】
以上の概要、及び本出願の幾つかの実施形態についての以下の詳細な説明は、添付図面と共に精読するとさらに十分に理解されよう。本発明を説明する目的で幾つかの実施形態を図面に示す。しかしながら、本発明は、添付図面に示されている構成及び手段に限定されないことを理解されたい。
【００２２】
図１は、本出願の一実施形態による分散型網１００のブロック図を示す。分散型網１００は、サーバ１０２、クライアント１０４及び通信経路１０６を含み得る。通信経路１０６は関連する帯域幅を有する。通信経路１０６の帯域幅は、通信経路１０６全体にわたり一様であってもよいし、様々なセグメントに沿って変化してもよい。例えば、通信経路１０６は、銅ワイヤ撚り二線式網及び光網のように様々な帯域幅を有する様々な形式のネットワークの組み合わせを含み得る。通信経路１０６は、構内網（ＬＡＮ）、広域網（ＷＡＮ）、有線網、無線網及び光網等、又はこれらの任意の組み合わせを含み得る。同様に、通信経路１０６は、ルータ、リピータ、スイッチ、ハブ、スプリッタ、カプラ又は中継コンピュータ等のような様々な網要素を含み得る。
【００２３】
図２は、本出願の一実施形態による分散型イメージング・システム１００のブロック図を示す。サーバ１０２は、ＣＰＵ２０２、キャッシュ・メモリ２０４、記憶メモリ２０６、ＲＡＭ２０８、オペレーティング・システム２３０、並びに他のドライバ及びアプリケーション２３２を含み得る。ＣＰＵ２０２は、多数のプロセッサを含み得る。キャッシュ・メモリ２０４は、ＣＰＵ２０２によって高速にアクセスされ得る揮発性メモリを含み得る。記憶メモリ２０６は、磁気ハード・ドライブ、光ハード・ドライブ、フラッシュ・メモリ又はＥＥＰＲＯＭ等のようなディジタル不揮発性記憶装置を含み得る。ＲＡＭ２０８は、ダイナミックＲＡＭ、スタティックＲＡＭ又はバッテリ・バックアップ式ＲＡＭ等を含み得る。オペレーティング・システム２３０は、例えばWindows（登録）、Unix（商標）、Linux（商標）又はMacintosh（商標）等のオペレーティング・システムを含み得る。オペレーティング・システム２３０は、サーバ１０２での動作向けに設計されていてよい。オペレーティング・システム２３０は、様々なサーバ１０２構成要素の間での相互作用を容易にすることができる。他のドライバ及びアプリケーション２３２は、多様なハードウェア・モジュール及びソフトウェア・モジュールを含み得る。例えば、他のドライバ及びアプリケーション２３２は、グラフィックス・アクセラレータ・ハードウェア・モジュール及び三次元グラフィックス・プロセッサ・ソフトウェア・モジュールを含み得る。他のドライバ及びアプリケーション２３２は、医用画像処理を容易にするためのドライバ及びアプリケーションを含み得る。本出願で用いられる画像処理との用語は、例えば画像表示及びボリューム・レンダリングを含めた広い意味の用語である。画像処理は、例えば２Ｄ画像データ、３Ｄ画像データ及び２Ｄ投影画像データの処理等を含み得る。画像処理は、例えばＭＰＲ、ＭＩＰ及びＶＲ等を含み得る。画像データは、例えばＤＩＣＯＭ、ＡＮＡＬＹＺＥ、ＢＭＰ、ＪＰＧ、ＧＩＦ及びＴＩＦ等を含めた多様なフォーマットに書式化されていてよい。画像データは、圧縮されていてもよいしいなくてもよい。
【００２４】
クライアント１０４は、パーソナル・コンピュータ、デスクトップ、ラップトップ、ワークステーション、ダム端末又はシン・クライアント等であってよい。クライアント１０４は、ＣＰＵ２１０、表示ドライバ２１２、表示器２１４、ユーザ・インタフェイス２１６、キャッシュ・メモリ２１８、記憶メモリ２２０、ビデオ・メモリ２２２、ＲＡＭ２２４、オペレーティング・システム２２６、並びに他のドライバ及びアプリケーション２２８を含み得る。ＣＰＵ２１０は、多数のプロセッサを含み得る。表示ドライバ２１２は、表示器２１４を駆動するように特殊化されたハードウェアを含み得る。表示器２１４は、陰極線管、フラット・パネル・モニタ、液晶表示器又は発光ダイオードのアレイ等を含み得る。ユーザ・インタフェイス２１６は、マウス及びキーボード、又は利用者からの動作を受け入れるその他外部入力装置を含み得る。キャッシュ・メモリ２１８は、ＣＰＵ２１０によって高速にアクセスされ得る揮発性メモリを含み得る。記憶メモリ２２０は、磁気ハード・ドライブ、光ハード・ドライブ、フラッシュ・メモリ又はＥＥＰＲＯＭ等のようなディジタル不揮発性記憶装置を含み得る。ビデオ・メモリ２２２は、ダイナミックＲＡＭビデオのようなＲＡＭを含み得る。ビデオ・メモリ２２２は、対応する画像が表示器２１４に表示される前に画像データをバッファリングすることができる。ＲＡＭ２２４は、ダイナミックＲＡＭ、スタティックＲＡＭ又はバッテリ・バックアップ式ＲＡＭ等を含み得る。オペレーティング・システム２２６は、例えばWindows（商標）、Unix（商標）、Linux（商標）又はMacintosh（商標）等のオペレーティング・システムを含み得る。オペレーティング・システム２２６は、クライアント１０４での動作向けに設計されていてよい。オペレーティング・システム２２６は、様々なクライアント１０４構成要素の間での相互作用を容易にすることができる。他のドライバ及びアプリケーション２２８は、多様なハードウェア・モジュール及びソフトウェア・モジュールを含み得る。例えば、他のドライバ及びアプリケーション２２８は、グラフィックス・アクセラレータ・ソフトウェア・モジュール及び三次元グラフィックス・プロセッサ・ハードウェア・モジュールを含み得る。他のドライバ及びアプリケーション２２８は、ＭＰＲ、ＭＩＰ及びＶＲ等のような医用画像データ処理を容易にするためのドライバ及びアプリケーションを含み得る。
【００２５】
図３は、本出願の一実施形態による分散型イメージング・システム３００のブロック図を示す。サーバ３０２は、図１及び図２に示すサーバ１０２と同様のものであってよい。サーバ３０２は、サーバ資源３０８、サーバ側モニタ３１０及び推奨供給器３０６を含み得る。サーバ資源３０８は、図２に示すサーバ構成要素の諸相を含み得る。例えば、サーバ資源３０８は、ＣＰＵ２０２、キャッシュ・メモリ２０４、記憶メモリ２０６、ＲＡＭ２０８、オペレーティング・システム２３０、並びに他のドライバ及びアプリケーション２３２の諸相を含み得る。サーバ資源３０８は、オペレーティング・システム２３０の形式及びバージョン情報、ＣＰＵ２０２の空き状況、ＲＡＭ２０８の空き容量、キャッシュ２０４の空き容量、記憶メモリ２０６の空き容量、並びに他のドライバ及びアプリケーション２３２の形式、バージョン及び空き状況を含み得る。例えば、サーバ資源３０８は、ＣＰＵ２０２の負荷状況を含むこともできるし、未処理要求の待ち行列に対応する情報を含むこともできる。
【００２６】
サーバ側モニタ３１０は、システム資源及び通信経路３０５の帯域幅を監視することができる。システム資源は、サーバ資源３０８及びクライアント資源３１６を含み得る。サーバ側モニタ３１０は、システム資源及び帯域幅に対応する監視データを供給することができる。サーバ側モニタは、例えば、サーバ資源３０８及び通信経路３０５の帯域幅を監視することができる。サーバ側モニタ３１０はまた、クライアント３１２と通信して、例えばクライアント資源３１６のようにクライアント側モニタ３１４によって収集された情報を受け取ることができる。サーバ側モニタ３１０はまた、クライアント３１２と通信して、性能指標器３２０からの情報を受け取ることもできる。サーバ側モニタ３１０は省かれてもよいし、サーバ３０２に対して外部に位置する装置として設けられてもよい。サーバ側モニタ３１０は、ソフトウェア、ハードウェア、又はファームウェア若しくはこれらの任意の組み合わせで具現化され得る。また、クライアント３１２にサーバ側モニタ３１０を含めることも可能であり得る。サーバ側モニタ３１０は、サーバ資源３０８の幾つか及び帯域幅に対応する情報を繰り返しチェックすることができる。例えば、サーバ側モニタ３１０は、サーバＣＰＵ２０２（図２に示す）に対する負荷を周期的にチェックすることができる。というのは、サーバＣＰＵ２０２の負荷はサーバ１０２の動作中に変化し得るからである。サーバ側モニタ３１０はまた、サーバ資源３０８の幾つか及び帯域幅に対し、１回限りのチェックを行なうこともできる。例えば、サーバ側モニタ３１０は、起動時にのみサーバのオペレーティング・システム２３０（図２に示す）のバージョンをチェックすることができる。というのは、オペレーティング・システムのバージョンはサーバ３０２の連続動作中には変化しない可能性が高いからである。
【００２７】
推奨供給器３０６は、サーバ３０２とクライアント３１２との間でのシステム資源の割当てを推奨する。推奨供給器３０６は、サーバ側モニタ３１０、クライアント側モニタ３１４、構成制御３１８及び性能指標器３２０によって収集された情報を扱うことができる。推奨供給器３０６はサーバ３０２に位置している必要はない。推奨供給器３０６は、クライアント３１２の一部であってもよいし、通信経路３０５で通信する追加装置であってもよいし、サーバ３０２、クライアント３１２又は追加装置の全体に分散されていてもよい。推奨供給器３０６は、ソフトウェア、ハードウェア若しくはファームウェア、又はこれらの組み合わせで具現化され得る。推奨供給器３０６については後にあらためて詳述する。
【００２８】
クライアント３１２は、クライアント資源３１６、クライアント側モニタ３１４、構成制御３１８及び性能指標器３２０を含み得る。クライアント３１２は、図２に示すクライアント１０４と同様のものであってよい。クライアント資源３１６は、図２に示すクライアント１０４構成要素を含み得る。例えば、クライアント資源は、ＣＰＵ２１０、キャッシュ・メモリ２１８、記憶メモリ２２０、ＲＡＭ２２４、ビデオ・メモリ２２２、表示ドライバ２１２、表示器２１４、ユーザ・インタフェイス２１６、オペレーティング・システム２２６、並びに他のドライバ及びアプリケーション２２８の諸相を含み得る。クライアント資源３１６は、オペレーティング・システム２２６の形式及びバージョン情報、ＣＰＵ２１０の空き状況、ＲＡＭ２２４の空き容量、キャッシュ２１０の空き容量、記憶メモリ２２０の空き容量、ビデオ・メモリ２２２の空き容量、表示器２１４の形式、表示ドライバ２１２の形式、並びに他のドライバ及びアプリケーション２２８の形式、バージョン及び空き状況を含み得る。例えば、クライアント資源３１６は、表示ドライバ２１２及びＣＰＵ２１０動作速度に対応するハードウェア情報及びソフトウェア情報を含み得る。
【００２９】
クライアント側モニタ３１４は、システム資源及び通信経路３０５の帯域幅に対応する情報を集積することができる。クライアント側モニタ３１４は特に、クライアント資源３１６及び帯域幅を監視することができる。クライアント側モニタは、システム資源及び帯域幅に対応する監視データを供給することができる。クライアント側モニタ３１４はまた、サーバ３０２と通信して、例えばサーバ資源３０８のようにサーバ側モニタ３１０によって収集された情報を受け取ることができる。クライアント側モニタ３１４は、性能指標器３２０からの情報を受け取ることができる。クライアント側モニタ３１４は省かれてもよいし、クライアント３１２に対して外部に位置する装置として設けられてもよい。また、サーバ３０２に別個の装置としてクライアント側モニタ３１４を含めることも可能であるし、クライアント側モニタ３１４が網構成装置の全体に分散されていてもよい。クライアント側モニタ３１４は、ソフトウェア、ハードウェア若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。クライアント側モニタ３１４は、クライアント資源３１６の幾つか及び帯域幅に対応する情報を繰り返しチェックすることができる。例えば、クライアント側モニタ３１４は、クライアントＲＡＭ２２４の空き容量を周期的にチェックすることができる。というのは、ＲＡＭ２２４の空き容量はクライアント１０４の動作中に変化し得るからである。クライアント側モニタ３１４はまた、クライアント資源３１６の幾つか及び帯域幅に対し、１回限りのチェックを行なうこともできる。例えば、クライアント側モニタ３１４は、起動時にのみ表示ドライバ２１２に対応する情報をチェックすることができる。というのは、表示器ドライバ２１２は、クライアント３１２の連続動作中には変化しない可能性が高いからである。
【００３０】
性能指標器３２０は、クライアント３１２の１又は複数の能力規準を推定し且つ／又は集積することができる。性能指標器３２０は、クライアント３１２の一部であってもよいし、サーバ３０２の一部であってもよいし、追加装置であってもよいし、ネットワークの全体に分散されていてもよい。性能指標器３２０は、ソフトウェア、ハードウェア及び／若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。一例として、性能指標器３２０は、医用画像を表示するためのクライアント３１２の処理能力を推定することができる。性能指標器３２０は、利用者が観察するようにクライアント３１２が医用画像を表示器２１４に表示する速度又は迅速性に対応する情報を供給することができる。工程指標器３１８は、クライアント側モニタ３１４、サーバ側モニタ３１０、構成制御３１８及び／又は推奨供給器３０６と通信して、情報を共有することができる。
【００３１】
構成制御３１８は、システム資源を割り当て、また画質のような他の変数に値を設定する能力を提供するクライアント側モジュールであってよい。構成制御３１８は、クライアント３１２の一部であってもよいし、サーバ３０２の一部であってもよいし、追加装置であってもよいし、ネットワークの全体に分散されていてもよい。構成制御３１８は、ソフトウェア、ハードウェア及び／若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。構成制御３１８は、利用者が、クライアント３１２のユーザ・インタフェイス２１６（図２にクライアント１０４の一部として示す）と相互作用（対話）して、如何にシステム資源を割り当て、また他の変数を設定すべきであるかを指令するのを可能にすることができる。構成制御３１８は、システム管理者が、如何にシステム資源を割り当てて設定すべきであるかを指令するのを可能にすることができる。構成制御３１８は、分散型撮像工程が分散型システム３００に如何に割り当てられるかを決定することができる。構成制御３１８は、クライアント１０４及びサーバ１０２の図２に示す様々な構成要素と通信することができる。構成制御３１８は、オペレーティング・システム２３０と通信するソフトウェア・モジュールの形態であってよい。構成制御３１８は、画像処理アプリケーションに統合されて、例えば「設定」、「オプション」又は「初期設定」のようなメニュー選択肢を介してアクセス可能にされ得る。構成制御３１８の動作については後にあらためて詳述する。
【００３２】
通信経路３０５の帯域幅は、クライアント３１２に医用画像を表示するために如何にシステム資源を割り当てるかを決定する要因となり得る。帯域幅は、クライアント３１２又はサーバ３０２のいずれかによって推定され又は測定され得る。例えば、クライアント側モニタ３１４又はサーバ側モニタ３０４は、多くの公知の手法の任意のものによって帯域幅を推定することができる。帯域幅を推定する一手法は、通信経路３０５を介して既知のサイズの試験用パケットを通信して、試験用パケット通信の完了に掛かる時間を測定するものである。
【００３３】
図７は、本発明の一実施形態による分散型撮像表示の方法７００の流れ図を示す。第一の枝７４０、第二の枝７５０及び第三の枝７６０の３列の異なる枝が示されている。枝７４０、７５０及び７６０の各々は、ステップ７０２で開始することができ、このステップでは、３Ｄ画像データをサーバ（図３に示すサーバ３０２等）に記憶させる。枝７４０、７５０及び７６０の各々は、ステップ７２８で終了することができ、このステップでは、２Ｄ画像データを処理して、クライアント（図３に示すクライアント３１２と同様のもの）の表示器に表示させる。点線７３０は、いずれのステップがサーバによって実行されいずれのステップがクライアントによって実行されるかを示す。ステップ７０２のように点線７３０よりも上の全ステップがサーバによって実行され得る。ステップ７２８のように点線７３０よりも下の全ステップがクライアントによって実行され得る。
【００３４】
ステップ７０２の後に、第一の枝７４０はステップ７０４に続き、このステップでは、３Ｄ画像データをサーバによって処理して２Ｄ画像データを形成することができる。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。ステップ７０６では、２Ｄ画像データをさらに処理して、表示される画像データを形成することができる。例えば、２Ｄ画像データは、濃淡、コントラスト及び／又は輝度を調節することによりさらに処理され得る。ステップ７０８で２Ｄ画像データはサーバから送信され、ステップ７１０でクライアントによって受信されることができる。ステップ７２８では、２Ｄデータをクライアントによって処理して表示させることができる。
【００３５】
第二の枝７５０は、ステップ７０２の後にステップ７１２へ進み、このステップでは、サーバが３Ｄ画像データを処理して２Ｄ画像データを形成する。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。次に、ステップ７１４で２Ｄ画像データはサーバから送信されて、ステップ７１６でクライアントによって受信される。２Ｄ画像データの受信の後に、クライアントは２Ｄ画像データをさらに処理して、表示用の画像データを形成することができる。ステップ７２８では、クライアントは２Ｄ画像データを処理して表示器に表示させることができる。
【００３６】
第三の枝７６０は、ステップ７０２の後にステップ７２０へ進み、このステップでは、３Ｄ画像データはサーバから送信されて、ステップ７２２でクライアントにおいて受信される。ステップ７２４では、クライアントが３Ｄ画像データを処理して２Ｄ画像データを形成することができる。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。次に、クライアントは、２Ｄ画像データをさらに処理して、表示用の画像データを形成することができる。ステップ７２８では、クライアントは、２Ｄ画像データを処理して、表示器に表示させることができる。点線７３０の角度から分かるように、クライアント及びサーバによって実行される処理の量は、流れ図７００のいずれの枝を辿っているかによって異なる。流れ図７００の各ステップは異なる順序で実行されてもよい。加えて、流れ図７００の１又は複数のステップを省いてもよい。例えば、ステップ７１８、７２６又は７０６を省いてもよい。３列の枝７４０、７５０及び７６０は、分散型撮像のための全ての可能な工程フローを網羅している訳ではない。その代わりに、これらの枝は、工程フローを異なるシナリオで如何に割り当て得るかの概念を例示するに過ぎない。ステップ７０４、７１２及び７２４で行なわれる処理をクライアント及びサーバの両方で分担する等の付加的な変形も可能である。
【００３７】
クライアントとサーバとの間で分散処理を如何に割り当てるかを決定するために、幾つかの形式の割当て工程が望ましい場合がある。図４は、本出願の一実施形態による分散画像処理のために資源の割当てを推奨する方法４００の流れ図を示す。ステップ４０２で開始して、分散型網での通信が行なわれる。例えば、クライアント３１２がサーバ３０２に対し、画像をクライアント３１２側で表示させたいと通信することができる。通信は、監視データ、画像処理割当て及び構成制御指令を含め多様な情報を含み得る。
【００３８】
ステップ４０４では、モニタが、帯域幅及びシステム資源を監視する。ステップ４０４は、１又は複数のモニタによって実行され得る。例えば、ステップ４０４は、サーバ側モニタ３１０及びクライアント側モニタ３１４によって実行され得る（図３に両方を示す）。モニタ（１又は複数）は、帯域幅及びシステム資源に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、分散型網３００の特性すなわち通信経路３０５の帯域幅、サーバ３０２ＣＰＵの負荷（図２に示すサーバ２０２と同様のもの）及びクライアント３１２の処理速度を追跡することができる。モニタ（１又は複数）は、様々なシステム資源及び帯域幅に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、サーバ３０２ＣＰＵの負荷、クライアント３１２の処理速度、クライアント３１２の処理能力、及び通信経路３０５の帯域幅に対応する監視データを供給することができる。
【００３９】
ステップ４０６では、クライアントに画像を表示させる要求を出す。例えば、クライアント３１２は、画像処理ソフトウェアを実行することができる。利用者は、このソフトウェアと相互作用して、医用画像に対して画像処理タスクを実行することができる。ソフトウェアは画像処理要求を開始することができ、要求はクライアント３１２のオペレーティング・システムに中継される。画像処理要求は、画質のような処理対象画像についての情報を含み得る。画像処理要求はまた、例えば画像をズームする又はパンする等のような画像処理要求の性質についての情報を含んでいてよい。画像処理要求は、クライアント３１２からサーバ３０２へ通信され得る。
【００４０】
ステップ４０８では、システム資源の割当てが監視データに基づいて推奨される。ここで一時図５を参照して述べると、同図には本出願の一実施形態による割当ての幾つかの例の表５００が示されている。各例は例示するものであって網羅するものではない。例１では、サーバ３０２は相対的に負荷を加えられておらず、すなわちサーバＣＰＵが他の処理待ちタスクによって過度に負荷を掛けられている状態ではないことを意味する。さらに、クライアント３１２処理速度は相対的に遅く、通信経路の帯域幅は相対的に高い。尚、相対的に高い所定の帯域幅とは、サーバ３０２に記憶されている三次元画像データが実質的な遅延を伴わないでクライアント３１２に通信され得ることを示すものと理解されたい。遅延は、例えば代替的な画像処理フローの方がクライアント３１２での画像表示が高速である場合には実質的であると言える。換言すると、実質的な遅延は、非効率的な画像処理フローを選択したときに生じ得る。例１のシナリオでは、全ての処理タスクをサーバ３０２で主に実行するように推奨する。例１での推奨は、図７の第一の枝７４０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４１】
例２では、サーバ３０２は相対的に負荷を加えられておらず、すなわちサーバＣＰＵが他の処理待ちタスクによって過度に負荷を掛けられている状態ではないことを意味する。さらに、クライアント３１２の処理速度は相対的に遅く、通信経路の帯域幅は相対的に低い。このシナリオでは、パン及びズームのような幾つかの単純な処理タスクはクライアント３１２によって実行され、高度なタスクはサーバ３０２に残しておくことができる。このシナリオでは、全ての処理タスクをサーバ３０２で主に実行するように推奨する。例２の推奨は、図７の第二の枝７５０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４２】
例３では、サーバ３０２は相対的に負荷を加えられており、すなわちサーバＣＰＵが、画像処理を実行するサーバの能力に干渉し得る処理待ちタスクを有していることを意味する。さらに、クライアント処理速度は相対的に速く、通信経路の帯域幅は相対的に高い。このシナリオでは、全ての処理タスクをクライアント３１２で実行するように推奨する。例３の推奨は、図７の第三の枝７６０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４３】
図４に戻ると、選択随意のステップ４１６では、監視データに基づいて画質もまた推奨する。例えば、クライアント処理速度が相対的に遅い場合には、相対的に低い画質を推奨して画像処理速度を高めることができる。
【００４４】
ステップ４１０では、システム資源の推奨された割当てを受け入れることができる。割当ては、例えばサーバ３０２及び／又はクライアント３１２によって受け入れられ得る。割当ては、自動的に受け入れられてもよいし、手動で受け入れられてもよい。加えて、割当ては、一組の規則に基づいて条件付きで受け入れられてもよい。構成制御３１８が、推奨の条件付き受け入れの規則を供給することができる。
【００４５】
選択随意のステップ４１８では、推奨された画質を受け入れる。ここでも、推奨は、自動的に受け入れられてもよいし、手動で受け入れられてもよいし、条件付きで受け入れられてもよい。
【００４６】
ステップ４１２では、割り当てられたシステム資源で画像データを処理する。例えば、幾つかのクライアント資源３１６及び幾つかのサーバ資源３０８が効率的な画像処理のためにステップ４０８で割り当てられていてよい。次いで、割り当てられたサーバ資源３０８は画像処理の一部を実行し、割り当てられたクライアント資源３１６は画像処理の残部を実行することができる。画像処理は、ＭＰＲ、ＭＩＰ、ＶＲのような処理集約的手法、及び／又は付加的な３Ｄ−２Ｄ変換処理手法を含み得る。画像処理はまた、回転、パン、ズーム、コントラスト調節、輝度調節及び／又は濃淡調節等のような手法を含み得る。
【００４７】
ステップ４１４では、対応する画像がクライアント３１２に表示される。ステップ４１２で割り当てられたシステム資源によって画像が処理された後に、得られた画像をクライアント３１２に表示することができる。画像をクライアント３１２に表示する処理はまた、さらに一般的には画像処理の一部と看做すこともできる。
【００４８】
方法４００の各ステップは任意の順序で実行されてよい。加えて、方法４００の１又は複数のステップを省いてもよい。例えば、ステップ４０４をステップ４０６の後に実行してもよいし、ステップ４１０、４１２及び４１４を省いてもよい。
【００４９】
説明のための例として、本出願の実施形態を次の態様で用いることができる。分散型網３００において、クライアント３１２が表示器２１４に医用画像を表示する。画像データは、クライアント３１２にローカルに記憶されていてもよいしサーバ３０２に記憶されていてもよい。クライアント３１２は、表示画像を利用者が編集し又は変更することを可能にするアプリケーションを提供する。利用者は、ユーザ・インタフェイス２１６を介してクライアント３１２と相互作用する。利用者は、注釈記入、コントラスト調節、輝度調節、濃淡調節、パン、ズーム、回転、３Ｄ処理を含めて、表示画像を画像処理アプリケーションによって編集し又は変更する多様な画像処理タスクから選択を行なうことができる。この説明のための例では、利用者は、ユーザ・インタフェイス２１６に相応に指令することにより「コントラスト調節」を選択する。この間に、クライアント側モニタ３１４及びサーバ側モニタ３１０の両方が、システム資源及び帯域幅を追跡している。サーバ側モニタ３１０がサーバＣＰＵ２０２の負荷を追跡すると、最新の指標は例えばサーバＣＰＵ２０２が９５％を上回る空き状態にある等のようにサーバＣＰＵが相対的に負荷を加えられていないことを示す。クライアント側モニタ３１４は、起動時にクライアント３１２が相対的に低いプロセッサ速度及びクロック速度を有していることを決定している。また、クライアント側モニタ３１４が通信経路３０５の帯域幅を追跡すると、最新の指標は帯域幅が相対的に低いことを示す。サーバ側モニタ３１０は、サーバＣＰＵ負荷情報を監視データとして推奨供給器３０６へ供給する。クライアント側モニタ３１４は、クライアント処理速度及び帯域幅情報を監視データとして推奨供給器３０６へ供給する。推奨供給器３０６は、効率的な画像処理モードは、画像のコントラストを調節するためにはクライアント資源３１６を割り当てるのみでよいと決定する。推奨供給器３０６はまた、クライアント３１２は、この画像処理タスクを低品質画像に対してしか十分な速度で実行し得ないものと決定する。推奨供給器３０６は、このタスクにクライアント資源３１６を割り当てて、画像は低画質とすべきであるとの推奨を供給する。クライアント３１２はこれらの推奨を自動的に受け入れて、利用者の指令に従ってコントラストを調節することにより画像の処理に着手する。
【００５０】
説明のための例を続けると、利用者は次に、相対的に複雑な画像処理タスクを実行しようとする。利用者は、異なる角度の画像を観察しようとする。この形式の画像処理は、相対的に集約的なＭＰＲ手法を必要とする。加えて、利用者は、新たな角度の画像を観察しているときにも以前に適用したコントラスト調節を保存しておこうとする。クライアント側モニタ３１４及びサーバ側モニタ３１０の両方とも、システム資源及び帯域幅に著しい変化を認めない。サーバ側モニタ３１０は、サーバＣＰＵ負荷情報を監視データとして推奨供給器３０６へ供給する。クライアント側モニタ３１４は、クライアント処理速度及び帯域幅を情報監視データとして推奨供給器３０６へ供給する。この場合には、推奨供給器３０６は、効率的な画像処理モードは、画像を処理するためにサーバ資源３０８の一部及びクライアント資源３１６の一部を割り当てるものと決定する。サーバ資源３０８は最も効率的にＭＰＲ処理を実行することができる一方で、クライアント資源３１６は最も効率的に後続のコントラスト調節処理を実行することができる。推奨供給器３０６はまた、システム資源は、この処理タスクを低品質画像に対してしか十分な速度で実行し得ないものと決定する。推奨供給器３０６は、幾つかのサーバ資源３０８及び幾つかのクライアント資源３１６をこのタスクのために割り当てて、画像は低画質とすべきであるとの推奨を供給する。クライアント３１２及びサーバ３０２はこれらの推奨を自動的に受け入れて、利用者の指令に従って画像の処理に着手する。
【００５１】
図６は、本出願の一実施形態による分散画像処理システムにおいてシステム資源を割り当てるために構成制御との相互作用（対話）を提供する方法６００の流れ図を示す。ステップ６０２では、利用者が、システム資源の割当て及び／又は画質に関連する指令を構成制御３１８に与える。もう一つの選択肢として、指令はシステム管理者によって与えられてもよい。また、指令は、例えば自動タイマ又はカレンダのスケジュールを介して自動的に与えられてもよい。
【００５２】
ステップ６０４では、分散型網での通信を行なう。例えば、クライアント３１２がサーバ３０２に対し、画像をクライアント３１２に表示させたいと通信することができる。通信は、監視データ、画像処理割当て及び構成制御指令を含め多様な情報を含み得る。
【００５３】
ステップ６０６では、帯域幅及びシステム資源を監視して監視データを形成する。ステップ６０６は、１又は複数のモニタによって実行され得る。例えば、ステップ６０６は、サーバ側モニタ３１０及びクライアント側モニタ３１４（両方とも図３に示されている）によって実行され得る。モニタ（１又は複数）は、帯域幅及びシステム資源に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、分散型網３００の特性すなわち通信経路３０５の帯域幅、サーバ３０２ＣＰＵの負荷（図２に示すサーバＣＰＵ２０２と同様のもの）及びクライアント３１２の処理速度を追跡することができる。モニタ（１又は複数）は、様々なシステム資源及び帯域幅に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、サーバ３０２ＣＰＵの負荷、クライアント３１２の処理速度、クライアント３１２の処理能力、及び通信経路３０５の帯域幅に対応する監視データを供給することができる。
【００５４】
ステップ６０８では、クライアントで画像を表示させる要求を出す。例えば、クライアント３１２は画像処理ソフトウェアを実行していてよい。利用者は、このソフトウェアと相互作用して、医用画像に対して画像処理タスクを実行することができる。ソフトウェアは画像処理要求を開始することができ、要求はクライアント３１２のオペレーティング・システムに中継される。画像処理要求は、画質のような処理対象画像についての情報を含み得る。画像処理要求はまた、例えば画像をズームする又はパンする等のような画像処理要求の性質についての情報を含んでいてよい。画像処理要求は、クライアント３１２からサーバ３０２へ通信され得る。
【００５５】
ステップ６１０では、システム資源の割当てが、監視データ及び／又は構成制御３１０に基づいて推奨される。システム設計及び構成制御３１０の選択に基づいて、多様な選択肢を可能にすることができる。例えば、推奨される割当ては、構成制御３１０に専ら基づいていてもよいし、監視データに専ら基づいていてもよい。推奨される割当ては、監視データ及び構成制御３１０の混成に基づいていてもよい。例えば、構成制御３１０は、特定の資源割当てについての最小限度又は最大限度を供給することができる。構成制御３１０は、サーバＣＰＵ２０２の負荷が５０％が超えてはならないと指示することができる。従って、この例では、サーバＣＰＵ２０２の任意の推奨される割当ては、サーバＣＰＵ２０２の負荷が５０％を下回った状態にある場合には監視データに基づくべきであるが、構成制御３１０によって決定された５０％のサーバＣＰＵ２０２の負荷を上限とすべきである。構成制御３１０の様々な設定又はパラメータが、監視データ及び構成制御３１０が推奨される割当てにどの程度影響を及ぼすべきかを指示することができる。
【００５６】
選択随意のステップ６１８では、監視データ及び／又は構成制御３１０に基づいて画質が推奨される。システム設計及び及び構成制御３１０の選択に基づいて、多様な選択肢を可能にすることができる。例えば、推奨される画質は、構成制御３１０に専ら基づいていてもよいし、監視データに専ら基づいていてもよい。推奨される画質は、監視データ及び構成制御３１０の混成に基づいていてもよい。例えば、構成制御３１０は、画質についての最小限度又は最大限度を供給することができる。構成制御３１０は、画質が一定の分解能を下回らないものと指示することができる。従って、この例では、任意の推奨される画質は、推奨が最低画質分解能を上回っている場合には監視データに基づくべきであるが、構成制御３１０によって決定された推奨される画質分解能を上限とすべきである。構成制御３１０の様々な設定が、監視データ及び構成制御３１０が推奨される画質にどの程度影響を及ぼすべきかを指示することができる。
【００５７】
ステップ６１２では、推奨されたシステム資源の割当てを受け入れることができる。割当ては、例えばサーバ３０２及び／又はクライアント３１２によって受け入れられ得る。割当ては、自動的に受け入れられてもよいし、手動で受け入れられてもよい。加えて、割当ては、一組の規則に基づいて条件付きで受け入れられてもよい。構成制御３１８が、推奨の条件付き受け入れの規則を供給することができる。
【００５８】
選択随意のステップ６２０では、推奨される画質が受け入れられる。ここでも、推奨は、自動的に受け入れられてもよいし、手動で受け入れられてもよい。
【００５９】
ステップ６１４では、割り当てられたシステム資源で画像データを処理する。例えば、幾つかのクライアント資源３１６及び幾つかのサーバ資源３０８が効率的な画像処理のためにステップ６１０で割り当てられていてよい。次いで、割り当てられたサーバ資源３０８は画像処理の一部を実行し、割り当てられたクライアント資源３１６は画像処理の残部を実行することができる。画像処理は、ＭＰＲ、ＭＩＰ、ＶＲのような処理集約的手法、及び／又は付加的な３Ｄ−２Ｄ変換処理手法を含み得る。画像処理はまた、パン、ズーム、コントラスト調節、輝度調節及び／又は濃淡調節等のような手法を含み得る。
【００６０】
ステップ６１６では、対応する画像がクライアント１０４に表示される。ステップ６１４で割り当てられたシステム資源によって画像が処理された後に、得られた画像をクライアント３１２に表示することができる。画像をクライアント３１２に表示する処理はまた、さらに一般的には画像処理の一部と看做すこともできる。
【００６１】
方法６００の各ステップは任意の順序で実行されてよい。加えて、方法６００の１又は複数のステップを省いてもよい。例えば、ステップ６０４をステップ６０６の後に実行してもよいし、ステップ６１０、６１２及び６１４を省いてもよい。
【００６２】
構成制御３１０の相互作用の説明のための例として、利用者は、ユーザ・インタフェイス２１６を介してクライアント１０４と相互作用する。利用者は、「オプション」メニューを有する画像処理ソフトウェアを動作させる。利用者は「オプション」メニューを開いて、構成制御３１０設定の幾つかにアクセスする。尚、利用者がアクセス可能な構成制御３１０設定もあれば、アクセス不能なものもあることを特記しておく。この説明のための例では、構成制御３１０設定は、最小分解能設定と、最小値設定が絶対的な最小値設定であるのか、又は単に示唆的な最小値設定であるのかを表わすチェック・ボックスとを含み得る。利用者は２００ドット毎インチ（「ＤＰＩ」）の最小分解能を選択して、この値が示唆的な最小値設定であって絶対的な最小値設定ではないことを示すようにチェック・ボックスを選択することができる。次いで、利用者は、画像処理を実行するようにソフトウェアに指令する。推奨供給器３１４は、サーバ側モニタ３０４及びクライアント側モニタ３１４によって収集された監視データを検討する。推奨供給器３１４はまた、構成制御３１０の設定を検討する。推奨供給器３１４は様々な要因を均衡させて、画像を処理する効率的な方法は、画像が１５０ＤＰＩの分解能を有するようにすることであると決定する。推奨供給器３１４は、資源の割当て及び１５０ＤＰＩの分解能を推奨する。推奨は、クライアント３１２及びサーバ３０２によって受け入れられる。画像データは処理されて、画像は１５０ＤＰＩの分解能でクライアント３１２の表示器２１４に表示される。
【００６３】
説明のための例を続けると、利用者は１５０ＤＰＩの画像を観察して、分解能を高めるべきであると判断する。そして、利用者は「オプション」メニューを開き、構成制御３１０にアクセスする。利用者は最小分解能を１７５ＤＰＩに設定する。利用者は、１７５ＤＰＩ設定は絶対的設定であることを示すチェック・ボックスを選択する。次いで、利用者は、画像処理を実行するようにソフトウェアに指令する。推奨供給器３１４は、サーバ側モニタ３０４及びクライアント側モニタ３１４によって収集された監視データを検討する。推奨供給器３１４はまた、構成制御３１０の設定を検討する。推奨供給器３１４は様々な影響のある要因を均衡させて、１７５ＤＰＩの分解能を有する画像を処理する最も効率的な方法を判定する。推奨供給器３１４は、資源の割当て及び１７５ＤＰＩの分解能を推奨する。推奨は、クライアント３１２及びサーバ１０２によって受け入れられる。画像データは処理されて、１７５ＤＰＩの分解能でクライアント１０４の表示器２１４に表示される。利用者は画像を検討して、画質に満足する。
【００６４】
図８は、本発明の一実施形態によるクライアントに表示される検査に対する繰り返し式の利用者相互作用を示す方法８００の流れ図である。ステップ８０２では、クライアント（図３に示すクライアント３１２と同様のもの）側に位置する利用者が、検査に対応する画像を表示することが可能であり得るアプリケーションを呼び出す。検査は、患者の放射線検査に対応する一組又は複数組の容積画像データ又は二次元画像データであってよい。例えば、検査は、３Ｄシネ画像データ、２Ｄシネ画像データ、３Ｄ静止データ及び／又は２Ｄ静止データ等を含み得る。アプリケーションは、検査全体を表示し得るものであってもよいし、検査の一部を表示し得るものであってもよい。アプリケーションは、利用者が、ユーザ・インタフェイスを介して検査の表示された部分又は検査全体と相互作用することを可能にすることができる。例えば、アプリケーションは、利用者が以下の相互作用を実行することを可能にすることができる。すなわち画像を前後にページめくりする、画像をパンする、画像をズーム・イン及び／又はズーム・アウトする、画像を回転させる、コントラストを調節する、輝度を調節する、色パラメータを調節する、濃淡パラメータを調節する、スライス厚を調節する、最大強度投影、平均強度投影及び最小強度投影の間を切り換える、ボリューム・レンダリング・モードに切り換える、視角を調節する等である。利用者が検査と相互作用するためのアプリケーションを呼び出すときに、画像処理を実行する且つ／又は支援することのできる対応するサーバ側アプリケーションを開始させると望ましい場合がある。そして、例えばクライアント側アプリケーションの呼び出しによって、メッセージをサーバへ送ることができる。メッセージは、画像処理アプリケーションがサーバでまだ実行されていない場合には、サーバに対しかかる画像処理アプリケーションを起動するように指令する又は要求することができる。例えば、サーバ側アプリケーションは、ＭＩＰ、ＭＰＲ及び／又はＶＲ等のような３Ｄ処理を実行することが可能なものであってよい。
【００６５】
ステップ８０４では、利用者は観察のための検査を選択する。例えば、利用者は放射線技師であってよく、臨床目的で検査を選択することができる。検査は、検査一覧から選択されてもよいし、過去の検査又は最近取得された検査に対応していてもよい。
【００６６】
ステップ８０６では、監視されたシステム・データ、構成制御設定、画像処理要求及び／又は利用者指令に基づいて、処理の割当てを選択する。例えば、図４に示す方法４００及び／又は図６に示す方法６００に従って割当てを選択することができる。
【００６７】
ステップ８０８では、選択された処理の割当てに従って、検査に対応する１又は複数の医用画像を処理する。画像を、例えば図７に示す方法７００に従って処理することができる。例えば、一つの検査に対応する多数の画像を処理することができる。各々の画像は、例えばアキシャル像、サジタル像、コロナル像及び斜方像のような異なる像に対応していてよい。
【００６８】
ステップ８１０では、１又は複数の医用画像をクライアントによって表示する。画像は、フラット・パネル・モニタ又は陰極線管のような表示器に表示され得る。表示される画像は実質的に２Ｄであってよいが、利用者にとっては３Ｄとして現われ得る。多数の画像は同時に表示されてもよいし、容易にアクセス可能であってもよい。例えば、一つの検査の多数の像に対応する多数の画像を同時に観察することができる。もう一つの例として、各々の画像表示がクライアントにおいてローカルにメモリに記憶されていてもよく、利用者が、画像データを再処理することに関連した遅延を招かずに多数の像の間を迅速に切り換えることもできる。
【００６９】
ステップ８１２では、利用者は表示画像（１又は複数）と相互作用して、選択された検査の異なる像を得る。例えば、利用者はアプリケーション及び／又は画像と相互作用して、以下の相互作用を実行することができる。すなわち画像を前後にページめくりする、画像をパンする、画像をズーム・イン及び／又はズーム・アウトする、画像を回転させる、コントラストを調節する、輝度を調節する、色パラメータを調節する、濃淡パラメータを調節する、スライス厚を調節する、最大強度投影、平均強度投影及び最小強度投影の間を切り換える、ボリューム・レンダリング・モードに切り換える、視角を調節する等である。利用者は、マウス、キーボード又は他のユーザ・インタフェイス装置と相互作用することができる。例えば、利用者は、タッチ・スクリーンの指触パッド及び／又はジョイスティック等と相互作用することができる。利用者は、メニュー、制御パネル及び／又はグラフィック・ユーザ・インタフェイス（ＧＵＩ）要素等を介してアプリケーション・プログラムと相互作用することができる。利用者はまた、例えば表示特性を調節することによりオペレーティング・システムを介して表示画像と相互作用することができる。利用者の表示画像との相互作用によって、画像処理要求が生じ得る。
【００７０】
利用者が表示画像と相互作用するときに、利用者の相互作用を反映させてクライアントに異なる画像を表示する必要がある場合がある。例えば、利用者が画像上でズーム・インを選択する場合に、ズーム（拡大）された画像の部分を、利用者の相互作用を反映させて表示させることができる。この相互作用を達成するために、方法８００のフローは１又は複数の前段のステップへ戻ることができる。例えば、相互作用を達成するために、方法８００はステップ８０６へ戻ることができる。ステップ８０６では、新たな割当てを選択することができる。システム資源モニタが、システム資源が実質的に変更されたと決定して、新たな資源割当てを推奨することが可能である場合もある。例えば、初期割当ては図７の枝７５０に対応し得る。この割当ては、図５の例２に示すように通信経路の帯域幅が相対的に低かったため選択されたものであり得る。しかしながら、続いての相互作用時に、網条件が改善して、通信経路の帯域幅が相対的に高くなっていたという場合もある。従って、図５の例１に従って、さらに効率的な割当ては図７の枝７４０に対応し得る。換言すると、改善された網条件のため、サーバにさらに多くの画像処理タスクを行なわせる方が効率的となる場合がある。
【００７１】
しかしながら、各回毎の相互作用時にシステム資源を割当てし直すのが望ましくない場合もある。従って、相互作用フローはステップ８１２からステップ８０８へ進んでもよい。ステップ８０８では、事前の処理の割当てに従って画像を処理する。例えば、画像処理タスクがサーバに割り当てられている場合には、画像処理要求はサーバへ直接向かってよい。もう一つの例として、画像処理タスクがクライアントに割り当てられている場合には、画像処理要求は、クライアントにおいてローカルに処理されてよい。
【００７２】
工程フローは、画像処理要求の性質に基づいて異なるステップに戻ってよい。例えば、画像処理要求が処理資源の集約的な利用を必要とし得る場合には、資源割当てを再度決定すると望ましい場合がある。もう一つの例として、画像処理要求が資源の集約的な利用を必要としないであろう場合には、既存の資源割当てを持続した方が望ましい場合がある。
【００７３】
方法８００の各ステップは異なる順序で実行されてもよい。加えて、方法８００の１又は複数のステップを省いてもよい。例えば、ステップ８０２又は８０４を省いてもよい。もう一つの例として、ステップ８０６をステップ８０２又は８０４の前に実行してもよい。
【００７４】
以下の説明のための例では、方法８００に従って利用者の画像との相互作用が如何に達成され得るかを説明する。ステップ８０２では、クライアント側に位置する利用者が、放射線検査を観察するように設計されているソフトウェア・アプリケーションを開く。このソフトウェア・アプリケーションはまた、利用者が検査の画像と相互作用することを可能にする。次いで、利用者はステップ８０４において、観察したい検査を選択する。検査はこの例では、胎児の超音波から得られたものとする。次に、ステップ８０６では、処理の割当てが選択される。この場合には、監視データは、サーバには負荷が加えられておらず、帯域幅は高く、クライアントは低速であることを示している。図５の例１に従って、例えば図７の枝７４０に示すように、画像処理の殆どをサーバで実行するように割り当てる。次に、ステップ８０８では、サーバに最初に記憶されていた画像データをサーバによって処理して、クライアントへ送信する。処理された画像データは胎児の２Ｄ画像であり、３Ｄとして現われる。ステップ８１０では、２Ｄ画像がクライアントに表示される。次に、ステップ８１２では、利用者は胎児の画像を観察する。しかしながら、利用者は、異なる角度の胎児を観察することを望む。従って、利用者は、ソフトウェア・アプリケーションの制御パネルを開いて、新たな視角を入力する。ソフトウェアはこの相互作用を解釈して、画像処理要求を生成する。新たな視角での画像は、画像データをＭＰＲ手法で再処理することを必要とし得る。ソフトウェア・アプリケーションは、この形式の相互作用が実質的な処理資源を要求し得ることを認識する。結果的に、工程フローはステップ８０６に戻る。ステップ８０６では、網条件が悪化しており、帯域幅が今は相対的に低くなっているものと決定される。従って、図５の例２に従って、３Ｄ画像処理の殆どをサーバで実行するように割り当てて、比較的単純なタスクはクライアントによって実行されるように割り当てる。この形式の割当てを、例えば図７の枝７５０に示す。次いで、ステップ８０８では、画像処理要求に従って画像データを処理する。次いで、ステップ８１０で画像をクライアントに表示する。
【００７５】
次に、利用者は、ステップ８１２で新たな角度の像のコントラストを変化させることを決定する。従って、利用者は、ソフトウェア・アプリケーションの制御パネルを開いて、新たなコントラスト量を入力する。ソフトウェアはこの相互作用を解釈して、画像処理要求を生成する。ソフトウェア・アプリケーションはまた、この形式の相互作用が実質的な処理資源を要求し得ることを認識する。結果的に、工程フローはステップ８０８に戻る。画像データは、画像処理要求及び事前割当てに従って処理される。資源の事前割当ては、この形式の画像処理を実行するためにはクライアントを割り当てているため、画像処理要求はローカルに直接クライアントに送られる。次いで、ステップ８１０において画像をクライアントに表示させる。ステップ８１２では、利用者が画像と相互作用し続ける間は繰り返し式工程は続行する。
【００７６】
このように、本出願の実施形態は、分散型網で画像データを効率的に処理する方法及びシステムを提供する。加えて、本出願の実施形態は、分散型網の全体で画像処理タスクを効率的に割り当てる方法及びシステムを提供する。さらに、本出願の実施形態は、分散型イメージング・システムの利用者に対し、柔軟性及び制御を提供する。
【００７７】
幾つかの実施形態を参照して本発明を説明したが、当業者には、本発明の範囲から逸脱せずに様々な変形を施し、また均等構成を置換し得ることが理解されよう。加えて、本発明の範囲から逸脱せずに、本発明の教示に合わせて特定の状況又は材料を適応構成する多くの改変を施すことができる。例えば、各特徴は、ソフトウェア、ハードウェア又はこれらの混成で具現化され得る。従って、本発明は開示された特定の実施形態に限定されず、特許請求の範囲に含まれる全ての実施形態を包含するものとする。また、図面の符号に対応する特許請求の範囲中の符号は、単に本願発明の理解をより容易にするために用いられているものであり、本願発明の範囲を狭める意図で用いられたものではない。そして、本願の特許請求の範囲に記載した事項は、明細書に組み込まれ、明細書の記載事項の一部となる。
【図面の簡単な説明】
【００７８】
【図１】本出願の一実施形態による分散型網を示す図である。
【図２】本出願の一実施形態による分散型イメージング・システムのブロック図である。
【図３】本出願の一実施形態による分散型イメージング・システムのブロック図である。
【図４】本出願の一実施形態による分散画像処理のためのシステム資源の割当てを推奨する方法の流れ図である。
【図５】本出願の一実施形態による割当ての幾つかの例の表を示す図である。
【図６】本出願の一実施形態による分散画像処理システムにおいてシステム資源を割り当てるために構成制御との相互作用（対話）を提供する方法の流れ図である。
【図７】本発明の一実施形態による分散型撮像表示の方法の流れ図である。
【図８】本発明の一実施形態によるクライアントに表示される検査に対する繰り返し式の利用者相互作用を示す方法８００の流れ図である。
【符号の説明】
【００７９】
１００、３００ 医用画像処理のためのシステム
１０２、３０２ サーバ
１０４、３１２ クライアント
１０６、３０５ 通信経路
３０６ 推奨供給器
３０８、３１６ システム資源
３１０ サーバ側モニタ
３１４ クライアント側モニタ
３１８ 構成制御
４００ 分散型網での医用画像処理の方法
【技術分野】
【０００１】
本出願の実施形態は一般的には、分散処理に関する。具体的には、幾つかの実施形態は、クライアントに画像を表示するためにクライアントとサーバとの間で医用画像データ処理を割り当てることに関する。
【背景技術】
【０００２】
現代のコンピュータの急増に伴って、コンピュータ網（ネットワーク）も急増している。コンピュータ網には、構内網（ＬＡＮ）、広域網（ＷＡＮ）、有線網、無線網及び光網等、又はこれらの任意の組み合わせがある。ネットワークは、ネットワーク上の個々のコンピュータの間の通信を可能にする。
【０００３】
データを共有することに加え、コンピュータ網はまた、コンピュータ資源の共有を容易にする。資源を共有したネットワークでは、個々のコンピュータが利用可能な全資源量が増強される。資源を共有したネットワークを分散型網とも呼ぶことができる。というのは、ネットワークで利用可能な全資源がネットワークの全体に分散しているからである。
【０００４】
分散型網との用語は広い意味であり、広範なネットワーク・モデルを包含している。例えば、分散型網はサーバ中心型網であってもよいし、クライアント中心型網であってもよい。サーバ中心型網は、何らかの重要資源がサーバによって供給されるように設計され得る。このことは、例えば相対的に安価なクライアント又は処理能力をあまり有しないクライアントが求められる場合に有利であり得る。対照的に、クライアント中心型網は、何らかの重要資源の供給についてクライアントの方により多く頼る場合がある。
【０００５】
ネットワークに影響を及ぼし得る要因の一つに、帯域幅がある。比較的低い帯域幅の分散型網では、網通信量を低減する設計を選択すると望ましい場合がある。例えば、低帯域幅ネットワークでは、サーバ中心型網を提供すると望ましい場合がある。対照的に、相対的に高い帯域幅の分散型網は、アーキテクチャの柔軟性を高めることができる。
【０００６】
合成モデル撮像のための分散型網は公知である。例えば、米国特許第６，３７７，２５７号「METHODS AND APPARATUS FOR DELIVERING 3D GRAPHICS IN A NETWORKED ENVIRONMENT」（以下「Borrel特許」と呼ぶ。特許文献１）は、クライアント及びサーバの両方で合成モデルをレンダリングする方法を議論している。Borrel特許の示すところによれば、従来技術の諸方式は、合成モデルをその構成部分（例えば前景物体及び背景）に分解して、サーバに構成部分の幾つかをレンダリングさせ、クライアントに残りの構成部分をレンダリングさせることにより動作するとして公知である。
【０００７】
加えて、合成モデリング・システムは、クライアントからのフィードバックに基づいて分散型撮像手法を適応構成するとして公知である。Borrel特許は、クライアントからフィードバックを供給する方式について議論している。かかるフィードバックは、誤差補正、利用者定義によるフィードバック及び画質から成る。サーバは、フィードバックを処理し、次いで、効率的な解に到達するために分散型工程に調節を加えるように試みなければならない。
【０００８】
しかしながら、合成モデリングに適用可能な解は、医療撮像には実用的でないことが判明する場合がある。モデリングとは異なり、医用画像は有機的でありすなわち一元的である傾向がある。換言すると、医用画像は、構成部分に容易に分解し得ない場合がある。例えば、人体の脊椎の合成モデルは、該モデルを生成して、各々の椎骨、各々の椎間板、各々の椎骨の表面テクスチャ生成、及び各々の椎間板の表面テクスチャ生成等を含めて多様な構成部分に基づいて記憶することができる。対照的に、人体の脊椎の医用画像（例えばＸ線によって撮影したもの）はかかる成分的構成要素を含んでいない場合がある。その代わりに、人体の脊椎の医用画像は、成分的構成要素には容易に分解しない一元的な画像であり得る。このように、分解という解が医用画像の分散型撮像に実用的でない場合がある。
【０００９】
加えて、フィードバック依存型の適応型手法では、処理タスクの開始時に分散型資源の効率的な割当てに失敗する場合がある。換言すると、フィードバック依存型のシステムは最終的には、効率的な解に引き付けられ得るが、タスクの開始時に資源を効率的に割り当てない場合がある。さらに、フィードバックは資源の効率的な割当てを決定する大まかな尺度であり得る。例えば、公知の形式のフィードバックは、タイム・スタンプを用いてクライアントがどの程度高速にタスク又はその一部を実行するかを測定する。かかるフィードバック情報は、ネットワーク帯域幅、クライアントの中央処理ユニット（「ＣＰＵ」）の速度及び負荷、クライアントのランダム・アクセス・メモリの空き容量、クライアントのビデオ・メモリの空き容量、並びにサーバのＣＰＵ速度及び負荷等を含めた広範な要因に基づいて変化し得る。このように、いずれの特定のファクタがフィードバック情報に影響を与え得るかを効率的に決定するのが不可能な場合がある。
【００１０】
医用画像を表示するためには、医用イメージング・システムの利用を介して取得された医用画像データを処理することができる。計算機式断層写真法（ＣＴ）走査システムのような医用イメージング・システムは、画像データをスライスとして得ることができる。スライスは二次元（２Ｄ）スライスであってよい。１枚のスライスは第三の次元については比較的小さい厚みを有し得るが、スライスを２Ｄとして参照する方が概念的には好都合であろう。関心のある３Ｄ空間の様々な断面に対応する多数の２Ｄスライスを得ることができる。複数の２Ｄ画像データ・スライスを処理して３Ｄ画像データ空間とすることができる。１又は複数の相対的に大きいデータ・ファイルが、３Ｄ医用画像データ空間を記憶し且つ／又は処理することができる。
【００１１】
医師は、さらなる処理を行なわなければ３Ｄ医用画像データ空間を観察することができない場合がある。フラット・パネル液晶ダイオード表示器又は陰極線管表示器のような表示器は、２Ｄ画像を表示することができるに留まる場合がある。但し、２Ｄ画像は観察者にとって３Ｄとして見えるようにすることができる。このように、表示器に医用画像を表示するために、３Ｄデータを処理して２Ｄデータを形成することができる。
【００１２】
３Ｄ画像データを処理して２Ｄ画像データとする多様な手法が公知である。これらの手法には、多断面再構成（ＭＰＲ）、最大（又は最小）強度投影（ＭＩＰ）及びボリューム・レンダリング（ＶＲ）等がある。ＭＰＲ処理では、３Ｄ空間を処理して２Ｄスライスを得ることができ、この２Ｄスライスを医用イメージング・システムによって得られたスライスとは異なるものにすることができる。例えば、ＭＰＲ機能を組み入れたアプリケーションは、利用者が空間内の任意の位置を中心として表示画像を任意の角度で回転させることを可能にすることができる。このように、ＭＰＲは、医師が多様な位置及び角度の任意のものから解剖学的構造を観察することを可能にする。
【００１３】
ＭＩＰ処理では、３Ｄ空間を処理して、観察者が３Ｄであるものと認知し得る２Ｄスライスを得ることができる。ＭＩＰ処理は、複数の２Ｄスライスの積層の結合である２Ｄ画像を作成することができる。各々の２Ｄスライスのピクセルを結合して２Ｄ画像を形成する幾つかの方法が存在する。例えば、最終的な２Ｄ画像の各々のピクセルを、２Ｄスライスの積層の対応するピクセルの中で最も明るいピクセル又は最も暗いピクセルとすることができる。もう一つの例では、最終的な２Ｄ画像の各々のピクセルを、２Ｄスライスの積層の対応するピクセルの平均としてもよい。
【００１４】
ＶＲ処理は、３Ｄ空間を２Ｄで表示するもう一つの方法である。ＶＲ処理は、対象の表面及び／又は内部をレンダリングして、対象の表面が中実、透明及び／又は半透明に見えるようにする。関心のある空間（器官、血管及び骨等）の内部の対象も、中実、透明及び／又は半透明に見えるようにすることができる。
【特許文献１】米国特許第６，３７７，２５７号
【発明の開示】
【発明が解決しようとする課題】
【００１５】
３ＤデータをＭＰＲ、ＭＩＰ及びＶＲのような２Ｄ表示可能な画像へ変換する手法は、医師にとって有用であろう。加えて、かかる手法はまた、データの容量を大幅に減少させることができる。２Ｄ表示可能な画像は、３Ｄデータ空間の容量の小部分となり得る。しかしながら、ＭＰＲ、ＭＩＰ及びＶＲのような手法は、かなりの処理資源量を消費し得る。処理資源が直ちに利用可能でない場合には、撮像能力は低速化し又は劣化し得る。同様に、ネットワークが比較的低い帯域幅を有する場合には、ネットワークを横断して３Ｄ画像データを転送するのに比較的長い時間が掛かる可能性がある。さらに、３Ｄデータ及び処理後の２Ｄデータの両方についての画質のような他の要因が画像表示システムの能力に影響を及ぼす可能性もある。
【００１６】
このように、分散型網で医用画像データを効率的に処理する方法及びシステムが求められている。加えて、分散型網の全体にわたって医用画像処理タスクを効率的に割り当てる方法及びシステムが求められている。また、分散型医用イメージング・システムの利用者に柔軟性及び制御を提供する方法及びシステムが求められている。
【課題を解決するための手段】
【００１７】
本発明の幾つかの実施形態は、分散型網での医用画像処理の方法を提供し、この方法は、サーバ、クライアント及び所定の帯域幅を有する通信経路を備えており、サーバ、クライアント及び通信経路に関連するシステム資源を含んでいる分散型網で通信を行なうステップと、監視データを生成するように、少なくとも一つの工程モニタでシステム資源及び帯域幅を監視するステップと、クライアントに表示可能な二次元画像データを形成するように三次元画像データを処理するためのシステム資源の少なくとも一部の割当てを、監視データに少なくとも部分的に基づいて推奨するステップと、を含んでいる。一実施形態では、二次元画像データを形成するように三次元画像データを処理する処理は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つを含んでいる。一実施形態では、二次元画像データを形成するように三次元画像データを処理する処理は、回転、ズーム、パン、コントラスト調節、輝度調節及び濃淡調節の少なくとも一つを含んでいる。一実施形態では、画像は医用画像データに対応している。一実施形態では、少なくとも一つの工程モニタは、クライアント側モニタ及びサーバ側モニタを含んでいる。一実施形態では、割当ては、サーバ及びクライアントの少なくとも一方によって自動的に受け入れられる。一実施形態では、システム資源は、サーバの処理負荷及びクライアントの処理速度を含んでいる。一実施形態では、システム資源はさらに、クライアントの処理能力を含んでいる。一実施形態では、この方法はさらに、監視データに少なくとも部分的に基づいて画像の画質を推奨するステップを含んでいる。
【００１８】
本発明の幾つかの実施形態は、医用画像処理のシステムを提供し、このシステムは、資源を処理するサーバを含んでおり、三次元画像データを記憶することが可能なサーバと、所定の帯域幅を有する通信経路を介したサーバとの通信が可能であり、資源を処理するクライアントを含んでおり、三次元画像データから形成された二次元画像を表示することが可能なクライアントと、資源を処理するクライアント、資源を処理するサーバ及び帯域幅に少なくとも部分的に基づいて、クライアントに画像を表示するために資源を処理するサーバの少なくとも一部及び資源を処理するクライアントの少なくとも一部を割り当てることが可能な構成制御と、を含んでいる。一実施形態では、構成制御は、資源を処理するクライアント、資源を処理するサーバ及び帯域幅に少なくとも部分的に基づいて、クライアントとサーバとの間での画像処理の配分についての推奨を供給する推奨供給器と相互作用することが可能である。一実施形態では、二次元画像は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つによって三次元画像データから形成可能である。一実施形態では、構成制御は、利用者によって調節可能である。一実施形態では、構成制御はさらに、画像の画質を制御することが可能である。一実施形態では、構成制御は、帯域幅、資源を処理するサーバ及び資源を処理するクライアントに対応する情報を受け取ることが可能である。一実施形態では、構成制御は、推奨供給器の推奨を無視することが可能である。一実施形態では、構成制御は、画質の事前指定の無視を帰結することが可能である。
【００１９】
本発明の幾つかの実施形態は、クライアントとサーバとの間で画像処理を配分するシステムを提供し、このシステムは、資源を処理するサーバを含んでおり、三次元医用画像データを記憶することが可能なサーバと、資源を処理するクライアントを含んでおり、二次元画像を表示することが可能なクライアントと、クライアントとサーバとの間に設けられており、所定の帯域幅を含む通信路と、監視データを生成するように、帯域幅、資源を処理するクライアント及びサーバ資源を監視する少なくとも一つの工程モニタと、二次元画像を形成するように三次元画像データを処理するために、監視データに少なくとも部分的に基づいてクライアントとサーバとの間での処理の配分を含む推奨を供給する推奨供給器と、を含んでいる。一実施形態では、三次元画像データは、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つで二次元画像を形成するように処理可能である。一実施形態では、モニタはさらに、監視データを形成するためにクライアントの処理能力を監視する。一実施形態では、少なくとも一つの工程モニタは、サーバ側工程モニタ及びクライアント側工程モニタを含んでいる。一実施形態では、推奨の少なくとも一部は、サーバ及びクライアントの少なくとも一方によって自動的に受け入れられる。一実施形態では、推奨はさらに、画像の画質を含んでいる。
【００２０】
本発明の幾つかの実施形態は、コンピュータ用の命令セットを含むコンピュータ読み取り可能な記憶媒体を提供し、命令セットは、クライアント及びサーバ、並びにクライアント及びサーバを結合する所定の帯域幅の通信路を含む分散型網のシステム資源を監視して、監視データを生成する監視ルーチンと、サーバに記憶可能な三次元画像データを処理することにより形成可能な二次元画像のクライアントでの表示を要求する要求ルーチンと、監視データに少なくとも基づいて、二次元画像をクライアントにおいて表示するために二次元画像の画質及び分散型網でのシステム資源の割当てを推奨する推奨ルーチンと、を含んでいる。一実施形態では、システム資源は、サーバの処理負荷及びクライアントの処理速度を含んでいる。一実施形態では、システム資源の割当ては、３Ｄ画像処理及び２Ｄ画像処理のためのサーバに対応するシステム資源の割当て、３Ｄ画像処理及び２Ｄ画像処理のためのクライアントに対応するシステム資源の割当て、並びにシステムの割当ての少なくとも一つを含んでいる。一実施形態では、サーバに対応する資源を３Ｄ画像処理のためのものとし、クライアントに対応するシステム資源を２Ｄ画像処理のためのものとする。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられていないことを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理及び２Ｄ画像処理のためにサーバに対応するシステム資源の割当てを推奨する。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられており、通信路の帯域幅が実質的な遅延を伴わずにサーバからクライアントへ三次元画像データを通信することが可能であることを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理及び２Ｄ画像処理のためにクライアントに対応するシステム資源の割当てを推奨する。一実施形態では、推奨ルーチンは、サーバが実質的に負荷を加えられており、通信路の帯域幅が実質的な遅延を伴ってサーバからクライアントへ三次元画像データを通信することが可能であることを示す監視データに少なくとも部分的に基づいて、３Ｄ画像処理のためにサーバに対応するシステム資源及び２Ｄ画像処理のためにクライアントに対応するシステム資源という割当てを推奨する。
【発明を実施するための最良の形態】
【００２１】
以上の概要、及び本出願の幾つかの実施形態についての以下の詳細な説明は、添付図面と共に精読するとさらに十分に理解されよう。本発明を説明する目的で幾つかの実施形態を図面に示す。しかしながら、本発明は、添付図面に示されている構成及び手段に限定されないことを理解されたい。
【００２２】
図１は、本出願の一実施形態による分散型網１００のブロック図を示す。分散型網１００は、サーバ１０２、クライアント１０４及び通信経路１０６を含み得る。通信経路１０６は関連する帯域幅を有する。通信経路１０６の帯域幅は、通信経路１０６全体にわたり一様であってもよいし、様々なセグメントに沿って変化してもよい。例えば、通信経路１０６は、銅ワイヤ撚り二線式網及び光網のように様々な帯域幅を有する様々な形式のネットワークの組み合わせを含み得る。通信経路１０６は、構内網（ＬＡＮ）、広域網（ＷＡＮ）、有線網、無線網及び光網等、又はこれらの任意の組み合わせを含み得る。同様に、通信経路１０６は、ルータ、リピータ、スイッチ、ハブ、スプリッタ、カプラ又は中継コンピュータ等のような様々な網要素を含み得る。
【００２３】
図２は、本出願の一実施形態による分散型イメージング・システム１００のブロック図を示す。サーバ１０２は、ＣＰＵ２０２、キャッシュ・メモリ２０４、記憶メモリ２０６、ＲＡＭ２０８、オペレーティング・システム２３０、並びに他のドライバ及びアプリケーション２３２を含み得る。ＣＰＵ２０２は、多数のプロセッサを含み得る。キャッシュ・メモリ２０４は、ＣＰＵ２０２によって高速にアクセスされ得る揮発性メモリを含み得る。記憶メモリ２０６は、磁気ハード・ドライブ、光ハード・ドライブ、フラッシュ・メモリ又はＥＥＰＲＯＭ等のようなディジタル不揮発性記憶装置を含み得る。ＲＡＭ２０８は、ダイナミックＲＡＭ、スタティックＲＡＭ又はバッテリ・バックアップ式ＲＡＭ等を含み得る。オペレーティング・システム２３０は、例えばWindows（登録）、Unix（商標）、Linux（商標）又はMacintosh（商標）等のオペレーティング・システムを含み得る。オペレーティング・システム２３０は、サーバ１０２での動作向けに設計されていてよい。オペレーティング・システム２３０は、様々なサーバ１０２構成要素の間での相互作用を容易にすることができる。他のドライバ及びアプリケーション２３２は、多様なハードウェア・モジュール及びソフトウェア・モジュールを含み得る。例えば、他のドライバ及びアプリケーション２３２は、グラフィックス・アクセラレータ・ハードウェア・モジュール及び三次元グラフィックス・プロセッサ・ソフトウェア・モジュールを含み得る。他のドライバ及びアプリケーション２３２は、医用画像処理を容易にするためのドライバ及びアプリケーションを含み得る。本出願で用いられる画像処理との用語は、例えば画像表示及びボリューム・レンダリングを含めた広い意味の用語である。画像処理は、例えば２Ｄ画像データ、３Ｄ画像データ及び２Ｄ投影画像データの処理等を含み得る。画像処理は、例えばＭＰＲ、ＭＩＰ及びＶＲ等を含み得る。画像データは、例えばＤＩＣＯＭ、ＡＮＡＬＹＺＥ、ＢＭＰ、ＪＰＧ、ＧＩＦ及びＴＩＦ等を含めた多様なフォーマットに書式化されていてよい。画像データは、圧縮されていてもよいしいなくてもよい。
【００２４】
クライアント１０４は、パーソナル・コンピュータ、デスクトップ、ラップトップ、ワークステーション、ダム端末又はシン・クライアント等であってよい。クライアント１０４は、ＣＰＵ２１０、表示ドライバ２１２、表示器２１４、ユーザ・インタフェイス２１６、キャッシュ・メモリ２１８、記憶メモリ２２０、ビデオ・メモリ２２２、ＲＡＭ２２４、オペレーティング・システム２２６、並びに他のドライバ及びアプリケーション２２８を含み得る。ＣＰＵ２１０は、多数のプロセッサを含み得る。表示ドライバ２１２は、表示器２１４を駆動するように特殊化されたハードウェアを含み得る。表示器２１４は、陰極線管、フラット・パネル・モニタ、液晶表示器又は発光ダイオードのアレイ等を含み得る。ユーザ・インタフェイス２１６は、マウス及びキーボード、又は利用者からの動作を受け入れるその他外部入力装置を含み得る。キャッシュ・メモリ２１８は、ＣＰＵ２１０によって高速にアクセスされ得る揮発性メモリを含み得る。記憶メモリ２２０は、磁気ハード・ドライブ、光ハード・ドライブ、フラッシュ・メモリ又はＥＥＰＲＯＭ等のようなディジタル不揮発性記憶装置を含み得る。ビデオ・メモリ２２２は、ダイナミックＲＡＭビデオのようなＲＡＭを含み得る。ビデオ・メモリ２２２は、対応する画像が表示器２１４に表示される前に画像データをバッファリングすることができる。ＲＡＭ２２４は、ダイナミックＲＡＭ、スタティックＲＡＭ又はバッテリ・バックアップ式ＲＡＭ等を含み得る。オペレーティング・システム２２６は、例えばWindows（商標）、Unix（商標）、Linux（商標）又はMacintosh（商標）等のオペレーティング・システムを含み得る。オペレーティング・システム２２６は、クライアント１０４での動作向けに設計されていてよい。オペレーティング・システム２２６は、様々なクライアント１０４構成要素の間での相互作用を容易にすることができる。他のドライバ及びアプリケーション２２８は、多様なハードウェア・モジュール及びソフトウェア・モジュールを含み得る。例えば、他のドライバ及びアプリケーション２２８は、グラフィックス・アクセラレータ・ソフトウェア・モジュール及び三次元グラフィックス・プロセッサ・ハードウェア・モジュールを含み得る。他のドライバ及びアプリケーション２２８は、ＭＰＲ、ＭＩＰ及びＶＲ等のような医用画像データ処理を容易にするためのドライバ及びアプリケーションを含み得る。
【００２５】
図３は、本出願の一実施形態による分散型イメージング・システム３００のブロック図を示す。サーバ３０２は、図１及び図２に示すサーバ１０２と同様のものであってよい。サーバ３０２は、サーバ資源３０８、サーバ側モニタ３１０及び推奨供給器３０６を含み得る。サーバ資源３０８は、図２に示すサーバ構成要素の諸相を含み得る。例えば、サーバ資源３０８は、ＣＰＵ２０２、キャッシュ・メモリ２０４、記憶メモリ２０６、ＲＡＭ２０８、オペレーティング・システム２３０、並びに他のドライバ及びアプリケーション２３２の諸相を含み得る。サーバ資源３０８は、オペレーティング・システム２３０の形式及びバージョン情報、ＣＰＵ２０２の空き状況、ＲＡＭ２０８の空き容量、キャッシュ２０４の空き容量、記憶メモリ２０６の空き容量、並びに他のドライバ及びアプリケーション２３２の形式、バージョン及び空き状況を含み得る。例えば、サーバ資源３０８は、ＣＰＵ２０２の負荷状況を含むこともできるし、未処理要求の待ち行列に対応する情報を含むこともできる。
【００２６】
サーバ側モニタ３１０は、システム資源及び通信経路３０５の帯域幅を監視することができる。システム資源は、サーバ資源３０８及びクライアント資源３１６を含み得る。サーバ側モニタ３１０は、システム資源及び帯域幅に対応する監視データを供給することができる。サーバ側モニタは、例えば、サーバ資源３０８及び通信経路３０５の帯域幅を監視することができる。サーバ側モニタ３１０はまた、クライアント３１２と通信して、例えばクライアント資源３１６のようにクライアント側モニタ３１４によって収集された情報を受け取ることができる。サーバ側モニタ３１０はまた、クライアント３１２と通信して、性能指標器３２０からの情報を受け取ることもできる。サーバ側モニタ３１０は省かれてもよいし、サーバ３０２に対して外部に位置する装置として設けられてもよい。サーバ側モニタ３１０は、ソフトウェア、ハードウェア、又はファームウェア若しくはこれらの任意の組み合わせで具現化され得る。また、クライアント３１２にサーバ側モニタ３１０を含めることも可能であり得る。サーバ側モニタ３１０は、サーバ資源３０８の幾つか及び帯域幅に対応する情報を繰り返しチェックすることができる。例えば、サーバ側モニタ３１０は、サーバＣＰＵ２０２（図２に示す）に対する負荷を周期的にチェックすることができる。というのは、サーバＣＰＵ２０２の負荷はサーバ１０２の動作中に変化し得るからである。サーバ側モニタ３１０はまた、サーバ資源３０８の幾つか及び帯域幅に対し、１回限りのチェックを行なうこともできる。例えば、サーバ側モニタ３１０は、起動時にのみサーバのオペレーティング・システム２３０（図２に示す）のバージョンをチェックすることができる。というのは、オペレーティング・システムのバージョンはサーバ３０２の連続動作中には変化しない可能性が高いからである。
【００２７】
推奨供給器３０６は、サーバ３０２とクライアント３１２との間でのシステム資源の割当てを推奨する。推奨供給器３０６は、サーバ側モニタ３１０、クライアント側モニタ３１４、構成制御３１８及び性能指標器３２０によって収集された情報を扱うことができる。推奨供給器３０６はサーバ３０２に位置している必要はない。推奨供給器３０６は、クライアント３１２の一部であってもよいし、通信経路３０５で通信する追加装置であってもよいし、サーバ３０２、クライアント３１２又は追加装置の全体に分散されていてもよい。推奨供給器３０６は、ソフトウェア、ハードウェア若しくはファームウェア、又はこれらの組み合わせで具現化され得る。推奨供給器３０６については後にあらためて詳述する。
【００２８】
クライアント３１２は、クライアント資源３１６、クライアント側モニタ３１４、構成制御３１８及び性能指標器３２０を含み得る。クライアント３１２は、図２に示すクライアント１０４と同様のものであってよい。クライアント資源３１６は、図２に示すクライアント１０４構成要素を含み得る。例えば、クライアント資源は、ＣＰＵ２１０、キャッシュ・メモリ２１８、記憶メモリ２２０、ＲＡＭ２２４、ビデオ・メモリ２２２、表示ドライバ２１２、表示器２１４、ユーザ・インタフェイス２１６、オペレーティング・システム２２６、並びに他のドライバ及びアプリケーション２２８の諸相を含み得る。クライアント資源３１６は、オペレーティング・システム２２６の形式及びバージョン情報、ＣＰＵ２１０の空き状況、ＲＡＭ２２４の空き容量、キャッシュ２１０の空き容量、記憶メモリ２２０の空き容量、ビデオ・メモリ２２２の空き容量、表示器２１４の形式、表示ドライバ２１２の形式、並びに他のドライバ及びアプリケーション２２８の形式、バージョン及び空き状況を含み得る。例えば、クライアント資源３１６は、表示ドライバ２１２及びＣＰＵ２１０動作速度に対応するハードウェア情報及びソフトウェア情報を含み得る。
【００２９】
クライアント側モニタ３１４は、システム資源及び通信経路３０５の帯域幅に対応する情報を集積することができる。クライアント側モニタ３１４は特に、クライアント資源３１６及び帯域幅を監視することができる。クライアント側モニタは、システム資源及び帯域幅に対応する監視データを供給することができる。クライアント側モニタ３１４はまた、サーバ３０２と通信して、例えばサーバ資源３０８のようにサーバ側モニタ３１０によって収集された情報を受け取ることができる。クライアント側モニタ３１４は、性能指標器３２０からの情報を受け取ることができる。クライアント側モニタ３１４は省かれてもよいし、クライアント３１２に対して外部に位置する装置として設けられてもよい。また、サーバ３０２に別個の装置としてクライアント側モニタ３１４を含めることも可能であるし、クライアント側モニタ３１４が網構成装置の全体に分散されていてもよい。クライアント側モニタ３１４は、ソフトウェア、ハードウェア若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。クライアント側モニタ３１４は、クライアント資源３１６の幾つか及び帯域幅に対応する情報を繰り返しチェックすることができる。例えば、クライアント側モニタ３１４は、クライアントＲＡＭ２２４の空き容量を周期的にチェックすることができる。というのは、ＲＡＭ２２４の空き容量はクライアント１０４の動作中に変化し得るからである。クライアント側モニタ３１４はまた、クライアント資源３１６の幾つか及び帯域幅に対し、１回限りのチェックを行なうこともできる。例えば、クライアント側モニタ３１４は、起動時にのみ表示ドライバ２１２に対応する情報をチェックすることができる。というのは、表示器ドライバ２１２は、クライアント３１２の連続動作中には変化しない可能性が高いからである。
【００３０】
性能指標器３２０は、クライアント３１２の１又は複数の能力規準を推定し且つ／又は集積することができる。性能指標器３２０は、クライアント３１２の一部であってもよいし、サーバ３０２の一部であってもよいし、追加装置であってもよいし、ネットワークの全体に分散されていてもよい。性能指標器３２０は、ソフトウェア、ハードウェア及び／若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。一例として、性能指標器３２０は、医用画像を表示するためのクライアント３１２の処理能力を推定することができる。性能指標器３２０は、利用者が観察するようにクライアント３１２が医用画像を表示器２１４に表示する速度又は迅速性に対応する情報を供給することができる。工程指標器３１８は、クライアント側モニタ３１４、サーバ側モニタ３１０、構成制御３１８及び／又は推奨供給器３０６と通信して、情報を共有することができる。
【００３１】
構成制御３１８は、システム資源を割り当て、また画質のような他の変数に値を設定する能力を提供するクライアント側モジュールであってよい。構成制御３１８は、クライアント３１２の一部であってもよいし、サーバ３０２の一部であってもよいし、追加装置であってもよいし、ネットワークの全体に分散されていてもよい。構成制御３１８は、ソフトウェア、ハードウェア及び／若しくはファームウェア、又はこれらの任意の組み合わせで具現化され得る。構成制御３１８は、利用者が、クライアント３１２のユーザ・インタフェイス２１６（図２にクライアント１０４の一部として示す）と相互作用（対話）して、如何にシステム資源を割り当て、また他の変数を設定すべきであるかを指令するのを可能にすることができる。構成制御３１８は、システム管理者が、如何にシステム資源を割り当てて設定すべきであるかを指令するのを可能にすることができる。構成制御３１８は、分散型撮像工程が分散型システム３００に如何に割り当てられるかを決定することができる。構成制御３１８は、クライアント１０４及びサーバ１０２の図２に示す様々な構成要素と通信することができる。構成制御３１８は、オペレーティング・システム２３０と通信するソフトウェア・モジュールの形態であってよい。構成制御３１８は、画像処理アプリケーションに統合されて、例えば「設定」、「オプション」又は「初期設定」のようなメニュー選択肢を介してアクセス可能にされ得る。構成制御３１８の動作については後にあらためて詳述する。
【００３２】
通信経路３０５の帯域幅は、クライアント３１２に医用画像を表示するために如何にシステム資源を割り当てるかを決定する要因となり得る。帯域幅は、クライアント３１２又はサーバ３０２のいずれかによって推定され又は測定され得る。例えば、クライアント側モニタ３１４又はサーバ側モニタ３０４は、多くの公知の手法の任意のものによって帯域幅を推定することができる。帯域幅を推定する一手法は、通信経路３０５を介して既知のサイズの試験用パケットを通信して、試験用パケット通信の完了に掛かる時間を測定するものである。
【００３３】
図７は、本発明の一実施形態による分散型撮像表示の方法７００の流れ図を示す。第一の枝７４０、第二の枝７５０及び第三の枝７６０の３列の異なる枝が示されている。枝７４０、７５０及び７６０の各々は、ステップ７０２で開始することができ、このステップでは、３Ｄ画像データをサーバ（図３に示すサーバ３０２等）に記憶させる。枝７４０、７５０及び７６０の各々は、ステップ７２８で終了することができ、このステップでは、２Ｄ画像データを処理して、クライアント（図３に示すクライアント３１２と同様のもの）の表示器に表示させる。点線７３０は、いずれのステップがサーバによって実行されいずれのステップがクライアントによって実行されるかを示す。ステップ７０２のように点線７３０よりも上の全ステップがサーバによって実行され得る。ステップ７２８のように点線７３０よりも下の全ステップがクライアントによって実行され得る。
【００３４】
ステップ７０２の後に、第一の枝７４０はステップ７０４に続き、このステップでは、３Ｄ画像データをサーバによって処理して２Ｄ画像データを形成することができる。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。ステップ７０６では、２Ｄ画像データをさらに処理して、表示される画像データを形成することができる。例えば、２Ｄ画像データは、濃淡、コントラスト及び／又は輝度を調節することによりさらに処理され得る。ステップ７０８で２Ｄ画像データはサーバから送信され、ステップ７１０でクライアントによって受信されることができる。ステップ７２８では、２Ｄデータをクライアントによって処理して表示させることができる。
【００３５】
第二の枝７５０は、ステップ７０２の後にステップ７１２へ進み、このステップでは、サーバが３Ｄ画像データを処理して２Ｄ画像データを形成する。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。次に、ステップ７１４で２Ｄ画像データはサーバから送信されて、ステップ７１６でクライアントによって受信される。２Ｄ画像データの受信の後に、クライアントは２Ｄ画像データをさらに処理して、表示用の画像データを形成することができる。ステップ７２８では、クライアントは２Ｄ画像データを処理して表示器に表示させることができる。
【００３６】
第三の枝７６０は、ステップ７０２の後にステップ７２０へ進み、このステップでは、３Ｄ画像データはサーバから送信されて、ステップ７２２でクライアントにおいて受信される。ステップ７２４では、クライアントが３Ｄ画像データを処理して２Ｄ画像データを形成することができる。処理は、ＭＰＲ、ＭＩＰ、ＶＲのような手法、及び／又は３Ｄデータを２Ｄデータへ変換するその他の画像処理手法を含み得る。次に、クライアントは、２Ｄ画像データをさらに処理して、表示用の画像データを形成することができる。ステップ７２８では、クライアントは、２Ｄ画像データを処理して、表示器に表示させることができる。点線７３０の角度から分かるように、クライアント及びサーバによって実行される処理の量は、流れ図７００のいずれの枝を辿っているかによって異なる。流れ図７００の各ステップは異なる順序で実行されてもよい。加えて、流れ図７００の１又は複数のステップを省いてもよい。例えば、ステップ７１８、７２６又は７０６を省いてもよい。３列の枝７４０、７５０及び７６０は、分散型撮像のための全ての可能な工程フローを網羅している訳ではない。その代わりに、これらの枝は、工程フローを異なるシナリオで如何に割り当て得るかの概念を例示するに過ぎない。ステップ７０４、７１２及び７２４で行なわれる処理をクライアント及びサーバの両方で分担する等の付加的な変形も可能である。
【００３７】
クライアントとサーバとの間で分散処理を如何に割り当てるかを決定するために、幾つかの形式の割当て工程が望ましい場合がある。図４は、本出願の一実施形態による分散画像処理のために資源の割当てを推奨する方法４００の流れ図を示す。ステップ４０２で開始して、分散型網での通信が行なわれる。例えば、クライアント３１２がサーバ３０２に対し、画像をクライアント３１２側で表示させたいと通信することができる。通信は、監視データ、画像処理割当て及び構成制御指令を含め多様な情報を含み得る。
【００３８】
ステップ４０４では、モニタが、帯域幅及びシステム資源を監視する。ステップ４０４は、１又は複数のモニタによって実行され得る。例えば、ステップ４０４は、サーバ側モニタ３１０及びクライアント側モニタ３１４によって実行され得る（図３に両方を示す）。モニタ（１又は複数）は、帯域幅及びシステム資源に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、分散型網３００の特性すなわち通信経路３０５の帯域幅、サーバ３０２ＣＰＵの負荷（図２に示すサーバ２０２と同様のもの）及びクライアント３１２の処理速度を追跡することができる。モニタ（１又は複数）は、様々なシステム資源及び帯域幅に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、サーバ３０２ＣＰＵの負荷、クライアント３１２の処理速度、クライアント３１２の処理能力、及び通信経路３０５の帯域幅に対応する監視データを供給することができる。
【００３９】
ステップ４０６では、クライアントに画像を表示させる要求を出す。例えば、クライアント３１２は、画像処理ソフトウェアを実行することができる。利用者は、このソフトウェアと相互作用して、医用画像に対して画像処理タスクを実行することができる。ソフトウェアは画像処理要求を開始することができ、要求はクライアント３１２のオペレーティング・システムに中継される。画像処理要求は、画質のような処理対象画像についての情報を含み得る。画像処理要求はまた、例えば画像をズームする又はパンする等のような画像処理要求の性質についての情報を含んでいてよい。画像処理要求は、クライアント３１２からサーバ３０２へ通信され得る。
【００４０】
ステップ４０８では、システム資源の割当てが監視データに基づいて推奨される。ここで一時図５を参照して述べると、同図には本出願の一実施形態による割当ての幾つかの例の表５００が示されている。各例は例示するものであって網羅するものではない。例１では、サーバ３０２は相対的に負荷を加えられておらず、すなわちサーバＣＰＵが他の処理待ちタスクによって過度に負荷を掛けられている状態ではないことを意味する。さらに、クライアント３１２処理速度は相対的に遅く、通信経路の帯域幅は相対的に高い。尚、相対的に高い所定の帯域幅とは、サーバ３０２に記憶されている三次元画像データが実質的な遅延を伴わないでクライアント３１２に通信され得ることを示すものと理解されたい。遅延は、例えば代替的な画像処理フローの方がクライアント３１２での画像表示が高速である場合には実質的であると言える。換言すると、実質的な遅延は、非効率的な画像処理フローを選択したときに生じ得る。例１のシナリオでは、全ての処理タスクをサーバ３０２で主に実行するように推奨する。例１での推奨は、図７の第一の枝７４０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４１】
例２では、サーバ３０２は相対的に負荷を加えられておらず、すなわちサーバＣＰＵが他の処理待ちタスクによって過度に負荷を掛けられている状態ではないことを意味する。さらに、クライアント３１２の処理速度は相対的に遅く、通信経路の帯域幅は相対的に低い。このシナリオでは、パン及びズームのような幾つかの単純な処理タスクはクライアント３１２によって実行され、高度なタスクはサーバ３０２に残しておくことができる。このシナリオでは、全ての処理タスクをサーバ３０２で主に実行するように推奨する。例２の推奨は、図７の第二の枝７５０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４２】
例３では、サーバ３０２は相対的に負荷を加えられており、すなわちサーバＣＰＵが、画像処理を実行するサーバの能力に干渉し得る処理待ちタスクを有していることを意味する。さらに、クライアント処理速度は相対的に速く、通信経路の帯域幅は相対的に高い。このシナリオでは、全ての処理タスクをクライアント３１２で実行するように推奨する。例３の推奨は、図７の第三の枝７６０に示すものと類似した工程フローに対応し、かかる工程フローを期待し、又はかかる工程フローにトリガを与えることができる。
【００４３】
図４に戻ると、選択随意のステップ４１６では、監視データに基づいて画質もまた推奨する。例えば、クライアント処理速度が相対的に遅い場合には、相対的に低い画質を推奨して画像処理速度を高めることができる。
【００４４】
ステップ４１０では、システム資源の推奨された割当てを受け入れることができる。割当ては、例えばサーバ３０２及び／又はクライアント３１２によって受け入れられ得る。割当ては、自動的に受け入れられてもよいし、手動で受け入れられてもよい。加えて、割当ては、一組の規則に基づいて条件付きで受け入れられてもよい。構成制御３１８が、推奨の条件付き受け入れの規則を供給することができる。
【００４５】
選択随意のステップ４１８では、推奨された画質を受け入れる。ここでも、推奨は、自動的に受け入れられてもよいし、手動で受け入れられてもよいし、条件付きで受け入れられてもよい。
【００４６】
ステップ４１２では、割り当てられたシステム資源で画像データを処理する。例えば、幾つかのクライアント資源３１６及び幾つかのサーバ資源３０８が効率的な画像処理のためにステップ４０８で割り当てられていてよい。次いで、割り当てられたサーバ資源３０８は画像処理の一部を実行し、割り当てられたクライアント資源３１６は画像処理の残部を実行することができる。画像処理は、ＭＰＲ、ＭＩＰ、ＶＲのような処理集約的手法、及び／又は付加的な３Ｄ−２Ｄ変換処理手法を含み得る。画像処理はまた、回転、パン、ズーム、コントラスト調節、輝度調節及び／又は濃淡調節等のような手法を含み得る。
【００４７】
ステップ４１４では、対応する画像がクライアント３１２に表示される。ステップ４１２で割り当てられたシステム資源によって画像が処理された後に、得られた画像をクライアント３１２に表示することができる。画像をクライアント３１２に表示する処理はまた、さらに一般的には画像処理の一部と看做すこともできる。
【００４８】
方法４００の各ステップは任意の順序で実行されてよい。加えて、方法４００の１又は複数のステップを省いてもよい。例えば、ステップ４０４をステップ４０６の後に実行してもよいし、ステップ４１０、４１２及び４１４を省いてもよい。
【００４９】
説明のための例として、本出願の実施形態を次の態様で用いることができる。分散型網３００において、クライアント３１２が表示器２１４に医用画像を表示する。画像データは、クライアント３１２にローカルに記憶されていてもよいしサーバ３０２に記憶されていてもよい。クライアント３１２は、表示画像を利用者が編集し又は変更することを可能にするアプリケーションを提供する。利用者は、ユーザ・インタフェイス２１６を介してクライアント３１２と相互作用する。利用者は、注釈記入、コントラスト調節、輝度調節、濃淡調節、パン、ズーム、回転、３Ｄ処理を含めて、表示画像を画像処理アプリケーションによって編集し又は変更する多様な画像処理タスクから選択を行なうことができる。この説明のための例では、利用者は、ユーザ・インタフェイス２１６に相応に指令することにより「コントラスト調節」を選択する。この間に、クライアント側モニタ３１４及びサーバ側モニタ３１０の両方が、システム資源及び帯域幅を追跡している。サーバ側モニタ３１０がサーバＣＰＵ２０２の負荷を追跡すると、最新の指標は例えばサーバＣＰＵ２０２が９５％を上回る空き状態にある等のようにサーバＣＰＵが相対的に負荷を加えられていないことを示す。クライアント側モニタ３１４は、起動時にクライアント３１２が相対的に低いプロセッサ速度及びクロック速度を有していることを決定している。また、クライアント側モニタ３１４が通信経路３０５の帯域幅を追跡すると、最新の指標は帯域幅が相対的に低いことを示す。サーバ側モニタ３１０は、サーバＣＰＵ負荷情報を監視データとして推奨供給器３０６へ供給する。クライアント側モニタ３１４は、クライアント処理速度及び帯域幅情報を監視データとして推奨供給器３０６へ供給する。推奨供給器３０６は、効率的な画像処理モードは、画像のコントラストを調節するためにはクライアント資源３１６を割り当てるのみでよいと決定する。推奨供給器３０６はまた、クライアント３１２は、この画像処理タスクを低品質画像に対してしか十分な速度で実行し得ないものと決定する。推奨供給器３０６は、このタスクにクライアント資源３１６を割り当てて、画像は低画質とすべきであるとの推奨を供給する。クライアント３１２はこれらの推奨を自動的に受け入れて、利用者の指令に従ってコントラストを調節することにより画像の処理に着手する。
【００５０】
説明のための例を続けると、利用者は次に、相対的に複雑な画像処理タスクを実行しようとする。利用者は、異なる角度の画像を観察しようとする。この形式の画像処理は、相対的に集約的なＭＰＲ手法を必要とする。加えて、利用者は、新たな角度の画像を観察しているときにも以前に適用したコントラスト調節を保存しておこうとする。クライアント側モニタ３１４及びサーバ側モニタ３１０の両方とも、システム資源及び帯域幅に著しい変化を認めない。サーバ側モニタ３１０は、サーバＣＰＵ負荷情報を監視データとして推奨供給器３０６へ供給する。クライアント側モニタ３１４は、クライアント処理速度及び帯域幅を情報監視データとして推奨供給器３０６へ供給する。この場合には、推奨供給器３０６は、効率的な画像処理モードは、画像を処理するためにサーバ資源３０８の一部及びクライアント資源３１６の一部を割り当てるものと決定する。サーバ資源３０８は最も効率的にＭＰＲ処理を実行することができる一方で、クライアント資源３１６は最も効率的に後続のコントラスト調節処理を実行することができる。推奨供給器３０６はまた、システム資源は、この処理タスクを低品質画像に対してしか十分な速度で実行し得ないものと決定する。推奨供給器３０６は、幾つかのサーバ資源３０８及び幾つかのクライアント資源３１６をこのタスクのために割り当てて、画像は低画質とすべきであるとの推奨を供給する。クライアント３１２及びサーバ３０２はこれらの推奨を自動的に受け入れて、利用者の指令に従って画像の処理に着手する。
【００５１】
図６は、本出願の一実施形態による分散画像処理システムにおいてシステム資源を割り当てるために構成制御との相互作用（対話）を提供する方法６００の流れ図を示す。ステップ６０２では、利用者が、システム資源の割当て及び／又は画質に関連する指令を構成制御３１８に与える。もう一つの選択肢として、指令はシステム管理者によって与えられてもよい。また、指令は、例えば自動タイマ又はカレンダのスケジュールを介して自動的に与えられてもよい。
【００５２】
ステップ６０４では、分散型網での通信を行なう。例えば、クライアント３１２がサーバ３０２に対し、画像をクライアント３１２に表示させたいと通信することができる。通信は、監視データ、画像処理割当て及び構成制御指令を含め多様な情報を含み得る。
【００５３】
ステップ６０６では、帯域幅及びシステム資源を監視して監視データを形成する。ステップ６０６は、１又は複数のモニタによって実行され得る。例えば、ステップ６０６は、サーバ側モニタ３１０及びクライアント側モニタ３１４（両方とも図３に示されている）によって実行され得る。モニタ（１又は複数）は、帯域幅及びシステム資源に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、分散型網３００の特性すなわち通信経路３０５の帯域幅、サーバ３０２ＣＰＵの負荷（図２に示すサーバＣＰＵ２０２と同様のもの）及びクライアント３１２の処理速度を追跡することができる。モニタ（１又は複数）は、様々なシステム資源及び帯域幅に対応する監視データを供給することができる。例えば、モニタ（１又は複数）は、サーバ３０２ＣＰＵの負荷、クライアント３１２の処理速度、クライアント３１２の処理能力、及び通信経路３０５の帯域幅に対応する監視データを供給することができる。
【００５４】
ステップ６０８では、クライアントで画像を表示させる要求を出す。例えば、クライアント３１２は画像処理ソフトウェアを実行していてよい。利用者は、このソフトウェアと相互作用して、医用画像に対して画像処理タスクを実行することができる。ソフトウェアは画像処理要求を開始することができ、要求はクライアント３１２のオペレーティング・システムに中継される。画像処理要求は、画質のような処理対象画像についての情報を含み得る。画像処理要求はまた、例えば画像をズームする又はパンする等のような画像処理要求の性質についての情報を含んでいてよい。画像処理要求は、クライアント３１２からサーバ３０２へ通信され得る。
【００５５】
ステップ６１０では、システム資源の割当てが、監視データ及び／又は構成制御３１０に基づいて推奨される。システム設計及び構成制御３１０の選択に基づいて、多様な選択肢を可能にすることができる。例えば、推奨される割当ては、構成制御３１０に専ら基づいていてもよいし、監視データに専ら基づいていてもよい。推奨される割当ては、監視データ及び構成制御３１０の混成に基づいていてもよい。例えば、構成制御３１０は、特定の資源割当てについての最小限度又は最大限度を供給することができる。構成制御３１０は、サーバＣＰＵ２０２の負荷が５０％が超えてはならないと指示することができる。従って、この例では、サーバＣＰＵ２０２の任意の推奨される割当ては、サーバＣＰＵ２０２の負荷が５０％を下回った状態にある場合には監視データに基づくべきであるが、構成制御３１０によって決定された５０％のサーバＣＰＵ２０２の負荷を上限とすべきである。構成制御３１０の様々な設定又はパラメータが、監視データ及び構成制御３１０が推奨される割当てにどの程度影響を及ぼすべきかを指示することができる。
【００５６】
選択随意のステップ６１８では、監視データ及び／又は構成制御３１０に基づいて画質が推奨される。システム設計及び及び構成制御３１０の選択に基づいて、多様な選択肢を可能にすることができる。例えば、推奨される画質は、構成制御３１０に専ら基づいていてもよいし、監視データに専ら基づいていてもよい。推奨される画質は、監視データ及び構成制御３１０の混成に基づいていてもよい。例えば、構成制御３１０は、画質についての最小限度又は最大限度を供給することができる。構成制御３１０は、画質が一定の分解能を下回らないものと指示することができる。従って、この例では、任意の推奨される画質は、推奨が最低画質分解能を上回っている場合には監視データに基づくべきであるが、構成制御３１０によって決定された推奨される画質分解能を上限とすべきである。構成制御３１０の様々な設定が、監視データ及び構成制御３１０が推奨される画質にどの程度影響を及ぼすべきかを指示することができる。
【００５７】
ステップ６１２では、推奨されたシステム資源の割当てを受け入れることができる。割当ては、例えばサーバ３０２及び／又はクライアント３１２によって受け入れられ得る。割当ては、自動的に受け入れられてもよいし、手動で受け入れられてもよい。加えて、割当ては、一組の規則に基づいて条件付きで受け入れられてもよい。構成制御３１８が、推奨の条件付き受け入れの規則を供給することができる。
【００５８】
選択随意のステップ６２０では、推奨される画質が受け入れられる。ここでも、推奨は、自動的に受け入れられてもよいし、手動で受け入れられてもよい。
【００５９】
ステップ６１４では、割り当てられたシステム資源で画像データを処理する。例えば、幾つかのクライアント資源３１６及び幾つかのサーバ資源３０８が効率的な画像処理のためにステップ６１０で割り当てられていてよい。次いで、割り当てられたサーバ資源３０８は画像処理の一部を実行し、割り当てられたクライアント資源３１６は画像処理の残部を実行することができる。画像処理は、ＭＰＲ、ＭＩＰ、ＶＲのような処理集約的手法、及び／又は付加的な３Ｄ−２Ｄ変換処理手法を含み得る。画像処理はまた、パン、ズーム、コントラスト調節、輝度調節及び／又は濃淡調節等のような手法を含み得る。
【００６０】
ステップ６１６では、対応する画像がクライアント１０４に表示される。ステップ６１４で割り当てられたシステム資源によって画像が処理された後に、得られた画像をクライアント３１２に表示することができる。画像をクライアント３１２に表示する処理はまた、さらに一般的には画像処理の一部と看做すこともできる。
【００６１】
方法６００の各ステップは任意の順序で実行されてよい。加えて、方法６００の１又は複数のステップを省いてもよい。例えば、ステップ６０４をステップ６０６の後に実行してもよいし、ステップ６１０、６１２及び６１４を省いてもよい。
【００６２】
構成制御３１０の相互作用の説明のための例として、利用者は、ユーザ・インタフェイス２１６を介してクライアント１０４と相互作用する。利用者は、「オプション」メニューを有する画像処理ソフトウェアを動作させる。利用者は「オプション」メニューを開いて、構成制御３１０設定の幾つかにアクセスする。尚、利用者がアクセス可能な構成制御３１０設定もあれば、アクセス不能なものもあることを特記しておく。この説明のための例では、構成制御３１０設定は、最小分解能設定と、最小値設定が絶対的な最小値設定であるのか、又は単に示唆的な最小値設定であるのかを表わすチェック・ボックスとを含み得る。利用者は２００ドット毎インチ（「ＤＰＩ」）の最小分解能を選択して、この値が示唆的な最小値設定であって絶対的な最小値設定ではないことを示すようにチェック・ボックスを選択することができる。次いで、利用者は、画像処理を実行するようにソフトウェアに指令する。推奨供給器３１４は、サーバ側モニタ３０４及びクライアント側モニタ３１４によって収集された監視データを検討する。推奨供給器３１４はまた、構成制御３１０の設定を検討する。推奨供給器３１４は様々な要因を均衡させて、画像を処理する効率的な方法は、画像が１５０ＤＰＩの分解能を有するようにすることであると決定する。推奨供給器３１４は、資源の割当て及び１５０ＤＰＩの分解能を推奨する。推奨は、クライアント３１２及びサーバ３０２によって受け入れられる。画像データは処理されて、画像は１５０ＤＰＩの分解能でクライアント３１２の表示器２１４に表示される。
【００６３】
説明のための例を続けると、利用者は１５０ＤＰＩの画像を観察して、分解能を高めるべきであると判断する。そして、利用者は「オプション」メニューを開き、構成制御３１０にアクセスする。利用者は最小分解能を１７５ＤＰＩに設定する。利用者は、１７５ＤＰＩ設定は絶対的設定であることを示すチェック・ボックスを選択する。次いで、利用者は、画像処理を実行するようにソフトウェアに指令する。推奨供給器３１４は、サーバ側モニタ３０４及びクライアント側モニタ３１４によって収集された監視データを検討する。推奨供給器３１４はまた、構成制御３１０の設定を検討する。推奨供給器３１４は様々な影響のある要因を均衡させて、１７５ＤＰＩの分解能を有する画像を処理する最も効率的な方法を判定する。推奨供給器３１４は、資源の割当て及び１７５ＤＰＩの分解能を推奨する。推奨は、クライアント３１２及びサーバ１０２によって受け入れられる。画像データは処理されて、１７５ＤＰＩの分解能でクライアント１０４の表示器２１４に表示される。利用者は画像を検討して、画質に満足する。
【００６４】
図８は、本発明の一実施形態によるクライアントに表示される検査に対する繰り返し式の利用者相互作用を示す方法８００の流れ図である。ステップ８０２では、クライアント（図３に示すクライアント３１２と同様のもの）側に位置する利用者が、検査に対応する画像を表示することが可能であり得るアプリケーションを呼び出す。検査は、患者の放射線検査に対応する一組又は複数組の容積画像データ又は二次元画像データであってよい。例えば、検査は、３Ｄシネ画像データ、２Ｄシネ画像データ、３Ｄ静止データ及び／又は２Ｄ静止データ等を含み得る。アプリケーションは、検査全体を表示し得るものであってもよいし、検査の一部を表示し得るものであってもよい。アプリケーションは、利用者が、ユーザ・インタフェイスを介して検査の表示された部分又は検査全体と相互作用することを可能にすることができる。例えば、アプリケーションは、利用者が以下の相互作用を実行することを可能にすることができる。すなわち画像を前後にページめくりする、画像をパンする、画像をズーム・イン及び／又はズーム・アウトする、画像を回転させる、コントラストを調節する、輝度を調節する、色パラメータを調節する、濃淡パラメータを調節する、スライス厚を調節する、最大強度投影、平均強度投影及び最小強度投影の間を切り換える、ボリューム・レンダリング・モードに切り換える、視角を調節する等である。利用者が検査と相互作用するためのアプリケーションを呼び出すときに、画像処理を実行する且つ／又は支援することのできる対応するサーバ側アプリケーションを開始させると望ましい場合がある。そして、例えばクライアント側アプリケーションの呼び出しによって、メッセージをサーバへ送ることができる。メッセージは、画像処理アプリケーションがサーバでまだ実行されていない場合には、サーバに対しかかる画像処理アプリケーションを起動するように指令する又は要求することができる。例えば、サーバ側アプリケーションは、ＭＩＰ、ＭＰＲ及び／又はＶＲ等のような３Ｄ処理を実行することが可能なものであってよい。
【００６５】
ステップ８０４では、利用者は観察のための検査を選択する。例えば、利用者は放射線技師であってよく、臨床目的で検査を選択することができる。検査は、検査一覧から選択されてもよいし、過去の検査又は最近取得された検査に対応していてもよい。
【００６６】
ステップ８０６では、監視されたシステム・データ、構成制御設定、画像処理要求及び／又は利用者指令に基づいて、処理の割当てを選択する。例えば、図４に示す方法４００及び／又は図６に示す方法６００に従って割当てを選択することができる。
【００６７】
ステップ８０８では、選択された処理の割当てに従って、検査に対応する１又は複数の医用画像を処理する。画像を、例えば図７に示す方法７００に従って処理することができる。例えば、一つの検査に対応する多数の画像を処理することができる。各々の画像は、例えばアキシャル像、サジタル像、コロナル像及び斜方像のような異なる像に対応していてよい。
【００６８】
ステップ８１０では、１又は複数の医用画像をクライアントによって表示する。画像は、フラット・パネル・モニタ又は陰極線管のような表示器に表示され得る。表示される画像は実質的に２Ｄであってよいが、利用者にとっては３Ｄとして現われ得る。多数の画像は同時に表示されてもよいし、容易にアクセス可能であってもよい。例えば、一つの検査の多数の像に対応する多数の画像を同時に観察することができる。もう一つの例として、各々の画像表示がクライアントにおいてローカルにメモリに記憶されていてもよく、利用者が、画像データを再処理することに関連した遅延を招かずに多数の像の間を迅速に切り換えることもできる。
【００６９】
ステップ８１２では、利用者は表示画像（１又は複数）と相互作用して、選択された検査の異なる像を得る。例えば、利用者はアプリケーション及び／又は画像と相互作用して、以下の相互作用を実行することができる。すなわち画像を前後にページめくりする、画像をパンする、画像をズーム・イン及び／又はズーム・アウトする、画像を回転させる、コントラストを調節する、輝度を調節する、色パラメータを調節する、濃淡パラメータを調節する、スライス厚を調節する、最大強度投影、平均強度投影及び最小強度投影の間を切り換える、ボリューム・レンダリング・モードに切り換える、視角を調節する等である。利用者は、マウス、キーボード又は他のユーザ・インタフェイス装置と相互作用することができる。例えば、利用者は、タッチ・スクリーンの指触パッド及び／又はジョイスティック等と相互作用することができる。利用者は、メニュー、制御パネル及び／又はグラフィック・ユーザ・インタフェイス（ＧＵＩ）要素等を介してアプリケーション・プログラムと相互作用することができる。利用者はまた、例えば表示特性を調節することによりオペレーティング・システムを介して表示画像と相互作用することができる。利用者の表示画像との相互作用によって、画像処理要求が生じ得る。
【００７０】
利用者が表示画像と相互作用するときに、利用者の相互作用を反映させてクライアントに異なる画像を表示する必要がある場合がある。例えば、利用者が画像上でズーム・インを選択する場合に、ズーム（拡大）された画像の部分を、利用者の相互作用を反映させて表示させることができる。この相互作用を達成するために、方法８００のフローは１又は複数の前段のステップへ戻ることができる。例えば、相互作用を達成するために、方法８００はステップ８０６へ戻ることができる。ステップ８０６では、新たな割当てを選択することができる。システム資源モニタが、システム資源が実質的に変更されたと決定して、新たな資源割当てを推奨することが可能である場合もある。例えば、初期割当ては図７の枝７５０に対応し得る。この割当ては、図５の例２に示すように通信経路の帯域幅が相対的に低かったため選択されたものであり得る。しかしながら、続いての相互作用時に、網条件が改善して、通信経路の帯域幅が相対的に高くなっていたという場合もある。従って、図５の例１に従って、さらに効率的な割当ては図７の枝７４０に対応し得る。換言すると、改善された網条件のため、サーバにさらに多くの画像処理タスクを行なわせる方が効率的となる場合がある。
【００７１】
しかしながら、各回毎の相互作用時にシステム資源を割当てし直すのが望ましくない場合もある。従って、相互作用フローはステップ８１２からステップ８０８へ進んでもよい。ステップ８０８では、事前の処理の割当てに従って画像を処理する。例えば、画像処理タスクがサーバに割り当てられている場合には、画像処理要求はサーバへ直接向かってよい。もう一つの例として、画像処理タスクがクライアントに割り当てられている場合には、画像処理要求は、クライアントにおいてローカルに処理されてよい。
【００７２】
工程フローは、画像処理要求の性質に基づいて異なるステップに戻ってよい。例えば、画像処理要求が処理資源の集約的な利用を必要とし得る場合には、資源割当てを再度決定すると望ましい場合がある。もう一つの例として、画像処理要求が資源の集約的な利用を必要としないであろう場合には、既存の資源割当てを持続した方が望ましい場合がある。
【００７３】
方法８００の各ステップは異なる順序で実行されてもよい。加えて、方法８００の１又は複数のステップを省いてもよい。例えば、ステップ８０２又は８０４を省いてもよい。もう一つの例として、ステップ８０６をステップ８０２又は８０４の前に実行してもよい。
【００７４】
以下の説明のための例では、方法８００に従って利用者の画像との相互作用が如何に達成され得るかを説明する。ステップ８０２では、クライアント側に位置する利用者が、放射線検査を観察するように設計されているソフトウェア・アプリケーションを開く。このソフトウェア・アプリケーションはまた、利用者が検査の画像と相互作用することを可能にする。次いで、利用者はステップ８０４において、観察したい検査を選択する。検査はこの例では、胎児の超音波から得られたものとする。次に、ステップ８０６では、処理の割当てが選択される。この場合には、監視データは、サーバには負荷が加えられておらず、帯域幅は高く、クライアントは低速であることを示している。図５の例１に従って、例えば図７の枝７４０に示すように、画像処理の殆どをサーバで実行するように割り当てる。次に、ステップ８０８では、サーバに最初に記憶されていた画像データをサーバによって処理して、クライアントへ送信する。処理された画像データは胎児の２Ｄ画像であり、３Ｄとして現われる。ステップ８１０では、２Ｄ画像がクライアントに表示される。次に、ステップ８１２では、利用者は胎児の画像を観察する。しかしながら、利用者は、異なる角度の胎児を観察することを望む。従って、利用者は、ソフトウェア・アプリケーションの制御パネルを開いて、新たな視角を入力する。ソフトウェアはこの相互作用を解釈して、画像処理要求を生成する。新たな視角での画像は、画像データをＭＰＲ手法で再処理することを必要とし得る。ソフトウェア・アプリケーションは、この形式の相互作用が実質的な処理資源を要求し得ることを認識する。結果的に、工程フローはステップ８０６に戻る。ステップ８０６では、網条件が悪化しており、帯域幅が今は相対的に低くなっているものと決定される。従って、図５の例２に従って、３Ｄ画像処理の殆どをサーバで実行するように割り当てて、比較的単純なタスクはクライアントによって実行されるように割り当てる。この形式の割当てを、例えば図７の枝７５０に示す。次いで、ステップ８０８では、画像処理要求に従って画像データを処理する。次いで、ステップ８１０で画像をクライアントに表示する。
【００７５】
次に、利用者は、ステップ８１２で新たな角度の像のコントラストを変化させることを決定する。従って、利用者は、ソフトウェア・アプリケーションの制御パネルを開いて、新たなコントラスト量を入力する。ソフトウェアはこの相互作用を解釈して、画像処理要求を生成する。ソフトウェア・アプリケーションはまた、この形式の相互作用が実質的な処理資源を要求し得ることを認識する。結果的に、工程フローはステップ８０８に戻る。画像データは、画像処理要求及び事前割当てに従って処理される。資源の事前割当ては、この形式の画像処理を実行するためにはクライアントを割り当てているため、画像処理要求はローカルに直接クライアントに送られる。次いで、ステップ８１０において画像をクライアントに表示させる。ステップ８１２では、利用者が画像と相互作用し続ける間は繰り返し式工程は続行する。
【００７６】
このように、本出願の実施形態は、分散型網で画像データを効率的に処理する方法及びシステムを提供する。加えて、本出願の実施形態は、分散型網の全体で画像処理タスクを効率的に割り当てる方法及びシステムを提供する。さらに、本出願の実施形態は、分散型イメージング・システムの利用者に対し、柔軟性及び制御を提供する。
【００７７】
幾つかの実施形態を参照して本発明を説明したが、当業者には、本発明の範囲から逸脱せずに様々な変形を施し、また均等構成を置換し得ることが理解されよう。加えて、本発明の範囲から逸脱せずに、本発明の教示に合わせて特定の状況又は材料を適応構成する多くの改変を施すことができる。例えば、各特徴は、ソフトウェア、ハードウェア又はこれらの混成で具現化され得る。従って、本発明は開示された特定の実施形態に限定されず、特許請求の範囲に含まれる全ての実施形態を包含するものとする。また、図面の符号に対応する特許請求の範囲中の符号は、単に本願発明の理解をより容易にするために用いられているものであり、本願発明の範囲を狭める意図で用いられたものではない。そして、本願の特許請求の範囲に記載した事項は、明細書に組み込まれ、明細書の記載事項の一部となる。
【図面の簡単な説明】
【００７８】
【図１】本出願の一実施形態による分散型網を示す図である。
【図２】本出願の一実施形態による分散型イメージング・システムのブロック図である。
【図３】本出願の一実施形態による分散型イメージング・システムのブロック図である。
【図４】本出願の一実施形態による分散画像処理のためのシステム資源の割当てを推奨する方法の流れ図である。
【図５】本出願の一実施形態による割当ての幾つかの例の表を示す図である。
【図６】本出願の一実施形態による分散画像処理システムにおいてシステム資源を割り当てるために構成制御との相互作用（対話）を提供する方法の流れ図である。
【図７】本発明の一実施形態による分散型撮像表示の方法の流れ図である。
【図８】本発明の一実施形態によるクライアントに表示される検査に対する繰り返し式の利用者相互作用を示す方法８００の流れ図である。
【符号の説明】
【００７９】
１００、３００ 医用画像処理のためのシステム
１０２、３０２ サーバ
１０４、３１２ クライアント
１０６、３０５ 通信経路
３０６ 推奨供給器
３０８、３１６ システム資源
３１０ サーバ側モニタ
３１４ クライアント側モニタ
３１８ 構成制御
４００ 分散型網での医用画像処理の方法
【特許請求の範囲】
【請求項１】
サーバ（１０２、３０２）、クライアント（１０４、３１２）及び所定の帯域幅を有する通信経路（１０６、３０５）を備えており、前記サーバ（１０２、３０２）、前記クライアント（１０４、３１２）及び前記通信経路（１０６、３０５）に関連するシステム資源（３０８、３１６）を含んでいる分散型網で通信を行なうステップと、
監視データを生成するように、少なくとも一つの工程モニタ（３１０、３１４）で前記システム資源（３０８、３１６）及び前記帯域幅を監視するステップと、
前記クライアント（１０４、３１２）に表示可能な二次元画像データを形成するように三次元画像データを処理するための前記システム資源（３０８、３１６）の少なくとも一部の割当てを、前記監視データに少なくとも部分的に基づいて推奨するステップと、
を備えた分散型網での医用画像処理の方法（４００）。
【請求項２】
二次元画像データを形成するように三次元画像データを処理する前記処理は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つを含んでいる、請求項１に記載の方法（４００）。
【請求項３】
二次元画像データを形成するように三次元画像データを処理する前記処理は、回転、ズーム、パン、コントラスト調節、輝度調節及び濃淡調節の少なくとも一つを含んでいる、請求項１に記載の方法（４００）。
【請求項４】
二次元画像データを形成するように三次元画像データを処理する前記処理は、前記クライアント（１０４、３１２）での相互作用に応答して実質的に実時間で実行可能である、請求項３に記載の方法（４００）。
【請求項５】
前記少なくとも一つの工程モニタ（３１０、３１４）は、クライアント側モニタ（３１４）及びサーバ側モニタ（３１０）を含んでいる、請求項１に記載の方法（４００）。
【請求項６】
前記割当ては、前記サーバ（１０２、３０２）及び前記クライアント（１０４、３１２）の少なくとも一方により自動的に受け入れられる、請求項１に記載の方法（４００）。
【請求項７】
前記監視データに少なくとも部分的に基づいて前記画像の画質を推奨するステップをさらに含んでいる請求項１に記載の方法（４００）。
【請求項８】
資源を処理するサーバ（１０２、３０２）を含んでおり、三次元画像データを記憶することが可能なサーバ（１０２、３０２）と、
所定の帯域幅を有する通信経路を介した前記サーバ（１０２、３０２）との通信が可能であり、資源を処理するクライアント（１０４、３１２）を含んでおり、前記三次元画像データから形成された二次元画像を表示することが可能なクライアント（１０４、３１２）と、
前記資源を処理するクライアント（１０４、３１２）、前記資源を処理するサーバ（１０２、３０２）及び前記帯域幅に少なくとも部分的に基づいて、前記クライアント（１０４、３１２）に前記画像を表示するために前記資源を処理するサーバ（１０２、３０２）の少なくとも一部及び前記資源を処理するクライアント（１０４、３１２）の少なくとも一部を割り当てることが可能な構成制御（３１８）と、
を備えた医用画像処理のシステム（１００、３００）。
【請求項９】
前記構成制御（３１８）は、前記資源を処理するクライアント（１０４、３１２）、前記資源を処理するサーバ（１０２、３０２）及び前記帯域幅に少なくとも部分的に基づいて、前記クライアント（１０４、３１２）と前記サーバ（１０２、３０２）との間での画像処理の配分についての推奨を供給する推奨供給器（３０６）と相互作用することが可能である、請求項８に記載のシステム（１００、３００）。
【請求項１０】
前記構成制御（３１８）はさらに、前記画像の画質を制御することが可能である、請求項８に記載のシステム（１００、３００）。
【請求項１】
サーバ（１０２、３０２）、クライアント（１０４、３１２）及び所定の帯域幅を有する通信経路（１０６、３０５）を備えており、前記サーバ（１０２、３０２）、前記クライアント（１０４、３１２）及び前記通信経路（１０６、３０５）に関連するシステム資源（３０８、３１６）を含んでいる分散型網で通信を行なうステップと、
監視データを生成するように、少なくとも一つの工程モニタ（３１０、３１４）で前記システム資源（３０８、３１６）及び前記帯域幅を監視するステップと、
前記クライアント（１０４、３１２）に表示可能な二次元画像データを形成するように三次元画像データを処理するための前記システム資源（３０８、３１６）の少なくとも一部の割当てを、前記監視データに少なくとも部分的に基づいて推奨するステップと、
を備えた分散型網での医用画像処理の方法（４００）。
【請求項２】
二次元画像データを形成するように三次元画像データを処理する前記処理は、多断面再構成、最小強度投影、最大強度投影及びボリューム・レンダリングの少なくとも一つを含んでいる、請求項１に記載の方法（４００）。
【請求項３】
二次元画像データを形成するように三次元画像データを処理する前記処理は、回転、ズーム、パン、コントラスト調節、輝度調節及び濃淡調節の少なくとも一つを含んでいる、請求項１に記載の方法（４００）。
【請求項４】
二次元画像データを形成するように三次元画像データを処理する前記処理は、前記クライアント（１０４、３１２）での相互作用に応答して実質的に実時間で実行可能である、請求項３に記載の方法（４００）。
【請求項５】
前記少なくとも一つの工程モニタ（３１０、３１４）は、クライアント側モニタ（３１４）及びサーバ側モニタ（３１０）を含んでいる、請求項１に記載の方法（４００）。
【請求項６】
前記割当ては、前記サーバ（１０２、３０２）及び前記クライアント（１０４、３１２）の少なくとも一方により自動的に受け入れられる、請求項１に記載の方法（４００）。
【請求項７】
前記監視データに少なくとも部分的に基づいて前記画像の画質を推奨するステップをさらに含んでいる請求項１に記載の方法（４００）。
【請求項８】
資源を処理するサーバ（１０２、３０２）を含んでおり、三次元画像データを記憶することが可能なサーバ（１０２、３０２）と、
所定の帯域幅を有する通信経路を介した前記サーバ（１０２、３０２）との通信が可能であり、資源を処理するクライアント（１０４、３１２）を含んでおり、前記三次元画像データから形成された二次元画像を表示することが可能なクライアント（１０４、３１２）と、
前記資源を処理するクライアント（１０４、３１２）、前記資源を処理するサーバ（１０２、３０２）及び前記帯域幅に少なくとも部分的に基づいて、前記クライアント（１０４、３１２）に前記画像を表示するために前記資源を処理するサーバ（１０２、３０２）の少なくとも一部及び前記資源を処理するクライアント（１０４、３１２）の少なくとも一部を割り当てることが可能な構成制御（３１８）と、
を備えた医用画像処理のシステム（１００、３００）。
【請求項９】
前記構成制御（３１８）は、前記資源を処理するクライアント（１０４、３１２）、前記資源を処理するサーバ（１０２、３０２）及び前記帯域幅に少なくとも部分的に基づいて、前記クライアント（１０４、３１２）と前記サーバ（１０２、３０２）との間での画像処理の配分についての推奨を供給する推奨供給器（３０６）と相互作用することが可能である、請求項８に記載のシステム（１００、３００）。
【請求項１０】
前記構成制御（３１８）はさらに、前記画像の画質を制御することが可能である、請求項８に記載のシステム（１００、３００）。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００７−５８８５７（Ｐ２００７−５８８５７Ａ）
【公開日】平成１９年３月８日（２００７．３．８）
【国際特許分類】
【出願番号】特願２００６−２２１４６７（Ｐ２００６−２２１４６７）
【出願日】平成１８年８月１５日（２００６．８．１５）
【出願人】（３９００４１５４２）ゼネラル・エレクトリック・カンパニイ (6,332)
【氏名又は名称原語表記】ＧＥＮＥＲＡＬ ＥＬＥＣＴＲＩＣ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
【公開日】平成１９年３月８日（２００７．３．８）
【国際特許分類】
【出願日】平成１８年８月１５日（２００６．８．１５）
【出願人】（３９００４１５４２）ゼネラル・エレクトリック・カンパニイ (6,332)
【氏名又は名称原語表記】ＧＥＮＥＲＡＬ ＥＬＥＣＴＲＩＣ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
[ Back to top ]