JP7282519B2

JP7282519B2 - 画像処理装置または画像処理サーバー

Info

Publication number: JP7282519B2
Application number: JP2018247191A
Authority: JP
Inventors: 武弘吉田; 雄資白川; 裕介春山
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2018-12-28
Filing date: 2018-12-28
Publication date: 2023-05-29
Anticipated expiration: 2038-12-28
Also published as: JP2020107196A

Description

本発明は撮影や映像モニターのための画像処理装置等に関するものである。

近年、国際化が進み、多くの観光客が日本を訪問するようになっている。また、競技スポーツにおいても、様々な国の選手の撮影機会が大幅に増加している。

しかしプロカメラマンにとっても、一般の写真を撮影する人にとっても、例えば競技スポーツシーンにおいて多数の選手の中から特定の選手を見つけることは比較的難しい。また、特に競技スポーツにおける競技中は動きが速く複数の選手が交錯し選手のいる場所を見失うことが多々ある。これは、競技スポーツに限らず雑踏の中から特定の人物等を撮影したりモニターしたりする場合でも同じことが言える。

特許文献１には、被写体を複数の方向から撮影するための複数のカメラと、前記複数のカメラのうち対応するカメラによる撮影画像から所定領域を抽出する複数の画像処理装置が記載されている。また、前記複数の画像処理装置により前記複数のカメラによる撮影画像から抽出された所定領域の画像データに基づいて仮想視点画像を生成する画像生成装置が記載されている。
特許文献２には、撮像された画像から取得したＡＦ評価値に基づいてフォーカスレンズを駆動し、自動焦点検出制御を行う自動焦点検出装置が記載されている。

特開２０１７－２１１８２８号公報特許第５３２２６２９号明細書

しかしながら、スポーツシーンなど、多くの選手が集まっている場合などでは、選手が重なってしまったりして、見失ったりすることがある。また視野から外れることもあり、適切なタイミングで選手を撮影するのはより難しかった。
さらに、最近は、カメラマンが写真を撮影した時のメモを例えば音声で写真に関連付けて残すことが多い。しかし、撮影の意図をメタデータ情報として残した場合に、他のメタデータと連携して残すことができないという欠点があった。また、試合の進み方によっては、カメラマンの撮影時のメモ内容と異なる結果になってしまうことがあった。この場合、カメラマンの撮影の意図とずれたメタデータのメモがそのまま、残ってしまうという課題もあった。

また、特に、プロカメラマンは、撮影した写真をすぐに、報道局などに送る必要があるが、判定結果が分からないと判定の認識に時間をとられてしまうという欠点があった。さらに、撮影したい選手を見つけても、その選手へのフォーカスを合わせた後に、その撮影したい選手を追いかけていかないといけなかった。これは、動きの速いスポーツでは、とても難しく、また、この追いかけることに集中していると、良い写真の撮影ができないということになってしまうという欠点があった。

またサーバー側では、全方位の映像、試合や競技のフィールドの各種情報を把握することができ、グランド内外の各種の貴重な情報も入手することができるが、従来のシステムではサーバーの活用が十分でないという問題があった。
同様に、競技場や自宅の端末で競技をモニターしている一般ユーザーにとっても特定の選手を見失ったり競技の状況がわからなくなったりする場合が多かった。同様にカーレースや飛行機レースや競馬などにおいても特定の車両や飛行機や馬などの対象を見失ってしまうことがあった。更には特定の人物を街角で追跡する場合においても雑踏の中にその特定の人物が紛れてしまい見失うことがあった。また、そのような、注目している特定の対象を目視で追いかけることに専念しているとその対象に対する撮影やピント合わせや露出調整などをスムーズにできないという問題があった。

また、プロカメラマンは、メタデータを画像に追加する場合が多いが、作業が煩雑で、時間をとられてしまうとともにメモの内容の正確性が劣る場合があった。さらに、あるタイミングでのメタデータは、時間の経過とともに修正、変更すべきケースがあるが、メタデータの変更が容易にできないという問題があった。
本発明は、上記、課題を解決し、有益な情報をタイムリーに付加でき、適宜修正できる画像処理装置を提供することを目的とする。

画像処理装置において、
画像を表示する表示手段、
前記表示手段に表示された画像の中から特定の対象を選択する選択手段、
前記選択手段によって選択された前記特定の対象に関する指定情報を生成する指定情報生成手段、
前記指定情報生成手段によって生成された前記指定情報をサーバーに送信する送信手段、
前記サーバーから前記指定情報に基づく前記特定の対象の位置情報及び前記サーバーにおいて作成された所定のメタデータを取得する取得手段、
前記取得手段によって取得された前記特定の対象の位置情報に基づく付加情報または前記メタデータに関する情報を前記表示手段に表示する制御手段、
を有することを特徴とする。

本発明によれば、有益な情報をタイムリーに付加でき、適宜修正できる画像処理装置を提供することができる。

実施例の画像処理装置を含むシステム全体のブロック図である。サーバー側のブロック図である。端末側の詳細ブロック図である。端末側の詳細ブロック図である。端末側の追跡部３７１の機能構成例を示すブロック図である。注目選手表示開始シーケンスの一例を示す図である。注目選手表示開始シーケンスの他の例を示す図である。ファイルの構造の例を示す図である。カメラ側の制御の例を示すフローチャートである。カメラ側の着目選手表示追跡制御の例を示すフローチャートである。カメラ側の着目選手表示追跡制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側における注目選手の検出制御の例を示すフローチャートである。サーバー側におけるトライ判定制御の例を示すフローチャートである。サーバー側におけるトライ判定制御の例を示すフローチャートである。トライ有無判定の審判動作を示す図である。サーバー側におけるトライ判定制御の例を示すフローチャートである。サーバー側におけるトライ判定制御の例を示すフローチャートである。カメラ等の端末側のトライ判定制御の例を示すフローチャートである。カメラ等の端末側の反則判定制御の例を示すフローチャートである。

以下本発明を実施するための形態につき、実施例を用いて説明をする。

最初に実施例１における、撮影や映像モニターを支援するための、画像処理装置を用いたシステムの全体像について図１を用いて説明する。図１は実施例の画像処理装置を含むシステム全体のブロック図である。

図１において、サーバー用の複数台のカメラ（固定カメラやドローンなどを用いた移動カメラ）を有するサーバー（画像処理サーバー）側が、競技場のフィールド全体における注目選手（特定の対象）の位置やゲームの最新の状況をリアルタイムで把握する。そして、サーバーが、個々の観客が持っている端末に対して、例えばカメラ撮影や画像のモニターの際に必要な情報をタイムリーに提供する例を示す。

一般にプロカメラマンや一般の写真撮影者がカメラで撮影している角度や視野では分からないあるいは追えない場所が存在することが多い。競技場外にいて撮影をしていない観客にとっても同様である。一方、サーバー側のシステムでは、複数のサーバー用のカメラの映像をもとに全方位の映像、試合のフィールド全体の情報（フィールドの座標情報等）をあらかじめ把握しマッピングができる。
従って、そのような各ユーザーには見えない、わかりにくい情報をサーバーが把握して配信することによって観客に対するサービスを大幅に向上することができる。

即ち、サーバー用の複数台のカメラ（固定カメラや移動カメラ）で、各選手の位置、得点、反則、審判の判断結果、その他の最新状況を追いかけたりすることができる。また大型スクリーンなどに表示され情報を基にして、サーバーで解析したりすることもできる。それにより全体の状況を正確に認識して、プロカメラマンや観客が保有するカメラ端末等やスマートフォンやタブレット等の端末にタイムリーに送信することができる。それにより、観客は競技の最新の状況をタイムリーに把握することが可能となる。特に、プロカメラマンは、撮影した写真をすぐに、報道局などに送る必要があるが、カメラの画面を見ているだけでは視野が狭いので競技の全体の状況などが正確に把握しにくい。しかし、本実施例のような構成を用いれば、競技の状況などが速やかに分かるので、報道局などに送る写真の選択を素早く行うことが可能となる。

なお、プロカメラマンや観客が用いる端末（画像処理装置）としては、デジタルカメラ、スマートフォン、カメラとスマートフォンなどを接続した構成、タブレットＰＣあるいはＴＶなどが考えられる。家庭でインターネットやテレビ放送をＰＣやＴＶ等の端末（画像処理装置）を通じて競技を見ている観客に対しても同様のサービスを提供することができるので競技などの状況をより正確に把握することができ競技をより楽しむことができる。

図１において、１０１～１０３はサーバー用のカメラであり、１０１（固定設置されたカメラ１）、１０２（固定設置されたカメラ２）、１０３（固定設置されたカメラ３）、１０４（大型スクリーン）、１１０（サーバー）、１１１（入力手段）、１１２（基地局）は、一般のプロカメラマンや観客への情報提供をするための映像取得や音声取得などを行う。サーバー用カメラは、本実施形態では１０１～１０３の３台としたが、１台でも複数台でもよい。また、これらのサーバー用カメラは、固定設置されたカメラではなく例えばドローンなどに搭載されたカメラでもよい。映像取得、音声取得に加えて、入力手段から映像以外の入力情報（例えば音声など）も取り込み、一般のプロカメラマンや観客等へのサービスを拡充できる。

１０５は有線／無線などによるＬＡＮやインターネットであり、１０６は、入力手段１１１から出力された情報をサーバー１１０で入力するための接続線である。１０７は、基地局１１２への信号を送受信するための接続線、１０８は、基地局の無線通信を実行するためのアンテナ部である。
すなわち、上記の１００番台のブロックは、プロカメラマンや一般観客などによる映像撮影等をサポートするためのブロックである。

