JP2006345095A - 撮像装置および情報処理方法 - Google Patents

Abstract

【課題】 コネクション型の通信とコネクションレス型の通信とを実装した撮像装置と表示装置と備えるシステムにおいて、表示装置からの指示に基づいて撮像装置にて撮影された画像を表示装置にて表示するにあたり、迅速な表示を実現する。
【解決手段】 画像を表示する表示装置と通信可能な撮像装置における情報処理方法であって、動画像を撮影中に、前記表示装置より、静止画像を撮像する旨の指示を受け付ける工程（ステップＳ３０２）と、前記指示に基づいて、静止画像を撮影する工程と、前記撮影された撮影画像を縮小し、コネクションレス型の通信により前記表示装置に送信する第１の送信工程（ステップＳ３０７、Ｓ３０８）と、前記撮影された前記静止画像を、コネクション型の通信により前記表示装置に送信する第２の送信工程（ステップＳ３０７、Ｓ３０９）とを備える。
【選択図】 図３

Description

本発明は、互いに通信機能を具備する撮像装置と表示装置との間で、情報を送受信する場合の情報処理技術に関するものである。

近年、光ファイバー、ＡＤＳＬ等のブロードバンド環境が普及するにつれ、動画像や音声等の種々のメディアデータを、ストリーム系の伝送方式（ストリーミングを実現するための伝送方式。なお、ストリーミングとは、インターネット上で音声や動画像などのメディアデータを受信しながらリアルタイムに再生する技術をいう）を用いて伝送するサービスが増えてきている。例えば、インターネット電話、ビデオ会議、映像配信などはその典型的な例である。

