JP2005334110A - ボリュームレンダリング等の画像処理システム - Google Patents

Abstract

【課題】 ネットワーク内の複数のＣＰＵ資源を有効に活用して、ボリュームレンダリングの処理時間を短縮する。
【解決手段】 ＣＰＵ１１１ｍは、手持ちのボリュームレンダリング処理の各々から、それぞれジョブを切り出し、ジョブの処理順序の優先度を決定し、引受側のコンピュータ（２１〜２ｋ）、及び自己と同格の他のコンピュータの各々に対して、処理順に達したジョブの１つを同時に送信した後、自己処理分のジョブの処理に取り掛かる。その後、上記送信したジョブを最も早く処理完了した引受側のコンピュータからの処理結果を受け取ると、引受側の他のコンピュータに対して、ジョブの実行中止指令を発信する。この時点で、依頼すべき手持ちジョブに未完了のものが残っている場合は、前述の同時通信から始まる一連の処理手順を繰り返す。
【選択図】 図２

Description

本発明は、ボリュームデータ使用の画像処理の構成に係り、特に、ネットワークに接続された複数のコンピュータを使用して、ボリュームレンダリング画像処理や領域抽出処理等を行う画像処理システムに関する。

コンピュータを用いた画像処理技術の進展により、人体の内部構造を直接観測することを可能にしたＣＴ（Computed Tomography）、ＭＲＩ（Magnetic Resonance Imaging）の出現は、医療分野に革新をもたらした技術であり、生体の断層画像を用いた医療診断が広く行われている。さらに近年は、断層画像だけでは分かり難い複雑な人体内部の３次元構造を可視化する技術として、例えば、ＣＴ等から得られる物体の３次元デジタルデータから、該データに対応する３次元構造のイメージを直接描画する処理（特にボリュームレンダリングと呼ばれる画像処理）の技術が普及し、医療診断に使用されている。

従来、ボリュームレンダリングの優れた手法として、レイキャスティングが周知である。このレイキャスティングは、仮想始点から物体に対して仮想光線（レイ）を照射し、物体内部からの仮想反射光の画像を仮想投影面に形成することにより、物体内部の３次元構造を透視するイメージ画像を形成する手法である。レイキャスティングについては、例えば、後述する非特許文献１に基本的な理論が述べられている。

ここで、レイキャスティングについて簡単に説明する。
物体の３次元領域の構成単位となる微小単位領域をボクセルと称し、ボクセルの濃度値等の特性を表す固有のデータをボクセル値と称する。物体全体はボクセル値の３次元配列であるボクセルデータで表現される。通常、ＣＴ等により得られる２次元の断層画像データを断層面に垂直な方向に沿って積層し、必要な補間を行うことにより３次元配列のボクセルデータが得られる。

仮想始点から物体に対して照射された仮想光線に対する仮想反射光は、ボクセル値に対して人為的に設定される不透明度（オパシティ値）に応じて生ずるものとする。さらに、仮想的な表面を立体的に陰影付けするために、ボクセルデータのグラディエントすなわち法線ベクトルを求め、仮想光線と法線ベクトルのなす角の余弦から陰影付けのシェーディング係数を計算する。仮想反射光は、ボクセルに照射される仮想光線の強度にボクセルの不透明度とシェーディング係数を乗じて算出される。仮想反射光を仮想光線に沿って積算し、仮想投影面上のすべての座標点について仮想反射光を計算することにより仮想的な３次元イメージの透視画像が形成される。以上の計算を以下では「ボリュームレンダリング処理」と呼ぶことにする。

このようにして得られるボリュームレンダリング画像は、対象ボクセルデータに対して多数のボリュームレンダリング・パラメータを用いて描画される３次元カラー画像である。
ボリュームレンダリング・パラメータには、拡大率、角度、位置等の表示制御情報、色指定情報、ボクセル値とオパシテイ値の対応情報、シェーディング情報、画像フィルタ、画像合成方法、レンダリング手段、光源、時系列及び位相情報、投影方法、表示領域情報、抽出領域情報等が含まれる。これらの情報を以下では「付加情報」と呼ぶことにする。

実際の医療診断においては、医療画像処理システムのユーザは、対象とするボクセルデータに対してボリュームレンダリング・パラメータ（付加情報）の設定を次々と更新しながら、様々な視点からボリュームレンダリング画像を観測していく。例えば、診断対象により適切なオパシティ値が異なるため、ユーザはボクセルデータごとにオパシティ値の設定を行う。また、患部等の注目領域を観察し易いように、観察の邪魔となる周辺組織を除去したり、組織に適切な色を設定したりする。

その他、ユーザは様々な煩雑な作業を行いパラメータを設定する必要がある。適切なパラメータを設定し、診断目的を満たすボリュームレンダリング画像が得られれば、編集作業を終了する。
従来は、貯蔵、計算、表示といったボリュームレンダリングによる画像処理の全工程を、１つ以上のコンピュータで行っており、特に、複数のコンピュータで行う場合は、主として、膨大な計算を必要とする計算資源の分散、並列処理をめぐって様々な工夫がなされている。
また、ボリュームレンダリングによる画像処理の全工程を、複数のコンピュータに分散させる方式も種々提案されている（例えば、特許文献１参照。）。

特開２００３−２３３６００号公報 「Ｉｎｔｒｏｄｕｃｔｉｏｎ Ｔｏ Ｖｏｌｕｍｅ Ｒｅｎｄｅｒｉｎｇ」、Ｂａｒｔｈｏｌｄ Ｌｉｃｈｔｅｎｂｅｌｔ、Ｒａｎｄｙ Ｃｒａｎｅ、Ｓｈａｚ Ｎａｑｖｉ共著、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ Ｐｒｏｆｅｓｓｉｏｎａｌ Ｂｏｏｋｓ（１９９８年発行）

