特許 7504634 画像提供システム、その制御方法、プログラムおよび記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-14

(45)【発行日】2024-06-24

(54)【発明の名称】画像提供システム、その制御方法、プログラムおよび記憶媒体

(51)【国際特許分類】

   H04N 23/60 20230101AFI20240617BHJP

   G03B 5/00 20210101ALI20240617BHJP

   G03B 15/00 20210101ALI20240617BHJP

   G03B 17/53 20210101ALI20240617BHJP

   G03B 17/56 20210101ALI20240617BHJP

   G03B 17/00 20210101ALN20240617BHJP

【ＦＩ】

H04N23/60 500

G03B5/00 D

G03B15/00 D

G03B15/00 F

G03B17/53

G03B17/56 Z

H04N23/60 300

G03B17/00 X

【請求項の数】 8

(21)【出願番号】P 2020048159

(22)【出願日】2020-03-18

(65)【公開番号】P2021002825

(43)【公開日】2021-01-07

【審査請求日】2023-03-08

(31)【優先権主張番号】P 2019115713

(32)【優先日】2019-06-21

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100223941

【弁理士】

【氏名又は名称】高橋 佳子

(74)【代理人】

【識別番号】100159695

【弁理士】

【氏名又は名称】中辻 七朗

(74)【代理人】

【識別番号】100172476

【弁理士】

【氏名又は名称】冨田 一史

(74)【代理人】

【識別番号】100126974

【弁理士】

【氏名又は名称】大朋 靖尚

(72)【発明者】

【氏名】平石 智宣

(72)【発明者】

【氏名】徳永 幸史

【審査官】大西 宏

(56)【参考文献】

【文献】特開２００２－２２９１０１（ＪＰ，Ａ）

【文献】特開２００４－２９７３６３（ＪＰ，Ａ）

【文献】特開２００７－１４２８９６（ＪＰ，Ａ）

【文献】特開２０１９－０４９９６０（ＪＰ，Ａ）

【文献】米国特許出願公開第２００２／００８５７６２（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０３４７８２７（ＵＳ，Ａ１）

【文献】国際公開第２０１５／０３１８６３（ＷＯ，Ａ１）

【文献】国際公開第２０１６／０８８４３７（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２３／４０ －２３／７６

Ｇ０３Ｂ ５／００ － ５／０８

Ｇ０３Ｂ １５／００ －１５／０３５

Ｇ０３Ｂ １７／００

Ｇ０３Ｂ １７／４８ －１７／５５

Ｇ０３Ｂ １７／５６ －１７／５８

(57)【特許請求の範囲】

【請求項1】

ユーザによる入力に応じて、座席の購入数を受け付ける受付手段と、
前記ユーザによる入力に応じて、画像を購入するか否かを選択する選択手段と、
前記画像を購入することが選択された場合、撮像部により撮像される画像のうち、前記 ユーザにより指定された１つの座席および前記購入数に対応する範囲をトリミング範囲として、前記撮像部が前記座席側の被写体を撮像する前に決定する決定手段と、
前記撮像部により前記座席側の被写体の撮像が開始された後、前記トリミング範囲に基づき、前記撮像により撮像された画像の一部を切り出すトリミングを行ってトリミング済み画像を生成する生成手段と、
前記トリミング済み画像を前記座席を特定する座席番号とともに格納するように制御する制御手段とを有することを特徴とする画像提供システム。

【請求項2】

前記トリミング範囲は、前記指定された１つの座席と横に並んだ１つ以上の座席および前記指定された１つの座席と前または後に並んだ１つ以上の座席のうち少なくとも１つを含むことを特徴とする請求項１に記載の画像提供システム。

【請求項3】

前記生成手段は、前記撮像部により撮像された１枚の画像から複数のトリミング済み画像を生成することを特徴とする請求項１または２に記載の画像提供システム。

【請求項4】

前記画像提供システムは、別々の位置に置かれた複数のカメラの撮像部により撮像された複数の画像を受信可能であって、
前記複数の画像のうち、前記トリミング範囲を含む画像の一部を切り出すトリミングを行うことを特徴とする請求項１乃至３のいずれか１項に記載の画像提供システム。

【請求項5】

前記制御手段は、前記ユーザによる前記座席番号の入力に応じて、前記トリミング済み画像を前記ユーザに提示するよう制御することを特徴とする請求項１乃至４のいずれか１ 項に記載の画像提供システム。

【請求項6】

ユーザによる入力に応じて、座席の購入数を受け付けるステップと、
前記ユーザによる入力に応じて、画像を購入するか否かを選択するステップと、
前記画像を購入することが選択された場合、撮像部により撮像される画像のうち、前記ユーザにより指定された１つの座席および前記購入数に対応する範囲をトリミング範囲として、前記撮像部が前記座席側の被写体を撮像する前に決定するステップと、
前記撮像部により前記座席側の被写体の撮像が開始された後、前記トリミング範囲に基づき、前記撮像により撮像された画像の一部を切り出すトリミングを行ってトリミング済み画像を生成するステップと、
前記トリミング済み画像を前記座席を特定する座席番号とともに格納するように制御するステップとを有することを特徴とする画像提供システムの制御方法。

【請求項7】

コンピュータを、請求項１乃至５何れか１項に記載された画像提供システムの各手段として機能させるためのプログラム。

【請求項8】

コンピュータを、請求項１乃至５何れか１項に記載された画像提供システムの各手段として機能させるためのプログラムを格納したコンピュータが読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、画像提供システムに関し、特に画像を撮影し、提供する際の技術に関する。

【背景技術】

【0002】

スポーツの試合や、観光施設において楽しんでいるユーザを撮影する需要がある。特許文献１には、観客席にいるユーザが撮影エリアや撮影時刻などの撮影要求を入力すると、入力された撮影要求に基づき、カメラが観客のいるエリアを撮影することが開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００７－１４２８９６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１の方法では、観客の要求により、カメラの台数よりも一度に必要な撮影枚数が多くなってしまった場合には、観客の求める画像を提供できない可能性がある。

【0005】

本発明は、上記の課題に鑑み、複数の異なるトリミング画像を素早く提供することのできる画像提供システムの提供を目的とする。

【課題を解決するための手段】

【0006】

本願に係る発明の１つは、画像提供システムであって、ユーザによる入力に応じて、座席の購入数を受け付ける受付手段と、前記ユーザによる入力に応じて、画像を購入するか否かを選択する選択手段と、前記画像を購入することが選択された場合、撮像部により撮像される画像のうち、前記ユーザにより指定された１つの座席および前記購入数に対応する範囲をトリミング範囲として、前記撮像部が前記座席側の被写体を撮像する前に決定する決定手段と、前記撮像部により前記座席側の被写体の撮像が開始された後、前記トリミング範囲に基づき、前記撮像により撮像された画像の一部を切り出すトリミングを行ってトリミング済み画像を生成する生成手段と、前記トリミング済み画像を前記座席を特定する座席番号とともに格納するように制御する制御手段とを有することを特徴とする。

【発明の効果】

【0007】

本発明によれば、複数の観客の画像を一度の撮影で取得し、ユーザに応じたトリミング済み画像を素早く提供することができるという効果が得られる。

【図面の簡単な説明】

【0008】

【図1】本実施形態における画像提供システムにおける施設配置図。

【図2】本実施形態における画像提供システムのシステム全体構成図。

【図3】本実施形態における画像処理装置のブロック図。

【図4】本実施形態における、座席ごとのトリミング位置の設定の例を示す図。

【図5】本実施形態における座席ごとのトリミング位置の設定の例を示す図。

【図6】本実施形態におけるデータ構造を示す図。

【図7】本実施形態におけるチケット購入処理を示すフローチャート。

【図8】本実施形態における試合前の設定に関するフローチャート。

