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

Description

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

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

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

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

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

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

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

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

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

従来から、単独のボリュームデータ処理システムにおいてはユーザが作業を中断するときに作業情報をユーザが操作しているコンピュータに保存することにより、前回の状態で作業の再開できるようにできていた。
しかし、前述のようにボリュームデータ処理を複数のコンピュータに分散処理させる場合、作業情報は前回のユーザが操作していたクライアントに保存されているのでユーザは作業を再開するには前回の端末を使用する必要があった。
この場合、例えば、クライアントが長期メンテナンスに入ったり、ユーザが場所を変えて作業を再開しようとしたときに不都合があった。
また、その一方で時間経過と共に画像処理サーバの状態も変化してしまっているので簡単には計算が再開できなかった。
そこで、本発明は、これらの課題を解決するものであり、作業を中断したクライアントとは異なるクライアントにより、前記作業を再開できるボリュームデータ処理システムを提供することを目的としている。

上記課題を解決するため、請求項１記載のボリュームデータ使用の画像処理システムの発明は、ネットワーク接続された複数のノードを有して、ボリュームデータを用いる画像処理システムであって、前記複数のノードからのうち少なくとも１のノードからなるノードの組み合わせが画像処理サーバとしてボリュームデータを用いた画像処理を行う画像処理手段と、前記画像処理システムがクライアントの作業情報を保存する作業情報保存条件の成立を管理する保存条件成立管理手段と、前記作業情報保存条件成立時に前記クライアントの作業状態の作業情報を収集して状態保存サーバに保存する作業情報保存手段と、前記状態保存サーバから前記作業を保存したクライントに対応する作業情報を読み込む作業情報読込手段と、前記複数のノード若しくは前記画像処理システムに新たに追加されたノードから処理代行ノードを選択する処理代行ノード選択手段と、前記処理代行ノードは、前記複数のノード若しくは前記画像処理システムに新たに追加されたノードのうち少なくとも１からなる新たなノードの組み合わせであって、その新たなノードの組み合わせは前記ノードの組み合わせと異なる組み合わせである新たなノードの組み合わせを新たな画像処理サーバとして選択する画像処理サーバ選択手段と、前記新たな画像処理サーバに対して、前記読み込んだ作業情報を用いて作業状態を復元する作業状態復元手段と、前記条件成立時点以降の処理を継続して行う処理継続手段と、を備えたことを特徴としている。

請求項２記載の発明は、請求項１記載のボリュームデータ使用の画像処理システムにおいて、前記作業情報には、ウィンドウ配置、画像種、ユーザの記述したコメント、診断結果、カメラの位置・種類・角度・拡大率、オペレーティングシステムのレベル情報、バージョン情報、マスクおよび領域抽出情報、血管走行などを表現するパス情報、画像解析によって得られる付加情報マップ、同一画像の生成に必要な情報、作業を担当したノードの識別名および処理能力等の情報、作業中画像データの識別名、ユーザ名、作業日時、付加情報、計算の途中経過を示す情報の１つ以上が含まれていることを特徴としている。

請求項３記載の発明は、請求項１又は２記載のボリュームデータ使用の画像処理システムにおいて、前記処理代行ノードが、前記複数のノードに対してデータを保持しているか問い合わせるデータ保持問合せ手段を備え、前記画像処理サーバ選択手段はデータを保持しているノードを前記新たな画像処理サーバに含めることを特徴としている。

請求項４記載の発明は、請求項３項記載のボリュームデータ使用の画像処理システムにおいて、前記新たな画像処理サーバであってデータを保持していない前記新たな画像処理サーバはボリュームデータを画像処理サーバから取得することを特徴としている。

請求項５記載の発明は、請求項１〜４のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記複数の各ノードの現在の負荷状況、過去の実績、ノードのステータス・スペック、ネットワーク上の距離の１つ以上から成る計算資源量を監視するノード計算資源量監視手段を備えたことを特徴としている。

請求項６記載の発明は、請求項１〜５のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記新たな画像処理サーバが、更に、前記新たな画像処理サーバの処理内容を少なくとも一つのノードに割り振ることができることを特徴としている

請求項７記載の発明は、請求項１〜６のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記ボリュームデータ使用の画像処理が、ボリュームレンダリング処理、領域抽出処理、フィルタ処理、雑音除去処理、画像合成処理、流量計算処理、逆投影処理、投影処理、ジオメトリ変換処理のいずれか１つ以上であることを特徴としている。

