JP4276120B2 - 画像伝送装置 - Google Patents

Description

本発明は、ネットワークを介して画像データの伝送を行う画像伝送装置に関し、特に、複数のクライアントに対して効果的に画像データの伝送を行う画像伝送装置に関する。

例えば、画像伝送装置は、図９に示されるような構成を有している。なお、ここでは、本発明の実施例に係る画像伝送装置を限定する意図は全く無い。
図９に示される画像伝送装置８は、例えばカメラ等から入力された画像信号をＡ／Ｄ（Analog to Digital）変換して画像データ（デジタル画像信号）を出力するＡ／Ｄ変換部２１と、Ａ／Ｄ変換部２１から入力された画像データを圧縮符号化して圧縮画像データを出力する画像符号化部２２と、画像符号化部２２から入力された圧縮画像データを一時的に保持するための画像データバッファ部８３と、画像データバッファ部８３に記憶された圧縮画像データを所定の通信プロトコルにより外部に送信するためのネットワークＩ／Ｆ（インターフェース）部２４と、画像伝送装置８の全体の機能の制御や各種の処理を実行するＣＰＵ（Central Processing Unit）８５から構成されている。

ここで、画像伝送装置８は、例えば、ネットワークを介して外部のＰＣ（Ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ：パソコン）端末から画像送信要求を受信すると、圧縮画像データを当該ＰＣ端末に対して送信する。また、例えば、ネットワークを介して外部の携帯電話端末から画像送信要求を受信した場合には、ＣＰＵ８５の制御により画像符号化部２２のパラメータを変更して圧縮符号化処理を行い、携帯電話端末で受信可能な縮小サイズの圧縮画像データ（以下、縮小画像データと称する。）を生成し、当該縮小画像データを携帯電話端末に対して送信する。

図１０には、画像伝送装置の他の構成例を示してある。なお、図９と同じものには同じ符号が付してあるので説明は省略する。図１０に示した画像伝送装置９では、画像符号化部２２に加えて、画像符号化部２２１という２つの画像符号化部が存在する。ここで、画像伝送装置９は、ネットワークを介して外部のＰＣ端末から画像送信要求を受信した場合には、画像符号化部２２により生成された圧縮画像データを当該ＰＣ端末に対して送信する。一方、ネットワークを介して外部の携帯電話端末から画像送信要求を受信した場合には、画像符号化部２２１により生成された携帯電話端末配信用の縮小画像データを当該携帯電話端末に対して送信する。

なお、従来、複数のユーザからの画像データの送信要求に十分対応できる画像伝送システムが検討されている（例えば、特許文献１参照）。
特開２００３−１７９９００号公報

しかしながら、例えば、図９に示したような構成の画像伝送装置では、携帯電話端末からの画像送信要求があった場合に画像符号化部のパラメータを変更して縮小画像データを生成するため、同時にＰＣ端末からも画像送信要求があった場合には、画像符号化部のパラメータを元に戻し、次のフレームの画像データによりＰＣ端末に配信する圧縮画像データを生成する必要があるため、例えば、配信のフレームレートが低下してしまうといった問題があった。

また、例えば、図１０に示したような構成の画像伝送装置では、画像符号化部が複数あるため、上記のようなフレームレートの低下の問題は改善される。しかしながら、図９に示したような画像伝送装置に比べると、画像符号化部２２１という新たなハードウェアの追加が必要となるため、例えば、コストの増加や装置の容積等の増加といった問題があった。

本発明は、このような従来の課題を解決するために為されたもので、例えば、複数のクライアントに対して効果的に画像データの伝送を行うことができる画像伝送装置を提供することを目的とする。

上記目的を達成するため、本例に係る画像伝送装置では、入力された画像データを圧縮符号化処理する画像符号化手段と、該画像符号化手段からの圧縮画像データを記憶する画像データ記憶手段と、クライアントから送信される画像送信要求を受信する画像送信要求受信手段と、前記クライアントからの画像送信要求に基づいて前記画像データ記憶手段に記憶された圧縮画像データを前記クライアントに対して送信する画像送信手段と、前記各手段を制御する制御手段と、を備えた構成において、次のような処理を行う。即ち、前記制御手段は、前記画像送信要求から前記クライアントのうち特定のクライアントか否かを判別する機能と、前記特定のクライアントである場合には前記画像データ記憶手段に記憶された圧縮画像データをリサイズ処理してリサイズ画像データを生成するリサイズ処理機能を備え、前記リサイズ画像データを前記特定のクライアントに対して送信するように制御する。

ここで、ここで、画像データとしては、動画像のデータが用いられてもよく、或いは、静止画像のデータが用いられてもよい。また、圧縮符号化処理としては、種々なものが用いられてもよく、例えば、ＪＰＥＧ方式やＭＰＥＧ方式を用いることができる。また、クライアントとしては、種々なものが用いられてもよい。また、リサイズ処理としては、種々なものが用いられてもよく、例えば、間引き処理や、補間処理等を用いることができる。