一般に、ストリーム系の伝送方式においては、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ）１８８９、１８９０で規定されているＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ)やＲＴＣＰ(ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）等のプロトコルが用いられる。

また、データの通信方式としては、一般にコネクション型とコネクションレス型という２つの通信方式が用いられる。コネクション型とは、最初に通信のコネクションを張り、エラーが発生した場合にデータの再送を行う通信方式であり、データロスのない通信を実現することができる。ＴＣＰ等の通信がこれに相当する。

一方、コネクションレス型とは、コネクションを張らずに行う、データヘッダ処理の少ない通信方式であり、迅速なデータの送受信を実現することができる。特に、動画像や音声等の送受信においてリアルタイム性が要求される場合に使われることが多く、ＵＤＰ等の通信がこれに相当する。

そして、従来より、このようなコネクション型の通信方式とコネクションレス型の通信方式の両方を実装した装置が知られ、当該装置について種々の提案がなされている（例えば、特許文献１参照）。
特開２００１−２３７８８４号公報

ここで、コネクション型の通信方式とコネクションレス型の通信方式の両方を実装した装置からなるシステムとして、例えばかかる通信機能を具備する撮像装置と表示装置とを接続し、撮像装置にて撮影された画像を送信し表示装置にて表示するシステムが知られている。このようなシステムでは、撮像装置で撮像された画像はファインダ画像としてリアルタイムに表示装置にて表示され（コネクションレス型の通信）、ユーザは表示装置にて、当該ファインダ画像を見ながらシャッターを押圧することで、所定の静止画像を取得することができる（コネクション型の通信）。

また、かかるシステムでは、撮影された静止画像をユーザが確認できるよう、サムネール画像を表示させることも可能である。そして、従来、サムネール画像の表示は、撮影された静止画像をコネクション型の通信により表示装置に送信した後に、撮影された静止画像についての縮小処理を行いサムネール画像を生成し、当該生成したサムネール画像をコネクション型の通信で送信することで、実現していた。このため、シャッターを押圧してから、サムネール画像の表示を行うまでに時間がかかるといった問題があった。

また、シャッターのＯＮ／ＯＦＦに限らず、撮像装置の制御を表示装置からの指示に基づいて行い、撮像装置にて取得された画像を表示装置にて表示させるような場合、通常、コネクション型の通信でコマンド／レスポンスのやりとりを行うが、動画像の撮影等で、コネクション型の通信が使用されているような場合には、レスポンスの送信がなかなかできず、応答が遅いといった問題があった。

さらに、上述のようなシステムにおいて、ファインダ機能を実現すべくストリーミング処理を行うにあたり、コネクションレス型のＲＴＰを使った場合、ＲＴＰのヘッダ処理に時間がかかり、遅延が発生するといった問題があった。

本発明は、上記課題に鑑みてなされたものであり、コネクション型の通信方式とコネクションレス型の通信方式とを実装した撮像装置と表示装置とを備えるシステムにおいて、情報を送受信する場合の処理の高速化を図ることを目的とする。

より具体的には、表示装置からの指示に基づいて撮像装置にて処理が実行された結果得られた処理結果を表示装置にて表示するにあたり、迅速な表示を実現することを目的とする。また、該システムにおいてコネクションレス型の通信を実現するにあたり、処理の高速化を図ることを目的とする。

上記の目的を達成するために本発明に係る撮像装置は以下のような構成を備える。即ち、
画像を表示する表示装置と通信可能な撮像装置であって、
動画像を撮影中に、前記表示装置より、静止画像を撮影する旨の指示を受け付ける受付手段と、
前記受付手段において受け付けた指示に基づいて、静止画像を撮影する撮像手段と、
前記撮像手段において撮影された静止画像を縮小し、コネクションレス型の通信により前記表示装置に送信する第１の送信手段と、
前記撮像手段において撮影された前記静止画像を、コネクション型の通信により前記表示装置に送信する第２の送信手段とを備える。

本発明によれば、コネクション型の通信方式とコネクションレス型の通信方式とを実装した撮像装置と表示装置とを備えるシステムにおいて、情報を送受信する場合の処理の高速化を図ることが可能となる。

より具体的には、表示装置からの指示に基づいて撮像装置にて処理が実行された結果得られた処理結果を表示装置にて表示するにあたり、迅速な表示を実現することが可能となる。また、該システムにおいてコネクションレス型の通信を実現するにあたり、処理の高速化が可能となる。

以下、必要に応じて添付図面を参照しながら本発明の各実施形態を詳細に説明する。

［第１の実施形態］
＜撮像装置の構成＞
図１Ａは、本発明の第１の実施形態にかかる撮像装置の構成を示す図である。同図に示すように、撮像装置１０１は、撮像部１０２、マルチエンコーダ１０３、通信制御ＣＰＵ１０４、通信モジュール１０５、ＲＯＭ／ＲＡＭ１０６、システムバス１０７を備える。

撮像部１０２は、画像を撮影し該画像を出力する機能を有する。マルチエンコーダ１０３は、撮像部１０２から出力された画像を、ＪＰＥＧ、ＭＰＥＧ４等の圧縮形式で圧縮するエンコーダであり、同時に複数の処理が行うことができる（本実施形態においては、ＲｅｃＶｉｅｗ画像、撮影画像、ファインダ用の画像を生成することができる）。通信制御ＣＰＵ１０４は、マイクロプロセッサ等で構成され、撮像装置１０１全体の制御及び通信制御を行い、後述のＲＯＭ／ＲＡＭ１０６に格納された制御プログラムに従って動作する。

通信モジュール１０５は、無線ＬＡＮ、或いは、有線ＬＡＮ或いは公衆回線用の通信モジュールであり、受信側の端末（本実施形態では表示装置）との接続、ネゴシエーション、パケットの送信を行う。また、コネクションレス型の通信方式とコネクション型の通信方式の両方の通信方式が実装されている。

ＲＯＭ／ＲＡＭ１０６は、制御プログラムデータ等を格納する格納機能を有する。また、通信制御ＣＰＵ１０４のワークエリアとしての機能も備えており、種々の制御データはＲＯＭ／ＲＡＭ１０６に一時保存される。

＜表示装置の構成＞
図１Ｂは、本発明の第１の実施形態にかかる撮像装置と通信可能な表示装置の構成を示す図である。同図に示すように、表示装置１１０は、通信モジュール１１１、１次ＲＸバッファ１１２、通信振分け部１１３、ストリーム振分け部１１４、負荷配分部１１５、デコーダ部１１６、１１７、１１８、１１９、２次ＲＸバッファ１２０、アプリケーションＣＰＵ１２１、デコード能力モニタ１２２、フレームバッファ１２３、表示部１２４を備える。

通信モジュール１１１は、無線ＬＡＮ、或いは、有線ＬＡＮ或いは公衆回線用の通信モジュールであり、送信側の端末（撮像装置）との接続、ネゴシエーション、送信されたパケットの受信を行う。１次ＲＸバッファ１２２は、通信モジュール１１１で受信したパケットを一時蓄積する。通信振分け部１１３は、受信したパケットの各レイヤのヘッダの内容を判断して、当該受信したパケットを、後述のストリーム振分け部１１４、またはアプリケーションＣＰＵ１２１に処理させるべく、２次ＲＸバッファ１２０に渡す。

ストリーム振分け部１１４は、受信したＵＤＰ／ＲＴＰパケットのペイロード部分の中身を判断し、動画像や音声等のメディアデータに分割して、負荷配分部１１５に渡す。負荷配分部１１５は、複数のデコーダ部１１６〜１１９の処理状況を監視し、ストリーム振分け部１１４から受け取ったパケットを対応するデコーダ部１１６〜１１９に渡す。デコーダ部１１６〜１１９では、受け取ったパケットをデコードして、表示可能な形式に直したのち、表示のためのメモリであるフレームバッファ１２３に書き込む。

２次ＲＸバッファ１２０は、通信振分け部１１３から受け取ったＴＣＰ／ＩＰパケットを一時蓄積するためのものである。アプリケーションＣＰＵ１２１は、表示装置１１０全体の制御を司り、かつ、上位レイヤのプロトコルを処理するものである。

デコード能力モニタ１２２は、複数のデコーダ部１１６〜１１９の処理状況を監視し、当該状況をアプリケーションＣＰＵ１２１に伝えるとともに、アプリケーションＣＰＵ１２１からの指示を負荷配分部１１５に伝える。

フレームバッファ１２３は、表示のためのメモリであり、デコーダ部１１６〜１１９からのデータと、アプリケーションＣＰＵ１２１からのデータとを重ね合わせて、表示部１２４に表示する。表示部１２４は、ディスプレイ等の表示機能を有する。

＜撮像装置１０１〜表示装置１１０間の通信シーケンス＞
図２は、本実施形態にかかる撮像装置１０１と表示装置１１０との間の通信のシーケンスを示す図である。また、図３、４は撮像装置１０１及び表示装置１１０におけるそれぞれの処理の詳細を示す図である。以下、図２〜図４を参照しながら、撮像装置１０１〜表示装置１１０間の通信シーケンスにおける撮像装置１０１及び表示装置１１０の処理の詳細について説明する。

撮影モードに移行すると、ステップＳ３０１では、まず、撮像部１０２から出力された画像をマルチエンコーダ１０３にてファインダ用の画像（撮影にあたり、表示装置１１０に表示される動画像）にエンコードする。そして、エンコードされた当該画像を通信制御ＣＰＵ１０４に渡し、通信モジュール１０５を介して表示装置１１０に送信することでファインダ用画像の送信を開始する（ファインダ画像送信２０１）。

この処理以降、撮像装置１０１では、ファインダ用画像の送信停止を指示されるまで、表示装置１１０に対して一定周期でファインダ画像を送信しつづける。

ステップＳ３０２では、表示装置１１０からのシャッターコマンド（２０２）を、通信モジュール１０５にて受信するのを待つ。シャッターコマンド（２０２）が受信された場合には、ステップＳ３０３に進む。

ステップＳ３０３では、表示装置１１０側から、撮影画像を送信するためのコネクション型の通信であるＴＣＰのコネクション要求コマンド（ＴＣＰコネクション要求コマンド２０３）が送信されるのを待つ。

ステップＳ３０３にて表示装置１１０からのＴＣＰコネクション要求コマンド２０３を受信すると、ステップＳ３０４に進み、通信モジュール１０５は表示装置１１０にＴＣＰコネクション確認コマンド（２０４）を送信する。

ステップＳ３０５では、通信モジュール１０５を介して、コネクションレス型の通信を開始するためのセッション開始要求コマンド（２０５）を送信する。次にステップＳ３０６では、表示装置１１０からのセッション確認コマンド（２０６）の受信を待つ。通信モジュール１０５にて、セッション確認コマンド（２０６）を受信すると、当該セッション確認コマンド（２０６）の内容が解析され、表示装置１０１にて指定されたデコーダ識別子を、一時的にＲＯＭ／ＲＡＭ１０６のＲＡＭ部に蓄積する。

ステップＳ３０７では、撮像部１０２から出力された画像をコネクション型の通信で送信するためのエンコードと、コネクションレス型の通信方式でＲｅｃＶｉｅｗ用に送信するためのサムネール画像（撮影された画像をユーザが確認するために表示装置１１０に一時的に表示される静止画像、ＲｅｃＶｉｅｗともいう）へのエンコードとをマルチエンコーダ１０３にて同時に行う。

エンコードされたＲｅｃＶｉｅｗ用のサムネール画像は、ステップＳ３０８において、通信モジュール１０５から、コネクションレス型の通信方式であるＲＴＰによって、表示装置１１０に送信される（２０７）。この際に、ステップＳ３０６では、ＲＯＭ／ＲＡＭ１０６のＲＡＭ部に蓄積されたデコーダ識別子（ステップＳ３０６にて表示装置１１０より送信され、ＲＯＭ／ＲＡＭ１０６に蓄積されている。詳細は後述）をＲＴＰの拡張ヘッダに設定して送信する。

一方、エンコードされた撮影画像は、ステップＳ３０９において、通信制御ＣＰＵ１０４によって、コネクション型の通信方式であるＴＣＰのプロトコルヘッダが付加され、通信モジュール１０５を介して、表示装置１１０に送信される（撮影画像２０８）。

ステップＳ３１０では、撮影画像（２０８）及びＲｅｃＶｉｅｗ用のサムネール画像（２０７）の送信が終了したかどうかを判断し、終了していないと判断された場合には、ステップＳ３０７に戻り、エンコード処理を続ける。

一方、送信が終了したと判断された場合には、ステップＳ３１１に進み、通信モジュール１０５に指示して、ＴＣＰコネクションを切断する（２０９）。さらに、ステップＳ３１２では、通信モジュール１０５に指示して、コネクションレス型の通信のセッションも切断する（２１０）。

ステップＳ３１３では、撮影モードが終了したかどうかを判断し、終了していないと判断された場合には、ステップＳ３０２に戻り、次のシャッターコマンドの受信を待つ。一方、終了したと判断された場合には、ステップＳ３１４に進み、ファインダ画像の送信を中止し、処理を終了する。

図４は、本発明の第１の実施形態にかかる撮像装置１０１と通信可能な、表示装置１１０の通信振分け部１１３及びストリーム振分け部２０４及びデコーダ部１１６〜１１９及びアプリケーションＣＰＵ１２５における処理の流れを説明するためのフローチャートである。ほとんどの処理は、アプリケーションＣＰＵ１２５によって行われ、ステップＳ４０６及びステップＳ４１０からＳ４１２の処理のみが、通信振分け部１１３及びストリーム振分け部２０４及びデコーダ部１１６〜１１９によって行われる。

撮影モードに移行すると、ステップＳ４０１では、ユーザによってシャッターが押されるのを待ち、シャッターが押されるとステップＳ４０２に進む。ステップＳ４０２では、通信モジュール１１１を介してコネクションレス型の通信方式にてシャッターコマンド（２０２）を撮像装置１０１に送信する。さらに、ステップＳ４０３では、通信モジュール１１１を介して、コネクション型の通信を確立するための、ＴＣＰコネクション要求コマンド（２０３）を撮像装置１０１に送信する。

ステップＳ４０４では、撮像装置１０１側からのＴＣＰコネクション確認コマンド（２０４）の受信を待つ。ＴＣＰコネクション確認コマンド（２０４）を受信すると、ステップＳ４０５では、コネクションレス型の通信方式であるＲＴＰセッションの開始要求コマンド（２０５）を待つ。ステップＳ４０５にて通信モジュール１１１を介して、ＲＴＰセッション開始要求コマンド（２０５）を受信すると、ステップＳ４０６では、デコード能力モニタ１２２が、現在のデコーダ部１１６〜１１９の使用状況を確認し、コネクション型の通信方式で使用するデコーダ部を決定し、通信モジュール１１１を介してデコーダ識別子を設定したコネクションレス型の通信方式にてセッション確認コマンド（２０６）を撮像装置１０１に送信する。

ステップＳ４０７では、通信モジュール１１１にて、撮像装置１０１からのパケット（撮影画像ｏｒＲｅｃＶｉｅｗ画像のパケット）の受信を待つ。通信モジュール１１１にてパケットを受信すると、ステップＳ４０８では、通信振分け部１１３において、パケットのトランスポートレイヤのヘッダ解析を行う。ステップＳ４０８における解析の結果、ＲＴＰのようなコネクションレス型の通信方式であると判断された場合には（ＲｅｃＶｉｅｗ画像の場合には）、ステップＳ４１２に進み、ストリーム振分け部１１４でパケットのペイロード部分の解析を行って分割する。この分割されたパケットは、負荷配分部１１５に渡され、予めアプリケーションＣＰＵ１２１から指定された設定（デコーダ識別子の設定）に従って、デコーダ部１１６〜１１９に渡される。ステップＳ４１３では、サムネール画像の形式に従って、デコードされる。

ステップＳ４１４では、デコードされたサムネール画像をフレームバッファ１２３に書き込んで、表示部１２４にＲｅｃＶｉｅｗ画像として表示して、ステップＳ４１１に進む。

一方、受信したパケットが、通信振分け部２０３で、ＴＣＰコネクション型の通信のパケットであると判断された場合には（ステップＳ４０８で「Ｎｏ」の場合には（つまり、撮影画像の場合には））、ステップＳ４０９に進む。

ステップＳ４０９では受信したパケットが２次ＲＸバッファ１２０に転送され、アプリケーションＣＰＵ１２１によって、トランスポート層以上の上位レイヤのプロトコルの処理がなされる。プロトコルの処理が終了して、撮影画像がパケットからとりだされると、ステップＳ４１０において、該撮影画像をメモリ等の補助記憶部（不図示）に蓄積する。

ステップＳ４１１では、全てのパケットの受信が終了したかどうかを判断し、終了したと判断された場合には、ステップＳ４１５において、通信モジュール１１１からのセッション切断コマンド（２１０）とＴＣＰコネクション切断コマンド（２０９）とを待ち、両方の切断コマンドを確認した後、処理を終了する。一方、全てのパケットの受信が終了していないと判断された場合には、ステップＳ４０７に戻り、次のパケットの受信処理を行う。

なお、蓄積した撮影画像を再生する場合には、デコード能力モニタ１２２で使用状況を確認して、複数のデコーダ部１１６〜１１９の中から、空いているデコーダ部を指定してデコード処理を行う。

以上のような構成により、コネクションレス型の通信方式で受信したＲｅｃＶｉｅｗ用のサムネール画像のデコードとコネクション型の通信方式で受信した撮影画像のデコードとを、別々のデコーダ部で処理することが可能となる。

＜ＲＴＣＰのＡＰＰパケットのフォーマット＞
図５は、本発明の第１の実施形態にかかる撮像装置１０１、表示装置１１０で使用されるＲＴＣＰのＡＰＰパケットのフォーマットを示す図である。ＡＰＰパケットは、表示装置１１０が備えるＡＰＰ（アプリケーション）によって定義される各種制御コマンドを送信するために使用される。本実施形態では、受信側の表示装置１１０から、当該ＡＰＰパケットに制御コマンドをのせて、ＲＴＣＰ／ＴＣＰ／ＩＰのプロトコルフォーマットで撮像装置１０１に送信される（撮像装置１０１は、該制御コマンドに基づいて動作制御される）。

＜表示装置１１０におけるＲＴＣＰ処理＞
次に図４に示す表示装置１１０の処理の流れのうち、ＲＴＣＰ処理に関して詳細を説明する。図６は表示装置１１０におけるＲＴＣＰ処理の流れを示すフローチャートである。

本実施形態では、表示装置１１０よりＲＴＣＰ処理にて撮像装置１０１に送信される制御コマンドとして、大きく２種類に大別できる。一方は、ユーザの指示等に基づいてアプリケーションＣＰＵ１２１を介して発生する制御コマンド（例えば、シャッターコマンド）であり、もう一方は、タイマー起動により発生する制御コマンドである。以下、ＲＴＣＰ処理にて制御コマンドを送信する場合の表示装置１１０の処理について説明する。

ステップＳ６０１では、本処理が、タイマにより起動されたのか、アプリケーションＣＰＵ１２１により起動されたのかを確認する。タイマにより起動された場合には、ステップＳ６０２に進み、受信レポート（Ｒｅｃｅｉｖｅ Ｒｅｐｏｒｔ）作成の指示であるかどうかを判断する。

受信レポート作成の指示であった場合には、ステップＳ６０３に進み、通信モジュール１１１に対して、通信状況の問い合わせを行い、パケットロスの個数、受信した最大のシーケンスＮＯ等の情報を受領する。ステップＳ６０４では、これらの情報に基づいて受信レポート（ＲＲ）を作成し、通信モジュール１１１を介して、ＲＴＣＰのＲＲコマンドを送信し、処理を終了する。なお、受信レポートを作成するか否かの設定は、表示装置１１０内のＲＡＭ等のメモリに、アプリケーションにより初期設定されているものとする。

一方、ステップＳ６０２において、受信レポート作成の指示でなかった場合には、ステップＳ６０５に進み、デコード能力モニタ１２２に、現在のデコーダ部１１６〜１１９の使用状況を確認する。

ステップＳ６０６では、デコーダ部１１６〜１１９の使用状況の確認結果を解析して、複数のデコーダ部の処理配分が適正かどうかを判断する。もし、処理配分が適正でないと判断された場合には、ステップＳ６０７において、使用されていないデコーダ部や、より処理能力が高いデコーダ部へと処理配分を変更すべく、ＲＴＣＰのＡＰＰコマンドで、変更すべきデコーダ識別子を指定して、通信モジュール１１１を介して、撮像装置１１０に送信して処理を終了する。一方、処理配分が適正であると判断された場合には、そのまま処理を終了する。

ＲＴＣＰのＡＰＰコマンドを受信した撮像装置１１０側では、撮影画像送信時のＲＴＰの拡張ヘッダに、当該指定されたデコーダ識別子を付加して送信を行う。これにより、表示装置１１０の負荷配分部１１５では、当該デコーダ識別子に基づいてパケットの振分けが動的に変化することとなる。

一方、ステップＳ６０１においてタイマー起動ではないと判断された場合には、本処理がユーザの操作等を契機として、アプリケーションＣＰＵ１２１により起動されたものであると判断し、ステップＳ６０８に進む。ステップＳ６０８ではアプリケーションＣＰＵ１２１からのコマンドを解析する。

次に、ステップＳ６０９では、ステップＳ６０８におけるコマンド解析に従って、ＲＴＣＰのＡＰＰコマンドを作成し、ステップＳ６１０において、通信モジュール１１１を介して、撮像装置１０１側に送信して処理を終了する。

＜撮像装置１０１におけるＲＴＣＰ処理＞
次に図３に示す撮像装置１０１の処理の流れのうち、ＲＴＣＰ処理に関して詳細を説明する。図７は撮像装置１０１におけるＲＴＣＰ処理の流れを示すフローチャートである（図６に示す表示装置１１０のＲＴＣＰ処理に対応している）。

ステップＳ７０１では、通信モジュール１０５にて受信したＲＴＣＰパケットの解析を行う。

次に、ステップＳ７０２では、受信したＲＴＣＰパケット（ＲＴＣＰのＲＲコマンドまたはＡＰＰコマンドのパケット）が、ＡＰＰパケットであるかどうかを判断する。ＡＰＰパケットであると判断された場合には、ステップＳ７０３に進み、ＡＰＰパケット内にある撮像装置制御用の制御コマンドを撮像部１０２に通知して、処理を実行させる。次に、ステップＳ７０４において、撮像装置制御用の制御コマンドを受理したことを示すＡＰＰレスポンスを、通信モジュール１０５を介して、ＴＣＰ／ＩＰ等のコネクション型の通信方式で表示装置１１０に送信する。

ステップＳ７０５では、撮像装置の制御に伴って何らかの表示をする必要があるかどうかを判断し、表示の必要があると判断された場合には、ステップＳ７０６に進む。ステップＳ７０６では、ＲｅｃＶｉｅｗ用のサムネール画像をＲＯＭ／ＲＡＭ１０６上に作成し、ステップＳ７０７では、通信モジュール１０５を介して、ＲＴＰ等のコネクションレス型の通信方式で表示装置１１０に送信する。

次にステップＳ７０８において、ＲｅｃＶｉｅｗ用のサムネール画像の送信が終了したかどうかを判断し、終了していなければ、ステップＳ７０７に戻り、送信処理を続ける。一方、送信が終了した場合には、処理を終了する。

一方、ステップＳ７０２において、受信したＲＴＣＰパケットがＡＰＰパケットでないと判断された場合には、ステップＳ７０９に進み、受信したＲＴＣＰパケットが、Ｒｅｃｅｉｖｅ Ｒｅｐｏｒｔ（ＲＲ）コマンドかどうかを判断する。ＲＲコマンドであると判断された場合には、ステップＳ７１０に進み、受信したＲＲコマンドの内容に応じて、パケットロスしたパケットの再送を行う等のレポート対応処理を行う。ステップＳ７１１では、通信モジュール１０５を介して、ＡＰＰレスポンスを表示装置１１０に送信し、処理を終了する。

一方、ステップＳ７０９で、受信したＲＴＣＰパケットがＲＲコマンドでないと判断された場合には、通信モジュール１０５を介して、エラーのレスポンスを送信して、処理を終了する。

＜ストリーミングデータの送信処理＞
図８は、本発明の第１の実施形態にかかる撮像装置１０１の通信制御ＣＰＵ１０４におけるストリーミングデータ送信処理の流れを示すフローチャートである（上述のファインダ用画像は、当該処理に基づいて送信される）。

ステップＳ８０１では、ストリーミングデータ送信側である撮像装置１０１が、通信モジュール１０５を介して、受信側である表示装置１０２に、ネゴシエーション要求コマンドを送信する。通常、コネクションレス型の通信方式であるＲＴＰ等では、ネゴシエーションは必要ではないが、本実施形態においては、ＲＴＰのヘッダを簡略化するための手段が複数用意され、このうちのどの簡略化方式を使用するかをネゴシエーションするために、対応可能な簡略化手段を受信側（表示装置１１０）に知らせる。

複数のヘッダの簡略化手段としては、ＲＴＰパケットのヘッダの構成要素であるｔｉｍｅｓｔａｍｐやＳｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｏｕｒｃｅ（ＳＳＲＣ） ｉｄｅｎｔｉｆｉｅｒやｓｅｑｕｅｎｔｉａｌ ｎｕｍｂｅｒの中で、受信側がその要素がなくても処理可能なもの（例えば、音声と映像とを含むメディアデータの場合には、出力タイミングを合わせるためにｔｉｍｅｓｔａｍｐが不可欠であるが、それ以外の場合（例えば、映像のみの場合）には、当該要素を省略しても処理することが可能である）を指定することにより簡略化する手段や、テキストデータをビット対応にすることで簡略化する手段等がある。

ステップＳ８０２では、表示装置１１０からのネゴシエーション確認コマンドの受信を待ち、通信モジュール１０５においてネゴシエーション確認コマンドを受信すると、当該ネゴシエーション確認コマンドで指示される簡略化手段を一時的にＲＯＭ／ＲＡＭ１０６のＲＡＭ部に記憶する。

ステップＳ８０３では、撮像部１０２より出力された画像をマルチエンコーダ１０３で圧縮する。ステップＳ８０４では、マルチエンコーダ１０３から出力された圧縮データを通信プロトコルで規定されているパケット長に収まるように分割し、ヘッダを追加する。なお、このときＲＴＰのヘッダについては、ＲＯＭ／ＲＡＭ１０６のＲＡＭ部に記憶している簡略化手段に応じて処理される。このようにして送信用のストリーミングデータを含んだパケットが生成されるとステップＳ８０５に進み、通信モジュール１０５にパケットを渡して、表示装置１１０に対して送信を行う。

ステップＳ８０６では、マルチエンコーダ１０３から出力された圧縮データを全て送信したかどうかを判断し、未完了の場合には、ステップＳ８０３に戻り、次の送信処理を行う。一方、送信が終了したと判断された場合には、ストリーミングデータの送信処理を終了する。

以上説明したように、本実施形態によれば、撮影時の画像確認のためのＲｅｃＶｉｅｗ画像を、送信側から、撮影画像の送信と並行して送信することにより、表示装置では迅速な表示が可能になる。

また、本実施形態によれば、ＲＴＣＰのＡＰＰパケットを使用して、撮像装置に対する制御コマンドを送信する構成としたため、表示装置では、その処理の結果を遅延なく表示することが可能となる。

さらに、本実施形態によれば、ＲＴＰのヘッダを簡略化する構成としたため、受信側でのパケットヘッダ処理の負荷を軽減させることが可能となり、その結果、ストリーミングデータの受信に関する遅延を少なくすることが可能となる。

［第２の実施形態］
上記第１の実施形態では、ＲｅｃＶｉｅｗ用のサムネール画像をコネクションレス型の通信方式で送信し、撮影画像をコネクション型の通信方式で送信することとしたが、本発明は特にこれに限られず、双方をコネクション型の通信方式で送信するようにしても、あるいは双方をコネクションレス型の通信方式で送信するようにしてもよい。なお、コネクションレス型の通信方式で撮影画像を送信する場合には、ＲＴＣＰを使った再送制御を行うことで、撮影画像を保証することができる。

また、エンコーダが階層構造となっており、撮影画像のエンコードの途中処理の段階で、順次サムネール画像を作成できるのであれば、撮影画像の送信に先立って、ＲｅｃＶｉｅｗ用のサムネール画像を送信するようにしてもよい。

また、上記第１の実施形態においては、ＲＴＣＰのＡＰＰパケットを使用して制御コマンドを送信することとしたが、本発明は特にこれに限られず、他のプロトコルを使用するようにしてもよい。

さらに、上記第１の実施形態においては、ＲＴＰのヘッダのみを簡略化することとしたが、本発明は特にこれに限られない。レイヤのヘッダだけでなく、ＩＰ／ＵＤＰ等も含めて簡略化するようにすれば、更に、受信側での処理負荷が減り、遅延を少なくさせることが可能となる。

［他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明の第１の実施形態にかかる撮像装置の構成を示す図である。 本発明の第１の実施形態にかかる撮像装置と通信可能な表示装置の構成を示す図である。 本発明の第１の実施形態にかかる撮像装置と表示装置との間の通信のシーケンスを示す図である。 本発明の第１の実施形態にかかる撮像装置及び表示装置におけるそれぞれの処理の詳細を示す図である。 本発明の第１の実施形態にかかる撮像装置と通信可能な表示装置の通信振分け部及びストリーム振分け部及びデコーダ部及びアプリケーションＣＰＵにおける処理の流れを説明するためのフローチャートである。 本発明の第１の実施形態にかかる撮像装置、表示装置で使用されるＲＴＣＰのＡＰＰパケットのフォーマットを示す図である。 表示装置におけるＲＴＣＰ処理の流れを示すフローチャートである。 撮像装置１０１におけるＲＴＣＰ処理の流れを示すフローチャートである。 本発明の第１の実施形態にかかる撮像装置の通信制御ＣＰＵにおけるストリーミングデータ送信処理の流れを示すフローチャートである。

符号の説明

１０１ 撮像装置
１０２ 撮像部
１０３ マルチエンコーダ
１０４ 通信制御ＣＰＵ
１０５ 通信モジュール
１０６ ＲＯＭ／ＲＡＭ
１０７ システムバス
１１０ 表示装置
１１１ 通信モジュール
１１２ １次ＲＸバッファ
１１３ 通信振分け部
１１４ ストリーム振分け部
１１５ 負荷配分部
１１６〜１１９ デコーダ部
１２０ ２次ＲＸバッファ
１２１ アプリケーションＣＰＵ
１２２ デコード能力モニタ
１２３ フレームバッファ
１２４ 表示部

Claims (10)

1. 画像を表示する表示装置と通信可能な撮像装置であって、
   動画像を撮影中に、前記表示装置より、静止画像を撮影する旨の指示を受け付ける受付手段と、
   前記受付手段において受け付けた指示に基づいて、静止画像を撮影する撮像手段と、
   前記撮像手段において撮影された静止画像を縮小し、コネクションレス型の通信により前記表示装置に送信する第１の送信手段と、
   前記撮像手段において撮影された前記静止画像を、コネクション型の通信により前記表示装置に送信する第２の送信手段と
   を備えることを特徴とする撮像装置。
2. 前記静止画像を撮影する旨の指示は、コネクションレス型の通信により送信され、前記第１の送信手段は、該指示に基づいて前記撮像手段にて撮影された静止画像を縮小し、生成されたサムネール画像を前記表示装置に送信することを特徴とする請求項１に記載の撮像装置。
3. 前記第１の送信手段は、
   前記受付手段において前記指示を受け付けた場合に、前記表示装置に対して、コネクションレス型の通信のセッション開始要求を送信することを特徴とする請求項１に記載の撮像装置。
4. 前記第１の送信手段は、
   前記セッション開始要求に対して前記表示装置より送信されたセッション確認コマンドを受信するとともに、該セッション確認コマンドに含まれ、前記表示装置が有するデコーダを指定する識別子を、前記サムネール画像に付加して前記表示装置に送信することを特徴とする請求項３に記載の撮像装置。
5. 前記第２の送信手段は、前記受付手段において前記指示を受け付けた場合に、前記表示手段との間に、コネクション型接続を確立することを特徴とする請求項１に記載の撮像装置。
6. 前記撮像手段において撮影された動画像を、コネクションレス型の通信により、ストリーミング画像として前記表示装置に送信する第３の送信手段を更に備え、
   前記第３の送信手段は、前記撮像手段において撮影された動画像に、所定の簡略化方式により簡略化されたヘッダを付加したうえで、前記ストリーミング画像として前記表示装置に送信することを特徴とする請求項１に記載の撮像装置。
7. 前記第３の送信手段は、前記撮像手段において動画像を撮影する前に、前記表示手段に対して、前記簡略化方式に関する情報を送信することを特徴とする請求項６に記載の撮像装置。
8. 画像を表示する表示装置と通信可能な撮像装置における情報処理方法であって、
   動画像を撮影中に、前記表示装置より、静止画像を撮像する旨の指示を受け付ける受付工程と、
   前記受付工程において受け付けた指示に基づいて、静止画像を撮影する撮像工程と、
   前記撮像工程において撮影された静止画像を縮小し、コネクションレス型の通信により前記表示装置に送信する第１の送信工程と、
   前記撮像工程において撮影された前記静止画像を、コネクション型の通信により前記表示装置に送信する第２の送信工程と
   を備えることを特徴とする情報処理方法。
9. 請求項８に記載の情報処理方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
10. 請求項８に記載の情報処理方法をコンピュータによって実現させるための制御プログラム。

Images