請求項８記載の発明は、請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記作業情報保存条件が、一定時間命令が存在しなかった場合、一定時間経過毎、前記クライアントが特定の状態になった時、前記状態保存サーバが特定の状態になった時、前記クライアントから明示的に指示があった場合、クライアントを停止させる時、ユーザが前記画像データにかかわる作業を終了した時のいずれか一つ以上であることを特徴としている。

請求項９記載の発明は、請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、システムに優先度の高いクライアントが存在しかつシステムの負荷が高いときにおける優先度の低いクライアントについても前記作業情報保存条件を成立させることを特徴としている。

請求項１０記載の発明は、請求項１〜９のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記作業情報保存条件が成立した時に、クライアントの終了又は／及び画像処理サーバの開放を行うことを特徴としている。

請求項１１記載の発明は、請求項１〜１０のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、処理再開時に前記画像処理サーバが前記データサーバから医療画像データを取得することを特徴としている。
そして、請求項１２記載の発明は、請求項１〜１１のいずれか１項記載のボリュームデータ使用の画像処理システムにおいて、前記クライントと前記複数のノードとの情報のやりとりが直接行われることを特徴としている。

以上説明したように、本発明のボリュームデータ処理システムによれば、作業情報を状態保存サーバに保存することにより、いかなるクライアントからでも作業情報を状態保存サーバから取得することにより、作業状態を回復することができる。
さらに、前回の画像処理サーバの情報を用いつつ必要に応じて画像処理サーバの動的再配置を行うことによって作業状態の回復を効率よく行うことができる。

以下、本発明に係る発明を実施するための最良の形態について、図面を用いて詳細に説明する。
本発明は、例えば、以下のような事例の場合に対処できるものである。
医師Ａが読影室の画像端末で患者Ｆの画像を参照した後、帰宅時間になったのでその作業を途中で終えて画像端末をシャットダウンする。そして、翌日、医師Ａが昨日の読影室の画像端末ではなくて、会議室の画像端末で患者Ｆの画像を参照することになっても、すぐに昨日の作業状態を会議室の画像端末で復元できて、他の医師に患者Ｆの病状を画像を見せながら説明することができるようになる、といった事例である。

図１は上記事例に対処できる本発明に係るボリュームレンダリング画像処理システムの構成図である。
同図に示すように、構成要素は、状態保存サーバ１１、データサーバ１２、画像処理サーバ１３、クライアント１４、画像処理サーバ１５、休止ノード１６から成っている。
状態保存サーバ１１は本発明により設けられたもので保存状態を保存するサーバ、データサーバ１２は膨大な量の画像データを主として保存しているサーバ、クライアント１４はユーザが直接操作する端末、画像処理サーバ１３、１５はボリュームレンダリング画像処理の分散処理を引き受ける計算ノードである。いずれもノードである。休止ノード１６は本システムに属しているノードであるが、ここでは画像処理に関与していない状態にある。なお、ここで使用する「ノード」とは計算単位を意味するコンピュータのことで、複数個のＣＰＵを内蔵するスーパーコンピュータも１ノード、サーバも１ノード、パーソナルコンピュータも１ノード、ノート形パソコンも１ノードということになる。

ここで扱うボリュームデータ使用の画像処理には、ボリュームレンダリング処理、領域抽出処理、フィルタ処理、雑音除去処理、画像合成処理、流量計算処理、逆投影処理、投影処理、ジオメトリ変換処理等が含まれている。

この画像処理システムのノードには、クライアントの作業情報を保存する条件の成立を管理する保存条件成立管理手段と、この条件が成立した時にクライアントの作業状態の作業情報を収集して状態保存サーバに保存する作業情報保存手段と、作業情報を保存したクライントに対応する作業情報を状態保存サーバから読み込む作業情報読込手段と、読み込んだ作業情報を用いて作業状態を復元する作業状態復元手段と、前記条件成立時点以降の処理を継続して行う処理継続手段と、を備えている。

状態保存サーバ１１は通常固定されているが、画像処理サーバ１３、１５とクライアント１４は簡単に立場を入れ替えることができる。また、一つのノードが複数の機能を同時に有することも可能である。例えば、状態保存サーバ１１と画像処理サーバ１３、クライアント１４と画像処理サーバ１５を兼ねることができる。