一方、図１において、４０１（端末１）、４０２（端末２）、４０３（端末３）は端末であり、例えばプロカメラマンや観客が撮影やモニターをするための例えばカメラやスマートフォンやタブレットＰＣやＴＶなどの映像表示端末装置である。ここで、４０４（アンテナ）４０５（アンテナ）、４０６（アンテナ）は、それぞれ、４０１（端末１）、２０２（端末２）、２０３（端末３）が無線通信するためのアンテナである。

サーバーが注目選手の位置を検出する際には、例えば端末からサーバー側に注目選手のＩＤ情報などを送り、また、サーバー側から端末にその選手に関する位置情報などの各種情報を送る。選手は動いており、競技状況も変化しているので、短時間での注目選手の検出処理が必要になる。よって、ここでの無線通信は、例えば５Ｇなどを用いる。

なお４０１（端末１）、４０２（端末２）、４０３（端末３）はカメラとスマートフォンなどを接続して組み合わせた構成としても良い。図１の右下において、３０１はスマートフォンであり、主にサーバーとの通信制御を行う。また、このスマートフォンに、アプリケーションソフトウェアをインストールすることで、各種の映像取得サービスを実現する。また、３００は（デジタル）カメラであり、主に、プロプロカメラマンや観客が撮影したり画像をモニターしたりする画像処理装置である。ここで、カメラ３００はスマートフォン３０１にＵＳＢあるいはブルートゥース（登録商標）などにより接続されている。３２０はスマートフォン３０１が基地局１１２と無線通信するためのアンテナである。

なお、端末がスマートフォン等の場合は、サーバーとの映像、制御信号のやりとりを無線で実行するが、端末との通信を実行するための接続は、無線通信と有線通信を適応的に使い分けても良い。例えば、無線通信環境が５Ｇであれば無線で通信し、無線通信環境がＬＴＥであればデータ量の多い情報は有線で送り、データ量の少ない制御信号は無線で送るといった制御も可能である。さらには、無線通信の回線の混み具合によって、有線通信に切り替えることも可能である。

次に、図２はサーバー側の詳細なブロック構成図であり、図２について説明する。図２において、図１と同じ符番は同じ構成を示し説明は省略する。
２０１は、イーサネット（登録商標）コントローラであり、２０４は選手の役割（所謂ポジション）に応じたプレイ位置を検出する検出部である。ここで選手の役割（ポジション）は予め登録等によって設定される。例えば、ラグビーの場合の役割（ポジション）としては、１、３はプロップ、２はフッカー、４、５はロック、６、７はフランカー、８はナンバー８と呼ばれ、９はスクラムハーフ、１０はスタンドオフと呼ばれる。また、１１、１４はウィング、１２、１３はセンター、１５はフルバックと呼ばれる。
これらの選手のいる場所は、セットプレイの時などは、フォワードは、攻撃している前方にいて、バックスは、攻撃している後方にいることが多い。

すなわち、選手の役割（ポジション）に応じて、選手のいる位置が大体決まるので、注目選手の上記役割（ポジション）を把握したうえで、選手を追いかけたほうが、効果的に精度よく選手を追いかけることができる。
なお、通常は、背番号から、選手の役割は認識できることが多い。しかしながら、場合によっては、１０番の選手が怪我をして、１５番の選手がスタンドオフ（１０番の位置に入り）、リザーブ選手が、１５番に入ることなどがある。ここで、リザーブ選手の背番号は、１６から２３である。しかし、背番号だけからポジションが確定するわけではない。従って２０４の検出部では選手の予め設定された役割に応じたプレイ位置を検出し、この検出したプレイ位置の情報は、サーバー１１０内のＣＰＵ２１１に取り込まれるが、上記の予め設定された役割は競技中に選手交代などによって変更になる場合もある。

２０５は、輪郭情報検出部であり、たとえば、プロカメラマンや観客が端末で映像をモニターしつつ、その位置、角度からカメラの倍率で撮影している時に、サーバー１１０は注目選手のいる位置を各端末４０１～４０３などに知らせる。また、撮影している注目選手の輪郭情報をサーバー１１０から各端末４０１～４０３などに知らせることで、各端末４０１～４０３側で、より確実に注目選手を認識することが可能になる。２０５のブロックで検出した輪郭情報は、ＣＰＵ２１１に取り込まれる。

２０６は選手の顔認識部であり、注目選手の予め登録された顔写真情報に基づきＡＩ、特に、ＤｅｅｐＬｅａｒｎｉｎｇなどの画像認識技術を用いて映像の中から選手を見つける。顔認識部２０６で検出した顔認識結果の情報もＣＰＵ２１１に取り込まれる。
２０７は選手の体格認識部であり、注目選手の予め登録された体格写真情報に基づき前記のような画像認識技術を用いて選手を見つける。

２０８は選手の背番号検出部であり、前記のような画像認識技術を用いて注目選手の、あらかじめ登録した番号（背番号など）から選手を見つける。なお選手の番号を検出する際はビブスの背中側の番号だけでなく、前側に書かれた番号を検出してもよいことは言うまでもない。２０９は位置情報作成部であり、カメラ１０１、１０２、１０３等のＧＰＳなどを用いた位置情報とカメラの向きと画角に関する情報から、各カメラの位置と方角と画角を認識する。そして、各カメラからの映像に基づきその選手がいるグラウンド上での絶対的な位置情報を三角測量方式で取得する。この位置情報作成部２０９は競技場に予め設置された基準位置検出用の基準指標としてのポールや競技フィールドのライン（例えばサイドラインやエンドライン）等の画面内での位置もあらかじめ映像から取得しておいてもよい。

そしてそれらを基準座標として競技場における注目選手のフィールドに対する絶対位置を取得するようにしてもよい。
２１０は各端末４０１～４０３から送られてくる各端末の位置情報と方角情報と画角情報から、各端末の位置と各端末のカメラの向いている方角と画角を検出するカメラ位置情報、方角検出部である。
２１１はコンピュータとしてのＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）であり、記憶媒体としてのプログラムメモリ７１２に記憶された制御用のコンピュータプログラムに基づいて、以下の実施例に示す制御を実行する中央演算処理装置である。

また、表示制御手段を兼ねており、後述する表示部２１４に表示する情報を制御する。２１３はＣＰＵ２１１において参照される各種データを記憶するデータメモリである。データメモリ２１３には過去の試合情報、過去の選手情報、本日の試合（競技）に関する情報、観客動員数に関する、天候などの情報、注目選手の情報、選手の現在の状況などが格納されている。注目選手の情報の中には顔、背番号、体格などの情報も含まれる。
１１０１はサーバー１１０内のデータバスラインである。

次に、画像処理装置としての端末側（カメラ）の詳細について図３、図４を用いて説明する。図３、図４は端末の構成例を示すブロック図であり、端末の例として（デジタル）カメラ５００全体の構成を２つの図面を用いて示す。
図３、図４に示される画像処理装置としての端末側（カメラ）は、動画および静止画の撮影、並びに、撮影情報の記録が可能である。また、図３、図４において、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）３１８、プログラムメモリ３１９、データメモリ３２０は重複して示すが、これらは同一のブロックでありそれぞれ１つだけ内蔵されている。
図３において、３０１はイーサネット（登録商標）コントローラである。３０２は記憶媒体であり、デジタルカメラで撮影した動画、静止画（写真）が所定のフォーマットで格納される。

３０３はＣＣＤやＣＭＯＳなどの撮像素子としてのイメージセンサーであり、光学像を光信号から電気信号に変換して、さらに、この情報をアナログ情報からデジタルデータに変換して出力する。３０４は信号処理部であり、イメージセンサー３０３から出力されるデジタルデータに対してホワイトバランス補正やガンマ補正などの各種補正をして出力するものである。３０５はセンサー駆動部であり、イメージセンサー３０３から情報を読み出すための水平垂直ライン駆動やイメージセンサー３０３がデジタルデータを出力するタイミング等を制御する。

３０６は操作部入力手段である。デジタルカメラで撮影する際の各種条件を選択したり設定したり、写真撮影するためのトリガー操作、フラッシュを使用するための選択操作、電池を交換する操作などに応じて入力が行われる。また、操作部入力手段３０６において、注目選手をサーバーからの位置情報に基づきＡＦ（オートフォーカス）するか否かを選択／設定できる。この注目選手をＡＦ（オートフォーカス）するかの選択／設定情報は、操作部入力手段３０６からバスライン３７０に出力される。
さらに、操作部入力手段３０６において、注目選手をサーバーからの位置情報に基づき自動追尾するか否かを選択／設定できる。どの選手を注目選手（特定の対象）に指定するか、注目選手の自動追尾をサーバーからの位置情報に基づき実行するか否かなどの情報は、選択手段としての操作部入力手段３０６によって生成される。即ち操作部入力手段３０６は特定の対象に関する指定情報を生成する指定情報生成手段として機能している。

３０７は送受信手段として機能する無線通信部であり、プロカメラマンや一般の観客などが持っているカメラ端末が無線でサーバー側と通信をするためのものである。３０８はデジタルカメラにおける撮影倍率を検出する倍率検出部である。３０９は操作部出力手段であり、デジタルカメラなどで撮影した画像情報を表示する画像表示部３８０にメニューや設定情報などのＵＩ情報を表示するためのものである。３１０は圧縮伸長回路であり、イメージセンサー３０３からのデジタルデータ（ＲＡＷデータ）を信号処理部３０４で現像処理後、圧縮伸長回路３１０で圧縮してＪＰＥＧ画像ファイルやＨＥＩＦ画像ファイルにするか、あるいは、ＲＡＷデータのまま圧縮してＲＡＷ画像ファイルにする。一方、ＲＡＷ画像ファイルをカメラ内で現像処理してＪＰＥＧ画像ファイルやＨＥＩＦ画像ファイルを生成する場合に、圧縮されている情報を伸張してＲＡＷデータに戻す処理を行う。