また、本発明に係るデータ記憶装置では、一構成例として、前記制御手段は、更に、前記リサイズ処理を複数の処理単位に分割して段階的に実行する処理管理機能を備え、前記画像送信手段の制御を前記リサイズ処理機能の実行に比べて優先する。

ここで、処理単位としては、種々なものが用いられてもよい。また、リサイズ処理を段階的に実行する態様としては、種々なものが用いられてもよい。

本発明に係る画像伝送装置によると、例えば、画像データのリサイズ処理をＣＰＵにより行うようにしたため、複数のクライアントに対して効果的に画像データの伝送を行うことができる。

以下、本発明の実施の形態について、図面を参照しながら説明する。
図１には、本発明の一実施例に係る画像伝送システムの構成例を示してある。
本例の画像伝送システムは、カメラ１と、画像伝送装置２と、ネットワーク３と、ＰＣ端末４−１、４−２と、携帯電話網５と、携帯電話端末６から構成されている。なお、本例では、説明を簡易化するために、１台のカメラ１により撮像された画像データの送信要求を行うクライアントとして、ＰＣ端末が２台、携帯電話端末が１台であるとして説明するが、これらの台数としては、種々なものが用いられてもよい。

ここで、図１に示す画像伝送システムでは、カメラ１で撮像された画像データが、サーバ機能を備える画像伝送装置２からネットワーク３を介してＰＣ端末４−１、４−２や、携帯電話端末６に送信される。なお、携帯電話端末６は、携帯電話網５と無線でパケットの送受信を行い、携帯電話網５は、携帯電話端末６からの要求を受け取って携帯電話端末６とネットワーク３の接続を図る。

図２には、本発明の一実施例に係る画像伝送装置２の構成例を示してある。
本例の画像伝送装置２は、例えばカメラ等の映像信号生成装置から入力された画像信号をＡ／Ｄ変換して画像データを出力するＡ／Ｄ変換部２１と、Ａ／Ｄ変換部２１から入力された画像データを、例えばＪＰＥＧ方式等の圧縮符号化方式により圧縮符号化して圧縮画像データを出力する画像符号化部２２と、画像符号化部２２から入力された圧縮画像データを一時的に保持するための画像データバッファ部２３と、画像データバッファ部２３に記憶された圧縮画像データを所定の通信プロトコルにより外部に送信するためのネットワークＩ／Ｆ部２４と、画像伝送装置２の全体の機能の制御や各種の処理を実行するＣＰＵ２５から構成され、ＣＰＵ２５は、画像データバッファ部２３に記憶された圧縮画像データのリサイズ処理を行うリサイズモジュール２５０を備えている。ここで、画像符号化部２２は、例えば、ＤＳＰ（Digital Signal Processor）や、ＦＰＧＡ（Field Programmable Gate Array）や、専用のＩＣにより実現される。また、ここで、リサイズ処理とは、例えば画像データのサイズを変更することをいい、リサイズには、間引きなどにより画像データのサイズを縮小する処理や、補間などにより画像データのサイズを拡大する処理等がある。なお、以下では、圧縮画像データを復号し、間引きなどにより画像データのサイズを縮小した後、再圧縮する処理をリサイズ処理と称する。

ここで、本例の画像伝送装置２では、ネットワーク３を介してネットワークＩ／Ｆ部２４が画像送信要求を受信すると、画像送信要求中に含まれる識別コードといった情報に基づきＣＰＵ２５では当該画像送信要求の送信元を判別する。例えば、各携帯電話会社固有のコードを画像伝送装置２のメモリ（不図示）に記憶しておき、当該コードに合致したものは携帯電話端末６からの画像送信要求であり、それ以外はＰＣ端末４−１や４−２からの画像送信要求である、といったような判別を行うことが可能である。判別の結果、画像送信要求の送信元がＰＣ端末４−１や４−２であれば、画像データバッファ部２３に記憶されている圧縮画像データをネットワークＩ／Ｆ部２４からネットワーク３に接続されているＰＣ端末４−１や４−２に対して送信する。また、判別の結果、画像送信要求の送信元が携帯電話端末６であれば、画像データバッファ部２３に記憶されている圧縮画像データをＣＰＵ２５のリサイズモジュール２５０によりリサイズ処理して縮小画像データを生成し、当該縮小画像データをネットワークＩ／Ｆ部２４から、携帯電話網５を介してネットワーク３に接続されている携帯電話端末６に対して送信する。

なお、本例の画像伝送装置２では、ＰＣ端末４−１、４−２や携帯電話端末６のいずれかのクライアントから画像送信要求を受信すると、当該クライアントに１フレームのＪＰＥＧ画像データ（圧縮画像データ）を送信するといったように、１つの要求がある毎に１フレームのＪＰＥＧ画像データが画像伝送装置２から当該クライアントへ送信されるようにしている。すなわち、本例では、要求がある毎に圧縮画像データを１フレームずつネットワーク３を介して通信する方法を採用しているが、要求がある毎に圧縮画像データを複数フレーム分通信するようにしてもよい。