また、保存する情報は、「作業情報」として、以下の（１）〜（１６）記載の内容を情報として含む。これは、作業中の画像を復元するのに用いる「画像データ」以外の情報である。
（１） ウィンドウ配置、
（２） 画像種（レイキャスト、ＭＰＲ、ＭＩＰ）、
（３） ユーザの記述したコメント、診断結果、
（４） カメラ位置、カメラの種類、角度、拡大率等、
（５） マスク、領域抽出情報、
（６） 血管走行などを表現するパス情報、
（７） 画像解析によって得られる付加情報マップ（例えば、Perfusion ）、
（８） その他、同一の画像を生成するのに必要な情報、
（９） 作業中画像データの識別名
（１０） ユーザ名、
（１１） 作業日時、
なお、上記の他に、付加することが望ましい情報として、
（１２） ＯＳ（オペレーティングシステム）のレベル情報、バージョン情報、
（１３） 作業を担当したノードの識別名、及び処理能力等の情報。
（１４） 付加情報
（１５） 計算の途中経過を示す情報、等が有る。
（１６）患者データ（例えば、患者名、性別、年齢など）

図２は、図１に示すボリュームレンダリング画像処理システムで、作業者（ユーザ）が別の端末を使って前回の作業の再開をする場合の説明図である。
図において、左は前回の作業を行なった図１の場合、右は作業再開の場合を示している。図２の左図において、ユーザがクライアント１４を使ってデータサーバ１２から送信されたデータを基に２つの画像処理サーバ１３、１５を使って分散処理させながら所望のボリュームレンダリング画像処理を実行し、その結果をクライアント１４のディスプレーに表示させて患者の診断を行なっている。上記事例で言えば、医師Ａが読影室の画像端末で患者Ｆの画像を参照している場合である。

次に、作業を中断する事情が生じた（上記事例で言えば、医師Ａの帰宅時間が来た）ので、作業を中断することにする。この場合、保存条件成立管理手段がクライアントの作業情報を保存する条件が成立しているかどうかを管理し、この条件が成立した時に作業情報保存手段に対してクライアントの作業状態の作業情報を収集して状態保存サーバに保存するように命ずる。このようにして、作業を中断する直前に画像処理サーバ１３、１５にある作業情報を本発明によって設けられた状態保存サーバ１１に保存する。作業情報の保存は作業情報がクライアント１４から状態保存サーバ１１に転送されることで行われる。作業情報は上記したように、画像識別名、ジオメトリ情報、画像処理サーバ識別名、領域情報、等である。画像データそのものは保存しない。この点がネットワーク記録システムとの違いである。
そして、前記作業情報保存条件が成立した時にクライアントは作業を終了し、画像処理サーバの開放を行うこととなる。

今回の保存は作業者の指示で行われたが、このような条件をいくつか設定しておき、作業情報保存条件の成立した時にも自動的に行なうようにするとよい。
作業情報保存条件とは、例えば、（１）一定時間命令が存在しなかった場合である。これは、作業者が何らかの理由で端末から離れてしまったものと想定され、今後もしばらくはキー入力がなされない確率が高いので、保存した方が好ましいからである。
（２）一定時間経過毎に保存する。これによって作業履歴が残ってユーザは任意の作業状態に復帰することができるようになる。
（３）クライアント１４が特定の状態になったときである。クライアントの特定の状態とは、
（イ）一定時間経過
（ロ）クライアント終了時
（ハ）ユーザがあらかじめ指定した条件に適合したとき
（ニ）画像抽出処理などの時間のかかる「状態情報を変更する」計算が完了したとき、等が考えられる。
（４）状態保存サーバ１１が特定の状態になったときである。状態保存サーバの特定の状態とは、
（イ）一定時間経過
（ロ）ユーザがあらかじめ指定した条件に適合したとき
（ハ）クライアントとの通信が絶たれたとき、等が考えられる。
（５）クライアント１４から明示的に指示があった場合、
（６）クライアントを停止させる時、
（７）ユーザが前記画像データにかかわる作業を終了した時などである。
（８）システムに優先度の高いクライアントが存在しシステムの負荷が高いときには優先度の低いクライアントの作業情報保存条件が成立する。