３１１は顔認識部であり、注目選手についてあらかじめサーバーに登録された顔写真情報を参照し、映像の中からその選手をＡＩ、特に、ＤｅｅｐＬｅａｒｎｉｎｇ等の技術を用いた画像認識によって見つけるためのものである。顔認識部３１１で検出した顔認識結果に関する情報は、バスライン３７０を介してＣＰＵ３１８に取り込まれる。

３１２は体格認識部であり、注目選手に関してサーバーに予め登録した体格写真情報を参照して、映像の中から前述のような画像認識技術によってその注目選手を見つける。
３１３は選手の背番号検出部であり、注目選手の背番号（もちろん前側の番号でもよい）から前述のような画像認識技術によって選手を見つけるものである。３１４は端末のレンズの向いている方角を検出する方角検出部である。３１５は端末の位置情報を例えばＧＰＳなどを用いて検出する位置検出部である。

３１６は端末の電源の状態を検出する電源管理部であり、電源スイッチがオフの状態で電源ボタンの押下を検出したら、端末全体に電源を供給する。３１８はコンピュータとしてのＣＰＵであり、記憶媒体としてのプログラムメモリ３１９に記憶された制御用のコンピュータプログラムに基づいて、以下の実施例に示す制御を実行する。また、表示制御手段を兼ねており画像表示部３８０に表示する画像情報を制御する。なお画像表示部３８０は液晶や有機ＥＬなどを用いた表示部である。
データメモリ３２０は、デジタルカメラの設定条件を格納したり、撮影した静止画、動画、さらには、静止画、動画の属性情報などを格納したりするためのものである。

図４において、３５０は撮影レンズユニットであり、固定１群レンズ３５１、ズームレンズ３５２、絞り３５５、固定３群レンズ３５８、フォーカスレンズ３５９、ズームモーター３５３、絞りモーター３５６、およびフォーカスモーター３６０を有する。固定１群レンズ３５１、ズームレンズ３５２、絞り３５５、固定３群レンズ３５８、フォーカスレンズ３５９は撮影光学系を構成する。なお、便宜上３５１、３５２、３５８、３５９は、それぞれ１枚のレンズとして図示しているが、それぞれ複数のレンズで構成されても良い。また、撮影レンズユニット３５０は、デジタルカメラに対して着脱可能な交換レンズユニットとして構成されてもよい。

ズーム制御部３５４はズームモーター３５３の動作を制御し、撮影レンズユニット３５０の焦点距離（画角）を変更する。絞り制御部３５７は絞りモーター３５６の動作を制御し、絞り３５５の開口径を変更する。

フォーカス制御部３６１は、イメージセンサー３０３から得られる１対の焦点検出用信号（Ａ像およびＢ像）の位相差に基づいて撮影レンズユニット３５０のデフォーカス量およびデフォーカス方向を算出する。そしてフォーカス制御部３６１は、デフォーカス量およびデフォーカス方向をフォーカスモーター３６０の駆動量および駆動方向に変換する。この駆動量および駆動方向に基づいてフォーカス制御部３６１はフォーカスモーター３６０の動作を制御し、フォーカスレンズ３５９を駆動することにより、撮影レンズユニット３５０の焦点を制御（フォーカス調整）する。

このように、フォーカス制御部３６１は位相差検出方式の自動焦点（ＡＦ）を実施する。なお、フォーカス制御部３６１は、イメージセンサー３０３から得られる画像信号のコントラストのピークをサーチするコントラスト検出方式のＡＦを実行しても良い。
３７１は、デジタルカメラ自身で注目選手の追跡を行うための追跡部である。ここでいう追跡とは例えば注目選手を囲む枠表示を画面内で移動させるとともに、前記枠によって追尾される注目選手にフォーカスを合わせたり、露出を合わせたりする。

ここで、追跡部３７１について図５を用いて説明する。
図５はデジタルカメラの追跡部３７１の機能構成例を示すブロック図である。追跡部３７１は、照合部３７１０と特徴抽出部３７１１と距離マップ生成部３７１２からなる。特徴抽出部３７１１はサーバーから送られた位置情報に基づき、追跡すべき画像領域（被写体領域）を特定する。そしてこの被写体領域の画像から特徴量を抽出する。一方、照合部３７１０は継続して供給される個々のフレームの撮像画像内で、前記の抽出した特徴量を参照して、前フレームの被写体領域と類似度の高い領域を被写体領域として探索する。

なお距離マップ生成部３７１２において、撮像素子からの１対の視差画像（Ａ像とＢ像）から被写体までの距離情報を取得し、照合部３７１０における被写体領域の特定精度を上げることもできる。ただし距離マップ生成部３７１２は必ずしもなくても構わない。
照合部３７１０が、特徴抽出部３７１１から供給される画像内の被写体領域の特徴量に基づいて被写体領域と類似度の高い領域を被写体領域として探索する際には例えばテンプレートマッチングやヒストグラムマッチングなどを用いる。

次に、図６を用いて注目選手表示開始シーケンスの例について説明する。これは、サーバー１１０とカメラ５００とで行うシーケンスである。図６（Ａ）は、カメラ５００側の問いかけ（リクエスト）に対して、サーバー１１０側が答えるシーケンスの一例を示す図である。そしてサーバー１１０側はカメラ５００側に、注目選手の絶対位置に関する情報を提供する。
カメラ５００からサーバー１１０には、注目選手指定情報（背番号、選手名などのＩＤ情報）を通知する。その際ユーザーは端末の画面上で注目選手の位置をタッチしてもよいし、指を画面にタッチしたまま注目選手の周りを指で囲んでもよい。

あるいはメニューで画面上に複数の選手のリストを表示し、その中の注目選手名をタッチしたりしてもよいし、あるいは画面上に文字入力画面を表示し選手名や選手の背番号を入力してもよい。その際、注目選手の画面上の顔位置をタッチすると顔を画像認識したり背番号を画像認識して選手名や背番号などを送ったりしてもよい。あるいは、画像認識せずに顔画像そのものをサーバーに送って、サーバー側で画像認識してもよい。またこの時あらかじめ決まったパスワードがあればそれもサーバーに送る。サーバー側では、映像を撮影することをサポートするブロックにより、注目選手指定情報（背番号、選手名等のＩＤ情報）に基づいて、選手のいる絶対値的な位置に関する情報をカメラに送る。パスワードもカメラから送られてくればそれに応じてカメラに送る情報の内容を変更する。

更に図６（Ａ）においては、カメラからサーバーに、プロカメラマンや観客が撮影しているカメラの位置情報、カメラの方角、カメラの倍率などの情報なども送る。サーバー側では、カメラが見ている位置、方角での自由視点映像を作り、さらに、カメラの倍率から、実際のカメラで見えている映像を認識する。この実際にカメラで見えている映像のどの位置に選手がいるかの位置情報、並びに、選手の輪郭情報などをカメラに送る。カメラは、サーバーから送られた位置情報、輪郭情報などをもとに、カメラの表示部の画面で注目選手をより精度高く目立つように表示するとともに注目選手に対してＡＦやＡＥを行う。

注目選手を見つける注目選手表示開始シーケンスの例を簡単に説明したが、さらに継続して選手を追いかけていきたい場合が多い。そこで、次に注目選手の追跡を継続するためのシーケンスについて図６（Ｂ）を用いて説明する。図６（Ｂ）においては、端末としてのカメラ５００から何度も、例えば周期的にサーバー１１０へ問い合わせ（リクエスト）を行って、選手の位置を継続して認識するものである。図６（Ｂ）において、カメラからサーバーに、注目選手表示開始シーケンス（Ａ１、Ｂ１、、、）を周期的に送り、サーバーから注目選手表示開始シーケンス（Ａ２、Ｂ２、、、）を周期的に受信して、注目選手の位置を認識する動作を何度も繰り返す。

更に図７は、カメラ側における注目選手表示開始シーケンスの他の例を示す図であり、カメラ自身でも自動的に注目選手を追跡する方法を示すものである。カメラ５００からサーバー１１０に注目選手のＩＤ情報を送って、一旦サーバーから注目選手の位置情報を取得する。取得後にその位置情報を参照して注目選手の位置を絞り込んだ後、カメラ５００自身で画像認識によって継続して注目選手を追跡する。その際図４、図５の追跡部３７１によって追跡を行う。なお、図７の注目選手表示追跡シーケンスにおいては、カメラ５００自身が画像認識技術で注目選手を追跡するが、途中で注目選手を見失ったとき（追跡に失敗したとき）には、カメラ側からサーバーに、注目選手の位置情報を再度リクエストする。具体的には、カメラで、注目選手を見失ったときには、カメラからサーバーに、再度注目選手表示開始シーケンス（Ａ１）を送り、サーバーから注目選手表示開始シーケンス（Ｂ２）を受信して、注目選手の位置を画面に表示する。そのあと再びカメラ自身が画像認識によって注目選手を追跡する。

なお、本実施例ではプロカメラマンや観客の撮影アシストのためのサービスの例を説明しているが、リモートカメラ制御に使ってもよい。サーバーからこれらの情報を送ることで、自動パンチルト雲台に搭載したリモートカメラにより、選手を追跡して、決定的瞬間を撮影することも可能である。
また、本実施例は撮影アシストの例を用いて説明しているが、端末が家庭用のＴＶであってもよい。即ち、ＴＶを見ている観客が注目選手を指定したら、サーバーがその注目選手の位置情報などをＴＶに送って注目選手を枠表示等により目立つように表示してもよい。なお、枠だけでなく、カーソル（例えば矢印など）で注目選手を示してもよいし、注目選手位置の領域の色や輝度を他の部分と異ならせてもよい。注目選手が端末の画面外にいる場合には、端末の画面に対してどの方向にずれているかを矢印や文字で表示してもよい。また表示画面外にいる場合に端末が現在見ている角度からどのくらい離れているか（ずれているか）、どのくらい端末を回転しないと注目選手が表示画面内に入らないかなどを矢印の長さや太さや、数字や目盛りなどで表示してもよい。