ここで、ＰＣ端末４−１、４−２に送信される圧縮画像データとしては、例えば、６４０×４８０ピクセルの解像度のＶＧＡ（Video Graphics Array）サイズの画像データや、３２０×２４０ピクセルの解像度のＱＶＧＡ（Quarter VGA）サイズの画像データが用いられる。また、携帯電話端末６に送信される縮小画像データとしては、例えば、１２０×９０ピクセルの解像度の画像データが用いられる。

図３には、本例の画像伝送装置２が画像データを送信する際の処理の様子の一例を示してある。図３では、主に画像データバッファ部２３を用いて画像データ送信処理の様子を模式的に示してある。なお、実際には画像データバッファ部２３自体がこのような処理を行うわけではなく、図２で示した本例の画像伝送装置２のＣＰＵ２５やリサイズモジュール２５０の制御により処理動作が実行される。

本例の画像データバッファ部２３は、リングバッファ部２３１と、送信データバッファ部２３２ａ〜ｃと、リサイズ用メモリ部２３３から構成される。ここでは、ＰＣ端末４−１、４−２、及び、携帯電話端末６に画像データを送信する際のバッファとして、送信データバッファ部２３２ａ〜ｃの３つのバッファ部を備える構成としているが、バッファ部の数は必ずしもクライアントの台数と同数である必要はない。

ここで、画像符号化部２２から出力された圧縮画像データ３００は、まず、画像データバッファ部２３のリングバッファ部２３１に入力される。ここで、リングバッファ部２３１は、例えば、数フレーム分の圧縮画像データを記録可能なリングバッファの構成を有しており、記録される圧縮画像データがいっぱいになったら、古い圧縮画像データから順次上書きされることで、圧縮画像データが更新されていく。

ネットワークＩ／Ｆ部２４は、ネットワーク３を介して画像送信要求を受信すると、送信データバッファ部２３２ａ〜ｃに画像送信要求の送信元のクライアントに対応する画像送信要求３０１ａ〜ｃを出力する。ここでは、ＰＣ端末４−１は画像送信要求３０１ａ、ＰＣ端末４−２は画像送信要求３０１ｂ、携帯電話端末６は画像送信要求３０１、とそれぞれ対応関係にある。

次に、ＣＰＵ２５の制御により実現される送信データバッファ部２３２ａの処理動作について説明する。なお、本例では、送信データバッファ部２３２ｂの処理動作についても送信データバッファ部２３２ａと同様の動作をする。すなわち、送信データバッファ部２３２ａでは、まず、ＰＣ端末４−１からの画像送信要求３０１ａを受信する。受信に応じて送信データバッファ部２３２ａは、リングバッファ部２３１に対して最新の圧縮画像データの送信要求３０２ａを送る。これに応答して、リングバッファ部２３１から最新の圧縮画像データ３０３ａが送られてくると、送信データバッファ部２３２ａは圧縮画像データ３０３ａを記憶する。そして、送信データバッファ部２３２ａは、記憶された圧縮画像データ３０３ａからネットワーク３上で伝送するのに適したパケットを生成し、生成されたデータ（パケット化された圧縮画像データ３０４ａ）をネットワークＩ／Ｆ部２４に出力する。ネットワークＩ／Ｆ部２４では、ＣＰＵ２５の制御に基づき、パケット化された圧縮画像データ３０４ａを所定の通信プロトコルによりＰＣ端末４−１に対して送信する。その結果、圧縮画像データを受信したＰＣ端末４−１では、例えば、更に次のフレームの画像配信要求を画像伝送装置２に対して送信し、以降、上記と同様の動作が繰り返される。

次に、ＣＰＵ２５の制御により実現される送信データバッファ部２３２ｃの処理動作について説明する。すなわち、送信データバッファ部２３２ｃでは、まず、携帯電話端末６からの画像送信要求３０１ｃを受信する。受信に応じて送信データバッファ部２３２ｃは、リングバッファ部２３１に対して最新の圧縮画像データの送信要求３０２ｃを送る。これに応答して、リングバッファ部２３１から最新の圧縮画像データ３０３ｃが送られてくると、送信データバッファ部２３２ｃは圧縮画像データ３０３ｃを記憶する。次に、送信データバッファ部２３２ｃは記憶された圧縮画像データ３０３ｃを読み出して、リサイズモジュール２５０に出力する。