次に、作業再開の場合を図２の右で説明する。
上記事例で言えば、翌日、医師Ａが会議室の画像端末で患者Ｆの画像を参照する場合である。まず、作業者（医師Ａ）は所望の端末（会議室の画像端末）で作業を再開する。作業開始端末は図では前回のクライアントであったノード１４ではなくて前回画像処理を行っていたノード１５をクライアント端末として選んでいる。このように任意のノードをクライアント端末として選ぶことができるのが本発明の効果の１つである。このようにして、元の状態に復帰させることができる。
本発明によれば、この場合、作業者がクライアント１４を使って作業情報を状態保存サーバ１１から転送させることで、作業情報読込手段は、作業情報を保存したクライントに対応する作業情報を状態保存サーバから読み込み、作業状態復元手段は、読み込んだ作業情報を用いて作業状態を復元し、その後、処理継続手段は先の条件成立時点以降の処理を継続して行うこととなる。

ここでは、前回のクライアントであったノード１４に新たに画像処理サーバの役割を割り当てることも可能である。本発明によれば、このように、前回画像処理サーバとして使用したノード１５に画像処理サーバの役割を拘泥することがない。各ノードの役割分担は本発明によれば自由になるが、ノードの過去の記録やスペックを考慮して画像処理サーバの再割り当てが行われるのが効率的である。したがって、以前の画像処理サーバ（例えば、ノード１３）が画像データを保持していたら、その画像処理サーバに画像処理を優先させるのがよい。そのために、一つのノードを「処理代行ノード」として選出する。ここで言う、「処理代行ノード」とは、特に、処理再開時にクライアントからの指令を受ける、（１）ただ一つの、（２）動的に定まるノードである。なお、「処理代行ノード」は、通常は新しくクライアントとなったノードで問題ないが、他のノードが担当してもかまわない。この処理代行ノードは、画像処理サーバを選択する画像処理サーバ選択手段と、画像処理サーバに対してデータを保持しているか問い合わせるデータ保持問合せ手段とを備えており、これによってデータ保持問合せ手段が各画像処理サーバに対してデータを保持しているか問い合わせ、その結果、データを保持している画像処理サーバがあれば、画像処理サーバ選択手段はデータを保持しているその画像処理サーバを選択することで、実現できる。
また、処理をすることになった画像処理サーバは、自分の処理が重くなってきたとき、その処理内容を他の画像処理サーバに割り振ることができるようにしておくとよい。
そのために、この画像処理システムには、少なくとも１つのノードに、各ノードの現在の負荷状況、過去の実績、ノードのステータス・スペック、ネットワーク上の距離の１つ以上から成る計算資源量を監視するノード計算資源量監視手段を備えるようにしておき、画像処理サーバに計算資源量監視データを問い合わせる監視データ問合せ手段を備えておくことにより、画像処理サーバは、ノード計算資源量監視手段に対して計算資源量を監視データを問い合わせることで、どのノードを画像処理サーバとして選択するのが最適かを選択することができ、このようにして、画像処理サーバは自己の処理内容を更に少なくとも一つの画像処理サーバに割り振ることができるようになる。

図３は、図１に示すボリュームレンダリング画像処理システムで、２人の作業者（医師）がそれぞれ別の端末から複数の画像処理サーバに分散処理させながら所望のボリュームレンダリング画像処理を実行する場合の説明図である。
図３においてクライアントＡ，Ｂは、図１の場合の休止ノードであったノード１６とクライアントであったノード１４がそれぞれクライアントＡ，Ｂの役割を努める。画像処理サーバは、図１の画像処理サーバであったノード１３、１５の他に、データサーバ１２が画像処理サーバの役割をも兼務する。この場合、画像処理サーバ１５はクライアントＡおよびＢ用に、画像処理サーバ１３はクライアントＡ専用に、データサーバ兼画像処理サーバ１２はクライアントＢ専用としている。
このように、本発明によれば、複数のクライアントが同時に存在することも可能であり、１つのノード（ここでは、データサーバのノード１２）が複数の処理を代行することも可能となる。なお、状態保存サーバ１１はここにおいても固定であるが、必ずしも固定でなくてはいけない、ということではない。

