(57)【要約】【課題】科学技術計算における対話的実時間遠隔可視化システムとして、一般公衆回線を利用して、高価な表示装置を用いることなく立体透過画像を表示でき、クライアントが膨大なデータに対して充分な解析を行うことができる対話的実時間遠隔システムおよび方法を提供する【解決手段】遠隔の端末より入力された入力データに基づき、三次元データ保持部から該当する三次元データを可視化サーバに読み出し処理を行った後、複数の画像ファイルに変換して可視化データとする可視化手段と、ストリーミングサーバがメモリ上で可視化データを動画変換してストリーミング動画データとするストリーミング手段と、ストリーミング動画データを遠隔の端末の表示装置にストリーミング配信する配信手段とを備え、ストリーミング手段の動画変換プログラムと配信手段のストリーミング配信プログラムとの間でメモリが共有されている対話的実時間遠隔可視化システム。【選択図】図２
2011061385.tif 000002
【特許請求の範囲】
【請求項１】
遠隔での三次元可視化計算をリアルタイムで対話的に操作する対話的実時間遠隔可視化システムであって、
通信回線を介して遠隔の端末より入力された入力データに基づき、三次元データ保持部から該当する三次元データを可視化サーバに読み出し、前記入力データに基づく処理を行った後、複数の画像ファイルに変換して可視化データを作成する可視化手段と、
ストリーミングサーバが、メモリ上で前記可視化データを動画変換して、ストリーミング動画データを作成するストリーミング手段と、
前記ストリーミング動画データを前記遠隔の端末の表示装置にストリーミング配信する配信手段とを備え、
前記ストリーミング手段における動画変換プログラムと、前記配信手段におけるストリーミング配信プログラムとの間で、メモリが共有されていることを特徴とする対話的実時間遠隔可視化システム。
【請求項２】
前記ストリーミング手段は、ＢＭＰ形式の可視化データをＦＬＶ形式のストリーミング動画データに変換する手段であることを特徴とする請求項１に記載の対話的実時間遠隔可視化システム。
【請求項３】
前記ＦＬＶ形式のストリーミング動画データの作成は、各ＢＭＰ形式の画像ファイルのヘッダ情報とメタデータを取得してメモリへ書込み、前記可視化手段により作成された複数の画像ファイルのＲＧＢ情報が存在する間、データの読込み、圧縮、およびＰｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅ値の計算と前記メモリへの書込みを繰り返すことにより行われることを特徴とする請求項２に記載の対話的実時間遠隔可視化システム。
【請求項４】
前記圧縮が、「ｚｌｉｂ圧縮」であることを特徴とする請求項３に記載の対話的実時間遠隔可視化システム。
【請求項５】
前記動画変換プログラムと前記ストリーミング配信プログラムとの間で行われるストリーミング動画データの受け渡しが、「Ｅｘｔｅｒｎａｌ  ＡＰＩ」を使用することにより行われることを特徴とする請求項２ないし請求項４のいずれか１項に記載の対話的実時間遠隔可視化システム。
【請求項６】
前記ストリーミング配信を行うストリーミング配信サーバが、「ｒｅｄ５」であることを特徴とする請求項５に記載の対話的実時間遠隔可視化システム。
【請求項７】
遠隔での三次元可視化計算をリアルタイムで対話的に操作する対話的実時間遠隔可視化方法であって、
通信回線を介して遠隔の端末より入力された入力データに基づき、三次元データ保持部から該当する三次元データを可視化サーバに読み出し、前記入力データに基づく処理を行った後、複数の画像ファイルに変換して可視化データを作成する可視化ステップと、
ストリーミングサーバが、メモリ上で前記可視化データを動画変換して、ストリーミング動画データを作成するストリーミングステップと、
前記ストリーミング動画データを前記遠隔の端末の表示装置にストリーミング配信する配信ステップとを備え、
前記ストリーミングステップにおける動画変換プログラムと、前記配信ステップにおけるストリーミング配信プログラムとの間で、メモリが共有されていることを特徴とする対話的実時間遠隔可視化方法。
【請求項８】
前記ストリーミングステップは、ＢＭＰ形式の可視化データをＦＬＶ形式のストリーミング動画データに変換するステップであることを特徴とする請求項７に記載の対話的実時間遠隔可視化方法。
【請求項９】
前記ＦＬＶ形式のストリーミング動画データの作成は、各ＢＭＰ形式の画像ファイルのヘッダ情報とメタデータを取得してメモリへ書込み、前記可視化ステップにおいて作成された複数の画像ファイルのＲＧＢ情報が存在する間、データの読込み、ｚｌｉｂ圧縮、およびＰｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅ値の計算と前記メモリへの書込みを繰り返すことにより行われることを特徴とする請求項８に記載の対話的実時間遠隔可視化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は対話的実時間遠隔可視化システムに関し、特に膨大なデータ量に基づく科学技術計算における対話的実時間遠隔可視化システムに関する。
【背景技術】
【０００２】
近年、医療現場や気象研究などにおいて、ホスト側のスーパーコンピュータやワークステーションを用いて三次元シミュレーションを行い、その結果を可視化データとしてクライアント（利用者）側に配信することが行われている。そして、クライアントは、配信されたデータを端末に立体透過画像として表示させ（三次元可視化）、表示された立体透過画像をインタラクティブに操作、即ち配信元と配信先との間で対話的に操作することにより、クライアント側において様々な解析を行うことがなされている。
【０００３】
しかし、このような三次元可視化において扱われるデータ量および計算量は膨大であり、表示された立体透過画像から解析すべき部分を素早く見出し、効率的な解析を行うためには、前記の対話的な操作が実時間（リアルタイム）で行われる（対話的実時間遠隔可視化）必要がある。
【０００４】
ここでの「実時間」とは、表示された立体透過画像を動画として眺める際にズレが起きない、即ち、１秒あたり３０個の可視化データが配信されることを指し、このような対話的実時間遠隔可視化を行うためには、大規模なデータ、特にボリュームデータを対象とする可視化等の処理の迅速化、通信遅延の防止等が必要であり、種々の発明がなされている（特許文献１〜３）。
【０００５】
この「対話的実時間遠隔可視化」は、従来、以下に示す２つの方法が使用されていたが、いずれの方法にも問題点があるため、対話的実時間遠隔可視化システムとしてクライアントが満足する状況にあるとは言えなかった。
【０００６】
第１の方法は、高速回線を使用して、データのボリュームを損なわずに「対話的実時間遠隔可視化」を行う方法である。この第１の方法の代表的な例としては、「スーパーＳＩＮＥＴ」がある（非特許文献１）。この方法では、東北大学に設置されているスーパーコンピュータ（演算サーバ）と北海道大学に設置されている可視化サーバとを１０Ｇｂｐｓ以上の専用高速回線で結び、可視化サーバにおいて作成された画像データを直接クライアントの端末に高速回線を用いて送信することにより、クライアントの端末に立体透過画像を表示させ、直接対話的な操作を行っている。
【０００７】
この際、クライアントの端末では、ＳＧＩ社のＯｐｅｎＧＬ  ＶｉｚＳｅｒｖｅｒを用いて、送信されてきた画像データを立体透過画像として表示している。また、可視化サーバでは、ＯｐｅｎＧＬのユーティリティライブラリであるＧＬＵＴを用いて、演算サーバからのデータ受信に加えて可視化処理（画像データへの変換）、および端末とのインタラクティブ操作への対応を実現している。
【０００８】
このシステムは、演算サーバによるシミュレーションの途中結果として得られた大容量データを、遠隔地の可視化サーバに順次転送し、リアルタイムに可視化処理することができ、クライアント側においても、膨大な立体透過画像データをリアルタイムに立体透過画像として表示させ、そのまま利用することができるという利点や、物理的に離れた場所にいる複数のクライアントが高価な可視化サーバを共有できるため、限られた計算機資源を有効に活用できるという利点を有している。
【０００９】
しかし、この方法は、可視化サーバとクライアントの端末とが広帯域の専用回線で結ばれていることを必要とする。例えば、５１２×５１２ピクセルの２４ビットカラー無圧縮画像ファイルは約６．３Ｍｂｉｔｓのサイズがあり、これを無圧縮のまま毎秒３０枚配信しようとすると、約１８９Ｍｂｐｓもの広帯域が必要となる。また、この方法には、複数のデータの可視化を同時に行えないこと、インタラクティブ操作に対する結果の表示が遅いことなどの問題点もある。
【００１０】
第１の方法の別な例としては、Ｘ線ＣＴ（通常の画素数は５１２×５１２×身長の５ｍｍスライスであるが、近年、１０２４×１０２４と一層の高画素化が進んでいる。）などの立体透過画像データを、病院内に張りめぐらされた専用高速回線を用いて、撮影室と手術室や診断室との間で直接対話的な操作を行う例もある。しかし、この方法においても、可視化処理された画像データを立体透過画像として表示する専用ワークステーションや院内の高速回線の敷設が必要であるという問題点がある。
【００１１】
第２の方法は、データのボリュームを減らし、擬似三次元画像を一般公衆回線を用いて見る方法である。前記したように、立体透過画像データを直接対話的に操作するには、広帯域の専用回線を必要とする。このため、例えば、専用回線がない病院や患者を送り込んだ小病院の医者が、診断した大病院のＸ線ＣＴ画像データにアクセスする場合には、一般公衆通信回線を使用せざるを得ず、膨大な画像データを実時間で対話的に送信することは困難である。
【００１２】
そこで、このような場合には、通常は、表面からだけの画像データを送信して、擬似三次元画像として表示させる。この表示方法として、Ｗｅｂ３Ｄという方法が広く用いられている。これは、Ｗｅｂブラウザ上でユーザが対話的に３次元ＣＧを操作する技術であり、表示対象物をポリゴン化（３角形や４角形の組合せで物体を表現する方法）することにより３Ｄオブジェクトとしてデータの再構築を行った上で、クライアントに配信し、閲覧可能としている。しかし、内部のデータを所持していないため、画像データ量は大幅に削減され、一般公衆通信回線での送信が可能となるものの、クライアントは内部から外部を見ることはできず、充分な解析を行うことができない。また、角度を変えたりすると、部分的に画像が消える場合がある。
【００１３】
このように、従来の「遠隔可視化方法」においては、膨大な立体透過画像データをそのまま利用して対話的実時間処理を行う場合には、画像データを有効に活用できるものの、高速（広帯域）の専用回線や高価な専用ワークステーションを必要とするため、クライアントのコスト的な負担が大きく、また、複数のデータの可視化を同時に行えないこと、インタラクティブ操作に対する結果の表示が遅いことなどの問題点がある。一方、低速の一般公衆回線を利用して対話的実時間処理を行う場合には、クライアントのコスト的な負担は小さいものの、配信されるデータはデータ量が削減された画像データであるため、画像データの活用が制限され、充分な解析を行うことができない問題点がある。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００４−２７２５７７号公報
【特許文献２】特開２００７−４１８１０号公報
【特許文献３】特開２００７−４１８１３号公報
【非特許文献】
【００１５】
【非特許文献１】滝沢寛之、小林広明著「スーパーＳＩＮＥＴを利用した大規模遠隔可視化処理の評価」、東北大学情報シナジーセンタースーパーコンピューティング研究、東北大学情報シナジーセンター年報、Ｎｏ３、１０６〜１１４頁、２００４年６月
【発明の概要】
【発明が解決しようとする課題】
【００１６】
そこで、膨大なデータ量に基づく科学技術計算における対話的実時間遠隔可視化システムとして、一般のクライアントでも利用可能な５００ｋｂｐｓ〜１Ｍｂｐｓという低速の一般公衆回線を利用して、専用ワークステーションなど高価な表示装置を用いることなく立体透過画像を表示することができ、擬似三次元画像の場合と異なり、クライアントが膨大なデータに対して充分な解析を行うことができる対話的実時間遠隔システムの開発が望まれていた。
【課題を解決するための手段】
【００１７】
本発明は、上記の課題を解決することを目的として成されたものであり、ホスト側の可視化サーバにより作成された画像データを、ストリーミングサーバによりストリーミング動画データへ高速に変換し、ストリーミング動画としてリアルタイムでクライアント側に配信するようにしたものである。
以下、各請求項の発明を説明する。
【００１８】
請求項１に記載の発明は、
遠隔での三次元可視化計算をリアルタイムで対話的に操作する対話的実時間遠隔可視化システムであって、
通信回線を介して遠隔の端末より入力された入力データに基づき、三次元データ保持部から該当する三次元データを可視化サーバに読み出し、前記入力データに基づく処理を行った後、複数の画像ファイルに変換して可視化データを作成する可視化手段と、
ストリーミングサーバが、メモリ上で前記可視化データを動画変換して、ストリーミング動画データを作成するストリーミング手段と、
前記ストリーミング動画データを前記遠隔の端末の表示装置にストリーミング配信する配信手段とを備え、
前記ストリーミング手段における動画変換プログラムと、前記配信手段におけるストリーミング配信プログラムとの間で、メモリが共有されていることを特徴とする対話的実時間遠隔可視化システムである。
【００１９】
本請求項の発明においては、従来のように、ホスト側に設けられた可視化サーバにおいて可視化手段により作成された可視化データ（画像ファイル）をそのままクライアント側に配信するのではなく、ストリーミング技術を活用し、ホスト側に同様に設けられたストリーミングサーバにおいてストリーミング手段により、予め、可視化データからストリーミング動画データへの変換を行っているため、配信データ量を従来に比べ大幅に低減することができ、一般公衆回線を用いた配信であっても、立体透過画像として充分に配信することができる。
【００２０】
そして、可視化データからストリーミング動画データへの変換をメモリ上で行っているため、短時間でストリーミング動画データへの変換を行うことができる。
【００２１】
また、動画変換プログラムとストリーミング配信プログラムとの間でメモリを共有しているため、ストリーミング配信されるストリーミング動画データファイルの内容を共有メモリ上に反映させることができ、これにより、ストリーミング動画データのストリーミング配信プログラムへの受け渡しをより高速化することができる。
【００２２】
さらに、ストリーミング配信は、動画データをパケット単位に分解してクライアントに配信（ダウンロード）する手法であるため、クライアントは、ストリーミング動画データ全体の配信（ダウンロード）を待つことなく、パケット単位で直ちに再生して端末に表示することができる。その際、クライアントが受信したデータ（パケット）は、一旦メモリに記憶されるものの、再生（表示）が完了する毎にメモリが解放される。このため、クライアントの端末のハードディスクやキャッシュなどには、特別な処理を行わない限り、動画データが残ることがなく、専用ワークステーションなど高性能で高価な計算機を端末とする必要がない。
【００２３】
以上の工夫がなされた本システムにおいては、クライアントは、表示された立体透過画像に対して、表示部分の拡大、縮小、回転などのインタラクティブな操作命令を、マウス操作やキーボード操作により入力する。入力された操作命令に従い、ホスト側では、該当する三次元データが読み出され、可視化サーバにおいて、操作命令に従った処理が行われて画像データが高速に作成される（可視化手段）。その後、ストリーミングサーバにおいて、ストリーミング動画データへと高速に変換される（ストリーミング手段）。このストリーミング動画データは、ストリーミング配信プログラムにより、クライアント端末にリアルタイムで配信される（配信手段）ため、クライアントは立体透過画像をリアルタイムで閲覧することができる。
【００２４】
以上の繰り返しにより、クライアントは、ストレスのない遠隔でのインタラクティブな操作をリアルタイムで実現することができ、解析作業の効率向上を図ることができる。また、遠隔にいる複数のクライアントが、リアルタイムでの閲覧が可能となる。
【００２５】
可視化データである画像ファイル（ＢＭＰ形式）から変換されるストリーミング動画データの形式としては、ＦＬＶ形式が好ましいが特に限定されず、ＷＭＶ形式、ＡＳＦ形式なども採用できる。
【００２６】
クライアントが、ストリーミング配信されたストリーミング動画データを閲覧する再生ソフトとしては、上記した各ストリーミング動画データの形式にそれぞれに対応した再生ソフトが適宜用いられる。例えば、ストリーミング動画データがＦＬＶ形式の場合には「Ｆｌａｓｈ  Ｐｌａｙｅｒ」が用いられる。
【００２７】
「Ｆｌａｓｈ  Ｐｌａｙｅｒ」は、多くのＰＣに導入されて広く使用されており、特殊なプラグインを必要とせず、容易に導入することができる。また、Ｗｉｎｄｏｗｓ（登録商標）（以下、Ｗｉｎｄｏｗｓという）、Ｍａｃｉｎｔｏｓｈ（登録商標）（以下、Ｍａｃｉｎｔｏｓｈという）のいずれのＰＣでも使用することができ、実用性が高い。
【００２８】
請求項２に記載の発明は、
前記ストリーミング手段は、ＢＭＰ形式の可視化データをＦＬＶ形式のストリーミング動画データに変換する手段であることを特徴とする請求項１に記載の対話的実時間遠隔可視化システムである。
【００２９】
ＦＬＶ形式は、アドビシステムが開発している動画ファイルフォーマットであり、ユーザ（クライアント）がコーデック等を気にせず簡単に利用できるため、ＹｏｕＴｕｂｅ等の動画投稿サイト等で広く使用されており、実用的である。また、ＦＬＶ形式は、プラットフォームに非依存であるため好ましい。
【００３０】
請求項３に記載の発明は、
前記ＦＬＶ形式のストリーミング動画データの作成は、各ＢＭＰ形式の画像ファイルのヘッダ情報とメタデータを取得してメモリへ書込み、前記可視化手段により作成された複数の画像ファイルのＲＧＢ情報が存在する間、データの読込み、圧縮、およびＰｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅ値の計算と前記メモリへの書込みを繰り返すことにより行われることを特徴とする請求項２に記載の対話的実時間遠隔可視化システムである。
【００３１】
本請求項の発明においては、ＦＬＶ形式のストリーミング動画データの作成に際して、メモリ上で処理を行うと共にデータの圧縮を行っているため、ストリーミング動画ファイルへの変換をより高速化することができる。
【００３２】
既存のＦＬＶ変換方法としてはｆｆｍｐｅｇを用いる方法がある。この方法は、最初にｃｏｎｖｅｒｔコマンドを用いて複数枚のＢＭＰ画像をＭｐｅｇ動画に変換し、次いでｆｆｍｐｅｇでＭｐｅｇをＦＬＶに変換する方法である。しかし、この方法を用いた場合、例えば、Ｐｅｎｔｉｕｍ  Ｄｕａｌ−Ｃｏｒｅ  （登録商標）１．６ＧＨｚのＣＰＵ、１ＧＢのメモリを搭載した計算機を用いて１枚約３５１ｋＢである４００×３００のＢＭＰ画像１０枚を変換するには、約３．０４３秒を要し、リアルタイムでのインタラクティブ操作を実現することができない。そこで、より高速な変換を行うためにデータの圧縮を行う。
【００３３】
圧縮方式としては、例えば、「ｚｌｉｂ圧縮」が好ましいが特に限定されず、「ｃｏｍｐｒｅｓｓ」、「ｌｈｚ」、「ｂｚｉｐ２」なども採用できる。
【００３４】
なお、「Ｐｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅ」とは、圧縮されたデータとタグのメモリサイズである。
【００３５】
請求項４に記載の発明は、
前記圧縮が、「ｚｌｉｂ圧縮」であることを特徴とする請求項３に記載の対話的実時間遠隔可視化システムである。
【００３６】
「ｚｌｉｂ」は、ｚｉｐやｇｚｉｐ、ＰＮＧ画像に使用されている可逆圧縮アルゴリズムをライブラリ化したものであり、ＧＮＵライセンスで配布されている自由に使用可能なアルゴリズムであり、圧縮方法として国際的にも信頼性が高いため、好ましい。また、「ｚｌｉｂ」は、圧縮率に対する計算コストが良好、即ち、迅速に圧縮可能であるため好ましい。
【００３７】
なお、変換に際しては、圧縮後のデータバッファサイズなどが必要であるため、圧縮部分には基本関数を使用せず、これらの値を取得することができる高次関数ｃｏｍｐｒｅｓｓ２（）を使用する。高次関数ｃｏｍｐｒｅｓｓ２（）は、９段階の圧縮率を指定することができる。
【００３８】
請求項５に記載の発明は、
前記動画変換プログラムと前記ストリーミング配信プログラムとの間で行われるストリーミング動画データの受け渡しが、「Ｅｘｔｅｒｎａｌ  ＡＰＩ」を使用することにより行われることを特徴とする請求項２ないし請求項４のいずれか１項に記載の対話的実時間遠隔可視化システムである。
【００３９】
前記したように、動画変換プログラムとストリーミング配信プログラムとの間でメモリを共有して、ストリーミング配信されるストリーミング動画データファイルの内容を共有メモリ上に反映させることにより、仮想アドレスを与え、ストリーミング動画データのストリーミング配信プログラムへの受け渡しをより高速化することができる。
【００４０】
しかし、「Ｆｌａｓｈ  Ｐｌａｙｅｒ」は、Ｗｅｂ上のアプリケーションということもあり、メモリを操作できない仕様となっている。このため、「Ｆｌａｓｈ  Ｐｌａｙｅｒ」だけでは共有メモリの技術を使用することができない。そこで、「Ｅｘｔｅｒｎａｌ  ＡＰＩ」を使用することにより、外部アプリケーションとの通信を確立でき、ストリーミング動画データの受け渡しを高速化することが可能となる。
【００４１】
「Ｅｘｔｅｒｎａｌ  ＡＰＩ」とは、「ＡｃｔｉｏｎＳｃｒｉｐｔ」の一部であり、Ｆｌａｓｈ  Ｐｌａｙｅｒのコンテナとして機能するＷｅｂブラウザなどの外部アプリケーションで実行されるコードと、「ＡｃｔｉｏｎＳｃｒｉｐｔ」間の通信用メカニズムを提供する。
【００４２】
請求項６に記載の発明は、
前記ストリーミング配信を行うストリーミング配信サーバが、「ｒｅｄ５」であることを特徴とする請求項５に記載の対話的実時間遠隔可視化システムである。
【００４３】
ストリーミング配信サーバとして「ｒｅｄ５」を用いることにより、「Ｅｘｔｅｒｎａｌ  ＡＰＩ」を使用したクライアントへのストリーミング動画データの送信に際し、動画変換プログラムとストリーミング配信プログラムとの間の通信を共有メモリで行い、データ送受信の高速化ができる。
【００４４】
「ｒｅｄ５」は、オープンソースで提供されるストリーミング配信サーバであり、容易に導入することができる。また、Ｗｉｎｄｏｗｓ、ＭａｃｉｎｔｏｓｈのいずれのＰＣでも使用することができ、実用性が高い。
【００４５】
請求項７に記載の発明は、
遠隔での三次元可視化計算をリアルタイムで対話的に操作する対話的実時間遠隔可視化方法であって、
通信回線を介して遠隔の端末より入力された入力データに基づき、三次元データ保持部から該当する三次元データを可視化サーバに読み出し、前記入力データに基づく処理を行った後、複数の画像ファイルに変換して可視化データを作成する可視化ステップと、
ストリーミングサーバが、メモリ上で前記可視化データを動画変換して、ストリーミング動画データを作成するストリーミングステップと、
前記ストリーミング動画データを前記遠隔の端末の表示装置にストリーミング配信する配信ステップとを備え、
前記ストリーミングステップにおける動画変換プログラムと、前記配信ステップにおけるストリーミング配信プログラムとの間で、メモリが共有されていることを特徴とする対話的実時間遠隔可視化方法である。
【００４６】
本請求項の発明は、物の発明である請求項１の発明を方法の発明として捉えたものである。
【００４７】
請求項８に記載の発明は、
前記ストリーミングステップは、ＢＭＰ形式の可視化データをＦＬＶ形式のストリーミング動画データに変換するステップであることを特徴とする請求項７に記載の対話的実時間遠隔可視化方法である。
【００４８】
本請求項の発明は、物の発明である請求項２の発明を方法の発明として捉えたものである。
【００４９】
請求項９に記載の発明は、
前記ＦＬＶ形式のストリーミング動画データの作成は、各ＢＭＰ形式の画像ファイルのヘッダ情報とメタデータを取得してメモリへ書込み、前記可視化ステップにおいて作成された複数の画像ファイルのＲＧＢ情報が存在する間、データの読込み、ｚｌｉｂ圧縮、およびＰｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅ値の計算と前記メモリへの書込みを繰り返すことにより行われることを特徴とする請求項８に記載の対話的実時間遠隔可視化方法である。
【００５０】
本請求項の発明は、物の発明である請求項３の発明を方法の発明として捉えたものである。
【発明の効果】
【００５１】
本発明によれば、膨大なデータ量に基づく科学技術計算における対話的実時間遠隔可視化システムとして、一般のクライアントでも利用可能な５００ｋｂｐｓ〜１Ｍｂｐｓという低速の一般公衆回線を利用して、専用ワークステーションなど高価な表示装置を用いることなく立体透過画像を表示することができ、擬似三次元画像の場合と異なり、クライアントが膨大なデータに対して充分な解析を行うことができる対話的実時間遠隔システムおよび対話的実時間遠隔方法を提供することができる。
【図面の簡単な説明】
【００５２】
【図１】本発明の実施の形態の対話的実時間遠隔可視化を行うシステムを概念的に示す図である。
【図２】対話型操作における可視化されたデータとクライアントの指示の流れの様子を概念的に示す図である。
【図３】クライアントの指示に基づくデータ処理の手順を示す図である。
【図４】ＢＭＰ形式のデータをリアルタイムでＦＬＶ変換する際の手順を示す図である。
【図５】画像データの圧縮の様子を示す図である。
【図６】ＦＬＶ変換プログラムと配信プログラム間の通信方法を概念的に示す図である。
【図７】Ｃ言語とＪａｖａ（登録商標）（以下、Ｊａｖａという）間での共有メモリを用いた通信を概念的に示す図である。
【図８】ストリーミングサーバとクライアント間のデータの流れを示す図である。
【発明を実施するための形態】
【００５３】
以下、本発明を実施の形態に基づいて説明する。なお、本発明は、以下の実施の形態に限定されるものではない。本発明と同一および均等の範囲内において、以下の実施の形態に対して種々の変更を加えることが可能である。
【００５４】
１．システムの概要とクライアントの指示を含むデータの流れ
はじめに、本発明の実施の形態の対話的実時間遠隔可視化を行うシステム全体の構成と、クライアントの指示を含むデータの流れの様子を、それぞれ図１と図２を参照しつつ説明する。
【００５５】
（１）システムの概要
図１は、本発明の実施の形態の対話的実時間遠隔可視化を行うシステムを、概念的に示す図である。図１において、１０はスーパーコンピュータであり、１１は大規模なデータであり、２０は送信側のサーバであり、２１はその可視化サーバであり、２２はそのストリーミングサーバであり、２３はその送信部であり、２４はその受信部であり、３１はクライアントＡ側の端末あり、３２はクライアントＢ側の端末である。
【００５６】
スーパーコンピュータ１０で計算されるなどしてそのメモリに蓄えられている大規模なデータ１１は、送信側のサーバ２０内の可視化サーバ２１で可視化され、ストリーミングサーバ２２の送信部２３からクライアントＡ側の端末３１等にストリーミング動画としてリアルタイムで配信され、クライアントＡ等はＦｌａｓｈ  Ｐｌａｙｅｒ等の所定のプログラムによって、配信されたストリーミング動画を端末に表示させて閲覧できる。また、閲覧したクライアントＡ等の指示は、送信側のサーバ２０内のストリーミングサーバ２２の受信部２４に送られる。なお、端末は、特に高性能である必要はなく、例えばパーソナルコンピュータが用いられる。
【００５７】
（２）クライアントの指示の流れ
図２は、対話型操作における可視化されたデータと、該データに関するクライアントの指示の流れの様子を概念的に示す図である。図２において、太い矢印で示す（１）と（２）は、送信するデータの流れを示し、（３）は、そのデータを閲覧したクライアントの指示の流れを示す。
【００５８】
図２に示す様に、クライアントは、自身の端末（パーソナルコンピュータ）に表示されているストリーミング動画を閲覧しつつ、サーバに対して、次に映し出されるストリーミング動画や画像についての指示、具体的には拡大・縮小・回転などの指示を出し（３）、サーバ２０は、クライアントからの指示を受けて大規模データ中から必要なデータを読み出し、３次元解析を行って可視化したデータとして出力（１）後、出力結果をストリーミング動画としてリアルタイムに配信（２）する。
【００５９】
２．クライアントの指示に基づくデータ処理の手順
次に、クライアントの指示に基づくデータ処理の手順について説明する。図３は、クライアントの指示に基づくデータ処理の手順を示す図である。なお、最初に表示するデータやその処理についてのサーバ２０側での認識、当該データの指示に従っての可視化を含む処理は、クライアントによる所定のキーボード操作等で行われる。
【００６０】
（Ｓ１）サーバ２０は、目下ストリーミングしているデータのアドレス、その他当該データに対する処理の内容を予め認識している。
（Ｓ２）クライアントから指示があったときには、すぐその内容を認識する。なお、クライアントの指示は、マウスのドラッグ、画面下のコンソールパネルでの拡大・縮小・回転等である。
【００６１】
（Ｓ３）クライアントの指示に基づき、指示先のデータのアドレスを認識する。
（Ｓ４）認識したアドレスのデータを読み出す。
（Ｓ５）読み出したデータについて、リアルタイムで可視化を含むクライアントに指示された処理を行う。なお、処理後のデータは、ＢＭＰ形式である。
【００６２】
３．画像配信するための手法
本実施の形態の画像配信の手法は、対象画像のＦＬＶ（Ｆｌａｓｈ  Ｖｉｄｅｏ）形式変換、共有メモリを用いたＦＬＶ変換プログラムと配信プログラム間の通信、ストリーミング配信によって構成される。以下に、各構成について具体的に説明する。
（１）ＦＬＶ変換
はじめに、ＦＬＶ変換について説明する。ＢＭＰ形式の静止画像を１秒に３０枚連続して、しかもクライアントの指示に応じて遅滞無く、即ちリアルタイムでストリーミング配信する為、ストリーミングサーバ２２でＦＬＶ形式のデータに変換する。なお、ＦＬＶとはアドビシステムズが開発している動画ファイルフォーマットである。
【００６３】
本実施の形態では、リアルタイムでＦＬＶ動画を作製するため、ＲＧＢ情報を取得し、ＦＬＶファイルへ変換する全ての流れをストリーミングサーバのメモリ上で行うことにより、処理時間の短縮を図る。これを、図４を参照しつつ説明する。図４は、このＲＧＢ情報を取得して、ＢＭＰ形式の画像をリアルタイムでＦＬＶ変換する際の手順を示す図である。
【００６４】
イ．ＦＬＶ変換の手順
［処理の開始］
（Ｓ１）１枚の画像データに対して、書込用ファイルを開く。
（Ｓ２）ヘッダ情報と属性や種類を記録した付属データであるメタデータを取得する。
（Ｓ３）ヘッダ情報とメタデータを、メモリに出力する。
（Ｓ４）変換用ＢＭＰファイルを指定する。なおこの際、ＢＭＰファイルヘッダは１４バイト（ｂｙｔｅ）固定となっており、最初の２ｂｙｔｅがファイルタイプＢＭであるか否かでＢＭＰファイルを識別する。
（Ｓ５）変換する画像の有無を調べ、無ければ当該ＢＭＰデータの処理を終える。あれば、次の（Ｓ６）へ進む。
（Ｓ６）Ｐｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅを取得する。
（Ｓ７）ＲＧＢ情報の有無を調べ、無ければ当該ＢＭＰデータの処理を終える。あれば、次の（Ｓ８）へ進む。
（Ｓ８）ＲＧＢ情報を読み込む。
（Ｓ９）画像データのｚｌｉｂ圧縮を行う。
（Ｓ１０）ｚｌｉｂ圧縮を行ったデータのＰｒｅｖｉｏｕｓ  Ｔａｇ  Ｓｉｚｅを計算する。
（Ｓ１１）サーバのメモリに、ｚｌｉｂ圧縮を行ったデータの書込みを行う。
［処理の終了］
【００６５】
前記のＦＬＶ変換には、圧縮後のデータバッファサイズ等が必要であるため、(Ｓ９)の圧縮部分には基本関数は使用せず、それらの値が取得でき、さらに９段階の圧縮率を指定可能なｚｌｉｂの高次関数ｃｏｍｐｒｅｓｓ２（）を使用する。
【００６６】
ロ．画像データ圧縮
次に、前記の（Ｓ９）における画像データ圧縮を、図５を参照しつつ説明する。図５は、画像データの圧縮の様子を示す図である。
【００６７】
色ビット数、画像の幅等のＢＰＭの画像データは、図５に示す様に左下から右上に向かって＃１から＃１６の順に上下が反転した状態でＨＤＤに格納されている。このデータを、ブロック幅ｂｌｏｃｋ＿ｗ、高さｂｌｏｃｋ＿ｈとして、幾つかのブロックに分けて圧縮を行う。ＢＭＰファイルでは画像１行毎の情報量が４の倍数でなければならないため、ブロックの縦と横の値はそれぞれ４の倍数とする。＃１３の様な画像の最後の余りの部分は任意の値で良い。また、各ブロック内での圧縮も、画像データ全体と同様に左下から右上に行う。
【００６８】
（２）ＦＬＶ変換プログラムと配信プログラム間の通信方法
イ．通信方法についての基本的な考え方
ＦＬＶ変換されたデータは、ストリーミングサーバに送られ、ストリーミング配信される。
【００６９】
ここで、ＦＬＶプログラムと配信プログラム間の通信について、図６を参照しつつ説明する。図６は、ＦＬＶ変換プログラムと配信プログラム間の通信方法を概念的に示す図である。
【００７０】
ＦＬＶ変換プログラムと配信プログラム間の通信方法は、基本的には、図６に示す様にＦＬＶ変換プログラム２１とｆｌａｓｈ上での配信プログラム間２２でメモリを共有し、ファイル内容をメモリ上に反映させることで仮想アドレスを与え、これによりストリーミングサーバが動画を読み込む際にＨＤＤに毎回アクセスする必要をなくしてデータの受渡しを高速化するものである。
【００７１】
図６に示す様に、クライアント側の装置３１には動画を再生する為のプラグインソフトとしてＦｌａｓｈ  Ｐｌａｙｅｒが装備されているが、これはｗｅｂ上でのアプリケーションであるため、送信側のメモリを操作できず、その結果フラッシュのみでは共有メモリの技術を使用できない。そこで、Ｅｘｔｅｒｎａｌ  ＡＰＩを用いて外部アプリケーションとの通信を確立し、高速でのデータの受渡しを可能とする。
【００７２】
前記の通り、このＥｘｔｅｒｎａｌ  ＡＰＩは、Ｆｌａｓｈ  Ｐｌａｙｅｒのコンテナとして機能するＷｅｂブラウザ等の外部アプリケーションで実行されるコードとＡｃｔｉｏｎＳｃｒｉｐｔ間の通信用メカニズムを提供するものである。また、Ｅｘｔｅｒｎａｌ  ＡＰＩを用いてクライアントにＦＬＶデータを通信するため、ストリーミングサーバにはｒｅｄ５を採用し、Ｊａｖａを用いてプログラムを作成する。これにより、ＦＬＶ変換プログラムと配信プログラム間の通信を共有メモリで実現する。なお、ｒｅｄ５は、Ｏｐｅｎ  Ｓｏｕｒｃｅ  Ｆｌａｓｈ（http://osflash.org/flv）にて開示されているプログラムである。
【００７３】
ロ．Ｃ言語とＪａｖａ間の通信
本実施の形態では、ＦＬＶプログラムにはＣ言語を用い、ストリーミングサーバ（ｒｅｄ５）にはＪａｖａを用いる。このため、Ｃ言語とＪａｖａ間で共有メモリを用いた通信が必要となる。Ｃ言語とＪａｖａ間の通信方法を、図７を参照しつつ説明する。図７は、Ｃ言語とＪａｖａ間での共有メモリを用いた通信方法を概念的に示す図である。
【００７４】
Ｃ言語側のプログラムでｓｈｍｇｅｔ（）で共有メモリを作成する。その領域の確保に成功すると、ｓｈｍｇｅｔ（）からユニークなＩＤを返される。Ｊａｖａ側は、そのＩＤに従って共有メモリにアクセスし、アドレスを取得し、データの読み出しを行うこととなる。なお、データは、Ｃ言語側がｓｈｍａｔ（）で共有メモリにマップしており、Ｊａｖａ側の読み出し後、ｓｈｍｃｔ（）で共有メモリを削除する。
【００７５】
Ｃ言語からＪａｖａの機能を呼び出す為には、Ｊａｖａのプログラムから他の言語で開発されたネイティブコードのプログラムを利用する為のＡＰＩであるＪＮＩ（Ｊａｖａ  Ｎａｔｉｖｅ  Ｉｎｔｅｒｆａｃｅ）を用いている。ＪＮＩを用いる為に、共有メモリにアクセスするためのＪａｖａプログラムのコンパイルにより作成されたクラスファイルからＣ言語で使用するヘッダファイルが作成され、そのヘッダファイルからＶＣ＋＋によってＣ言語のｄ１１ファイルを作成する。最後に、Ｊａｖａファイルが実行され、データが共有される。
【００７６】
（３）ストリーミング配信
次に、Ｃ言語プログラミングとＪａｖａプログラム間で共有しているデータをストリーミング配信するための手段について説明する。
【００７７】
イ．適用プログラム
前記ストリーミング配信を実現するため、以下のプログラムを使用する。
ａ．ストリーミング配信サーバ
ストリーミング配信サーバは、オープンソースで提供されているストリーミングサーバであり、Ｊａｖａで実装されているため、メモリ操作が可能なｒｅｄ５を使用する。
【００７８】
ｂ．クライアント
クライアント側は、世界中のパソコンの９０％以上にインストールされており、特殊なプラグインを必要としないＭａｃｒｏｍｅｄｉａ  Ｆｌａｓｈ  Ｐｌａｙｅｒを用いる。また、配信用および受信用のアプリケーションはＳＷＦ形式であるため、ＷｉｎｄｏｗｓあるいはＭａｃｉｎｔｏｓｈのいずれであってもＦｌａｓｈ  Ｐｌａｙｅｒさえあれば利用可能である。
【００７９】
ｃ．Ｊａｖａコンテンツ制作ツール
サーバ側で使用するＪａｖａコンテンツの制作ツールとしては、Ｅｃｌｉｐｓｅを用いる。
【００８０】
ｄ．Ｆｌａｓｈコンテンツ制作ツール
Ｆｌａｓｈコンテンツ制作ツールとしては、Ａｄｏｂｅ  Ｆｌａｓｈ  ＣＳ３  Ｐｒｏｆｅｓｓｉｏｎａｌを用いる。
【００８１】
ロ．ストリーミングサーバとクライアント間のデータの流れ
ストリーミングサーバとクライアント間のデータの流れについて、図８を参照しつつ説明する。図８は、ストリーミングサーバとクライアント間のデータの流れを示す図である。
【００８２】
ａ．サーバ側の流れ
サーバ側では、データを図８の（２）に相当するＣ言語とＪａｖａ間でのデータの通信プログラムから受取る。次に、（３）に相当する配信プログラムは、受取ったデータを読み込んでｒｅｄ５に認識させる。ｒｅｄ５への接続が成功したら、ｒｅｄ５に認識させたデータを読み出した後、配信用ＳＷＦを作成して配信する。次に、ｗｅｂ．ｘｍｌ，ｒｅｄ５−ｗｅｂ．ｘｍｌ，ｒｅｄ５−ｗｅｂ．ｐｒｏｐｅｒｔｉｅｓにそれぞれ作成したアプリケーションを指定し、パスを通す。
【００８３】
プログラムは、Ｅｃｌｉｐｓｅのワークスペースでコーディングした後、ｒｅｄ５のｗｅｂａｐｐフォルダにコピーし、ｒｅｄ５を再起動することにより有効となる。
【００８４】
ｂ．サーバとクライアント間の流れ
クライアント側では、先ず図８の（５）に当る受信用ＳＷＦを作成する。受信用ＳＷＦに、（４）のｒｅｄ５があるパーソナルコンピュータのＩＰアドレスを指定し、接続する。次に、動画を扱うオブジェクトを作成し、ｒｅｄ５から送信された映像をクライアント側に表示させる。ｒｅｄ５は、（３）の配信プログラムから受取った映像を、クライアント側からのリクエストに応じて配信する。
【００８５】
クライアント側で受信用ＳＷＦを実行すると、ＲＴＭＰで配信されている可視化サーバで作成されたストリーミング動画を、（６）のＦｌａｓｈ  Ｐｌａｙｅｒで閲覧することが可能となる。
【００８６】
なお、ｒｅｄ５は、ＳＷＦとのデータのやりとりをＲＴＭＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）という専用プロトコルを使用して行う。クライアントのＷｅｂブラウザは、ＨＴＴＰを通してＷｅｂサーバからＨＴＭＬやＳＷＦをダウンロードし、次にＦｌａｓｈ  ＰｌａｙｅｒがそのＳＷＦに含まれる動作に従ってＲＴＭＰプロトコルを使用してｒｅｄ５に接続する。ｒｅｄ５上の可視化サーバが作成した動画はｒｅｄ５からストリーミングされ、クライアントのＳＷＦ上で再生される。
【産業上の利用可能性】
【００８７】
本発明は、高価な専用の高速回線と可視化サーバ等の設置が困難な一般ユーザ、中小の研究所、中小の病院や開業医等における大規模データの利用に用いられる。
【符号の説明】
【００８８】
１０    スーパーコンピュータ
１１    大規模なデータ
２０    送信側のサーバ
２１    可視化サーバ
２２    ストリーミングサーバ
２３    送信部
２４    受信部
３１    クライアントＡ側の端末
３２    クライアントＢ側の端末
【図１】
2011061385.tif 000003
【図２】
2011061385.tif 000004
【図３】
2011061385.tif 000005
【図４】
2011061385.tif 000006
【図５】
2011061385.tif 000007
【図６】
2011061385.tif 000008
【図７】
2011061385.tif 000009
【図８】
2011061385.tif 000010