ところが、従来のボリュームレンダリング画像処理システムにあっては、前述のとおり、計算資源の分散、並列処理をめぐって様々な工夫がなされている。
しかし、大規模な計算が必要であるボリュームレンダリングを高精度、リアルタイムで処理するには全計算を１台のコンピュータの計算資源で行うには限度がある。
そこで、複数のコンピュータを使用する場合、ボリュームレンダリングの処理を事前に適当なジョブ（負荷）に区分けして、前記複数のコンピュータに分散処理させる必要があるが、一般に、その管理は非常に困難であり、下手をすると、この管理がオーバーヘッドとなって、システムの効率を低下させかねない。

特に、これら複数のコンピュータの負荷情報や資源使用状況を事前に収集して、公平にジョブを割り振ったとしても、その終了時点を予測することは容易ではない。

本発明はこれらの課題を解決するもので、終了時点を予測する必要のないしかもネットワーク内の複数のＣＰＵ資源を有効に活用して、ボリュームレンダリングの処理時間を短縮することができるボリュームレンダリング画像処理システムを提供することを目的としている。

上記課題を解決するため、請求項１記載のボリュームデータ使用の画像処理システムの発明は、ネットワーク接続された複数のノードを有して、ＣＴ等から得られる物体のボリュームデータを用いて３次元構造のイメージを直接描画する画像処理システムであって、ジョブ依頼側のコンピュータ群の少なくとも１つにおいて、ボリュームデータを用いた手持ちの画像処理のうち依頼すべき各々から複数のジョブを切り出すジョブ切り出し手段と、前記切り出されたジョブの各々の優先度を決定する手段と、前記ジョブの実行依頼を、ジョブ依頼側の他のコンピュータ群及び／又はジョブ引受側のノード群に対して送信する手段と、前記送信されたジョブを最も早く処理完了したノードからの前記ジョブの処理結果を受け取って、該処理結果を検証する手段と、前記最も早く処理完了したノードを除く前記他のノード群に対して、ジョブの実行中止指令を送信する手段と、を備えたことを特徴とする。
このように構成することにより、手持ちのボリュームレンダリング処理を小口のジョブに切り分け、前記ジョブ毎に、ネットワーク内の複数のコンピュータ（自己と同格のジョブ依頼資格を有するコンピュータを含む）に対して、同じジョブを割り当てて処理させ、かつ最も早く処理できたノードの処理結果を受信できるので、手持ちのボリュームレンダリング処理の処理時間を、全体として大幅に短縮できるボリュームレンダリング画像処理システムを実現することができる。
また、ジョブを引き受ける側のノードの実際の負荷状況や、処理能力を考慮することなく、ジョブの実行を依頼することができるので、ジョブを依頼する側のコンピュータがオーバーヘッドとなることを回避することができる。

請求項２記載のボリュームデータ使用の画像処理システムの発明は、ネットワーク接続された複数のノードを有して、ＣＴ等から得られる物体のボリュームデータを用いて３次元構造のイメージを直接描画する画像処理システムであって、ジョブ依頼側のコンピュータ群の少なくとも１つにおいて、ボリュームデータを用いた手持ちの画像処理のうち依頼すべき各々から複数のジョブを切り出すジョブ切り出し手段と、前記切り出されたジョブの各々の優先度を決定する手段と、前記ジョブの実行依頼を、ジョブ依頼側の他のコンピュータ群及び／又はジョブ引受側のノード群に対して送信する手段と、前記送信されたジョブを処理している各ノードのジョブ処理の経過情報を取得する手段と、前記ジョブ処理経過情報取得手段の取得した情報を基に、ジョブを処理しているノードの１つ以上に対して、ジョブの実行中止指令を送信する手段と、を備えたことを特徴とする。
このように構成することにより、最先処理したノードからのジョブの処理結果の受け取りを待たずに処理途中で、特に処理の遅いノードに対して処理を中止させるようにできるので、計算資源の無駄な処理を続行させることがなくなり、効率的となる。

請求項３記載の発明は、請求項１又は２記載のボリュームデータ使用の画像処理システムにおいて、前記ボリュームデータ使用の画像処理は、ボリュームレンダリング処理、領域抽出処理、フィルタ処理、雑音除去処理、画像合成処理、流量計算処理、逆投影処理、投影処理、ジオメトリ変換処理のいずれか１つ以上であることを特徴とする。
このように構成することにより、ボリュームレンダリング処理の限定せず、ボリュームデータを使用する各種の処理を行うようになるので、画像の表示がさらにスピードアップする。

請求項４記載の発明は、請求項１〜３のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ジョブ切り出し手段は、前記ボリュームデータ使用の画像処理に対応する物体の３次元デジタルデータを解析することにより、前記複数のジョブを切り出すことを特徴とする。
このように構成することにより、割り当てるべきジョブと、ＣＴ等から得られる具体的な物体の３次元デジタルデータとの対応を確実にとることができる。

請求項５記載の発明は、請求項１〜４のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ジョブの実行依頼を発信するコンピュータにおいて、前記切り出し手段の実行に先立って、前記ネットワーク接続された他のノードの負荷状況を検証し、前記負荷状況と前記切り出されたジョブの各々の難易度とに基づいて、ジョブの発信先のノードを群別することを特徴とする。
このように構成することにより、ジョブを引き受けるノードの現在の負荷状況と、ジョブの難易度とを勘案して、ジョブを引き受けるノードを群別できるので、手持ちのボリュームレンダリング処理の処理時間を、全体として、より一層、大幅に短縮できるボリュームレンダリング画像処理システムを実現することができる。

請求項６記載の発明は、請求項１〜５のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ジョブの実行依頼を発信するコンピュータにおいて、前記ジョブの一斉発信後に、自己処理分のジョブを実行すること特徴とする。
このように構成することにより、例えば、１サイクル前のボリュームレンダリング処理における処理結果の編集作業（結果を表示するための各種変換処理等）を、ジョブの実行依頼を発信するコンピュータ側で行うことができる。