なお、この他に、本発明に関していくつかの処理について説明を追加する。
本実施例では中断が指示されると、関連する画像処理サーバはすべて処理を停止する。処理停止時に画像処理サーバのメモリ上に存在する画像データは、画像処理サーバのＨＤＤに保存するようなことは特に必要ではないが、処理再開時に画像データがメモリ上に残っていれば、この画像処理サーバを選択することでその画像データがそのまま利用できる利点がある。そこで、可能な限り画像データの再利用の促進を図るために、上述のように、処理再開時に、画像処理サーバが画像データを保持しているかを問い合わせるようにすることによって画像処理サーバの割り当てを最適化することができる。
勿論、計算の途中状態は、必ず保存するというものではない。そこで、画像データを保有していない画像処理サーバが選択された場合はデータサーバから再度データを受信することとなる。

各ノードが画像データを破棄するのは各自のメモリが不足するまで遅延できるようにしておくとよい。また、計算の途中状態を保存することはしないこととする。なぜなら、計算の途中状態を保存したほうが効率が良くなる場合もあるが、その効果はわずかだからである。
作業情報はユーザ端末や画像処理サーバから廃棄する必要はないが、必ず保存しなければならないものではない。なぜなら、状態保存サーバ上のデータを原則優先させるからである。

図４は、図２の左図に示すボリュームレンダリング画像処理システムでの作業状態の保存のフローチャートである。
ステップＳ１で、保存条件が満たされているかどうか常にチェックする。チェックを行うのは画像処理サーバ、クライアント、状態保存サーバのいずれであってもよく、システム全体が保有している。
前述の作業情報保存条件管理手段が管理する作業情報保存条件とは、上述の如く、（１）一定時間命令が存在しなかった場合、（２）クライアントが特定の状態になった時、（３）状態保存サーバが特定の状態になった時、（４）クライアントから明示的に指示があった場合、（５）クライアントを停止させる時、（６）ユーザが前記画像データにかかわる作業を終了した時などである。
保存条件が満たされたら、ステップＳ２へ進み、保存命令をクライアントへ通達する。

一方、クライアントは、ステップＳ３で保存命令を受信したら、ステップＳ４で作業情報の収集を行う。
作業情報としては、ウィンドウ配置、画像種、ユーザの記述したコメント、診断結果、カメラの位置・種類・角度・拡大率、オペレーティングシステムのレベル情報、バージョン情報、マスクおよび領域抽出情報、血管走行などを表現するパス情報、画像解析によって得られる付加情報マップ、同一画像の生成に必要な情報、作業を担当したノードの識別名および処理能力等の情報、作業中画像データの識別名、ユーザ名、作業日時、付加情報、計算の途中経過を示す情報などが含まれる。

ステップＳ４での所定の作業情報の収集が終了したらステップＳ５に進み、クライアントは作業情報を状態保存サーバに保存して一連の保存作業を終了する。

図５は、図２の右図に示すボリュームレンダリング画像処理システムでの作業状態の再開（回復）のフローチャートである。
作業者が端末から復元の開始を指示すると、ステップＳ１１でクライアントが状態保存サーバから作業情報を取得する。

ステップＳ１１で状態保存サーバから作業情報を取得し終わると、クライアントは、ステップＳ１２へ進み、システム内のノードのうち画像処理サーバとして割り当てる候補のノードの全てについてその状態および性能を取得する。

ステップＳ１２で画像処理サーバ割り当て候補ノードの全ての状態および性能を取得し終わると、クライアントは、ステップＳ１３へ進み、どのノードあるいはどれとどのノードを画像処理サーバとして割り当て、各ノードにどの処理を行わせるかの決定をする。

ステップＳ１４では、決定された画像処理サーバに対してクライアントから計算に必要な作業情報を転送する。

ステップＳ１５では、画像データが残っているかを調べ、残っていなければ復元作業は終了する。残っていたら、ステップＳ１６へ進む。

ステップＳ１６では、画像処理サーバは残っている画像データを取得して復元作業は終了する。

前記事例の場合、本発明によれば、状態保存サーバを備えたことにより、医師Ａが読影室の画像端末で患者Ｆの画像を参照した後、帰宅時間になったのでその作業状態を各ノードのアクセスできる状態保存サーバに図４の手順で保存することにより、翌日、医師Ａが昨日の読影室の画像端末ではなくて、会議室の画像端末で患者Ｆの画像を参照することになっても、会議室の画像端末を使って図５の手順で状態保存サーバから昨日の作業状態を呼び出すことができる。
本発明に係る状態保存サーバがないと、領域情報や診断コメントなど作成するのに時間のかかる情報を、画像を開くたびに再作成しなければならなくなり、大変面倒であったが、本発明により状態保存サーバを設けることでこのような手間が省けるようになる。
そして、ネットワークを考慮しない既存のスタンドアローンのシステムでは上記情報をローカルのハードディスクに保存していたが、ネットワーク画像処理システムでは特に途中でユーザが端末を変更することがあるので上記情報を状態保存サーバに保存することで上記事例が可能となる。