更に、画面内に注目選手がいる場合には付加情報を画面に表示するように制御し、画面外に注目選手が移動した場合には、矢印等で画面外にいることを表示しないようにユーザーが選択できるようにしてもよい。
あるいは競技の状況を自動的に判断して、注目選手がベンチに下がった場合等には、画面外に注目選手が移動しても、画面外にいることを矢印等で表示しないようにしてもよい。そのように自動的に付加情報の表示を消すモードと消さないモードをユーザーが選択できるようにすると更に使い勝手が向上する。
なお、本実施例ではカメラマンの撮影アシスト機能を主眼に置いているが、将来的にはこの部分がロボットカメラになっても良い。サーバーからこれだけの情報がもらえれば、カメラマンに代わって、自動雲台に搭載したロボットカメラが、選手を追跡して、決定的瞬間を撮影することも可能である。

なお、撮影された静止画像（写真）は、画像処理をした後に圧縮伸長回路３１０において例えば、ＪＰＥＧで圧縮した画像ファイルになる。
本実施例では、静止画像（写真）に各種のメタデータを付加して記録する。メタデータとしては、例えば撮影日時、撮影した位置情報（緯度、経度、高度、方向）、撮影した情報（絞り値、露出時間、ＩＳＯ感度、シャッタースピード、測光方式などが含まれる。更にメタデータとして、レンズ焦点距離、フラッシュの有無、露出補正値、手ブレ補正、色空間等）、撮影したカメラ情報（カメラの機種名、レンズ名）なども含まれる。これらのメタデータは、例えばＥｘｉｆ（ＥｘｃｈａｎｇｅａｂｌｅＩｍａｇｅＦｉｌｅＦｏｒｍａｔ）フォーマットで画像ファイル内に記録される。

図８はファイル構造の例を示す図であり、図８（Ａ）は本実施例における、ＤＣＦ（ＤｅｓｉｇｎｒｕｌｅｆｏｒＣａｍｅｒａＦｉｌｅｓｙｓｔｅｍ）サムネイルファイルの構造、図８（Ｂ）はＤＣＦ基本ファイルの構造を示す図である。
図８（Ａ）に示すように、ＤＣＦサムネイルファイルは、ＳＯＩ（ＳｔａｒｔＯｆＩｍａｇｅ）、Ｅｘｉｆ情報、サムネイルファイル、ＥＯＩ（ＥｎｄＯｆＩｍａｇｅ）等から構成される。一方、図８（Ｂ）に示すようにＤＣＦ基本ファイルは、ＳＯＩ、Ｅｘｉｆ情報、サムネイル、ＤＣＦ基本主画像、ＥＯＩ等から構成される。
ここで、ＳＯＩ（ＳｔａｒｔＯｆＩｍａｇｅ）はＪＰＥＧデータの先頭、ＥＯＩ（ＥｎｄＯｆＩｍａｇｅ）はＪＰＥＧデータの終端を表している。また、Ａｐｐ１（Ａｐｐｌｉｃａｔｉｏｎｍａｒｋｅｒｓｅｇｍｅｎｔ１）は、Ｅｘｉｆ情報を記憶する。

本実施例では、Ｅｘｉｆ情報として、選手を撮影した時には、選手名も含めてＥｘｉｆ情報として画像ファイルに記憶する。更に対戦カード、試合会場、試合時間、試合での経過時間などを記憶しても良い。
撮影した選手が誰であるかを判断して、データベースから選手固有の詳細情報をメタデータとして記憶することもできる。選手がトライを決めた時に、例えば、その選手の出場タイミング、現在の試合における時間、さらに、選手の試合中の行動記録（「～選手は、スタメンで出場し、前半３６分に１トライを決める。」）などをメタデータとして記憶しても良い。

なお、サーバー側は、メタデータ作成手段によって、一般情報（日付け、対戦カード、試合会場、試合時間、撮影時間、試合での経過時間、さらに、選手を撮影した時には、選手名等）、判定情報、試合終了後情報のメタデータを作成する。
本実施例では、静止画像（写真）に対応したメタデータとして、カメラ側は、上記のような一般情報及びカメラマンの音声情報に関するメタデータを格納するものとする。またサーバー側は、すべての情報（一般情報、判定情報、試合終了情報、プロカメラマン音声情報等）を記憶する機能を有する。なお、静止画像（写真）に対応したメタデータとして、カメラ側、サーバー側ともに、すべての情報（一般情報、判定情報、試合終了情報、プロカメラマン音声情報）を格納するようにしてもよい。

また、本実施例では、写真に対応したメタデータとして、カメラ側は、１枚の写真につき最新のメタデータのみ格納し、サーバー側は、各写真に対するメタデータとして最新のものだけでなく、過去の変更履歴まで含めて記憶しても良い。
また、注目選手の写真に対してだけ上記のようなメタデータを付加して記憶するのではなく、すべての選手の写真に対してメタデータを付加して記憶しても良い。
サーバーは、写真に対して付加された一般情報やカメラマンの音声情報などのメタデータに対して、更に審判などによる判定情報、あるいは、試合終了後の情報を追加することができる。このようにサーバー側でメタデータを追加した時に、カメラに対して、逐一そのことを知らせるようにしても良い。

また、サーバーは、写真（画像）をカメラ（画像処理装置）から受信した時に、所定のフォトエージェンシー（画像処理装置以外）を宛先として、その写真とメタデータを転送するようにしてもよい。その場合には、その写真のメタデータが変更になった時にその写真とメタデータを一緒にフォトエージェンシーに再送するようにしても良い。
本実施例では、特定の注目選手の写真を撮影した時に、試合の情報、および、この特定選手に関する情報をメタデータとして、サーバーから宛先の一つとしてデバイス端末（カメラ）に送る。更にカメラ（画像処理装置）以外の宛先として予め登録したフォトエージェンシーなどに送る。そして、カメラマンは更に試合開始前に試合情報などの各種メタデータを追加入力し、更に撮影時に、カメラマンの音声情報もメタデータとして撮影画像（写真）に付加する。更にそのメタデータ付きの写真をサーバーに送信すると、サーバー側で、審判などによる判定結果をメタデータとして入力する。

このようなメタデータにより、写真の付加価値があがる。しかもメタデータの追加などが短時間でできるようになり、報道局に付加価値の高い写真を速やかに送れるようになる。
更に、カメラマンの音声によるコメント等の情報を、カメラが認識した情報、サーバーが持っている情報により修正したり、組み合わせたりすることができる。

次に、図７におけるカメラ側の制御フローの例を、図９（Ａ）、（Ｂ）、図１０のフローチャートを用いて説明する。図９（Ａ）、（Ｂ）、図１０は、カメラ側における注目選手表示追跡制御フローを表している。
図９（Ａ）においてＳ１０１は初期化を表している。Ｓ１０２で写真撮影（静止画撮影）が選択されたか否かが判断され、写真撮影が選択されるとＳ１０３に進み、写真撮影が選択されていないとＳ１０１に進む。Ｓ１０３ではカメラの設定情報を入手する。Ｓ１０４では注目選手の撮影（指定）が選択されたか否かが判断され、注目選手の撮影が選択されているとＳ１０５に進み、注目選手の撮影が選択されていないとＳ１１０に進みその他の処理をする。Ｓ１０５は注目選手情報（注目選手のＩＤ情報等）とパスワードがあればそれをカメラからサーバーに送る。これによってサーバー側は注目選手の位置情報を検出してカメラに送信する。Ｓ１０６ではサーバーから注目選手の位置情報等をサーバーから受けとる。

Ｓ１０７はサーバーから送られた位置情報を参照しつつカメラ自身で注目選手の追跡を実施する。ここでは、カメラ自身で注目選手について例えば画像認識を行って追跡する。その場合、選手の背番号、選手の顔情報、選手の体格などのいずれかの認識結果あるいはそれらの組み合わせに基づき選手の追跡を行う。すなわち、注目選手の一部または全体の形状を画像認識して追跡する。ただし、ユーザーの撮影ポジションが悪い場合や、カメラの視界が狭い場合や、撮影角度などによっては他の被写体の背後に隠れてしまったりするので見失う可能性があり、見失った場合には再度サーバーに位置情報のリクエストを送ることになる。

Ｓ１０７－２は、注目選手に対する付加情報としてのマーク表示の例を示している。即ち付加情報としては、注目選手を示すカーソルを表示したり注目選手の位置に枠を表示したり、注目選手位置の色や輝度を目立つように変更したり、あるいはそれらの組み合わせにより表示をする。マーク以外にも文字で表示したりしてもよい。そして画像表示部にイメージセンサーからのライブビュー画像を表示している状態において、注目選手に位置を示す付加情報を重畳する。

図９（Ｂ）にＳ１０７－２のマーク表示のフローの具体例を示しており、Ｓ１２０ではサーバーから受け取った位置情報に基づき、表示部における注目選手の相対位置を計算して求める。Ｓ１２１では画像表示部にイメージセンサーからのライブビュー画像を表示している状態において、注目選手に位置を示すマークなどを画像に重畳する。
なお、上記のようなＳ１０７の追跡動作はスキップし、実行しないように選択スイッチでユーザーが選択可能にしてもよい。あるいは、注目選手が画面内にいるときには追跡動作を実行するが画面外に出た場合には追跡動作をしない、というモードを設け、そのモードを選択できるようにしてもよい。更には、競技の状況を自動的に判断し、例えば注目選手がベンチ入りした場合などに、画面外の注目選手の追跡動作（矢印などの付加情報を表示など）を自動的に停止するように制御してもよい。あるいは画面内であるか画面外であるかにかかわらず、注目選手がベンチ入りしたことがサーバー側でわかったら画面における注目選手位置の表示や注目選手に対するオートフォーカスや注目選手に対する自動露光調整を停止するように制御してもよい。

