(57)【要約】      （修正有）【課題】Ｘ線ＣＴスキャンによって得られた物体の画像を効率よくクライアントに供給可能な技術の提供。【解決手段】ネットワークを通じて受信したクライアントからの検索要求に応じた閲覧対象の物体を検索モジュールで検索し、対応する物体のＸ線ＣＴスキャンによって得られた複数のスライス画像から各レンダラは３次元モデルを生成する、この３次元モデルからクライアントに送信すべき２次元画像を生成可能である。各レンダラで生成された３次元モデルを一時記憶するメモリと、物体の識別情報とレンダラとの対応関係を記憶する記憶部とを含み、新たな画像生成要求が受け付けられたときに、前記対応関係に基づき、前記新たな画像生成要求に含まれた物体の識別情報に対応するレンダラに当該新たな画像生成要求が供給され、当該レンダラは、メモリに一時記憶された３次元モデルを用いて新たな要求に対応する２次元画像を生成する。【選択図】図１
2014235607.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じて受信されたクライアントからの検索要求に応じた閲覧対象の物体を検索する検索モジュールと、
前記検索モジュールによって検索された物体の識別情報を含む画像生成要求に応じて、当該識別情報に対応する物体のＸ線ＣＴスキャンによって得られた複数のスライス画像から３次元モデルを生成可能であり、且つこの３次元モデルから前記クライアントへ前記ネットワークを通じて送信すべき２次元画像を生成可能な複数のレンダラと、
前記各レンダラで生成された３次元モデルを一時記憶するメモリと、
前記物体の識別情報とレンダラとの対応関係を記憶する記憶部とを含み、
新たな画像生成要求が受け付けられたときに、前記対応関係に基づき前記新たな画像生成要求に含まれた物体の識別情報に対応するレンダラに当該新たな画像生成要求が供給され、当該レンダラは、メモリに一時記憶された３次元モデルを用いて新たな画像生成要求に対応する２次元画像を生成する
サーバシステム。
【請求項２】
前記複数のレンダラの中から前記物体の識別情報に対応する３次元モデルの生成を実行すべきレンダラを決定するロードバランサをさらに含む
請求項１に記載のサーバシステム。
【請求項３】
前記物体は、岩石試料又は堆積物試料を含む
請求項１又は２に記載のサーバシステム。
【請求項４】
ネットワークを通じて受信されたクライアントからの検索要求に応じた閲覧対象の物体を検索するステップと、
検索された物体の識別情報を含む画像生成要求に応じて、複数のレンダラの１つに当該識別情報に対応する物体のＸ線ＣＴスキャンによって得られた複数のスライス画像から３次元モデルを生成させ、且つこの３次元モデルから前記クライアントへ前記ネットワークを通じて送信すべき２次元画像を生成させるステップと、
前記レンダラで生成された３次元モデルを一時記憶するステップと、
前記物体の識別情報とレンダラとの対応関係を記憶するステップと、
新たな画像生成要求が受け付けられたときに、前記対応関係に基づき前記新たな画像生成要求に含まれた物体の識別情報に対応するレンダラが一時記憶された３次元モデルを用いて新たな画像生成要求に対応する２次元画像を生成するために、当該レンダラに当該新たな画像生成要求を供給するステップと
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバシステム，及びプログラムに関する。
【背景技術】
【０００２】
出願人が所有する地球深部探査船「ちきゅう」は、地球環境変動、地球内部構造及び地殻内生物圏の解明を目的として、海底の掘削を行っている。海底を掘削した柱状の地層サンプルは、掘削コア試料と呼ばれている（単に「コア試料」、「コア」とも呼ばれる）。「ちきゅう」船上には、掘削コア試料を分析する装置の一つとして、Ｘ線ＣＴ（Computed
Tomography）スキャナを搭載している。本装置を用いて掘削コア試料をディジタルデー
タ化することによって、コア試料の物性や構造が変化してしまう前に、コア試料の内部を立体的に可視化しディジタルアーカイブとして保存することができる。
【０００３】
掘削コア試料のＸ線ＣＴスキャンデータ（以下、「コアデータ」と称する）を用いて予めコア内部に係る調査を行うことで、実際のコア試料を用いた分析の効率や効果を高めることができる。このような、コアデータの利用促進のため、コアデータをネットワーク上のサーバに配置し、研究者がクライアント端末を用いてサーバにアクセスすることで、コアデータの閲覧とインタラクティブな画像操作を可能とすることが考えられる。
【０００４】
本発明に関連する先行技術として、例えば、以下のような特許文献１〜５に記載された技術がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４３３７９８７号公報
【特許文献２】特許第４６４６２７３号公報
【特許文献３】特開２００８−２８４２９１号公報
【特許文献４】特開２００６−３１４６２６号公報
【特許文献５】特開２００２−３２９１９０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、コアデータを用いた分析には、以下のような問題があった。第１の問題は、コアデータのサイズである。コア試料は、所定長さ（１．５ｍ）で複数のセクションに分割され、セクション毎にコアデータが生成される。コアデータは、医用画像の標準フォーマットであるＤＩＣＯＭ（Digital Imaging and COmmunication in Medicine）に基
づき作成された３次元画像ファイルであり、コアデータのデータ容量は、コアセクション当たり４００メガバイトである。このようなサイズのデータをサーバから大量にダウンロードし、３次元描画を行うには、高速なプロセッサと大容量のメモリが必要となる。換言すれば、クライアント端末として、ハイスペックなハードウェアを備えた情報処理装置（コンピュータ）を使用することが要求される。また、円滑なコアデータのダウンロードのために、広帯域の通信回線が必要となる。
【０００７】
第２の問題は、コアデータに基づく３次元画像を閲覧するためのビューワの問題である。上記のように、コアデータは、ＤＩＣＯＭ画像ファイルである。ＤＩＣＯＭフォーマットのコアデータのファイル（ＤＩＣＯＭファイル）を読み込んで３次元画像を表示するソフトウェア専用ソフトウェア（ビューワ）として、例えば、ＤＩＣＯＭ画像の参照に特化したオープンソフトウェアであるOsiriX（オザイリクス）がある。
【０００８】
しかしながら、OsiriXは、医用のＤＩＣＯＭ画像の描画に特化されたソフトウェアであるため、骨や筋肉、靱帯のような生体組織に対応するＣＴ値（Ｘ線吸収率）に対する描画は可能であるが、コア試料のような、生体組織と異なるＣＴ値を持つ物質に対する色づけ、すなわちコア試料観察に最適な描画設定を行うことはできなかった。また、ＤＩＣＯＭは、医用の画像フォーマット、及び医用通信機器間での通信プロトコルを規定したものであり、一般的なクライアント−サーバ方式（例えば、ＨＴＴＰ（HyperText Transfer Protocol）通信）にそのまま適用可能な仕様を備えていない。
【０００９】
さらに、第３の問題として、サーバは、ネットワークを通じて全世界の研究者をはじめとする関係者に対してコアデータを提供可能に構築されることが想定される。このため、サーバにコアデータの提供要求が集中したり、コア試料間の比較のために或る閲覧者が或る時間内に幾つかのコアデータの提供を交互に繰り返して要求したりすることが想定される。上記のような要求に対して、サーバ側で閲覧者が要求する画像データをいち早く生成し、閲覧者に送信するような機構がなければ、閲覧者に対して適当なコアデータの調査環境を提供することができなかった。
【００１０】
上記した第１〜第３の問題は、Ｘ線ＣＴスキャンデータの利用範囲が医用に特化しており、Ｘ線ＣＴスキャンデータを不特定多数者にネットワークを介して配信することが想定されていなかったことに起因する。当該問題は、コアデータだけでなく、Ｘ線ＣＴスキャンデータに基づく画像を広く配信することに対して提起される問題である。
【００１１】
本発明は、上記の事情に鑑みなされたものであり、Ｘ線ＣＴスキャンによって得られた物体の画像を効率よくクライアントに供給可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の一側面は、ネットワークを通じて受信されたクライアントからの検索要求に応じた閲覧対象の物体を検索する検索モジュールと、
前記検索モジュールによって検索された物体の識別情報を含む画像生成要求に応じて、当該識別情報に対応する物体のＸ線ＣＴスキャンによって得られた複数のスライス画像から３次元モデルを生成可能であり、且つこの３次元モデルから前記クライアントへ前記ネットワークを通じて送信すべき２次元画像を生成可能な複数のレンダラと、
前記各レンダラで生成された３次元モデルを一時記憶するメモリと、
前記物体の識別情報とレンダラとの対応関係を記憶する記憶部とを含み、
新たな画像生成要求が受け付けられたときに、前記対応関係に基づき前記新たな画像生成要求に含まれた物体の識別情報に対応するレンダラに当該新たな画像生成要求が供給され、当該レンダラは、前記メモリに一時記憶された３次元モデルを用いて新たな画像生成要求に対応する２次元画像を生成するサーバシステムである。
【００１３】
また、本発明の他の側面は、コンピュータに上記サーバあシステムにおける処理を実行させるプログラム、又は当該プログラムを記録したコンピュータ読み取り可能な記録媒体であっても良い。
【発明の効果】
【００１４】
本発明によれば、Ｘ線ＣＴスキャンによって得られた物体の画像を効率よくクライアントに供給可能な技術を提供することができる。
【図面の簡単な説明】
【００１５】
【図１】図１は、本発明のコア画像配信システムの構成例を示す図である。
【図２】図２は、検索処理及び画像生成処理の説明図である。
【図３】図３（Ａ）は、検索ＡＰＩへ引き渡されるパラメータとその意味を示す表であり、図３（Ｂ）は、検索ＡＰＩの受信パラメータと返り値とを示す表である。図３（Ｃ）は、検索ＡＰＩに引き渡すパラメータと返り値の具体例を示す。
【図４】図４（Ａ）は、クライアントからレンダラＡＰＩへ送信されるクエリ（画像生成要求（リクエスト））のパラメータを示し、図４（Ｂ）は、クエリに対するレスポンス（応答）としてクライアントに送信されるＪＳＯＮ形式のパラメータを示す。
【図５】図５は、ラウンドロビン方式による負荷分散の説明図である。
【図６】図６は、画像生成に用いるメタデータを示す。
【図７】図７は、描画処理におけるレンダリングの流れを説明する図である。
【図８】図８は、コアと視点の位置関係を説明する図である。
【図９】図９は、クオータニオンに基づく視点の決定を用いた回転の例を示す。
【図１０】図１０は、ＲＧＢ値を示す関数の例を示す。
【図１１】図１１（Ａ）は、色のグラデーション（ヒートマップ）に対してＣＴ値が線形に変化する場合の説明図であり、図１１（Ｂ）は、ユーザが指定した２点に応じてこれらの点間を３次スプライン保管した関数により、ＣＴ値に対する色づけがなされる例を示す。
【図１２】図１２は、α値の関数の例を示す。
【図１３】図１３は、縦方向切断が適用された例を示す。
【図１４】図１４は、コア画像の検索，コア画像の閲覧，及びコア画像に対する各種の操作を行うＷｅｂページの例を示す。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について、図面に基づいて説明する。実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
【００１７】
〔システム構成〕
図１は、本発明のコア画像配信システムの構成例を示す図である。図  において、コア画像配信システムは、コアの２次元画像（以下、「コア画像」と称する）の提供を要求するクライアント端末（以下、「クライアント」と称する）１０と、クライアント１０から受け取る要求に応じた２次元画像の生成及び送信処理を行うサーバシステム（以下、単に「サーバ」と称する）２０とを備えている。
【００１８】
クライアント１０は、例えば、パーソナルコンピュータ（ＰＣ），タブレット端末，スマートフォンである。クライアント１０は、コア画像を閲覧するためのユーザインタフェースを提供するクライアントアプリケーションを備える。
【００１９】
クライアントアプリケーションは、例えば、通常のＰＣが備えるＷｅｂアプリケーションの一つとして提供される。或いは、スマートフォンやタブレット端末が備えるプラットフォーム（例えば、Android）上で動作するアプリケーションとして提供される。クライ
アントアプリケーションは、サーバ２０が備えるレンダラＡＰＩ（アプリケーションプログラミングインタフェース（Application Programming Interface））２１２及び検索Ａ
ＰＩ２１１を利用して、コアの情報や画像を取得することができる。
【００２０】
サーバ２０は、クライアント１０とネットワーク（例えば、インターネット）を介して接続される。サーバ２０は、例えば、クラウド上に置かれた、クライアント１０から要求に応じたコア画像データを生成してクライアント１０へ送信する機能を持つ、単一のコンピュータ（情報処理装置）又は複数のコンピュータの集合体である。
【００２１】
〔サーバ〕
サーバ２０は、図１に示すように、大略して、クライアント１０とのインタフェース機
能を司るゲートウェイ２１と、クライアント１０から要求されたコア画像の生成機能を司るレンダリングエンジン２２と、コア検索用データベース（検索用ＤＢ）２３と、ＤＩＣＯＭファイルサーバ（ＤＩＣＯＭサーバ）２４とを備えている。
【００２２】
クライアント１０が備えるクライアントアプリケーションと、サーバ２０との通信プロトコルは、以下のように形成される。例えば、クライアントアプリケーションからサーバ２０への通信方法は、ＨＴＴＰ（HyperText Transfer Protocol）におけるHTTP GETメソ
ッドを用いる。HTTP GETメソッドでは、“http://URL?パラメータ＝値＆パラメータ値”
のような形式で、単数又は複数のパラメータをサーバに送ることができる。このようなHTTP GETメソッドを用いて、サーバ２０に対し、検索やコア画像生成のクエリ（リクエスト）を送ることができる。
【００２３】
サーバ２０からクライアントアプリケーションへの通信は、例えば、軽量なデータ記述言語であるＪＳＯＮ（JavaScript Object Notation）や、ＸＭＬ（Extensible Markup Language）を用いて実現することができる。すなわち、クライアントアプリケーションは、リクエストに対する結果（応答）は、ＪＳＯＮやＸＭＬ形式で受け取る。
【００２４】
ゲートウェイ２１は、クライアント１０（クライアント１０が備えるアプリケーション）からの要求を受け付けるサーバである。ゲートウェイ２０は、クライアント１０によって利用されるＡＰＩ２１０として、クライアント１０が閲覧を希望するコアを検索するためのリクエスト（検索要求）を受け付ける検索ＡＰＩ２１１と、コア画像を生成するためのリクエスト（画像生成要求）を受け付けるレンダラＡＰＩ２１２とを備えている。
【００２５】
ゲートウェイ２１は、さらに、検索ＡＰＩ２１１から得られた情報に基づいて検索用ＤＢ２３に対する検索処理を行う検索モジュール２１３と、レンダラＡＰＩ２１２からの情報を用いたコア画像生成を制御するレンダラ制御モジュール２１４とを備える。レンダラ制御モジュール２１４は、クライアント１０のリクエストに対応するコア情報と、コア画像に対する操作の情報とを受け取り、レンダリングエンジン２２に含まれたレンダラ２２１にコア画像生成処理を依頼（「要求」、「リクエスト」とも呼ぶ）する。但し、レンダラ２２１の起動制御は、レンダラ制御モジュール２１５が備えるロードバランサ２１５によって行われる。ロードバランサ２１５は、レンダリングエンジン２２を形成する複数のノード２２０の中から、負荷の少ないノード２２０を選択し、選択されたノードで形成されるレンダラ２２１に対して、コア画像生成処理を依頼する。
【００２６】
レンダリングエンジン２２は、複数のノード２２０から形成されており、各ノード２２０上で、画像生成を行うレンダラ２２１が稼働する。各レンダラ２２１は、ＤＩＣＯＭファイルサーバ２４にアクセスすることができ、レンダラ制御モジュール２１４からの依頼に応じたコアデータ（ＤＩＣＯＭファイル）を得ることができる。各ノード２２０は、ローカルメモリ２２２を有している。ローカルメモリ２２２は、コアデータを用いたコア画像生成処理の作業領域、及び生成されたコア画像データの一時的な保管領域として使用される。ローカルメモリ２２２は、「メモリ」の一例である。
【００２７】
上記したゲートウェイ２１が備える機能は、ＣＰＵ，主記憶装置（メインメモリ），補助記憶装置，及び通信インタフェース回路（通信Ｉ／Ｆ）（いずれも図示せず）を備える情報処理装置（コンピュータ）において、例えば、補助記憶装置に記憶（インストール）されたミドルウェア（プログラム）をＣＰＵが主記憶装置にロードして実行することによって実現される。情報処理装置として、例えば、ＰＣや専用又は汎用のサーバマシンを用いることができる。
【００２８】
また、レンダリングエンジン２２は、複数のＣＰＵと、複数の主記憶装置と、１以上の
補助記憶装置とを含む情報処理装置を用いて実現することができる。レンダリングエンジン２２０が備える複数のノード２２１のそれぞれは、レンダリングエンジン２２を実現する情報処理装置に含まれた単数又は複数のＣＰＵと、当該単数又は複数のＣＰＵが使用する主記憶装置によって実現される。ノード２２０を実現する単数又は複数のＣＰＵは、補助記憶装置に予め記憶（インストール）されたプログラムの実行によって、レンダラ２２１の起動・起動停止（削除）を行う。また、ノード２２０が有するローカルメモリ２２２は、ノード２２０を実現する単数又は複数のＣＰＵが使用する主記憶装置、又は補助記憶装置における所定の記憶領域である。
【００２９】
また、レンダリングエンジン２２が備える複数のノード２２０は、上記したＣＰＵを用いた構成に代えて、単数又は複数のＧＰＵ（Graphical Processing Unit）と、単数又は
複数のＧＰＵの動作を制御するＣＰＵとから形成されても良い。このとき、各ＧＰＵが備える複数のプロセッサに対し、複数のノードが割り当てられる（ＧＰＵクラスタが形成される）ようにしても良い。
【００３０】
＜検索処理＞
以下、コアの検索処理の詳細について説明する。コアデータのファイル名は、「航海番号」，「掘削サイト情報」，「ホール番号」，「コア番号」，「ビットタイプ」及び「セクション番号」の組み合わせによって作成されることが決められている。航海番号は、航海プロジェクトの番号であり、掘削サイト及びホール番号は、コアの掘削位置の特定情報である。コア番号は、掘削されたコア試料毎に付けられる連続番号である。ビットタイプは、コア試料の掘削を行ったドリルの識別番号である。セクション番号は、１つのコア試料に対して１．５ｍ間隔で割り振られた連続番号（コアセクションの識別情報）である。
【００３１】
検索処理では、航海番号，掘削サイト番号，ホール番号，コア番号，ビットタイプ及びセクション番号からなる６つのパラメータが順番に選択されることで、コアデータの候補を徐々に絞り込み、検索用ＤＢ２３に登録された膨大な（約４０００）のコアデータの中から、目的のコアデータを特定することができる。
【００３２】
図２は、検索処理及び画像生成処理の説明図である。検索ＡＰＩ２２１は、クライアント１０（クライアントアプリケーション）から、HTTP GETメソッドで、コアの検索要求（リクエスト）を受信する（図２＜１＞）。検索ＡＰＩ２２１は、検索要求に含まれるパラメータを検索モジュール２１３に引き渡す（図２＜２＞）。
【００３３】
検索モジュール２１３は、受け取ったパラメータに基づくクエリ（ＳＱＬ文）を生成し、検索用ＤＢ２３に問い合わせを行う（図２＜３＞）。検索モジュール２１３は、検索用ＤＢ２３から検索結果を受け取って検索ＡＰＩ２１１に渡す（図２＜４＞）。検索ＡＰＩ２１１は、検索結果をＪＳＯＮ形式に加工した後に、返り値としてクライアント１０（クライアントアプリケーション）に送信する（図２＜５＞）。なお、検索用ＤＢ２３は、ゲートウェイ２１を実現する情報処理装置の補助記憶装置に記憶されたＤＢであっても良く、当該情報処理装置から独立した情報処理装置（ＤＢサーバ）であっても良い。
【００３４】
返り値は、クライアント１０から検索ＡＰＩ２１１へ送信されたパラメータによって変化する。パラメータとして航海番号が送信（選択）された場合には、選択された航海番号を有する掘削サイト番号の集合が返り値として返信される。掘削サイト番号の集合から選択された１つの掘削サイト番号がパラメータとしてクライアント１０から検索ＡＰＩ２１１へ引き渡された場合には、航海番号及び掘削サイト番号を持つホール番号の集合が返り値となる。このようにして、ホール番号，コア番号，ビットタイプ，及びセクション番号が、順次パラメータとして引き渡されることで、最終的に１つのコア試料（コアセクション）を特定することができる。６つのパラメータで特定されたコアセクションには、コア
セクションを一意に識別する固有のＩＤ（「コアＩＤ」又は「コア番号」と称する）が割り振られており、検索ＡＰＩ２１１は、コアＩＤを返り値としてクライアント１０に送信する。コアＩＤは、「物体の識別情報」の一例である。
【００３５】
クライアント１０でコアＩＤが受信された場合には、コアＩＤを含むコア画像生成要求（リクエスト）がHTTP GETメソッドを用いてレンダラＡＰＩ２１２に送信される（図２＜６＞）。これによって、サーバ２０での画像生成処理が開始される。具体的には、リクエストは、レンダラ制御モジュール２１４を介してレンダリングエンジン２２に含まれるレンダラ２２１に供給される（図２＜７＞）。レンダラ２２１は、リクエストに応じたコアの２次元画像を生成する。２次元画像の描画結果は、レンダラ制御モジュール２１４及びレンダラＡＰＩ２１２を介してクライアント１０に送信される（図２＜８＞，＜９＞）。このようにして、コアＩＤに対応するコアの２次元画像がレンダリングエンジン２２で生成され、レンダラＡＰＩ２１２を通じてクライアント１０に送信される。このようにして、クライアント１０のユーザは、所望のコアセクションの画像を閲覧することができる。
【００３６】
図３（Ａ）は、検索ＡＰＩ２１１へ引き渡されるパラメータとその意味を示す表であり、図３（Ｂ）は、検索ＡＰＩ２１１の受信パラメータと返り値とを示す表である。図３（Ｃ）は、検索ＡＰＩ２１１に引き渡すパラメータと返り値の具体例を示す。図３（Ａ）〜（Ｃ）によれば、最初に、パラメータを指定しないクエリが送信されると、検索可能な航海番号の集合（３１４，３１５，３１６，３１９）が返り値としてクライアント１０に渡される。
【００３７】
例えば、航海番号“３１５”が選択されると、掘削サイト番号の集合（Ｃ０００１，Ｃ０００２）が返り値としてクライアント１０に渡される。例えば、掘削サイト番号“Ｃ０００１”が選択されると、ホール番号の集合（Ｅ，Ｆ，Ｈ）が返り値としてクライアント１０に渡される。その後、ホール番号“Ｅ”，コア番号“３”，ビットタイプ“Ｈ”及びセクション番号“４”が選択されると、これまでに選択した６つのパラメータで一意に特定されるコアセクションのコアＩＤ（Coreid）が、返り値としてクライアント１０に渡される。
【００３８】
＜レンダラＡＰＩ及びレンダラ制御モジュール＞
次に、レンダラＡＰＩ２１２及びレンダラ制御モジュール２１４の詳細について説明する。図４（Ａ）は、クライアント１０からレンダラＡＰＩ２１２へ送信されるクエリ（画像生成要求（リクエスト））のパラメータを示し、図４（Ｂ）は、クエリに対するレスポンス（応答）としてクライアント１０に送信されるＪＳＯＮ形式のパラメータを示す。クライアント１０におけるユーザの操作に応じて、図４（Ａ）に示すパラメータの値を含むクエリが作成される。
【００３９】
図４（Ａ）に示すように、クエリは、検索ＡＰＩ２１１でクライアント１０に提供されたコアＩＤ（コア番号）を含む。さらに、クエリでは、閲覧を所望するコア画像のビュー情報として、以下のパラメータを指定することができる。但し、常に以下の情報の全てがクエリに含まれる訳ではなく、ユーザの操作に応じたパラメータがクエリに含まれる。
・拡大率
・縦切断の角度
・解像度
・回転方法
・ｘｙｚ方向の回転角度
・コアの上下動
・色の付け方
・ＣＴ値と色の関係を示す組の配列
・ＣＴ値と当過度の関係を示す組の配列
・現在のカメラ座標
・現在のカメラの上方向ベクトル
・マウスの移動ベクトル
・回転角度
【００４０】
一方、クエリに対するレスポンスとして、図４（Ｂ）に示す以下のような情報がＪＳＯＮ形式でクライアント１０に返信される。
・生成されたコア画像のＵＲＬ（Uniform Resource Locator ）
・ＣＴ値のヒストグラムの配列
・１ピクセル当たりの長さ
・現在のカメラ座標
・現在のカメラの上方向ベクトル
【００４１】
レンダラ制御モジュール２１４は、上記したクエリ（リクエスト）をレンダラＡＰＩ２１２から受け取って、クエリに応じたコア画像を生成するノード２２０を特定し、特定されたノード２２０に対して専用のコマンドを与えることで、特定されたノード２２０上で画像生成処理を行うレンダラ２２１が起動する。レンダラ２２１は、ノード２２０に常駐し、クエリ（リクエスト）に応じたコアＩＤで特定されるコア試料（コアセクション）の画像を生成する。
【００４２】
１種類のコア試料に対して１つのレンダラ２２０が起動する。例えば、３種類のコア試料の画像生成が要求された場合には、３つのレンダラ２２０が起動する。このため、複数の種類のコア試料の閲覧を所望するクエリが発生した場合には、複数のレンダラ２２１がノード２２０上で起動する。
【００４３】
レンダラ２２０は、ＤＩＣＯＭファイルサーバ２４からボリュームデータ（２次元スライス画像データ）を読み込んで、３次元モデルを生成してから２次元画像（クライアントに提供されるコア画像）を生成する。このような画像処理によって、ノードには高い負荷がかかるため、複数のノードに対して負荷を分散し、１つのノードに負荷が集中することを回避する。このため、レンダラ制御モジュール２１４は、ロードバランサ２１５を有し、画像処理の負荷分散及び負荷軽減が次のように行われる。
【００４４】
基本的には、ロードバランサ２１５は、いわゆるラウンドロビン方式によって複数のノード２２０に対し、順番にレンダラ２２１を起動させる。図５は、ラウンドロビン方式による負荷分散の説明図である。図５に示すように、例えば、レンダリングエンジン２２が１６個のノード２２０を備えている場合には、ロードバランサ２１５は、１番目のノード（ノード１）から１６番目のノード（ノード１６）に対し、順番にレンダラ２２１の起動命令を与える。次のリクエスト（クエリ）を受け取った場合には、ロードバランサ２１５は、再び１番目のノード（ノード１）に対してレンダラ２２１の起動命令を与える。このように、ノード１からノード１６までのレンダラ起動が繰り返し行われる。
【００４５】
但し、レンダラ２２１の削除処理（後述）によって、例えば、図５に示したノード３のレンダラ２２１が削除された場合には、ノード３におけるレンダラ２２１の起動数が他のノード２２１よりも一つ少なくなる。このため、負荷がノード間で均等に分散されない。このため、ロードバランサ２１５は、各ノード２２０におけるレンダラ２２１の起動数を監視して、負荷が少ない（レンダラ２２１の起動数が）少ないノード２２０を発見した場合には、当該ノード２２０に対して優先的にレンダラ起動命令を与える。
【００４６】
ところで、レンダラ制御モジュール２１４（ロードバランサ２１５）によって起動した
レンダラ２２１は、画像生成処理を行っていないときには、クエリ（リクエスト）の待ち受け状態で常駐する。この待ち受け状態においても、レンダラ２２１は、ノードのメモリ（ローカルメモリ２２２）の一部を占有し、且つＣＰＵリソースもわずかながら占有する。このため、起動したレンダラの数が或る数を超えると、ノードが高負荷状態となって、画像生成処理の遅延や失敗を招来する虞がある。
【００４７】
このため、レンダラ制御モジュール２１４は、起動中の各レンダラ２２１の状態を監視し、不要なレンダラの削除（終了処理）を行う。例えば、一定時間リクエストを受け付けていないレンダラ２２１が存在する場合には、当該レンダラの削除命令をレンダラ制御モジュール２１４はノード２２０に与える。
【００４８】
レンダラ制御モジュール２１４は、例えば、定期的又は周期的に、レンダラ監視用のプログラム（スクリプト）を起動して、以下の式（１）に基づく判定処理を、レンダラ毎に行う。
（最後にアクセスされた日時）−（スクリプト実行の日時）＞Ｔ  ・・・式（１）
【００４９】
或るレンダラ２２１について、最後にアクセスされた日時（すなわち、リクエストを受け付けた日時）とスクリプト実行の日時との差分（時間の長さ）が閾値Ｔを上回る場合には、レンダラ制御モジュール２１４は、当該レンダラ２２１の削除命令を、当該レンダラ２２１に対応するノード２２０に与える。このようにして、無駄なレンダラ２２１を削除する。閾値Ｔは、例えば３０分であるが、数分〜数１０分、或いは１〜数時間のような所望の時間を設定することができる。
【００５０】
また、レンダラ制御モジュール２１４は、さらに、レンダラ２２１の総数を監視し、総数が予め定められたレンダラの起動上限数Ｎを上回る場合には、少なくとも１つのレンダラ２２１の削除処理を行う。判定式は以下の式（２）で与えられる。
（起動しているレンダラの総数）＞Ｎ  ・・・式（２）
【００５１】
上記式（２）が満たされる（総数が閾値Ｎを上回る）場合には、レンダラ制御モジュール２１４は、各レンダラ２２１の最終アクセス日時（予め記憶される）を参照し、最終アクセス日時が最も古いレンダラ２２１に対する削除命令を対応するノード２２０に与える。
【００５２】
レンダラ２２１は、単に起動しただけでは、コア画像の生成処理を行わず、リクエストの待ち受け状態となる。レンダラ２２１は、リクエストを受信したときに、リクエストに応じた画像生成処理（画像描画処理）を行う。レンダラ制御モジュール２１４からレンダラ２２１に対するリクエストの送信は、ソケット通信によって行われる。また、レンダラ２２１に対する削除命令（終了メッセージ）の送信も、ソケット通信によって行われる。
【００５３】
ソケット通信では、ＩＰ（Internet Protocol）アドレスとポート番号との組によって
通信相手を選択する。レンダリングエンジン２２に備えられた複数のノード２２０は、それぞれ異なるＩＰアドレスを有している。このため、各ノード２２０におけるノードに異なるポート番号を割り当てることで、正確なソケット通信によるリクエスト送信や終了メッセージ送信を行うことができる。なお、ソケット通信は、通信の正常性を確認するコネクション型通信で行われる。例えばＴＣＰが適用される。
【００５４】
レンダラ２２１の起動状況の記録は「起動ログ」２１４Ａによって行われる。起動ログ２１４Ａは、起動したレンダラ２２１の各種情報を記憶するファイルである。起動ログ２１４Ａは、レンダラ制御モジュール２１４にて保持及び管理される。レンダラ起動時には、レンダラ制御モジュール２１４は、起動ログ２１４Ａに、起動対象のレンダラ２２１に
関する情報を追記し、レンダラ削除時には、削除対象のレンダラ２２１の情報を削除する。レンダラ２２１に関する情報として、コアＩＤ（コア番号），ノード番号，ポート番号，アクセス日時（タイムスタンプ）の項目が記録される。起動ログ２１４Ａは、ゲートウェイ２１として機能する情報処理装置の主記憶装置又は補助記憶装置に記憶される。
【００５５】
コアＩＤとして、リクエストに対応するコアＩＤが記述される。コアＩＤとして、上記したコアデータを特定する６つパラメータがファイルパスとして記述されても良い。また、ノード番号として、レンダラ２２１が起動中のノード番号が記述される。また、ポート番号としてレンダラ２２１の起動時に指定されたポート番号が記述される。そして、アクセス日時として、レンダラ２２１にリクエストが送信された最新の日時が記述される。
【００５６】
レンダラ制御モジュール２１４は、レンダラ２２１を起動する前に、起動ログ２１４Ａに記述されたコアＩＤを参照することで、コアＩＤに対応するレンダラ２２１が既に起動しているか否かを確認する。起動ログ２１４ＡにコアＩＤがない場合には、コアＩＤに対応するレンダラ２２１が起動していないと判定され、レンダラ制御モジュール２１４は、起動ログ２１４Ａに記述されたノード番号の参照結果に基づいて、或るノード２２０に対してレンダラ２２１の起動命令（専用の起動コマンド）を与える。このとき、ロードバランサ２１５が、上記したラウンドロビン方式、及び各ノード２２０におけるレンダラの起動数を考慮して、レンダラ２２１を起動するノード２２０を決定する。さらに、レンダラ制御モジュール２１４は、起動対象のレンダラ２２１に対するポート番号の割り当てを行い、割り当てたポート番号を起動ログ２１４Ａに記述する。
【００５７】
レンダラ２２１が起動すると、レンダラ制御モジュール２１４は、起動ログ２１４Ａに記述されたノード番号及びポート番号で特定されるレンダラ２２１に対して、コア画像生成のリクエストをソケット通信で送信する。或るレンダラ２２１にリクエストが送信される毎に、起動ログ２１４Ａにおける、該当レンダラの最終アクセス日時が更新される。
【００５８】
起動ログ２１４Ａには、各レンダラの最終アクセス日時が記録される。このため、レンダラ制御モジュール２１４は、定期的又は周期的なレンダラ監視において、起動ログ２１４Ａを参照し、差分（式（１）参照）が閾値Ｔを超えるレンダラ２２１に対する削除命令（終了メッセージ）を発行することができる。また、起動ログ２１４Ａにおけるノード番号及びポート番号の記述から、起動中のレンダラ２２１の総数をレンダラ制御モジュール２１４は把握することができる。総数が閾値Ｎを超える場合に、レンダラ制御モジュール２１４はアクセス日時が最古のレンダラ２２１に対する削除処理を行う。
【００５９】
＜レンダリングエンジン＞
次に、レンダリングエンジン２２（レンダラ２２１）の詳細について説明する。レンダラ２２１は、リクエスト中のコアＩＤに対応するＤＩＣＯＭファイルをＤＩＣＯＭファイルサーバ２４から得る。
【００６０】
ＤＩＣＯＭファイルサーバ２４は、ＤＩＣＯＭフォーマットで保存された、コアセクション毎の画像データ（コアデータ）を蓄積したＤＢサーバである。Ｘ線ＣＴスキャンによって得られた１枚の断面画像は「スライス（画像）」と呼ばれ、１つのコアセクションについて得られた複数のスライス画像の集合が、１つのコアＩＤに対応するコアデータとして、ＤＩＣＯＭファイルサーバ２４から２次元画像生成のために取得される。
【００６１】
ＤＩＣＯＭフォーマットの画像ファイルは、メタデータと画像情報とから構成される。メタデータには、撮影対象に対する情報が含まれる。画像情報には、撮影された物体を画像として表すために必要な情報が含まれる。また、ＤＩＣＯＭフォーマットの画像ファイルは、画像のピクセル値がＣＴ値に対応している。ＣＴ値は、Ｘ線の吸収度合いを表現し
た値である。ＣＴ値は、密度と元素番号とに相関した値を採る。具体的には、密度と元素番号とが高い程ＣＴ値は高くなり、密度と元素記号とが低い程ＣＴ値は低くなる、画像のピクセル値がＣＴ値に対応している性質を利用して、ＣＴ値の異なるピクセルに異なる色を割り当てることで、或るＣＴ値に対応する物体を強調表示することができる。
【００６２】
レンダリングエンジン２２は、以下の手順によって、クライアント１０のユーザが閲覧を所望する２次元画像を生成する。
１）初期化処理
２）描画パラメータの受信
３）描画処理
４）描画結果の送信
【００６３】
＜＜１．初期化処理＞＞
レンダラ２２１は，起動時に引数として与えられたパス（コアＩＤのファイルパス）で特定される複数のＤＩＣＯＭファイル（コアＩＤに応じたスライス画像）を、ＤＩＣＯＭファイルサーバ２４から取得する。ＤＩＣＯＭファイルは、上記したように、メタデータと画像情報（画像データ）とを含んでいる。
【００６４】
図６は、画像生成に用いるメタデータを示す。図６の表に示す“ＩNUM” は，ＤＩＣＯＭファイルが何番目のスライス画像に当たるかを意味している。レンダラ２２１は、“ＩNUM”の値を基に複数のスライス画像をソートし、ボリュームデータ（スライス画像の集
合）を作成する。
【００６５】
作成されたボリュームデータは、レンダラ２２１が終了する（削除される）まで、レンダラ２２１のプロセスが保持する。すなわち、ボリュームデータは、レンダラ２２１が描画に利用するローカルメモリ２２２で保存される。このようなボリュームデータの一時記憶によって、同一のコアＩＤに関する新たなリクエストが受信された場合に、作成したボリュームデータを用いた２次元画像の生成を開始することができる。この場合、改めてボリュームデータを作成する場合に比べて、クライアント１０に対する応答時間の短縮化を図ることができる。
【００６６】
＜＜２．描画パラメータの受信＞＞
レンダラ２２１は、起動時に指定されたポート番号をソケットに割り当てて通信相手（レンダラ制御モジュール２１４）からの接続（リクエスト送信）を待ち受ける。レンダラ２２１は、リクエストを受信した場合に、当該リクエストに含まれる視点移動，画像の品質，画像保存先に関する情報に基づく描画を開始する。
【００６７】
＜＜３．描画処理＞＞
レンダラ２２１は、描画処理において、コアの２次元画像を生成するために、以下の処理を行う。
（ａ）視点の決定
（ｂ）ボリュームデータの圧縮
（ｃ）ＣＴ値に対する色の設定
（ｄ）ＣＴ値に対するα値の設定
（ｅ）縦方向切断
【００６８】
図７は、描画処理におけるレンダリングの流れを説明する図である。最初に、レンダラ２２１は、初期化処理において取得した（ローカルメモリ２２２に読み込んだ）ボリュームデータを三次元（３Ｄ） テクスチャデータに変換する。続いて、レンダラ２２１は、
複数枚重ねた長方形ポリゴンに対し、３Ｄテクスチャデータを用いたテクスチャマッピン
グを行うことによって、ボリュームレンダリングを実現する。
【００６９】
具体的には、レンダラ２２１は、図６に示したメタデータを利用して長方形ポリゴンの縦横及び間隔を計算し、実際のコアセクションにおける縦・横・高さの比を保つ。長方形ポリゴンの辺の長さは，ピクセル数とピクセル間隔を用いて，幅PW・SW，高さPH・SHとなる。レンダラ２２１は、長方形ポリゴンの中心をｚ軸が通り、且つｚ軸と長方形ポリゴンとが直交するように、複数の長方形ポリゴンを配置する。このとき、長方形ポリゴンの間隔として、スライスの厚さＴが適用される。デフォルト（初期状態）の視点の座標は、ｙ軸上にあり、ｙ軸の＋方向から原点方向を向いている。なお、視点の上方向はｚ軸の＋方向と一致する。
【００７０】
（ａ）視点の決定
コアを所望の方向から閲覧するために、２種類の視点計算方法を採用されている。１つ目はオイラー角のよる視点の決定であり、２つ目はクオータニオンによる視点の決定である。オイラー角は，x 軸，y 軸，z 軸の回転角度を指定することによる視点の計算法である。図８は、コアと視点の位置関係を説明する図である。コアは円柱状であるため、側面，上面及び底面の閲覧が考慮される。コアの軸に沿った回転によりコアの側面を閲覧することが可能となる。一方、前後方向への回転により底面の閲覧が可能となる。このため、デフォルトの視点をｙ軸上の+から原点とし、回転をｚ軸回転(コア軸回転)，ｘ軸(前後回転) の順序で適用する。
【００７１】
クオータニオンは，回転軸ベクトルと回転角度を指定することによる視点の計算法である。コアを閲覧するためには前述の２軸考慮すれば十分であったが，ここにｙ軸を加えて３軸を指定した時の視点がどこに移動するかは、ユーザにとってイメージしにくい。その解決案がクオータニオンによる視点の決定であり、画像平面に対するマウスドラッグを用いた回転操作を想定している。この操作法による回転軸ベクトルａは、現在の視線とマウスの移動ベクトルに直交してなおかつコアの描画空間内における原点を通る直線となる。現在の視点位置から原点への単位ベクトルをe = (ex, ey, ez)T 視点の上向きベクトルをu = (ux, uy, uz)T ，画像平面におけるマウスの移動ベクトルをm = (mx, my, 0)T ，マ
ウスの移動ベクトルとx軸のなす角をθとすると、回転軸ベクトルをa = (ax, ay, az)T 
は以下の式で表される。
【００７２】
【数１】
2014235607.tif 000003
【００７３】
現在の空間座標に対してａを軸とした座標変換を適用することにより、新たな視点が決定される。図９は、クオータニオンに基づく視点の決定を用いた回転の例を示す。レンダラ２２１は、上述したような視点を決定するためのパラメータに基づき、生成するコア画像の視点を決定する。
【００７４】
（ｂ）ボリュームデータの圧縮
コアデータの１枚のＤＩＣＯＭファイルに格納されているスライス画像のサイズは、幅５１２ピクセル，高さ５１２ピクセルであり、１ピクセルあたり１６ビットである。また、１つのコアセクションあたりのＤＩＣＯＭファイルの数は、およそ４００〜２５００である。このため、ボリュームデータは大きいもので１Ｇバイトを超えるデータサイズとな
る。描画処理の時間短縮のために，ボリュームデータが圧縮される。
【００７５】
本実施形態では、ボリュームデータの解像度を５段階（データ量1/1, 1/8, 1/64, 1/216, 1/512）用意し、ユーザが品質及び応答速度に応じて選択した解像度で画像が生成される。圧縮の手法として、平均画素法が用いられる。平均画素法では、例えば，3＊3＊3ボ
クセルが1＊1＊1 ボクセルに圧縮されるとき，元のボクセル値の平均値を新たなボクセル値として用いる。平均画素法の適用により、単純にボクセルを間引いた圧縮手法に比べて、粗さを抑えることができる。
【００７６】
（ｃ）ＣＴ値に対する色及び透過の設定
ＣＴ値に対応する色の色づけにおいて、ヒートマップが用いられる。ヒートマップは、値の低いものを青色に、値の高いものを赤色にマッピングするためのマップである。例えば青→水色→緑→黄色→橙→赤のようなグラデーションとなる。ＣＴ値の範囲は、例えば、−１０００〜４０００の値を採ることができる。但し、０以下の値の物質は水より密度の低い液体又は気体であり、通常、コア試料物質の中に殆ど含まれない。このため、コア画像作成に用いるＣＴ値の範囲は、０以上４０００以下とした、ＲＧＢ値は、ＣＴ値v(vmin ≦ v＜ vmax) を用いて、以下の４．４式，４，５式及び４．６式で示すことができ、図１０に示すような関数で表すことができる。
【００７７】
【数２】
2014235607.tif 000004
【００７８】
また、本実施形態では、色付けをＣＴ値に対して線形にするだけでなく、３次スプライン補間を用いた関数によりユーザが色付けを変化させることができる。図１１（Ａ）は、色のグラデーション（ヒートマップ）に対してＣＴ値が線形に変化する場合の説明図であり、図１１（Ｂ）は、ユーザが指定した２点に応じてこれらの点間を３次スプライン補間した関数により、ＣＴ値に対する色づけがなされる例を示す。レンダラ２２１は、ユーザが指定した曲線（関数）を示す情報（リクエストに含まれる）を用いて、各ピクセルのＣＴ値に対する色を決定し、ピクセル（ボクセル）に対する色づけを行う。
【００７９】
（ｄ）ＣＴ値に対するα値の設定
クライアントアプリケーションは、ＣＴ値とα値（透過度）の組列を指定し、点列を線形補間することによりα値関数を生成する。例えば、図１２に示すようなα値の関数を用いることによって、コアの表面を覆っていたＣＴ値の低いボクセルが透過され、内側の構造を閲覧することが可能となる。レンダラ２２１は、ユーザが指定したα値の関数を示す情報（リクエストに含まれる）を用いて、各ピクセル（ボクセル）の透過度を決定する。
【００８０】
（ｅ）縦方向切断
縦方向の切断は、例えばOpenGL のクリッピング関数を用いて実現される。クリッピン
グ処理は、以下の４．７式を満たす領域を描画しない。縦方向切断を実現するには、z 軸に水平で原点を通る平面を指定することで、縦方向切断を実現することができる。当該平面の方程式は、角度θを用い、以下の４．８ 式によって求めることができる。図１３は
、縦方向切断が適用された例を示す。
【数３】
2014235607.tif 000005
【００８１】
以上のようにして、レンダラ２２１は、ＤＩＣＯＭファイルサーバ２４から得られたコアＩＤに対応する複数のスライス画像（ボリュームデータ）に対するボリュームレンダリングを行い、３次元モデルデータを生成する。さらに、レンダラ２２１は、上述した（ａ）〜（ｄ）の処理に基づき、３次元モデルの視点決定、ボリュームデータ圧縮、ＣＴ値に対する色づけ及びα値の設定を行う。さらに、レンダラ２２１は、リクエストに応じて（ｅ）に示した縦方向縦断処理を行う。そして、レンダラ２２１は、決定された視点，ＣＴ値に対する色及びα値に従った２次元のカラー画像を、２次元のコア画像として生成する。２次元のコア画像は、例えば、３次元モデルが指定された視点（ビュー）に基づく投影面に投影されたときのコアセクションの２次元画像を所定のビデオメモリ（ビデオＲＡＭ）に書き込むことによって生成される。
【００８２】
そして、レンダラ２２１は、指定された送信ポート（レンダラ制御モジュール２１４）に対して、ソケット通信により、図４（Ｂ）に示したパラメータを含むレスポンス（応答）を送信する。レスポンスは、２次元のコア画像データのＵＲＬ（位置情報），現在の視点位置ベクトル，視点の上向き方向ベクトル，ＣＴ値のヒストグラム，１ピクセルあたりの長さ(mm) を含む。さらに、レスポンスは、描画が正常に終了したか否かを示すＯＫ又
はＮＧの文字列を含むことができる。ヒストグラムはボリュームデータの圧縮時における計算によって得ることができる。1 ピクセルあたりの長さs は、視体積のニアクリップ面の長さをＬ，生成する画像の１辺のピクセル数をＷＷとして4.9 式で計算される。
ｓ＝２Ｌ／ＷＷ・ＰＷ・ＳＷ    ・・・(4.9)
【００８３】
レンダラ制御モジュール２１４は、描画結果のパラメータをレンダラＡＰＩ２１２に引き渡し、レンダラＡＰＩ２１２は、描画結果をＪＳＯＮ形式でクライアント１０に送信する。
【００８４】
上記した描画処理では、レンダラ２２１は、ボリュームレンダリングによって、コアセクションの３次元モデルを生成する。３次元モデルデータは、ボリュームデータと同様に、ローカルメモリ２２２にて、レンダラ２２１の終了まで一時的に保存される。一方、レンダラ制御モジュール２１４は、新たなリクエストを受信した場合には、起動ログ２１４Ａを参照することによって、当該リクエストに対応する起動中のレンダラ２２１を特定することができ、特定したレンダラ２２１に新たなリクエストを送信することができる。レンダラ２２１は、新たなリクエストを受信したときには、ローカルメモリ２２２に記憶されている３次元モデルデータを用いて、上記（ａ）〜（ｅ）に係る処理を行う。これによって、ＤＩＣＯＭファイルサーバ２４へのアクセス及びボリュームデータの作成が省略されるので、２次元のコア画像データを短い時間で生成することができる。すなわち、応答時間の短縮化を図ることができる。
【００８５】
〔クライアント〕
クライアント１０は、クライアントアプリケーションとして、例えば、ビューワ機能を司るＷｅｂブラウザ１１を備える。Ｗｅｂブラウザ１１は、サーバ２０へHTTP GETに基づ
くと通信（例えば、ＨＴＴＰ通信）を行い、サーバ２０に対してクライアント１０のユーザが閲覧を所望するコア画像データの提供要求を送信する。また、Ｗｅｂブラウザ１１は、コア画像データの提供要求に応じてサーバ２０にて生成されたコア画像データを含むファイルを受信し、ファイルに基づくコア画像をディスプレイに表示する。コア画像データを含むファイルは、例えば、ＪＳＯＮ（JavaScript Object Notation）ファイルとして提供される。
【００８６】
クライアント１０は、ＣＰＵと、主記憶装置と、補助記憶装置と、通信Ｉ／Ｆと、入力装置（キーボード，マウス（ポインティングデバイス））と、ディスプレイ装置（いずれも図示せず）を備えて下り、補助記憶装置に記憶（インストール）されたＷｅｂブラウザ１１をＣＰＵが主記憶装置にロードして実行することによって、以下のようなＷｅｂブラウザ１１（クライアントアプリケーション）の機能を実現する。
【００８７】
クライアント１０は、ネットワークを介してサーバ２０が提供するＷｅｂサイトにアクセスすることによって、図１４に示すような、コア画像の検索，コア画像の閲覧，及びコア画像に対する各種の操作を行うＷｅｂページ１００をディスプレイ装置に表示することができる。
【００８８】
Ｗｅｂページ１００の左側は、コア検索のためのユーザインタフェース（ＵＩ）１０１がレイアウトされている。上から順に、航海番号，掘削サイト番号，ホール番号，コア番号，ビットタイプ及びセクション番号の６つのパラメータを入力又は選択するための欄が設けられている。例えば、航海番号に対応するボタンを押すと、航海番号の候補を示すプルダウンメニューが表示され、候補のいずれかをクリックすると、クリックされた航海番号が入力され、且つ航海番号を含む検索クエリがサーバ２０に送信される。その結果、掘削サイト番号に対応するプルダウンメニューに、掘削サイトの候補が選択可能に表示されるようになる。このようにして、掘削サイト番号以降の各パラメータを絞り込むことで、クライアント１０は、閲覧を所望するコアＩＤ（コア番号）をサーバ２０から受信することができる。
【００８９】
コアＩＤが取得されると、コアＩＤのパスを含む画像生成のクエリ（リクエスト）がＷｅｂブラウザ１１からサーバ２０へ送信される。サーバ２０では、上記した手法で、コアＩＤに応じた複数のＤＩＣＯＭファイル（スライス画像）からボリュームレンダリングによって、３次元モデルが生成され、３次元モデルに対するデフォルトの視点，解像度，色づけ，及びα値に従った２次元画像が生成され、リクエストに対するレスポンスがサーバからクライアント１０へ返信される。
【００９０】
レスポンスは、生成された２次元のコア画像のＵＲＬを含んでおり、Ｗｅｂブラウザ１１は、当該ＵＲＬへの自動アクセスによって、２次元画像データを取得し、当該２次元の画像データに基づくコア画像を、Ｗｅｂページ１００の中央に設けられた表示領域１０２に表示する。
【００９１】
Ｗｅｂページ１００の右側には、画像に対する各種の設定を行うためのＵＩが設けられている。ＵＩが操作される毎に、操作の結果に応じたパラメータを含む画像生成のリクエスト（クエリ）がレンダラＡＰＩ２１２に送信され、リクエストに応じた画像生成が行われる。そして、画像生成の結果（２次元画像）がクライアント１０に送信され、操作結果が反映された２次元画像が表示領域１０２に表示される。
【００９２】
具体的には、右側の最上段には、解像度の設定欄１０３と、カラーマップの選択欄１０４とが設けられている。ユーザは、入力装置と、設定欄１０３及び選択欄１０４とを用いて、解像度及びカラーマップを指定することができる。解像度の設定欄１０３の下側には
、表示領域１０２におけるコア画像の移動ボタン１０４が設けられており、コア画像を表示領域１０２にて上方向、下方向へ移動させることができる。移動ボタン１０４の右側には、コア画像の回転角度を設定するための入力欄１０５が設けられており、入力欄１０５への回転角度の入力によって、例えば、コア画像をそのｚ軸周りに回転させることができる。
【００９３】
また、入力欄１０５の右側には、コア画像の拡大・縮小を制御するためのスライドバー１０６が設けられており、スライドバーの移動によって、コア画像の大きさを所望のサイズで表示することができる。さらに、スライドバー１０６の下段には、縦方向切断用の入力欄（ＵＩ）１０７が設けられている。入力欄１０７を用いて、コアの切断平面を指定することで、表示領域１０２に縦方向切断処理が施されたコア画像を表示することができる。
【００９４】
さらに、入力欄１０７の下側には、ＣＴ値とカラーマップとの設定画面（ＵＩ）１０８が設けられている。設定画面には、コア画像の各ピクセル（ボクセル）におけるＣＴ値のヒストグラムが表示される。ユーザは、設定画面１０８の操作により、色づけ対象のＣＴ値の範囲を指定することができる。さらに、カラーマップ（例えばヒートマップ）とＣＴ値との相関を示す関数を当該設定画面１０８で指定することができる。例えば、デフォルト設定である線形を指定可能であるし、或いは、複数の点を指定することで、３次スプライン補間による関数を指定することもできる。
【００９５】
Ｗｅｂページ１００の右側の最下段には、透明度（透過度）、すなわちα値とＣＴ値との関連を定義するためのＵＩ１０９が設けられている。α値（０≦α≦１）を設定することで、コアの内部構造（コア内部のＣＴ値分布）を閲覧することが可能となる。
【００９６】
＜実施形態の効果＞
実施形態のサーバ２０によれば、ＤＩＣＯＭファイルに比べてデータ容量の小さい２次元のコア画像データをクライアント１０へ送信する。これによって、クライアント１０を形成する端末の性能に依存せず、且つ低速な回線でも利用可能なシステム（サービス）を、クライアント１０のユーザへ提供することが可能となる。
【００９７】
特に、サーバ２０によれば、コアＩＤとレンダラ２２１とが１対１で対応づけられ、コアＩＤに係るリクエストは同一のレンダラ２２１に供給される。従って、クライアント１０のユーザが、符号１０３〜１０９で示した各ＵＩの操作を行うと、操作結果に応じたクエリ（描画のリクエスト）がサーバ２０に送られる。
【００９８】
サーバ２０では、上記したように、起動ログ２１４ＡにてコアＩＤに対応づけられたレンダラ２２１が、ローカルメモリ２２２に一時記憶された３次元モデルを用いて２次元画像（コア画像）を生成し、コア画像がクライアント１０に提供（配信）される。このような、３次元モデルデータの利用によって、クエリに対する応答時間を短縮化し、ユーザに対するコア画像を用いた適正な調査環境を提供することができる。
【００９９】
なお、図１４では、ＷｅｂブラウザベースのＵＩについて説明したが、例えば、タブレット端末ベースのビューワ及びＵＩがクライアント１０でユーザに提供されるようにしても良い。この場合、例えば、コアデータ（コアセクション）の検索画面、コア画像の表示画面、縦方向断面の設定画面、ＣＴ値に対する色づけ及びα値の設定画面が、それぞれ個別の画面としてディスプレイに表示される。また、コア画像の表示画面（閲覧画面）において、クライアント１０が備えるタッチパネルを用いた指の操作（ピンチイン、ピンチアウト操作）に応じてコア画像の拡大・縮小が行われるようにしても良い。また、閲覧画面においてタッチパネル上の指の操作に応じてコア画像の回転や移動が行われるようにして
も良い。
【０１００】
なお、実施形態では、Ｘ線ＣＴスキャンされる物体の例としてコアを例示したが、対象の物体はコアに限定されず、医用（生体組織）を含め、様々な物体について、実施形態で説明したシステムを利用することができる。例えば、物体は、岩石試料や堆積物試料を含むことができる。岩石試料や堆積物試料には、上記したコアを含む。但し、上記において「コア」は“海底を掘削した柱状の地層サンプル”として説明したが、コアは、柱状の地質試料を指す広い概念であり、採取場所は、海底に限られず、例えば、地上、地下、川底などの掘削によって採取されたものも含む。
【符号の説明】
【０１０１】
１０・・・クライアント
１１・・・Ｗｅｂブラウザ（ビューワ）
２０・・・サーバ
２１・・・ゲートウェイ
２２・・・レンダリングエンジン
２１１・・・検索ＡＰＩ
２１２・・・レンダラＡＰＩ
２１３・・・検索モジュール（検索手段）
２１４・・・レンダラ制御モジュール
２１４Ａ・・・起動ログ（記憶部）
２１５・・・ロードバランサ
２２０・・・ノード
２２１・・・レンダラ
２２２・・・ローカルメモリ（メモリ）
【図１】
2014235607.tif 000006
【図２】
2014235607.tif 000007
【図３】
2014235607.tif 000008
【図４】
2014235607.tif 000009
【図５】
2014235607.tif 000010
【図６】
2014235607.tif 000011
【図７】
2014235607.tif 000012
【図８】
2014235607.tif 000013
【図９】
2014235607.tif 000014
【図１０】
2014235607.tif 000015
【図１１】
2014235607.tif 000016
【図１２】
2014235607.tif 000017
【図１３】
2014235607.tif 000018
【図１４】
2014235607.tif 000019