なお、複数のノードに共通のバックアップサーバを置き、各ノードの処理した結果を共通のバックアップサーバへ保存しておくことにより、他のノードからいつでもその結果を取り出すことができるようにしているシステムが公知であるが、このようなシステムに対して本発明に係るシステムは次の点で異なっている。
本発明に係るシステムは、公知のような単体のマシンでの状態復帰ではなく、システム全体の状態を復元できる点で異なる。これは、公知例では、例えば、通常の文章データサーバではクライアントの状態しか復元せず、例えば、ASP(Active Server Pages)ではサーバの状態しか復元しないのに対して、本発明では、システム全体の状態を復元するため、状態情報は「必須情報」と「推奨情報」との両方を保持することとしている。「必須情報」は画像を表現するのに必須の情報であり、「推奨情報」は画像処理サーバの接続情報などのユーザーが直接管理する必要のない情報で、再接続の際に利用されるものである。

このように、「必須情報」はユーザが明示的に指令を行った情報であり、「推奨情報」は「必須情報」を基にシステムが作成した情報である。そのために「推奨情報」は失われても「必須情報」を基に復元することができる。また、「推奨情報」は「画像処理サーバの構成」のように時間の経過とともに価値が失われるものもあり、「必須情報」はシステムをユーザの思ったとおりの状態に復元するために必要な情報であるので、本発明に係るシステムは「必須情報」のみでも実施可能である。

それに対して「推奨情報」はシステムに対してヒントを与えることによって復元を効率よく行うためのもので、「画像処理サーバの構成」がこれの代表例となる。これは、「ボリュームデータ」は「データサーバ」から再取得可能であるが、過去の「画像処理サーバ」は高い確率で「ボリュームデータ」を既に保有していることが期待できるからである。

上記のように、「作業情報」（状態情報）を「必須情報」と「推奨情報」とに定義した場合、例えば、特にユーザが特定の「画像処理サーバ」を使用することを強く求めた場合は「画像処理サーバの構成」が「必須情報」に含まれる場合もあるので、そのためにどの情報が「必須情報」と「推奨情報」のいずれかに所属されるのかはある程度の流動性があることとなる。

上述の「作業情報」の説明項で列挙した（１）〜（１６）記載の内容のうち、「必須情報」は、（１）ウィンドウ配置、（２）画像種（レイキャスト、ＭＰＲ、ＭＩＰ）、（３）ユーザの記述したコメントや診断結果、（４）カメラ位置・カメラの種類・角度・拡大率等、（５）マスク・領域抽出情報、（６）血管走行などを表現するパス情報、（７）画像解析によって得られる付加情報マップ（例えば、Perfusion ）、（８）その他、同一の画像を生成するのに必要な情報、（９）作業中画像データの識別名、（１０）ユーザ名、（１１）作業日時、である。

一方、「推奨情報」は、（１２）ＯＳ（オペレーティングシステム）のレベル情報やバージョン情報、（１３）作業を担当したノードの識別名及び処理能力等の情報、（１４）付加情報、（１５）計算の途中経過を示す情報、（１６）患者データである。
「必須情報」のうち「作業日時」等を付加することが望ましい情報としているのは、これ自体が診断に必ず必要となる情報ではないが、ユーザが明示的に行った作業の記録であるからである。

クライアントと画像処理サーバとの情報のやりとりは、間に状態保存サーバを置かないで直接やりとりすることとし、状態保存サーバがシステムに介入するのは、状態保存や状態呼び出し処理の時に限っている。なぜならば、クライアントと画像処理サーバとの情報のやりとりは、画像処理に関わることであって状態保存に関わることではないからである。