【図9】本実施形態における試合開始後の処理に関するフローチャート。

【図10】本実施形態におけるトリミング処理の例を示すフローチャート。

【図11】本実施形態におけるグループの人数に応じた座席配置の例を示す図。

【図12】本実施形態における座席配置における座席の関係性を示した図。

【図13】本実施形態におけるトリミング位置の計算方法を格納したデータ構造例の図。

【図14】本実施形態におけるトリミング位置の計算方法を格納したデータ構造例の図。

【図15】本実施形態におけるトリミング位置の計算例を示した図。

【図16】本実施形態において試合の終了後に画像を提供する場合のシステム全体構成図。

【図17】本実施形態において試合の終了後に画像を提供する場合のシステム全体構成図。

【発明を実施するための形態】

【0009】

以下、本発明を実施するための例示的な実施形態を、図面を参照して詳細に説明する。ただし、この実施形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。

【0010】

図１は、本実施形態における、画像提供システムにおいてリモートコントロール撮影を行うための施設配置図である。図１では説明の都合上、野球場を例としているが、スポーツ競技を行うスタジアムや、闘技場やコンサートを行うためのアリーナ会場、演劇やオペラを行う劇場など、多数の観客が定位置から観覧できる施設に対して適応される。

【0011】

図１（ａ）、（ｂ）、（ｃ）の野球場の例では、撮影指示部１０１が一塁側の内野席を撮影するためのカメラ１０２～１０５に対して同時に撮影指示を行う。本実施例では撮影を簡略化するためにカメラの台数を４台として説明するが、物理的に同時に撮影指示ができる範囲であれば、カメラの台数が本発明を限定するものではない。

【0012】

球場などで反対側の観客席の上段から撮影する場合などは、観客（被写体）までの距離が遠いため、焦点距離の大きい望遠レンズをつけていたとしても、ある程度の観客が１フレーム内に収まることになる。そのため、座席ごと・グループごとのトリミング処理が必要になってくる。また、焦点距離の大きい望遠レンズは高額であるため、投資を抑えようとすると、焦点距離を大きくすることができないため、より１フレーム内に収まる人数が増えるため、トリミング処理の必要性が増すことになる。また、１フレームの画角内に複数の観客を収めることによって、例えば１つのハイライトシーンにおける盛り上がる臨場感と表情ある複数の観客の画像を１度の撮影で取得することが可能になる。このとき、より１フレーム内に収まる人数が増えるため、トリミング処理の必要性が増すことになる。

【0013】

なお、撮影指示に関しては定期的に撮影するインターバル撮影（例えば１０秒に１回のレリーズ指示をする、など）と、オペレータの撮影意思に応じて手動撮影できる２つの手段を提供する。

【0014】

また、施設によってはより競技等のイベントを見やすい位置をより高額に設定し、見にくい位置を安価に設定することがあり、複数の券種が存在するのが通例である。図１（ａ）、（ｂ）、（ｃ）では、グラウンドに近いエリア１、席数が最も多いエリア２、それぞれ区切られた空間となっているエリア３を示している。エリア１では、より近くで観戦をしたいと考えている観客であり、席数が限られているため、何十人という単位ではなく、家族などの少ない人数で特別な時に観戦することが多いエリアである。よって、一緒に来たメンバーのみで思い出に残る画像を提供することが観客の満足度の向上につながる。エリア２では、高い頻度で観戦に来る多くのファンが観戦しているエリアであり、固まって熱意の高いファンが座っている。また、エリア２では体験として試合の観戦に来た観客や、試合自体に高い熱意のない観客など、様々な層の観客が含まれている。よって、観戦中の画像が欲しい観客もいれば、不要だと考える観客もいるエリアであり、観客の意思に応じた画像の提供をすることで観客の満足度が向上する。エリア３は、空間内で楽しむ観戦を楽しむ様子や、特定の観客が良い表情をしている画像を提供することで顧客の満足度が向上する。以上のようにエリアによって、観客のニーズが異なる。全ての観客のニーズにこたえるためには、撮影した画像を様々なパターンに応じて準備しておくことが求められるが、データ量が多くなるとコストが高くなり、観客が手軽に画像を購入できなくなるという課題もある。また、試合中に観客が観戦をしている間に画像を提供することで、観客の試合に対する満足度はより向上されるが、画像のデータ量が多いため、購入しない可能性の高い観客までの画像データをも処理しようとすると処理に時間がかかり画像の提供に時間を要してしまう。

【0015】

エリア１や３の観客は、撮影画像を購入する可能性がより高いと判断できるため、図１（ａ）ではエリア１をカメラ１０２・１０３の２台でカバーしているが、図１（ｂ）ではエリア１よりより広いエリア２をカメラ１０４・１０５の同様２台でカバーしている。その結果、エリア１の画像に収まる人数の方がより少なくなり、観客はより大きく写るので、トリミング済み画像の解像度が高くなり、より商品性の高い画像を得ることができ、より購買につなげることができる。なお、エリア３では、エリア１よりさらに狭い範囲を２台のカメラで撮影をすることで、さらにトリミング済み画像の解像度を高くする。エリア３では、より高解像度なトリミング済み画像が取得できるため、撮影した画像の画像解析も可能となり、エリア３では構造上観覧するスペースを含めて複数のスペースがあることが多いため観覧するスペースに所定以上の観客がいることを判断したり、顔の表情を解析してより良い画像を選択したり、などエリア１よりさらに商品性の高い画像を得ることが可能となる。もしくは、エリア１では、常に観客がカメラから撮影可能な位置にいるとは限らない。よって、リモート操作でカメラの首振りを行うことのできる雲台システムを使用して、１台のカメラで複数の区切られた空間を観測しておき、観客を撮影可能になったことに応じて特定の空間の撮影をしてもよい。

【0016】

図１（ｃ）には、撮影指示装置１０１から各カメラ群へと撮影指示をするための構成図を示している。撮影指示装置１０１は、図１（ｃ）に示すように複数のカメラ群ＡからＤへと撮影指示が可能である。カメラ群Ｃは外野席の広いエリア４を４台でカバーし、カメラ群Ｄは外野席の広いエリア５を４台でカバーする。

【0017】

カメラ１０２－１０５は、光学像を電気信号に変換するＣＣＤやＣＭＯＳ素子等で構成される撮像素子（撮像センサー）等で構成されるカメラユニットである。カメラには、ズームレンズやフォーカスレンズを含むレンズ群（撮影レンズ）、絞り機能を備えるシャッター、撮像素子、撮像素子から出力されるアナログ信号をデジタル信号に変換するＡ／Ｄ変換器、撮像系を覆って汚れや破損を防止するバリアを含む。カメラ内の画像処理部は、カメラで撮像して取得したデータに対し所定の画素補間、縮小といったリサイズ処理や色変換処理を行う。画像処理部により得られた演算結果に基づいてカメラ内のＣＰＵが露光制御、測距制御、ＡＷＢ（オートホワイトバランス）処理を行う。カメラで撮像され、画像処理部で画像処理された表示用の画像データは後述するＰＣのディスプレイ０４により表示される。カメラで撮像され、Ａ／Ｄ変換器によって一度Ａ／Ｄ変換されＲＡＭに蓄積されたデジタル信号をＤ／Ａ変換器でアナログ変換し、ディスプレイ０４に逐次転送して表示することで、ライブビュー表示（ＬＶ表示）を行える。ライブビューは、静止画の撮影待機状態、動画の撮影待機状態、動画の記録時に表示可能であり、撮像された被写体像がほぼリアルタイムに表示される。ＣＰＵは、入力装置０６で行われたユーザ操作に基づく撮影準備指示に応じて、ＡＦ（オートフォーカス）処理、ＡＥ（自動露出）処理、ＡＷＢ処理等の動作を開始するように、カメラ、画像処理部を制御する。カメラ側のＣＰＵは、撮影指示に応じて、本露光して撮像部素子からの信号を読み出し、撮像された画像を画像処理部で画像処理して画像ファイルを生成し、外部のストレージへ記録するまでの一連の撮影処理（本撮影）の動作を開始ように制御する。撮影指示は、ＰＣ２０１ａの入力装置０６に対するユーザ操作によって行うことも、カメラ側のシャッターボタンの押下によっても行うことができる。カメラは、静止画及び動画の撮影が可能である。

