情報処理装置および情報処理方法
【課題】画像データと副画像データを含むファイルを送信する際に、送信量の増加を抑える情報処理装置を提供する。
【解決手段】画像を表す画像データと画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを格納し、該ファイルから副画像データを削除して第１のファイルを生成し、画像データと副画像データを比較して副画像が画像のどの領域に基づいて生成されたかを検出し、該検出された領域の情報と副画像のサイズとを含む第２のファイルを生成し、ファイルを送信する代わりに、第１のファイルと第２のファイルを送信する。
【解決手段】画像を表す画像データと画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを格納し、該ファイルから副画像データを削除して第１のファイルを生成し、画像データと副画像データを比較して副画像が画像のどの領域に基づいて生成されたかを検出し、該検出された領域の情報と副画像のサイズとを含む第２のファイルを生成し、ファイルを送信する代わりに、第１のファイルと第２のファイルを送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の画像データを含むファイルを処理する情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
複数の画像データを１つのファイルにまとめて取り扱いたいというアイデアは、従来からある。特許文献１には、複数の画像データの関連情報を容易に参照可能な画像記録方法について記載されている。特許文献２には、１回の記録動作で生成する記録用の圧縮画像データを独立した画像データの結合体とする画像記録方法が記載されている。
【０００３】
また、サムネイル画像を含む画像データの転送量の削減のアイデアも提案されている。特許文献３には、主画像とサムネイル画像を比較し、主画像とサムネイル画像とのサイズ差が小さいときは、サムネイル画像を添付せずに主画像のファイルを転送する転送方法が記載されている。特許文献４には、画像サーバが、携帯電話からの電子メールに添付された画像ファイルを受信し、その受信した画像からサムネイル画像を生成し、受信した画像にサムネイルを付加しサムネイル付き画像データを生成する転送方法が記載されている。
【０００４】
ここで、特許文献１や特許文献２と同様に、主画像とモニタ表示用のサムネイル画像（副画像）とが１つのファイルになった画像ファイルを考える。従来のＥｘｉｆファイルのサムネイル画像は、６４キロバイト以上の画像データを保持することができなかった。しかしながら、このような画像ファイルでは、Ｅｘｉｆファイルのサムネイル画像に比べて、より大きいサイズで高画質のモニタ表示用の画像データを副画像として保持することが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１６７０６７号公報
【特許文献２】特開平１１―２６６４２０号公報
【特許文献３】特開２００３−２０４５００号公報
【特許文献４】特開２００５―１１７２２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、主画像データ（単に、画像データという）とモニタ表示用の副画像データを１つのファイルで保持するようなフォーマットの画像ファイルを装置の外部に送信することを考える。そのような場合、従来の主画像データのみのファイルの転送を行うときに比べて、副画像データの分だけ送信量が増加してしまう。
【０００７】
上記の点に鑑み、本発明は、画像データと副画像データを含むファイルを送信する際に、送信量の増加を抑える情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る情報処理装置は、画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する送信手段を備える情報処理装置であって、前記ファイルを格納する格納手段と、前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成手段と、前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成手段とを有し、前記送信手段は、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、画像データと副画像データを含むファイルを送信する際に、副画像データを送信しないので送信量の増加を抑えることができる。
【図面の簡単な説明】
【００１０】
【図１】本実施例におけるシステムの構成の概要を示す図である。
【図２】本実施例において用いられる装置の構成の概要を示す図である。
【図３】送信処理されるファイル構成を示す図である。
【図４】クリッピング領域を説明する図である。
【図５】送信元の装置において実行される処理の手順を示す図である。
【図６】副画像再生情報ファイルの構成を示す図である。
【図７】クリッピング領域の取得を説明する図である。
【図８】送信されるファイル構成を示す図である。
【図９】送信先の装置において実行される処理の手順を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本発明を実施するための形態について、図面を参照しながら詳しく説明する。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。
【００１２】
図１は、本実施例で説明する情報処理システムの構成の概要を示している。本実施例では、転送元であるＰＣ１００から、ネットワークを経由して、転送先である画像サーバ１１０に、後述する１つのファイルに画像データと副画像データとを含むファイルを転送する場合を考える。なお、本実施例では、ＰＣ１００と画像サーバ１１０間は、無線ネットワークとする。しかしながら、両者間でファイルの転送が可能な状態であれば、ネットワークの形態は、これに限定されない。
【００１３】
図２は、本実施例において用いられる情報処理装置の構成を示すブロック図である。情報処理装置であるＰＣ１００は、画像サーバ１１０とネットワークを介して双方向通信可能に接続されている。ＰＣ１００は、基本ソフトウェアであるＯＳ等のプログラムに基づき、ＰＣ１００内の各構成を制御するＣＰＵ１０１と、ＰＣ１００の起動時に実行されるプログラム等を記録するＲＯＭ１０２とを含む。また、ＰＣ１００は、プログラムの実行に必要なワークエリアのバッファエリアとして利用されるＲＡＭ１０３と、ＯＳやアプリケーションソフトや各種のデータを格納するＨＤ（ハードディスク）１０４と、各種情報を視覚的に表示するモニタ１０５とを含む。また、ＰＣ１００は、キーボードやマウス等の入力デバイスを介したユーザによる入力操作を検出して、その操作に応じた制御を実行する操作制御部１０６と、モニタ１０５上での各種情報の表示を制御する表示制御部１０７とを含む。また、ＰＣ１００は、画像サーバ１１０等の外部の装置との間で各種データの送受信を行なうためのＩＦ（インタフェース）１０８とを含む。以上の構成は、バス１０９を介して互いにデータ送受信可能に接続されている。また、特に図示しないが、ＰＣ１００は、例えば、ＣＤ又はＤＶＤのデータ読み出し／書き込みに対応した光ディスクドライブ、キーボード、マウス等の入力デバイス等も含む。画像サーバ１１０の構成も図２に示す構成と同じである。
【００１４】
図３は、主画像データと１枚以上の副画像データが格納され、主画像データから副画像データが生成可能であるファイルの構成を示す図である。以下、説明上、そのようなファイルを、複数画像格納ファイルという。複数画像格納ファイル３００は、ヘッダ部３１とデータ部３２の２つから大きく構成されている。ヘッダ部３１は、ファイルフォーマットを識別するためのフォーマット識別ＩＤ３１１、ファイル中に含まれる副画像データ数３１２を含む。また、ヘッダ部３１は、主画像データの先頭アドレスを示す主画像ポインタ３１３、副画像クリッピング情報３１４、副画像データの先頭アドレスを示す副画像ポインタ３１５を含む。
【００１５】
フォーマット識別ＩＤ３１１は、複数画像格納ファイル３００の先頭にアスキーコードで埋め込まれている。例えば、６バイトの文字列「＄＄ＭＩ＄＄」が本フォーマットのフォーマット識別ＩＤとすると、ファイル解析を行う際は、ファイルの先頭から６バイトが「＄＄ＭＩ＄＄」となっているか否かが判定される。その結果、容易に複数画像格納フォーマットか否かが区別される。
【００１６】
副画像クリッピング情報３１４は、主画像データから副画像データを生成する際に、主画像中のどの領域をクリッピング（指定）して副画像領域としたかの情報を表すものである。副画像クリッピング情報３１４は、図４で示すように、クリッピング始点座標とクリッピング幅とクリッピング高さとを含んでいる。本実施例において、クリッピング領域とは、図４に示すように、主画像の少なくとも一部である矩形領域である。クリッピング始点座標は、主画像領域に対するクリッピング領域の左上の座標を表す。また、クリッピング幅は、その始点座標からのクリッピング領域の幅を表す。また、クリッピング高さは、その始点座標からのクリッピング領域の高さを表す。
【００１７】
ここで、副画像が主画像からクリッピングされた領域を縮小して得られた領域である場合には、副画像クリッピング情報３１４は、特に指定されている必要はない。そのような場合に、副画像クリッピング情報３１４には、未設定を意味する情報を格納するようにしても良い。または、副画像クリッピング情報３１４自体がなくてもよい。副画像クリッピング情報３１４と副画像ポインタ３１５は、各副画像毎に存在する。図３に示す例では、副画像１と副画像２の２枚の副画像が存在するため、副画像クリッピング情報３１４と副画像ポインタ３１５の組が、２組格納されている。
【００１８】
データ部３２には、主画像および副画像の画像データが格納されている。本実施例例では、主画像データおよび副画像データは、ＪＰＥＧフォーマットとする。その場合に、主画像データや副画像データ内のＪＰＥＧヘッダの情報から、主画像データの縦横のピクセル数および各副画像データの縦横のピクセル数を取得することができる。
【００１９】
次に、複数画像格納ファイル３００の送信元であるＰＣ１００での処理の手順を図５を用いて説明する。図５に示す処理は、例えば、ＰＣ１００におけるＣＰＵ１０１によって実行される。
【００２０】
まず、ユーザから複数画像格納ファイル３００の送信指示があると、削除する副画像の情報を格納するための副画像再生情報ファイル６００を生成する（Ｓ５０１）。本実施例において、副画像再生情報ファイル６００を第２のファイルとし、その第２のファイルを生成するＳ５０１の処理を第２の生成処理とする。第１のファイルと第１の生成処理については、後述する。副画像再生情報ファイル６００は、図６に示すように、副画像データ数６０１と副画像サイズ情報６０２と副画像クリッピング情報６０３と副画像圧縮パラメータ６０４とを含む。副画像データ数６０１は、削除した副画像数を表す。副画像サイズ情報６０２は、削除した副画像の縦横のサイズ（ピクセル数）を表す。副画像クリッピング情報６０３は、上述したとおりである。副画像圧縮パラメータ６０４は、副画像を例えばＪＰＥＧデータに変換した際の画像品位を決定するパラメータを表す。本実施例では、副画像圧縮パラメータとして、量子化テーブルと各色のサンプリング数の２つを用いる。両者とも、ＪＰＥＧファイル内のヘッダから取得可能な情報である。副画像サイズ情報６０２と副画像クリッピング情報６０３と副画像圧縮パラメータ６０４の３項目は、副画像毎に用意される。図６に示す例では、削除した副画像が副画像１と副画像２の２枚であり、それぞれに対して、６０２から６０４の項目が存在する。Ｓ５０１では、複数画像格納ファイル３００の副画像データ数３１２を参照し、副画像数に対応した大きさの副画像再生情報ファイル６００を作成する。この時点では、副画像再生情報ファイル６００内の副画像データ数６０１だけが設定されており、その他の項目は未設定状態である。後述するフローに従って、それらの未設定項目に対して情報が設定されていく。
【００２１】
続いて、未処理の副画像についての副画像クリッピング情報とその副画像を表す副画像データを複数画像格納ファイル３００から取得する（Ｓ５０２）。Ｓ５０３では、Ｓ５０２にて、副画像クリッピング情報を取得していたか否かが判定される。ここで、取得していたと判定された場合に、Ｓ５０４に進み、Ｓ５０２で取得した副画像クリッピング情報を、副画像再生情報ファイル６００の副画像クリッピング情報６０３に格納する。一方、Ｓ５０３で副画像クリッピング情報を取得していなかった（即ち、未設定状態であった）と判定された場合に、Ｓ５０５に進み、主画像の縦横のアスペクト比と副画像の縦横のアスペクト比が等しいか否かが判定される。これは、上述のＪＰＥＧヘッダから主画像データと副画像データの縦横のピクセル数から判定するようにしても良い。
【００２２】
Ｓ５０５にてアスペクト比が等しいと判定された場合に、Ｓ５０６にて主画像領域全体をそのまま縮小して副画像が生成されたとみなす。つまり、副画像クリッピング情報として、クリッピング始点座標を主画像の左上の座標（０、０）とし、クリッピング幅と高さを主画像の横と縦のピクセル数とする。それらの情報を副画像再生情報ファイル６００の副画像クリッピング情報６０３に保存する。一方、Ｓ５０５にてアスペクト比が等しくないと判定された場合には、Ｓ５０７に進む。
【００２３】
以下、図７を用いて、Ｓ５０７における副画像クリッピング領域の取得について説明する。前提として、図７の（ａ）に示すような主画像領域（幅Ｍｗ、高さＭｈ）と副画像領域（幅Ｓｗ、高さＳｈ）である場合を考える。
【００２４】
まず、図６の（ｂ）に示すように、主画像のアスペクト比を保ったまま、主画像領域を副画像領域が収まる最小サイズまで縮小して縮小主画像領域を生成する。本例では、（Ｓｗ／Ｍｗ）＞（Ｓｈ／Ｍｈ）なので、幅がＳｗのサイズになるまで、主画像領域をアスペクト比を保ちつつ縮小して縮小主画像領域を作成する。その場合、縮小率はＳｗ／Ｍｗとなり、図６の（ｃ）に示すように、縮小主画像領域の幅はＭｗ×Ｓｗ／ＭｗでＳｗと等しくなり、高さはＭｈ×Ｓｗ／Ｍｗとなる。
【００２５】
次に、この縮小主画像領域に対して、図６の（ｄ）に示すように、副画像領域でテンプレートマッチング処理を行い、縮小主画像領域のどの領域から実際に副画像領域がクリッピングされたかを検出する。図６の（ｅ）は、縮小主画像領域の左上を原点Ｐ０（０、０）とした場合に、Ｐ１（０、ｔｙ）がクリッピング始点座標として検出されたことを示している。
【００２６】
最後に、縮小主画像領域上のクリッピング領域が実際の主画像上ではどの領域に相当するかを、縮小主画像領域をもとの主画像領域の大きさまで拡大して算出する。その場合、拡大率は、図６の（ｆ）に示すように、Ｍｗ／Ｓｗとなる。これにより、副画像領域を拡大して得られた拡大副画像領域が、主画像に対する副画像のクリッピング領域となる。即ち、図６の（ｇ）のようにクリッピング始点座標Ｐ１’（０、ｔｙ×Ｍｗ／Ｓｗ）、クリッピング幅Ｍｗ、クリッピング高さＳｈ×Ｍｗ／Ｓｗとなる。そして、Ｓ５０７で算出した副画像のクリッピング領域の情報を、副画像再生情報ファイル６００の副画像クリッピング情報６０３に保存する（Ｓ５０８）。
【００２７】
以上により、Ｓ５０４、Ｓ５０６、Ｓ５０８のいずれかを経由して、Ｓ５０９に処理が進む。Ｓ５０９では、取得された副画像の縦横のピクセル数を、副画像再生情報ファイル６００内の副画像サイズ情報６０２に格納する。Ｓ５１０では、副画像の圧縮パラメータを副画像データのヘッダから取得し、副画像再生情報ファイル６００の副画像圧縮パラメータ６０４に格納する。Ｓ５１１にて、複数画像格納ファイル３００内の全ての副画像に対して、Ｓ５０２〜Ｓ５１０の処理が行われたかが判定される。ここで、全副画像に対して処理が終了したと判定された場合に、Ｓ５１２に進み、処理が終了していない（即ち、未処理の副画像が存在する）と判定された場合に、再び、Ｓ５０２に戻る。
【００２８】
ここまでの一連の処理により、副画像再生情報ファイル６００に必要な情報が全て保存されたことになる。Ｓ５１２にて、送信用ファイル（第１のファイルとする）を生成する（第１の生成処理とする）。送信用ファイルは、複数画像格納ファイル３００から副画像データ部分を単純に削除して生成される。図８は、図３に示す複数画像格納ファイル３００から、送信用ファイル８００を生成した例である。図３に示す複数画像格納ファイル３００から副画像１データと副画像２データが単純に削除されている。最後に、作成された送信用ファイル８００と副画像再生情報ファイル６００の２ファイルを送信先に送信し（Ｓ５１３）、送信元での処理を終了する。
【００２９】
次に、図９を用いて、送信先である画像サーバ１１０での処理の手順を説明する。図９に示す処理は、例えば、画像サーバ１１０におけるＣＰＵ１０１によって実行される。まず、Ｓ９０１で、送信元ＰＣ１００から送られてきた送信用ファイル８００と副画像再生情報ファイル６００の２ファイルを受信する。次に、副画像再生情報ファイル６００を参照し、まだ、再生成が行われていない副画像に対応した副画像サイズ情報６０２、副画像クリッピング情報６０３、副画像圧縮パラメータ６０４の情報を取得する（Ｓ９０２）。続いて、送信用ファイル８００内の主画像データの主画像領域に対して、取得された副画像クリッピング情報６０３を用いて副画像領域を抽出する（Ｓ９０３）。
【００３０】
次に、Ｓ９０３で抽出された副画像領域をＳ９０２で取得した副画像サイズ情報６０２の縦と横のピクセル数となるように縮小処理して縮小副画像領域を生成する（Ｓ９０４）。Ｓ９０４で生成された縮小副画像領域を、Ｓ９０２で取得した副画像圧縮パラメータ６０４でＪＰＥＧ等の圧縮を行い、圧縮後の画像データを再生成された副画像データとする。再生成された副画像データは、生成後、各副画像毎に再生成副画像ファイルとして保存される（Ｓ９０５）。
【００３１】
Ｓ９０６で、副画像再生情報ファイル６００に記述された全ての副画像に対して、Ｓ９０２〜Ｓ９０５の処理が行われたかが判定される。ここで、全ての副画像に対して処理が終了したと判定された場合に、Ｓ９０７に進み、未処理の副画像が存在すると判定された場合に、再び、Ｓ９０２に戻る。
【００３２】
ここまでの処理が終了すると、再生成副画像ファイルが副画像の数だけ生成されることになる。最後に、再生成副画像ファイルを作成した順番で送信用ファイル８００の最後尾に、副画像データとして付加していき、１つのファイルを生成する。このときに生成されたファイルを第３のファイルとし、生成する処理を第３の生成処理とする。以上の作業により、図８で示した送信用ファイル８００は、副画像データが追加されて、図３に示す複数画像格納ファイル３００の形式に戻る。また、再生成された副画像データは、演算誤差などの影響により、完全に同一のものになるとは限らないため、再生後のファイル内での各副画像の副画像ポインタを正しい値に更新し（Ｓ９０７）、送信先である画像サーバ１１０での処理を終了する。
【００３３】
以上の処理により、副画像データの再生成情報を送信先に送信することで、送信先で得られるファイル内に含まれる副画像データのサイズや品位についての情報を保持したまま、ファイル送信時のデータ転送量を削減することが可能となる。なお、本実施例では、複数画像格納ファイル３００に格納されている主画像データおよび副画像データのフォーマットをＪＰＥＧ以外の一般的な画像データフォーマットとしても良い。また、ＢＭＰ形式等の非圧縮の画像フォーマットであるならば、圧縮パラメータは特に必要ない。
【００３４】
また、送信用ファイル８００のヘッダ部分は、本実施例では変更していないが、ヘッダ内の副画像データ数を０と設定して、主画像のみが存在するファイルとして、送信用ファイル８００を生成してもよい。また、送信時にヘッダを変更した場合には、送信先でのファイル再生時に、ヘッダ情報を正しい値に戻すようにする。
【００３５】
また、本実施例では、副画像再生情報を転送するために、副画像再生情報ファイル６００を使用しているが、副画像再生情報を送信用ファイル８００内に組み込んでも良い。つまり、送信先で、副画像再生情報を取得できるような仕組みになっていれば良い。
【００３６】
また、副画像圧縮パラメータ６０４は、主画像の圧縮パラメータと同じであれば、主画像のパラメータを用いるようにしても良い。具体的には、Ｓ５１０にて主画像データ内に保存されているＪＰＥＧヘッダ内の圧縮パラメータと副画像データ内のＪＰＥＧヘッダ内に保存されている圧縮パラメータを比較する。その場合に同じであれば、副画像再生情報ファイル６００の副画像圧縮パラメータ６０４には、主画像データと同じであることを示すＩＤを設定する。送信先でのＳ９０５の処理では、副画像圧縮パラメータ６０４が主画像データと同じであることを示すＩＤの場合には、主画像データのＪＰＥＧヘッダから圧縮パラメータを取得し、そのパラメータで縮小副画像領域をＪＰＥＧ圧縮すればよい。このように、圧縮パラメータを共有することにより、送信データ量をさらに削減することが可能である。
【００３７】
本実施例は、送信（または転送）速度が遅い、通信コストが高いといった場合に、より効果が高い。従って、通信経路の速度やコストによって、本実施例の送信方法と通常の送信方法の２つを使い分けるようにしてもよい。具体的には、送信速度が遅い場合や、通信コストが高い場合には、本実施例での送信方法を使用するようにする。また、例えば、送信前に通信経路を検出し、有線ＬＡＮやＵＳＢの場合には、通常の送信方法を用い、無線ＬＡＮやＩｒＤＡによる送信では、本実施例の送信方法を用いる。また、通信コストに注目すると、送信前に通信経路を検出し、携帯電話からの送信である場合には、本実施例の送信方法を用い、携帯電話以外からの送信である場合には、通常の送信方法を用いるということが考えられる。
【００３８】
また、複数画像格納ファイル３００の生成時に、主画像データから副画像データ作成時に使用した縮小アルゴリズム名を副画像の情報として、圧縮パラメータと同様に、複数画像格納ファイル３００内のヘッダ部３１に格納するようにしても良い。その縮小アルゴリズム名を副画像再生情報ファイル６００に含めて送信し、送信先のＳ９０４での縮小処理において、この名称の縮小アルゴリズムの処理を行うことが可能な場合には、その名称の縮小アルゴリズムで縮小処理を行う。その場合、縮小処理アルゴリズムとして、ニアレストネイバー法、バイリニア法、バイキュービック法など多くの手法が一般的に知られており、アルゴリズムの違いによって出力結果も微妙に異なる。このため、送信元にある複数画像格納ファイル３００内の副画像データの生成時の縮小処理と処理を合わせることで、オリジナルの副画像データにより近い再生成副画像データを作成することが可能となる。
【００３９】
また、本実施例では、複数画像格納ファイル３００の１ファイルを送信する場合の例を説明したが、複数の複数画像格納ファイル３００を送信する場合も、実施例で示した処理を送信したいファイル数分だけ繰り返す。このとき、送信したい複数画像格納ファイル３００のファイル数が一定数以上の場合だけ、本実施例の送信方法で送信を行い、そうでない場合には、通常の送信方法で送信するようにしても良い。また、送信したい複数画像格納ファイル３００に格納されている各副画像データの合計サイズが一定サイズ以上の場合にのみ本実施例の送信方法を用い、そうでない場合には、通常の送信方法を用いるようにしても良い。また、主画像データサイズに対する各副画像データの合計サイズが一定割合以上の場合にのみ本実施例の送信方法を用い、そうでない場合には、通常の送信方法を用いるようにしても良い。
【技術分野】
【０００１】
本発明は、複数の画像データを含むファイルを処理する情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
複数の画像データを１つのファイルにまとめて取り扱いたいというアイデアは、従来からある。特許文献１には、複数の画像データの関連情報を容易に参照可能な画像記録方法について記載されている。特許文献２には、１回の記録動作で生成する記録用の圧縮画像データを独立した画像データの結合体とする画像記録方法が記載されている。
【０００３】
また、サムネイル画像を含む画像データの転送量の削減のアイデアも提案されている。特許文献３には、主画像とサムネイル画像を比較し、主画像とサムネイル画像とのサイズ差が小さいときは、サムネイル画像を添付せずに主画像のファイルを転送する転送方法が記載されている。特許文献４には、画像サーバが、携帯電話からの電子メールに添付された画像ファイルを受信し、その受信した画像からサムネイル画像を生成し、受信した画像にサムネイルを付加しサムネイル付き画像データを生成する転送方法が記載されている。
【０００４】
ここで、特許文献１や特許文献２と同様に、主画像とモニタ表示用のサムネイル画像（副画像）とが１つのファイルになった画像ファイルを考える。従来のＥｘｉｆファイルのサムネイル画像は、６４キロバイト以上の画像データを保持することができなかった。しかしながら、このような画像ファイルでは、Ｅｘｉｆファイルのサムネイル画像に比べて、より大きいサイズで高画質のモニタ表示用の画像データを副画像として保持することが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１６７０６７号公報
【特許文献２】特開平１１―２６６４２０号公報
【特許文献３】特開２００３−２０４５００号公報
【特許文献４】特開２００５―１１７２２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、主画像データ（単に、画像データという）とモニタ表示用の副画像データを１つのファイルで保持するようなフォーマットの画像ファイルを装置の外部に送信することを考える。そのような場合、従来の主画像データのみのファイルの転送を行うときに比べて、副画像データの分だけ送信量が増加してしまう。
【０００７】
上記の点に鑑み、本発明は、画像データと副画像データを含むファイルを送信する際に、送信量の増加を抑える情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る情報処理装置は、画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する送信手段を備える情報処理装置であって、前記ファイルを格納する格納手段と、前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成手段と、前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成手段とを有し、前記送信手段は、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信することを特徴とする。
【発明の効果】
【０００９】
本発明によれば、画像データと副画像データを含むファイルを送信する際に、副画像データを送信しないので送信量の増加を抑えることができる。
【図面の簡単な説明】
【００１０】
【図１】本実施例におけるシステムの構成の概要を示す図である。
【図２】本実施例において用いられる装置の構成の概要を示す図である。
【図３】送信処理されるファイル構成を示す図である。
【図４】クリッピング領域を説明する図である。
【図５】送信元の装置において実行される処理の手順を示す図である。
【図６】副画像再生情報ファイルの構成を示す図である。
【図７】クリッピング領域の取得を説明する図である。
【図８】送信されるファイル構成を示す図である。
【図９】送信先の装置において実行される処理の手順を示す図である。
【発明を実施するための形態】
【００１１】
以下に、本発明を実施するための形態について、図面を参照しながら詳しく説明する。なお、同一の構成要素には同一の参照番号を付して、説明を省略する。
【００１２】
図１は、本実施例で説明する情報処理システムの構成の概要を示している。本実施例では、転送元であるＰＣ１００から、ネットワークを経由して、転送先である画像サーバ１１０に、後述する１つのファイルに画像データと副画像データとを含むファイルを転送する場合を考える。なお、本実施例では、ＰＣ１００と画像サーバ１１０間は、無線ネットワークとする。しかしながら、両者間でファイルの転送が可能な状態であれば、ネットワークの形態は、これに限定されない。
【００１３】
図２は、本実施例において用いられる情報処理装置の構成を示すブロック図である。情報処理装置であるＰＣ１００は、画像サーバ１１０とネットワークを介して双方向通信可能に接続されている。ＰＣ１００は、基本ソフトウェアであるＯＳ等のプログラムに基づき、ＰＣ１００内の各構成を制御するＣＰＵ１０１と、ＰＣ１００の起動時に実行されるプログラム等を記録するＲＯＭ１０２とを含む。また、ＰＣ１００は、プログラムの実行に必要なワークエリアのバッファエリアとして利用されるＲＡＭ１０３と、ＯＳやアプリケーションソフトや各種のデータを格納するＨＤ（ハードディスク）１０４と、各種情報を視覚的に表示するモニタ１０５とを含む。また、ＰＣ１００は、キーボードやマウス等の入力デバイスを介したユーザによる入力操作を検出して、その操作に応じた制御を実行する操作制御部１０６と、モニタ１０５上での各種情報の表示を制御する表示制御部１０７とを含む。また、ＰＣ１００は、画像サーバ１１０等の外部の装置との間で各種データの送受信を行なうためのＩＦ（インタフェース）１０８とを含む。以上の構成は、バス１０９を介して互いにデータ送受信可能に接続されている。また、特に図示しないが、ＰＣ１００は、例えば、ＣＤ又はＤＶＤのデータ読み出し／書き込みに対応した光ディスクドライブ、キーボード、マウス等の入力デバイス等も含む。画像サーバ１１０の構成も図２に示す構成と同じである。
【００１４】
図３は、主画像データと１枚以上の副画像データが格納され、主画像データから副画像データが生成可能であるファイルの構成を示す図である。以下、説明上、そのようなファイルを、複数画像格納ファイルという。複数画像格納ファイル３００は、ヘッダ部３１とデータ部３２の２つから大きく構成されている。ヘッダ部３１は、ファイルフォーマットを識別するためのフォーマット識別ＩＤ３１１、ファイル中に含まれる副画像データ数３１２を含む。また、ヘッダ部３１は、主画像データの先頭アドレスを示す主画像ポインタ３１３、副画像クリッピング情報３１４、副画像データの先頭アドレスを示す副画像ポインタ３１５を含む。
【００１５】
フォーマット識別ＩＤ３１１は、複数画像格納ファイル３００の先頭にアスキーコードで埋め込まれている。例えば、６バイトの文字列「＄＄ＭＩ＄＄」が本フォーマットのフォーマット識別ＩＤとすると、ファイル解析を行う際は、ファイルの先頭から６バイトが「＄＄ＭＩ＄＄」となっているか否かが判定される。その結果、容易に複数画像格納フォーマットか否かが区別される。
【００１６】
副画像クリッピング情報３１４は、主画像データから副画像データを生成する際に、主画像中のどの領域をクリッピング（指定）して副画像領域としたかの情報を表すものである。副画像クリッピング情報３１４は、図４で示すように、クリッピング始点座標とクリッピング幅とクリッピング高さとを含んでいる。本実施例において、クリッピング領域とは、図４に示すように、主画像の少なくとも一部である矩形領域である。クリッピング始点座標は、主画像領域に対するクリッピング領域の左上の座標を表す。また、クリッピング幅は、その始点座標からのクリッピング領域の幅を表す。また、クリッピング高さは、その始点座標からのクリッピング領域の高さを表す。
【００１７】
ここで、副画像が主画像からクリッピングされた領域を縮小して得られた領域である場合には、副画像クリッピング情報３１４は、特に指定されている必要はない。そのような場合に、副画像クリッピング情報３１４には、未設定を意味する情報を格納するようにしても良い。または、副画像クリッピング情報３１４自体がなくてもよい。副画像クリッピング情報３１４と副画像ポインタ３１５は、各副画像毎に存在する。図３に示す例では、副画像１と副画像２の２枚の副画像が存在するため、副画像クリッピング情報３１４と副画像ポインタ３１５の組が、２組格納されている。
【００１８】
データ部３２には、主画像および副画像の画像データが格納されている。本実施例例では、主画像データおよび副画像データは、ＪＰＥＧフォーマットとする。その場合に、主画像データや副画像データ内のＪＰＥＧヘッダの情報から、主画像データの縦横のピクセル数および各副画像データの縦横のピクセル数を取得することができる。
【００１９】
次に、複数画像格納ファイル３００の送信元であるＰＣ１００での処理の手順を図５を用いて説明する。図５に示す処理は、例えば、ＰＣ１００におけるＣＰＵ１０１によって実行される。
【００２０】
まず、ユーザから複数画像格納ファイル３００の送信指示があると、削除する副画像の情報を格納するための副画像再生情報ファイル６００を生成する（Ｓ５０１）。本実施例において、副画像再生情報ファイル６００を第２のファイルとし、その第２のファイルを生成するＳ５０１の処理を第２の生成処理とする。第１のファイルと第１の生成処理については、後述する。副画像再生情報ファイル６００は、図６に示すように、副画像データ数６０１と副画像サイズ情報６０２と副画像クリッピング情報６０３と副画像圧縮パラメータ６０４とを含む。副画像データ数６０１は、削除した副画像数を表す。副画像サイズ情報６０２は、削除した副画像の縦横のサイズ（ピクセル数）を表す。副画像クリッピング情報６０３は、上述したとおりである。副画像圧縮パラメータ６０４は、副画像を例えばＪＰＥＧデータに変換した際の画像品位を決定するパラメータを表す。本実施例では、副画像圧縮パラメータとして、量子化テーブルと各色のサンプリング数の２つを用いる。両者とも、ＪＰＥＧファイル内のヘッダから取得可能な情報である。副画像サイズ情報６０２と副画像クリッピング情報６０３と副画像圧縮パラメータ６０４の３項目は、副画像毎に用意される。図６に示す例では、削除した副画像が副画像１と副画像２の２枚であり、それぞれに対して、６０２から６０４の項目が存在する。Ｓ５０１では、複数画像格納ファイル３００の副画像データ数３１２を参照し、副画像数に対応した大きさの副画像再生情報ファイル６００を作成する。この時点では、副画像再生情報ファイル６００内の副画像データ数６０１だけが設定されており、その他の項目は未設定状態である。後述するフローに従って、それらの未設定項目に対して情報が設定されていく。
【００２１】
続いて、未処理の副画像についての副画像クリッピング情報とその副画像を表す副画像データを複数画像格納ファイル３００から取得する（Ｓ５０２）。Ｓ５０３では、Ｓ５０２にて、副画像クリッピング情報を取得していたか否かが判定される。ここで、取得していたと判定された場合に、Ｓ５０４に進み、Ｓ５０２で取得した副画像クリッピング情報を、副画像再生情報ファイル６００の副画像クリッピング情報６０３に格納する。一方、Ｓ５０３で副画像クリッピング情報を取得していなかった（即ち、未設定状態であった）と判定された場合に、Ｓ５０５に進み、主画像の縦横のアスペクト比と副画像の縦横のアスペクト比が等しいか否かが判定される。これは、上述のＪＰＥＧヘッダから主画像データと副画像データの縦横のピクセル数から判定するようにしても良い。
【００２２】
Ｓ５０５にてアスペクト比が等しいと判定された場合に、Ｓ５０６にて主画像領域全体をそのまま縮小して副画像が生成されたとみなす。つまり、副画像クリッピング情報として、クリッピング始点座標を主画像の左上の座標（０、０）とし、クリッピング幅と高さを主画像の横と縦のピクセル数とする。それらの情報を副画像再生情報ファイル６００の副画像クリッピング情報６０３に保存する。一方、Ｓ５０５にてアスペクト比が等しくないと判定された場合には、Ｓ５０７に進む。
【００２３】
以下、図７を用いて、Ｓ５０７における副画像クリッピング領域の取得について説明する。前提として、図７の（ａ）に示すような主画像領域（幅Ｍｗ、高さＭｈ）と副画像領域（幅Ｓｗ、高さＳｈ）である場合を考える。
【００２４】
まず、図６の（ｂ）に示すように、主画像のアスペクト比を保ったまま、主画像領域を副画像領域が収まる最小サイズまで縮小して縮小主画像領域を生成する。本例では、（Ｓｗ／Ｍｗ）＞（Ｓｈ／Ｍｈ）なので、幅がＳｗのサイズになるまで、主画像領域をアスペクト比を保ちつつ縮小して縮小主画像領域を作成する。その場合、縮小率はＳｗ／Ｍｗとなり、図６の（ｃ）に示すように、縮小主画像領域の幅はＭｗ×Ｓｗ／ＭｗでＳｗと等しくなり、高さはＭｈ×Ｓｗ／Ｍｗとなる。
【００２５】
次に、この縮小主画像領域に対して、図６の（ｄ）に示すように、副画像領域でテンプレートマッチング処理を行い、縮小主画像領域のどの領域から実際に副画像領域がクリッピングされたかを検出する。図６の（ｅ）は、縮小主画像領域の左上を原点Ｐ０（０、０）とした場合に、Ｐ１（０、ｔｙ）がクリッピング始点座標として検出されたことを示している。
【００２６】
最後に、縮小主画像領域上のクリッピング領域が実際の主画像上ではどの領域に相当するかを、縮小主画像領域をもとの主画像領域の大きさまで拡大して算出する。その場合、拡大率は、図６の（ｆ）に示すように、Ｍｗ／Ｓｗとなる。これにより、副画像領域を拡大して得られた拡大副画像領域が、主画像に対する副画像のクリッピング領域となる。即ち、図６の（ｇ）のようにクリッピング始点座標Ｐ１’（０、ｔｙ×Ｍｗ／Ｓｗ）、クリッピング幅Ｍｗ、クリッピング高さＳｈ×Ｍｗ／Ｓｗとなる。そして、Ｓ５０７で算出した副画像のクリッピング領域の情報を、副画像再生情報ファイル６００の副画像クリッピング情報６０３に保存する（Ｓ５０８）。
【００２７】
以上により、Ｓ５０４、Ｓ５０６、Ｓ５０８のいずれかを経由して、Ｓ５０９に処理が進む。Ｓ５０９では、取得された副画像の縦横のピクセル数を、副画像再生情報ファイル６００内の副画像サイズ情報６０２に格納する。Ｓ５１０では、副画像の圧縮パラメータを副画像データのヘッダから取得し、副画像再生情報ファイル６００の副画像圧縮パラメータ６０４に格納する。Ｓ５１１にて、複数画像格納ファイル３００内の全ての副画像に対して、Ｓ５０２〜Ｓ５１０の処理が行われたかが判定される。ここで、全副画像に対して処理が終了したと判定された場合に、Ｓ５１２に進み、処理が終了していない（即ち、未処理の副画像が存在する）と判定された場合に、再び、Ｓ５０２に戻る。
【００２８】
ここまでの一連の処理により、副画像再生情報ファイル６００に必要な情報が全て保存されたことになる。Ｓ５１２にて、送信用ファイル（第１のファイルとする）を生成する（第１の生成処理とする）。送信用ファイルは、複数画像格納ファイル３００から副画像データ部分を単純に削除して生成される。図８は、図３に示す複数画像格納ファイル３００から、送信用ファイル８００を生成した例である。図３に示す複数画像格納ファイル３００から副画像１データと副画像２データが単純に削除されている。最後に、作成された送信用ファイル８００と副画像再生情報ファイル６００の２ファイルを送信先に送信し（Ｓ５１３）、送信元での処理を終了する。
【００２９】
次に、図９を用いて、送信先である画像サーバ１１０での処理の手順を説明する。図９に示す処理は、例えば、画像サーバ１１０におけるＣＰＵ１０１によって実行される。まず、Ｓ９０１で、送信元ＰＣ１００から送られてきた送信用ファイル８００と副画像再生情報ファイル６００の２ファイルを受信する。次に、副画像再生情報ファイル６００を参照し、まだ、再生成が行われていない副画像に対応した副画像サイズ情報６０２、副画像クリッピング情報６０３、副画像圧縮パラメータ６０４の情報を取得する（Ｓ９０２）。続いて、送信用ファイル８００内の主画像データの主画像領域に対して、取得された副画像クリッピング情報６０３を用いて副画像領域を抽出する（Ｓ９０３）。
【００３０】
次に、Ｓ９０３で抽出された副画像領域をＳ９０２で取得した副画像サイズ情報６０２の縦と横のピクセル数となるように縮小処理して縮小副画像領域を生成する（Ｓ９０４）。Ｓ９０４で生成された縮小副画像領域を、Ｓ９０２で取得した副画像圧縮パラメータ６０４でＪＰＥＧ等の圧縮を行い、圧縮後の画像データを再生成された副画像データとする。再生成された副画像データは、生成後、各副画像毎に再生成副画像ファイルとして保存される（Ｓ９０５）。
【００３１】
Ｓ９０６で、副画像再生情報ファイル６００に記述された全ての副画像に対して、Ｓ９０２〜Ｓ９０５の処理が行われたかが判定される。ここで、全ての副画像に対して処理が終了したと判定された場合に、Ｓ９０７に進み、未処理の副画像が存在すると判定された場合に、再び、Ｓ９０２に戻る。
【００３２】
ここまでの処理が終了すると、再生成副画像ファイルが副画像の数だけ生成されることになる。最後に、再生成副画像ファイルを作成した順番で送信用ファイル８００の最後尾に、副画像データとして付加していき、１つのファイルを生成する。このときに生成されたファイルを第３のファイルとし、生成する処理を第３の生成処理とする。以上の作業により、図８で示した送信用ファイル８００は、副画像データが追加されて、図３に示す複数画像格納ファイル３００の形式に戻る。また、再生成された副画像データは、演算誤差などの影響により、完全に同一のものになるとは限らないため、再生後のファイル内での各副画像の副画像ポインタを正しい値に更新し（Ｓ９０７）、送信先である画像サーバ１１０での処理を終了する。
【００３３】
以上の処理により、副画像データの再生成情報を送信先に送信することで、送信先で得られるファイル内に含まれる副画像データのサイズや品位についての情報を保持したまま、ファイル送信時のデータ転送量を削減することが可能となる。なお、本実施例では、複数画像格納ファイル３００に格納されている主画像データおよび副画像データのフォーマットをＪＰＥＧ以外の一般的な画像データフォーマットとしても良い。また、ＢＭＰ形式等の非圧縮の画像フォーマットであるならば、圧縮パラメータは特に必要ない。
【００３４】
また、送信用ファイル８００のヘッダ部分は、本実施例では変更していないが、ヘッダ内の副画像データ数を０と設定して、主画像のみが存在するファイルとして、送信用ファイル８００を生成してもよい。また、送信時にヘッダを変更した場合には、送信先でのファイル再生時に、ヘッダ情報を正しい値に戻すようにする。
【００３５】
また、本実施例では、副画像再生情報を転送するために、副画像再生情報ファイル６００を使用しているが、副画像再生情報を送信用ファイル８００内に組み込んでも良い。つまり、送信先で、副画像再生情報を取得できるような仕組みになっていれば良い。
【００３６】
また、副画像圧縮パラメータ６０４は、主画像の圧縮パラメータと同じであれば、主画像のパラメータを用いるようにしても良い。具体的には、Ｓ５１０にて主画像データ内に保存されているＪＰＥＧヘッダ内の圧縮パラメータと副画像データ内のＪＰＥＧヘッダ内に保存されている圧縮パラメータを比較する。その場合に同じであれば、副画像再生情報ファイル６００の副画像圧縮パラメータ６０４には、主画像データと同じであることを示すＩＤを設定する。送信先でのＳ９０５の処理では、副画像圧縮パラメータ６０４が主画像データと同じであることを示すＩＤの場合には、主画像データのＪＰＥＧヘッダから圧縮パラメータを取得し、そのパラメータで縮小副画像領域をＪＰＥＧ圧縮すればよい。このように、圧縮パラメータを共有することにより、送信データ量をさらに削減することが可能である。
【００３７】
本実施例は、送信（または転送）速度が遅い、通信コストが高いといった場合に、より効果が高い。従って、通信経路の速度やコストによって、本実施例の送信方法と通常の送信方法の２つを使い分けるようにしてもよい。具体的には、送信速度が遅い場合や、通信コストが高い場合には、本実施例での送信方法を使用するようにする。また、例えば、送信前に通信経路を検出し、有線ＬＡＮやＵＳＢの場合には、通常の送信方法を用い、無線ＬＡＮやＩｒＤＡによる送信では、本実施例の送信方法を用いる。また、通信コストに注目すると、送信前に通信経路を検出し、携帯電話からの送信である場合には、本実施例の送信方法を用い、携帯電話以外からの送信である場合には、通常の送信方法を用いるということが考えられる。
【００３８】
また、複数画像格納ファイル３００の生成時に、主画像データから副画像データ作成時に使用した縮小アルゴリズム名を副画像の情報として、圧縮パラメータと同様に、複数画像格納ファイル３００内のヘッダ部３１に格納するようにしても良い。その縮小アルゴリズム名を副画像再生情報ファイル６００に含めて送信し、送信先のＳ９０４での縮小処理において、この名称の縮小アルゴリズムの処理を行うことが可能な場合には、その名称の縮小アルゴリズムで縮小処理を行う。その場合、縮小処理アルゴリズムとして、ニアレストネイバー法、バイリニア法、バイキュービック法など多くの手法が一般的に知られており、アルゴリズムの違いによって出力結果も微妙に異なる。このため、送信元にある複数画像格納ファイル３００内の副画像データの生成時の縮小処理と処理を合わせることで、オリジナルの副画像データにより近い再生成副画像データを作成することが可能となる。
【００３９】
また、本実施例では、複数画像格納ファイル３００の１ファイルを送信する場合の例を説明したが、複数の複数画像格納ファイル３００を送信する場合も、実施例で示した処理を送信したいファイル数分だけ繰り返す。このとき、送信したい複数画像格納ファイル３００のファイル数が一定数以上の場合だけ、本実施例の送信方法で送信を行い、そうでない場合には、通常の送信方法で送信するようにしても良い。また、送信したい複数画像格納ファイル３００に格納されている各副画像データの合計サイズが一定サイズ以上の場合にのみ本実施例の送信方法を用い、そうでない場合には、通常の送信方法を用いるようにしても良い。また、主画像データサイズに対する各副画像データの合計サイズが一定割合以上の場合にのみ本実施例の送信方法を用い、そうでない場合には、通常の送信方法を用いるようにしても良い。
【特許請求の範囲】
【請求項１】
画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する送信手段を備える情報処理装置であって、
前記ファイルを格納する格納手段と、
前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成手段と、
前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成手段とを有し、
前記送信手段は、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信することを特徴とする情報処理装置。
【請求項２】
前記領域は矩形領域であることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記副画像は、前記矩形領域の表す画像、若しくは、前記矩形領域の表す画像を縮小した画像であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
請求項１乃至３のいずれか１項に記載の情報処理装置と、
前記第１のファイルと前記第２のファイルを受信する受信手段と、
前記第２のファイルに含まれる前記領域の情報と前記副画像のサイズとを用いて、前記第１のファイルに含まれる前記画像データから前記副画像データを生成し、前記第１のファイルに前記副画像データを付加して前記ファイルと同じ構成を有する第３のファイルを生成する第３の生成手段とを備える装置と
を含むことを特徴とする情報処理システム。
【請求項５】
画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する情報処理装置において実行される情報処理方法であって、
前記情報処理装置の第１の生成手段が、前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成工程と、
前記情報処理装置の第２の生成手段が、前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成工程と、
前記情報処理装置の送信手段が、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信する送信工程と
を備えることを特徴とする情報処理方法。
【請求項１】
画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する送信手段を備える情報処理装置であって、
前記ファイルを格納する格納手段と、
前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成手段と、
前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成手段とを有し、
前記送信手段は、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信することを特徴とする情報処理装置。
【請求項２】
前記領域は矩形領域であることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記副画像は、前記矩形領域の表す画像、若しくは、前記矩形領域の表す画像を縮小した画像であることを特徴とする請求項２に記載の情報処理装置。
【請求項４】
請求項１乃至３のいずれか１項に記載の情報処理装置と、
前記第１のファイルと前記第２のファイルを受信する受信手段と、
前記第２のファイルに含まれる前記領域の情報と前記副画像のサイズとを用いて、前記第１のファイルに含まれる前記画像データから前記副画像データを生成し、前記第１のファイルに前記副画像データを付加して前記ファイルと同じ構成を有する第３のファイルを生成する第３の生成手段とを備える装置と
を含むことを特徴とする情報処理システム。
【請求項５】
画像を表す画像データと前記画像の少なくとも一部の領域に基づいて生成された副画像を表す副画像データとを含むファイルを外部に送信する情報処理装置において実行される情報処理方法であって、
前記情報処理装置の第１の生成手段が、前記ファイルから前記副画像データを削除して第１のファイルを生成する第１の生成工程と、
前記情報処理装置の第２の生成手段が、前記画像データと前記副画像データを比較して前記副画像が前記画像のどの領域に基づいて生成されたかを検出し、該検出された前記領域の情報と前記副画像のサイズとを含む第２のファイルを生成する第２の生成工程と、
前記情報処理装置の送信手段が、前記ファイルを送信する代わりに、前記第１のファイルと前記第２のファイルを送信する送信工程と
を備えることを特徴とする情報処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１０−２８８２３９（Ｐ２０１０−２８８２３９Ａ）
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願番号】特願２００９−１４２７０９（Ｐ２００９−１４２７０９）
【出願日】平成２１年６月１５日（２００９．６．１５）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２２年１２月２４日（２０１０．１２．２４）
【国際特許分類】
【出願日】平成２１年６月１５日（２００９．６．１５）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]