一般画像処理の実行中は保存条件成立監視手段は監視のためにクライアントと画像処理サーバと多少の情報のやりとりをし、そして、保存条件が成立したときに保存条件成立監視手段は処理に関わっているノード（クライアントと画像処理サーバ）の情報は状態保存サーバに通知する。通知を受けた状態保存サーバはクライアントと画像処理サーバから情報を収集して情報保存処理に入る。これは例えばクライアントの接続が失われた場合でも「必須情報」および「推奨情報」はクライアントと画像処理サーバの双方が保有していれば状態保存が行えるからである。状態保存サーバ自体は状態保存関連の処理以外はしないが、もちろん、状態保存サーバに保存条件成立監視手段が実装されていれば、状態保存サーバとクライアントとのやりとりは行なわれる。

状態保存時にはクライアントのみならず画像処理サーバからも状態情報が手に入るようにしておく。すなわち、「必須情報」および「推奨情報」はクライアント及び画像処理サーバの双方に存在させておき、これによって、いずれか一つの接続が失われても対処できるようにしている。ただし、「推奨情報」に関しては保存することが必須要件ではなく、場合によっては一つのノードにのみ存在しても問題はない。 また、事実上、画像処理を行うためには「必須情報」および「推奨情報」のほとんどをクライアント及び画像処理サーバの双方が直接保有することが必要なので、実装としても自然な形になっているといえる。

状態保存は複数保存することができる。これによって、状態を復帰するときにユーザは複数の状態の中からもっとも好ましいものを選択することができる。これは、それぞれの状態保存時の表示画面の画像をユーザに提示することによって効率よく行うことができる。

・緊急時のスワップアウト：
複数のクライアントが本画像処理システムに接続されているときは、クライアントに優先度情報を持たせることによって、優先度の低いクライアントの状態を保存して画像処理サーバを解放して、優先度の高いクライアントに画像処理サーバを割り当てることができる。
１、優先度の低いクライアントには、優先処理が入ったので状態を保存した旨が通達され、そのユーザにも通知される。
２、優先度の低いクライアントの表示画面自体は変える必要がない。
３、システムの負荷が下がったときに自動的に停止した優先度の低いクライアントの状態を、自動的に復帰する機能があるとさらによい。
このようにすれば、例えば急患が来たような状況で重要なクライアントに多くの資源を割り振ることが容易になる。

・画像処理サーバの解放遅延：
画像処理サーバの解放は、画像処理サーバの解放を前記作業情報保存条件が成立した後に直ちに行うのではなく、画像処理サーバの解放可能フラグを設定するに留め、画像処理サーバの解放を画像処理サーバのメモリなどのリソースが不足するまで遅延させることができるようにするとよい。この場合、特に処理再開が迅速に行えるので有効だからである。

・医療画像データの扱い：
医療画像処理にあっては、特に該当医療画像データがボリュームデータである場合は、保存情報と医療画像データを比較すると、通常、保存情報は小さいデータで医療画像データが巨大なデータとなる。この場合、保存情報に医療画像データを含めず、処理再開時に医療画像データをデータサーバから再取得することによって保存情報を迅速に保存することができ、また状態保存サーバに保存される情報が膨大になることを防ぐことができる。

このように、本発明によれば、作業を中断したクライアントとは異なるクライアントによりボリュームデータ処理作業を再開できるようになる。

本発明に係るボリュームレンダリング画像処理システムの構成図である。 図１に示すボリュームレンダリング画像処理システムで、作業者が別の端末を使って前回の作業の再開をする場合の説明図である。 図１に示すボリュームレンダリング画像処理システムで、２人の作業者（医師）がそれぞれ別の端末から複数の画像処理サーバに分散処理させながら所望のボリュームレンダリング画像処理を実行する場合の説明図である。 図２の左図に示すボリュームレンダリング画像処理システムでの作業状態の保存のフローチャートである。 図２の右図に示すボリュームレンダリング画像処理システムでの作業状態の再開（回復）のフローチャートである。

符号の説明

１１ 状態保存サーバ
１２ データサーバ（兼画像処理サーバ）
１３ 画像処理サーバ
１４ クライアント（画像処理サーバ）
１５ 画像処理サーバ（クライアント）
１６ 休止ノード（クライアント）

Claims (12)