【0018】

なお、施設によっては構造上撮影するカメラ位置から座席のエリアごとに撮影距離や照度が異なるため、これらの条件によって一度の撮影で多くのエリアをカバーする本実施形態の撮影では、画質に差異がでてくることがあり、画質に応じて値段を変えたり提供枚数を多くしてもよい。また、単にグラウンドに近い席であり、カメラから距離の近い席の画像を高額に設定するのではなく、明るさ等の条件やカメラの台数により画質が良くなる座席を高額に設定するようなケースもある。

【0019】

図２は、本実施形態における、画像提供システムのシステム全体構成図である。画像処理装置２０１は、撮影指示部１０１と画像転送受信部２０１ｂと、トリミング部２０２と、選択・アップロード部２０３と、ストレージ２０４・２０５を持つ。

【0020】

図２において、各処理部１０１・２０１・２０２・２０３は１つの画像処理装置２０１の中に記載しているが、物理的に別の処理装置であっても構わず、処理部の構成が本発明を限定するものではない。

【0021】

撮影処理部１０１は、図１同様にカメラ１０２～１０５に同時に撮影指示を行う。撮影指示に関しては定期的に撮影するインターバル撮影（例えば１０秒に１回のレリーズ指示をする、など）と、オペレータの撮影意思に応じて手動撮影できる２つの手段を提供する。

【0022】

画像転送受信部２０１ｂは、カメラ１０２～１０５で撮影された画像が、カメラ側から転送されてきた画像データをストレージ２０４に記録する。画像データの送受信のプロトコルは、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）などを用いる。

【0023】

トリミング部２０２は、カメラ１０２～１０５からストレージ２０４に画像データが転送されたことをトリガーに、各画像データに対してトリミング処理を実施して、トリミング済み画像と座席番号をストレージ２０５に記録する。

【0024】

ここではストレージ２０４・２０５を別のストレージとして表現しているが、物理的には同じでも構わない。

【0025】

また、トリミング処理を行う際に、後述するチケット購入部２０６から事前に購入されたグループ人数・座席番号・座席配置を入手して、その情報を基にトリミング処理を実施するが、詳細な処理については図１０～１５で後述する。

【0026】

選択・アップロード部２０３は、ストレージ２０５に格納されたトリミング済み画像データと座席番号、及びイベントの日時情報を配信部２０７（配信サーバー）にアップロードする。撮影指示部１０１が競技中・イベント中にインターバル撮影を行っている場合には、大量のトリミング済み画像が作成されるため、オペレータは観客が盛り上がった場面を抽出・選択して、画像を配信部２０７にアップロードできるようにする。選択方法は不図示であるが、画像の一覧から目視で対象画像を選択しても良いし、特定の時間を入力することで該当時間のデータを抽出できるようにしても良く、選択方法が本発明を限定するものではない。

【0027】

逆に撮影指示部１０１がオペレータの手動撮影しか行わない場合は、通常観客が盛り上がった場面で撮影指示を行うことになるので、特に選択せずに全画像をアップロード対象としても構わない。

【0028】

チケット購入部２０６は、利用者がチケットを購入するための仕組みであり、購入時の処理については図８を用いて後述する。利用者は、購入したい日付と座席数を入力し代金を支払うことで、所望した数の座席番号を入手することになる。

【0029】

配信部２０７は、利用者が入力したイベント日付と座席番号をＫｅｙに、該当日付の該当座席番号の画像データ群を利用者に提示する。利用者の入力に関しては、利用者がチケットを見て手動で入力しても良いし、チケットにＱＲコード（登録商標）などを印字して、それをスマートホンで読み取って認識するのでも良く、入力方法が本発明を限定するものではない。

【0030】

また、利用者への提示はスマートホンのアプリケーションでも良いし、ブラウザでアクセスするようなＷｅｂアプリケーションの形でも良く、提示方法についても本発明を限定するものではない。

【0031】

図３に、本発明を適用可能な装置の一例としての画像処理装置２０１の中のＰＣ２０１ａ（パーソナルコンピュータ）の構成の一例を示す。画像処理装置２０１は、複数の電子機器からなるものでもよいし、一台のＰＣからなるものでもよい。

【0032】

図３において、内部バス０９に対してＣＰＵ０１、ＲＡＭ０３、ＲＯＭ０２、ディスプレイ０４、入力装置０６、Ｉ／Ｆ０８が接続されている。内部バス０９に接続される各部は、内部バス０９を介して互いにデータのやりとりを行うことができるようにされている。

【0033】

ＲＡＭ０３は、例えばＲＡＭ（半導体素子を利用した揮発性のメモリなど）からなる。ＣＰＵ０１は、例えばＲＯＭ０２に格納されるプログラムに従い、ＲＡＭ０３をワークメモリとして用いて、ＰＣ２０１ａの各部を制御する。ＲＯＭ０２には、画像データや音声データ、その他のデータ、ＣＰＵ０１が動作するための各種プログラムなどが格納される。ＲＯＭ０２は例えばハードディスク（ＨＤ）やＲＯＭなどで構成される。

【0034】

ディスプレイ０４は、ＣＰＵ０１の制御に基づいて、画像やＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を構成するＧＵＩ画面などを表示する。ＣＰＵ０１は、プログラムに従い表示制御信号を生成し、ディスプレイ０４に表示するための映像信号を生成してディスプレイ０４に出力するようにＰＣ２０１ａの各部を制御する。ディスプレイ０４は出力された映像信号に基づいて映像を表示する。なお、ＰＣ２０１ａ自体が備える構成としてはディスプレイ０４に表示させるための映像信号を出力するためのインターフェースまでとし、ディスプレイ０４は外付けのモニタ（テレビなど）で構成してもよい。

【0035】

入力装置０６は、キーボードなどの文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイス、ボタン、ダイヤル、ジョイスティック、タッチセンサ、タッチパッドなどを含む、ユーザ操作を受け付けるための入力デバイスである。なお、タッチパネルは、ディスプレイ０４に重ね合わせて平面的に構成され、接触された位置に応じた座標情報が出力されるようにした入力デバイスである。

【0036】

図４、５は、本実施形態における、座席ごとのトリミング位置の設定例である。

【0037】

図４は、観客のほぼ正面のカメラから撮影された画像に対してのトリミング位置の設定例である。図４（ａ）のように座席ごとにトリミング位置の矩形を定義して、横方向をＸ軸、縦方向とＹ軸の座標系と定義して、左上の頂点位置４０１と右下の頂点位置４０２の座標を後述する図６にあるデータ構造として記憶する。

【0038】

上記の作業を撮影された画像に含まれている座席ごとに指定することで、図４（ｂ）のように全座席のトリミング位置が指定される。ここでは長方形の矩形として例示をしているが、多角形や楕円での矩形定義など、座標系で表すことのできる矩形であればよく、矩形の形が本発明を限定するものではない。

【0039】

図５は、観客のやや斜め上方のカメラから撮影された画像に対してのトリミング位置の設定であるが、図４の例と同様に座席ごとにトリミング位置の矩形を定義して、Ｘ・Ｙ軸の座標系を定義することで、座席位置が斜めになっていても左上の頂点位置５０１と右下の頂点位置５０２の座標を後述する図６にあるデータ構造として格納することができる。

【0040】

