JP2004180190A - カメラ制御装置及びその制御ステップを実行するプログラム - Google Patents
カメラ制御装置及びその制御ステップを実行するプログラム Download PDFInfo
- Publication number
- JP2004180190A JP2004180190A JP2002346771A JP2002346771A JP2004180190A JP 2004180190 A JP2004180190 A JP 2004180190A JP 2002346771 A JP2002346771 A JP 2002346771A JP 2002346771 A JP2002346771 A JP 2002346771A JP 2004180190 A JP2004180190 A JP 2004180190A
- Authority
- JP
- Japan
- Prior art keywords
- camera
- control command
- visual field
- camera control
- motion
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Closed-Circuit Television Systems (AREA)
- Studio Devices (AREA)
- Selective Calling Equipment (AREA)
- Image Analysis (AREA)
Abstract
【課題】遠隔監視カメラサービスにおいて、カメラ制御操作に対してカメラ映像の応答遅延が大きい場合、ユーザが意図した視野と、遅延時間後に応答した実際の映像の視野とが異なってしまい、ユーザは快適にカメラを制御できない。
【解決手段】ユーザのカメラ制御操作に対応するカメラ映像の視野範囲を予測し、予測された視野範囲を直ぐにユーザに提示する。
【選択図】図１
【解決手段】ユーザのカメラ制御操作に対応するカメラ映像の視野範囲を予測し、予測された視野範囲を直ぐにユーザに提示する。
【選択図】図１
Description
【０００１】
【発明の属する技術分野】
本発明は、パン、チルト、およびズーム制御機能を有するカメラを遠隔制御するためのユーザインタフェース提示装置とシステムに関するものであり、特にカメラ映像の遅延が大きい場合のユーザインタフェース提示装置とシステムに関するものである。
【０００２】
【従来の技術】
近年のモバイル通信技術の急速な進展に伴い、携帯電話やＰＤＡなどの携帯端末は、これまでの音声通話のみでなく、文字や画像、さらに動画像を用いた高度なコミュニケーションを可能とするマルチメディアツールへと進化してきている。２００２年には通信キャリア会社が、携帯電話への映像コンテンツダウンロードサービスやＴＶ電話サービスを開始しており、ユーザはいつでもどこでも携帯端末により動画像を手元で楽しむことができるようになる。
こうした携帯端末を用いたアプリケーションとして、携帯端末による遠隔制御可能な監視カメラサービスがある。近年の世界規模でのテロ事件の多発や犯罪率の増加を背景に、一般家庭でも防犯意識が高まってきており監視カメラサービスの需要は今後さらに大きくなると考えられる。さらに、日本では急速な高齢化や共働き世帯の増加といった社会的背景からも、一般家庭において安価な監視カメラサービスの潜在需要は大きいと推測される。
しかし携帯端末の無線通信網は一般的に伝送路誤りの発生が多く、パケットロスが大きい。このため無線通信網向け映像配信サービスでも、ダウンロードサービスのような遅延が許容される用途では、一般的に再送要求をともなう伝送プロトコル（例えばＴＣＰ）が用いられる。一方、ＴＶ電話などのリアルタイム性が重視される（遅延に対する制限が厳しい）用途では、再送要求をともなわない伝送プロトコル（例えばＵＤＰ）が用いられることが多い。再送要求をともなわない伝送プロトコルでは、ＦＥＣ（前方誤り訂正符号）を用いることで、損失データを回復することが可能であるが、ＦＥＣによりデータの冗長性が増すため、伝送データ量が増加する。このためＦＥＣを適用する際は、誤り訂正能力と伝送ビットレートのトレードオフを考慮する必要があるため、伝送容量の小さい無線通信網ではＦＥＣで回復できないデータ損失が頻繁に発生し、映像品質劣化につながる場合が多い。
このようにリアルタイム性を重視する場合にはデータ損失による劣化が常に問題となるが、遅延制限を緩和することにより、映像の品質を向上できる場合が多い。従来の監視カメラサービスでは、インターネット網のような高速かつデータ損失がほとんど発生しない通信路を前提とした、リアルタイム映像配信が一般的であった。これに対し、携帯通信網において監視カメラサービスを提供するためには、必ずしもリアルタイム配信であることがユーザへのサービスとして優れていることにはならない。つまり監視カメラサービスに対して時間遅延を許容することで、映像品質の向上が期待でき、また既存のダウンロード配信サービスのインフラを共用することでコストを削減できれば、ユーザに対してより望ましいサービスを実現できる可能性がある。
そして上記のような、映像の遅延を考慮した遠隔カメラ制御の方法として、例えば特許文献１、特許文献２が提案されている。
【０００３】
【特許文献１】特開平１０−３４１３７１号公報
【特許文献２】特開平６−３８０８７号公報
【発明が解決しようとする課題】
しかし従来の監視カメラサービスでは、リアルタイムな映像配信を前提としていたため、ユーザのカメラ制御操作に対する映像の応答の遅延が大きい場合を想定したカメラ制御ユーザインタフェースが考慮されていない。このため、映像の遅延が大きい場合には、ユーザがカメラ制御操作を行っても、制御操作の結果の映像を視野の移動として直ぐに確認することができないため、ユーザが意図した視野と、遅延時間後に応答した実際の映像の視野とが異なってしまい、ユーザは快適にカメラを制御できないという問題があった。
上記の第一従来例は、映像の遅延を考慮したカメラ制御方法を提案している。しかしこの第一従来例はカメラ映像の解像度や撮像範囲を小さくすることでカメラ映像の情報量を削減し、映像遅延を減少させる方法であるため、情報量に関わらず最低限のバッファリング遅延時間が生じるような映像配信方式においては、遅延を削減することはできず、効果が期待できない。
また上記の第二従来例は、映像の遅延時間を考慮してカメラ制御のずれを補正する方法を提案している。しかしこの方法では遠隔カメラ操作を終えた後に、遅延時間を考慮してカメラ制御のずれ補正を行うため、遠隔ユーザがカメラを操作している最中に、映像遅延による操作の不便を解消することはできない。また上記の第二従来例の方法が適用できる映像遅延時間は高々数秒程度であり、最低でも数十秒程度の映像遅延が生じるような映像配信方式には適用することはできない。
本発明の目的は、上記の事情を鑑みてなされるものであり、ユーザのカメラ制御操作に対する映像の応答の遅延が大きいような場合であっても、ユーザに対し快適なカメラ制御インタフェースを提供することである。
【０００４】
【課題を解決するための手段】
上記目的を達成するため、本発明のカメラ制御ユーザインタフェース装置では、ユーザのカメラ制御操作に対応するカメラ映像の視野を予測し、予測された視野範囲を直ぐにユーザに提示することを特徴とする。
本特徴により、ユーザは、映像の遅延が大きい場合であってもカメラ制御操作に対する映像の視野を直ぐに確認することができるので、快適にカメラを制御することが可能となる。
【０００５】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。
図１は、本発明の実施形態１によるカメラ制御ユーザインタフェース装置における、ユーザインタフェースモジュール（以下、ＵＩモジュール）１６０の構成を示す図である。実施形態１では、遠隔カメラのカメラワークに関する情報がクライアントへ全く提供されない条件の下で、ユーザのカメラ制御操作に対する推定視野を提示する。
図２は、本発明の実施形態１によるＵＩモジュール１６０を用いた、カメラ制御システムの全体構成を示す図である。図２において、携帯端末１１５はＵＩモジュール１６０を内部に備え、無線通信網によって配信サーバ２０２と接続されている。配信サーバ２０２とエンコーダ２０３、およびカメラ２０４はＬＡＮなどの高速かつロスがほとんど発生しない通信網で常時接続されている。ただしエンコーダ２０３とカメラ２０４が通信網を介さずに一体となった構成や、さらに配信サーバ２０２とエンコーダ２０３、およびカメラ２０４が一体となった構成も可能である。
図３は、図２のカメラ制御システムの全体構成の時間的流れを示す図である。図３を参照して、本発明の実施形態１によるユーザインタフェース装置を用いた、カメラ制御システムの処理の流れを説明する。
カメラ２０４は、撮影映像２０５をエンコーダ２０３へ常時送信する。
エンコーダ２０３は、撮影映像２０５を符号化し、フラグメント２０６を生成する。フラグメント２０６の符号化方式としては、例えばＩＳＯ／ＩＥＣ １４４９６−２（以下、ＭＰＥＧ−４ Ｖｉｄｅｏ）で定められる符号化方式により動画像符号化を行い、この動画像符号化データをＩＳＯ／ＩＥＣ １４４９６−１で定めるＭＰＥＧ−４ Ｆｉｌｅ Ｆｏｒｍａｔ（以下、ＭＰ４と記す）形式で格納する方式がある。実際のカメラでは、通常は動画だけではなくマイクロフォンからの入力音声も符号化対象としても良い。
図４に、例としてＭＰ４形式によるフラグメント２０６の構成図を示す。ＭＰ４形式において、個々のフラグメントはヘッダ情報とメディアデータとで構成される。フラグメントのヘッダ情報はＭｏｖｉｅ Ｂｏｘ（以下、ｍｏｏｖと記す）の形式で格納され、メディアデータは、Ｍｅｄｉａ Ｄａｔａ Ｂｏｘ（以下、ｍｄａｔと記す）の形式で格納される。ｍｄａｔ内には動画像符号化データが格納されている。ｍｏｏｖ内には、ｍｄａｔ内の動画像符号化データへアクセスするための位置情報やタイムスタンプなどの基本情報が格納される。このため個々のフラグメントを再生するためには、各フラグメント内のヘッダ情報（ｍｏｏｖ）を初めに受信する必要がある。
図３において、個々のフラグメント２０６内には、ある時間長Ｔに相当する動画像符号化データがまとめて格納される。エンコーダ２０３が時間長Ｔのフラグメント２０６を生成すると、エンコーダ２０３はフラグメント２０６を直ちに配信サーバ２０２へ送信する。フラグメントの時間長Ｔの大きさは原理的には任意だが、以下に示すトレードオフに注意して設定する必要がある。すなわち前述のＭＰ４形式では、フラグメント単位でヘッダ情報と動画像符号化データとを格納するため、フラグメント長Ｔが小さいと、ヘッダ情報が頻繁に生成されるためオーバヘッドが大きくなる。一方でフラグメント長Ｔが大きいと、オーバヘッドは小さくなるが、フラグメントを生成する時間が大きくなるため、エンコードによる遅延時間が大きくなる。従ってフラグメント時間長Ｔの設定は、オーバヘッドとエンコード遅延時間のトレードオフとなる。本発明の実施形態１では、例えばＴを２０秒に設定する。
図３において、携帯端末１１５が配信サーバ２０２に対して配信要求２００を送信すると、配信サーバ２０２は、既にエンコーダ２０３から受信したフラグメント２０６のうち最新のフラグメントを、携帯端末１１５が受信可能な形式のフラグメント１１１を変換し、これを携帯端末１１５へ送信する。ただしフラグメント１１１とフラグメント２０６の形式が同一である場合には、上記の変換処理は必要ない。本発明の説明においては、フラグメント１１１とフラグメント２０６は同一形式であると仮定するが、異なる形式であっても本発明の処理の流れに影響はない。
配信サーバ２０２と携帯端末１１５間の伝送プロトコルには、例えばＴＣＰ／ＩＰを用いる。ＴＣＰ／ＩＰでは伝送エラーによるデータ損失が発生した場合にはデータの再送が行われるため、エラーフリーなデータ伝送が保証される。本発明の実施形態１では、エンコーダ２０３においてフラグメント時間長Ｔの遅延を許容しているため、無線通信網において、時間長Ｔのフラグメント１１１を時間長Ｔ以内で送信できるための十分なスループットが確保されていれば、途中のスループット変動によってデータ損失が起こっても、時間内で再送が行われるため携帯端末１１５において再生映像が劣化することはない。
図３において携帯端末１１５は、フラグメント１１１を受信すると、フラグメント１１１内のヘッダ情報を解析して動画像符号化データを取り出し、ビデオ復号部１１８へ渡す。ビデオ復号部１１８で動画像符号化データを復号後、フラグメント１１１内のヘッダ情報の再生時刻情報に従い、携帯端末１１５上で動画が再生される。なお、フラグメント１１１は無線通信網上で受信するため、受信速度に変動が生じることが多いが、ビデオ復号部１１８内のバッファにおいてデータを蓄えることができるため、前述と同様に、無線通信網で十分なスループットが実現されていれば、携帯端末１１５上で再生される動画像の再生速度が変動することはない。
そして図３において、携帯端末１１５からカメラ制御要求２０１を配信サーバ２０２へ送信すると、配信サーバ２０２は、カメラ制御要求２０１をカメラ２０４が解釈可能なカメラ制御コマンド２０７へ変換し、カメラ２０４へ送信する。カメラ制御要求２０１、およびカメラ制御コマンド２０７には、後述のようにパン・チルト・ズーム動作の命令が格納されている。カメラ２０４は、カメラ制御コマンド２０７を受信すると、これを解析してカメラワークを行い、カメラワークが行われた撮影映像２０５をエンコーダ２０３へ送信する。送信された撮影映像２０５は、上で述べた流れにより、携帯端末１１５にて再生される。
以上に述べたように、本発明の実施形態１のカメラ制御システムでは、カメラ２０４の撮影映像２０５と、最終的に携帯端末１１５上で再生される映像との間には、最低でもフラグメント時間長Ｔ以上の遅延が生じる。ただし前述のように、携帯端末１１５上での再生速度に変動はないため、撮影映像２０５と携帯端末１１５上の再生映像の遅延は一定である。
次に、図１を参照してＵＩモジュール１６０におけるカメラ制御インタフェース提示処理について説明する。
図１において、ＵＩモジュール１６０は本実施形態１によるユーザインタフェース提示装置における、ユーザインタフェース提示処理を行うモジュールである。ユーザ操作検出部１００は、ユーザがカメラ制御を行うボタン押下操作を行ったときの、押下されたボタンの種類を検出する。
図５にＵＩモジュール１６０をカメラ制御に用いるときの、携帯端末のボタンインタフェースの例を示す。同図において、Ｂ１は「上」「下」「左」「右」方向矢印ボタンであり、パン操作に対しては「左」「右」方向ボタンが、チルト操作に対しては「上」「下」方向ボタンがそれぞれ割り当てられる。Ｂ２は「＋」ボタンであり、ズームイン操作に対して割り当てられる。Ｂ３は「−」ボタンであり、ズームアウト操作に対して割り当てられる。Ｂ４は画像表示領域である。
図１のユーザ操作検出部１００は上記の例では、「上」「下」「左」「右」「＋」「−」ボタンのうちどれが押下されたかを示すカメラ制御ボタン押下情報１０２を発行する。本発明の実施形態１では、一度に一つのボタンのみを操作できるものとする。すなわちカメラ制御動作は、一度の動作ではパン、チルト、ズーム操作のいずれかしか行うことができないこととする。
図１のカメラ制御要求生成部１１７は、ユーザ操作検出部１００が発行するカメラ制御ボタン押下情報１０２を受け取り、カメラ制御要求２０１を配信サーバ２０２へ送信する。図６にカメラ制御要求２０１のデータフォーマット例を示す。図中、カメラＩＤは例えば制御対象のカメラのＩＰアドレスや、配信サーバ２０２が管理するカメラＩＤなどである。コマンドタイプは、例えば配信サーバ２０２が管理する、カメラ制御コマンドの種類（パン・チルト・ズーム）を示すインデックスである。値は、それぞれのコマンドに対する値（パン角度、チルト角度、ズーム率）である。前に述べたようにカメラ制御要求２０１は、配信サーバ２０２においてカメラ２０４が解釈可能なカメラ制御コマンド２０７へ変換され、カメラ２０４へ送信される。
図１において、カメラ操作動きパラメータ記憶部１０１には、カメラ操作動きパラメータ１３０が保持される。ここでカメラ操作動きパラメータ１３０とは、パン、チルト、ズームに対応するボタン押下操作一回に対するカメラワークによる再生映像の動きパラメータの推定値である。具体的には以下の関係式を与える３つのパラメータ、ａ、Ｆｘ、Ｆｙである。
（ｘ’， ｙ’） ＝ （ａ ＊ ｘ ＋ Ｆｘ， ａ ＊ ｙ ＋ Ｆｙ） （１）
数式（１）において、（ｘ， ｙ）はカメラワーク前のフレームの画素値、（ｘ’， ｙ’）はカメラワーク後のフレームの画素値、ａは一回のズーム操作による拡大率（ａ＜１でズームイン、ａ＞１でズームアウト）、Ｆｘは一回のパン操作による水平方向の動き量、Ｆｙは一回のチルト操作による垂直方向の動き量である。ただし（ｘ，ｙ）の原点はカメラの光軸、すなわち視野範囲を示す矩形の中心点とする。カメラ操作動きパラメータ記憶部１０１内のカメラ操作動きパラメータ１３０は、予めキャリブレーション処理によって測定された値が初期値として設定され、カメラ動き推定部１２１から得られるフレーム間動きパラメータ１１６に基づいて更新される。キャリブレーション処理、およびフレーム間動きパラメータ１１６に基づいた更新処理の詳細は後述する。
前述のようにパン操作、チルト操作、およびズーム操作はそれぞれ一度ずつ行われると仮定するので、数式（１）は実際には以下の３つの関係式で表される。数式（２）はパン操作、数式（３）はチルト操作、数式（４）はズーム操作を行ったときの画像変換にそれぞれ相当する。
（ｘ’， ｙ’） ＝ （ｘ ＋ Ｆｘ， ｙ） （２）
（ｘ’， ｙ’） ＝ （ｘ， ｙ ＋ Ｆｙ） （３）
（ｘ’， ｙ’） ＝ （ａ ＊ ｘ， ａ ＊ ｙ） （４）
図１において、視野範囲推定部１０４は、ユーザ操作検出部１００からは上述のカメラ制御ボタン押下情報１０２を、カメラ操作動きパラメータ記憶部１０１からはカメラ制御ボタン押下情報１０２に対応するカメラ操作動きパラメータ１３０を、そして視野範囲記憶部１２２からは現在の視野範囲情報１１０をそれぞれ受け取る。ここで視野範囲位置情報１１０は、描画部１１４において表示される視野範囲を示す矩形の中心点の座標、縦の長さ、および横の長さで表される情報である。そして視野範囲推定部１０４は、視野範囲位置情報１１０に対し、カメラ操作動きパラメータ１３０のうちの数式（２）、（３）、および（４）のいずれかのパラメータを用いて変換を施すことにより推定視野範囲位置情報１０８を算出し、視野範囲生成部１０９へ渡す。ここで、推定視野範囲位置情報１０８は、ユーザのカメラ制御操作から推定される視野範囲を示す矩形の中心点の座標、縦の長さ、および横の長さで表される情報である。
視野範囲記憶部１２２では、視野範囲生成部１０９で計算される、描画部１１４において現在表示されている視野範囲の位置情報１１０を記憶する。視野範囲生成部１０９の処理については後述する。
次に図１を用いて、ＵＩモジュール１６０における、データ受信後の処理の流れについて説明する。ＵＩモジュール１６０は、配信サーバ２０２が送信するフラグメント１１１を受信すると、これを多重分離部１１２に渡す。多重分離部１１２は、受信したフラグメント１１１内のヘッダ情報（前述のように、ｍｏｏｖに相当）を解析し、ｍｄａｔ内の動画像符号化データ１２０を取得し、これをビデオ復号部１１８へ渡す。
ビデオ復号部１１８は、動画像符号化データ１２０の復号処理を行い、復号されたフレーム画像信号１１３を描画部１１４へ渡す。
本発明の実施形態１では、ビデオ復号部１１８は現フレーム画像の、直前フレームを参照フレームとする動きベクトル１１９を求め、これをカメラ動き推定部１２１へ渡す。
本実施形態１におけるカメラ制御インタフェース提示装置で用いているＭＰＥＧ−４ Ｖｉｄｅｏなどの動画像符号化方式では、一般的にフレーム間の動き補償が行われており、動画フレームの種類は、フレーム内符号化画像（以降、Ｉフレームと記す）、フレーム間順方向予測符号化画像（以降、Ｐフレームと記す）、フレーム間双方向予測符号化画像（以降、Ｂフレームと記す）に大別される。よって動きベクトル１１９を求めるためには、Ｐフレームの場合には、符号化データ内に直前のフレームを参照画像とする動きベクトル情報が存在するため、これを動きベクトル１１９とすることができる。
一方、ＩフレームかＢフレームのように、直前のフレームを参照する動きベクトルが存在しない場合には、ビデオ復号部１１８内において、現フレームに対し直前のフレーム画像からの動き補償を行い、動きベクトル１１９を求めることができる。動き補償の処理手法として、具体的にはブロックマッチング法や勾配法等の一般的な従来技術を用いることができる。この場合、ビデオ復号部１１８内には、直前フレーム画像と現フレーム画像とを保持するメモリ領域を必要とする。
次に図１における、カメラ動き推定部１２１における処理について説明する。
まず本発明の実施形態１では、カメラ２０４で撮像されている画像内では、移動する物体は十分小さく、画像全体を占める映像の大部分の動きが極めて少ない背景であると仮定する。すなわち移動物体による動きベクトルの影響は無視できるものとする。このような仮定の場合、移動物体のない背景映像で、パン、又はチルト操作を行って、カメラワーク直前とカメラワーク直後のフレーム間の動き補償を行うと、画面領域全体で一定の大きさの動きベクトルが検出され、数式（２）、又は（３）のように近似される。またズーム操作を行うと、動きベクトルは拡大、又は縮小の動きとなり、数式（４）のように近似される。
カメラ動き推定部１２１では、フレーム間動きパラメータ１１６を求める処理と、キャリブレーション処理（詳細は後述する）とが行われる。
図７に、カメラ動き推定部１２１における、フレーム間動きパラメータ１１６を求める処理の流れ図を示す。カメラ動き推定部１２１では、現フレーム画像全体の動きベクトルのヒストグラムを作成し、最も頻度の高い動きベクトル（最尤ベクトル）を求める（Ｓ７０１）。そしてパン、チルト、ズーム操作のいずれかのカメラワークが行われたか、何もカメラワークが行われていないかを推定する。具体的には、Ｓ７０１で求めた最尤ベクトルが、水平方向である（もしくは水平方向と近似できる）場合（Ｓ７０２）、現フレームはパン操作が行われたと判定し、数式（２）のＦｘを求める（Ｓ７０３）。
Ｓ７０２において、最尤ベクトルが水平方向ではないと判定された場合、次に最尤ベクトルが垂直方向かどうか（もしくは、垂直方向と近似できるか）を判定する（Ｓ７０４）。Ｓ７０４で垂直方向と判定された場合、現フレームはチルト操作が行われたと判定し、数式（３）のＦｙを求める（Ｓ７０５）。
Ｓ７０４において、最尤ベクトルが水平方向ではないと判定された場合、次に各画素における動きベクトルと数式（４）を比較し、数式（４）が成り立つ（もしくは、成り立つと近似できる）かどうかを判定する（Ｓ７０６）。数式（４）が成り立つ場合には、現フレームはズーム操作が行われたと判定し、数式（４）のａを求める（Ｓ７０７）。
Ｓ７０６において、数式（４）が成立しないと判定された場合、現フレームにはカメラワークによる画面の移動や拡大・縮小はないと判定する（Ｓ７０８）。
以上のように求められたフレーム間動きパラメータ１１６（Ｆｘ、Ｆｙ、ａのいずれか）は視野範囲生成部１０９と、カメラ操作動きパラメータ記憶部１０１に送られる。視野範囲生成部１０９における処理、およびカメラ操作動きパラメータ記憶部１０１における処理については後述する。
次に、カメラ動き推定部１２１において行われるキャリブレーション処理について説明する。本発明では、カメラ操作動きパラメータ記憶部１０１内に保持するカメラ操作動きパラメータ１３０の初期値を決定する処理をキャリブレーションと称する。具体的には、キャリブレーション処理によって、ユーザがパン・チルト・ズーム操作をそれぞれ一回行ったときの画面の移動パラメータ、すなわち数式（２）のＦｘ、数式（３）のＦｙ、数式（４）のａをそれぞれ求め、これらの組をカメラ操作動きパラメータ１３０の初期値とする。本発明の実施形態１では、このキャリブレーション処理は、ＵＩモジュール１６０を起動直後に自動的に（すなわち、ユーザは意識的にキャリブレーションのための操作は行わない）一度だけ行われるものとする。
また本発明の実施形態１では、キャリブレーション処理により上記のパラメータを個別に推定するために、キャリブレーション処理中は、パン・チルト・ズーム操作をそれぞれ一度だけ行い、かつ各操作の間にはある程度の時間間隔を行うものとする。このような仮定を設けることにより、各カメラワーク操作による画面移動の識別が容易になる。
図８はキャリブレーション処理の流れ図である。カメラ動き推定部１２１がキャリブレーション処理に入ると、まずパラメータの初期化が行われる（Ｓ８０１）。図８では具体的には、カメラ操作動きパラメータＭＰ、現在フレームのカメラ操作の種類を示すパラメータＰＴ１、直前のカメラ操作の種類を示すパラメータＰＴ０、およびカウンタＣＴＲを初期化する。ここでＭＰは上述の数式（２）、（３）、および（４）の３つのパラメータの組（Ｍｘ、Ｍｙ、Ｍａ）であり、初期値はＭＰ＝（０，０，１）を与える。ＰＴ０とＰＴ１は、パン操作を表す”Ｐ”、チルト操作を表す”Ｃ”、ズーム操作を表す”Ｚ”のいずれかの値をとり、ここではＰＴ０とＰＴ１の初期値を”Ｐ”とする（初期値は特に”Ｐ”でなくてもよい）。ＣＴＲはカウンタであり、０を初期値とする。
そして次の動きベクトル１１９をビデオ復号部１１８より取得し、この動きベクトルから、前フレームからの移動パラメータ（Ｆｘ、Ｆｙ、ａのいずれか）を求める（Ｓ７００〜Ｓ７０８）。これらのステップにおける処理は、前述の図７と同様である。ただし図８に示すように、ステップＳ７０３、Ｓ７０５、Ｓ７０７においてそれぞれ、現フレームのカメラ操作種類を示すパラメータＰＴ１を更新する。
もしもＦｘ、Ｆｙ、ａのいずれかのパラメータが求められ、ＰＴ１が、直前のカメラ操作種類を示すパラメータＰＴ０と等しいか、もしくはカウンタＣＴＲが０である場合（Ｓ８０２）、パラメータＭＰ（Ｍｘ、Ｍｙ、Ｍａ）を更新する（Ｓ８０３）。具体的にステップＳ８０３では、もしも現フレームの動きがパン操作の場合（すなわちＰＴ１＝＝”Ｐ”）、ＭｘにＦｘを加算する。同様にもしも現フレームの動きがチルト操作の場合（すなわちＰＴ１＝＝”Ｃ”）、ＭｙにＦｙを加算する。もしも現フレームの動きがズーム操作の場合（すなわちＰＴ１＝＝”Ｚ”）、ＭｘとＭｙをａで除算した値をそれぞれ新たにＭｘ、Ｍｙとし、Ｍａにａを乗算した値を新たにＭａとする。
そしてＰＴ０をＰＴ１で置換し、カウンタＣＴＲに１を加算する（Ｓ８０６）。そして次の動きベクトル１１９の取得を行い、再び同様の処理を行う（Ｊ１）。もしもステップＳ８０２の条件判定で“ＮＯ”の場合、もしくはカメラ操作なしと判定された場合（Ｓ７０８）には、上述のパラメータＭＰ（Ｍｘ、Ｍｙ、Ｍａ）の３つの要素が全て求められたかどうかを判定（Ｓ８０４）する。ステップＳ８０４の条件判定で“ＮＯ”の場合、カウンタＣＴＲを０にリセット（Ｓ８０７）し、次の動きベクトル１１９の取得を行い、再び同様の処理を行う（Ｊ１）。ステップＳ８０４の条件判定で“ＹＥＳ”の場合、パラメータＭＰをカメラ操作動きパラメータ１３０としてカメラ操作動きパラメータ記憶部１０１へ出力し（Ｓ８０５）、キャリブレーション処理を終了する。
以上に述べたキャリブレーション処理により、ユーザがパン・チルト・ズーム操作を一回行ったときのカメラ操作動きパラメータ１３０の初期値が得られ、カメラ操作動きパラメータ記憶部１０１に保持される。
以上に述べたように、カメラ動き推定部１２１においては、ＵＩモジュール１６０の起動直後に行われるキャリブレーション処理（すなわち、カメラ操作動きパラメータ１３０の初期値を求める処理）と、カメラ映像を受信したときの現フレームのカメラ動き推定処理（すなわちフレーム間動きパラメータ１１６を求める処理）、の２つが行われる。
次に、上述のカメラ動き推定処理によって得られたフレーム間動きパラメータ１１６に基づいて、カメラ操作動きパラメータ記憶部１０１内の動きパラメータがどのように更新されるかについて説明する。
図９は、カメラ操作動きパラメータ記憶部１０１において、カメラ動き推定部１２１が出力するフレーム間動きパラメータ１１６に基づいた、カメラ操作動きパラメータ１３０の変更処理の流れを示す図である。カメラ操作動きパラメータ記憶部１０１では、同図に示すように、もしもカメラ動き推定部１２１においてズーム操作が検出された場合（Ｓ９０２）、カメラ上での画像の平行移動量が変わるため、前述のカメラ操作動きパラメータ１３０のＦｘとＦｙをズームパラメータ値ａで除算した値をそれぞれ新たにＦｘ、Ｆｙとする（Ｓ９０３）。なおカメラ操作動きパラメータ１３０の初期ズームパラメータ値は変更されない。
上述のような更新処理をカメラ操作動きパラメータ記憶部１０１において行うことで、受信したカメラ映像のズーム倍率が変化した場合においても、ユーザのカメラワーク操作による、現在表示している画像上の視野範囲の推定を正しく行うことが可能となる。
次に図１０を参照して、視野範囲生成部１０９における処理の流れを説明する。視野範囲生成部１０９は、視野範囲位置情報１１０を生成し、これを描画部１１４へ渡す。前述のように描画部１１４では、この視野範囲位置情報１１０を元にして視野範囲を示す画像信号を生成し、これをフレーム画像信号１１３の上にオーバレイ表示する。
本実施形態１では、ＵＩモジュール１６０がカメラ制御モードである場合に限り、カメラ制御操作による推定視野範囲をユーザに提示する。ここでカメラ制御モードとは、ＵＩモジュール１６０のインタフェースにより、ユーザがパン・チルト・ズームなどのカメラ制御操作を行うことができる状態を指す。
図１０中、ステップＳ１００１では、ＵＩモジュール１６０がカメラ制御モードであるかどうかを判断し、カメラ制御モードでなければ視野範囲生成処理を終了する。
もしもステップＳ１００１においてカメラ制御モードである場合、前述の視野範囲推定部１０４において推定された、推定視野範囲位置情報１０８を取得する（ステップＳ１００２）。次に前述のカメラ動き推定部１２１において推定されたフレーム間動きパラメータ１１６を取得する（ステップＳ１００３）。
そしてカメラ動き推定部１２１において、次に表示されるフレーム画像に、カメラワークによる動きが検出されたかどうかを判定する（ステップＳ１００４）。もしもステップＳ１００４においてカメラワークが検出されなかった場合には、前述の推定視野範囲位置情報１０８を、視野範囲位置情報１１０とする（ステップＳ１００６）。
もしもステップＳ１００４においてカメラワークが検出された場合には、前述のフレーム間動きパラメータ１１６による座標変換を推定視野範囲位置情報１０８に対して施し、この変換結果を視野範囲位置情報１１０とする（ステップＳ１００５）。このようにフレーム毎に画面全体の動きによる座標変換を、推定される視野範囲位置情報に対しても施すことにより、カメラ制御モードにおいて、推定視野範囲を表示している最中に、カメラワークによる映像の移動が生じた場合にも、正しく視野範囲を推定して表示することができる。
上述のように計算された視野範囲位置情報１１０は前述の描画部１１４と、前述の視野範囲記憶部１２２に送られる（ステップＳ１００６）。前述のように、描画部１１４ではこの視野範囲位置情報１１０を用いて、同じく描画部１１４に送られたフレーム画像信号１１３上に視野範囲を示す画像信号をオーバレイ表示する。以上の処理を、ＵＩモジュール１６０がカメラ制御モードである間繰り返すことで、ユーザがカメラ制御操作を行う度に、現在の映像における視野範囲を連続的に推定し、ユーザに提示することが可能となる。
ここで図１１、および図１２を参照し、描画部１１４において、上述の視野範囲生成部１０９が生成する視野範囲位置情報１１０と受信フレーム画像信号１１３との関係について説明する。図１１では、上述のステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出されなかった場合のインタフェース表示例を説明する。図１２では、上述のステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出された場合のインタフェース表示例を説明する。
図１１は、パン操作（図１１上列）、およびズーム操作（図１１下列）を行ったときの描画部１１４が表示するインタフェース画面の流れを示す。図１１のインタフェース画面Ｍ１は、パン、又はチルト操作を行うためのカメラ制御モード画面である。この状態で、ユーザの矢印ボタンの押下によりパン又はチルトのカメラ操作要求が行われるものとする。カメラ制御モードの状態では、現在の視野範囲を示す矩形枠１１０１と、現在の視野の中心軸を示す小矩形枠１１０２が表示される。インタフェース画面Ｍ１の状態では、矩形枠１１０１は描画領域と一致しており、かつ小矩形枠１１０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ１の状態において「←」（左矢印）ボタンを押下すると、視野範囲生成部１０９では上で述べた処理により、推定視野範囲位置情報１０８を元に矩形枠１１０１と小矩形枠１１０２の画像信号を生成する。そして生成された矩形枠１１０１と小矩形枠１１０２は、そのまま描画部１１４にてフレーム画像信号１１３上にオーバレイ表示される。このときの画面の状態を図５のインタフェース画面Ｍ２に示す。
インタフェース画面Ｍ２に示すように、視野範囲の矩形枠１１０１と小矩形枠１１０２が左へ移動している。インタフェース画面Ｍ２では、左矢印ボタン操作によるカメラ制御要求は配信サーバ２０２に送信されているが、上述のように最低でもフラグメント時間長分の遅延が生じ、かつ上述のように図９のインタフェース画面Ｍ１、Ｍ２では、パン・チルトモードでボタン操作を行う間に、過去のカメラ制御操作による動画像の大きな動きはない（図１１では、図１０中のステップＳ１００４において、カメラ制御モードの間はカメラワークが検出されないと仮定しているため）ため、フレーム画像信号１１３はインタフェース画面Ｍ１とほぼ同じまま（図１１では背景の木は中央で止まった状態）である。
ユーザは所望のパン・チルト操作が終了すると、何らかのボタン操作によりカメラ制御モードを終了し、通常モードへ移行する。通常モードでは、上述の視野範囲を示す矩形枠は表示されない。そして左向きのパン操作が行われた映像は、最低でもフラグメント時間長分の遅延時間後に、ＵＩモジュール１６０で受信され、最終的に描画部１１４において表示される。最終的に左向きパン操作の映像が表示された状態の画面をインタフェース画面Ｍ３に示す。
インタフェース画面Ｍ４は、ズーム操作を行うためのカメラ制御モードにおける画面である。この状態では、ユーザの「＋」「−」ボタン押下によりズームイン、ズームアウトのカメラ操作要求が行われるものとする。インタフェース画面Ｍ４でもＭ１と同様に、現在の視野範囲を示す矩形枠１１０１と、現在の視野の中心軸を示す小矩形枠８０２が表示される。インタフェース画面Ｍ４では、矩形枠１１０１は描画領域と一致しており、かつ小矩形枠１１０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ４の状態において、「＋」ボタン（ズームイン操作）を押下すると、上述のように視野範囲推定部１０４において、この「＋」ボタン操作による、現画面上での視野範囲が推定され、描画部１１４にてフレーム画像信号１１３上にオーバレイ表示される。このときの画面の状態を図１１のインタフェース画面Ｍ５に示す。
インタフェース画面Ｍ５では、ズームイン操作により矩形枠１１０１が縮小しており、縮小の中心点は元の描画領域の中心点と同じであるため、小矩形枠１１０２は描画領域の中心位置に表示されている。ここで本実施形態１では、小矩形枠１１０２は中心位置を示すための枠であるため、拡大・縮小は行わないものとする。インタフェース画面Ｍ５の状態では、「＋」ボタン操作によるカメラ制御要求は配信サーバ２０２に送信されているが、前述のインタフェース画面Ｍ２と同様に遅延が生じるため、フレーム画像信号１１３はインタフェース画面Ｍ４と同じ背景映像のままである。
ユーザは所望のズームイン操作が終了すると、何らかのボタン操作によりカメラ制御モードを終了し、上述と同様に、通常モードへ移行する。通常モードでは、上述の視野範囲を示す矩形枠は表示されない。そしてズーム操作が行われた映像は、最低でもフラグメント時間長分の遅延時間後に、ＵＩモジュール１６０で受信され、最終的に描画部１１４において表示される。最終的にズームイン操作の映像が表示された状態の画面をインタフェース画面Ｍ６に示す。
次に図１２を参照し、図１０におけるステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出された場合のインタフェース画面表示例を説明する。
図１２は、パン操作とチルト操作を行い、カメラ制御モードの状態でしばらく経過後、パン操作、チルト操作によるカメラワークが反映された映像を受信したときの、ＵＩモジュール１６０のインタフェース画面の流れを示している。図１２のインタフェース画面Ｍ７は、パン、又はチルト操作を行うためのカメラ制御モード画面である。この状態で、ユーザの矢印ボタンの押下によりパン又はチルトのカメラ操作要求が行われる。インタフェース画面Ｍ７の状態では、矩形枠１２０１は描画領域と一致しており、かつ小矩形枠１２０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ７の状態において「←」（左矢印）ボタンを押下すると、上に述べた処理により、インタフェース画面Ｍ８の画面が提示される。同様にインタフェース画面Ｍ８の状態において「↑」（上矢印）ボタンを押下すると、上に述べた処理により、インタフェース画面Ｍ９の画面が提示される。
インタフェース画面Ｍ９のままの状態でカメラ制御モード状態を保持し続けると、やがてインタフェース画面Ｍ７の状態における左向きのパンニング操作が反映された映像を受信する。このとき図１０のステップＳ１００４においてカメラワークによる動きが検出される。すなわち、左向きのパンニング操作により、相対的に背景画面の右向きの動きが検出されるので、矩形枠１２０１と小矩形枠１２０２を、インタフェース画面Ｍ９の状態から右向きに移動させることで、インタフェース画面Ｍ１０のような画面となる。
同様に、インタフェース画面Ｍ１０の状態で、インタフェース画面Ｍ８の状態における上向きのチルト操作が反映された映像を受信すると、相対的に背景画面の下向きの動きが検出されるので、矩形枠１２０１と小矩形枠１２０２を、インタフェース画面Ｍ９の状態から右向きに移動させることで、インタフェース画面Ｍ１０のような画面となる。
以上に述べたように、カメラ制御モードの間（つまり現在の推定視野範囲を表示しているとき）に、過去のカメラワークにより背景画像が大きく動いても、その動きに合わせて推定視野範囲を移動させることにより、適切な推定視野範囲をユーザに提示することができる。
以上に述べたように、本発明の実施形態１のカメラ制御インタフェース装置では、カメラ映像を受信するまでの遅延が大きい場合でも、推定される視野範囲を直ちにユーザに提示できるので、ユーザの遠隔カメラ操作の利便性を向上させることができる。また、カメラ制御モードでユーザが遠隔カメラ操作を行っている際に、過去のカメラワーク制御による映像の移動が生じた場合でも、常に正しい推定視野範囲をユーザに対し提示することができる。
次に本発明の実施形態２によるカメラ制御インタフェース装置について説明する。
本発明の実施形態２では、実施形態１の変形例として、カメラ２０４においてカメラワークが行われているか否かを示す状態フラグ２１０を、撮影映像２０５と同期させて常にエンコーダ２０３に送る。エンコーダ２０３では各動画フレームが、カメラワークが行われているかどうかを示す状態フラグ２１０を、各フラグメント１１１内のヘッダ情報（前述のように、ｍｏｏｖに相当）内に格納する。
図１３に実施形態２によるカメラ制御ユーザインタフェース装置における、ＵＩモジュール１６１のブロック図を示す。実施形態２では、多重分離部１１２において、各動画像符号化データ１２０内のフレームと同期して、そのフレームではカメラワークが行われているかどうかを示す状態フラグ２１０を抽出し、この状態フラグ２１０をカメラ動き推定部１２１に渡すことを特徴とする。
実施形態１によるＵＩモジュール内のカメラ動き推定部１２１では、カメラ２０４から撮像されている画像内では、移動する物体は十分小さく、画像全体を占める映像の大部分の動きが極めて少ない背景であると仮定していた。このため、もしも移動物体が画像全体に占める割合が大きい場合には、実際にはカメラが動いていないときにも、誤ってカメラ動きと判定しまう問題がある。
実施形態２では、ＵＩモジュール１６１におけるカメラ動き推定部１２１において、フレーム毎にカメラワークが行われているかどうかを示す状態フラグ２１０を調べ、同フラグ２１０によりカメラワークが行われていることが指示されている場合にのみ、上に述べたフレーム間動きパラメータ１１６を推定する。以上のような処理により、移動物体が画面内に存在した場合にも、カメラ動きの誤判定を防ぐことが可能となる。
次に本発明の実施形態３によるカメラ制御インタフェース装置について説明する。
本発明の実施形態３では、実施形態１、２の変形例として、ユーザのカメラ制御操作による視野範囲の移動履歴を保持し、ある視野範囲移動時刻（すなわちカメラ制御操作時刻）と、そのカメラ制御操作が反映された映像を受信し、再生する時刻との差を算出し、この差を遅延時間としてユーザに提示する機能を備える。図１４に実施形態３によるカメラ制御ユーザインタフェース装置における、ＵＩモジュール１６２のブロック図を示す。実施形態３によるＵＩモジュール１６２は、図１３に示した実施形態２のＵＩモジュール１６１内に、視野範囲移動履歴記憶部１０６が追加された構成となる。すなわち視野範囲移動履歴記憶部１０６では、ユーザのカメラ制御操作による視野範囲の変更が発生すると、推定視野範囲位置情報１０８を受け取り、その変更時刻を保持する。図１４内の視野範囲生成部１０９では、カメラ動き推定部１２１から現フレームのフレーム間動きパラメータ１１６を受け取ると、このカメラ動きを検出した時刻Ｕを保持し、対応する視野範囲移動時刻Ｖを視野範囲移動履歴記憶部１０６から取得し、Ｕ−Ｖを遅延時間としてユーザに提示する画像信号を、上述の視野範囲を示す視野範囲位置情報１１０に加え、これが描画部１１４においてオーバレイ表示される。
以上のように、実施形態３によるカメラ制御インタフェース提示装置では、ユーザに対し、推定される視野範囲に加え、遅延時間を提示することができる。このためユーザは、ユーザが現在行ったカメラワーク制御操作が、何秒後に受信映像に反映されるかがわかるため、大きな遅延によるユーザの不便感を軽減することが可能となる。
次に本発明の実施形態４によるカメラ制御インタフェース装置について説明する。本発明の実施形態４では、実施形態１の変形例として、実施形態１によるＵＩモジュール１６０内の、カメラ動き推定部１２１において行っていたキャリブレーション処理と、動きパラメータ推定処理とを配信サーバ２０２にて行い、推定されたパラメータ値を本実施形態４のカメラ制御インタフェース装置に送信することを特徴とする。
実施形態４によるカメラ制御インタフェース装置を用いたカメラ制御システムの全体構成は、図２と同様である。図１５に、実施形態４によるカメラ制御システムの配信サーバ２０２におけるカメラ制御モジュール１５００の構成を示す。カメラ制御モジュール１５００内のカメラ制御要求受信部１５０１において、携帯端末１１５からのカメラ制御要求２０１が受信されると、カメラ制御コマンド生成部１５０２はカメラ制御要求２０１をカメラ２０４が解析可能なカメラ制御コマンド２０７に変換し、カメラ２０４へ送信する。カメラ制御モジュール１５００は、最低でもフラグメント時間長Ｔの遅延時間後に、エンコーダ２０３から、カメラ制御コマンド２０７によるカメラワークが行われた映像がフラグメント２０６を受信する。
カメラ制御モジュール１５００内では、受信したフラグメント２０６から、多重分離部１５０６において動画像符号化データ１２０を取得する。取得された動画像符号化データ１２０は、カメラ動き推定部１５０８とビデオ復号部１５０９におくられ、キャリブレーション処理と、動きパラメータ推定処理とが行われる。これらの処理の流れは実施形態１と同様である。
カメラ制御モジュール１５００内のカメラ操作動きパラメータ記憶部１５０７における、動きパラメータ更新処理の流れは実施形態１と同様である。
携帯端末１１５が、配信要求２００を配信サーバ２０２へ送ると、多重分離部１５０６において取得された動画像符号化データ１２０は逐次、多重部１５０４へ送られる。またこの動画像符号化データ１２０が最初に多重部１５０４へ送られた時刻におけるカメラ操作動きパラメータ１５０５が、カメラ操作動きパラメータ記憶部１５０７から多重部１５０４へ送られる。また２つ目以降の動画像符号化データ１２０に対しては、この動画像符号化データに対応するフレーム間動きパラメータ１１６をカメラ動き推定部１５０８から取得する。
多重部１５０４は、最初の動画像符号化データ１２０に対してはカメラ操作動きパラメータ１５０５を、２つ目以降の動画像符号化データ１２０に対してはそれぞれについてフレーム間動きパラメータ１１６を、各々対応づけて多重化し、携帯端末１１５で解析可能なフラグメント１１１を生成する。フラグメント１１１において、カメラ操作動きパラメータ１３０とフレーム間動きパラメータ１１６は、例えば図４に示したＭＰ４形式のフラグメント内のヘッダ情報として格納される。生成されたフラグメント１１１は、携帯端末１１５へ送信される。
図１６に、本発明の実施形態４によるカメラ制御インタフェース装置におけるＵＩモジュール１６３のブロック図を示す。ＵＩモジュール１６３は、実施形態１におけるＵＩモジュールから、カメラ動き推定部１２１を除いた構成となる。
ＵＩモジュール１６３では、配信サーバ２０２からフラグメント１１１を受信すると、これを多重分離部１１２へ渡す。多重分離部１１２では、動画像符号化データ１２０をフラグメント１１１から取得し、これをビデオ復号部１１８へ渡す。また同時に多重分離部１１２では、前述の先頭の動画像符号化データ１２０と時間的に同期した、カメラ操作動きパラメータ１５０５をフラグメント１１１から取得し、これをカメラ操作動きパラメータ記憶部１０１に渡す。そして先頭以外の動画像符号化データ１２０と時間的に同期した、フレーム間動きパラメータ１１６をフラグメント１１１から取得し、これを視野範囲生成部１０９へ送ると同時に、カメラ操作動きパラメータ記憶部１０１へ渡す。
カメラ操作動きパラメータ記憶部１０１においては、多重分離部から取得したカメラ操作動きパラメータ１５０５を初期値として保持し、フレーム間動きパラメータ１１６を取得すると、図９で述べた処理と同様に、カメラ操作動きパラメータ１５０５を更新する。
ＵＩモジュール１６３では、カメラ操作動きパラメータ１５０５を元に視野範囲推定部１０４において視野範囲の位置座標を推定する。
以降、推定された視野範囲が視野範囲生成部１０９において生成され、描画部１１４においてオーバレイ表示されるまでの処理は、実施形態１におけるＵＩモジュール１６０と同様である。
実施形態１によるカメラ制御インタフェース装置では、キャリブレーション処理を、ＵＩモジュール１６０の起動直後に行うことを想定していたため、本発明のように映像の遅延が大きい場合には、キャリブレーション処理に要する時間が長くなるという問題があった。また、携帯端末上にて動きベクトルや動きパラメータの推定処理などを行う必要があるため、携帯端末上における処理量が多くなるという問題があった。
以上のように、実施形態４によるカメラ制御インタフェース装置では、上述のカメラ動き推定処理を全て配信サーバにて行う。すなわちＵＩモジュール１６３では、配信サーバ２０２におけるカメラ制御モジュール１５００において推定されたカメラ操作動きパラメータ１５０５を、実施形態１によるキャリブレーション処理の代わりの初期値として用いることができる。また実施形態１によるカメラ動き推定部におけるフレーム間動きパラメータ１１６についても、配信サーバ２０２におけるカメラ制御モジュール１５００にて推定された値を受信し、これを用いて視野範囲を推定することができる。このため、実施形態４によるカメラ操作制御インタフェースは、実施形態１に比べてユーザインタフェース提示における処理量を大幅に軽減できる。
【０００６】
【発明の効果】
本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザの操作を反映した視野範囲を予測し、直ぐにユーザに提示することができるため、ユーザに対し快適なカメラ操作インタフェースを提供することができる。
また本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、遅延時間をユーザに対し提示することができるため、遅延が大きいことによるユーザのカメラ操作の不快さを軽減できるという効果がある。
さらに本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザ操作の視野範囲を予測する処理を配信サーバにて行うことができるため、携帯端末上で多くの処理を行わずに、ユーザに対し快適なカメラ操作インタフェースを提供することができる。
以上に述べたように本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザに対し快適なカメラ操作インタフェースを効率よく提供できる。本発明は特に携帯電話網のような通信速度の変動が激しい通信網において有用である。従って現在広く普及している携帯端末を利用することで、安価な遠隔監視サービスの提供が可能となり、安全管理や作業管理など幅広い用途における監視サービスの普及に貢献できる。
【図面の簡単な説明】
【図１】本発明の実施形態１によるカメラ制御ユーザインタフェースモジュールの構成を示すブロック図。
【図２】本発明の実施形態１によるカメラ制御システムの全体構成図。
【図３】本発明の実施形態１によるカメラ制御システムの処理の時間的流れを示す図。
【図４】ＭＰ４形式によるフラグメントの構成図。
【図５】本発明の実施形態１によるカメラ制御インタフェース装置の例を示す図。
【図６】本発明の実施形態１によるカメラ制御要求のデータフォーマット例を示す図。
【図７】本発明の実施形態１によるカメラ動き推定部の処理を示すフローチャート。
【図８】本発明の実施形態１によるキャリブレーション処理を示すフローチャート。
【図９】本発明の実施形態１によるカメラ操作動きパラメータ記憶部における動きパラメータの更新処理を示すフローチャート。
【図１０】本発明の実施形態１による視野範囲生成部における処理を示すフローチャート。
【図１１】本発明の実施形態１による描画部において、カメラ制御モード中にカメラワークが起こらなかった映像を受信した場合の、視野範囲とフレーム画像の関係を示す図。
【図１２】本発明の実施形態１による描画部において、カメラ制御モード中にカメラワークが起こった映像を受信した場合の、視野範囲とフレーム画像の関係を示す図。
【図１３】本発明の実施形態２によるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【図１４】本発明の実施形態３によるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【図１５】本発明の実施形態４による、配信サーバにおけるカメラ制御モジュールの処理構成を示すブロック図。
【図１６】本発明の実施形態４による、携帯端末におけるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【符号の説明】
１００・・・ユーザ操作検出部
１０１・・・カメラ操作動きパラメータ記憶部
１０２・・・カメラ制御ボタン押下情報
１０４・・・視野範囲推定部
１０６・・・視野範囲移動履歴記憶部
１０８・・・推定視野範囲位置情報
１０９・・・視野範囲生成部
１１０・・・視野範囲位置情報
１１１・・・フラグメント
１１２・・・多重分離部
１１３・・・フレーム画像信号
１１４・・・描画部
１１５・・・携帯端末
１１６・・・フレーム間動きパラメータ
１１７・・・カメラ制御要求生成部
１１８・・・ビデオ復号部
１１９・・・動きベクトル
１２０・・・動画像符号化データ
１２１・・・カメラ動き推定部
１２２・・・視野範囲記憶部
１３０・・・カメラ操作動きパラメータ
１６０・・・ユーザインタフェース（ＵＩ）モジュール
１６１・・・実施形態２によるユーザインタフェース（ＵＩ）モジュール
１６２・・・実施形態３によるユーザインタフェース（ＵＩ）モジュール
１６３・・・実施形態４によるユーザインタフェース（ＵＩ）モジュール
２００・・・配信要求
２０１・・・カメラ制御要求
２０２・・・配信サーバ
２０３・・・エンコーダ
２０４・・・カメラ
２０５・・・撮影映像
２０６・・・フラグメント
２０７・・・カメラ制御コマンド
２１０・・・（フレームでカメラワークが行われているかどうかを示す）状態フラグ
１１０１、１２０１・・・現在の視野範囲を示す矩形枠
１１０２、１２０２・・・現在の視野の中心軸を示す小矩形枠
１５００・・・実施形態４による配信サーバにおけるカメラ制御モジュール
１５０１・・・カメラ制御要求受信部
１５０２・・・カメラ制御コマンド生成部
１５０４・・・多重部
１５０５・・・カメラ操作動きパラメータ
１５０６・・・多重分離部
１５０７・・・カメラ操作動きパラメータ記憶部
１５０８・・・カメラ動き推定部
１５０９・・・ビデオ復号部
Ｂ１・・・「上」「下」「左」「右」方向矢印ボタン
Ｂ２・・・「＋」ボタン
Ｂ３・・・「−」ボタン
Ｂ４・・・画像表示領域
Ｍ１〜Ｍ１１・・・インタフェース画面。
【発明の属する技術分野】
本発明は、パン、チルト、およびズーム制御機能を有するカメラを遠隔制御するためのユーザインタフェース提示装置とシステムに関するものであり、特にカメラ映像の遅延が大きい場合のユーザインタフェース提示装置とシステムに関するものである。
【０００２】
【従来の技術】
近年のモバイル通信技術の急速な進展に伴い、携帯電話やＰＤＡなどの携帯端末は、これまでの音声通話のみでなく、文字や画像、さらに動画像を用いた高度なコミュニケーションを可能とするマルチメディアツールへと進化してきている。２００２年には通信キャリア会社が、携帯電話への映像コンテンツダウンロードサービスやＴＶ電話サービスを開始しており、ユーザはいつでもどこでも携帯端末により動画像を手元で楽しむことができるようになる。
こうした携帯端末を用いたアプリケーションとして、携帯端末による遠隔制御可能な監視カメラサービスがある。近年の世界規模でのテロ事件の多発や犯罪率の増加を背景に、一般家庭でも防犯意識が高まってきており監視カメラサービスの需要は今後さらに大きくなると考えられる。さらに、日本では急速な高齢化や共働き世帯の増加といった社会的背景からも、一般家庭において安価な監視カメラサービスの潜在需要は大きいと推測される。
しかし携帯端末の無線通信網は一般的に伝送路誤りの発生が多く、パケットロスが大きい。このため無線通信網向け映像配信サービスでも、ダウンロードサービスのような遅延が許容される用途では、一般的に再送要求をともなう伝送プロトコル（例えばＴＣＰ）が用いられる。一方、ＴＶ電話などのリアルタイム性が重視される（遅延に対する制限が厳しい）用途では、再送要求をともなわない伝送プロトコル（例えばＵＤＰ）が用いられることが多い。再送要求をともなわない伝送プロトコルでは、ＦＥＣ（前方誤り訂正符号）を用いることで、損失データを回復することが可能であるが、ＦＥＣによりデータの冗長性が増すため、伝送データ量が増加する。このためＦＥＣを適用する際は、誤り訂正能力と伝送ビットレートのトレードオフを考慮する必要があるため、伝送容量の小さい無線通信網ではＦＥＣで回復できないデータ損失が頻繁に発生し、映像品質劣化につながる場合が多い。
このようにリアルタイム性を重視する場合にはデータ損失による劣化が常に問題となるが、遅延制限を緩和することにより、映像の品質を向上できる場合が多い。従来の監視カメラサービスでは、インターネット網のような高速かつデータ損失がほとんど発生しない通信路を前提とした、リアルタイム映像配信が一般的であった。これに対し、携帯通信網において監視カメラサービスを提供するためには、必ずしもリアルタイム配信であることがユーザへのサービスとして優れていることにはならない。つまり監視カメラサービスに対して時間遅延を許容することで、映像品質の向上が期待でき、また既存のダウンロード配信サービスのインフラを共用することでコストを削減できれば、ユーザに対してより望ましいサービスを実現できる可能性がある。
そして上記のような、映像の遅延を考慮した遠隔カメラ制御の方法として、例えば特許文献１、特許文献２が提案されている。
【０００３】
【特許文献１】特開平１０−３４１３７１号公報
【特許文献２】特開平６−３８０８７号公報
【発明が解決しようとする課題】
しかし従来の監視カメラサービスでは、リアルタイムな映像配信を前提としていたため、ユーザのカメラ制御操作に対する映像の応答の遅延が大きい場合を想定したカメラ制御ユーザインタフェースが考慮されていない。このため、映像の遅延が大きい場合には、ユーザがカメラ制御操作を行っても、制御操作の結果の映像を視野の移動として直ぐに確認することができないため、ユーザが意図した視野と、遅延時間後に応答した実際の映像の視野とが異なってしまい、ユーザは快適にカメラを制御できないという問題があった。
上記の第一従来例は、映像の遅延を考慮したカメラ制御方法を提案している。しかしこの第一従来例はカメラ映像の解像度や撮像範囲を小さくすることでカメラ映像の情報量を削減し、映像遅延を減少させる方法であるため、情報量に関わらず最低限のバッファリング遅延時間が生じるような映像配信方式においては、遅延を削減することはできず、効果が期待できない。
また上記の第二従来例は、映像の遅延時間を考慮してカメラ制御のずれを補正する方法を提案している。しかしこの方法では遠隔カメラ操作を終えた後に、遅延時間を考慮してカメラ制御のずれ補正を行うため、遠隔ユーザがカメラを操作している最中に、映像遅延による操作の不便を解消することはできない。また上記の第二従来例の方法が適用できる映像遅延時間は高々数秒程度であり、最低でも数十秒程度の映像遅延が生じるような映像配信方式には適用することはできない。
本発明の目的は、上記の事情を鑑みてなされるものであり、ユーザのカメラ制御操作に対する映像の応答の遅延が大きいような場合であっても、ユーザに対し快適なカメラ制御インタフェースを提供することである。
【０００４】
【課題を解決するための手段】
上記目的を達成するため、本発明のカメラ制御ユーザインタフェース装置では、ユーザのカメラ制御操作に対応するカメラ映像の視野を予測し、予測された視野範囲を直ぐにユーザに提示することを特徴とする。
本特徴により、ユーザは、映像の遅延が大きい場合であってもカメラ制御操作に対する映像の視野を直ぐに確認することができるので、快適にカメラを制御することが可能となる。
【０００５】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。
図１は、本発明の実施形態１によるカメラ制御ユーザインタフェース装置における、ユーザインタフェースモジュール（以下、ＵＩモジュール）１６０の構成を示す図である。実施形態１では、遠隔カメラのカメラワークに関する情報がクライアントへ全く提供されない条件の下で、ユーザのカメラ制御操作に対する推定視野を提示する。
図２は、本発明の実施形態１によるＵＩモジュール１６０を用いた、カメラ制御システムの全体構成を示す図である。図２において、携帯端末１１５はＵＩモジュール１６０を内部に備え、無線通信網によって配信サーバ２０２と接続されている。配信サーバ２０２とエンコーダ２０３、およびカメラ２０４はＬＡＮなどの高速かつロスがほとんど発生しない通信網で常時接続されている。ただしエンコーダ２０３とカメラ２０４が通信網を介さずに一体となった構成や、さらに配信サーバ２０２とエンコーダ２０３、およびカメラ２０４が一体となった構成も可能である。
図３は、図２のカメラ制御システムの全体構成の時間的流れを示す図である。図３を参照して、本発明の実施形態１によるユーザインタフェース装置を用いた、カメラ制御システムの処理の流れを説明する。
カメラ２０４は、撮影映像２０５をエンコーダ２０３へ常時送信する。
エンコーダ２０３は、撮影映像２０５を符号化し、フラグメント２０６を生成する。フラグメント２０６の符号化方式としては、例えばＩＳＯ／ＩＥＣ １４４９６−２（以下、ＭＰＥＧ−４ Ｖｉｄｅｏ）で定められる符号化方式により動画像符号化を行い、この動画像符号化データをＩＳＯ／ＩＥＣ １４４９６−１で定めるＭＰＥＧ−４ Ｆｉｌｅ Ｆｏｒｍａｔ（以下、ＭＰ４と記す）形式で格納する方式がある。実際のカメラでは、通常は動画だけではなくマイクロフォンからの入力音声も符号化対象としても良い。
図４に、例としてＭＰ４形式によるフラグメント２０６の構成図を示す。ＭＰ４形式において、個々のフラグメントはヘッダ情報とメディアデータとで構成される。フラグメントのヘッダ情報はＭｏｖｉｅ Ｂｏｘ（以下、ｍｏｏｖと記す）の形式で格納され、メディアデータは、Ｍｅｄｉａ Ｄａｔａ Ｂｏｘ（以下、ｍｄａｔと記す）の形式で格納される。ｍｄａｔ内には動画像符号化データが格納されている。ｍｏｏｖ内には、ｍｄａｔ内の動画像符号化データへアクセスするための位置情報やタイムスタンプなどの基本情報が格納される。このため個々のフラグメントを再生するためには、各フラグメント内のヘッダ情報（ｍｏｏｖ）を初めに受信する必要がある。
図３において、個々のフラグメント２０６内には、ある時間長Ｔに相当する動画像符号化データがまとめて格納される。エンコーダ２０３が時間長Ｔのフラグメント２０６を生成すると、エンコーダ２０３はフラグメント２０６を直ちに配信サーバ２０２へ送信する。フラグメントの時間長Ｔの大きさは原理的には任意だが、以下に示すトレードオフに注意して設定する必要がある。すなわち前述のＭＰ４形式では、フラグメント単位でヘッダ情報と動画像符号化データとを格納するため、フラグメント長Ｔが小さいと、ヘッダ情報が頻繁に生成されるためオーバヘッドが大きくなる。一方でフラグメント長Ｔが大きいと、オーバヘッドは小さくなるが、フラグメントを生成する時間が大きくなるため、エンコードによる遅延時間が大きくなる。従ってフラグメント時間長Ｔの設定は、オーバヘッドとエンコード遅延時間のトレードオフとなる。本発明の実施形態１では、例えばＴを２０秒に設定する。
図３において、携帯端末１１５が配信サーバ２０２に対して配信要求２００を送信すると、配信サーバ２０２は、既にエンコーダ２０３から受信したフラグメント２０６のうち最新のフラグメントを、携帯端末１１５が受信可能な形式のフラグメント１１１を変換し、これを携帯端末１１５へ送信する。ただしフラグメント１１１とフラグメント２０６の形式が同一である場合には、上記の変換処理は必要ない。本発明の説明においては、フラグメント１１１とフラグメント２０６は同一形式であると仮定するが、異なる形式であっても本発明の処理の流れに影響はない。
配信サーバ２０２と携帯端末１１５間の伝送プロトコルには、例えばＴＣＰ／ＩＰを用いる。ＴＣＰ／ＩＰでは伝送エラーによるデータ損失が発生した場合にはデータの再送が行われるため、エラーフリーなデータ伝送が保証される。本発明の実施形態１では、エンコーダ２０３においてフラグメント時間長Ｔの遅延を許容しているため、無線通信網において、時間長Ｔのフラグメント１１１を時間長Ｔ以内で送信できるための十分なスループットが確保されていれば、途中のスループット変動によってデータ損失が起こっても、時間内で再送が行われるため携帯端末１１５において再生映像が劣化することはない。
図３において携帯端末１１５は、フラグメント１１１を受信すると、フラグメント１１１内のヘッダ情報を解析して動画像符号化データを取り出し、ビデオ復号部１１８へ渡す。ビデオ復号部１１８で動画像符号化データを復号後、フラグメント１１１内のヘッダ情報の再生時刻情報に従い、携帯端末１１５上で動画が再生される。なお、フラグメント１１１は無線通信網上で受信するため、受信速度に変動が生じることが多いが、ビデオ復号部１１８内のバッファにおいてデータを蓄えることができるため、前述と同様に、無線通信網で十分なスループットが実現されていれば、携帯端末１１５上で再生される動画像の再生速度が変動することはない。
そして図３において、携帯端末１１５からカメラ制御要求２０１を配信サーバ２０２へ送信すると、配信サーバ２０２は、カメラ制御要求２０１をカメラ２０４が解釈可能なカメラ制御コマンド２０７へ変換し、カメラ２０４へ送信する。カメラ制御要求２０１、およびカメラ制御コマンド２０７には、後述のようにパン・チルト・ズーム動作の命令が格納されている。カメラ２０４は、カメラ制御コマンド２０７を受信すると、これを解析してカメラワークを行い、カメラワークが行われた撮影映像２０５をエンコーダ２０３へ送信する。送信された撮影映像２０５は、上で述べた流れにより、携帯端末１１５にて再生される。
以上に述べたように、本発明の実施形態１のカメラ制御システムでは、カメラ２０４の撮影映像２０５と、最終的に携帯端末１１５上で再生される映像との間には、最低でもフラグメント時間長Ｔ以上の遅延が生じる。ただし前述のように、携帯端末１１５上での再生速度に変動はないため、撮影映像２０５と携帯端末１１５上の再生映像の遅延は一定である。
次に、図１を参照してＵＩモジュール１６０におけるカメラ制御インタフェース提示処理について説明する。
図１において、ＵＩモジュール１６０は本実施形態１によるユーザインタフェース提示装置における、ユーザインタフェース提示処理を行うモジュールである。ユーザ操作検出部１００は、ユーザがカメラ制御を行うボタン押下操作を行ったときの、押下されたボタンの種類を検出する。
図５にＵＩモジュール１６０をカメラ制御に用いるときの、携帯端末のボタンインタフェースの例を示す。同図において、Ｂ１は「上」「下」「左」「右」方向矢印ボタンであり、パン操作に対しては「左」「右」方向ボタンが、チルト操作に対しては「上」「下」方向ボタンがそれぞれ割り当てられる。Ｂ２は「＋」ボタンであり、ズームイン操作に対して割り当てられる。Ｂ３は「−」ボタンであり、ズームアウト操作に対して割り当てられる。Ｂ４は画像表示領域である。
図１のユーザ操作検出部１００は上記の例では、「上」「下」「左」「右」「＋」「−」ボタンのうちどれが押下されたかを示すカメラ制御ボタン押下情報１０２を発行する。本発明の実施形態１では、一度に一つのボタンのみを操作できるものとする。すなわちカメラ制御動作は、一度の動作ではパン、チルト、ズーム操作のいずれかしか行うことができないこととする。
図１のカメラ制御要求生成部１１７は、ユーザ操作検出部１００が発行するカメラ制御ボタン押下情報１０２を受け取り、カメラ制御要求２０１を配信サーバ２０２へ送信する。図６にカメラ制御要求２０１のデータフォーマット例を示す。図中、カメラＩＤは例えば制御対象のカメラのＩＰアドレスや、配信サーバ２０２が管理するカメラＩＤなどである。コマンドタイプは、例えば配信サーバ２０２が管理する、カメラ制御コマンドの種類（パン・チルト・ズーム）を示すインデックスである。値は、それぞれのコマンドに対する値（パン角度、チルト角度、ズーム率）である。前に述べたようにカメラ制御要求２０１は、配信サーバ２０２においてカメラ２０４が解釈可能なカメラ制御コマンド２０７へ変換され、カメラ２０４へ送信される。
図１において、カメラ操作動きパラメータ記憶部１０１には、カメラ操作動きパラメータ１３０が保持される。ここでカメラ操作動きパラメータ１３０とは、パン、チルト、ズームに対応するボタン押下操作一回に対するカメラワークによる再生映像の動きパラメータの推定値である。具体的には以下の関係式を与える３つのパラメータ、ａ、Ｆｘ、Ｆｙである。
（ｘ’， ｙ’） ＝ （ａ ＊ ｘ ＋ Ｆｘ， ａ ＊ ｙ ＋ Ｆｙ） （１）
数式（１）において、（ｘ， ｙ）はカメラワーク前のフレームの画素値、（ｘ’， ｙ’）はカメラワーク後のフレームの画素値、ａは一回のズーム操作による拡大率（ａ＜１でズームイン、ａ＞１でズームアウト）、Ｆｘは一回のパン操作による水平方向の動き量、Ｆｙは一回のチルト操作による垂直方向の動き量である。ただし（ｘ，ｙ）の原点はカメラの光軸、すなわち視野範囲を示す矩形の中心点とする。カメラ操作動きパラメータ記憶部１０１内のカメラ操作動きパラメータ１３０は、予めキャリブレーション処理によって測定された値が初期値として設定され、カメラ動き推定部１２１から得られるフレーム間動きパラメータ１１６に基づいて更新される。キャリブレーション処理、およびフレーム間動きパラメータ１１６に基づいた更新処理の詳細は後述する。
前述のようにパン操作、チルト操作、およびズーム操作はそれぞれ一度ずつ行われると仮定するので、数式（１）は実際には以下の３つの関係式で表される。数式（２）はパン操作、数式（３）はチルト操作、数式（４）はズーム操作を行ったときの画像変換にそれぞれ相当する。
（ｘ’， ｙ’） ＝ （ｘ ＋ Ｆｘ， ｙ） （２）
（ｘ’， ｙ’） ＝ （ｘ， ｙ ＋ Ｆｙ） （３）
（ｘ’， ｙ’） ＝ （ａ ＊ ｘ， ａ ＊ ｙ） （４）
図１において、視野範囲推定部１０４は、ユーザ操作検出部１００からは上述のカメラ制御ボタン押下情報１０２を、カメラ操作動きパラメータ記憶部１０１からはカメラ制御ボタン押下情報１０２に対応するカメラ操作動きパラメータ１３０を、そして視野範囲記憶部１２２からは現在の視野範囲情報１１０をそれぞれ受け取る。ここで視野範囲位置情報１１０は、描画部１１４において表示される視野範囲を示す矩形の中心点の座標、縦の長さ、および横の長さで表される情報である。そして視野範囲推定部１０４は、視野範囲位置情報１１０に対し、カメラ操作動きパラメータ１３０のうちの数式（２）、（３）、および（４）のいずれかのパラメータを用いて変換を施すことにより推定視野範囲位置情報１０８を算出し、視野範囲生成部１０９へ渡す。ここで、推定視野範囲位置情報１０８は、ユーザのカメラ制御操作から推定される視野範囲を示す矩形の中心点の座標、縦の長さ、および横の長さで表される情報である。
視野範囲記憶部１２２では、視野範囲生成部１０９で計算される、描画部１１４において現在表示されている視野範囲の位置情報１１０を記憶する。視野範囲生成部１０９の処理については後述する。
次に図１を用いて、ＵＩモジュール１６０における、データ受信後の処理の流れについて説明する。ＵＩモジュール１６０は、配信サーバ２０２が送信するフラグメント１１１を受信すると、これを多重分離部１１２に渡す。多重分離部１１２は、受信したフラグメント１１１内のヘッダ情報（前述のように、ｍｏｏｖに相当）を解析し、ｍｄａｔ内の動画像符号化データ１２０を取得し、これをビデオ復号部１１８へ渡す。
ビデオ復号部１１８は、動画像符号化データ１２０の復号処理を行い、復号されたフレーム画像信号１１３を描画部１１４へ渡す。
本発明の実施形態１では、ビデオ復号部１１８は現フレーム画像の、直前フレームを参照フレームとする動きベクトル１１９を求め、これをカメラ動き推定部１２１へ渡す。
本実施形態１におけるカメラ制御インタフェース提示装置で用いているＭＰＥＧ−４ Ｖｉｄｅｏなどの動画像符号化方式では、一般的にフレーム間の動き補償が行われており、動画フレームの種類は、フレーム内符号化画像（以降、Ｉフレームと記す）、フレーム間順方向予測符号化画像（以降、Ｐフレームと記す）、フレーム間双方向予測符号化画像（以降、Ｂフレームと記す）に大別される。よって動きベクトル１１９を求めるためには、Ｐフレームの場合には、符号化データ内に直前のフレームを参照画像とする動きベクトル情報が存在するため、これを動きベクトル１１９とすることができる。
一方、ＩフレームかＢフレームのように、直前のフレームを参照する動きベクトルが存在しない場合には、ビデオ復号部１１８内において、現フレームに対し直前のフレーム画像からの動き補償を行い、動きベクトル１１９を求めることができる。動き補償の処理手法として、具体的にはブロックマッチング法や勾配法等の一般的な従来技術を用いることができる。この場合、ビデオ復号部１１８内には、直前フレーム画像と現フレーム画像とを保持するメモリ領域を必要とする。
次に図１における、カメラ動き推定部１２１における処理について説明する。
まず本発明の実施形態１では、カメラ２０４で撮像されている画像内では、移動する物体は十分小さく、画像全体を占める映像の大部分の動きが極めて少ない背景であると仮定する。すなわち移動物体による動きベクトルの影響は無視できるものとする。このような仮定の場合、移動物体のない背景映像で、パン、又はチルト操作を行って、カメラワーク直前とカメラワーク直後のフレーム間の動き補償を行うと、画面領域全体で一定の大きさの動きベクトルが検出され、数式（２）、又は（３）のように近似される。またズーム操作を行うと、動きベクトルは拡大、又は縮小の動きとなり、数式（４）のように近似される。
カメラ動き推定部１２１では、フレーム間動きパラメータ１１６を求める処理と、キャリブレーション処理（詳細は後述する）とが行われる。
図７に、カメラ動き推定部１２１における、フレーム間動きパラメータ１１６を求める処理の流れ図を示す。カメラ動き推定部１２１では、現フレーム画像全体の動きベクトルのヒストグラムを作成し、最も頻度の高い動きベクトル（最尤ベクトル）を求める（Ｓ７０１）。そしてパン、チルト、ズーム操作のいずれかのカメラワークが行われたか、何もカメラワークが行われていないかを推定する。具体的には、Ｓ７０１で求めた最尤ベクトルが、水平方向である（もしくは水平方向と近似できる）場合（Ｓ７０２）、現フレームはパン操作が行われたと判定し、数式（２）のＦｘを求める（Ｓ７０３）。
Ｓ７０２において、最尤ベクトルが水平方向ではないと判定された場合、次に最尤ベクトルが垂直方向かどうか（もしくは、垂直方向と近似できるか）を判定する（Ｓ７０４）。Ｓ７０４で垂直方向と判定された場合、現フレームはチルト操作が行われたと判定し、数式（３）のＦｙを求める（Ｓ７０５）。
Ｓ７０４において、最尤ベクトルが水平方向ではないと判定された場合、次に各画素における動きベクトルと数式（４）を比較し、数式（４）が成り立つ（もしくは、成り立つと近似できる）かどうかを判定する（Ｓ７０６）。数式（４）が成り立つ場合には、現フレームはズーム操作が行われたと判定し、数式（４）のａを求める（Ｓ７０７）。
Ｓ７０６において、数式（４）が成立しないと判定された場合、現フレームにはカメラワークによる画面の移動や拡大・縮小はないと判定する（Ｓ７０８）。
以上のように求められたフレーム間動きパラメータ１１６（Ｆｘ、Ｆｙ、ａのいずれか）は視野範囲生成部１０９と、カメラ操作動きパラメータ記憶部１０１に送られる。視野範囲生成部１０９における処理、およびカメラ操作動きパラメータ記憶部１０１における処理については後述する。
次に、カメラ動き推定部１２１において行われるキャリブレーション処理について説明する。本発明では、カメラ操作動きパラメータ記憶部１０１内に保持するカメラ操作動きパラメータ１３０の初期値を決定する処理をキャリブレーションと称する。具体的には、キャリブレーション処理によって、ユーザがパン・チルト・ズーム操作をそれぞれ一回行ったときの画面の移動パラメータ、すなわち数式（２）のＦｘ、数式（３）のＦｙ、数式（４）のａをそれぞれ求め、これらの組をカメラ操作動きパラメータ１３０の初期値とする。本発明の実施形態１では、このキャリブレーション処理は、ＵＩモジュール１６０を起動直後に自動的に（すなわち、ユーザは意識的にキャリブレーションのための操作は行わない）一度だけ行われるものとする。
また本発明の実施形態１では、キャリブレーション処理により上記のパラメータを個別に推定するために、キャリブレーション処理中は、パン・チルト・ズーム操作をそれぞれ一度だけ行い、かつ各操作の間にはある程度の時間間隔を行うものとする。このような仮定を設けることにより、各カメラワーク操作による画面移動の識別が容易になる。
図８はキャリブレーション処理の流れ図である。カメラ動き推定部１２１がキャリブレーション処理に入ると、まずパラメータの初期化が行われる（Ｓ８０１）。図８では具体的には、カメラ操作動きパラメータＭＰ、現在フレームのカメラ操作の種類を示すパラメータＰＴ１、直前のカメラ操作の種類を示すパラメータＰＴ０、およびカウンタＣＴＲを初期化する。ここでＭＰは上述の数式（２）、（３）、および（４）の３つのパラメータの組（Ｍｘ、Ｍｙ、Ｍａ）であり、初期値はＭＰ＝（０，０，１）を与える。ＰＴ０とＰＴ１は、パン操作を表す”Ｐ”、チルト操作を表す”Ｃ”、ズーム操作を表す”Ｚ”のいずれかの値をとり、ここではＰＴ０とＰＴ１の初期値を”Ｐ”とする（初期値は特に”Ｐ”でなくてもよい）。ＣＴＲはカウンタであり、０を初期値とする。
そして次の動きベクトル１１９をビデオ復号部１１８より取得し、この動きベクトルから、前フレームからの移動パラメータ（Ｆｘ、Ｆｙ、ａのいずれか）を求める（Ｓ７００〜Ｓ７０８）。これらのステップにおける処理は、前述の図７と同様である。ただし図８に示すように、ステップＳ７０３、Ｓ７０５、Ｓ７０７においてそれぞれ、現フレームのカメラ操作種類を示すパラメータＰＴ１を更新する。
もしもＦｘ、Ｆｙ、ａのいずれかのパラメータが求められ、ＰＴ１が、直前のカメラ操作種類を示すパラメータＰＴ０と等しいか、もしくはカウンタＣＴＲが０である場合（Ｓ８０２）、パラメータＭＰ（Ｍｘ、Ｍｙ、Ｍａ）を更新する（Ｓ８０３）。具体的にステップＳ８０３では、もしも現フレームの動きがパン操作の場合（すなわちＰＴ１＝＝”Ｐ”）、ＭｘにＦｘを加算する。同様にもしも現フレームの動きがチルト操作の場合（すなわちＰＴ１＝＝”Ｃ”）、ＭｙにＦｙを加算する。もしも現フレームの動きがズーム操作の場合（すなわちＰＴ１＝＝”Ｚ”）、ＭｘとＭｙをａで除算した値をそれぞれ新たにＭｘ、Ｍｙとし、Ｍａにａを乗算した値を新たにＭａとする。
そしてＰＴ０をＰＴ１で置換し、カウンタＣＴＲに１を加算する（Ｓ８０６）。そして次の動きベクトル１１９の取得を行い、再び同様の処理を行う（Ｊ１）。もしもステップＳ８０２の条件判定で“ＮＯ”の場合、もしくはカメラ操作なしと判定された場合（Ｓ７０８）には、上述のパラメータＭＰ（Ｍｘ、Ｍｙ、Ｍａ）の３つの要素が全て求められたかどうかを判定（Ｓ８０４）する。ステップＳ８０４の条件判定で“ＮＯ”の場合、カウンタＣＴＲを０にリセット（Ｓ８０７）し、次の動きベクトル１１９の取得を行い、再び同様の処理を行う（Ｊ１）。ステップＳ８０４の条件判定で“ＹＥＳ”の場合、パラメータＭＰをカメラ操作動きパラメータ１３０としてカメラ操作動きパラメータ記憶部１０１へ出力し（Ｓ８０５）、キャリブレーション処理を終了する。
以上に述べたキャリブレーション処理により、ユーザがパン・チルト・ズーム操作を一回行ったときのカメラ操作動きパラメータ１３０の初期値が得られ、カメラ操作動きパラメータ記憶部１０１に保持される。
以上に述べたように、カメラ動き推定部１２１においては、ＵＩモジュール１６０の起動直後に行われるキャリブレーション処理（すなわち、カメラ操作動きパラメータ１３０の初期値を求める処理）と、カメラ映像を受信したときの現フレームのカメラ動き推定処理（すなわちフレーム間動きパラメータ１１６を求める処理）、の２つが行われる。
次に、上述のカメラ動き推定処理によって得られたフレーム間動きパラメータ１１６に基づいて、カメラ操作動きパラメータ記憶部１０１内の動きパラメータがどのように更新されるかについて説明する。
図９は、カメラ操作動きパラメータ記憶部１０１において、カメラ動き推定部１２１が出力するフレーム間動きパラメータ１１６に基づいた、カメラ操作動きパラメータ１３０の変更処理の流れを示す図である。カメラ操作動きパラメータ記憶部１０１では、同図に示すように、もしもカメラ動き推定部１２１においてズーム操作が検出された場合（Ｓ９０２）、カメラ上での画像の平行移動量が変わるため、前述のカメラ操作動きパラメータ１３０のＦｘとＦｙをズームパラメータ値ａで除算した値をそれぞれ新たにＦｘ、Ｆｙとする（Ｓ９０３）。なおカメラ操作動きパラメータ１３０の初期ズームパラメータ値は変更されない。
上述のような更新処理をカメラ操作動きパラメータ記憶部１０１において行うことで、受信したカメラ映像のズーム倍率が変化した場合においても、ユーザのカメラワーク操作による、現在表示している画像上の視野範囲の推定を正しく行うことが可能となる。
次に図１０を参照して、視野範囲生成部１０９における処理の流れを説明する。視野範囲生成部１０９は、視野範囲位置情報１１０を生成し、これを描画部１１４へ渡す。前述のように描画部１１４では、この視野範囲位置情報１１０を元にして視野範囲を示す画像信号を生成し、これをフレーム画像信号１１３の上にオーバレイ表示する。
本実施形態１では、ＵＩモジュール１６０がカメラ制御モードである場合に限り、カメラ制御操作による推定視野範囲をユーザに提示する。ここでカメラ制御モードとは、ＵＩモジュール１６０のインタフェースにより、ユーザがパン・チルト・ズームなどのカメラ制御操作を行うことができる状態を指す。
図１０中、ステップＳ１００１では、ＵＩモジュール１６０がカメラ制御モードであるかどうかを判断し、カメラ制御モードでなければ視野範囲生成処理を終了する。
もしもステップＳ１００１においてカメラ制御モードである場合、前述の視野範囲推定部１０４において推定された、推定視野範囲位置情報１０８を取得する（ステップＳ１００２）。次に前述のカメラ動き推定部１２１において推定されたフレーム間動きパラメータ１１６を取得する（ステップＳ１００３）。
そしてカメラ動き推定部１２１において、次に表示されるフレーム画像に、カメラワークによる動きが検出されたかどうかを判定する（ステップＳ１００４）。もしもステップＳ１００４においてカメラワークが検出されなかった場合には、前述の推定視野範囲位置情報１０８を、視野範囲位置情報１１０とする（ステップＳ１００６）。
もしもステップＳ１００４においてカメラワークが検出された場合には、前述のフレーム間動きパラメータ１１６による座標変換を推定視野範囲位置情報１０８に対して施し、この変換結果を視野範囲位置情報１１０とする（ステップＳ１００５）。このようにフレーム毎に画面全体の動きによる座標変換を、推定される視野範囲位置情報に対しても施すことにより、カメラ制御モードにおいて、推定視野範囲を表示している最中に、カメラワークによる映像の移動が生じた場合にも、正しく視野範囲を推定して表示することができる。
上述のように計算された視野範囲位置情報１１０は前述の描画部１１４と、前述の視野範囲記憶部１２２に送られる（ステップＳ１００６）。前述のように、描画部１１４ではこの視野範囲位置情報１１０を用いて、同じく描画部１１４に送られたフレーム画像信号１１３上に視野範囲を示す画像信号をオーバレイ表示する。以上の処理を、ＵＩモジュール１６０がカメラ制御モードである間繰り返すことで、ユーザがカメラ制御操作を行う度に、現在の映像における視野範囲を連続的に推定し、ユーザに提示することが可能となる。
ここで図１１、および図１２を参照し、描画部１１４において、上述の視野範囲生成部１０９が生成する視野範囲位置情報１１０と受信フレーム画像信号１１３との関係について説明する。図１１では、上述のステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出されなかった場合のインタフェース表示例を説明する。図１２では、上述のステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出された場合のインタフェース表示例を説明する。
図１１は、パン操作（図１１上列）、およびズーム操作（図１１下列）を行ったときの描画部１１４が表示するインタフェース画面の流れを示す。図１１のインタフェース画面Ｍ１は、パン、又はチルト操作を行うためのカメラ制御モード画面である。この状態で、ユーザの矢印ボタンの押下によりパン又はチルトのカメラ操作要求が行われるものとする。カメラ制御モードの状態では、現在の視野範囲を示す矩形枠１１０１と、現在の視野の中心軸を示す小矩形枠１１０２が表示される。インタフェース画面Ｍ１の状態では、矩形枠１１０１は描画領域と一致しており、かつ小矩形枠１１０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ１の状態において「←」（左矢印）ボタンを押下すると、視野範囲生成部１０９では上で述べた処理により、推定視野範囲位置情報１０８を元に矩形枠１１０１と小矩形枠１１０２の画像信号を生成する。そして生成された矩形枠１１０１と小矩形枠１１０２は、そのまま描画部１１４にてフレーム画像信号１１３上にオーバレイ表示される。このときの画面の状態を図５のインタフェース画面Ｍ２に示す。
インタフェース画面Ｍ２に示すように、視野範囲の矩形枠１１０１と小矩形枠１１０２が左へ移動している。インタフェース画面Ｍ２では、左矢印ボタン操作によるカメラ制御要求は配信サーバ２０２に送信されているが、上述のように最低でもフラグメント時間長分の遅延が生じ、かつ上述のように図９のインタフェース画面Ｍ１、Ｍ２では、パン・チルトモードでボタン操作を行う間に、過去のカメラ制御操作による動画像の大きな動きはない（図１１では、図１０中のステップＳ１００４において、カメラ制御モードの間はカメラワークが検出されないと仮定しているため）ため、フレーム画像信号１１３はインタフェース画面Ｍ１とほぼ同じまま（図１１では背景の木は中央で止まった状態）である。
ユーザは所望のパン・チルト操作が終了すると、何らかのボタン操作によりカメラ制御モードを終了し、通常モードへ移行する。通常モードでは、上述の視野範囲を示す矩形枠は表示されない。そして左向きのパン操作が行われた映像は、最低でもフラグメント時間長分の遅延時間後に、ＵＩモジュール１６０で受信され、最終的に描画部１１４において表示される。最終的に左向きパン操作の映像が表示された状態の画面をインタフェース画面Ｍ３に示す。
インタフェース画面Ｍ４は、ズーム操作を行うためのカメラ制御モードにおける画面である。この状態では、ユーザの「＋」「−」ボタン押下によりズームイン、ズームアウトのカメラ操作要求が行われるものとする。インタフェース画面Ｍ４でもＭ１と同様に、現在の視野範囲を示す矩形枠１１０１と、現在の視野の中心軸を示す小矩形枠８０２が表示される。インタフェース画面Ｍ４では、矩形枠１１０１は描画領域と一致しており、かつ小矩形枠１１０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ４の状態において、「＋」ボタン（ズームイン操作）を押下すると、上述のように視野範囲推定部１０４において、この「＋」ボタン操作による、現画面上での視野範囲が推定され、描画部１１４にてフレーム画像信号１１３上にオーバレイ表示される。このときの画面の状態を図１１のインタフェース画面Ｍ５に示す。
インタフェース画面Ｍ５では、ズームイン操作により矩形枠１１０１が縮小しており、縮小の中心点は元の描画領域の中心点と同じであるため、小矩形枠１１０２は描画領域の中心位置に表示されている。ここで本実施形態１では、小矩形枠１１０２は中心位置を示すための枠であるため、拡大・縮小は行わないものとする。インタフェース画面Ｍ５の状態では、「＋」ボタン操作によるカメラ制御要求は配信サーバ２０２に送信されているが、前述のインタフェース画面Ｍ２と同様に遅延が生じるため、フレーム画像信号１１３はインタフェース画面Ｍ４と同じ背景映像のままである。
ユーザは所望のズームイン操作が終了すると、何らかのボタン操作によりカメラ制御モードを終了し、上述と同様に、通常モードへ移行する。通常モードでは、上述の視野範囲を示す矩形枠は表示されない。そしてズーム操作が行われた映像は、最低でもフラグメント時間長分の遅延時間後に、ＵＩモジュール１６０で受信され、最終的に描画部１１４において表示される。最終的にズームイン操作の映像が表示された状態の画面をインタフェース画面Ｍ６に示す。
次に図１２を参照し、図１０におけるステップＳ１００４において、カメラ制御モードの間に、カメラワークによる動きが検出された場合のインタフェース画面表示例を説明する。
図１２は、パン操作とチルト操作を行い、カメラ制御モードの状態でしばらく経過後、パン操作、チルト操作によるカメラワークが反映された映像を受信したときの、ＵＩモジュール１６０のインタフェース画面の流れを示している。図１２のインタフェース画面Ｍ７は、パン、又はチルト操作を行うためのカメラ制御モード画面である。この状態で、ユーザの矢印ボタンの押下によりパン又はチルトのカメラ操作要求が行われる。インタフェース画面Ｍ７の状態では、矩形枠１２０１は描画領域と一致しており、かつ小矩形枠１２０２は描画領域の中心位置に表示されている。
インタフェース画面Ｍ７の状態において「←」（左矢印）ボタンを押下すると、上に述べた処理により、インタフェース画面Ｍ８の画面が提示される。同様にインタフェース画面Ｍ８の状態において「↑」（上矢印）ボタンを押下すると、上に述べた処理により、インタフェース画面Ｍ９の画面が提示される。
インタフェース画面Ｍ９のままの状態でカメラ制御モード状態を保持し続けると、やがてインタフェース画面Ｍ７の状態における左向きのパンニング操作が反映された映像を受信する。このとき図１０のステップＳ１００４においてカメラワークによる動きが検出される。すなわち、左向きのパンニング操作により、相対的に背景画面の右向きの動きが検出されるので、矩形枠１２０１と小矩形枠１２０２を、インタフェース画面Ｍ９の状態から右向きに移動させることで、インタフェース画面Ｍ１０のような画面となる。
同様に、インタフェース画面Ｍ１０の状態で、インタフェース画面Ｍ８の状態における上向きのチルト操作が反映された映像を受信すると、相対的に背景画面の下向きの動きが検出されるので、矩形枠１２０１と小矩形枠１２０２を、インタフェース画面Ｍ９の状態から右向きに移動させることで、インタフェース画面Ｍ１０のような画面となる。
以上に述べたように、カメラ制御モードの間（つまり現在の推定視野範囲を表示しているとき）に、過去のカメラワークにより背景画像が大きく動いても、その動きに合わせて推定視野範囲を移動させることにより、適切な推定視野範囲をユーザに提示することができる。
以上に述べたように、本発明の実施形態１のカメラ制御インタフェース装置では、カメラ映像を受信するまでの遅延が大きい場合でも、推定される視野範囲を直ちにユーザに提示できるので、ユーザの遠隔カメラ操作の利便性を向上させることができる。また、カメラ制御モードでユーザが遠隔カメラ操作を行っている際に、過去のカメラワーク制御による映像の移動が生じた場合でも、常に正しい推定視野範囲をユーザに対し提示することができる。
次に本発明の実施形態２によるカメラ制御インタフェース装置について説明する。
本発明の実施形態２では、実施形態１の変形例として、カメラ２０４においてカメラワークが行われているか否かを示す状態フラグ２１０を、撮影映像２０５と同期させて常にエンコーダ２０３に送る。エンコーダ２０３では各動画フレームが、カメラワークが行われているかどうかを示す状態フラグ２１０を、各フラグメント１１１内のヘッダ情報（前述のように、ｍｏｏｖに相当）内に格納する。
図１３に実施形態２によるカメラ制御ユーザインタフェース装置における、ＵＩモジュール１６１のブロック図を示す。実施形態２では、多重分離部１１２において、各動画像符号化データ１２０内のフレームと同期して、そのフレームではカメラワークが行われているかどうかを示す状態フラグ２１０を抽出し、この状態フラグ２１０をカメラ動き推定部１２１に渡すことを特徴とする。
実施形態１によるＵＩモジュール内のカメラ動き推定部１２１では、カメラ２０４から撮像されている画像内では、移動する物体は十分小さく、画像全体を占める映像の大部分の動きが極めて少ない背景であると仮定していた。このため、もしも移動物体が画像全体に占める割合が大きい場合には、実際にはカメラが動いていないときにも、誤ってカメラ動きと判定しまう問題がある。
実施形態２では、ＵＩモジュール１６１におけるカメラ動き推定部１２１において、フレーム毎にカメラワークが行われているかどうかを示す状態フラグ２１０を調べ、同フラグ２１０によりカメラワークが行われていることが指示されている場合にのみ、上に述べたフレーム間動きパラメータ１１６を推定する。以上のような処理により、移動物体が画面内に存在した場合にも、カメラ動きの誤判定を防ぐことが可能となる。
次に本発明の実施形態３によるカメラ制御インタフェース装置について説明する。
本発明の実施形態３では、実施形態１、２の変形例として、ユーザのカメラ制御操作による視野範囲の移動履歴を保持し、ある視野範囲移動時刻（すなわちカメラ制御操作時刻）と、そのカメラ制御操作が反映された映像を受信し、再生する時刻との差を算出し、この差を遅延時間としてユーザに提示する機能を備える。図１４に実施形態３によるカメラ制御ユーザインタフェース装置における、ＵＩモジュール１６２のブロック図を示す。実施形態３によるＵＩモジュール１６２は、図１３に示した実施形態２のＵＩモジュール１６１内に、視野範囲移動履歴記憶部１０６が追加された構成となる。すなわち視野範囲移動履歴記憶部１０６では、ユーザのカメラ制御操作による視野範囲の変更が発生すると、推定視野範囲位置情報１０８を受け取り、その変更時刻を保持する。図１４内の視野範囲生成部１０９では、カメラ動き推定部１２１から現フレームのフレーム間動きパラメータ１１６を受け取ると、このカメラ動きを検出した時刻Ｕを保持し、対応する視野範囲移動時刻Ｖを視野範囲移動履歴記憶部１０６から取得し、Ｕ−Ｖを遅延時間としてユーザに提示する画像信号を、上述の視野範囲を示す視野範囲位置情報１１０に加え、これが描画部１１４においてオーバレイ表示される。
以上のように、実施形態３によるカメラ制御インタフェース提示装置では、ユーザに対し、推定される視野範囲に加え、遅延時間を提示することができる。このためユーザは、ユーザが現在行ったカメラワーク制御操作が、何秒後に受信映像に反映されるかがわかるため、大きな遅延によるユーザの不便感を軽減することが可能となる。
次に本発明の実施形態４によるカメラ制御インタフェース装置について説明する。本発明の実施形態４では、実施形態１の変形例として、実施形態１によるＵＩモジュール１６０内の、カメラ動き推定部１２１において行っていたキャリブレーション処理と、動きパラメータ推定処理とを配信サーバ２０２にて行い、推定されたパラメータ値を本実施形態４のカメラ制御インタフェース装置に送信することを特徴とする。
実施形態４によるカメラ制御インタフェース装置を用いたカメラ制御システムの全体構成は、図２と同様である。図１５に、実施形態４によるカメラ制御システムの配信サーバ２０２におけるカメラ制御モジュール１５００の構成を示す。カメラ制御モジュール１５００内のカメラ制御要求受信部１５０１において、携帯端末１１５からのカメラ制御要求２０１が受信されると、カメラ制御コマンド生成部１５０２はカメラ制御要求２０１をカメラ２０４が解析可能なカメラ制御コマンド２０７に変換し、カメラ２０４へ送信する。カメラ制御モジュール１５００は、最低でもフラグメント時間長Ｔの遅延時間後に、エンコーダ２０３から、カメラ制御コマンド２０７によるカメラワークが行われた映像がフラグメント２０６を受信する。
カメラ制御モジュール１５００内では、受信したフラグメント２０６から、多重分離部１５０６において動画像符号化データ１２０を取得する。取得された動画像符号化データ１２０は、カメラ動き推定部１５０８とビデオ復号部１５０９におくられ、キャリブレーション処理と、動きパラメータ推定処理とが行われる。これらの処理の流れは実施形態１と同様である。
カメラ制御モジュール１５００内のカメラ操作動きパラメータ記憶部１５０７における、動きパラメータ更新処理の流れは実施形態１と同様である。
携帯端末１１５が、配信要求２００を配信サーバ２０２へ送ると、多重分離部１５０６において取得された動画像符号化データ１２０は逐次、多重部１５０４へ送られる。またこの動画像符号化データ１２０が最初に多重部１５０４へ送られた時刻におけるカメラ操作動きパラメータ１５０５が、カメラ操作動きパラメータ記憶部１５０７から多重部１５０４へ送られる。また２つ目以降の動画像符号化データ１２０に対しては、この動画像符号化データに対応するフレーム間動きパラメータ１１６をカメラ動き推定部１５０８から取得する。
多重部１５０４は、最初の動画像符号化データ１２０に対してはカメラ操作動きパラメータ１５０５を、２つ目以降の動画像符号化データ１２０に対してはそれぞれについてフレーム間動きパラメータ１１６を、各々対応づけて多重化し、携帯端末１１５で解析可能なフラグメント１１１を生成する。フラグメント１１１において、カメラ操作動きパラメータ１３０とフレーム間動きパラメータ１１６は、例えば図４に示したＭＰ４形式のフラグメント内のヘッダ情報として格納される。生成されたフラグメント１１１は、携帯端末１１５へ送信される。
図１６に、本発明の実施形態４によるカメラ制御インタフェース装置におけるＵＩモジュール１６３のブロック図を示す。ＵＩモジュール１６３は、実施形態１におけるＵＩモジュールから、カメラ動き推定部１２１を除いた構成となる。
ＵＩモジュール１６３では、配信サーバ２０２からフラグメント１１１を受信すると、これを多重分離部１１２へ渡す。多重分離部１１２では、動画像符号化データ１２０をフラグメント１１１から取得し、これをビデオ復号部１１８へ渡す。また同時に多重分離部１１２では、前述の先頭の動画像符号化データ１２０と時間的に同期した、カメラ操作動きパラメータ１５０５をフラグメント１１１から取得し、これをカメラ操作動きパラメータ記憶部１０１に渡す。そして先頭以外の動画像符号化データ１２０と時間的に同期した、フレーム間動きパラメータ１１６をフラグメント１１１から取得し、これを視野範囲生成部１０９へ送ると同時に、カメラ操作動きパラメータ記憶部１０１へ渡す。
カメラ操作動きパラメータ記憶部１０１においては、多重分離部から取得したカメラ操作動きパラメータ１５０５を初期値として保持し、フレーム間動きパラメータ１１６を取得すると、図９で述べた処理と同様に、カメラ操作動きパラメータ１５０５を更新する。
ＵＩモジュール１６３では、カメラ操作動きパラメータ１５０５を元に視野範囲推定部１０４において視野範囲の位置座標を推定する。
以降、推定された視野範囲が視野範囲生成部１０９において生成され、描画部１１４においてオーバレイ表示されるまでの処理は、実施形態１におけるＵＩモジュール１６０と同様である。
実施形態１によるカメラ制御インタフェース装置では、キャリブレーション処理を、ＵＩモジュール１６０の起動直後に行うことを想定していたため、本発明のように映像の遅延が大きい場合には、キャリブレーション処理に要する時間が長くなるという問題があった。また、携帯端末上にて動きベクトルや動きパラメータの推定処理などを行う必要があるため、携帯端末上における処理量が多くなるという問題があった。
以上のように、実施形態４によるカメラ制御インタフェース装置では、上述のカメラ動き推定処理を全て配信サーバにて行う。すなわちＵＩモジュール１６３では、配信サーバ２０２におけるカメラ制御モジュール１５００において推定されたカメラ操作動きパラメータ１５０５を、実施形態１によるキャリブレーション処理の代わりの初期値として用いることができる。また実施形態１によるカメラ動き推定部におけるフレーム間動きパラメータ１１６についても、配信サーバ２０２におけるカメラ制御モジュール１５００にて推定された値を受信し、これを用いて視野範囲を推定することができる。このため、実施形態４によるカメラ操作制御インタフェースは、実施形態１に比べてユーザインタフェース提示における処理量を大幅に軽減できる。
【０００６】
【発明の効果】
本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザの操作を反映した視野範囲を予測し、直ぐにユーザに提示することができるため、ユーザに対し快適なカメラ操作インタフェースを提供することができる。
また本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、遅延時間をユーザに対し提示することができるため、遅延が大きいことによるユーザのカメラ操作の不快さを軽減できるという効果がある。
さらに本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザ操作の視野範囲を予測する処理を配信サーバにて行うことができるため、携帯端末上で多くの処理を行わずに、ユーザに対し快適なカメラ操作インタフェースを提供することができる。
以上に述べたように本発明によれば、遠隔監視カメラサービスにおいて映像の遅延が大きい場合であっても、ユーザに対し快適なカメラ操作インタフェースを効率よく提供できる。本発明は特に携帯電話網のような通信速度の変動が激しい通信網において有用である。従って現在広く普及している携帯端末を利用することで、安価な遠隔監視サービスの提供が可能となり、安全管理や作業管理など幅広い用途における監視サービスの普及に貢献できる。
【図面の簡単な説明】
【図１】本発明の実施形態１によるカメラ制御ユーザインタフェースモジュールの構成を示すブロック図。
【図２】本発明の実施形態１によるカメラ制御システムの全体構成図。
【図３】本発明の実施形態１によるカメラ制御システムの処理の時間的流れを示す図。
【図４】ＭＰ４形式によるフラグメントの構成図。
【図５】本発明の実施形態１によるカメラ制御インタフェース装置の例を示す図。
【図６】本発明の実施形態１によるカメラ制御要求のデータフォーマット例を示す図。
【図７】本発明の実施形態１によるカメラ動き推定部の処理を示すフローチャート。
【図８】本発明の実施形態１によるキャリブレーション処理を示すフローチャート。
【図９】本発明の実施形態１によるカメラ操作動きパラメータ記憶部における動きパラメータの更新処理を示すフローチャート。
【図１０】本発明の実施形態１による視野範囲生成部における処理を示すフローチャート。
【図１１】本発明の実施形態１による描画部において、カメラ制御モード中にカメラワークが起こらなかった映像を受信した場合の、視野範囲とフレーム画像の関係を示す図。
【図１２】本発明の実施形態１による描画部において、カメラ制御モード中にカメラワークが起こった映像を受信した場合の、視野範囲とフレーム画像の関係を示す図。
【図１３】本発明の実施形態２によるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【図１４】本発明の実施形態３によるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【図１５】本発明の実施形態４による、配信サーバにおけるカメラ制御モジュールの処理構成を示すブロック図。
【図１６】本発明の実施形態４による、携帯端末におけるカメラ制御ユーザインタフェースモジュールの処理構成を示すブロック図。
【符号の説明】
１００・・・ユーザ操作検出部
１０１・・・カメラ操作動きパラメータ記憶部
１０２・・・カメラ制御ボタン押下情報
１０４・・・視野範囲推定部
１０６・・・視野範囲移動履歴記憶部
１０８・・・推定視野範囲位置情報
１０９・・・視野範囲生成部
１１０・・・視野範囲位置情報
１１１・・・フラグメント
１１２・・・多重分離部
１１３・・・フレーム画像信号
１１４・・・描画部
１１５・・・携帯端末
１１６・・・フレーム間動きパラメータ
１１７・・・カメラ制御要求生成部
１１８・・・ビデオ復号部
１１９・・・動きベクトル
１２０・・・動画像符号化データ
１２１・・・カメラ動き推定部
１２２・・・視野範囲記憶部
１３０・・・カメラ操作動きパラメータ
１６０・・・ユーザインタフェース（ＵＩ）モジュール
１６１・・・実施形態２によるユーザインタフェース（ＵＩ）モジュール
１６２・・・実施形態３によるユーザインタフェース（ＵＩ）モジュール
１６３・・・実施形態４によるユーザインタフェース（ＵＩ）モジュール
２００・・・配信要求
２０１・・・カメラ制御要求
２０２・・・配信サーバ
２０３・・・エンコーダ
２０４・・・カメラ
２０５・・・撮影映像
２０６・・・フラグメント
２０７・・・カメラ制御コマンド
２１０・・・（フレームでカメラワークが行われているかどうかを示す）状態フラグ
１１０１、１２０１・・・現在の視野範囲を示す矩形枠
１１０２、１２０２・・・現在の視野の中心軸を示す小矩形枠
１５００・・・実施形態４による配信サーバにおけるカメラ制御モジュール
１５０１・・・カメラ制御要求受信部
１５０２・・・カメラ制御コマンド生成部
１５０４・・・多重部
１５０５・・・カメラ操作動きパラメータ
１５０６・・・多重分離部
１５０７・・・カメラ操作動きパラメータ記憶部
１５０８・・・カメラ動き推定部
１５０９・・・ビデオ復号部
Ｂ１・・・「上」「下」「左」「右」方向矢印ボタン
Ｂ２・・・「＋」ボタン
Ｂ３・・・「−」ボタン
Ｂ４・・・画像表示領域
Ｍ１〜Ｍ１１・・・インタフェース画面。
Claims (12)
- 前記カメラの視野範囲を表示する表示手段と、
前記カメラに指示を伝える制御命令を入力する手段と、
前記制御命令を前記カメラに伝える手段と、
前記制御命令によって動作した前記カメラの動作後の視野範囲を、前記制御命令に基いて定義されたカメラ操作動きパラメータにより推定する手段とを少なくとも有し、
前記表示手段が、前記推定する手段により推定された前記カメラの動作後の視野範囲を表示することを特徴とするカメラ制御装置。 - 請求項１記載のカメラ制御装置において、
前記表示手段が、
前記カメラ操作動きパラメータにより推定された視野範囲を表示後、
前記制御命令によって動作した前記カメラの動作後の視野範囲が表示可能となった場合に、前記制御命令によって動作した前記カメラの動作後の視野範囲を表示することを特徴とするカメラ制御装置。 - 請求項１記載のカメラ制御装置において、
前記推定手段が、
前記カメラ操作動きパラメータを、前記制御命令に応じたフレーム間の動きベクトルから定義することを特徴とするカメラ制御装置。 - 請求項１記載のカメラ制御装置において、
前記制御命令がカメラのズーム動作の場合に、前記カメラ操作動きパラメータを補正することを特徴とするカメラ制御装置。 - 請求項１記載のカメラ制御装置において、
前記カメラが動いたか否かを示す信号により、カメラワークの有無を判定する判定部を有することを特徴とするカメラ制御装置 - 請求項１記載のカメラ制御装置において、
前記制御命令があってから前記制御命令によって動作した前記カメラの動作後の前カメラの映像が表示されるまでの時間を、前記表示手段に表示することを特徴とする前記カメラ制御装置。 - カメラの視野範囲を表示するステップと、
前記カメラに指示を伝える制御命令を入力するステップと、
前記制御命令を前記カメラに伝えるステップと、
前記制御命令によって動作した前記カメラの動作後の視野範囲を、前記制御命令に基いて定義されたカメラ操作動きパラメータにより推定するステップと、
前記推定された前記カメラの動作後の視野範囲を、表示するステップとを実行するプログラム。 - 請求項７記載のプログラムにおいて、
カメラ操作動きパラメータにより推定された視野範囲を表示後、
前記制御命令によって動作した前記カメラの動作後の視野範囲が表示可能となった場合に、前記制御命令によって動作した前記カメラの動作後の視野範囲を表示するステップを更に実行するプログラム。 - 請求項７記載のプログラムにおいて、
前記カメラ操作動きパラメータを、前記制御命令に応じたフレーム間の動きベクトルから定義するステップを更に実行するプログラム。 - 請求項７記載のプログラムにおいて、
前記制御命令がカメラのズーム動作の場合に、前記カメラ操作動きパラメータを補正するステップを更に実行するプログラム。 - 請求項７記載のプログラムにおいて、
前記カメラワークの有無を示す信号により、カメラワークの有無を判定する
ステップを更に実行するプログラム。 - 請求項７記載のプログラムにおいて、
前記制御命令があってから前記制御命令によって動作した前記カメラの動作後の前カメラの映像が表示されるまでの時間を、前記表示手段に表示するステップを更に実行するプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002346771A JP2004180190A (ja) | 2002-11-29 | 2002-11-29 | カメラ制御装置及びその制御ステップを実行するプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002346771A JP2004180190A (ja) | 2002-11-29 | 2002-11-29 | カメラ制御装置及びその制御ステップを実行するプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004180190A true JP2004180190A (ja) | 2004-06-24 |
| JP2004180190A5 JP2004180190A5 (ja) | 2005-12-15 |
Family
ID=32707556
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002346771A Pending JP2004180190A (ja) | 2002-11-29 | 2002-11-29 | カメラ制御装置及びその制御ステップを実行するプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004180190A (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006074441A (ja) * | 2004-09-02 | 2006-03-16 | Matsushita Electric Ind Co Ltd | 画像受信装置及び画像受信方法、並びに画像伝送システム |
| WO2007028193A1 (en) * | 2005-09-06 | 2007-03-15 | Digisensory Technologies Pty, Ltd. | Method and system for a programmable camera for configurable security and surveillance systems |
| JP5140889B2 (ja) * | 2006-08-10 | 2013-02-13 | サンリツオートメイション株式会社 | ゆらぎ補正による画像表示方法及びその方法を用いた動体リモートコントロールシステム |
| US9342978B2 (en) | 2005-04-15 | 2016-05-17 | 9051147 Canada Inc. | Method and system for configurable security and surveillance systems |
| JPWO2014030510A1 (ja) * | 2012-08-22 | 2016-07-28 | オムロン株式会社 | デバイス管理装置及びデバイス管理方法 |
| WO2016151925A1 (ja) * | 2015-03-26 | 2016-09-29 | 富士フイルム株式会社 | 追尾制御装置、追尾制御方法、追尾制御プログラム、及び、自動追尾撮影システム |
-
2002
- 2002-11-29 JP JP2002346771A patent/JP2004180190A/ja active Pending
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4593209B2 (ja) * | 2004-09-02 | 2010-12-08 | パナソニック株式会社 | 画像受信装置及び画像受信方法、並びに画像伝送システム |
| JP2006074441A (ja) * | 2004-09-02 | 2006-03-16 | Matsushita Electric Ind Co Ltd | 画像受信装置及び画像受信方法、並びに画像伝送システム |
| US9595182B2 (en) | 2005-04-15 | 2017-03-14 | Avigilon Patent Holding 1 Corporation | Method and system for configurable security and surveillance systems |
| US9342978B2 (en) | 2005-04-15 | 2016-05-17 | 9051147 Canada Inc. | Method and system for configurable security and surveillance systems |
| US10854068B2 (en) | 2005-04-15 | 2020-12-01 | Avigilon Patent Holding 1 Corporation | Method and system for configurable security and surveillance systems |
| US10311711B2 (en) | 2005-04-15 | 2019-06-04 | Avigilon Patent Holding 1 Corporation | Method and system for configurable security and surveillance systems |
| WO2007028193A1 (en) * | 2005-09-06 | 2007-03-15 | Digisensory Technologies Pty, Ltd. | Method and system for a programmable camera for configurable security and surveillance systems |
| US8508607B2 (en) | 2005-09-06 | 2013-08-13 | Its-7 | Method and system for a programmable camera for configurable security and surveillance systems |
| JP5140889B2 (ja) * | 2006-08-10 | 2013-02-13 | サンリツオートメイション株式会社 | ゆらぎ補正による画像表示方法及びその方法を用いた動体リモートコントロールシステム |
| US9585019B2 (en) | 2012-08-22 | 2017-02-28 | Omron Corporation | Device management apparatus and device management method |
| JPWO2014030510A1 (ja) * | 2012-08-22 | 2016-07-28 | オムロン株式会社 | デバイス管理装置及びデバイス管理方法 |
| JPWO2016151925A1 (ja) * | 2015-03-26 | 2018-01-11 | 富士フイルム株式会社 | 追尾制御装置、追尾制御方法、追尾制御プログラム、及び、自動追尾撮影システム |
| WO2016151925A1 (ja) * | 2015-03-26 | 2016-09-29 | 富士フイルム株式会社 | 追尾制御装置、追尾制御方法、追尾制御プログラム、及び、自動追尾撮影システム |
| US10451705B2 (en) | 2015-03-26 | 2019-10-22 | Fujifilm Corporation | Tracking control device, tracking control method, tracking control program, and automatic tracking imaging system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8089514B2 (en) | Moving image communication device, moving image communication system and semiconductor integrated circuit used for communication of moving image | |
| US9699099B2 (en) | Method of transmitting data in a communication system | |
| US8711929B2 (en) | Network-based dynamic encoding | |
| US5910827A (en) | Video signal decoding arrangement and method for improved error concealment | |
| US9143730B2 (en) | Information processing apparatus, transmission system and program | |
| JP5731672B2 (ja) | 暗黙基準フレームを用いる動画像符号化システム | |
| TWI364220B (en) | A video processing method and a video system | |
| US20090323801A1 (en) | Image coding method in thin client system and computer readable medium | |
| CN111221491A (zh) | 交互控制方法及装置、电子设备、存储介质 | |
| KR20090124993A (ko) | 송신 장치, 송신 방법 및 수신 장치 | |
| WO2013135141A1 (zh) | 动态调整视频的系统、终端和方法 | |
| JP2000312360A (ja) | 情報提供装置 | |
| KR20140006102A (ko) | 후속 적용들을 용이하게 하기 위해 비디오 이미지 파라미터들을 동적으로 적응시키기 위한 방법 | |
| US9306987B2 (en) | Content message for video conferencing | |
| JP4768250B2 (ja) | 送信装置、受信装置、送受信装置、送信方法及び伝送システム | |
| US9185159B2 (en) | Communication between a server and a terminal | |
| JP2004180190A (ja) | カメラ制御装置及びその制御ステップを実行するプログラム | |
| JP2011176490A (ja) | 映像配信システム、中継装置及び映像配信プログラム | |
| CN111147892A (zh) | 用于视频传输的方法和装置，存储介质和电子设备 | |
| CN113259729B (zh) | 数据切换的方法、服务器、系统及存储介质 | |
| US7827458B1 (en) | Packet loss error recovery | |
| CN112752074A (zh) | 数据传输方法、装置、终端设备和存储介质 | |
| US20080291262A1 (en) | Visual communication method and appratus | |
| JP5141477B2 (ja) | 動画像受信装置、動画像通信システム、動画像受信プログラム及び動画像通信プログラム | |
| US20080052631A1 (en) | System and method for executing server applications in mobile terminal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051028 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051028 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080930 |