Ｓ１０８では、注目選手の追跡継続がＯＫ（成功している）か否かを判断し、注目選手の追跡継続に成功していれば、Ｓ１０７に戻り、再度注目選手の位置を認識して、注目選手の撮影を継続する。一方、追跡が失敗した場合はＳ１０８でＮｏとなり、Ｓ１０９に進む。
Ｓ１０９では注目選手の撮影が終了したか否かが判断され、注目選手の撮影が終了するとＳ１０１に戻り、注目選手の撮影が継続している場合には、図１０のＳ１１１に進む。

図１０のＳ１１１において、予め選択した注目選手の撮影が実際に行われたか判断され、注目選手の撮影が実際に行われた場合にはＳ１１２に進み、撮影時のカメラマンの音声情報を不図示のマイクから入力する。注目選手の撮影が実際には行われていないとＳ１０７に進む。Ｓ１１３において、Ｓ１１２で入力した音声情報を音声認識により文字情報に変換し記憶する。Ｓ１１４において、注目選手のメタデータ（一般情報）をサーバーから入力する。なお、サーバーから取得したメタデータに関する情報（例えば一般情報の中身等）をカメラ側の表示装置でユーザーがメニュー操作で選択した場合には表示できるようにする。あるいはユーザーがメニュー操作で予め設定していた場合には、表示装置の画面に自動的に表示するようにしても良い。なお、その際注目選手の位置情報など他の情報と同時に表示しても良いし、サーバーから取得したメタデータに関する情報だけを選択的に表示しても良い。あるいはＳ１１５において、撮影した写真に対して、文字情報に変換された音声情報をメタデータとする。Ｓ１１６において、上記Ｓ１１４、Ｓ１１６等で取得されたメタデータをＥｘｉｆ情報として撮影画像（写真）に付加して記録媒体に記録する。Ｓ１１７において、上記のメタデータを付加した写真をサーバーに送り、その後、図９（Ａ）のＳ１０７に進む。

次に図１０の変形例である実施例２について図１１のカメラ側の着目選手表示追跡制御フローの例を示すフローチャートを用いて説明する。図１１において図１０と同じ符番は同じステップを示すので説明は省略する。
実施例２では、撮影時に付加されたメタデータ（文字情報に変換された音声情報等）を、審判の判定情報などのメタデータに置き換える。
即ち、図１１のＳ１１８において、撮影した写真のメタデータの更新がサーバー側でなされたか否かが判断される。そして、撮影した写真のメタデータの更新があるとＳ１１９に進み、撮影時のメタデータ（文字情報に変換された撮影時の音声情報等）を審判の判定情報に置き換える。即ち更新する。また、サーバーから取得したメタデータに関する情報（例えば更新されたメタデータの中身等）をカメラ側の表示装置でユーザーがメニュー操作で選択した場合には表示できるようにする。撮影した写真のメタデータの更新がないと図９（Ａ）のＳ１０７に進む。また、Ｓ１１１で注目選手の撮影がなかった場合にはＳ１１８に進む。

なお、実施例２では、判定情報によりメタデータを書き換えたが、判定情報をメタデータとして写真に追加して記録しても良い。このようにすれば、カメラマンの音声メモなどとともに、審判などの判定情報も写真に対して追加保存できるので、写真に対するいろいろな付加情報が残ることになり、後で写真（画像）の分析や選別をする際に役立つ。
なお、審判などの判定情報をメタデータとして写真に記憶する際に、この判定情報を画面に文字情報として表示しても良い。これによってカメラマンが、撮影した写真に対して、どのような判定がなされたかを画面で確認することができる。例えば具体的には、「～選手は後半５分から出場して、後半３５分に、トライ成功と思われたが、判定の結果は、ノートライでした。」などと画面表示することができる。

同様に、撮影時のカメラマンの音声情報のメタデータと審判の判定情報と、試合後の結果情報のメタデータを写真にメタデータとして付加して記憶するとともに、画面に表示してもよい。
また、例えば、選手がスタメンで試合に出場して、選手交代で退いた時刻、さらに選手交代で試合に出場した時刻などの情報も選手に着目したメタデータとして写真に付加して記憶したり表示したりしても良い。

以上説明したように、カメラからメタデータ付きの写真をサーバーにアップロードし、その後、サーバー側で、同じ写真に対してメタデータ（判定情報、試合結果情報など）を変更や追加した場合に、カメラ側ではメタデータの変更のみを実行しても良い。
なお、サーバーは、登録された選手などに関する一般的な選手としての情報をデータベースとして保存しているだけでなく、メタデータ化したデータベースとして保存していても良い。

なお、実施例では、サーバー１１０は、例えば競技フィールド全体の映像を読み取り座標を取得することができるので、プロカメラマンや観客が撮影している画像を分析することができる。それによって、競技フィールドに対してどこから撮影しているかを把握することもできる。すなわちサーバーは、サーバー用の複数台のカメラ（固定カメラや移動カメラ）から競技フィールドの全体の映像をあらかじめ把握しておく。それにより、フィールド内における注目選手の絶対位置情報と、プロカメラマンや観客が端末やデジタルカメラで見ている映像とのマッピングが可能になる。

また、プロカメラマンや観客のカメラ等の端末は、サーバーから選手の絶対位置情報を受信するとこの絶対位置情報と今撮影あるいはモニターしている映像とのマッピングが可能になる。なお、例えばサーバーからの注目選手のフィールド内での絶対位置情報を（Ｘ、Ｙ）とする。この絶対位置情報を個々のカメラの位置情報に従い、カメラから見たときの相対的な位置情報（Ｘ´、Ｙ´）に変換する必要がある。上記の絶対位置情報から相対位置情報への変換は、Ｓ１２０のようにカメラ側で実施してもよいし、サーバー側で変換した後に個々の端末（カメラなど）に相対位置情報を送ってもよい。

カメラ等の端末で上記変換を実行する場合は、サーバーから送られた絶対位置情報（Ｘ、Ｙ）から個々のカメラのＧＰＳ等を用いた位置情報に従い、相対的な位置情報（Ｘ´、Ｙ´）に変換する。この相対的な位置情報をもとに、カメラ側の表示画面内での位置情報とする。
一方、サーバーで上記変換を実行する場合は、サーバーは、絶対位置情報（Ｘ、Ｙ）から個々のカメラのＧＰＳ等を用いた位置情報に従い、個々のカメラの相対的な位置情報（Ｘ´、Ｙ´）に変換する。サーバーは、個々のカメラに対して、この相対的な位置情報を送り、この相対的な位置情報を受信したカメラは、この相対的な位置情報を個々のカメラ側の表示画面内での位置情報とする。

以上のようにして、プロカメラマンや観客のカメラ等の端末では、注目選手を見失うことが減るので、タイミングを逃さず注目選手の良い写真の撮影が可能になるという効果もある。
上記のような構成によって、カメラマン、あるいは一般観客が保有するカメラでは、注目選手の情報をサーバーに送り、サーバーから取得した情報をもとに注目選手の追跡を実施する。更にこれに合わせて、カメラマン、あるいは、一般観客が保有するカメラ自身でも注目選手の位置を検出することができる。

なお、例えばラグビー競技においては、メタデータとしては、例えば試合開始４８時間前の情報、試合開始数時間前の変更情報、試合中の選手の変更などの情報、撮影時の例えばカメラマンの音声コメント情報などが考えられる。更に、審判の判定に関する情報、試合終了時点での試合結果などに関する情報、サーバーがラグビー協会などから入手してくる情報なども考えられる。また、カメラなどのデバイス情報を入手し、このカメラのデバイス情報をサーバーが分析した結果得られる情報、カメラマンなどの撮影者から得られる情報などもある。

これらのメタデータを統合的にサーバーに蓄積して、必要な情報をカメラに送信する。カメラは、サーバーから取得した情報を、写真のメタデータとして追加する。
サーバーは撮影した選手が誰かを判断して、選手固有の情報をメタデータとして格納することもできる。例えば、その選手の出場タイミング、現在の試合における時間、さらに、選手の動作（「ＡＡＡ選手は、スタメンで出場し、前半３６分に１トライを決める。」）をメタデータとして格納しても良い。

次に、図１０に示した実施例１に対応した、サーバー側における注目選手の検出制御フローについて図１２、図１３を用いて説明する。ここでは撮影時に、カメラマンの音声情報をメタデータとして含める場合を説明する。
カメラ等の端末から送られてきた注目選手のＩＤ情報等に基づき、サーバーは注目選手の画像認識を行い画面の中からその注目選手を探す。サーバーはサーバー用の複数台のカメラ（固定されたカメラや移動カメラなど）からの映像をもとに選手の位置情報を検出して、プロカメラマンや観客のカメラ端末などに選手の位置情報を送る。特に、プロカメラマンや観客が撮影を行う際に、サーバーからの注目選手の位置情報があれば注目選手を間違えることなく確実に撮影できる。さらに、カメラでも注目選手の追跡を実施している際に、死角となって選手を見失ったときなどにおいても同様に、サーバーからの情報は重要になる。なお、サーバー側ではサーバー用の複数台のカメラからの映像をもとに選手の位置情報を検出し続ける。