1. ネットワーク接続された複数のノードを有して、ボリュームデータを用いる画像処理システムであって、
   前記複数のノードからのうち少なくとも１のノードからなるノードの組み合わせが画像処理サーバとしてボリュームデータを用いた画像処理を行う画像処理手段と、
   前記画像処理システムがクライアントの作業情報を保存する作業情報保存条件の成立を管理する保存条件成立管理手段と、
   前記作業情報保存条件成立時に前記クライアントの作業状態の作業情報を収集して状態保存サーバに保存する作業情報保存手段と、
   前記状態保存サーバから前記作業を保存したクライントに対応する作業情報を読み込む作業情報読込手段と、
   前記複数のノード若しくは前記画像処理システムに新たに追加されたノードから処理代行ノードを選択する処理代行ノード選択手段と、
   前記処理代行ノードは、前記複数のノード若しくは前記画像処理システムに新たに追加されたノードのうち少なくとも１からなる新たなノードの組み合わせであって、その新たなノードの組み合わせは前記ノードの組み合わせと異なる組み合わせである新たなノードの組み合わせを新たな画像処理サーバとして選択する画像処理サーバ選択手段と、
   前記新たな画像処理サーバに対して、前記読み込んだ作業情報を用いて作業状態を復元する作業状態復元手段と、
   前記条件成立時点以降の処理を継続して行う処理継続手段と、
   を備えたことを特徴とするボリュームデータ使用の画像処理システム。
2. 前記作業情報には、ウィンドウ配置、画像種、ユーザの記述したコメント、診断結果、カメラの位置・種類・角度・拡大率、オペレーティングシステムのレベル情報、バージョン情報、マスクおよび領域抽出情報、血管走行などを表現するパス情報、画像解析によって得られる付加情報マップ、同一画像の生成に必要な情報、作業を担当したノードの識別名および処理能力等の情報、作業中画像データの識別名、ユーザ名、作業日時、付加情報、計算の途中経過を示す情報の１つ以上が含まれていることを特徴とする請求項１記載のボリュームデータ使用の画像処理システム。
3. 前記処理代行ノードは、前記複数のノードに対してデータを保持しているか問い合わせるデータ保持問合せ手段を備え、
   前記画像処理サーバ選択手段はデータを保持しているノードを前記新たな画像処理サーバに含めることを特徴とする請求項１又は２記載のボリュームデータ使用の画像処理システム。
4. 前記新たな画像処理サーバであってデータを保持していない前記新たな画像処理サーバはボリュームデータを画像処理サーバから取得することを特徴とする請求項３項記載のボリュームデータ使用の画像処理システム。
5. 前記複数の各ノードの現在の負荷状況、過去の実績、ノードのステータス・スペック、ネットワーク上の距離の１つ以上から成る計算資源量を監視するノード計算資源量監視手段を備えたことを特徴とする請求項１〜４のいずれか１項記載のボリュームデータ使用の画像処理システム。
6. 前記新たな画像処理サーバは、更に、前記新たな画像処理サーバの処理内容を少なくとも一つのノードに割り振ることができることを特徴とする請求項１〜５のいずれか１項記載のボリュームデータ使用の画像処理システム。
7. 前記ボリュームデータ使用の画像処理は、ボリュームレンダリング処理、領域抽出処理、フィルタ処理、雑音除去処理、画像合成処理、流量計算処理、逆投影処理、投影処理、ジオメトリ変換処理のいずれか１つ以上であることを特徴とする請求項１〜６のいずれか１項記載のボリュームデータ使用の画像処理システム。
8. 前記作業情報保存条件は、一定時間命令が存在しなかった場合、一定時間経過毎、前記クライアントが特定の状態になった時、前記状態保存サーバが特定の状態になった時、前記クライアントから明示的に指示があった場合、クライアントを停止させる時、ユーザが前記画像データにかかわる作業を終了した時のいずれか一つ以上であることを特徴とする請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システム。
9. システムに優先度の高いクライアントが存在しかつシステムの負荷が高いときにおける優先度の低いクライアントについても前記作業情報保存条件を成立させることを特徴とする請求項１〜７のいずれか１項記載のボリュームデータ使用の画像処理システム。
10. 前記作業情報保存条件が成立した時に、クライアントの終了又は／及び画像処理サーバの開放を行うことを特徴とする請求項１〜９のいずれか１項記載のボリュームデータ使用の画像処理システム。
11. 処理再開時に前記画像処理サーバは前記データサーバから医療画像データを取得することを特徴とする請求項１〜１０のいずれか１項記載のボリュームデータ使用の画像処理システム。
12. 前記クライントと前記複数のノードとの情報のやりとりは直接行われることを特徴とする請求項１〜１１のいずれか１項記載のボリュームデータ使用の画像処理システム。

Images