次に、リサイズモジュール２５０では、圧縮画像データ３０３ｃを圧縮前の画像データに復号して、更に復号した画像データに間引き処理を行い、リサイズ済みの非圧縮の縮小画像データ３０５−１をリサイズ用メモリ部２３３に送る。次に、リサイズ用メモリ部２３３に記憶された非圧縮の縮小画像データ３０５−１は読み出されて、リサイズモジュール２５０に送られる。リサイズモジュール２５０では、非圧縮の縮小画像データ３０５−１を圧縮符号化処理し、圧縮された縮小画像データ３０５−２が送信データバッファ部２３２ｃに出力する。送信データバッファ部２３２ｃでは、それまで記憶していた圧縮画像データ３０３ｃの内容を縮小画像データ３０５−２に更新する。そして、送信データバッファ部２３２ｃは、縮小画像データ３０５−２からネットワーク３上で伝送するのに適したパケットを生成し、生成されたデータ（パケット化された縮小画像データ３０４ｃ）をネットワークＩ／Ｆ部２４に出力する。ネットワークＩ／Ｆ部２４では、ＣＰＵ２５の制御に基づき、パケット化された縮小画像データ３０４ｃを所定の通信プロトコルにより携帯電話端末６に対して送信する。その結果、縮小画像データを受信した携帯電話端末６では、例えば、更に次のフレームの画像配信要求を画像伝送装置２に対して送信し、以降、上記と同様の動作が繰り返される。

以上のように、本例の画像伝送装置２では、ネットワーク３に接続されたＰＣ端末４−１、４−２からの画像送信要求に対しては、画像符号化部２２により生成された圧縮画像データを送信し、ネットワーク３に接続された携帯電話端末６からの画像送信要求に対しては、画像符号化部２２により生成された圧縮画像データをＣＰＵ２５のリサイズモジュール２５０によりリサイズ処理して生成された縮小画像データを送信することが可能である。

従って、本例の画像伝送装置２では、例えば、専用のハードウェアの追加を行わずに、ＣＰＵ２５にリサイズモジュール２５０といった処理ソフトウェアを追加することにより、携帯電話端末配信用の縮小画像データを生成することができ、例えば、異なるクライアントからの画像データの送信要求に効果的に対応することができる。

次に、本例の画像伝送装置２のＣＰＵ２５の処理の優先度について説明する。上述したように、本例の画像伝送装置２のＣＰＵ２５には、リサイズモジュール２５０が追加されている。例えば、１フレーム分の圧縮画像データに対して、復号処理、間引き処理、及び、再圧縮処理からなるリサイズ処理を行うには、４００ｍｓｅｃ程度の処理時間を要する。その結果、４００ｍｓｅｃという時間分はＣＰＵ２５がリサイズ処理に占有されることになり、その間は画像データバッファ部２３に記憶された圧縮画像データをネットワークＩ／Ｆ部２４から外部のクライアントに送信する処理が出来なくなる。その結果、クライアントへの画像データの配信のフレームレートが大きく低下する事態が生じる場合がある。そこで、本例の画像伝送装置２のＣＰＵ２５では、例えば、携帯電話端末６からの画像送信要求に応じてリサイズモジュール２５０により圧縮画像データのリサイズ処理を行う場合には、本来の画像データの配信性能が大きく低下しないように、ＣＰＵ２５の処理の優先度を設定する。即ち、画像データの送信処理に比べて、リサイズ処理の優先度を低く設定することにより、画像データの配信性能の低下を防いでいる。

図４（Ａ）、（Ｂ）、（Ｃ）を参照して、ＣＰＵ２５の処理に優先度を設定することによる画像データの配信性能低下の低減効果の具体例を説明する。
図４（Ａ）には、一例として、２０クライアントに対して画像データを配信する場合の配信のフレームレートを示してある。例えば、画像伝送装置２の画像データの配信能力には限界があり、ここではその限界値を一秒間に１００フレーム、つまり１００ｆｐｓ（frame per second）であるとする。従って、クライアント数が多くなれば、配信能力１００フレームをクライアント同士で分け合う形となり、２０クライアントが画像伝送装置２に接続する場合には、図４（Ａ）に示すように、１クライアント当りの配信フレーム数は一秒間に５フレームずつ、つまり５ｆｐｓとなる。

図４（Ｂ）には、４００ｍｓｅｃという処理時間がかかるリサイズ処理を新たにＣＰＵ２５に行わせた場合についてを示してある。図４（Ｂ）に示すように、リサイズ処理の追加により、ＣＰＵ２５が４００ｍｓｅｃという時間分はリサイズ処理に占有されることとなるため、２０クライアントへの配信性能は５ｆｐｓから３ｆｐｓに低下する。また、画像伝送装置２が常に最新フレームの圧縮画像データを送信するような構成とした場合、図４（Ｂ）に示すようにリサイズ処理を連続的に実行した場合には、２フレーム分の圧縮画像データが連続して送信できなくなる。