図１２は、実施例１に対応した、サーバー側における注目選手の検出制御のメインフローを示す。
図１２において、最初にＳ２０１で初期化を行う。次にＳ２０２でカメラにおいて写真撮影が選択されたか否かが判断され、写真撮影が選択されるとＳ２０３に進み、カメラの設定情報を入手する。このときカメラの設定情報の中にパスワードがあればそれも入手する。写真撮影が選択されていないとＳ２０１に進む。Ｓ２０４では、注目選手の撮影（指定）が選択されたか否かが判断され、注目選手の撮影が選択されているとＳ２０５に進み、サーバーは、カメラから注目選手のＩＤ情報（例えば選手名、背番号など）を受信する。Ｓ２０４で注目選手の撮影が選択されていないとＳ２１０に進みその他の処理をする。

Ｓ２０６で、サーバーは、前記注目選手のＩＤ情報に基づき、複数のカメラ（固定カメラや移動カメラなど）からの映像に基づき画像認識によって、注目選手を画面内で見つける。Ｓ２０７で、サーバーは、複数のカメラからの映像に基づき注目選手を追跡する。Ｓ２０８で、カメラからの情報により、注目選手の写真撮影（静止画撮影）があるか否かが判断され、注目選手の実際の撮影がある場合はＳ２０８－２に進み、注目選手の実際の写真撮影がないと、Ｓ２０５に戻る。
Ｓ２０８－２では、撮影時のメタデータがついている写真をカメラから受信する。ここで、メタデータとしては、カメラマンがシャッターをきった時のカメラマンの音声情報やその他の一般情報などのメタデータが含まれている。

Ｓ２０８－３は、Ｓ２０８－２の写真を予め登録した所定の宛先であるフォトエージェンシーに送る。
これにより、フォトエージェンシーは、撮影されたメタデータ付きの写真を早いタイミングで受け取ることが可能になり、写真情報の活用が可能になる。
Ｓ２０９では、注目選手の撮影が終了したか否かが判断され、注目選手の撮影が終了するとＳ２０１に戻り、注目選手の撮影が継続している場合には、Ｓ２０５に戻る。そして、再度、サーバーは、カメラマン、あるいは、一般観客の保有するカメラからの情報を認識する。そして、複数のサーバー用のカメラ（固定カメラや移動カメラ）からの情報を探索して、注目選手を見つけて、Ｓ２０７で、継続してサーバーは、複数のカメラからの映像に基づき、注目選手の追跡を実施する。

Ｓ２０２で写真撮影が選択されていない場合には、Ｓ２１１で、メタデータの入力が選択されたか判断され、メタデータの入力が選択されているとＳ２１２に進み、メタデータの入力を実施し、メタデータの入力が選択されていないとＳ２０１に戻る。
Ｓ２１２でのメタデータの入力は、ラグビーの試合開始前に入力されるものであり、その際のメタデータとしては、例えば試合開始前の情報（４８時間前）、試合開始に先立って行われた例えば出場選手の変更（数時間前の情報）などがある。

これにより、試合の開始前のメタデータ情報は、サーバー側に予め一旦蓄積しておく。そして、カメラマンが実際に撮影を行った時、すなわち、シャッターを切った時に、カメラマンの音声情報とともにメタデータとして、サーバー側で写真に追加することが可能になる。
これにより、カメラマンの音声メモを写真のメタデータとして残すことが可能になるとともに、例えば試合開始前の試合に関する情報などは、カメラマンが、入力しなくてもサーバーにおいて自動的に入力されることになる。従って、カメラマンは撮影や音声メモに集中でき、撮影直後に音声のメタデータ付きの写真を報道局などに送ることが可能になる。

次に上記Ｓ２０６において注目選手を見つけ、Ｓ２０７で追跡するための方法の例について図１３を用いて説明する。
図１３は背番号情報を用いた注目選手検出制御フローを示す。図１３において、Ｓ４０１で、サーバーは注目選手のＩＤ情報に基づきデータメモリ２１３から背番号を取得し、サーバー用の複数台のカメラの映像情報の中からこの背番号を画像認識で探し、その背番号の選手の位置情報を取得する。Ｓ４０２において、更にサーバー用の複数台のカメラの画像から取得された位置情報を総合することにより、注目選手の絶対位置情報を取得する。このようにサーバー用の複数台のカメラの情報を総合することによって、ある背番号の選手の絶対位置情報の精度が向上する。Ｓ４０３では、Ｓ４０２で検出した注目選手の絶対位置をプロカメラマンや観客の保有するカメラ等の端末に対して送信する。Ｓ４０４では、注目選手の追跡が継続しているか否かが判断され、注目選手の追跡が継続しているとＳ４０１に戻り、注目選手の追跡が継続していないと図１３のフローを終了する。

次に、図カメラマンの音声情報を、審判の判定情報に置き換えてメタデータとする例について図１４のフローチャートを用いて説明する。この図１４は図１１に示したカメラ側の実施例２に対応したサーバー側のフローチャートである。
Ｓ２０１からＳ２０７、Ｓ２０８－２、Ｓ２０８－３、Ｓ２０９から２１２は、図１２と同一なので説明を省略する。
Ｓ２０８では、カメラからの情報により、注目選手の実際の撮影があるか、すなわち、シャッターをきることがあるか否かが判断される。そして、注目選手の実際の撮影がある、すなわち、シャッターを切ることがあると、Ｓ２０８－２に進み、注目選手の実際の撮影がない、すなわち、シャッターを切ることがないと、Ｓ２１３に進む。
Ｓ２１３においては、カメラマンの音声情報から入力したときの判定情報がサーバーにあるか否かが判断され、ＹｅｓであればＳ２１４に進み、ＮｏであればＳ２０５に進む。

Ｓ２１４は、カメラマンの音声情報のメタデータを、審判の判定情報に変更する。また、メタデータが変更されるので写真の名称を更新する。
このように、試合の開始前に取得されたメタデータは、サーバー側に蓄積しておいて、カメラマンが実際に撮影を行った時に、カメラマンの音声情報をメタデータとして写真に付加して、サーバーに送る。サーバーでは、審判の判定がカメラマンの音声メモと異なるときに自動的にメタデータを書き換えることが可能になる。
Ｓ２１４－２では、Ｓ２１４でのメタデータをカメラに送る。これによってカメラ側では、サーバーから送られたメタデータに関する情報（例えば判定情報の中身等）をカメラ側の表示装置でユーザーがメニュー操作で選択した場合には表示できるようになる。

これにより、カメラにおいても、サーバー側のメタデータと同期させることが可能になる。カメラでは、写真（静止画像）は変更せず、写真のメタデータのみ変更する。
次にＳ２１４－３において、上記Ｓ２１４でメタデータと名称を変更した写真を、フォトエージェンシーに送り、その後Ｓ２０５に進む。
これにより、フォトエージェンシーは、メタデータが変更になった時に、名称番号が変更された写真として受け取ることが可能になり、写真情報の活用がより高まるとともに、カメラマンの作業が簡略化され、速やかに写真を報道局に送ることが可能になる。

次に図１５は、カメラマンの音声情報と審判の判定情報をともにメタデータとする実施例３に対応したサーバー側のフローチャートである。
Ｓ２０１からＳ２０７、Ｓ２０８－２、Ｓ２０８－３、Ｓ２０９から２１２は、図１２と同一なので説明は省略する。
Ｓ２０８では、カメラからの情報により、注目選手の実際の撮影があるか、すなわち、シャッターをきることがあるか否かが判断される。そして、注目選手の実際の撮影がある、すなわち、シャッターを切ることがあると、Ｓ２０８－２に進み、注目選手の実際の撮影がない、すなわち、シャッターを切ることがないと、Ｓ２１５に進む。
Ｓ２１５においては、カメラマンの音声情報を入力した際の判定情報がサーバーにあるか否かが判断され、ＹｅｓであればＳ２１６に進み、ＮｏであればＳ２０５に進む。
Ｓ２１６では、カメラマンの音声情報のメタデータに、判定情報のメタデータもともに記憶する。まあ、メタデータが変更されているので写真の名称も変更する。

これにより、試合の開始前のメタデータ情報は、サーバー側に蓄積しておいて、カメラマンが実際に撮影を行った時のカメラマンの音声情報をメタデータとして、写真に付加するとともに、さらに、審判の判定もメタデータとして記憶することが可能になる。
Ｓ２１６－２では、Ｓ２１６のメタデータをカメラに送る。これによってカメラ側では、サーバーから送られたメタデータに関する情報（例えば判定情報の中身等）をカメラ側の表示装置でユーザーがメニュー操作で選択した場合には表示できるようになる。
これにより、カメラにおいて、メタデータを最新のものに更新することが可能になる。カメラでは、写真は変更せず、写真のメタデータのみ変更する。
Ｓ２１６－３は、Ｓ２１６において、変更したメタデータ付きの写真をフォトエージェンシーに送る。

これにより、フォトエージェンシーは、メタデータが変更になった時に、名称が変更された写真として受け取ることが可能になり、写真とメタデータを活用して速やかに出版等をすることができる。またカメラマンの作業は簡略化され、写真を速やかに報道局に送ることができる。

次に図１６、図１７のフローチャートを用いて、撮影時の情報として、プロカメラマンの音声情報と審判の判定情報と試合の結果情報を併記した情報をメタデータとする例について説明する。
図１６において、Ｓ２０９以外は図１２と同一なので説明は省略する。

Ｓ２０９において注目選手の撮影が終了した場合には図１７のＳ２１９に進む。Ｓ２１９では、試合が終了したか否かが判断され、試合が終了するとＳ２２０に進み、試合が終了していないとＳ２０５に進む。
Ｓ２２０では、試合終了後のメタデータがあるか否かが判断され、試合終了後のメタデ
ータがあるとＳ２２１に進み、試合終了後のメタデータがないとＳ２０１に進む。
Ｓ２２１では、カメラマンが入力した音声情報のメタデータ、判定情報のメタデータ、更に試合終了後のメタデータ情報も追加する。メタデータ変更に伴い写真の名称も変更する。
これにより、カメラマンの音声情報、審判の判定結果、試合終了後の情報もメタデータとして写真に付加することが可能になる。