図６は、本発明の実施形態における、各座席のトリミング位置を格納するデータ構造の例である。データ構造６００は、列番号６０１と座席番号６０２とカメラ番号６０３と左上の頂点座標のＸ座標６０４と左上の頂点座標のＹ座標６０５と右下の頂点座標のＸ座標６０６と右下の頂点座標のＹ座標６０７を持つ。

【0041】

データ構造６００では、Ｘ座標とＹ座標を個別のカラムと管理しているが、（Ｘ，Ｙ）のようなリスト情報として１つのカラムで管理しても構わない。また、列番号６０１と座席番号６０２は、図６では数値データとしているが、アルファベットなどの文字列データでも構わない。座標情報である６０４～６０７はピクセル位置を表す数値データが記録されている。

【0042】

なお、本実施形態においては、野球の試合を観戦する観客をユーザとして写真を撮影して、グループできた観客の画像をトリミングすることによって画像を提供することを説明する。しかしながら、本実施形態において説明をする野球の試合の例は一例であり、その他のスポーツの試合であっても、観光地や演劇などの場所であっても適用可能である。また、コンサートを含むエンターテインメントショーの場所であっても良く、エンターテインメントを観賞中の観客をユーザとした場合でも適用可能である。

【0043】

本実施形態におけるチケットの購入処理について図７を用いて説明をする。

【0044】

図７は、ユーザがチケットを購入するアプリやインターネットのサイトにおいて、チケットを購入する際の処理を示したものである。この処理は、ＲＯＭ０２（不揮発性メモリ）に記録されたプログラムをＲＡＭ０３（システムメモリ）に展開してＣＰＵ０１が実行することで実現する。なお、この処理は、カメラ１０や操作部１０５の状態に関わらず、独立して処理が開始可能となるが、カメラ１０に電源が入り、操作部１０５へのユーザ操作を受け付け可能になると開始するものとしてもよい。

【0045】

Ｓ７０１では、ＣＰＵ０１は、ユーザからのチケットの購入枚数の入力を受け付ける。

【0046】

Ｓ７０２では、ＣＰＵ０１は、ユーザから画像購入の意思があるか否かの入力を受け付ける。Ｓ７０２における入力は、ユーザが画像を購入するか否かを直接購入画面において選択をできるようにしてもよいし、チケットと画像購入とがセットになっており、チケットの購入と画像購入の選択が一度にできるようにしてもよい。また、一部の座席は、ユーザが選択をしなくても画像購入がセットになっており、対象となる座席を選択した時点でユーザが画像購入の意思があるもとしてもよい。Ｓ７０３では、ＣＰＵ０１は、Ｓ７０２における入力において画像購入の意思があるか否かを判定する。ユーザに画像購入の意思があると判定した場合は、Ｓ７０４へ進み、そうでない場合には、Ｓ７０６へ進む。

【0047】

Ｓ７０４では、ＣＰＵ０１は、ユーザにより指定された座席を選択する。このとき、ユーザが代表となる座席を１席選択することで、Ｓ７０１において入力した購入枚数分の座席位置を複数パターン提示することでユーザが容易に座席を選択できるようにしてもよい。また、図１０で後述する画像のトリミングの処理においては、ユーザの座席位置の指定に応じてトリミングの範囲を変える。

【0048】

Ｓ７０５では、ＣＰＵ０１は、Ｓ７０４において受け付けた情報に基づいてグループ情報を生成する。グループ情報においては、代表となる座席とＳ７０１において入力された同時購入されたチケットの座席位置と紐づけた情報である。ユーザが単数であっても、Ｓ７０５においてはグループ情報として座席と紐づけて情報を生成する。なお、グループ情報は、同時購入されなかったチケットに記載の情報をアプリやインターネットのサイトを通して入力することで、他の座席を同じグループに追加できるようにしてもよい。ただし、グループとなる座席は縦または横に隣り合っていることが望ましい。これは、トリミングをする際に、離れた座席同士は、撮影するカメラが異なる可能性があるため、１枚のトリミング範囲に収めきれない可能性があるためである。また、トリミングした画像にグループに含まれない他の座席が多く含まれてしまうと、１人１人のサイズが小さくなってしまう。

【0049】

Ｓ７０６では、ＣＰＵ０１は、ユーザにより指定された座席を選択する。

【0050】

次に図８を用いて本実施形態における試合開始前の設定の処理について説明をする。この処理は、試合の開始前に画像処理装置２０１により行われる処理を示している。この処理は、試合の前に画像処理装置２０１の電源オンになり、対象となる試合の準備を始める指示がシステムのオペレータからされる、もしくは試合の３時間や前日といった所定の時間の前になると開始される。この処理は、ＲＯＭ０２（不揮発性メモリ）に記録されたプログラムをＲＡＭ０３（システムメモリ）に展開してＣＰＵ０１が実行することで実現する。

【0051】

Ｓ８０１では、ＣＰＵ０１は、配信部２０７、チケット購入部２０６と接続をする。

【0052】

Ｓ８０２では、ＣＰＵ０１は、チケット購入部２０６から対象となる試合のチケット情報を取得する。チケット情報には、トリミング処理時に必要な同時に購入されたグループのチケット購入枚数・座席位置情報・座席配置についての情報が含まれる。また、より商品性の高い画像を選択するために、座席の種類に関する情報、内野・外野・ＶＩＰにあるのかといったエリアに関する情報、撮影対象となっているエリアの座席か否かの情報、自由席か指定席かの情報、頻繁に試合を観戦しているユーザであるかの情報、ファンクラブに加入しているか否か等の情報も含まれる。

【0053】

Ｓ８０３では、ＣＰＵ０１は、Ｓ８０２において取得した情報をもとにトリミングの範囲を算出する。Ｓ８０２で取得したグループの人数・配置パターンを用いて、後述する図１３・１４で定義されている人数・パターンごとのトリミング位置の算出方法を取得し、トリミング範囲を算出する。ここでのトリミング範囲とは、トリミングする矩形の左上の頂点位置のＸ・Ｙ座標、及び右下の頂点位置のＸ・Ｙ座標として、この２つの頂点に囲まれた長方形の矩形のことを指す。ここでは、２つの頂点で定義される長方形の矩形を用いているが、多角形や楕円での矩形定義など、座標系で表すことのできる矩形であればよく、矩形の形が本発明を限定するものではない。

【0054】

図１３・１４は、本発明の実施形態における、トリミング範囲の算出方法を格納したデータ構造例の図である。図１３は、図４のように観客のほぼ正面から撮影された画像に対する定義の例、図１４は、図５のように観客がやや斜めに撮影された画像に対しての定義の例である。

【0055】

図１３・１４は、グループの人数１３０１と座席配置のパターン１３０２と左上頂点位置のＸ座標計算方法１３０３と左上頂点位置のＹ座標計算方法１３０４と右下頂点位置のＸ座標計算方法１３０５と右下頂点位置のＹ座標計算方法１３０６とグループ外席の情報１３０７を管理する。

【0056】

グループの人数１３０１と座席配置のパターン１３０２は、チケット購入部２０６から事前に取得した購入されたグループ人数・座席配置と一致する。座標計算方法１３０３～１３０６は、図１３・１４の例ではグループ内のいずれかの座席位置のトリミング位置情報を用いているが、具体的なピクセル数の数字や計算式を定義しても構わない。

【0057】

グループ外席の情報１３０７は、座席配置パターンにおいて、矩形の中には入ってしまうがグループ内の座席として購入されていない座席位置の情報が定義されている。

【0058】