請求項７記載の発明は、請求項１〜６のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ジョブの実行依頼を受信した前記ノードの各々は、それぞれ他のノードとは独立に、前記ジョブに対応する画像処理を実行し、その結果を、前記ジョブの依頼元のコンピュータに送信することを特徴とする。
このように構成することにより、引き受けたジョブを、結果的に最も早く処理できるノードを利用して当該ジョブを処理させることができるので、ジョブの実行時間を常に最適化することができる。

請求項８記載の発明は、請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ネットワークは、インターネット網、またはインターネット網を含む他の接続用回線によって構成されていることを特徴とする。
このように構成することにより、ボリュームレンダリング画像処理のための広域的なシステムを、オーバーヘッド無しで構築することが可能となり、ボリュームレンダリングの処理時間を、常に、かつ実質的に無制限に短縮することができるボリュームレンダリング画像処理システムを提供することができる。

請求項９記載の発明は、請求項１〜８のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ボリュームデータ使用の画像処理のうちの最終ステップの画像処理をユーザのコンソールだけで行わせることを特徴とする。
このように構成することにより、通常、最終ステップの画像処理はそれほど重い負荷ではなく、しかも最終的にはユーザコンソールのディスプレーに表示させるため早晩各ノードの処理結果が統合されることになるので、早めに統合しておく方がユーザの使い勝手が良くなる。
請求項１０記載の発明は、請求項９記載のボリュームデータ使用の画像処理システムにおいて、前記ボリュームデータ使用の画像処理のうちの最終ステップの画像処理をユーザのコンソールのＧＰＵ（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内で行わせることを特徴とする。
このように構成することにより、通常、最終ステップの画像処理はそれほど重い負荷ではなく、しかも最終的にはユーザコンソールのディスプレーに画像の表示をさせるため、画像表示を得意とするＧＰＵに任せることにより、迅速な処理が行われることとなる。

以上説明したように、本発明のボリュームレンダリング画像処理システムによれば、手持ちのボリュームレンダリング処理を小口のジョブに切り分け、前記ジョブ毎に、ネットワーク内の複数のコンピュータ（自己と同格のジョブ依頼資格を有するコンピュータを含む）に対して、同じジョブを割り当てて処理させ、かつ最も早く処理できたノードの処理結果を受信できるので、手持ちのボリュームレンダリング処理の処理時間を、全体として大幅に短縮できるボリュームレンダリング画像処理システムを提供することができる。

また、ジョブを引き受ける側のノードの実際の負荷状況や、処理能力を考慮することなく、ジョブの実行を依頼することができるので、ジョブを依頼する側のコンピュータがオーバーヘッドとなることを回避することができる。
また、割り当てるべきジョブと、ＣＴ等から得られる具体的な物体の３次元デジタルデータとの対応を確実にとることができるボリュームレンダリング画像処理システムを提供することができる。

また、ジョブを引き受けるノードの現在の負荷状況と、ジョブの難易度とを勘案して、ジョブを引き受けるノードを群別できるので、手持ちのボリュームレンダリング処理の処理時間を、全体として、より一層、大幅に短縮できるボリュームレンダリング画像処理システムを提供することができる。

また、処理結果の編集作業（結果を表示するための各種変換処理等）を、ジョブの実行依頼を発信するコンピュータ側で行うことができるボリュームレンダリング画像処理システムを提供することができる。

また、引き受けたジョブを、結果的に最も早く処理できるノードを利用して当該ジョブを処理させることができるので、ジョブの実行時間を常に最適化することができるボリュームレンダリング画像処理システムを提供することができる。
また、コンピュータを接続するネットワークを、インターネット網、またはインターネット網を含む他の接続用回線によって構成することができるので、ボリュームレンダリング画像処理のための広域的なシステムを、オーバーヘッド無しで構築することが可能となり、ボリュームレンダリングの処理時間を、常に、かつ実質的に無制限に短縮することができるボリュームレンダリング画像処理システムを提供することができる。

一方、データベースでの分野でも、似たような分散処理を行っている。
データベースの分野ではデータ処理の命令をあるコンピュータに発してから答えが返ってくるまでにどれくらい時間がかかるかは、通常、数秒〜数分のオーダーであり、このようにコンピュータの負荷状態がわかりにくく予測がつかないので、複数のコンピュータに同じ命令を発して最初に帰ってきた解答を採用するというようにしていたのである。

これに対して、医療の画像処理の分野では、画像処理の命令を発すると解答が返ってくるまでの時間は大方予想がつくのである。通常、コンマ何秒〜何秒のオーダーであるので、データベースのように競争させる必要性が元々全くなかったのである。

しかしながら本発明では、敢えて、予想がつく範囲内であってもその範囲内に甘んじて画像処理演算の結果を待つのではなくて、予想がつく範囲内で敢えて競争させて予想がつく範囲内での最先の処理結果を採用するようにしている点が特徴である。このようにすることにより、予想がつく範囲内で待つのではなくて、予想がつく範囲内でさらに画像表示をコンマ何秒でも早くするようにすることができるユーザーの待ち時間を短縮できる便利な画像表示システムとするものである。

データベースとの違いの２つ目は、データベースの場合は処理内容を分割させることができず、したがって全てのコンピューターに必ず同一命令を発するこのになるのであるが、医療の画像処理分野では、各コンピュータの負荷状況を勘案して、１つの画像を得る画像処理を重い演算処理と軽い演算処理とに分けることができる点が特徴である。例えば、１つの表示画像を計算させるのに、単純に上から２／３と後の１／３とに分けてそれぞれの画像処理をさせることもできるし、画像処理の手順を工程で分割させることもできるのである。そして、軽負荷中の複数コンピュータに対しては重い演算処理を競争させ、重い負荷中の複数コンピュータに対しては軽い演算処理を競争させるようにすればよい。
あるいは、画像処理演算を軽・中・重の３つ以上の工程に分けて、それぞれを競争させることもできる。このように１つの画像処理を重い演算処理と軽い演算処理とに分けることができる点が、同一命令しか発せられないデータベースにはない特徴である。