そこで、本例の画像伝送装置２では、図４（Ｂ）に示すように、ＣＰＵ２５が１秒間に行う処理内容にリサイズ処理をそのまま追加するのではなく、ＣＰＵ２５は画像データの送信処理を優先的に行うようにし、図４（Ｃ）に示すように、リサイズ処理については細かい処理単位に分割してＣＰＵ２５に実行させるようにする。この結果、２０クライアントへの画像データの配信性能は、図４（Ｂ）では３ｆｐｓであったものが、図４（Ｃ）では４ｆｐｓとなり、画像データの配信性能の低下を低減させることができる。また、図４（Ｃ）に示すように、細かい処理単位に分割して分散的にリサイズ処理を実行することで、図４（Ｂ）に示したように最新フレームの圧縮画像データが複数フレーム分連続して送信できないといった事態が避けられ、例えば、クライアントで表示される動画の連続性を保つことができる。もちろん、図４（Ｃ）に示すような場合には、図４（Ｂ）に示すような場合と比べてリサイズ処理により多くの時間を要するため、携帯電話端末６への縮小画像データの配信は、例えば、１秒間に１フレームであったものが、４秒間に１フレームといったようにフレームレートが低下することとなるのは言うまでもない。従って、リサイズ処理に比べてどの程度クライアントへの画像データの送信処理を優先させるかは、実際のシステムの設定状況において種々な値を設定すればよい。

図５には、本例の画像伝送装置２のＣＰＵ２５が実行する処理の流れ（概略）の一例を示してある。ここでは、図１に示したＰＣ端末４−１、４−２、及び携帯電話端末６という３クライアントからそれぞれ画像送信要求があった場合として説明する。

図５に示すように、ＣＰＵ２５は、まず、最新の圧縮画像データｎをＰＣ端末４−１、４−２へ送信する処理を行う（ステップＳ５０１ａ、ｂ）。次のステップでは、ＣＰＵ２５は携帯電話端末配信用の縮小画像データを生成するために、リサイズモジュール２５０により圧縮画像データｎのリサイズ処理を、図４（Ｃ）に示したように分割された１単位分（例えば、後述するＮ或いはＭブロック分）だけ行う（ステップＳ５０１ｃ）。ステップＳ５０１ｃの処理を終えると、次に、ＣＰＵ２５は、最新の圧縮画像データｎ＋１をＰＣ端末４−１、４−２へ送信する処理を行う（ステップＳ５０２ａ、ｂ）。そして、次のステップでは、リサイズモジュール２５０による圧縮画像データｎのリサイズ処理を再開し、リサイズ処理を次の１単位分だけ行う（ステップＳ５０２ｃ）。ステップＳ５０２ｃの処理を終えると、次に、ＣＰＵ２５は、最新の圧縮画像データｎ＋２をＰＣ端末４−１、４−２へ送信する処理を行う（ステップＳ５０３ａ、ｂ）。そして、次のステップでは、リサイズモジュール２５０による圧縮画像データｎのリサイズ処理を再開し、リサイズ処理を残りの１単位分だけ行う（ステップＳ５０３ｃ）。ここでは、ステップＳ５０１ｃ、５０２ｃ、５０３ｃの処理により圧縮画像データｎのリサイズ処理は完了し、縮小画像データｎが生成されるものとする。

ステップＳ５０３ｃの処理を終えると、次に、ＣＰＵ２５は、最新の圧縮画像データｎ＋３をＰＣ端末４−１、４−２へ送信する処理を行う（ステップＳ５０４ａ、ｂ）。そして、次のステップでは、ＣＰＵ２５は、ステップＳ５０１ｃ、５０２ｃ、５０３ｃにより生成された縮小画像データｎを携帯電話端末６へ送信する処理を行う（ステップＳ５０４ｃ）。次に、ＣＰＵ２５は、最新の圧縮画像データｎ＋４をＰＣ端末４−１、４−２へ送信する処理を行う（ステップＳ５０５ａ、ｂ）。そして、次のステップでは、ＣＰＵ２５は携帯電話端末配信用の縮小画像データを生成するために、リサイズモジュール２５０により最新の圧縮画像データｎ＋４のリサイズ処理を１単位分だけ行う（ステップＳ５０１ｃ）。以下、ＣＰＵ２５では、同様な処理が繰り返され、リサイズ処理に比べて画像データを送信する処理を優先させたＣＰＵ２５の実行処理の管理が実現される。なお、画像データの送信処理の詳細は、図３を用いて上述した通りである。また、図５においては説明の簡易化のために省略しているが、実際のＣＰＵ２５では、図５に示した処理以外にも画像伝送装置２の全体の機能を制御する処理等を適宜行っていることは言うまでもない。

図６には、優先度を設定してＣＰＵ２５の実行する処理を管理する場合におけるリサイズ処理の流れの具体例を示してある。なお、ここでは、図３を参照しながら図６に示したリサイズ処理を説明する。

まず、リサイズ処理の実行が許可されたか否かが判定される（ステップＳ６０１）。実行許可がない場合には（ステップＳ６０１でＮＯ）、処理待ち状態となる。実行が許可された場合には、送信データバッファ部２３２ｃから１ブロック分の圧縮画像データが読み出される（ステップＳ６０２）。ここで、１ブロックとは、１枚の画像データを複数ブロックに分割した場合の最小の単位を表す。例えば、ＪＰＥＧ方式では１枚の画像データを８画素×８画素からなるブロックに分割し、各ブロック毎に順に画像データの圧縮符号化処理を行い、圧縮画像データを復号する際にも各ブロック毎に復号処理を行っていく。