Ｓ８０４では、ＣＰＵ０１は、顔データを準備する。顔データは、Ｓ８０２で取得した情報をもとに、頻繁に試合を観戦しているユーザ、すなわち過去顔が多く検出された観客、そしてファンクラブに加入している観客の顔データとを準備しておく。これにより、撮影した画像の中に、顔データ中の顔と一致されたと判定された観客がいた場合に、特定の観客の画像をデータとして紐づけて集め、特定の観客にまとめて提供することができる。また、ファンクラブに加入している観客は、チケット購入時に毎回画像購入の意思を示さなくても、自動的に画像が収集されることで、試合シーズンの終了後にまとめて振り返りをすることができる。観客によっては、試合を観戦する頻度が大きく異なるので、１試合の中で、複数の画像が欲しい観客と、１試合１枚でよいが観戦した全ての試合での画像が欲しい観客とがいる可能性がある。よって、上記のように顔データを準備しておくことで、高い頻度で観戦をする観客が毎回画像購入の意思を示すための作業をしなくても、画像を提供することができる。また、毎回画像購入の意思を示すための作業を忘れてしまっても画像を提供することができる。さらに、座席位置の分からない自由席座ったとしても、特定の観客の画像を集めることができる。なお、Ｓ８０２において取得したチケットの購入時の情報ではなく、観戦チケットの購入とは別途観客が画像を購入するためのプランを設け、プランを選択した場合には、顔データを登録し、観客が観戦した様子を毎回画像として提供できるようにしてもよい。上記のような場合に、顔データを準備しておくことで、試合中にスムーズに観客へ画像を提供することができる。

【0059】

Ｓ８０５では、ＣＰＵ０１は、カメラ１０２～１０５で撮影した画像の撮影時刻が一致するように、各カメラの時計を同じ時刻に設定する。

【0060】

Ｓ８０６では、ＣＰＵ０１は、撮影要因の入力をする。撮影要因とは、１０秒や２０秒といったインターバル撮影の期間、もしくは観客の歓声が所定以上になったことに応じてといった検出に基づくものでもよい。また、撮影された試合の様子を分析したり、試合データを分析する制御部を用意しておき、試合の点数や、試合の進み具合、選手の位置に応じて、インターバルの間隔を短くしたり、動画の撮影に切り替えるようにしてもよい。また、休憩時間には、インターバル撮影を停止し、休憩時間の応援合戦やクイズといったイベントが発生する時間にはインターバル撮影を開始してもよい。なお、手動による撮影の指示を組み合わせてもよいことは言うまでもない。

【0061】

Ｓ８０７では、ＣＰＵ０１は、システムテストとして、カメラを実際に起動して撮影とトリミングに処理を行う。撮影された画像に基づいて、その日の明るさや光の入り具合に応じた撮影条件の設定をしたり、撮影した画像を座席に紐づく座標に基づいてトリミングした際に、対象となる座席を切り取ることができるのかを確認してもよい。なお、座席側に指標となるポイントとなる被写体を置いておいて、カメラが撮影した画像の中の被写体が予め定まっている座標にあるか否か、フォーカス位置が問題ないか、などを確認してもよい。また、このシステムはイベントごとに稼働させるため、以前のイベントのデータが残っている場合もあるので、カメラのデータの削除・システム内のデータの整理・削除やバックアップをこのタイミングで行っても良い。

【0062】

Ｓ８０８では、ＣＰＵ０１は、撮影条件をＳ８０７のシステムテストに基づいて設定する。

【0063】

次に図９の（ａ）から（ｃ）を用いて試合開始後の処理を示している。図９（ａ）は、画像処理装置２０１の処理であり、図９（ｂ）は撮影に関する処理であり、図９（ｃ）は、画像をトリミングし、配信する処理である。各処理は試合が開始される、もしくは試合の開始前の撮影を開始する前に開始される。この処理は、ＲＯＭ０２（不揮発性メモリ）に記録されたプログラムをＲＡＭ０３（システムメモリ）に展開してＣＰＵ０１が実行することで実現する。

【0064】

Ｓ９０１では、ＣＰＵ０１は、途中チケット情報を取得する。途中チケット情報は、試合の開始後の購入された、もしくは、図９のＳ８０２の処理の後に購入されたチケットに関する情報である。この情報は、チケット購入部２０６より取得してもよいし、チケット購入部２０６側から定期的、もしくは更新がある度に画像処理装置２０１へ通知されるようにしてもよい。

【0065】

Ｓ９０２では、ＣＰＵ０１は、カメラｃ＝１に対応するカメラに関する情報を取得する。Ｓ９０２では、カメラｃ＝１の撮影範囲と対象となる座席に関する情報を取得する。

【0066】

Ｓ９０３では、ＣＰＵ０１は、現在処理をしようとしているカメラｃがカメラの全体数Ｋよりも大きいか否かを判定し、大きい場合には、全てのカメラに対する処理が終了したとして、Ｓ９０７へ進む。そうでない場合には、Ｓ９０４へ進む。

【0067】

Ｓ９０４では、ＣＰＵ０１は、対象となるカメラｃの位置から撮影する座席の範囲でのトリミング情報を取得する。

【0068】

Ｓ９０５では、ＣＰＵ０１は、対象となるカメラｃの位置から撮影をする座席の範囲での撮影要因を取得する。例えば、チームＡとチームＢとが対戦している場合には攻めと守りのタイミングとで撮影のインターバル期間を変えたほうがよい場合がある。また、座席の種類によっては、頻度を高く撮影をしたほうがよい場合もある。よって、カメラの撮影範囲に含まれる座席に応じて、撮影要因を取得することによって、観客に提供しない可能性の高い画像を多く撮影することなく、撮影チャンスを逃さないようにすることができる。なお、Ｓ９０５の撮影要因は、全てのカメラで同じでもよい。

【0069】

新たにチケットが購入されたり、新たに画像購入の意思が観客から示された、すなわち、新たなトリミンググループが発生した場合には、Ｓ９０４、Ｓ９０５において図８のＳ８０３，Ｓ８０４の処理を行う。

【0070】

Ｓ９０６では、ＣＰＵ０１は、Ｓ９０２と同様にカメラｃ＝ｃ＋１にして、次のカメラに関する情報を取得する。

【0071】

Ｓ９０７では、ＣＰＵ０１は、所定時間が経過したかを判定する。所定時間は、Ｓ９０７の判定を図９の処理の開始後初めて行う場合には、Ｓ９０１からの時間、２回目以降の場合は前回Ｓ９０７の判定においてＹｅｓと判定してからの時間で計時をする。Ｓ９０７は所定時間おきに途中チケット情報を取得するためのものである。Ｓ９０７においてＹｅｓと判定された場合は、Ｓ９０１へ進み、そうでない場合は、Ｓ９０８へ進む。

【0072】

Ｓ９０８では、ＣＰＵ０１は、Ｓ９０５で撮影をされた撮影要因があったか否かを判定する。Ｓ９０８においてＹｅｓと判定された場合は、Ｓ９０９へ進み、そうでない場合は、Ｓ９０７へ進む。

【0073】

Ｓ９０９では、ＣＰＵ０１は、カメラ側へ撮影をする指示を通知する。

【0074】

Ｓ９１０では、ＣＰＵ０１は、トリミング情報をトリミング部２０２に通知をする。トリミング情報、撮影要因に関する情報は所定時間ごとにアップデートされるので、途中でチケットを購入した観客も、試合の途中からトリミング済み画像を得ることができるようになる。

【0075】

Ｓ９１１では、ＣＰＵ０１は、処理を終了するか、すなわち試合が終了し、撮影を終了するか否かを判定する。終了する場合にはＳ９１２へ進み、そうでない場合には、Ｓ９０１へ進む。

【0076】

Ｓ９１２では、ＣＰＵ０１は、カメラへ電源をＯＦＦすることを通知する。

【0077】