また、分割については、ボリュームレンダリング以外の画像処理分野では処理内容が極めて軽いので分割するとかえって能率が落ちるため、画像処理内容をわざわざ分割するといったことを行う必要性がなかった。ボリュームレンダリングといった重い処理の場合に分割を採用することでしかも競争させることで初めて意義が出るのである。

以下、本発明に係る発明を実施するための最良の形態について、図面を用いて詳細に説明する。

図１は、本発明の実施形態に係るボリュームレンダリング画像処理システムのネットワーク構成を示すグラフである。
同図に示すように、本実施形態に係るボリュームレンダリング画像処理システムのネットワーク構成は、ボリュームレンダリング処理を切り分けて得られるジョブの依頼側として、ノード１１〜１ｎを含み、このジョブの引受側として、ノード２１〜２ｋを含む。これらのノードの各々は、ネットワークにより、他のノードと互いに通信可能に接続されている。なお、ここで使用する「ノード」とは計算単位を意味するコンピュータのことで、複数個のＣＰＵを内蔵するスーパーコンピュータも１ノード、サーバも１ノード、パーソナルコンピュータも１ノード、ノート形パソコンも１ノードということになる。
ノード１１〜１ｎは互いに対等の関係を有する。また、ノード２１〜２ｋは互いに対等の関係を有する。

図２は、本発明の実施形態に係るボリュームレンダリング画像処理システムの全体構成を示す構成図である。
同図に示すボリュームレンダリング画像処理システムの全体構成は、図１に示すネットワーク構成と対応するものである。
同図に示すように、本実施形態に係るボリュームレンダリング画像処理システムは、ボリュームレンダリング処理を切り分けて得られるジョブの依頼側として、コンピュータ１１〜１ｎを具備し、このジョブの引受側として、ノード２１〜２ｋを具備する。

これらノードの各々は、通信ネットワーク１０に接続され、通信ネットワーク１０を介して他のノードと通信可能に構成されている。
通信ネットワーク１０は、インターネット網、またはインターネット網を含む（インターネット網を接続する）他の接続用回線によって構成することができる。
前記インターネット網を接続する他の接続用回線としては、公衆回線、ＩＳＤＮ回線、パケット通信回線、フレームリレー回線、ＡＴＭ回線、専用回線、ＡＤＳＬ回線、ＰＨＳ回線、光通信ケーブル回線を利用することができる。また、ＣＡＴＶ等の今後普及する回線であってもインターネットが利用できる仕様の回線であれば利用可能である。

なお、通信ネットワーク１０がインターネット網を含む場合は、本発明に係るボリュームレンダリング画像処理システムは、グリッドコンピューティングシステムの新規方式となる。

図３は、本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの構成を示す構成図である。
図３では、図２に示すジョブ依頼側の任意のコンピュータ１ｍの構成を示すが、ジョブ依頼側の他のコンピュータの構成も、コンピュータ１ｍの構成と同じである。

同図に示すジョブ依頼側のコンピュータは、全体を制御すると共に自己処理分のジョブを処理する主制御部１１ｍと、一般的な業務に使用する業務用ＤＢ（データベース）１２ｍと、他ノードの管理に必要な情報を記録する管理用ＤＢ１３ｍと、ＣＴ等から得られる物体の３次元デジタルデータを格納する画像データＤＢ１４ｍとを備えて構成される。

主制御部１１ｍは、全体を制御するＣＰＵ１１１ｍと、物体の３次元デジタルデータ等を読み込むＲＡＭ１１２ｍと、ルーター機能を有する回線制御部１１３ｍと、通信機能を有する通信制御部１１４ｍと、各データベースを制御するＤＢ管理部１１５ｍと、画像データ等を表示する表示部１１６ｍと、操作情報等を入力するための入力部１１７ｍと、ＣＰＵ１１１ｍと他の構成要素との間の指令及びデータの伝達を行うコモンバス１１０ｍと、ＤＢ管理部１１５ｍと各データベースとの間の制御信号及びデータの伝達を行う入出力バス１２０ｍとを具備する。

ＲＡＭ１１２ｍは、画像データＤＢ１４ｍ等から読み込まれた物体の３次元デジタルデータ等を格納し、必要に応じてＣＰＵ１１１ｍに供給する。
回線制御部１１３ｍは、通信ネットワーク１０（図２）に接続するためのものであり、具体的には、デジタル終端接続装置（ＤＳＵ）や侵入防止用のファイアウォールアプリケーションを実装したルータなどを備えて構成することができる。

通信制御部１１４ｍは、他ノードとの通信処理を行う。なお、この通信制御部１１４ｍは、例えば、インターネット上の時刻同期用のＮＴＰ（Network Time Protocol）サーバや、分散ファイルシステム用のＮＦＳ（Network File System)サーバなどを備えることができる。通信制御部１１４ｍは、さらに、暗号化データ転送用の暗号化通信プロトコルを保持し、暗号化通信サービスを実行することができる。
ＤＢ管理部１１５ｍは、ＣＰＵ１１１ｍからの指令により、業務用ＤＢ１２ｍ、管理用ＤＢ１３ｍ、画像データＤＢ１４ｍを制御し、これらのデータベースに格納されているデータをＣＰＵ１１１ｍに入出力する。

