以下、本開示を実施するための形態(以下実施の形態とする)について説明する。なお、説明は以下の順序で行う。
1.内視鏡システムの画像処理性能
2.第1の実施の形態(内視鏡手術システム・CCU内複数リソース利用)
3.第2の実施の形態(CCUシステム・他のCCUリソース利用)
4.第3の実施の形態(CCUシステム・複数CCUリソース利用)
5.第4の実施の形態(CCUシステム・クラウドコンピューティング利用)
6.その他
<1.内視鏡システムの画像処理性能>
従来、内視鏡システムなど医療用治療機器では、通常使用、緊急使用といった具合に信号処理デバイスを複数有し、万一、通常使用の信号処理デバイスが動作不良に陥っても、残りの緊急使用の信号処理デバイスで処理を行い、治療が中断することが無いように冗長性を持たせる工夫がされていた。
このようなシステムの場合、緊急使用の信号処理デバイスには通常使用の信号処理デバイスと同じ処理しか行わせないのが一般的であった。そのため、その画像処理性能は、通常使用の信号処理デバイスの処理可能な処理内容に制限されてしまっていた。したがって、例えば、術者の手技効率を向上させるような高画質化処理が、その通常使用の信号処理デバイスの処理可能な処理内容を上回る場合、その高画質化処理を実現することは困難であった。
<2.第1の実施の形態>
<処理の分配>
そこで、医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配するようにする。このようにすることにより、リソースの利用効率を向上させることができる。これにより、各演算処理部の性能よりも高性能な処理を実現することができる。例えば、単数の演算処理部では実現することができない高画質な内視鏡画像を術者に提供することができるので、手術手技を向上させることができる。
また、複数の演算処理部を用いることにより、単数の演算処理部を用いる場合よりも高速に処理を行うことができる。また、各演算処理部に求められる演算性能等を低減させることができるので、コストの増大を抑制することができる。なお、高性能な処理は高画質化処理に限られず、例えば、病変部を強調したり、病変部の切り取り箇所を画像上に重畳したりするような手術支援処理であってもよい。
<内視鏡手術システム>
図1は、本開示に係る技術が適用され得る内視鏡手術システム100の概略的な構成の一例を示す図である。図1では、術者(医師)167が、内視鏡手術システム100を用いて、患者ベッド169上の患者171に手術を行っている様子が図示されている。図示するように、内視鏡手術システム100は、内視鏡101と、その他の術具117と、内視鏡101を支持する支持アーム装置127と、内視鏡下手術のための各種の装置が搭載されたカート137と、から構成される。
内視鏡手術では、腹壁を切って開腹する代わりに、トロッカ125a乃至125dと呼ばれる筒状の開孔器具が腹壁に複数穿刺される。そして、トロッカ125a乃至125dから、内視鏡101の鏡筒103や、その他の術具117が患者171の体腔内に挿入される。図示する例では、その他の術具117として、気腹チューブ119、エネルギー処置具121及び鉗子123が、患者171の体腔内に挿入されている。また、エネルギー処置具121は、高周波電流や超音波振動により、組織の切開及び剥離、又は血管の封止等を行う処置具である。ただし、図示する術具117はあくまで一例であり、術具117としては、例えば攝子、レトラクタ等、一般的に内視鏡下手術において用いられる各種の術具が用いられてよい。
内視鏡101によって撮影された患者171の体腔内の術部の画像が、表示装置141に表示される。術者167は、表示装置141に表示された術部の画像をリアルタイムで見ながら、エネルギー処置具121や鉗子123を用いて、例えば患部を切除する等の処置を行う。なお、図示は省略しているが、気腹チューブ119、エネルギー処置具121及び鉗子123は、手術中に、術者167又は助手等によって支持される。
<支持アーム装置>
支持アーム装置127は、ベース部129から延伸するアーム部131を備える。図示する例では、アーム部131は、関節部133a、133b、133c、及びリンク135a、135bから構成されており、アーム制御装置145からの制御により駆動される。アーム部131によって内視鏡101が支持され、その位置及び姿勢が制御される。これにより、内視鏡101の安定的な位置の固定が実現され得る。
<内視鏡>
内視鏡101は、先端から所定の長さの領域が患者171の体腔内に挿入される鏡筒103と、鏡筒103の基端に接続されるカメラヘッド105と、から構成される。図示する例では、硬性の鏡筒103を有するいわゆる硬性鏡として構成される内視鏡101を図示しているが、内視鏡101は、軟性の鏡筒103を有するいわゆる軟性鏡として構成されてもよい。
鏡筒103の先端には、対物レンズが嵌め込まれた開口部が設けられている。内視鏡101には光源装置143が接続されており、当該光源装置143によって生成された光が、鏡筒103の内部に延設されるライトガイドによって当該鏡筒の先端まで導光され、対物レンズを介して患者171の体腔内の観察対象に向かって照射される。なお、内視鏡101は、直視鏡であってもよいし、斜視鏡又は側視鏡であってもよい。
カメラヘッド105の内部には光学系及び撮像素子が設けられており、観察対象からの反射光(観察光)は当該光学系によって当該撮像素子に集光される。当該撮像素子によって観察光が光電変換され、観察光に対応する電気信号、すなわち観察像に対応する画像信号が生成される。当該画像信号は、RAWデータとしてカメラコントロールユニット(CCU(Camera Control Unit))139に送信される。なお、カメラヘッド105には、その光学系を適宜駆動させることにより、倍率及び焦点距離を調整する機能が搭載される。
なお、例えば立体視(3D表示)等に対応するために、カメラヘッド105には撮像素子が複数設けられてもよい。この場合、鏡筒103の内部には、当該複数の撮像素子のそれぞれに観察光を導光するために、リレー光学系が複数系統設けられる。
<カートに搭載される各種の装置>
CCU139は、CPU(Central Processing Unit)やGPU(Graphics Processing Unit)等によって構成され、内視鏡101及び表示装置141の動作を統括的に制御する。例えば、CCU139は、内視鏡101において撮像された撮像画像等を即時的に(リアルタイムに)表示装置141に表示させる。具体的には、CCU139は、カメラヘッド105から受け取った画像信号に対して、例えば現像処理(デモザイク処理)等の、当該画像信号に基づく画像を表示するための各種の画像処理をすぐに施す。CCU139は、当該画像処理を施した画像信号を表示装置141に提供する。また、CCU139は、カメラヘッド105に対して制御信号を送信し、その駆動を制御する。当該制御信号には、倍率や焦点距離等、撮像条件に関する情報が含まれ得る。
表示装置141は、CCU139からの制御により、当該CCU139によって画像処理が施された画像信号に基づく画像を表示する。内視鏡101が例えば4K(水平画素数3840×垂直画素数2160)又は8K(水平画素数7680×垂直画素数4320)等の高解像度の撮影に対応したものである場合、及び/又は3D表示に対応したものである場合には、表示装置141としては、それぞれに対応して、高解像度の表示が可能なもの、及び/又は3D表示可能なものが用いられ得る。4K又は8K等の高解像度の撮影に対応したものである場合、表示装置141として55インチ以上のサイズのものを用いることで一層の没入感が得られる。また、用途に応じて、解像度、サイズが異なる複数の表示装置141が設けられてもよい。
光源装置143は、例えばLED(light emitting diode)等の光源から構成され、術部を撮影する際の照射光を内視鏡101に供給する。
アーム制御装置145は、例えばCPU等のプロセッサによって構成され、所定のプログラムに従って動作することにより、所定の制御方式に従って支持アーム装置127のアーム部131の駆動を制御する。
入力装置147は、内視鏡手術システム100に対する入力インタフェースである。ユーザは、入力装置147を介して、内視鏡手術システム100に対して各種の情報の入力や指示入力を行うことができる。例えば、ユーザは、入力装置147を介して、患者の身体情報や、手術の術式についての情報等、手術に関する各種の情報を入力する。また、例えば、ユーザは、入力装置147を介して、アーム部131を駆動させる旨の指示や、内視鏡101による撮像条件(照射光の種類、倍率及び焦点距離等)を変更する旨の指示、エネルギー処置具121を駆動させる旨の指示等を入力する。
入力装置147の種類は限定されず、入力装置147は各種の公知の入力装置であってよい。入力装置147としては、例えば、マウス、キーボード、タッチパネル、スイッチ、フットスイッチ157及び/又はレバー等が適用され得る。入力装置147としてタッチパネルが用いられる場合には、当該タッチパネルは表示装置141の表示面上に設けられてもよい。
あるいは、入力装置147は、例えばメガネ型のウェアラブルデバイスやHMD(Head Mounted Display)等の、ユーザによって装着されるデバイスであり、これらのデバイスによって検出されるユーザのジェスチャや視線に応じて各種の入力が行われる。また、入力装置147は、ユーザの動きを検出可能なカメラを含み、当該カメラによって撮像された映像から検出されるユーザのジェスチャや視線に応じて各種の入力が行われる。更に、入力装置147は、ユーザの声を収音可能なマイクロホンを含み、当該マイクロホンを介して音声によって各種の入力が行われる。このように、入力装置147が非接触で各種の情報を入力可能に構成されることにより、特に清潔域に属するユーザ(例えば術者167)が、不潔域に属する機器を非接触で操作することが可能となる。また、ユーザは、所持している術具から手を離すことなく機器を操作することが可能となるため、ユーザの利便性が向上する。
処置具制御装置149は、組織の焼灼、切開又は血管の封止等のためのエネルギー処置具121の駆動を制御する。気腹装置151は、内視鏡101による視野の確保及び術者の作業空間の確保の目的で、患者171の体腔を膨らめるために、気腹チューブ119を介して当該体腔内にガスを送り込む。レコーダ153は、手術に関する各種の情報を記録可能な装置である。プリンタ155は、手術に関する各種の情報を、テキスト、画像又はグラフ等各種の形式で印刷可能な装置である。
以下、内視鏡手術システム100において特に特徴的な構成について、更に詳細に説明する。
<支持アーム装置>
支持アーム装置127は、基台であるベース部129と、ベース部129から延伸するアーム部131と、を備える。図示する例では、アーム部131は、複数の関節部133a、133b、133cと、関節部133bによって連結される複数のリンク135a、135bと、から構成されているが、図1では、簡単のため、アーム部131の構成を簡略化して図示している。実際には、アーム部131が所望の自由度を有するように、関節部133a乃至133c及びリンク135a、135bの形状、数及び配置、並びに関節部133a乃至133cの回転軸の方向等が適宜設定され得る。例えば、アーム部131は、好適に、6自由度以上の自由度を有するように構成され得る。これにより、アーム部131の可動範囲内において内視鏡101を自由に移動させることが可能になるため、所望の方向から内視鏡101の鏡筒103を患者171の体腔内に挿入することが可能になる。
関節部133a乃至133cにはアクチュエータが設けられており、関節部133a乃至133cは当該アクチュエータの駆動により所定の回転軸まわりに回転可能に構成されている。当該アクチュエータの駆動がアーム制御装置145によって制御されることにより、各関節部133a乃至133cの回転角度が制御され、アーム部131の駆動が制御される。これにより、内視鏡101の位置及び姿勢の制御が実現され得る。この際、アーム制御装置145は、力制御又は位置制御等、各種の公知の制御方式によってアーム部131の駆動を制御することができる。
例えば、術者167が、入力装置147(フットスイッチ157を含む)を介して適宜操作入力を行うことにより、当該操作入力に応じてアーム制御装置145によってアーム部131の駆動が適宜制御され、内視鏡101の位置及び姿勢が制御されてよい。当該制御により、アーム部131の先端の内視鏡101を任意の位置から任意の位置まで移動させた後、その移動後の位置で固定的に支持することができる。なお、アーム部131は、いわゆるマスタースレイブ方式で操作されてもよい。この場合、アーム部131は、手術室から離れた場所に設置される入力装置147を介してユーザによって遠隔操作され得る。
また、力制御が適用される場合には、アーム制御装置145は、ユーザからの外力を受け、その外力にならってスムーズにアーム部131が移動するように、各関節部133a乃至133cのアクチュエータを駆動させる、いわゆるパワーアシスト制御を行ってもよい。これにより、ユーザが直接アーム部131に触れながらアーム部131を移動させる際に、比較的軽い力で当該アーム部131を移動させることができる。従って、より直感的に、より簡易な操作で内視鏡101を移動させることが可能となり、ユーザの利便性を向上させることができる。
ここで、一般的に、内視鏡下手術では、スコピストと呼ばれる医師によって内視鏡101が支持されていた。これに対して、支持アーム装置127を用いることにより、人手によらずに内視鏡101の位置をより確実に固定することが可能になるため、術部の画像を安定的に得ることができ、手術を円滑に行うことが可能になる。
なお、アーム制御装置145は必ずしもカート137に設けられなくてもよい。また、アーム制御装置145は必ずしも1つの装置でなくてもよい。例えば、アーム制御装置145は、支持アーム装置127のアーム部131の各関節部133a乃至133cにそれぞれ設けられてもよく、複数のアーム制御装置145が互いに協働することにより、アーム部131の駆動制御が実現されてもよい。
<光源装置>
光源装置143は、内視鏡101に術部を撮影する際の照射光を供給する。光源装置143は、例えばLED、レーザ光源又はこれらの組み合わせによって構成される白色光源から構成される。このとき、RGBレーザ光源の組み合わせにより白色光源が構成される場合には、各色(各波長)の出力強度及び出力タイミングを高精度に制御することができるため、光源装置143において撮像画像のホワイトバランスの調整を行うことができる。また、この場合には、RGBレーザ光源それぞれからのレーザ光を時分割で観察対象に照射し、その照射タイミングに同期してカメラヘッド105の撮像素子の駆動を制御することにより、RGBそれぞれに対応した画像を時分割で撮像することも可能である。当該方法によれば、当該撮像素子にカラーフィルタを設けなくても、カラー画像を得ることができる。
また、光源装置143は、出力する光の強度を所定の時間ごとに変更するようにその駆動が制御されてもよい。その光の強度の変更のタイミングに同期してカメラヘッド105の撮像素子の駆動を制御して時分割で画像を取得し、その画像を合成することにより、いわゆる黒つぶれ及び白とびのない高ダイナミックレンジの画像を生成することができる。
また、光源装置143は、特殊光観察に対応した所定の波長帯域の光を供給可能に構成されてもよい。特殊光観察では、例えば、体組織における光の吸収の波長依存性を利用して、通常の観察時における照射光(すなわち、白色光)に比べて狭帯域の光を照射することにより、粘膜表層の血管等の所定の組織を高コントラストで撮影する、いわゆる狭帯域光観察(NBI(Narrow Band Imaging))が行われる。あるいは、特殊光観察では、励起光を照射することにより発生する蛍光により画像を得る蛍光観察が行われてもよい。蛍光観察では、体組織に励起光を照射し当該体組織からの蛍光を観察するもの(自家蛍光観察)、又はインドシアニングリーン(ICG)等の試薬を体組織に局注するとともに当該体組織にその試薬の蛍光波長に対応した励起光を照射し蛍光像を得るもの等が行われ得る。光源装置143は、このような特殊光観察に対応した狭帯域光及び/又は励起光を供給可能に構成され得る。
<内視鏡>
鏡筒103の先端から取り込まれた観察光は、カメラヘッド105まで導光され、レンズユニットに入射する。カメラヘッド105のレンズユニットは、ズームレンズ及びフォーカスレンズを含む複数のレンズが組み合わされて構成される。このレンズユニットは、撮像素子の受光面上に観察光を集光するように、その光学特性が調整されている。また、ズームレンズ及びフォーカスレンズは、撮像画像の倍率及び焦点の調整のため、その光軸上の位置が移動可能に構成される。
このようなレンズユニットを通過した観察光は、撮像素子の受光面に集光され、光電変換によって、観察像に対応した画像信号が生成される。このようにして生成された画像信号は、通信部に提供される。
この撮像素子としては、例えばCMOS(Complementary Metal Oxide Semiconductor)タイプのイメージセンサであり、Bayer配列を有するカラー撮影可能なものが用いられる。なお、この撮像素子としては、例えば4K以上の高解像度の画像の撮影に対応可能なものが用いられてもよい。術部の画像が高解像度で得られることにより、術者5067は、当該術部の様子をより詳細に把握することができ、手術をより円滑に進行することが可能となる。
また、この撮像素子は、3D表示に対応する右目用及び左目用の画像信号をそれぞれ取得するための1対の撮像素子を有するように構成される。3D表示が行われることにより、術者167は術部における生体組織の奥行きをより正確に把握することが可能になる。なお、撮像素子が多板式で構成される場合には、各撮像素子に対応して、レンズユニットも複数系統設けられる。
また、撮像素子は、必ずしもカメラヘッド105に設けられなくてもよい。例えば、撮像素子は、鏡筒103の内部に、対物レンズの直後に設けられてもよい。
カメラヘッド105において、アクチュエータがレンズユニットのズームレンズ及びフォーカスレンズを光軸に沿って所定の距離だけ移動させる。これにより撮像画像の倍率及び焦点が適宜調整され得る。
また、カメラヘッド105の通信部は、CCU139との間で各種の情報を送受信するための通信装置によって構成される。この通信部は、撮像素子から得た画像信号をRAWデータとして伝送ケーブルを介してCCU139に送信する。この際、術部の撮像画像を低レイテンシで表示するために、当該画像信号は光通信によって送信されることが好ましい。手術の際には、術者167が撮像画像によって患部の状態を観察しながら手術を行うため、より安全で確実な手術のためには、術部の動画像が可能な限りリアルタイムに(即時的に)表示されることが求められるからである。光通信が行われる場合には、通信部には、電気信号を光信号に変換する光電変換モジュールが設けられる。画像信号は当該光電変換モジュールによって光信号に変換された後、伝送ケーブルを介してCCU139に送信される。
また、カメラヘッド105の通信部は、CCU139から、カメラヘッド105の駆動を制御するための制御信号を受信する。当該制御信号には、例えば、撮像画像のフレームレートを指定する旨の情報、撮像時の露出値を指定する旨の情報、並びに/又は撮像画像の倍率及び焦点を指定する旨の情報等、撮像条件に関する情報が含まれる。通信部は、受信した制御信号をカメラヘッド制御部に提供する。なお、CCU139からの制御信号も、光通信によって伝送されてもよい。この場合、通信部には、光信号を電気信号に変換する光電変換モジュールが設けられ、制御信号は当該光電変換モジュールによって電気信号に変換された後、カメラヘッド制御部に提供される。
なお、上記のフレームレートや露出値、倍率、焦点等の撮像条件は、取得された画像信号に基づいてCCU139によって自動的に設定される。つまり、いわゆるAE(Auto Exposure)機能、AF(Auto Focus)機能及びAWB(Auto White Balance)機能が内視鏡101に搭載される。
カメラヘッド105のカメラヘッド制御部は、通信部を介して受信したCCU139からの制御信号に基づいて、カメラヘッド105の駆動を制御する。例えば、カメラヘッド制御部は、撮像画像のフレームレートを指定する旨の情報及び/又は撮像時の露光を指定する旨の情報に基づいて、撮像素子の駆動を制御する。また、例えば、カメラヘッド制御部は、撮像画像の倍率及び焦点を指定する旨の情報に基づいて、レンズユニットのズームレンズ及びフォーカスレンズを適宜移動させる。カメラヘッド制御部は、更に、鏡筒103やカメラヘッド105を識別するための情報を記憶する機能を備えてもよい。
なお、レンズユニットや撮像素子等の構成を、気密性及び防水性が高い密閉構造内に配置することで、カメラヘッド105について、オートクレーブ滅菌処理に対する耐性を持たせることができる。
<CCU>
図2は、CCU139の主な構成例を示すブロック図である。図2に示されるように、CCU139は、制御部201、画像処理部202、入力部221、出力部222、記憶部223、通信部224、およびドライブ225を有する。
制御部201は、例えば演算処理や制御処理等、任意の処理を行う。例えば、制御部201は、CCU139内の各処理部の制御に関する処理を行う。また、例えば、制御部201は、内視鏡101により撮像された撮像画像(内視鏡画像)を即時的に(リアルタイムに)表示装置141に表示させる(出力する)ための画像処理に関する制御を行う。
より具体的には、例えば、制御部201は、画像処理部202を構成するデバイス(ハードウエアリソース)に対する処理の分配(割り当て)に関する処理を行う。この分配される処理は、どのような処理であってもよいが、例えば、医療に用いられる医用データの即時的な(リアルタイムな)出力に関する処理を含むようにしてもよい。
また、例えば、制御部201は、画像処理部202に対して提供する情報の取得や、その情報の画像処理部202に対する提供に関する処理を行う。この情報は、どのような情報であってもよいが、例えば医療等に用いられる医用データを含むようにしてもよい。この医用データはどのような情報であってもよいが、例えば、医療等に用いられる医用画像(例えば患部の内視鏡画像等)を含むようにしてもよい。また、この情報の取得は、例えば、入力部221や通信部224を介したCCU139の外部からの情報の取得を含むようにしてもよい。例えば、制御部201は、通信部224を介したカメラヘッド105から供給される医用画像の画像信号等の取得や、その画像信号等の画像処理部202への提供に関する処理を行う。
また、例えば、制御部201は、画像処理部202より供給される情報の取得や、その情報の出力に関する処理を行う。この情報は、どのような情報であってもよいが、例えば、医用データ(医用画像)を含むようにしてもよい。また、この情報の出力は、例えば、出力部222や通信部224を介したCCU139の外部への出力を含むようにしてもよい。また、例えば、情報が医用画像等の画像情報である場合、出力部222を介して表示装置141に画像を表示させることを含むようにしてもよい。また、記憶部223に情報を記憶させることや、ドライブ225を介してリムーバブルメディア231に情報を記録することを含むようにしてもよい。
制御部201の物理的な構成は任意である。例えば、FPGA(Field Programmable Gate Array)やASIC(Application Specific Integrated Circuit)等の論理回路等の専用のハードウエアにより構成され、そのハードウエアによって各種処理を実現するようにしてもよいし、CPU、ROM(Read Only Memory)、RAM(Random Access Memory)等の汎用のハードウエアを有し、それらを用いてソフトウエアを実行することにより各種処理を実現するようにしてもよい。
画像処理部202は、制御部201により制御されて、制御部201を介して供給される情報に関する処理を行う。例えば、画像処理部202は、制御部201より供給される医用画像に対する画像処理を行う。また、例えば、画像処理部202は、画像処理後の医用画像等の情報を、制御部201に供給する。
画像処理部202は、物理的に分かれており、互いに独立に処理を行うことができる複数の演算用デバイス(演算処理部)をハードウエアリソースとして有する。例えば、画像処理部202が、このような複数の演算処理部として、複数種類の演算処理部を有するようにしてもよい。
演算処理部の種類を示す項目として、例えば、製造番号(ID)、用途、性能(能力)や機能等の特徴、物理構造等の内少なくとも1つが含まれるようにしてもよい。例えば、画像処理部202が、製造番号(ID)が互いに異なる複数の演算処理部を有するようにしてもよい。また、例えば、画像処理部202が、通常使用向けの演算処理部と緊急使用向けの演算処理部とを備えるようにしてもよい。また、例えば、画像処理部202が、処理能力の特徴が互いに異なる複数の演算処理部を有するようにしてもよい。なお、この処理能力の特徴とは、例えば処理速度や消費電力等のような処理性能に関する特徴であってもよいし、例えば、実行可能な処理等のような機能に関する特徴であってもよい。さらに、例えば、画像処理部202が、物理構成が互いに異なる複数の演算処理部を有するようにしてもよい。もちろん、演算処理部の種類を示す項目は任意であり、これらの例に限定されない。
画像処理部202は、このような複数種類の演算処理部として、例えば、GPU(Graphics Processing Unit)211およびFPGA(Field Programmable Gate Array)212を有する。
GPU211は、画像処理演算用の構成を備える演算処理部である。GPU211は、画像処理演算を得意とする特徴を備え、FPGA212よりも高い画像処理演算能力を有する。これに対して、FPGA212は、製造後にユーザの手許で内部論理回路を定義・変更できる集積回路を備える演算処理部である。FPGA212は、プログラミングにより任意の処理を実装することができるという特徴を備え、GPU211よりも高い汎用性を有する。
また、これらのリソースに冗長性を持たせる場合、GPU211は、通常使用として用いられ、FPGA212は、緊急使用として用いられる。つまり、GPU211とFPGA212は、その用途も、処理能力の特徴(処理性能に関する特徴および機能に関する特徴)も、互いに異なる。つまり、これらは互いに異なる種類の演算処理部である。
なお、画像処理部202が有する演算処理部は、上述したGPU211とFPGA212とに限定されない。例えば画像処理部202が、3つ以上の演算処理部を有するようにしてもよい。つまり、処理を分配する対象となるリソースの数は複数であればいくつであってもよい。また、FPGA212が、予め制御部201の制御により処理内容を切り換える機能を有していることが好ましい。
画像処理部202は、さらに、合成処理部213を有する。合成処理部213は、GPU211およびFPGA212の処理結果の合成に関する処理(例えば合成画像の生成等)を行う。そして、合成処理部213は、その合成結果に関する情報を制御部201に供給する。制御部201は、その合成結果に関する情報を、例えば、出力部222や通信部224を介して、CCU139の外部(例えば、表示装置141等)に出力する。
なお、GPU211またはFPGA212において、GPU211およびFPGA212の処理結果の合成に関する処理(例えば合成画像の生成等)を行うようにしてもよい。その場合、合成処理部213は、省略することができる。また、GPU211は複数あってもよい。
入力部221は、ユーザ入力等の外部の情報を受け付ける入力デバイスよりなる。例えば、入力部221には、キーボード、マウス、操作ボタン、タッチパネル、カメラ、マイクロホン、入力端子等が含まれるようにしてもよい。また、加速度センサ、光センサ、温度センサ等の各種センサや、バーコードリーダ等の入力機器が入力部221に含まれるようにしてもよい。入力部221は、例えば、CCU139の外部からの情報を受け付け、受け付けた情報を制御部201に供給する。
出力部222は、画像や音声等の情報を出力する出力デバイスよりなる。例えば、出力部222には、ディスプレイ、スピーカ、出力端子等が含まれるようにしてもよい。出力部222は、例えば、制御部201から供給された情報をCCU139の外部に出力する。
記憶部223は、プログラムやデータ等の情報を記憶する記憶媒体よりなる。例えば、記憶部223には、ハードディスク、RAMディスク、不揮発性メモリ等が含まれるようにしてもよい。記憶部223は、制御部201から供給された情報をその記憶媒体に記憶する。また、記憶部223は、記憶媒体から読み出した情報を制御部201に供給する。
通信部224は、所定の通信媒体(例えばインターネット等の任意のネットワーク)を介して外部の装置とプログラムやデータ等の情報を授受する通信を行う通信デバイスよりなる。通信部224は、例えば、ネットワークインタフェースよりなるようにしてもよい。例えば、通信部224は、CCU139の外部の装置と通信(プログラムやデータの授受)を行う。なお、通信部224が有線通信機能を有するようにしてもよいし、無線通信機能を有するようにしてもよいし、その両方を有するようにしてもよい。
ドライブ225は、自身に装着された、例えば、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア231に記憶されている情報(プログラムやデータ等)を読み出す。ドライブ225は、リムーバブルメディア231から読み出した情報を制御部201に供給する。また、ドライブ225は、書き込み可能なリムーバブルメディア231が自身に装着された場合、制御部201から供給される情報(プログラムやデータ等)を、そのリムーバブルメディア231に記憶させることができる。
制御部201は、例えば、記憶部223に記憶されているプログラム等をロードして実行することにより、各種処理を行う。
<機能ブロック>
以上のようなハードウエアリソースにより実現される機能について説明する。図3においては、制御部201および画像処理部202が実現する機能を示す機能ブロックの例が示されている。図3に示されるように、制御部201は、リソース制御部251を実現する。
リソース制御部251は、医用データの即時的な出力に関する処理の分配に関する処理や、画像処理部202への画像の提供および画像処理部202からの画像の取得等に関する処理を行う。
画像処理部202は、自身が有する演算処理部を用いて、基本現像部261、高画質化処理部262、検波部263、認識部264、出力データ生成部265、およびリソース情報記憶部266等の機能を実装する。
基本現像部261は、通常画質の撮像画像の生成に関する処理を行う。例えば、基本現像部261は、デモザイク処理や変換処理等を行い、RAWデータを輝度や色差の撮像画像に変換する。高画質化処理部262は、画像の高画質化に関する処理を行う。例えば、高画質化処理部262は、超解像やノイズリダクション等を行い、基本現像部261において生成される撮像画像の画質よりも高画質な撮像画像を生成する。
検波部263は、例えば出血検出等の検波処理に関する処理を行う。認識部264は、画像における所定の被写体(例えば鉗子先端部等)の認識に関する処理を行う。
出力データ生成部265は、CCU139の外部に出力する出力データの生成に関する処理を行う。例えば、出力データ生成部265は、基本現像部261や高画質化処理部262において生成された複数のデータ(例えば複数の撮像画像)を合成する等して、1つの出力データを生成する。
リソース情報記憶部266は、画像処理部202が有するリソースに関する情報であるリソース情報を記憶する。リソース情報はどのような情報であってもよいが、例えば、リソースの処理能力や機能等、処理をリソースに分配するのに有用な情報を含む。
なお、リソース情報記憶部266は、例えば、画像処理部202の各リソース、例えば、GPU211およびFPGA212に割り当てられる。つまり、画像処理部202の各リソースが、自身のリソース情報を記憶する。従ってこの場合、リソース制御部251は、画像処理部202の各リソースにアクセスし、各リソースからそれぞれのリソース情報を取得する。
なお、リソース情報記憶部266が、画像処理部202GPU211やFPGA212等のリソース以外に形成されるようにしてもよい。その場合、リソース制御部251は、画像処理部202内の各リソースとは異なるところに設けられたリソース情報記憶部266にアクセスし、各リソースのリソース情報を取得するようにしてもよい。
また、リソース情報記憶部266は、予め記憶部223に形成されているようにしてもよい。
リソース制御部251は、例えば、基本現像部261乃至認識部264により示される機能を実現するための各処理を画像処理部202のリソース(例えばGPU211やFPGA212)に割り当てる。
例えば、リソース制御部251は、医用データの即時的な出力に関する処理を、画像処理部202の各リソースに分配する(割り当てる)。これにより、リソース制御部251は、複数のリソースを用いて処理を行うことができるので、リソースの利用効率を向上させることができる。
また、リソース制御部251は、複数種類のリソースに対しても、医用データの即時的な出力に関する処理を適応的に分配する。したがって、リソース制御部251は、複数種類のリソースの利用効率の低減を抑制することができる。
また、リソース制御部251は、この処理の分配(割り当て)を、その分配する処理の内容とリソースの性能とに基づいて行う。したがって、リソース制御部251は、処理の分配をより適切に行うことができ、リソースの利用効率を向上させることができる。
なお、リソース制御部251は、上述したように、処理を分配するリソースの性能を、リソース情報から把握することができる。
<処理分配例>
次に、リソースへの処理分配について説明する。例えば、医療機器では、図4のAに示される医用画像301のように、GPU211が術者提示用の画像処理を行い、FPGA212も万が一GPU211が故障した場合に備えて画像処理を行う場合がしばしばある。この場合、GPU211で画像全体を処理すると計算コストが高いので、計算コストの低い、やや画質を落とした処理を行う。
これに対してリソース制御部251は、術者が指定したROI(Region Of Interest)について、GPU211の処理能力上許容できるフレーム内のROIサイズを判定し、リソース制御部251が、ROIについてのみGPU211で高画質化処理を行うよう指示を出し、また、それ以外の部分はFPGA212で基本画像処理を行うよう指示を出す。このリソース制御によって、例えば、図4のBに示される医用画像301が得られる。この医用画像301の場合、点線302aで囲まれる注目領域302は、その他の領域よりも高画質の画像が提供される。つまり、術者は、より視認性の高い画像で手技を行うことができ、手術手技の効率化につながる。
なお、このように、フレーム内の特定の領域だけ画像処理を変更することは、画像処理の有り無しの境界で違和感を与えたり、誤診したりする懸念がある。そのため、境界部分(点線302a)については、点線等で表示するなどして術者に明示するなどしてもよい。
なお、画像処理の境界部分の表現については処理に応じて表現を変更してもよい。境界部分の枠線の数、色、種類、太さ、形を処理内容や処理状況に応じて変更することで、手術手技を中断することなく、ユーザに処理内容や処理状況を提示することが可能となる。例えば、図4のBのように高画質化処理を行うことによる遅延の有無を、注目領域とそれ以外の領域との境界を示す枠線の数により表現するようにしてもよい。これにより、遅延の有無をユーザに直感的に示すことができる。
例えば、高画質化処理を行うことによる遅延が生じない場合(遅延量が予め定めた一定の値より大きくない場合)、図4のCの医用画像301のように、斜線模様で示される注目領域とそれ以外の領域との境界が、1本の点線からなる枠線304で示されるようにする。そして、高画質化処理を施すことで遅延が生じている場合(遅延量が予め定めた一定の値よりも大きくなった場合)、図4のDの医用画像301のように、注目領域とそれ以外の領域との境界が枠線304A乃至枠線304Cの3本の点線により示されるようにする。このようにすることにより、ユーザは枠線の本数に基づいて直感的に遅延の有無を把握することができる。
なお、この遅延量の大きさに応じて、枠線の本数を決定するようにしてもよい。例えば、遅延が発生しない場合は、斜線模様で示される注目領域とそれ以外の領域との境界が1本の枠線により示されるようにし、遅延量が増大する程、その枠線の本数が増大するようにしてもよい。これにより、遅延量をユーザに直感的に示すことができる。他にも、伝送の品質が良い場合は枠線を緑色表示し、品質が悪い場合(例えば、伝送中にパケット損失率が一定値より大きい場合)に枠線を赤色表示することで、ユーザに画像劣化や処理中断のリスクが高くなっていることを直感的に知らせることができる。
また、後述のCCUの外部のリソースに処理を分配する場合、外部リソースを占有できる時間、使用時間や発生費用に応じて枠線の太さや本数を変化させてもよい。例えば、外部リソースを占有できる時間が減るにあわせて枠線の本数を減らしていくことで、ユーザが直感的に使用可能時間を把握することができる。また、外部リソース使用により発生する発生費用が予算内である場合は緑色、予算限界に近づくと黄色、予算を超えた場合に赤色と表示することで、ユーザが発生費用の常用を直感的に把握することができる。
さらに、機械学習により病変の発見をサポートする診断サポート機能を用いている場合に、病変を発見したら枠線を変化させる構成としてもよい。例えば、リアルタイムで内視鏡の映像を、機械学習を用いた手法により解析している場合に、解析が適用されている範囲を示す境界部分の枠線を表示し、一定確率以上で病変であると判定された領域が画面内に存在した場合に、枠線を赤色に表示する。これにより、診断サポート結果を表示する画面と、内視鏡のリアルタイム映像を映す画面とを目線が行き来しなくとも、病変を検知したかどうかをユーザが直感的に把握することができる。なお、機械学習は深層ニューラルネットワークや強化学習など、必要な精度を満たす方法が適宜使用される。
なお、境界部分の表現は、画像処理の処理内容や処理状況にあわせて枠線を点滅させたり、枠線の透過率や明度を変化させたりしてもよい。例えば、枠線が赤色だと生体組織色と見分けづらくなる場合があるため、画像の色分布に基づいて枠線の色を変更する。また、診断サポート機能を用いている場合に、病変を検知したら枠線の色の透過率を変更し、ユーザが視認しやすくしてもよい。
<リソースの分配範囲>
なお、このROI(注目領域)の設定方法は任意である。例えば、上述のように術者等が指定するようにしてもよいが、それ以外の方法であってもよい。
例えば、CCU139が、術者の入力無しに、術者の注目領域となりやすい所定の領域(例えば撮像範囲の中央付近等)を、注目領域として設定するようにしてもよい。また、例えば、CCU139が、術者の入力無しに、硬性鏡のケラレが発生していない画面中央領域を注目領域として設定するようにしてもよい。
また、例えば、CCU139が、認識部264の認識技術等で検出された所定の被写体(例えば鉗子先端等)を含む近傍領域を注目領域として設定するようにしてもよい。
また、例えば、CCU139が、空間周波数の高い領域または低い領域を注目領域として設定するようにしてもよい。
以上においては、注目領域とそれ以外の領域で、処理を割り当てるリソースを切り替えるように説明したが、その他にも、例えば、CCU139が、インターレース表示のようにフレーム内のライン単位で処理を割り当てるリソースを切り替えるようにしてもよい。
また、例えば、内視鏡101が白色光とIR光(ICG撮影)をフレームシーケンシャルで撮影する場合、ICG画像はモノクロであるため、カラー画像に比べて、色関連の処理が不要になる。そこで、例えば、CCU139が、フレーム毎に処理を割り当てるリソースを切り替えるようにしてもよい。このようにすることにより、色関連処理が省略されるリソースができるので、その余剰となった計算リソースを、白色光画像処理に配分するようにしてもよい。
また、例えば、CCU139が、時間周波数の高い領域または低い領域とで処理を割り当てるリソースを切り替えるようにしてもよい。
<リソースの分配処理>
また、<処理分配例>においては、注目領域に対する高画質化処理と他の領域に対する基本画像処理とで割り当てるリソースを切り替える例を説明したが、リソースの分配の仕方(どの処理をどのリソースに割り当てるか)は任意であり、この例に限定されない。
例えば、注目領域に対する高画質化処理と、他の領域に対する出血検出等の検波処理とを互いに異なるリソースに割り当てるようにしてもよい。また、例えば、注目領域に対する識別性向上処理(血管強調、血管深度表示等)と、他の領域に対する基本現像処理とを互いに異なるリソースに割り当てるようにしてもよい。さらに、例えば、注目領域に対する動画視認性向上処理(例えば、30fpsを60fps、または60fpsを120fpsにフレーム補間するフレーム補間処理等)と、その他の領域に対する基本現像処理とで互いに異なるリソースに割り当てるようにしてもよい。
以上のように分配する処理に対して適応的に分配するので、リソース制御部251は、処理の分配をより適切に行うことができ、リソースの利用効率を向上させることができる。
<リソース制御のプロトコル>
<処理分配例>では、リソースの切り替えを主に演算処理能力によって行うように説明した。つまり、複雑な高速並列演算を必要とする処理はGPU211に割り当て、データに依存しない固定の処理はFPGA212に割り当てるように説明した。しかしながら、処理の分配の仕方はこの例に限定されない。例えば、以下の情報をリソース情報として受け取り、状況に応じて、リソースを振り分けるようにしてもよい。
・演算性能:単位時間あたりの演算回数を示す。例えば高負荷な処理が、その負荷に耐えられる演算性能が高いリソースに割り当てられるようにしてもよい。
・消費電力:例えば、システム全体で許容できる合計電力を考慮して、処理が使用可能なリソースに割り当てられるようにしてもよい。
・応答速度:例えば、注目領域外など処理遅延がそれほど問題にならない領域に関しては、クラウド等、処理能力は高いが応答速度の悪いリソースが選択されるようにしてもよい。
・占有可否:例えば、手術手技によっては一定時間同じ画像処理を保持する必要がある。その場合、占有可否と占有可能時間を考慮して、リソースの選択が行われるようにしてもよい。
・累積使用時間:例えば、製品寿命を考慮して使用するリソースが選択されるようにしてもよい。
・HWバージョン:ハードウエア(HW)によっては、要求された画像処理ができない場合がある。このハードウエアのバージョンを考慮してリソースが選択される(すなわち、処理を実行可能なリソースが選択される)ようにしてもよい。
・使用料金:リソースの使用毎あるいは使用時間毎に課金される場合、その使用料金とユーザの設定予算を考慮して、リソースが選択されるようにしてもよい。
例えば、リソース制御部251は、上述した情報を含むリソース情報を各リソースから受け取り、どのリソースを選択するかを決定する。その決定後、リソース制御部251は、各リソースに占有時間、占有演算能力、処理してもらう信号処理等を通知する。
<リソース制御のトリガ>
リソース制御のトリガは任意であり、上述した術者によるROI設定のみに限定されない。例えば、認識技術等により鉗子認識を行い、鉗子先端部が画像中に存在する場合、その先端を含む領域の検出をトリガとしてもよい。その場合、検出した先端を含む領域をROIとして設定し、リソース制御を行うようにしてもよい。また、撮影のモードの切り替えをトリガとしてリソース制御が行われるようにしもよい。
<画像処理の流れ>
次に、図5のフローチャートを参照して、CCU139により実行される画像処理の流れの例を説明する。
画像処理が開始されると、リソース制御部251は、ステップS101において、リソース情報記憶部266からリソース情報を取得し(図3矢印271)、リソース情報を確認する。ステップS102において、リソース制御部251は、割り当てる画像処理内容を確認する。ステップS103において、リソース制御部251は、リソース情報に基づいて、画像処理内容に含まれる各処理を各リソースに割り当てる。
ステップS104において、リソース制御部251は、例えば、通信部224を介して内視鏡101から供給される撮像画像データ(内視鏡画像)を取得する(矢印272)。ステップS105において、リソース制御部251は、ステップS103において割り当てたリソースに、撮像画像データ等、必要な情報を供給し(矢印273乃至矢印276)、それぞれ実行させる。各リソースは、供給された情報を用いて、リソース制御部251により割り当てられた処理を実行する。
例えば、検波部263が検波処理を行う場合、検波部263は、その処理結果を高画質化処理部262に供給する(矢印277)。また、例えば、認識部264が処理を行う場合、認識部264は、その処理結果を高画質化処理部262に供給する(矢印278)。基本現像部261が基本現像処理を行う場合、その処理結果を出力データ生成部265に供給する(矢印279)。また、高画質化処理部262が高画質化処理を行う場合、その処理結果を出力データ生成部265に供給する(矢印280)。
ステップS106において、リソース制御部251は、出力データ生成部265に出力データを生成させる。出力データ生成部265は、その制御に基づき、例えば基本現像処理結果と高画質処理結果を合成する等して、出力データを生成する。出力データ生成部265は、生成した出力データをリソース制御部251に供給する(矢印281)。
ステップS107において、リソース制御部251は、出力データをCCU139の外部に出力する(矢印282)。例えば、リソース制御部251は、出力データを出力部222を介して表示装置141に供給し、その出力データに含まれる内視鏡画像等を表示させる。
ステップS108において、リソース制御部251は、画像処理を終了するか否かを判定する。例えば手術が終了しておらず、画像処理を終了しないと判定された場合、処理はステップS104に戻り、それ以降の処理を繰り返す。つまり、画像処理が終了するまで、ステップS104乃至ステップS108の各処理が繰り返し実行される。
例えば手術が終わる等して、ステップS108において、画像処理を終了すると判定された場合、画像処理が終了する。
このように画像処理を行うことにより、医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配することができるので、リソースの利用効率を向上させることができる。例えば、術者に単体の演算処理部では実現できない高画質な内視鏡画像を提供することができる。これにより、術者の手術手技の効率を向上させることができる。また、上述のように適応的に演算リソースを分散させることができるので、CCU139単体に高い演算性能を持たせる必要がなくなり、低いデバイスコストで高機能なサービスを、ユーザに提供することができる。
また、例えばFPGAにより構成されたリソース制御部251により画像処理部202である複数のGPU211に分配処理を行う場合、そのGPU211毎に処理内容を変えることで、GPU211単体では処理できない高い演算性能を実現することができる。このとき、その複数のGPU211から出力された処理結果を再びそのFPGA(リソース制御部251)に入力し、そのFPGAがそれらの処理結果を合成して出力する構成としてもよい。
<3.第2の実施の形態>
<CCUシステム>
なお、処理を分配するリソースは、CCU139の外部のものであってもよい。例えば、図1のCCU139が、複数のCCU139により構成される(つまり、CCUシステムとして構成される)ようにしてもよい。
図6は、その場合の(図1のCCU139に対応する)CCUシステムの主な構成例を示すブロック図である。
図6に示されるCCUシステムは、2台のCCU139(CCU139-1およびCCU139-2)を有する。CCU139-1およびCCU139-2は、それぞれ、第1の実施の形態において説明したCCU139と基本的に同一の装置であり、同一の構成を有する。CCU139-1には、第1の実施の形態の場合と同様に、内視鏡101や表示装置141が有線または無線の伝送路を介して接続されており、その伝送路を介して情報の授受を行うことができるようになされている。ただし、CCU139-1には、CCU139-2も通信可能に接続されている。CCU139-1およびCCU139-2は、互いの通信部224を介して通信を行う。この通信は、有線または無線の通信媒体を介して行われる。
なお、CCU139-1およびCCU139-2は、それぞれ、図2を参照して説明したような構成を有するが、図6においては、一部の機能ブロックのみが示されている。
図6のCCUシステムの場合、そのCCUシステムを構成する複数のCCU139の内の1つであるCCU139-1が主リソースとなって、処理の分配を行う。つまり、CCU139-1の制御部201-1が、処理の分配を行う。この処理の分配は第1の実施の形態において説明した場合と略同様であるが、本実施の形態の場合、複数のCCU139のリソースが処理の分配対象とされる。つまり、図6の例の場合、CCU139-1の制御部201-1は、画像処理部202-1のリソースだけでなく、CCU139-2の画像処理部202-2のリソースにも適応的に処理を分配する。
つまり、内視鏡101から送信された画像信号等は、CCU139-1の(通信部224を介して)制御部201-1に供給される(矢印331)。制御部201-1は、画像処理部202-1と、外部リソースであるCCU139-2の画像処理部202-2とに対して、処理内容とそれらのリソース情報に基づいて処理を分配する(矢印332および矢印333)。画像処理部202-1および画像処理部202-2は、それぞれ、割り当てられた処理を実行する。画像処理部202-2は、その処理結果を、制御部201-1経由で画像処理部202-1に供給する(矢印334および矢印332)。画像処理部202-1は、自身の処理結果と、画像処理部202-2の処理結果とを合成して出力データを生成し、それを、制御部201-1を介して、例えば表示装置141等に出力する(矢印332および矢印335)。表示装置141には、その出力データに含まれる内視鏡画像等が表示される。
なお、外部リソースであるCCU139-2は、どのようなハードウエアとして構成されるようにしてもよい。例えば、CCU139-2が、主リソースであるCCU139-1のバックアップ用デバイス等として、CCU139-1と同じ内視鏡手術システム100に設けられるようにしてもよい。また、例えば、CCU139-2が、CCU139-1が属する内視鏡手術システム100とは異なる内視鏡手術システム100に属するようにしてもよい。その場合、CCU139-1が属する内視鏡手術システム100と、CCU139-2が属する内視鏡手術システム100とが互いに同一の手術室に設けられていてもよい。例えば、CCU139-2が属する内視鏡手術システム100が、CCU139-1が属する内視鏡手術システム100のバックアップ用システムとして設けられていてもよい。
さらに、CCU139-1が属する内視鏡手術システム100と、CCU139-2が属する内視鏡手術システム100とが互いに異なる手術室に設けられるようにしてもよい。例えば、通常時、CCU139-1が属する内視鏡手術システム100と、CCU139-2が属する内視鏡手術システム100とが互いに異なる手術に用いられるが、CCU139-2が属する内視鏡手術システム100が利用されていない場合、CCU139-1によって、CCU139-2のリソースを利用することができるようにしてもよい。
さらに、CCU139-1が属する内視鏡手術システム100と、CCU139-2が属する内視鏡手術システム100とが互いに異なる病院等に設けられるようにしてもよい。
勿論、CCU139-2が、上述の内視鏡手術システム以外のシステムに属するようにしてもよい。また、外部リソースとするデバイスは、割り当てられた処理を実行することができる構成を有し(つまり、処理を割り当てるリソースを有し)、かつ、他の装置と通信を行うことができるものであればどのようなものであってもよく、CCU139でなくてもよい。ただし、図6の例のように、主リソースと外部リソースとが互いに同様の構成を有し、同様の処理を行うデバイスである方が制御をより容易にすることができる。
なお、外部リソースの数は任意であり、2以上(複数)であってもよい。例えば、上述したCCUユニットが3つ以上のCCU139により構成されるようにしてもよい。各CCU139が有する演算処理部の数は、統一されていてもよいし、統一されていなくてもよい。
<機能ブロック>
以上のようなハードウエアリソースにより実現される機能について説明する。図7においては、制御部201-1、画像処理部202-1、および画像処理部202-2が実現する機能を示す機能ブロックの例が示されている。図7に示されるように、制御部201-1は、リソース制御部351を実現する。
リソース制御部351は、基本的にリソース制御部251と同様の構成を有し、同様の処理を行うが、主リソースの画像処理部202-1だけじゃなく、外部リソースであるCCU139-2の画像処理部202-2にも処理を分配する。つまり、リソース制御部351は、医用データの即時的な出力に関する処理を、画像処理部202-1および画像処理部202-2に適応的に分配するように構成される。
外部リソースであるCCU139-2の画像処理部202-2は、基本的に画像処理部202(図3)と同様の構成を有するが、出力データ生成部265の代わりに合成データ生成部361を有する。
合成データ生成部361は、CCU139-2の外部に出力する合成データの生成に関する処理を行う。例えば、合成データ生成部361は、基本現像部261-2や高画質化処理部262-2において生成された複数のデータ(例えば複数の撮像画像)を合成する等して、1つの合成データを生成する。合成データ生成部361は、その合成データをリソース制御部351を介して画像処理部202-1(出力データ生成部362)に供給する。
なお、図7においては、図示を省略しているが、矢印371-2、矢印373-2乃至矢印376-2、並びに、矢印381は、リソース制御部351に接続される。
主リソースであるCCU139-1の画像処理部202-1は、基本的に画像処理部202(図3)と同様の構成を有するが、出力データ生成部265の代わりに出力データ生成部362を有する。
出力データ生成部362は、CCU139-1の外部に出力する出力データの生成に関する処理を行う。例えば、出力データ生成部362は、基本現像部261-1や高画質化処理部262-1において生成された複数のデータ(例えば複数の撮像画像)、並びに、リソース制御部351を介して合成データ生成部361から供給された合成データを合成する等して、1つの出力データを生成する。出力データ生成部362は、その出力データをリソース制御部351および出力部222等を介してCCU139-1の外部(例えば表示装置141等)に出力する。
リソース制御部351は、医用データの即時的な出力に関する処理を、画像処理部202-1のリソースだけでなく画像処理部202-2のリソースにも分配する(割り当てる)。これにより、リソース制御部351は、第1の実施の形態の場合と同様に、複数のリソースを用いて処理を行うことができるので、リソースの利用効率を向上させることができる。
<画像処理の流れ>
次に、図8のフローチャートを参照して、この場合の画像処理の流れの例を説明する。
画像処理が開始されると、リソース制御部351は、ステップS201において、主リソース(CCU139-1)のリソース情報をリソース情報記憶部266-1から取得して確認する(矢印371-1)。同様に、ステップS202において、リソース制御部351は、外部リソース(CCU139-2)のリソース情報をリソース情報記憶部266-2から取得して確認する(矢印371-2)。
ステップS203において、リソース制御部351は、割り当てる画像処理内容を確認する。ステップS204において、リソース制御部351は、リソース情報に基づいて、画像処理内容に含まれる各処理を主リソースおよび外部リソースの各リソースに割り当てる。
ステップS205において、リソース制御部351は、例えば、通信部224を介して内視鏡101から供給される撮像画像データ(内視鏡画像)を取得する(矢印372)。ステップS206において、リソース制御部351は、ステップS204において割り当てた主リソースの各リソースに、撮像画像データ等、必要な情報を供給し(矢印373-1乃至矢印376-1)、それぞれ実行させる。各リソースは、供給された情報を用いて、リソース制御部351により割り当てられた処理を実行する。
例えば、検波部263-1が検波処理を行う場合、検波部263-1は、その処理結果を高画質化処理部262-1に供給する(矢印377-1)。また、例えば、認識部264-1が処理を行う場合、認識部264-1は、その処理結果を高画質化処理部262-1に供給する(矢印378-1)。基本現像部261-1が基本現像処理を行う場合、その処理結果を出力データ生成部362に供給する(矢印379-1)。また、高画質化処理部262-1が高画質化処理を行う場合、その処理結果を出力データ生成部362に供給する(矢印380-1)。
同様に、ステップS207において、リソース制御部351は、ステップS204において割り当てた外部リソースの各リソースに、撮像画像データ等、必要な情報を供給し(矢印373-2乃至矢印376-2)、それぞれ実行させる。各リソースは、供給された情報を用いて、リソース制御部351により割り当てられた処理を実行する。
例えば、検波部263-2が検波処理を行う場合、検波部263-2は、その処理結果を高画質化処理部262-2に供給する(矢印377-2)。また、例えば、認識部264-2が処理を行う場合、認識部264-2は、その処理結果を高画質化処理部262-2に供給する(矢印378-2)。基本現像部261-2が基本現像処理を行う場合、その処理結果を合成データ生成部361に供給する(矢印379-2)。また、高画質化処理部262-2が高画質化処理を行う場合、その処理結果を合成データ生成部361に供給する(矢印380-2)。
ステップS208において、リソース制御部251は、合成データ生成部361に合成データを生成させる。合成データ生成部361は、その制御に基づき、例えば基本現像処理結果と高画質処理結果を合成する等して、合成データを生成する。合成データ生成部361は、生成した合成データを、リソース制御部351を介して、出力データ生成部362に供給する(矢印381および矢印382)。
ステップS209において、リソース制御部251は、出力データ生成部362に出力データを生成させる。出力データ生成部362は、その制御に基づき、例えば基本現像処理結果および高画質処理結果、並びに、合成データを合成する等して、出力データを生成する。出力データ生成部362は、生成した出力データをリソース制御部351に供給する(矢印382)。
ステップS210において、リソース制御部351は、出力データをCCU139-1の外部に出力する(矢印383)。例えば、リソース制御部351は、出力データを出力部222を介して表示装置141に供給し、その出力データに含まれる内視鏡画像等を表示させる。
ステップS211において、リソース制御部351は、画像処理を終了するか否かを判定する。例えば手術が終了しておらず、画像処理を終了しないと判定された場合、処理はステップS205に戻り、それ以降の処理を繰り返す。つまり、画像処理が終了するまで、ステップS205乃至ステップS211の各処理が繰り返し実行される。
例えば手術が終わる等して、ステップS211において、画像処理を終了すると判定された場合、画像処理が終了する。
このように画像処理を行うことにより、医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配することができるので、リソースの利用効率を向上させることができる。例えば、術者にCCU139単体では実現できない高画質な内視鏡画像を提供することができる。これにより、術者の手術手技の効率を向上させることができる。また、上述のように適応的に演算リソースを分散させることができるので、CCU139単体に高い演算性能を持たせる必要がなくなり、低いデバイスコストで高機能なサービスを、ユーザに提供することができる。
<4.第3の実施の形態>
<CCUシステム>
また、制御は、各CCU139の外部で行うようにしてもよい。図9にその場合の(図1のCCU139に対応する)CCUシステムの主な構成例を示す。
図9に示されるCCUシステムは、第2の実施の形態の場合と同様に、2台のCCU139(CCU139-1およびCCU139-2)を有する。ただし、本実施の形態の場合、CCUシステムは、さらに制御装置401を有する。なお、CCU139-1およびCCU139-2は、それぞれ、第1の実施の形態において説明したCCU139と基本的に同一の装置であり、同一の構成を有する。ただし、図9においては、CCU139-1およびCCU139-2の、一部の機能ブロックのみが示されている。
内視鏡101や表示装置141は制御装置401に接続される。制御装置401は、CCU139-1およびCCU139-2の理を分配する等の処理を行う。なお、CCU139-1内における画像処理部202-1のリソースへの処理の分配は、CCU139-1の制御部201-1により行われる。同様に、CCU139-2内における画像処理部202-2のリソースへの処理の分配は、CCU139-2の制御部201-2により行われる。
例えば、内視鏡101から送信された画像信号等は、制御装置401に供給される(矢印431)。制御装置401は、CCU139-1およびCCU139-2のそれぞれに対して、処理内容とそれらのリソース情報に基づいて処理を分配する(矢印432および矢印433)。CCU139-1の制御部201-1は、画像処理部202-1に対して、処理内容とそのリソース情報とに基づいて処理を分配する(矢印434)。同様に、CCU139-2の制御部201-2は、画像処理部202-2に対して、処理内容とそのリソース情報とに基づいて処理を分配する(矢印435)。
画像処理部202-1および画像処理部202-2は、それぞれ、割り当てられた処理を実行する。画像処理部202-2は、その処理結果を、制御部201-2および制御部201-1経由で画像処理部202-1に供給する(矢印435、矢印436、および矢印434)。画像処理部202-1は、自身の処理結果と、画像処理部202-2の処理結果とを合成して出力データを生成し、それを制御部201-1と制御装置401を介して例えば表示装置141等に出力する(矢印434、矢印437、および矢印438)。表示装置141には、その出力データに含まれる内視鏡画像等が表示される。
なお、CCU139-1およびCCU139-2は、どのようなハードウエアとして構成されるようにしてもよい。例えば、CCU139-2がCCU139-1のバックアップ用デバイス等として、CCU139-1と同じ内視鏡手術システム100に設けられるようにしてもよい。その際、制御装置401もその内視鏡手術システム100に属するようにしてもよいし、内視鏡手術システム100には属さない装置として構成されるようにしてもよい。例えば、制御装置401が、内視鏡手術システム100を制御する装置として構成されるようにしてもよい。
また、例えば、CCU139-1とCCU139-2とが、互いに異なる内視鏡手術システム100に属するようにしてもよい。その場合、CCU139-1が属する内視鏡手術システム100と、CCU139-2が属する内視鏡手術システム100とが互いに同一の手術室に設けられていてもよい。例えば、CCU139-2が属する内視鏡手術システム100が、CCU139-1が属する内視鏡手術システム100のバックアップ用システムとして設けられていてもよい。この場合、制御装置401が、CCU139-1が属する内視鏡手術システム100か、または、CCU139-2が属する内視鏡手術システム100かに属するようにしてもよいし、これらの内視鏡手術システム100には属さないようにしてもよい。例えば、制御装置401は、これらの内視鏡手術システム100を制御する装置として構成されるようにしてもよい。
さらに、制御装置401は、例えば中央管理センタ等の、内視鏡手術システム100とは異なる場所に設置されるようにしてもよい。その場合、CCU139-1が属する内視鏡手術システム100とCCU139-2が属する内視鏡手術システム100とが、同一の手術室に設置されていてもよいし、互いに異なる手術室に設置されていてもよいし、互いに異なる病棟や病院に設置されるようにしてもよい。
なお、リソースとなるCCU139の数は複数であれば任意である。また、各CCU139が有する演算処理部の数は、統一されていてもよいし、統一されていなくてもよい。
<制御装置>
図10は、制御装置401の主な構成例を示すブロック図である。図10に示されるように、制御装置401は、CPU(Central Processing Unit)451、ROM(Read Only Memory)452、RAM(Random Access Memory)453、バス454、入出力インタフェース460、入力部461、出力部462、記憶部463、通信部464、およびドライブ465を有する。
CPU451、ROM452、およびRAM453は、バス454を介して相互に接続されている。バス454にはまた、入出力インタフェース460も接続されている。入出力インタフェース460には、入力部461乃至ドライブ465が接続されている。
入力部461は、例えば、キーボード、マウス、タッチパネル、イメージセンサ、マイクロホン、スイッチ、入力端子等の任意の入力デバイスを有する。出力部462は、例えば、ディスプレイ、スピーカ、出力端子等の任意の出力デバイスを有する。記憶部463は、例えば、ハードディスク、RAMディスク、SSD(Solid State Drive)やUSB(Universal Serial Bus)(登録商標)メモリ等のような不揮発性のメモリ等、任意の記憶媒体を有する。通信部464は、例えば、イーサネット(登録商標)、Bluetooth(登録商標)、USB、HDMI(High-Definition Multimedia Interface)(登録商標)、IrDA等の、有線若しくは無線、または両方の、任意の通信規格の通信インタフェースを有する。ドライブ465は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等の任意の記憶媒体を有するリムーバブルメディア471を駆動する。
CPU451が、例えば、ROM452や記憶部463に記憶されているプログラムを、RAM453にロードして実行することにより処理が行われる。RAM453にはまた、CPU451が各種の処理を実行する上において必要なデータなども適宜記憶される。
<機能ブロック>
以上のようなハードウエアリソースにより実現される機能について説明する。図11においては、制御装置401、CCU139-1の制御部201-1および画像処理部202-1、並びに、CCU139-2の制御部201-2および画像処理部202-2が実現する機能を示す機能ブロックの例が示されている。図11に示されるように、制御装置401は、リソース制御部501を実現する。制御部201-1は、リソース制御部511-1を実現する。制御部201-2は、リソース制御部511-2を実現する。画像処理部202-1および画像処理部202-2は、第2の実施の形態の場合(図7)と同様の機能ブロックを実現する。
リソース制御部501は、例えば、リソース制御部511-1およびリソース制御部511-2への処理の分配等を行う(矢印531、矢印533)。リソース制御部511-1は、例えば、画像処理部202-1のリソースへの処理の分配等を行う(矢印532)。リソース制御部511-2は、例えば、画像処理部202-2のリソースへの処理の分配等を行う(矢印532)。
これにより、リソース制御部501は、第1の実施の形態の場合と同様に、複数のリソースを用いて処理を行うことができるので、リソースの利用効率を向上させることができる。
<画像処理の流れ>
次に、図12および図13のフローチャートを参照して、この場合の画像処理の流れの例を説明する。
画像処理が開始されると、制御装置401のリソース制御部501、CCU139-1のリソース制御部511-1、およびCCU139-2のリソース制御部511-2は、互いに連携して処理を行い、リソース情報を確認する(図12のステップS301、ステップS311、ステップS321)。
より具体的には、リソース制御部511-1は、リソース情報記憶部266-1から画像処理部202-1のリソース情報を読み出して保持するとともに、それをリソース制御部501に供給する。同様に、リソース制御部511-2は、リソース情報記憶部266-2から画像処理部202-2のリソース情報を読み出して保持するとともに、それをリソース制御部501に供給する。
ステップS302において、リソース制御部501は、画像処理内容を確認する。そして、ステップS303において、リソース制御部501は、画像処理部202-1のリソース情報と画像処理部202-2のリソース情報とに基づいて、画像処理内容に含まれる各処理を各リソース(画像処理部202-1か画像処理部202-2か)に割り当てる。
リソース制御部511-1は、ステップS312において、ステップS303の処理と連携して、画像処理部202-1のリソース情報に基づいて、画像処理部202-1に割り当てられた画像処理内容に含まれる各処理を、画像処理部202-1の各リソースに割り当てる。
同様に、リソース制御部511-2は、ステップS322において、ステップS303の処理と連携して、画像処理部202-2のリソース情報に基づいて、画像処理部202-2に割り当てられた画像処理内容に含まれる各処理を、画像処理部202-2の各リソースに割り当てる。
ステップS304において、リソース制御部501は、通信部464を介して、内視鏡101から供給される撮像画像(内視鏡画像のRAWデータ)等のデータを取得する。
図13のステップS331において、リソース制御部501は、その撮像画像等のデータをリソース制御部511-1およびリソース制御部511-2に供給する。リソース制御部511-1は、ステップS341においてその撮像画像等のデータを取得する。また、リソース制御部511-2は、ステップS351においてその撮像画像等のデータを取得する。
ステップS342においてリソース制御部511-1は、画像処理部202-1の割り当てられたリソースで画像処理の各処理を実行させる。画像処理部202-1の各機能ブロックは、その制御に従って、割り当てられたリソースを用いて各処理を行う。
ステップS352においてリソース制御部511-2は、画像処理部202-2の割り当てられたリソースで画像処理の各処理を実行させる。画像処理部202-2の各機能ブロックは、その制御に従って、割り当てられたリソースを用いて各処理を行う。
ステップS353において、リソース制御部511-2は、合成データ生成部361において生成され供給された合成データを、CCU139-1に供給する。リソース制御部511-1は、ステップS343において、その合成データを取得する。
ステップS344において、リソース制御部511-1は、出力データ生成部362を制御し、出力データを生成させる。出力データ生成部362は、ステップS342の処理結果とステップS343において取得した合成データとを用いて、出力データを生成し、リソース制御部511-1に供給する。
ステップS345において、リソース制御部511-1は、その出力データをリソース制御部501に供給する。ステップS333において、リソース制御部501は、出力データを制御装置401の外部に出力する。
このように画像処理を行うことにより、医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配することができるので、リソースの利用効率を向上させることができる。例えば、術者にCCU139単体では実現できない高画質な内視鏡画像を提供することができる。これにより、術者の手術手技の効率を向上させることができる。また、上述のように適応的に演算リソースを分散させることができるので、CCU139単体に高い演算性能を持たせる必要がなくなり、低いデバイスコストで高機能なサービスを、ユーザに提供することができる。
<5.第4の実施の形態>
<CCUシステム>
なお、例えば第2の実施の形態において説明したCCUシステムにおいて、外部リソースは、CCU139に限らず、どのようなデバイスであってもよい。例えば、図14に示されるように、1つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
図14に示されるCCUシステムの場合、図6の場合と比較して、外部リソースが、クラウドコンピューティング601により構成される。すなわち、この外部リソースの構成は任意である。なお、クラウドコンピューティング601は例えば、CPU、RAM、ROM、GPU、HDD、SDDを含む複数のサーバ装置で構成されるサーバ群である。
この場合も、第2の実施の形態の場合と同様に、CCU139を主リソースとし、その制御部201が、画像処理部202やクラウドコンピューティング601を制御する。したがって、構成や処理の内容は、第2の実施の形態場合と同様であるのでその説明を省略する。
例えば、内視鏡101から送信された画像信号等は、CCU139の(通信部224を介して)制御部201に供給される(矢印631)。制御部201は、画像処理部202と、外部リソースであるクラウドコンピューティング601とに対して、処理内容とそれらのリソース情報に基づいて処理を分配する(矢印632および矢印633)。画像処理部202およびクラウドコンピューティングは、それぞれ、割り当てられた処理を実行する。画像処理部202は、その処理結果を、制御部201経由で画像処理部202に供給する(矢印634および矢印632)。画像処理部202は、自身の処理結果と、画像処理部202の処理結果とを合成して出力データを生成し、それを、制御部201を介して、例えば表示装置141等に出力する(矢印632および矢印635)。表示装置141には、その出力データに含まれる内視鏡画像等が表示される。
このように画像処理を行うことにより、医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配することができるので、リソースの利用効率を向上させることができる。これにより、内部リソースの演算処理性能を上回る処理であっても、外部リソースに処理を分配することで実現することが可能となる。例えば、内部リソースの演算処理部では実現することができない高画質な内視鏡画像を術者に提供することができるので、手術手技を向上させることができる。
このとき、制御部201は、外部リソースのリソース情報として占有可否を参照し、外部リソースが使用可能かを判定してもよい。さらに、制御部201は、外部リソースが使用可能であると判定した場合に、高性能な処理を行うかどうかの選択を術者に提示し、術者の選択に応じて外部リソースに適応的に処理を分配してもよい。これにより、外部リソース状況に応じて術者の手術手技を向上させるような内視鏡画像を術者に提供することができる。
また、制御部201は、外部リソースのリソース情報として外部リソースを使用する際の使用料金を参照し、使用料金とユーザの設定予算を考慮して、外部リソースを使用できる時間と高性能な処理を行うかどうかの選択を術者に提示し、術者の選択に応じて外部リソースに適応的に処理を分配してもよい。これにより、予算に応じて術者の手術手技を向上させるような内視鏡画像を術者に提供することができる。なお、外部リソースのリソース情報は、演算処理の性能、消費電力、応答速度、累積使用時間、またはハードウエアバージョンであってもよい。
また、制御部201は、処理内容が早い応答速度が必要な処理かどうかを判定し、早い応答処理が必要な処理は内部リソースを使用し、早い応答処理が必要ない処理は外部リソースを使用するように適応的に処理を分配してもよい。早い応答処理が必要な処理は、例えば、内視鏡画像に対するリアルタイム高画質化処理、リアルタイム病変検出である。早い応答処理が必要ない処理は、例えば、視野外の出血・火傷監視やピットパターン(大腸粘膜表面のくぼみのパターン)の自動診断、手術の進行状況の記録と解析、画像がどの手術シーンに取得されたものかを示すタグ付与、組織変形の計算、リアルタイム画像に対する関連画像検索、診断時の画像と手術時の画像の比較、録音の遅延・音質・音量調整、録画画像に対する高画質化・ぶれ補正、バイタル状況といったメタ記録・メタ再生、出血箇所推定処理である。なお、制御部201による処理内容の判定は、予め記憶したテーブルを用いてもよいし、ユーザが選択するようにしてもよい。
上記のようなクラウドコンピューティングを利用することで、手術中に術前情報では想定していなかった状況に陥り、内部リソースだけではリソースが足りない処理が必要となった場合でも、外部リソースを適応的に使用して処理することができる。例えば、術前では高画質化処理のみ使用の予定であったが、突然の出血により血管強調処理および出血箇所推定処理を併用する必要が生じることがある。このような場合に、制御部が高画質化処理と血管強調処理を内部リソースに分配し、出血箇所推定処理を外部リソースに分配することで、内部リソースだけでは処理できない場合であっても対処できる。
<6.その他>
<ソフトウエア>
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。また、一部の処理をハードウエアにより実行させ、他の処理をソフトウエアにより実行させることもできる。上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラム等が、ネットワークや記録媒体からインストールされる。
例えば図2のCCU139の場合、この記録媒体は、装置本体とは別に、ユーザにプログラム等を配信するために配布される、プログラム等が記録されているリムーバブルメディア231により構成される。その場合、例えば、リムーバブルメディア231をドライブ225に装着することにより、そのリムーバブルメディア231に記憶されているこのプログラム等を読み出させ、記憶部223にインストールさせることができる。
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。例えば図2のCCU139の場合、プログラムは、通信部224で受信し、記憶部223にインストールすることができる。
その他、このプログラムは、記憶部やROM等に、あらかじめインストールしておくこともできる。例えば図2のCCU139の場合、プログラムは、記憶部223や制御部201に内蔵されるROM等に予めインストールしておくこともできる。
<ユーザインタフェース>
上記の各実施の形態において、リソースの分配処理のユーザインタフェース(UI(User Interface))は、例えば、図15のように表示されるようにしてもよい。
図15に示される信号処理内容確認画面701は、実行される信号処理の内容や、各信号処理に割り当てられたリソースに関する情報等をユーザが確認するためのUIである。
図15に示されるように、この信号処理内容確認画面701の上部には、実行される信号処理の一覧710が表示されている。例えば図15の信号処理内容確認画面701の場合、「cam」から「monitor」までの間に、「Raw NR」アイコン711、「Demosaic」アイコン712、「Color Correction」アイコン713、および「Super Resolution」アイコン714が表示されている。「Raw NR」アイコン711は、Raw画像に対するノイズリダクション処理を示す。「Demosaic」アイコン712は、デモザイク処理を示す。「Color Correction」アイコン713は、色彩補正処理を示す。「Super Resolution」アイコン714は、超解像処理を示す。つまり、この一覧710には、撮像(cam)から画像表示(monitor)までの間に、Raw画像に対するノイズリダクション処理(Raw NR)と、デモザイク処理(Demosaic)と、色彩補正処理(Color Correction)と、超解像処理(Super Resolution)とが行われることが示されている。
また、その一覧710の下側には、一覧710の各信号処理に割り当てられたリソースの一覧720が表示されている。例えば図15の信号処理内容確認画面701の場合、一覧720には、「Raw NR」アイコン711の下に「local FPGA」アイコン721が表示され、「Demosaic」アイコン712の下に「local GPU」アイコン722が表示され、「Color Correction」アイコン713の下に「remote CCU」アイコン723が表示され、「Super Resolution」アイコン714の下に「cloud」アイコン724が表示されている。
「local FPGA」アイコン721は、ローカル(当該CCU)のFPGAをリソースとすることを示す処理である。つまり、一覧720においては、「Raw NR」アイコン711の下に「local FPGA」アイコン721が配置されることにより、Raw画像に対するノイズリダクション処理に対して当該CCUのFPGAがリソースとして割り当てられていることが示されている。
「local GPU」アイコン722は、ローカル(当該CCU)のGPUをリソースとすることを示す処理である。つまり、一覧720においては、「Demosaic」アイコン712の下に「local GPU」アイコン722が配置されることにより、デモザイク処理に対して当該CCUのGPUがリソースとして割り当てられていることが示されている。
「remote CCU」アイコン723は、リモートCCU(外部リソースとなり得る他のCCU)をリソースとすることを示す処理である。つまり、一覧720においては、「Color Correction」アイコン713の下に「remote CCU」アイコン723が配置されることにより、色彩補正処理に対してリモートCCUがリソースとして割り当てられていることが示されている。
「cloud」アイコン724は、クラウドコンピューティングをリソースとすることを示す処理である。つまり、一覧720においては、「Super Resolution」アイコン714の下に「cloud」アイコン724が配置されることにより、超解像処理に対してクラウドコンピューティングがリソースとして割り当てられていることが示されている。
以上のように、実行される処理内容と、各処理に割り当てられたリソースとがその対応関係を示すように表示される。つまり、この信号処理内容確認画面701においては、医用データの即時的な出力に関する処理として実行される処理毎に、割り当てられた演算処理部(リソース)が示される。したがって、ユーザは、それらの情報(どのようなリソースを使用してどのような処理が行われるか)を容易に把握することができる。
なお、一覧720の各アイコンを、リソースの種類等を識別可能に表示する(つまり表示方法を変える)ようにしてもよい。例えば、ローカル(当該CCU)のリソースと、外部リソース(他のCCUやクラウドコンピューティング等)のリソースとを識別可能(つまり、リソースが外部リソースであるか否かを識別可能)に表示するようにしてもよい。識別可能にする表示方法(リソースの種類に応じて変更する表示方法)は任意である。例えば、アイコン(またはアイコンに表示される文字)の色、濃度、明るさ、大きさ、太さ、線種、形状等の内、少なくともいずれか1つを変えるようにしてもよい。例えば、図15の場合、ローカルのリソースに対応する「local FPGA」アイコン721および「local GPU」アイコン722は、グレー地のアイコンとして表示され、外部リソースに対応する「remote CCU」アイコン723および「cloud」アイコン724は、斜線模様のアイコンとして表示されている。このように表示を変更することにより、ユーザは、各アイコンが対応するリソースの種類等を直感的に把握することができる。
また、一覧720の各アイコンを指定することによりそのアイコンに対応する処理についての情報を得ることができるようにしてもよい。例えば、図15の例の場合、ユーザがカーソル702を操作して「cloud」アイコン724を指定すると、メニュー画面731が表示される。このメニュー画面731には、ユーザが選択可能な処理の一覧が表示される。例えば図15の場合、このメニュー画面731には、「画質パラメータ」、「リソース情報」、「ヘルプ」等のメニューが表示される。
「画質パラメータ」メニューは、画質に関するパラメータについての情報を表示するメニューである。「リソース情報」メニューは、リソースに関する情報を表示するメニューである。「ヘルプ」メニューは、画面内の表示内容の説明や操作に関するヘルプ情報を表示するメニューである。例えば、ユーザがカーソル702を操作して「リソース情報」メニューを選択すると、図15の例のように、吹き出し732が表示され、その内部に、「使用時間」、「残り占有可能時間」、「演算リソース占有率」、および「現在料金」等の、超解像処理に割り当てられたクラウドコンピューティングについての情報が表示される。
「使用時間」は、これまでのそのリソースの使用時間を示す情報である。図15の例の場合、クラウドコンピューティングの使用時間が3時間(3h)であることが示されている。「残り占有可能時間」は、そのリソースを占有することができる残り時間を示す情報である。例えば、占有を予約した時間の長さから、上述の使用時間を減算した時間が、この残り占有可能時間として表示される。図15の例の場合、クラウドコンピューティングを占有可能な残り時間が1時間(1h)であることが示されている。「演算リソース占有率」は、そのリソースを実際に占有している割合(率)を示す情報である。換言するに、「演算リソース占有率」は、リソースにどの程度の空き(余裕)があるかを示す情報である。図15の例の場合、クラウドコンピューティングの占有率が10%であることが示されている。「現在料金」は、これまでのそのリソースの使用状況に対する使用料を示す情報である。図15の例の場合、クラウドコンピューティングの使用料が5千円(5,000円)であることが示されている。
このように、ユーザは、各リソースについての各種情報をより容易に把握することができる。
なお、信号処理内容確認画面701には、左下に、合計の使用料金(「Total使用料金」)が示されている。したがって、ユーザは、現在までの費用を容易に把握することができる。
この信号処理内容確認画面701の構成は、任意であり、図15の例に限定されない。例えば、この信号処理内容確認画面701に、さらに他の情報を表示するようにしてもよい。例えば図16のように、各リソースの使用率や高画質化処理を行う領域の枠設定等についての表示も行われるようにしてもよい。
図16の例の場合、信号処理内容確認画面701の一覧720の下側の領域750には、各リソースの使用率が円グラフとして表示されている。このような表示を行うことにより、ユーザは直感的に各リソースの使用率を把握することができる。
また、図16の例の場合、信号処理内容確認画面701の下部には、遅延確認画面760が表示されている。遅延確認画面760には、ユーザが、術者に提示される(術者に向けて表示される)医用画像における注目領域(高画質化される領域)の遅延に関する設定や確認を行うUIである。この遅延確認画面760において、ユーザは、例えば、カーソル702を操作することにより、高画質化処理による遅延が生じた場合の、注目領域の枠の表示方法(枠数、色、太さ、形状等)の設定を行うことができる。また、例えば、ユーザは、カーソル702を操作することにより、注目領域の大きさや形状等を指定することができる。その際、その設定された注目領域の大きさや形状等に応じた高画質化処理の遅延量が表示されるようにしてもよい。このような遅延確認画面760を設けることにより、ユーザは、医用画像における注目領域の遅延に関する設定や確認を行うことができる。
また、例えば図17のように、この信号処理内容確認画面701において、リソースの利用に関する要望等の為のユーザ(オペレータ)間のコミュニケーションを行うことができるようにしてもよい。例えば、他のユーザが占有しているリソースの解放(および自分によるそのリソースの占有)をそのユーザに対して打診することができるようにしてもよい。また、他のユーザから、自分が占有しているリソースの解放(およびそのユーザによるそのリソースの占有)の打診を受けたりすることができるようにしてもよい。もちろん、その両方ができるようにしてもよい。
図17の場合、例えば、ユーザがカーソル702を用いて信号処理内容確認画面701の「cloud」アイコン724を操作すると、打診受信確認画面781、打診送信確認画面782、および打診通知終了アイコン783が表示される。
打診受信確認画面781は、ユーザが、他のユーザから送信された自分に対する打診の受信状況を確認するUIである。図17の例の場合、自分が占有しているリソース(cloud)について、他のユーザ(OR2)から緊急度の低い打診を受けており、その打診は確認済み(既読)であることが示されている。また、他のユーザ(OR1)から緊急度の高い打診を受けており、その打診は未確認(未読)であることが示されている。このような表示を行うことにより、ユーザは、打診の受信状況を容易に把握することができる。
打診送信確認画面782は、ユーザが、自分が他のユーザに対して送信した打診の送信状況を確認するUIである。図17の例の場合、他のユーザ(OR2)が占有しているリソースについて、緊急度の低い打診を行い、その打診はそのユーザ(OR2)によって確認済み(既読)であることが示されている。また、他のユーザ(OR1)が占有しているリソースについて、緊急度の高い打診を行い、その打診はそのユーザ(OR1)によって確認されていない(未読である)ことが示されている。このような表示を行うことにより、ユーザは、打診の送信状況を容易に把握することができる。
打診通知終了アイコン783は、打診受信確認画面781および打診送信確認画面782の表示を終了させるためのUIである。例えば、ユーザがカーソル702を用いてこの打診通知終了アイコン783を操作すると、打診受信確認画面781および打診送信確認画面782の表示が終了する(打診受信確認画面781および打診送信確認画面782が消去される)。その際、打診通知終了アイコン783自身も消去されるようにしてもよい。このようなアイコンを表示することにより、ユーザは、より容易に打診受信確認画面781および打診送信確認画面782の表示を終了させることができる。
また、ユーザがリソース(特に外部リソース)の割り当てを行う際に、利用可能なリソースの一覧をUIとして提示するようにしてもよい。図18に示されるリソース選択画面791は、ユーザが実行される処理に割り当てるリソースを選択するためのUIである。図18に示されるように、リソース選択画面791には、利用可能な外部リソースの一覧が含まれている。ユーザは、カーソル792を用いてこの一覧の中から所望のリソースを選択することにより、処理に割り当てるリソースを容易に選択することができる。
なお、この一覧には、リソース名(マシン名)だけでなく、そのリソースの予約状況、稼働状況、料金、利用可能時間、選択可能処理等の、リソースに関する情報が含まれている。そのため、ユーザは、それらの情報に基づいて、実行する処理に対して最適なリソース(条件の最もよいリソース)を選択することができる。
また、このリソース選択画面791において、ユーザがリソースを複数予約することができるようにしてもよい。例えば図18に示されるように、1次予約と2次予約として2つのリソースを予約することができるようにしてもよい。この場合、1次予約したリソースが優先的に使用され、不測の事態により1次予約したリソースが使用できなくなると、2次予約したリソースがその処理に割り当てられる。例えば、手術が長引く等して、1次予約したリソースが期限切れとなる場合に、2次予約したリソースに切り替えられる。医療現場においては突発的な事態が起こり得るため、このように複数のリソースを確保することができるようにすることにより、より安全な医用支援を実現することができる。
<補足>
本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
例えば、本技術は、装置またはシステムを構成するあらゆる構成、例えば、システムLSI(Large Scale Integration)等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等(すなわち、装置の一部の構成)として実施することもできる。
なお、本明細書において、システムとは、複数の構成要素(装置、モジュール(部品)等)の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、1つの筐体の中に複数のモジュールが収納されている1つの装置は、いずれも、システムである。
また、例えば、1つの装置(または処理部)として説明した構成を分割し、複数の装置(または処理部)として構成するようにしてもよい。逆に、以上において複数の装置(または処理部)として説明した構成をまとめて1つの装置(または処理部)として構成されるようにしてもよい。また、各装置(または各処理部)の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置(または処理部)の構成の一部を他の装置(または他の処理部)の構成に含めるようにしてもよい。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能(機能ブロック等)を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、1つの装置で実行する他、複数の装置で分担して実行することができる。さらに、1つのステップに複数の処理が含まれる場合には、その1つのステップに含まれる複数の処理は、1つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、1つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を1つのステップとしてまとめて実行することもできる。
コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
なお、本技術は以下のような構成も取ることができる。
(1) 医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配する制御部
を備える情報処理装置。
(2) 前記複数の演算処理部は、性能が互いに異なる
(1)に記載の情報処理装置。
(3) 前記性能は、演算処理の性能、消費電力、応答速度、占有可否、累積使用時間、ハードウエアバージョン、または使用料金の内の少なくともいずれか1つを含む
(2)に記載の情報処理装置。
(4) 前記制御部は、前記処理の内容と前記演算処理部の性能とに基づいて前記処理を分配する
(2)または(3)に記載の情報処理装置。
(5) 前記制御部は、リソース情報に基づいて前記演算処理部の性能を把握する
(4)に記載の情報処理装置。
(6) 前記リソース情報を取得する取得部をさらに備え、
前記制御部は、前記取得部により取得された前記リソース情報に基づいて前記演算処理部の性能を把握するように構成される
(5)に記載の情報処理装置。
(7) 前記医用データは、医用画像のデータを含む
(1)乃至(6)のいずれかに記載の情報処理装置。
(8) 前記制御部は、前記医用画像の注目領域に関する処理を、他の領域に関する処理が割り当てられた演算処理部とは異なる演算処理部に割り当てる
(7)に記載の情報処理装置。
(9) 前記制御部は、前記医用画像の鉗子先端部周辺の領域を前記注目領域とする
(8)に記載の情報処理装置。
(10) 前記制御部は、前記医用画像の空間周波数の高い領域または低い領域を前記注目領域とする
(8)に記載の画像処理装置。
(11) 前記制御部は、前記注目領域に対する、通常画質よりも高画質な医用画像を生成する高画質化処理と、前記他の領域に対する、前記通常画質の医用画像を生成する基本現像処理とを互いに異なる演算処理部に割り当てる
(8)乃至(10)のいずれかに記載の情報処理装置。
(12) 前記制御部は、前記注目領域に対する、通常画質よりも高画質な医用画像を生成する高画質化処理と、前記他の領域に対する、出血の検出を行う検波処理とを互いに異なる演算処理部に割り当てる
(8)乃至(10)のいずれかに記載の画像処理装置。
(13) 前記制御部は、前記注目領域に対する、血管を強調したり、血管深度を表示したりする識別性向上処理と、前記他の領域に対する、通常画質の医用画像を生成する基本現像処理とを互いに異なる演算処理部に割り当てる
(8)乃至(10)のいずれかに記載の情報処理装置。
(14) 前記制御部は、前記注目領域に対する、フレームの補間を行う動画視認性向上処理と、前記他の領域に対する、通常画質の医用画像を生成する基本現像処理とを互いに異なる演算処理部に割り当てる
(8)乃至(10)のいずれかに記載の情報処理装置。
(15) 前記制御部は、前記医用画像に関する処理の割り当てを、フレームまたはライン毎に切り替える
(7)に記載の情報処理装置。
(16) 前記制御部は、前記医用画像のうち、処理内容が異なっている領域に境界部を重畳して表示し、
前記境界部は、前記処理内容に基づいて変更可能である
(7)乃至(15)のいずれかに記載の情報処理装置。
(17) 前記演算処理部を複数備え、
前記制御部は、前記医用データの即時的な出力に関する処理を複数の前記演算処理部に適応的に分配するように構成される
(1)乃至(16)のいずれかに記載の情報処理装置。
(18) 前記演算処理部を備え、
前記制御部は、前記医用データの即時的な出力に関する処理を、前記演算処理部と外部の演算処理部とに適応的に分配するように構成される
(1)乃至(16)のいずれかに記載の情報処理装置。
(19) 前記制御部は、前記外部の演算処理部の使用料金を含むリソース情報を取得し、該リソース情報とユーザの設定予算に基づいて、前記医用データの即自的な出力に関する処理を、前記外部の演算処理部に適応的に分配するように構成される
(18)に記載の情報処理装置。
(20) 前記演算処理部は、少なくともFPGA(Field Programmable Gate Array)により構成された第1の演算処理部と、GPU(Graphics Processing Unit)により構成された第2の演算処理部を含み、
前記FPGAは少なくとも2つの機能を切り換え可能であり、
前記制御部は、前記処理の内容と前記演算処理部の性能とに基づいて、前記FPGAの機能を切り替える
(1)乃至(19)のいずれかに記載の情報処理装置。
(21) 前記医用データの即時的な出力に関する処理として実行される処理毎に、前記制御部により割り当てられた前記演算処理部を示すユーザインタフェースを表示させる表示制御部をさらに備える
(1)乃至(20)のいずれかに記載の情報処理装置。
(22) 前記表示制御部は、前記ユーザインタフェースにおいて、各演算処理部を示す表示を、前記演算処理部の種類に応じた表示方法で表示させる
(21)に記載の情報処理装置。
(23) 前記演算処理部の種類は、前記演算処理部が、前記情報処理装置の外部の演算処理部であるか否かである
(22)に記載の情報処理装置。
(24) 前記表示方法は、前記演算処理部を示す表示の色、濃度、明るさ、大きさ、太さ、線種、および形状の内の少なくともいずれか1つを含む
(22)または(23)に記載の情報処理装置。
(25) 医用データの即時的な出力に関する処理を複数の演算処理部に適応的に分配する
情報処理方法。
(26) 制御装置と、
複数の演算処理装置と
を備え、
前記制御装置は、
医用データの即時的な出力に関する処理を、複数の前記演算処理装置のそれぞれの演算処理部に適応的に分配する制御部
を備え、
前記演算処理装置は、
前記制御部により割り当てられた処理を行う演算処理部
を備える情報処理システム。