以上説明したように、図９においては、トリミング情報をトリミング部２０２に撮影の指示とほぼ同時に送るので、撮影後に素早く登録されたトリミング処理を実施することができる。トリミング部２０２では、カメラ側からストレージ２０４へ画像が送られるときには、トリミングすべきグループについて把握し、トリミング範囲を算出できているので、素早くトリミング処理をし、観客が画像を確認できるようになる。

【0078】

次に、図９（ｂ）の撮影に関する処理について説明をする。図９（ｂ）の処理は各カメラにおいて行われる処理である。

【0079】

Ｓ９３０では、ＣＰＵ０１は、カメラ側が撮影条件を取得するようにする。

【0080】

Ｓ９３１では、カメラ側で、撮影指示がされたか否かを判定し、撮影指示がされた場合には、Ｓ９３２へ進み、そうでない場合には、撮影指示がされるのを待つ。

【0081】

Ｓ９３２では、カメラ側で、設定された撮影条件での撮影を行う。

【0082】

Ｓ９３３では、ＣＰＵ０１は、カメラから画像転送受信部２０１ｂへ画像を転送するように制御するし、転送された画像データはストレージ２０４に格納される。もしくは、カメラにおいて撮影された画像は逐次ストレージ２０４へ転送する。

【0083】

Ｓ９３４では、ＣＰＵ０１は、図９（ｂ）の処理を終了するか否かの判定をする。Ｓ９３４の判定は、図９（ａ）のＳ９１２においてカメラの電源のオフをする指示がきた場合にＹｅｓとなる。Ｓ９３４において図９（ｂ）の処理を終了すると判定した場合は、図９（ｂ）の処理を終了し、そうでない場合は、Ｓ９３１へ進む。

【0084】

次に図９（ｃ）の画像をトリミングし、配信する処理に関する説明をする。

【0085】

Ｓ９５１では、ＣＰＵ０１は、画像を取得する指示がされたか否かを判定する。画像を取得する指示とは、野球であればホームランがあった時刻や、ファインプレーのあった時刻などのイベント時刻において、図８のＳ８０５において設定された時計の時刻をもとに、イベント時刻の前後に撮影された画像を取得する指示である。画像の取得指示は、イベント時刻の発生に応じて行うものとする。なお、イベント時刻でなくても例えば、試合の分析を行い、イベントが発生したことに応じて画像の撮影指示と画像の取得指示とを同時にＣＰＵ０１が行ってもよい。

【0086】

Ｓ９５２では、ＣＰＵ０１は、対象画像をストレージ２０４から取得する。

【0087】

Ｓ９５３では、トリミング部２０２がトリミング情報を取得する。

【0088】

Ｓ９５４以降の処理ではトリミングの処理を開始する。

【0089】

Ｓ９５４では、トリミング部２０２がｎ＝１の座席の情報を取得する。そして、現在トリミングをしようとしている画像を撮影したカメラの撮影範囲における座席数をｍとする。本実施形態においては座席の番号に関して簡単のためにｎ＝１からｍまでとしているが、これに限らず、１台のカメラが撮影しており、かつトリミング対象となっている座席のすべてがカバーされれば、実際に球場で使用されている座席と紐づけてもよい。複数のカメラで観客の席をカバーするためには、他のカメラとの撮影の範囲と撮影範囲が被ることがある。２台のカメラから撮影をされている観客であっても、いずれか一方である１台のカメラで撮影された画像からトリミングされた画像が提供される。よって、カメラの撮影範囲とトリミング範囲とは異なることがある。Ｓ９５４では、全てのトリミング範囲の座席数をｍとして取得する。トリミング範囲は、試合中に可変としてもよいし、予め球場側で定めておいてもよい。

【0090】

Ｓ９５５では、ＣＰＵ０１は、トリミングを行うエリアにある座席か否かを判定する。球場では、ネットやポール、屋根等によりカメラの死角になってしまったり、撮影が禁止されているエリアがある可能性がある。また、自由席など観客の位置が分からないエリアにおいては、そもそも座席の位置に対応するトリミングを行わない。よって、Ｓ９５５の判定はＮｏとする。なお、自由席であっても後述するように顔検出によるトリミングやより広い範囲のトリミングは行うことができる。Ｓ９５５においてＹｅｓと判定された場合は、Ｓ９５６へ進み、そうでない場合はＳ９６３へ進む。なお、チケットの購入時や、座席付近いにおいて画像購入ができないエリアであることを観客に示すようにしてもよい。

【0091】

Ｓ９５６では、ＣＰＵ０１は、現在トリミング対象か否かを判定している座席ｎがトリミング範囲にある座席数ｍより小さいか否かを判定する。すなわち、トリミング範囲全ての座席に対して、トリミングをするか否かの判定がし終わっていないかを確認する。Ｓ９５６の判定がＹｅｓである場合には、Ｓ９５７へ進み、そうでない場合は、Ｓ９６５へ進む。

【0092】

Ｓ９５７では、ＣＰＵ０１は、座席ｎがトリミング対象の座席か否かを判定する。トリミング対象の座席か否かは、図７において観客が画像購入の意思を示したか否かにより決まる。すなわち、Ｓ９５５の判定は、トリミンググループに含まれる座席である場合にはＹｅｓとなり、そうでない場合にはＮｏとなる。

【0093】

Ｓ９５８では、ＣＰＵ０１は、Ｓ９５２で取得した画像からトリミングを行う元の画像であるトリミング画像を選択する。トリミング画像の選択は、現在対象となっている座席ｎのトリミンググループの観客の様子に応じて、最も表情が良いものや、前後の画像と比較して動きの大きなものを選択するようにしてもよい。また、トリミンググループごとで選択する画像を変えず、マニュアルで画像を選択したり、トリミング範囲の観客の動きを数値化し、一番大きな動きがあると思われる画像を選択してもよい。

【0094】

Ｓ９５９では、ＣＰＵ０１は、トリミング処理を実行する。トリミング処理は、図１０を用いて後述する。

【0095】

Ｓ９６０では、ＣＰＵ０１は、座席ｎ＝ｎ＋１とする。なお、すでにトリミング処理が実施済みのトリミンググループに含まれている座席ｎであって場合には、さらにｎ＋１として、まだＳ９５７の判定をしていない座席を探していく。

【0096】

Ｓ９６１、Ｓ９６２では、座席ｎの観客のグループトリミングに入っていない場合の処理について説明をする。本実施形態においては、試合の後に観客が画像を得られるように座席番号と紐づけてエリアでのトリミングを行う。すなわち、グループトリミングのように同時購入した観客が入り、その他の観客が入らないようにトリミング範囲を決めるのではなく、３０人や５０人といったように予め決められた人数でのトリミングを行う。これにより、トリミングにかかる時間とデータ量を削減することができ、グループトリミングの対象となっている観客には素早く画像の提供ができるようにしつつ、そうでない観客にも後から画像を提供できるようにしている。

【0097】

Ｓ９６１では、ＣＰＵ０１は、Ｓ９５８と同様にトリミング画像を選択する。エリアトリミングの場合には、各座席の観客に合わせてトリミング画像を保存しておかないので、座席ｎの観客に応じたトリミング画像の選択は行わない。エリアトリミングの場合には、手動で画像を選択してもよいし、トリミング範囲にいる観客の動きを数値化して最も動きの大きな数値の画像を選択してもよい。もしくは、予め顔データが準備されていた観客の表情が良い、もしくは動きの大きな画像を選択するようにしてもよい。このように、グループトリミングの対象となっていない観客であっても、画像購入をする可能性の高い観客の表情が良い、もしくは大きく動いている画像を選択することで、将来、画像を購入したより多くの観客の満足度を満たすことができる。それぞれの観客の表情の良い画像を保存しておくと、データ量が多くなりコストアップにつながり、またデータの取り出しも時間を要す。購入の可能性の高い、高い頻度で観戦のする観客を優先的にして画像を選択することで、よりコストが低くさらに素早く画像を提供することができるようになる。なお、顔検出された観客には、例えば１０試合や５試合といった所定の数の試合ごとに、対象の観客の画像をまとめて、観客に通知をしてもよいし、次の試合の観戦時に観客に画像を通知し、購入を促してもよい。さらに、前回の試合で撮影された画像を、次の試合のチケットの購入時に観客に提示することで、どのような画像が撮影されるのかを観客が把握し、画像購入をするか否かの判断をしやすくしてもよい。