表示部１１６ｍは、ＣＰＵ１１１ｍからの指令とデータ供給により、物体の３次元デジタルデータに対応する３次元構造のイメージ等を表示する。
入出力手段１１７ｍは、ユーザが、ボリュームレンダリング処理や表示に必要な指令等を入力するために使用される。
図４は、本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ受取側のノードの構成を示す構成図である。
図４では、図２に示すジョブ受取側の任意のノード２ｉの構成を示すが、ジョブ受取側の他のノードの構成も、ノード２ｉの構成と同じである。

同図に示すジョブ受取側のノードは、全体を制御すると共に受け取ったジョブを処理する主制御部１１ｍと、一般的な業務に使用する業務用ＤＢ（データベース）２２ｉと、受け取ったジョブの処理に必要な情報を記録する処理用ＤＢ２３ｉと、ＣＴ等から得られる物体の３次元デジタルデータを格納する画像データＤＢ２４ｉとを備えて構成される。なお、画像データＤＢ２４ｉはデータが多い場合、１個のみ設置し、これをすべてのノードが共用して用いるようにすることが推奨される。

主制御部２１ｉは、全体を制御するＣＰＵ２１１ｉと、物体の３次元デジタルデータ等を読み込むＲＡＭ２１２ｉと、ルーター機能を有する回線制御部２１３ｉと、通信機能を有する通信制御部２１４ｉと、各データベースを制御するＤＢ管理部２１５ｉと、画像データ等を表示する表示部２１６ｉと、操作情報等を入力するための入力部２１７ｉと、ＣＰＵ２１１ｉと他の構成要素との間の指令及びデータの伝達を行うコモンバス２１０ｉと、ＤＢ管理部２１５ｉと各データベースとの間の制御信号及びデータの伝達を行う入出力バス２２０ｉとを具備する。

ＲＡＭ２１２ｉは、画像データＤＢ２４ｉ等から読み込まれた物体の３次元デジタルデータ等を格納し、必要に応じてＣＰＵ２１１ｉに供給する。
回線制御部２１３ｉは、通信ネットワーク１０（図２）に接続するためのものであり、具体的には、デジタル終端接続装置（ＤＳＵ）や侵入防止用のファイアウォールアプリケーションを実装したルータなどを備えて構成することができる。

通信制御部２１４ｉは、他ノードとの通信処理を行う。なお、この通信制御部２１４ｉは、例えば、インターネット上の時刻同期用のＮＴＰ（Network Time Protocol）サーバや、分散ファイルシステム用のＮＦＳ（Network File System)サーバなどを備えることができる。通信制御部２１４ｉは、さらに、暗号化データ転送用の暗号化通信プロトコルを保持し、暗号化通信サービスを実行することができる。

ＤＢ管理部２１５ｉは、ＣＰＵ２１１ｉからの指令により、業務用ＤＢ２２ｉ、管理用ＤＢ２３ｉ、画像データＤＢ２４ｉを制御し、これらのデータベースに格納されているデータをＣＰＵ２１１ｉに入出力する。
表示部２１６ｉは、ＣＰＵ２１１ｉからの指令とデータ供給により、物体の３次元デジタルデータに対応する３次元構造のイメージ等を表示する。
入出力部２１７ｉは、ユーザが、ボリュームレンダリング処理や表示に必要な指令等を入力するために使用される。

なお、ＤＢ管理部２１５１〜ＤＢ管理部２１５ｉ〜ＤＢ管理部２１５ｎには、事前に同じデータ（即ち、ＣＴ等から得られる物体の３次元デジタルデータ）が格納されるが、読み取り時の競合を避けるためにデータベースを共有化しないことが望ましい。
以下、本発明の実施形態に係るボリュームレンダリング画像処理システムの動作を説明する。

〔動作例１〕
この動作例は、依頼するジョブの難易度や、引受側のノードの負荷等を考慮しないで、ジョブを引受側のノードに対して対等に割り当てる場合の動作例である。
ＣＰＵ１１１ｍは、この場合、依頼すべき手持ちのボリュームレンダリング処理の各々から、それぞれジョブを切り出し、ジョブの優先度（処理順序の優先度）を決定する。この時、必要に応じて、画像データＤＢ１４ｍから前記ボリュームレンダリング処理に対応するデータを、ＲＡＭ２１２ｉに順次に読み込んで、分析する。

次に、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータ（すなわち、クライアント）の各々に対して、処理順に達したジョブの１つの実行依頼を同時の通信により送信した後、自己処理分のジョブの処理に取り掛かる。この時、画像データＤＢの前記ジョブに対応するデータを、ＲＡＭ１１２ｍに読み込んで、参照する。自己処理分のジョブの処理が完了すると（必要ならば待機し）、上記送信したジョブを最も早く処理完了した引受側のノードからの処理結果を受け取る。
このように、クライアント（ユーザ）は複数存在することが可能であり、本発明の場合、他のクライアントを計算ノードとして使用させることが可能である。

受け取ったジョブの処理結果を検証し、問題がなければ、上記ジョブを引き受けた自己と同格の他のコンピュータの各々、及び上記ジョブ引受側の他のノードに対して、ジョブの実行中止指令を送信する。
この時点で、ＣＰＵ１１１ｍは、依頼すべき手持ちジョブは全て完了したか否かを検証し、依頼すべき手持ちジョブに未完了のものが残っている場合は、前述の処理順に達したジョブの１つを同時に通信することで始まる一連の処理を繰り返す。

〔動作例２〕
この動作例は、依頼するジョブの難易度や、引受側のノード群の負荷等を考慮して、ジョブを、引受側の１以上のノード群に対して割り当てる場合の動作例である。
ＣＰＵ１１１ｍは、この場合、依頼すべき手持ちのボリュームレンダリング処理の各々から、それぞれジョブを切り出すと共に、この切り出されたジョブの優先度（処理順序の優先度）を決定する。この時、必要に応じて、画像データＤＢ１４ｍから前記ボリュームレンダリング処理に対応するデータを、ＲＡＭ２１２ｉに順次に読み込んで、分析する。