Ｓ２２１－２では、Ｓ２２１のメタデータをカメラに送る。これによってカメラ側では、サーバーから送られたメタデータに関する情報（例えば判定情報や試合終了情報等）をカメラ側の表示装置でユーザーがメニュー操作で選択した場合には表示できるようになる。
これにより、カメラにおいて、メタデータを最新のものに更新することが可能になる。カメラでは、写真は変更せず、メタデータのみ変更する。
Ｓ２２１－３では、Ｓ２２１のメタデータ付きの写真をフォトエージェンシーに送る。
なお以上の実施例において、カメラからメタデータを有する写真をサーバーにアップロードする際には、カメラ側では写真１枚ずつに対して、メタデータのみを更新していく。一方、サーバー側では、メタデータが更新されたときに写真（撮影画像）のファイルをアップデートしていくので、写真は複数枚となり、写真の名称は更新されていく。

これにより、カメラマンの音声情報と、審判の判定結果と、試合終了後の試合結果情報をメタデータとして写真に格納することができる。写真の付加価値をより高めることができる。
プロカメラマンや一般観客にとって、ゲームの中での判定は気になるものである。審判は主審１人とタッチジャッジ２人の３人体制で行っている。特に、トライを決めたかに見えたシーンにおいての判定、あるいは、ゲームの中での反則が起きたかの判定など人間の眼だけでは判断ができないことがある。このために、肉眼での判定が難しい場合に審判の判定の手助けとなるビデオ判定（ＴＭＯ（テレビジョン・マッチ・オフィシャル））を行っている。

プロカメラマンや一般観客の保有するカメラ等の端末で、トライシーンを撮影した時に、今、撮影した画像は、トライとして認定されたかそれともトライにならなかったかをプロカメラマンや一般観客は即座に知りたい。そのため、複数台のカメラの映像から、その後の判定を追いかけたり、電光掲示板に表示される情報を基にしてサーバーで解析したりして判定を正確に認識する。そして審判の判定結果を、プロカメラマンや一般観客のカメラ等の端末に送信することにより、ユーザーは判定結果をタイムリーに正しく認識することが可能になる。

トライが行われたかどうかの検出方法は複数ある。以下に、具体的に説明する
トライ判定制御フロー（サーバー側）が図１８に図示されている。
図１８において、Ｓ１１０１は、初期化を表している。ここで、ＴＲＹジャッジフラグは、クリアする。Ｓ１１０２では、写真撮影が選択されたか否かが判断され、写真撮影が選択されるとＳ１１０３に進み、写真撮影が選択されていないとＳ１１０１に進む。Ｓ１１０３では、カメラの設定情報を入手する。Ｓ１１０４では、複数台のカメラの映像から、試合で使用しているボールを追いかける。

Ｓ１１０５では、ＴＲＹジャッジフラグが０であるか否かが判断され、ＴＲＹジャッジフラグが０であるとＳ１１０６に進み、ＴＲＹジャッジフラグが０でないとＳ１１０７に進む。Ｓ１１０６では、トライがあったようであるかが判断され、トライがあったようであるとＳ１１０７に進み、トライがあったようでなければＳ１１１２に進む。ここで、トライがあったようというのは、選手がボールをトライエリアに持ち込んでいる状態である。例えば、選手は、トライの直前に、ボールを前に落とすノックオンをしているケース、あるいは、守備の選手がトライしようとしているボールに手や体を入れて、グラウンディングを阻止していることもある。すなわち、トライが、確定した状態ではない。Ｓ１１０７は、ＴＲＹジャッジフラグに１をセットする。Ｓ１１０８は、トライの有無を判定する。
図１９、図２０、図２１、図２２に、トライの判定を行う具体例が図示されており、これらについては後述する。

Ｓ１１０９では、Ｓ１１０８の制御にて、トライの有無の判定結果がでたか否かが判断され、トライの有無の判定結果がでると、Ｓ１１１０に進み、トライの有無の判定結果がでていないとＳ１１１２に進む。Ｓ１１１０は、ＴＲＹジャッジフラグに０をセットする。Ｓ１１１１は、サーバーは、トライがあったか否かの情報をプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。Ｓ１１１２では、ゲームが終了したか否かが判断され、ゲームが終了しているとＳ１１０１に進み、ゲームが終了していないとＳ１１０４に進む。
以上は、トライの有無を判定する制御である。しかしながら、ＣＰＵはこの制御のみを実行するのではなく、例えば、図１２等に示した注目選手の検出制御と同時並行して実行しても良い。

なお、サーバーが同時並行して実行する制御はこれに限定されず、その他の複数の制御を同時に行っても良い。一方、プロカメラマンや一般観客が保持するカメラ等の端末についても、同様であり、その他の複数の制御を同時に行っても良い。
トライシーンの撮影をした際に、トライが成功したか失敗したかを正しく認識しないといけない。サーバーは、トライが成功したか、あるいは、コンバージョンが成功したかの判定を確認する。ここでは、トライの例で説明を行った。しかしながら、トライに限らず、その他の得点シーンに対しても同様の制御を実行できる。

複数台のカメラの映像を分析して、トライが行われたと思われるプレイがあった時には、複数台のカメラで、ボールの動きを分析して、ボールがきちんと所定エリア内にグラウンディングされていたか否かを認識する。サーバーは、認識したこのボールの動きからトライであったか否かの情報を選手情報とともにプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。
サーバー側でボールの動きからのトライの有無を判定するフローを図１９（Ａ）に示す。
図１９（Ａ）において、Ｓ１２０１では、サーバーは、複数台のカメラの画像からボールのある場所を検出する。Ｓ１２０２では、複数台のカメラの画像からトライと思われるシーンでトライがあったかをボールの動きから認識する。

次に、審判動作からのトライ有無判定フローが図１９（Ｂ）に示されている。
複数台のカメラの映像を分析して、トライが行われたと思われるプレイがあった時には、複数台のカメラの映像から、その後の注目選手の周囲にいる審判のルール上の動作を分析し画像認識して、審判の動作からトライであったか否かを認識してもよい。サーバーは、認識したこの審判の動作からトライであったか否かの分析結果に関する情報（動作認識結果）を選手情報とともにプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。

図１９（Ｂ）において、Ｓ１３０１では、サーバーは、複数台のカメラの映像からトライ判定をしているような動きの近くの審判の動作を検出する。Ｓ１３０２では、複数台のカメラの映像からトライと思われるシーンでトライがあったかを審判の動作から認識する。
図２０には、トライ有無判定の審判動作が、図示されている。図２０において、図２０（Ａ）は、トライが成立した時に、審判の動作である。図２０（Ｂ）は、トライが成立しない時の審判の動作である。

更に、競技場の大型スクリーンに表示される情報からトライの有無を認識するフローについて図２１を用いて説明する。
複数台のカメラの映像を分析して、トライが行われたと思われるプレイがあった時には、複数台のカメラで、競技場の大型スクリーンに映し出される情報を入力して、このスクリーンの情報からトライであったか否かを認識する。サーバーは、認識したこのスクリーンの情報からトライであったか否かの情報を選手情報とともにプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。

サーバー側における、スクリーン表示の判定結果からのトライの有無を判定するフローを図２１（Ａ）に示す。図２１（Ａ）において、Ｓ１４０１では、サーバーは、複数台のカメラからの画像からトライのような動きの後のスクリーンに表示される判定結果の情報を検出する。Ｓ１４０２では、複数台のカメラの画像からトライと思われるシーンでトライがあったかをスクリーンに表示される判定結果から認識する。

次にスクリーンに表示されている得点情報からトライの有無を認識するフローについて図２１（Ｂ）を用いて説明する。
複数台のカメラの映像を分析して、トライが行われたと思われるプレイがあった時には、複数台のカメラの画像に基づき、スクリーンに映し出される得点情報を入力して、このスクリーンの得点情報からトライであったか否かを認識する。サーバーは、認識したこのスクリーンの得点情報からトライであったか否かの情報を選手情報とともにプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。トライをすると得点は５点入り、その後のコンバージョンキックが成功すると得点は２点入る。

また、ペナルティキック、あるいは、ドロップゴールに成功すると得点は３点入る。トライが行われたと思われる前の得点とトライが行われた後の得点を比較することでトライが成功したかを認識できる。
スクリーンの得点情報からサーバーがトライの有無を判定するフローを図２１（Ｂ）に示す。

図２１（Ｂ）において、Ｓ１５０１では、サーバーは、複数台のカメラの画像からトライのような動きの後のスクリーンに表示される得点情報を検出する。Ｓ１５０２では、複数台のカメラの画像からトライと思われるシーンでトライがあったかをスクリーンに表示される得点情報の差分から認識する。Ｓ１５０３では、複数台のカメラの画像からトライと思われるシーンでトライがあったかをスクリーンに表示される得点情報の差分から、トライ、コンバージョンキック、ペナルティキック、あるいは、ドロップゴールを認識する。

次にフィールドでアナウンスされる音声情報からトライの有無を認識するフローについて図２２を用いて説明する。
複数台のカメラ（固定カメラや移動カメラ）についているマイクから入力される音声情報を分析し、トライが行われたと思われるプレイがあった時には、上記マイクからの音声情報からトライであったか否かを認識する。サーバーは、認識したこの音声情報からトライであったか否かの情報を選手情報とともにプロカメラマンや一般観客の保有するカメラ等の端末に対して送る。
サーバーによる、音声情報からトライの有無を判定する具体的なフローを図１６に示す。図２２において、Ｓ１６０１では、サーバーは、複数台のカメラのマイクからトライのような動きの後の音声情報を検出する。Ｓ１６０２では、複数台のカメラのマイクからトライと思われるシーンでトライがあったかを音声情報に基づき認識する。