【0098】

Ｓ９６２では、ＣＰＵ０１は、エリアトリミングをする。エリアトリミングは上述したように、所定の人数で区切った画像をトリミングする。既に他の座席ｎに対する処理においてエリアトリミングされた画像に含まれている座席ｎであった場合には、改めてエリアトリミングをせず、画像のデータ量の削減をする。

【0099】

Ｓ９６３、Ｓ９６４では、Ｓ９６１、Ｓ９６２と同様の処理を実行する。トリミング対象の座席でない自由席であれば、顔検出に基づいた処理を行い、トリミング対象座席でグループトリミング範囲の観客でない場合には、エリアトリミングをしないようにしてもよい。また、一部の熱狂的なファンが固まっていたり、団体の座っている座席においては、エリアトリミングの範囲を広く設けてもよい。例えば、同じ色の服を着ているユーザをトリミング範囲としてもよい。これにより、応援しているチームのユニフォームを着ている団体を一枚に収めることができる。

【0100】

Ｓ９６５では、ＣＰＵ０１は、トリミングした画像の中に、顔データがあったか否かを判定する。顔データがあった場合には、Ｓ９６６へ進み、そうでない場合は、Ｓ９６７へ進む。

【0101】

Ｓ９６６では、ＣＰＵ０１は、各観客のＩＤと画像とを結びつけ、観客が観戦中の試合における画像フラグをＯＮにする。画像フラグがＯＮであれば、観客に対して、いつの試合に撮影された画像があるのかを提示することができる。

【0102】

Ｓ９６７では、ＣＰＵ０１は、トリミングをした画像を配信部２０７へアップロードし、グループトリミングの対象となっている観客が画像を閲覧可能にする。なお、グループトリミングの対象となっている観客でなくても、トリミングした画像を提示するようにしてもよい。このとき、グループトリミングの対象外となっている観客にはウォーターマークでサンプルなどの文字をいれる。なお、アップロードしなかった画像データはストレージ２０４から削除、もしくは画質を落として記録することで、画像の容量を減らし、コストの削減へとつなげる。ただし、試合後、所定期間はＳ９５８、９６１、９６３で選択した画像自体と保存しておいてもよいし、削除をする前に各観客に通知をしてもよい。

【0103】

図１０は、本実施形態における、トリミング処理の例を示すフローチャート図である。この処理は、ＲＯＭ０２（不揮発性メモリ）に記録されたプログラムをＲＡＭ０３（システムメモリ）に展開してＣＰＵ０１が実行することで実現する。

【0104】

ＣＰＵ０１は、チケット購入部２０６から事前に取得した購入されたグループ人数・座席番号・座席配置を読み出す（Ｓ１００１）。

【0105】

図１１は、本発明の実施形態における、グループの人数に応じた座席配置の例である。図１１（ａ）は４人のグループの座席配置例であり、パターン（１）では４人が横並びになっており、パターン（２）では２人ずつ前後に並んでいる。あくまでもパターンは一例であり、パターンの形と人数の組合せが、本発明を限定するものではない。

【0106】

同様に、図１１（ｂ）は５人のグループの座席配置の例、図１１（ｃ）は６人のグループの座席配置の例である。

【0107】

図１２は、本発明の実施形態における、座席配置における座席の関係性を示した図である。グループ内で左下の座席位置を基準として、水平方向の座席位置を「番」、垂直方向の座席位置を「列」で表現し、水平方向右側に向かって「番」の数字がインクリメントされ、垂直方向上側に向かって「列」の番号がインクリメントされる。

【0108】

図１２は図１１（ｂ）のパターン（２）における座席配置の具体的な例を示したものである。Ｘ＋２番・Ｙ列にはグループ内の利用者はいないが、矩形をトリミングする際のデータとして必要であるため、後述する図１３・１４のデータ構造においてグループ外席として定義する。

【0109】

図１０の説明に戻る。

【0110】

ＣＰＵ０１は、トリミング範囲、及びグループ外席情報を取得する（Ｓ１００２）。なお、事前にトリミング範囲を算出せずにＳ１００１においてトリミング範囲の算出を行ってもよい。

【0111】

ＣＰＵ０１は、Ｓ１００２で取得したグループ情報にグループ外席の情報が存在していた場合（Ｓ１００３でＹＥＳ）、グループ外席に定義されている座席位置のトリミング範囲を灰色の単色で塗り潰す（Ｓ１００４）。グループ外席の情報が存在していない場合（Ｓ１００３でＮＯ）には、Ｓ１００４の処理はスキップする。

【0112】

Ｓ１００４において、グループ外の座席のトリミング位置の全範囲を塗りつぶしてしまうと、一部上下隣のグループ内の座席のトリミング位置と重なっていることがあるため、若干トリミング位置よりも内側を塗り潰すことが望ましい。これは、グループ外の観客が写らないようにするための処理であるが、塗り潰しの方法については本発名を限定するものではなく、また、特に肖像権の問題などがなく、利用者の意思としてグループ外の人物が写っていても問題ない場合には、Ｓ１００４の処理は必要がないケースもある。

【0113】

ＣＰＵ０１は、Ｓ１００２で取得した１３０３～１３０６のトリミング位置の計算方法に従い、トリミング位置を確定させる（Ｓ１００５）。

【0114】

図１５は、本実施形態における、トリミング位置の計算例を示した図である。図１５（ａ）は、図４のように観客のほぼ正面から撮影された画像に対する計算方法の例、図１５（ｂ）は、図５のように観客がやや斜めに撮影された画像に対しての計算方法の例である。図１５（ａ）では単純に左上座席の左上頂点と、右下座席の右下頂点をそれぞれ全体のトリミング位置の頂点として利用しているが、図１５（ｂ）では上下列が若干ずれているため、
左上頂点
Ｘ座標＝左下座席の左上頂点のＸ座標
Ｙ座標＝左上座席の左上頂点のＹ座標
右下頂点
Ｘ座標＝右上座席の右下頂点のＸ座標
Ｙ座標＝右下座席の右下頂点のＹ座標
が定義されており、この計算方法を用いて左上頂点・右下頂点の座標位置を求める。

【0115】

図１０の説明に戻る。

【0116】

ＣＰＵ０１は、Ｓ１００５で確定したトリミング位置に従い、カメラで撮影した全体画像から該当人数・座席配置に従ったトリミング位置で切り出したトリミング済み画像を生成して、ストレージ２０５に撮影日付・座席番号情報と共に格納する（Ｓ１００６）。

【0117】

以上、説明した実施形態によれば、１枚の画像の中から複数のトリミング範囲を切り出し、素早く画像を各ユーザに提供することができるようになる。

【0118】

なお、上述した実施形態において以下のようにシステムを運用することで、観客がより容易に画像の取得をできるようにしてもよい。
・配信サーバへの閲覧要求を、チケットのＱＲコードの読み取りにする。
・事前にグループ情報を取得するようにしているが、処理を行う度に取得してもよい。この場合は、チケット購入システムも常にグループ情報を作り直す必要があり、それを都度トリミング部２０２から取得するので、システム全体としては処理が増えるが、例えば、野球の場合当日券の売り上げの割合が多く、試合開始後にグループ情報が多く作成される場合、などには有効である。

【0119】

次に、事前に観客が画像の購入意思を示さなかったが、試合の終了後に画像を購入しようとした場合について図１６、図１７を用いて説明をする。