優先度の中味は、発注（クライアント）側が画像処理の内容に付ける優先度と受注側（各計算ノード）の負荷状況・過去の履歴に応じて画像処理を行わせる優先度とが含まれている。
負荷状況による優先度とは、各ノードの負荷状況に基づいて軽い負荷中のノード群に対しては重い画像処理命令を発し、重い負荷中のノード群に対しては軽い画像処理命令を発するようにすることである。各ノードは共通のジョブ管理部に自己の処理能力を登録しておくと共に、現在の処理内容を逐次報告しておく。
クライアントは各ノードに画像処理発注するときにジョブ管理部にアクセスして各ノードの処理能力と現在の処理内容を知ることができ、これに基づいて画像処理の分割等と依頼すべき複数ノードの選択をすることができる。
過去の履歴による優先度とは、過去の履歴に基づいてある画像処理が得意なノード群に対してそれに向いた命令を発し、他の画像処理が得意なノード群に対してはそれ用の命令を発するようにすることである。ある画像処理が得意なノードとは、メモリはあまり使用せずに高速演算が得意なノードもあれば、演算は遅いがメモリをたくさん使う処理が得意なノードもあり、既にたくさんのボリュームデータを揃えているため改めて膨大なデータをもはや要求する必要のないノード等である。

次に、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータの負荷情報を収集し、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータを、引受可能なジョブ毎に群分けし、この群別されたノードの各々に対して、上記切り出され、かつ処理順序に達したジョブの内から、相当するジョブを割り当てる。

次に、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータの各々に対して、上記の割り当てたジョブの実行依頼を、それぞれ同時に送信した後、自己処理分のジョブの処理に取り掛かる。この時、画像データＤＢの前記ジョブに対応するデータを、ＲＡＭ２１２ｉに読み込んで、参照する。自己処理分のジョブの処理が完了すると（必要ならば待機し）、上記送信したいずれかのジョブを最も早く処理完了した引受側のノードからの処理結果を受け取る。

受け取ったジョブの処理結果を検証し、問題が無ければ、上記ジョブを引き受けた自己と同格の前記他のコンピュータの各々、及び上記ジョブを最も早く処理し終えた上記ジョブ引受側のノードと同じ群に属する他のジョブ引受側のノードの各々に対して、当該ジョブの実行中止指令を送信する。
この時点で、ＣＰＵ１１１ｍは、依頼すべき手持ちジョブは全て完了したか否かを検証し、依頼すべき手持ちジョブに未完了のものが残っている場合は、前述の他のノードの負荷情報から始まる一連の処理を繰り返す。

なお、前述の〔動作例１〕及び〔動作例２〕における同時の通信手段として、通信ネットワーク１０に固有のブロードキャスト手段等を使用することが可能である。
また、上記ジョブを引き受けたノードの各々は、それぞれ独立に、画像データベース２４から、断層面に垂直な方向に沿って積層された２次元の断層画像データをＲＡＭ２１２に読み出し、必要な補間を行うことにより、３次元配列のボクセルデータを得て、ジョブの依頼元のコンピュータに送信するものとする。

この時、現在のサイクルのボクセルデータの計算処理と、次のサイクルのための２次元断層画像データの読み込みとは、それぞれ別タスクで起動させ、かつ両者に並列動作をとらせることにより、処理時間を短縮することができる。ちなみに、このサイクルの周期は、ＲＡＭ２１２の容量で決定されるが、２次元断層画像データの、ＲＡＭ２１２における読み込み領域を、ダイナミックリロケーションさせることにより、実質的に無限長とすることも可能である。

画像処理を分割して競争させるか、分割せずに競争させるかの判断基準は、画像処理を分割して再び統合させるという処理自体が複雑なので、かかる複雑な処理を介しても処理時間の短縮ができるのであれば分割にし、逆に極めて軽い簡単な画像処理の場合は分割せずに競争させるのがよい。

図５は、本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの１例としての動作を示すフローチャートである。
以下、図１〜４を参照しながら、図５に示すフローチャートを使用して本実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの１例としての動作を説明する。
同図に示すジョブ依頼側のコンピュータの動作は、依頼するジョブの難易度や、引受側のノードの負荷等を考慮しないで、ジョブを引受側のノードに対して対等に割り当てる場合の動作を示す。

まず、ＣＰＵ１１１ｍは、依頼すべき手持ちのボリュームレンダリング処理の各々から、それぞれジョブを切り出すと共に、この切り出されたジョブの優先度（処理順序の優先度）を決定する（ステップＳ１）。
次に、ＣＰＵ１１１ｍは、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータの各々に対して、処理順に達したジョブの１つの実行依頼を同時に送信する（ステップＳ２）。
次に、ＣＰＵ１１１ｍは、自己処理分のジョブを処理する（ステップＳ３）。

その後、ＣＰＵ１１１ｍは、上記送信したジョブを最も早く処理した引受側のノードからの処理結果を受け取る（ステップＳ４）。
次に、ＣＰＵ１１１ｍは、受け取ったジョブの処理結果を検証する（ステップＳ５）。
次に、ＣＰＵ１１１ｍは、上記ジョブを引き受けた自己と同格の前記他のコンピュータの各々、及び引受側の他のノードに対して、ジョブの実行中止指令を送信する（ステップＳ６）。

次に、ＣＰＵ１１１ｍは、依頼すべき手持ちジョブは全て完了したか否かを検証し、依頼すべき手持ちジョブに未完了のものが残っている場合はステップＳ２に戻る。また、依頼すべき手持ちジョブが全て完了している場合は処理を終了する（ステップＳ７）。
図６は、本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの他の１例としての動作を示すフローチャートである。