上記の実施例においてはトライの得点の判断について述べたが、トライの得点に加えて、トライ後のコンバージョンによる得点、ペナルティキックによる得点を考えても良い。
なお、トライが行われたかどうかのサーバー側の検出フローは、図２３に図示されているが、トライが行われたかどうかに関するカメラ等の端末側の制御について説明する。
図２３はカメラ等の端末側のトライ判定制御フローを示している。図２３においてＳ１０１からＳ１０７－２、Ｓ１１０は、図９のステップと同一であるので説明を省略する。

Ｓ１６２０では、注目選手の追跡継続ＯＫ（成功している）か否かが判断され、注目選手の追跡継続に成功していれば、Ｓ１６２１に進む。Ｓ１６２１では、サーバーからトライ判定結果が送られたか否かが判断され、サーバーからトライ判定結果が送られるとＳ１６２２に進み、サーバーからトライ判定結果が送られていないとＳ１０７に戻り、カメラ自身で注目選手の追跡を継続する。Ｓ１６２２では、カメラの表示部にトライの判定結果を表示する。

なお、Ｓ１６２０で注目選手の追跡継続に成功していないとＳ１０９に進み、注目選手の撮影が終了したか否かを判断し、終了していなければＳ１０５に戻る。終了していればＳ１６２３に進み、サーバーからトライ判定結果が送られたか否かが判断され、サーバーからトライ判定結果が送られているとＳ１６２４に進みカメラ端末の表示部にトライの判定結果を表示する。サーバーからトライ判定結果が送られていないとＳ１０１に戻る。
以上により、トライらしき状態になった時に、カメラ端末側に、そのトライに成功したか否かを表示できるようになる。これにより、一般観客、あるいは、カメラマンは、例えば撮影した写真の評価を正しく認識できるようになる。そして、カメラマンは、カメラの表示部を見るだけで、判定について認識できるので、報道機関等に送る写真の選定を適切に行うことができるとともに、次の撮影に向けた準備をいち早くできる。

反則が起きた時に、複数台のカメラ（固定カメラや移動カメラ）で反則の状況を認識するが、この情報は、プロカメラマンや一般観客の保有するカメラ等の端末にも送られ上記端末で表示される。
ここでは、図２４にカメラ側の反則判定制御フローが図示されている。図２４はカメラ側でのトライ判定制御フローがベースになっており、カメラ側に反則の状況を表示するためのものである。
図２４において、図２３とはＳ７４２１～Ｓ７４２４のみが異なる。即ち、図２３におけるＳ１６２１、Ｓ１６２２、Ｓ１６２３、Ｓ１６２４は、Ｓ７４２１、Ｓ７４２２、Ｓ７４２３、Ｓ７４２４に置き換わり、それぞれ、の「トライ判定」が「反則判定」になっている点のみ異なる。

以上により、プロカメラマンや一般観客の保有するカメラ等の端末に、反則の状況を表示できるようになるので、プロカメラマンや一般観客は、撮影した写真の状況を正しく認識できるようになる。特に、プロカメラマンは、試合中に、写真を報道機関に送る必要があり、この写真選定にとって、有効な情報になる。
以上のように本実施例によれば、サーバーは、注目選手以外（特定の対象以外）の周囲の情報を分析し、分析結果をカメラ等の画像処理装置に送信するので、カメラ等の端末側ではトライやゴールや反則などの競技のリアルタイムの状況を把握できるようになる。従って、特に、プロカメラマン等は、試合中に、写真を選択してタイムリーに報道機関に送る際に、非常に有益な情報を得ることができる。

なお、選手の動きをビッグデータとしてサーバーに格納しておいて、このビッグデータをもとに、ＡＩによる選手の動き予測を行っても良い。なお、注目選手は１人だけ指定する例を説明したが、注目選手は複数選手指定しても良い。また、注目選手は、途中で切り替えができるものとする。注目選手として、試合に出場している選手全員でも良い。また、映像や画像としては、動画だけでなくて、静止画も含むものとする。また、注目選手を追い追跡することをメインに説明をしてきた。

しかしながら、注目選手だけを追いかけないで、ボールを持っている、あるいは、ボールを受ける選手についての情報をプロカメラマンや観客に送信し表示させるようにしてもよい。また、実施例では選手を追跡する例を用いて説明したが、犯人などの人物を複数の監視カメラなどを使って追跡するシステムに適用できることは言うまでもない。あるいは人物に限らずカーレーシングなどにおいて特定の車などを追跡するシステムや競馬等において馬を追跡するシステムに適用することもできる。なお、実施例では注目選手をカメラ端末などで指定する例を説明したが、サーバー側が注目選手を指定できるようにしてもよい。

なお、以上の実施例においては、ラグビーを例にして説明したが、その他のスポーツやフィールドワークなどにおいても適用できることは言うまでもない。
なお、サーバー側では、端末装置から送られた写真を、図示しないネットワークを介して、例えば放送局などにも送るようにしても良い。
以上実施例で説明したように、カメラマンは写真撮影に際して様々なデータをメタデータとして追加したいが、そのために写真撮影に集中できない恐れがある。しかし本実施例によればサーバーに写真を送ることによってサーバー側で写真に対する種々のメタデータを追加したり書き換えしたりできるので、カメラマンの撮影時の負荷が大幅に減る。それによってカメラマンは撮影に集中できようになる。また、サーバー側でその写真に関連した一般的情報や試合の判定情報など従来では得られなかった情報を付加することができる。従って、写真一枚一枚の付加価値を高めることができるとともに、後で写真の分析や選別や編集などをする際にも効率をアップすることができる。

以上、本発明の好ましい実施例について説明したが、本発明はこれらの実施例に限定されず、その要旨の範囲内で種々の変形及び変更が可能である。
また、本発明における制御の一部または全部を上述した実施例の機能を実現するプログラム（ソフトウェア）をネットワーク又は各種記憶媒体を介して撮像装置や情報処理装置に供給するようにしてもよい。そしてその撮像装置や情報処理装置におけるコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行するようにしてもよい。その場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することとなる。

１０１、１０２、１０３・・・・カメラ
４０１，４０２，４０３・・・・端末
１１０・・・・サーバー
３７１・・・・追跡部
３８０・・・・画像表示部

Claims

画像を表示する表示手段、
前記表示手段に表示された画像の中から特定の対象を選択する選択手段、
前記選択手段によって選択された前記特定の対象を指定する指定情報を生成する指定情報生成手段、
前記指定情報生成手段によって生成された前記指定情報をサーバーに送信する送信手段、
前記サーバーから前記表示手段に表示される画像における前記特定の対象の相対位置又は絶対位置を示す位置情報、及び前記サーバーにおいて作成された前記特定の対象の所定のメタデータを取得する取得手段、
前記取得手段によって取得された前記特定の対象の前記位置情報に基づく付加情報または前記所定のメタデータに基づく文字情報を前記表示手段に表示する制御手段、
を有することを特徴とする画像処理装置。
前記画像処理装置は撮影された画像を前記送信手段によって前記サーバーに送信することを特徴とする請求項１に記載の画像処理装置。
前記サーバーは前記送信手段によって送信された前記画像に対して前記所定のメタデータを付加することを特徴とする請求項２に記載の画像処理装置。
前記サーバーは前記所定のメタデータを付加した前記画像を所定の宛先に送信することを特徴とする請求項３に記載の画像処理装置。
前記所定の宛先は前記画像処理装置を含むことを特徴とする請求項４に記載の画像処理装置。
前記所定の宛先は前記画像処理装置以外の宛先を含むことを特徴とする請求項４に記載の画像処理装置。
前記画像処理装置においてメタデータを入力するための入力手段を有し、前記送信手段は前記入力手段によって入力されたメタデータを前記サーバーに送信することを特徴とする請求項１から５のいずれか一項に記載の画像処理装置。
前記サーバーは前記送信手段によって前記画像処理装置から送信されたメタデータに基づき前記所定のメタデータを作成するメタデータ作成手段を有することを特徴とする請求項７に記載の画像処理装置。
前記サーバーは前記メタデータ作成手段によって作成された前記所定のメタデータを、前記画像処理装置から送信されたメタデータと置き換えることを特徴とする請求項８に記載の画像処理装置。
前記入力手段によって入力されるメタデータは音声に関するメタデータを含むことを特徴とする請求項７に記載の画像処理装置。
前記入力手段は前記音声を文字に変換してメタデータとすることを特徴とする請求項１０に記載の画像処理装置。
画像処理装置から送られてくる特定の対象を指定する指定情報を受信する受信手段、
前記受信手段によって受信された前記指定情報に基づき、前記特定の対象を複数のカメラの画像の中から探して前記画像処理装置の表示手段に表示される画像における前記特定の対象の相対位置又は絶対位置を示す位置情報を生成する生成手段、
前記特定の対象の所定のメタデータを作成するメタデータ作成手段、
前記生成手段によって生成された前記特定の対象の位置情報および前記所定のメタデータを前記画像処理装置に送信する送信手段、を有することを特徴とする画像処理サーバー。
請求項１から１１のうちいずれか一項に記載の画像処理装置の各手段としてコンピュータを機能させるためのコンピュータプログラム。
請求項１３に記載のコンピュータプログラムを記憶したコンピュータで読み取り可能な記憶媒体。
請求項１２に記載の画像処理サーバーの各手段としてコンピュータを機能させるためのコンピュータプログラム。
請求項１５に記載のコンピュータプログラムを記憶したコンピュータで読み取り可能な記憶媒体。