次に、読み出された１ブロック分の圧縮画像データの復号化処理を行う（ステップＳ６０３）。次に、復号化された１ブロック分の画像データの間引き処理を行い（ステップＳ６０４）、間引き処理後の１ブロック分の画像データをリサイズ用メモリ部２３３に書き込む（ステップＳ６０５）。次に、送信データバッファ部２３２ｃに記憶されている１枚の圧縮画像データのすべてのブロックに対して上述した復号化、間引き処理が行われたか否かが判定され（ステップＳ６０６）、まだ処理していないブロックがある場合には、ステップＳ６０７に進む。一方、すべてのブロックに対して上述した復号化、間引き処理が行われている場合には、ステップＳ６０８に進む。

ステップＳ６０７では、送信データバッファ部２３２ｃに記憶されている１枚の圧縮画像データのＮブロック分について上述した復号化、間引き処理が行われたか否かが判定される（ステップＳ６０７）。ここで、ＣＰＵ２５では、上述した復号化、間引き処理を実行したブロック数をカウントするカウンターを有している。また、ここで、Ｎは自然数を表し、Ｎの値は予め画像伝送装置２のメモリ（不図示）に記憶しておけばよい。ステップＳ６０７の判定の結果、まだＮブロック分について上述した復号化、間引き処理が行われていない場合は、カウンターの数値を１増やし、ステップＳ６０２に戻り、次の１ブロックに対して同様の処理が繰り返される。一方、ステップＳ６０７の判定の結果、既にＮブロック分について上述した復号化、間引き処理が行われている場合は、カウンターの数値を初期値１にリセットし、ステップ６０１に戻る。即ち、ここでは、一度リサイズ処理の実行が許可された場合には、Ｎブロック分のリサイズ処理を行い、実行後はリサイズ処理を停止し、ＣＰＵ２５に画像データの送信処理を実行させるようにして、ステップＳ６０１に示したように、再びリサイズ処理の実行が許可されるまではリサイズ処理は処理待ちの状態となる。

次に、ステップＳ６０６の判定の結果、すべてのブロックに対して上述した復号化、間引き処理が行われている場合には、ステップＳ６０８へ進み、リサイズ処理の実行が許可されたか否かが判定される（ステップＳ６０８）。実行が許可され、処理待ちの状態が解消された場合には、次に、リサイズ用メモリ部２３３から１ブロック分の画像データが読み出される（ステップＳ６０９）。次に、読み出された１ブロック分の画像データの圧縮符号化処理が行われ（ステップＳ６１０）、圧縮された１ブロック分の画像データを送信データバッファ２３２ｃに書き込む（ステップＳ６１１）。次に、リサイズ用メモリ部２３３に記憶されている１枚の画像データのすべてのブロックに対して上述した圧縮符号化処理が行われたか否かが判定され（ステップＳ６１２）、まだ処理していないブロックがある場合には、ステップＳ６１３に進む。一方、すべてのブロックに対して上記した圧縮符号化処理が行われている場合には、リサイズ処理は終了となる。

ステップＳ６１３では、送信データバッファ部２３２ｃに記憶されている１枚の圧縮画像データのＭブロック分について上述した圧縮符号化処理が行われたか否かが判定される（ステップＳ６１３）。ここで、Ｍは自然数であり、Ｍ＝Ｎであっても構わない。ステップＳ６１３の判定の結果、まだＭブロック分について上述した圧縮符号化処理が行われていない場合は、カウンターの数値を１増やし、ステップＳ６０９に戻り、次の１ブロックに対して同様の処理が繰り返される。一方、既にＭブロック分について上述した圧縮符号化処理が行われている場合は、カウンターの数値を初期値１にリセットし、ステップ６０８に戻る。

以上の処理により、画像データの送信処理を優先させ、例えば、リサイズ処理については段階的に実行していきながら、携帯電話端末配信用の縮小画像データの生成が行われる。なお、上述したＮやＭの値は、画像伝送装置２に接続されているクライアントの数に応じて変更されるように設定しておいてもよい。例えば、ＣＰＵ２５が図５に示したような順序で処理を実行していくような場合であれば、ＮやＭの値を小さく設定すればするほど、１枚の圧縮画像データをリサイズ処理するのに要する時間は長くなり、一方で、画像データの配信性能の低下は抑えられる。逆に、ＮやＭの値を大きく設定すればするほど、１枚の圧縮画像データをリサイズ処理するのに要する時間は短くなり、一方で、画像データの配信性能の低下は避けられなくなる。つまり、ここでは、ＮやＭの値を小さく設定することがリサイズ処理の優先度を低く設定することに対応し、ＮやＭの値を大きく設定することがリサイズ処理の優先度を高く設定することに対応する。