以下、図１〜４を参照しながら、図６に示すフローチャートを使用して本実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの他の１例としての動作を説明する。
同図に示すジョブ依頼側のコンピュータの動作は、依頼するジョブの難易度や、引受側のコンピュータ群の負荷等を考慮して、ジョブを、引受側の１以上のノード群に対して割り当てる場合の動作を示す。
まず、ＣＰＵ１１１ｍは、依頼すべき手持ちのボリュームレンダリング処理の各々から、それぞれジョブを切り出すと共に、この切り出されたジョブの優先度（処理順序の優先度）を決定する（ステップＳ２１）。

次に、ＣＰＵ１１１ｍは、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータの負荷情報を収集する（ステップＳ２２）。
次に、ＣＰＵ１１１ｍは、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータを、引受可能なジョブ毎に群分けし、この群別されたノードの各々に対して、相当するジョブを割り当てる（ステップＳ２３）。
次に、ＣＰＵ１１１ｍは、引受側のノード（２１〜２ｋ）、及び自己と同格の他のコンピュータの各々に対して、上記の割り当てたジョブの実行依頼を、それぞれ同時に送信する（ステップＳ２４）。

次に、ＣＰＵ１１１ｍは、自己処理分のジョブを処理する（ステップＳ２５）。
その後、ＣＰＵ１１１ｍは、上記送信したいずれかのジョブを最も早く処理した引受側のノードからの処理結果を受け取る（ステップＳ２６）。
次に、ＣＰＵ１１１ｍは、受け取ったジョブの処理結果を検証する（ステップＳ２７）。
次に、ＣＰＵ１１１ｍは、上記ジョブを引き受けた自己と同格の前記他のコンピュータの各々、及び上記ジョブを最も早く処理した上記引受側のノードと同じ群に属する他の引受側のノードに対して、当該ジョブの実行中止指令を送信する（ステップＳ２８）。

次に、ＣＰＵ１１１ｍは、依頼すべき手持ちジョブは全て完了したか否かを検証し、依頼すべき手持ちジョブに未完了のものが残っている場合はステップＳ２２に戻る。また、依頼すべき手持ちジョブが全て完了している場合は処理を終了する（ステップＳ２９）。
なお、この実施の形態では、システムが処理すべき仕事をボリュームレンダリング画像処理としたが、本発明に係るシステムは、一般に、他の任意の仕事の処理に適用することができる。特に、グリッドコンピューティングの１方式として使用することができる。

また、本発明に係るＣＰＵ１１１ｍ（図３）の処理の少なくとも一部をコンピュータ制御により実行するものとし、かつ、上記処理を、図５，６のフローチャートで示した手順によりコンピュータに実行せしめるプログラムは、半導体メモリを始め、ＣＤ−ＲＯＭや磁気テープなどのコンピュータ読み取り可能な記録媒体に格納して配付してもよい。そして、少なくともマイクロコンピュータ，パーソナルコンピュータ，汎用コンピュータを範疇に含むコンピュータが、上記の記録媒体から上記プログラムを読み出して、実行するものとしてもよい。

以上は、画像処理演算を複数に分割して複数の演算処理を各ノードに競争させるものであったが、本発明はさらに付加的機能として、画像処理が時間的にＡ計算→Ｂ計算→Ｃ計算、・・・といった手順を踏んで最終的な画像が得られるとしたとき、そのうちの最後の画像処理はそれほど重い処理内容ではないので、ユーザのコンソールだけで計算させるようにするものである。

すなわち、クライアントの物理ユーザコンソールに計算の一部を負担可能とさせる。例えば、ボリュームレンダリングで計算上のアフィン計算（一連の画像処理のうち最後の処理）を物理ユーザコンソールに特に負担させることが好ましい。
また、多ビット画像（濃淡９ビット以上の画像）からユーザ提示に適したＷＬ変換とアフィン変換を物理ユーザコンソールに特に負担させることが好ましい。
ユーザインタフェース（ＵＩ）画面に表示するための拡大・縮小・パンといった処理を物理ユーザコンソールに特に負担させるのが好ましい。
また、ＧＰＵが搭載されている場合は、以上の処理を特にＧＰＵに負担させるのが好ましい。ＧＰＵは、Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略語で、汎用のＣＰＵと比較して特に画像処理に特化した設計がなされている演算処理装置で、通常ＣＰＵとは別個にコンピュータに搭載されている。この場合、ＧＰＵには実行時に動的に制御コードを読み込んで処理内容を変更できる機能を備えていることが望ましい。
また、画像以外の付帯情報である、患者名、誕生日、年齢、等といった患者に関する情報を物理ユーザコンソールに特に負担させるのが好ましい。
物理ユーザコンソールはＷｅｂブラウザのプラグイン（ｐｌｕｇ−ｉｎプログラム）であっても構わない。

以上の説明では、画像処理の分散処理のうち、送信されたジョブを最も早く処理完了したノードからのジョブの処理結果を受け取って、該処理結果を検証すると共に、最も早く処理完了したノードを除く他のノード群に対して処理を中止させるようにしているが、最先処理したノードからのジョブの処理結果の受け取りを待たずに、処理途中であったとしても、特に処理の遅いノードに対しては最先処理の可能性が無くなったと判断したら処理を中止させるようにすれば、無駄な処理を続行させることがなくなるので、さらに効率的となる。
このようにするためには、送信されたジョブを処理している各ノードのジョブ処理の経過情報を取得する手段と、前記ジョブ処理経過情報取得手段の取得した情報を基に、ジョブを処理しているノードの１つ以上に対して、ジョブの実行中止指令を送信する手段と、を備えるようにすればよい。