【0120】

図１６は、本実施形態における、画像提供システムのシステム全体構成図の別実施例である。画像処理装置２０１は、撮影指示部１０１と、カメラ１０２～１０５、画像転送受信部２０１ｂと、選択・アップロード部２０３と、ストレージ２０４を持つ。

【0121】

図１６において、各処理部１０１・２０１ｂ・２０３・２０４は１つの画像処理装置２０１の中に記載しているが、物理的に別の処理装置であっても構わず、処理部の構成が本発明を限定するものではない。同様に、配信部２０７とトリミング部２０２も物理的に別の処理装置であってもよい。

【0122】

撮影処理部１０１・カメラ１０２～１０５・カメラ画像転送受信部２０１ｂ・チケット購入部２０６については、図２の説明と同様であるため割愛する。

【0123】

選択・アップロード部２０３は、ストレージ２０４に撮影画像データが格納されたこととトリガーに、撮影画像データをイベントの日時情報と座席ごとのトリミング位置情報と共に配信部２０７にアップロードする。

【0124】

ここでの撮影画像データはトリミングされていない高解像のデータであるため、インターバル撮影などで撮影枚数が多くなった場合や、カメラの台数が多くなった場合には、大量のデータが配信部２０７にアップロードされることになり、後からグループトリミングをしようとした際には、より大量のデータをシステムが保持しなければならない。

【0125】

なお、ここでは座席ごとのトリミング位置情報を画像処理装置２０１から配信部２０７にアップロードしているが、配信部２０７とトリミング部２０２で情報を持っても良い。ただし、トリミング位置情報はあくまでもカメラ１０２～１０５で撮影される画像に対しての位置情報となるので、画像処理装置２０１側におけるカメラ１０２～１０５の取り付け位置や画角を変更した場合に都度更新が必要となるので、画像処理装置２０１と配信部２０７、トリミング部２０２のシステムがより連携して対応する必要がある。

【0126】

配信部２０７は、利用者が入力したイベント日付と座席番号をＫｅｙに、トリミング部２０２に選択・アップロード部から取得したサムネイル位置情報と座席番号を送信し、トリミング処理を指示して、取得したトリミング済み画像を利用者に提示する。

【0127】

利用者の入力に関しては、図２同様に利用者がチケットを見て手動で入力しても良いし、チケットや座席にＱＲコードなどを印字して、それをスマートホンで読み取って認識するのでも、またチケット情報が分からない場合には顔検出でもよく、入力方法は上述の方法に限られない。

【0128】

また、利用者への提示はスマートホンのアプリケーションでも良いし、ブラウザでアクセスするようなＷｅｂアプリケーションの形でも良く、提示方法についても本発明を限定するものではない。

【0129】

トリミング部２０２は、処理自体は図２と同様であるが、利用者が購入を希望する都度にトリミング済み画像を生成することになり、利用者がトリミング済み画像を取得するまでの時間にそのトリミング時間が含まれてしまうため、画像の提供を素早く行うことができない。また、素早く行うためにはより画像処理を高速に実施できる環境が必要となる。

【0130】

次に、図１７においては、画像データをストレージ２０４に保存している場合について説明をする。図１７の処理では、図１６とは異なり、配信部２０７に大量の画像データが送信されることはないが、利用者からの画像購入のトリガーを受けてから画像処理装置２０１に対象カメラで撮影した画像を要求してアップロードしてもらうため、図１６よりも画像取得分だけ時間が長くかかってしまうので、利用者がトリミング済み画像データを取得するのにさらに時間がかかってしまう。

【0131】

図１７は、図１６と構成は同じである。

【0132】

本実施例は、利用者がチケットを購入したことを前提に、次は画像購入の指示を配信部２０７に行ったところから処理がスタートする（ステップ１）。

【0133】

配信部２０７は、対象カメラの画像を画像処理装置２０１へ要求し（ステップ２）、画像処理装置２０１内においてストレージ２０４へと画像が要求される（ステップ３）。その後、選択・アップロード部２０３が画像データを配信部２０７へ送信（ステップ４）する。このとき、画像データには日付情報（撮影日時）、座席ごとのトリミング位置情報とトリミング前の画像データとが含まれるため、データ量が大きくなる。配信部２０７からトリミング部２０２へとトリミング指示がされる（ステップ５）と、トリミング部２０２がトリミングをし、トリミング済みの画像データが配信部２０７へと配信される（ステップ６）。その後、配信部から画像を購入した観客へとトリミング済みの画像が配信される（ステップ７）。

【0134】

このように、図１７の方法では、事前に観客が画像購入の意思を示していなくても、トリミンググループを対象としたトリミングをした画像を観客に提供することができる。しかし、システム内、装置内におけるやり取りが多く、事前に画像の購入意思のある観客よりも画像の提供にまでに時間を要する可能性がある。

【0135】

なお、観客に画像を提供する際には、座席情報も紐づけて観客に提供することで、観客がソーシャルネットワークサイト（ＳＮＳ）に画像をアップロードした際に、画像をみた人がどの位置の座席であればよい画像が撮られるのかを認識することができる。

【0136】

さらに、座席の位置に応じて明るさに関する画像処理を行い、暗い部分や明るい部分に対して適正な画像を提供するようにすることで、複数座席を含む広い範囲の観客を同じ画角範囲に含めて撮影をしてもより良い画像を提供することが可能になる。同じ画角内において明るさが所定以上変わるような場合には、ＲＡＷ画像を取得し、後で画像の加工をしやすくしてもよい。

【0137】

なお、図２の画像処理装置２０１は１つの装置でなくても、複数の装置に分かれていてもよい。

【0138】

なお、図７においてＳ７０１のチケット購入の直後に、Ｓ７０２において画像購入意思を入力することを説明したが、試合の開始前や試合中にチケットのコードや番号などのチケット情報を読み込んでＳ７０２の画像購入の意思を受け付けるようにしてもよい。このとき、Ｓ７０５において生成されるグループ情報は、例えば、試合の開始後など、いったん撮影が開始された後に更新されることもできる。これにより、グループの人数が当日や試合中に変更した場合であっても、グループ情報を更新することで全てのメンバーをおさめたトリミングを行うことができるようになる。また、チケットを購入する前に撮影の予約をできるようにしてもよい。この場合には、ユーザはチケットを購入し座席が決定した際に、チケット情報を読み込めば、読み込んだ座席に基づいて撮影が行われることになる。

【0139】

図１１で示したグループの場合の座席配置のパターンは、ＣＰＵ０１が判定を行わなくても、ユーザのアプリ側でパターンを判定してもよい。

【0140】

＜その他の実施形態＞
本発明は、上述した各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【0141】

上述の各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明は、その技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

【0142】

なお、画像処理装置２０１が行うものとして説明した上述の各種制御は１つのハードウェアが行ってもよいし、複数のハードウェア（例えば、複数のプロセッサや回路）が処理を分担することで、装置全体の制御を行ってもよい。

【0143】

また、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。さらに、上述した各実施形態は本発明の一実施形態を示すものにすぎず、各実施形態を適宜組み合わせることも可能である。

【0144】

また、上述した実施形態においては、本発明を画像処理装置２０１に適用した場合を例にして説明したが、これはこの例に限定されず、画像に関する制御が可能な電子機器もしくは複数の電子機器からなるシステムであれば適用可能である。すなわち、本発明はパーソナルコンピュータやＰＤＡ、携帯電話端末や携帯型の画像ビューワ、ディスプレイを備えるプリンタ装置、デジタルフォトフレーム、音楽プレーヤー、ゲーム機、電子ブックリーダーなどに適用可能である。また、ＡＩ（人口知能）と結び付けて制御を行うことも適用可能であることは言うまでもない。

【0145】

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】