ここで、図７は、クライアント数と処理ブロック数（上述したＮやＭの値）との関係の一例を示すもので、このようなテーブルが画像伝送装置２のメモリに記憶されている。図７に示した例では、クライアント数の増加に応じて、処理ブロック数（上述したＮやＭの値）が増加するように設定されている。これは、ＣＰＵ２５が図５に示したような順序で処理を実行していく場合、クライアント数が多くなればなるほどリサイズ処理の処理待ち時間が長くなるため、図７に示した例では、１フレーム分の圧縮画像データのリサイズ処理に要する時間が長くならないようにクライアント数の増加に応じて処理ブロック数を増加させている。即ち、図５に示した例ではＰＣ端末が２台の場合についてのＣＰＵ２５の処理の流れであったが、更にＰＣ端末の数が増えれば、それに応じて図５のＳ５０１ａやＳ５０１ｂに相当する処理の数が増えることになり、リサイズ処理の処理待ち時間は増加する。従って、図７に示した例では、クライアント数の増加に応じて、１回のリサイズ処理（図５では、Ｓ５０１ｃや、Ｓ５０２ｃや、Ｓ５０３ｃに相当する処理）で実行する処理ブロック数を増加させている。一例として、図７に示したような設定とする場合、クライアント数が増加しても１フレーム分の圧縮画像データのリサイズ処理に要する時間をほぼ一定とすることが可能である。なお、図５に示したＣＰＵ２５の処理については、処理の順番を変えて、例えば、Ｓ５０１ａ、Ｓ５０１ｃ、Ｓ５０１ｂ、Ｓ５０２ｃ、・・・のようにすれば、リサイズ処理の処理待ち時間は減少することになり、また、例えば、Ｓ５０１ａ、Ｓ５０１ｂ、Ｓ５０２ａ、Ｓ５０２ｂ、Ｓ５０１ｃ、・・・のようにすれば、リサイズ処理の処理待ち時間は増加することになり、このようにしてもリサイズ処理の優先度を変えることができることは言うまでもない。

以上のように、本例の画像伝送装置２では、ＣＰＵ２５にリサイズモジュール２５０を追加する一方で、画像データの送信処理に比べてリサイズ処理の優先度を低く設定することで、画像データの配信性能が大きく低下することを防ぐことが可能である。

従って、本例の画像伝送装置２では、ＰＣ端末や携帯電話端末といった異なるクライアントからの画像データの送信要求に効果的に対応することができる。
なお、図８には、本例の一実施例に係る画像伝送装置２の他の構成例を示してある。図８においては、画像データバッファ部２３−１とリサイズモジュール２５１以外は図２に示した構成と同様であるため、詳細な説明は省略する。図８に示した画像伝送装置２では、Ａ／Ｄ変換部２１から出力された非圧縮の画像データ７０が画像データバッファ部２３−１に記憶される。本例のリサイズモジュール２５１では、この非圧縮の画像データ７０をリサイズ処理して携帯電話端末配信用の縮小画像データを生成するため、図２に示したリサイズモジュール２５０とは異なり、圧縮画像データを復号化する処理を省くことができる。一方で、非圧縮の画像データ７０を一時的に格納する必要があるため、画像データバッファ部２３−１は、図２に示した画像データバッファ部２３と比べると、より大きな記憶領域が必要となる。

ここで、本例では、クライアントであるＰＣ端末４−１、４−２や携帯電話端末６から画像送信要求があった場合には、画像伝送装置２は最新の画像データの送信を行う構成を示したが、他の構成例として、クライアントからの画像送信要求に時刻情報等の画像特定情報を付加するようにして、画像伝送装置２では、画像送信要求に付加された画像特定情報に基づき、画像データバッファ部２３に記憶されている過去の時刻の画像データを読み出し、当該画像データをクライアントに対して送信するような構成が用いられてもよい。この場合、画像伝送装置２では、例えば、圧縮画像データと共に、各圧縮画像データに関する画像特定情報も画像データバッファ部２３に記憶する機能を備える。

また、本例では、例えば、携帯電話端末６からの画像送信要求に対しては縮小画像データを送信する構成を示したが、他の構成例として、例えば、ＰＣ端末４−１、４−２や更にその他のクライアント（不図示）からの画像送信要求に対しても縮小画像データを送信するような構成が用いられてもよい。また、本例では、縮小画像データを送信するクライアントの識別コードを予め画像伝送装置２側に設定しておき、当該クライアントからの画像送信要求に対しては縮小画像データを送信する構成を示したが、他の構成例としては、クライアントが送信する画像送信要求に画像サイズを指定する情報を付加するようにして、画像伝送装置２では、当該指定内容に応じて、例えば、圧縮画像データを送信するのか、縮小画像データを送信するのかを決定するような構成が用いられてもよい。また、画像伝送装置２では、例えば、各クライアントが接続されているネットワーク３の伝送容量等に応じて、例えば、圧縮画像データを送信するのか、縮小画像データを送信するのかを決定するような構成が用いられてもよい。