以上はボリュームレンダリングの分散処理についての実施例を説明してきたが、本発明の分散処理は当然のことながらんボリュームレンダリングに限定されるものではなく、ボリュームデータを用いる画像処理一般に適用できることは言うまでもない。例えば、領域抽出(segmentation)、フィルタ処理、雑音除去、画像合成、流量計算(Perfusion)、逆投影、投影、ジオメトリ変換等にも適用でき、特に、領域抽出は、VOI(Volume of Interest)の抽出から、臓器を表現する表面や中心線をボリュームから抽出し、それを利用した描画を行うことによって診断を助けることができるので有効である。

本発明の実施形態に係るボリュームレンダリング画像処理システムのネットワーク構成を示すグラフである。 本発明の実施形態に係るボリュームレンダリング画像処理システムの全体構成を示す構成図である。 本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの構成を示す構成図である。 本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ受取側のノードの構成を示す構成図である。 本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの１例としての動作を示すフローチャートである。 本発明の実施形態に係るボリュームレンダリング画像処理システムのジョブ依頼側のコンピュータの他の１例としての動作を示すフローチャートである。

符号の説明

１０ 通信ネットワーク
１１〜１ｎ ジョブ依頼側のコンピュータ（ノード）
１２，２２ 業務用ＤＢ（データベース）
１３ 管理用ＤＢ
２３ 処理用ＤＢ
１４，２４ 画像データＤＢ
２１〜２ｋ ジョブ引受側のコンピュータ（ノード）
１１０，２１０ コモンバス
１１１，２１１ ＣＰＵ
１１２，２１２ ＲＡＭ
１１３，２１３ 回線制御部
１１４，２１４ 通信制御部
１１５，２１５ ＤＢ管理部
１１６，２１６ 表示部
１１７，２１７ 入力部

Claims (10)

1. ネットワーク接続された複数のノードを有して、ＣＴ等から得られる物体のボリュームデータを用いて３次元構造のイメージを直接描画する画像処理システムであって、
   ジョブ依頼側のコンピュータ群の少なくとも１つにおいて、
   ボリュームデータを用いた手持ちの画像処理のうち依頼すべき各々から複数のジョブを切り出すジョブ切り出し手段と、
   前記切り出されたジョブの各々の優先度を決定する手段と、
   前記ジョブの実行依頼を、ジョブ依頼側の他のコンピュータ群及び／又はジョブ引受側のノード群に対して送信する手段と、
   前記送信されたジョブを最も早く処理完了したノードからの前記ジョブの処理結果を受け取って、該処理結果を検証する手段と、
   前記最も早く処理完了したノードを除く前記他のノード群に対して、ジョブの実行中止指令を送信する手段と、
   を備えたことを特徴とするボリュームデータ使用の画像処理システム。
2. ネットワーク接続された複数のノードを有して、ＣＴ等から得られる物体のボリュームデータを用いて３次元構造のイメージを直接描画する画像処理システムであって、
   ジョブ依頼側のコンピュータ群の少なくとも１つにおいて、
   ボリュームデータを用いた手持ちの画像処理のうち依頼すべき各々から複数のジョブを切り出すジョブ切り出し手段と、
   前記切り出されたジョブの各々の優先度を決定する手段と、
   前記ジョブの実行依頼を、ジョブ依頼側の他のコンピュータ群及び／又はジョブ引受側のノード群に対して送信する手段と、
   前記送信されたジョブを処理している各ノードのジョブ処理の経過情報を取得する手段と、
   前記ジョブ処理経過情報取得手段の取得した情報を基に、ジョブを処理しているノードの１つ以上に対して、ジョブの実行中止指令を送信する手段と、
   を備えたことを特徴とするボリュームデータ使用の画像処理システム。
3. 前記ボリュームデータ使用の画像処理は、ボリュームレンダリング処理、領域抽出処理、フィルタ処理、雑音除去処理、画像合成処理、流量計算処理、逆投影処理、投影処理、ジオメトリ変換処理のいずれか１つ以上であることを特徴とする請求項１又は２記載のボリュームデータ使用の画像処理システム。
4. 前記ジョブ切り出し手段は、前記ボリュームデータ使用の画像処理に対応する物体の３次元デジタルデータを解析することにより、前記複数のジョブを切り出すことを特徴とする請求項１〜３のいずれか１項記載のボリュームデータ使用の画像処理システム。
5. 前記ジョブの実行依頼を発信するコンピュータにおいて、前記切り出し手段の実行に先立って、前記ネットワーク接続された他のノードの負荷状況を検証し、前記負荷状況と前記切り出されたジョブの各々の難易度とに基づいて、ジョブの発信先のノードを群別することを特徴とする請求項１〜４のいずれか１項記載のボリュームデータ使用の画像処理システム。
6. 前記ジョブの実行依頼を発信するコンピュータにおいて、前記ジョブの一斉発信後に、自己処理分のジョブを実行すること特徴とする請求項１〜５のいずれか１項記載のボリュームデータ使用の画像処理システム。
7. 前記ジョブの実行依頼を受信した前記ノードの各々は、それぞれ他のノードとは独立に、前記ジョブに対応する画像処理を実行し、その結果を、前記ジョブの依頼元のコンピュータに送信することを特徴とする請求項１〜６のいずれか１項記載のボリュームデータ使用の画像処理システム。
8. 前記ネットワークは、インターネット網、またはインターネット網を含む他の接続用回線によって構成されていることを特徴とする請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システム。
9. 前記ボリュームデータ使用の画像処理のうちの最終ステップの画像処理をユーザのコンソールだけで行わせることを特徴とする請求項１〜８のいずれか１項記載のボリュームデータ使用の画像処理システム。
10. 前記ボリュームデータ使用の画像処理のうちの最終ステップの画像処理をユーザのコンソールのＧＰＵ（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）内で行わせることを特徴とする請求項９記載のボリュームデータ使用の画像処理システム。

Images