また、本例の画像伝送装置２では、ＣＰＵ２５に画像データのリサイズ処理を行うリサイズモジュール２５０を追加する構成を示したが、他の構成例として、１画素当たりの階調数や、圧縮率や、圧縮符号化方式等の少なくともいずれか１つの処理により画像のデータ量や、画像サイズや、画像品質や、画像フォーマット等を変更するモジュールをＣＰＵ２５が実行する処理として追加するような構成が用いられてもよい。また、クライアントが送信する画像送信要求に画像のデータ量や、画像サイズや、画像品質や、画像フォーマットを指定する情報を付加するようにして、画像伝送装置２では、当該指定内容に応じた画像データを生成して、生成された画像データをクライアントに対して送信するような構成が用いられてもよい。

また、本例では、主に、１台の携帯電話端末６からの画像送信要求があった場合について説明したが、複数台の携帯電話端末から同時に画像送信要求があった場合には、例えば、図３に示した送信データバッファ部２３２ｃでは、リサイズ処理後の縮小画像データを複数の携帯電話端末に送信するようにして、複数の携帯電話端末すべてに縮小画像データを送信した後、リングバッファ部２３１に対して次の圧縮画像データの送信要求３０２ｃを送るような構成が用いられてもよい。

なお、本例の画像伝送装置２では、画像符号化部２２の機能により画像符号化手段が構成されており、画像データバッファ部２３の機能により画像データ記憶手段が構成されており、ネットワークＩ／Ｆ部２４やＣＰＵ２５の機能により画像送信要求受信手段が構成されており、ネットワークＩ／Ｆ部２４やＣＰＵ２５の機能により画像送信送信手段が構成されており、ＣＰＵ２５やリサイズモジュール２５０の機能により制御手段が構成されている。また、本例の画像伝送装置２では、ネットワークＩ／Ｆ部２４やＣＰＵ２５の機能により特定のクライアントか否かを判別する機能が構成されており、ＣＰＵ２５やリサイズモジュール２５０の機能によりリサイズ処理機能が構成されている。また、本例の画像伝送装置２では、ＣＰＵ２５の機能により処理管理機能が構成されている。

ここで、本発明に係る画像伝送装置や画像伝送システムなどの構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。また、本発明は、例えば、本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムや当該プログラムを記録する記録媒体などとして提供することも可能であり、また、種々な装置やシステムとして提供することも可能である。

また、本発明の適用分野としては、必ずしも以上に示したものに限られず、本発明は、種々な分野に適用することが可能なものである。
また、本発明に係る画像伝送装置や画像伝送システムなどにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウエア資源においてプロセッサがＲＯＭ（Read Only Memory）に格納された制御プログラムを実行することにより制御される構成が用いられてもよく、また、例えば当該処理を実行するための各機能手段が独立したハードウエア回路として構成されてもよい。

また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクやＣＤ（Compact Disc）−ＲＯＭ等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体からコンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。

本発明の一実施例に係る画像伝送システムの構成例を示す図である。 本発明の一実施例に係る画像伝送装置の構成例を示す図である。 本発明の一実施例に係る画像伝送装置の画像データ送信処理の一例を説明するための図である。 （Ａ）〜（Ｃ）は画像データの配信性能の変動の具体例を説明するための図である。 ＣＰＵが実行する処理の流れの一例を示す図である。 リサイズ処理の流れの一例を示す図である。 クライアント数とリサイズ処理の処理単位数との関係の一例を示す図である。 本発明の一実施例に係る画像伝送装置の構成例を示す図である。 画像伝送装置の構成例を示す図である。 画像伝送装置の構成例を示す図である。

符号の説明

１：カメラ、２：画像伝送装置、３：ネットワーク、４−１、４−２：ＰＣ端末、５：携帯電話網、６：携帯電話端末

Claims (1)

1. 入力された画像データを圧縮符号化処理する画像符号化手段と、
   該画像符号化手段からの圧縮画像データを記憶する画像データ記憶手段と、
   少なくとも１つのクライアントから送信される画像送信要求を受信する画像送信要求受信手段と、
   前記クライアントからの画像送信要求に基づいて前記画像データ記憶手段に記憶された圧縮画像データを当該クライアントに対して送信する画像送信手段と、
   前記各手段を制御する制御手段と、を備えた画像伝送装置であって、
   前記制御手段は、前記画像送信要求から前記クライアントのうち特定のクライアントか否かを判別する機能と、
   前記特定のクライアントである場合には前記画像データ記憶手段に記憶された圧縮画像データに対して復号し、該復号した画像データに間引き処理を施し、これを再圧縮処理を行うことによるリサイズ処理してリサイズ画像データを生成するリサイズ処理機能を備え、
   前記リサイズ画像データを複数のブロックまたはフレームに分割し、該分割した単位毎に前記特定のクライアントに対して繰り返しの送信動作を行うように制御するものであり、
   さらに、前記制御手段は、予めクライアント数と処理ブロック数に応じたリサイズ処理の順番を決定するメモリテーブルを備え、
   複数のクライアントから画像送信要求がされた場合に、クライアントの数に応じて処理ブロック数を可変してリサイズ処理を行うことで、前記複数のクライアントへの送信の順番を可変し、
   前記画像送信手段の制御を前記リサイズ処理機能の実行に比べて優先することを特徴とする画像伝送装置。