(57)【要約】【課題】  簡単安価な構成によって、高解像度なデータと低解像度なデータを確実性をもって管理でき、特に、ユーザ／クライアントが低解像度なデータから極めて容易に高解像度なデータを取得できるようにする。【解決手段】目的の画像データを含みリモートホストないしローカルホスト上の所定の格納位置に格納されたオリジナル画像ファイル１００と、オリジナル画像ファイル１００の格納位置を示すアドレスタグと、オリジナル画像ファイル１００の画像データの内容を表現したサムネイル画像データ１１０を含むショートカット画像ファイル１０１を用いて画像データを分割記録し、データ利用に際して上記アドレスタグに基づきオリジナル画像ファイル１００を転送するか、条件に応じて、たとえばオリジナル画像ファイル１００が転送不可の時、ショートカット画像ファイル１０１を転送する。【選択図】  図１
2006139632.tif 000002
【特許請求の範囲】
【請求項１】
画像処理装置のハードウェアを用いて画像データを分割記録し、また必要に応じて転送する画像データ処理方法において、
前記画像データを含みリモートホストないしローカルホスト上の所定の格納位置に格納された第１の画像ファイルと、
第１の画像ファイルの格納位置を示すアドレスタグと、第１の画像ファイルが含む前記画像データの内容を表現した画像データを含む第２の画像ファイルを用い、
第２の画像ファイルのアドレスタグに基づき第１の画像ファイルを転送するか、または、第２の画像ファイルを転送することを特徴とする画像データ処理方法。
【請求項２】
請求項１に記載の画像データ処理方法において、第２の画像ファイルのフォーマットが主画像を含まないＤＣＦ基本ファイルフォーマットであることを特徴とする画像データ処理方法。
【請求項３】
請求項１に記載の画像データ処理方法において、第２の画像ファイルのフォーマットがＤＣＦサムネイルファイルフォーマットであることを特徴とする画像データ処理方法。
【請求項４】
請求項１に記載の画像データ処理方法において、第２の画像ファイルのフォーマットが第１の画像ファイルの画像データを縮小した主画像を含むＤＣＦ基本ファイルフォーマットであることを特徴とする画像データ処理方法。
【請求項５】
請求項１に記載の画像データ処理方法において、前記第２の画像ファイルのアドレスタグに基づき第１の画像ファイルを転送できない場合に、第２の画像ファイルを転送することを特徴とする画像データ処理方法。
【請求項６】
請求項１〜５のいずれか１項に記載の画像データ処理方法を実施することを特徴とする画像処理装置。
【請求項７】
画像処理装置のハードウェアを用いて請求項１〜６のいずれか１項に記載の画像データ処理方法を実施することを特徴とする画像処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置のハードウェアを用いて画像データを分割記録する画像データ処理方法、画像処理装置、および画像処理プログラムに関するものである。
【背景技術】
【０００２】
現在では、ｅ−ｍａｉｌやＤＣＳ（デジタルカメラシステム）の普及により画像イメージがコミュニケーションの表現手段のひとつとして市民権を獲得したといってよい。
【０００３】
従来より、コンピュータなどの画像処理装置上で実施される画像データの転送方法として、ショートカットファイル（シンボリックリンクやショートカットなどＯＳにより名称が異なる）やハイパーリンクのように、画像の格納位置を示す情報を含むリンクファイルを利用して、高解像度で大きいファイルサイズの画像データを任意の場所に格納し、必要なときのみリンクファイルの情報を用いて画像データの転送を行なう技術が知られている。
【０００４】
また、低解像度の画像データと高解像度の画像データとを切り分けて、低解像度の画像データのみをｅ−ｍａｉｌ送信し、受信した相手は高解像度の画像データが必要なときだけｅ−ｍａｉｌに記された指示にしたがって、高解像度の画像データを別の通信手段で転送する技術も知られている（たとえば下記の特許文献１）。
【特許文献１】特開平９−３５１２９号公報
【特許文献２】特願２００４−１４１７６７号
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記のショートカットファイルやハイパーリンクのように、画像の格納位置を示す情報を含むリンクファイルを介して画像データを転送する方法では次のような問題がある。
【０００６】
まず、ＨＴＭＬ文書内のハイパーリンクの場合は、画像の格納位置を示すＵＲＬ（ＵＲＩ）情報をテキストベースのＨＴＭＬ書式で記載し、さらに本体の画像の転送前にクライアントにイメージの内容を示す必要があれば、本体の画像を縮小するなどして得たサムネイル画像を用意し、そのリンク先を特定の書式で記載するなどの面倒な作業が必要となる。
【０００７】
また、ショートカットファイルでは、通常、画像の格納位置を示す情報しか含まれていないので、転送に前もって転送したい画像ファイルの概要を知りたいときにはＯＳのシステムファイル等のリンクファイルの対象となる画像のイメージ管理ファイルを別途（何らかのビューワを介して、あるいは直接）参照する必要があった。つまり、ショートカットファイルからは直接、オリジナル画像ファイルの画像イメージを取得することができなかった。
【０００８】
また、特許文献１に記載されるような管理方法では、高解像度の画像データを転送するためには、低解像度の画像データが添付されたｅ−ｍａｉｌ本文の指示に従う必要があり、ｅ−ｍａｉｌ本文を消去し、添付の低解像度の画像データのみが残っている場合などは本体の高解像度の画像データを取得することができない問題がある。すなわち、特許文献１に記載のような技術では、ｅ−ｍａｉｌに添付された低解像度の画像データで構成される画像ファイルのみを手がかりに、高解像度の画像データが含まれる画像ファイルを転送することはできなかった。
【０００９】
一方、画像データの管理方式において、ＤＣＦ規格のように高解像度の実画像データと低解像度のサムネイル画像データとを一つの画像ファイルで格納する画像データフォーマットが知られている。
【００１０】
ＤＣＦ（Ｄｅｓｉｇｎ  ｒｕｌｅ  ｆｏｒ  Ｃａｍｅｒａ  Ｆｉｌｅ  ｓｙｓｔｅｍ）はデジタルカメラの画像データフォーマットとしてＩＳＯで標準化された仕様であるが、ＪＥＩＤＡ（日本電子工業振興協会）が策定したＥｘｉｆ（Ｅｘｃｈａｎｇｅａｂｌｅ  Ｉｍａｇｅ  Ｆｉｌｅ）形式が元になっており、これらＤＣＦ／Ｅｘｉｆ形式はほぼ同一のデータフォーマットといってよい。
【００１１】
ＤＣＦ／Ｅｘｉｆ形式の画像の構造は基本的には通常のＪＰＥＧ画像形式そのものであり、サムネィル画像や撮影情報等のデータをＪＰＥＧの規約に準拠した形で埋め込んだものである。このような管理方法によれば、画像データの詳細な情報を知りたいときには高解像度の画像データを参照し、画像データの概要がわかればよいときには低解像度の画像データを参照する、というように画像データを使用する目的によって参照する情報を選択できるメリットがある。
【００１２】
上記のように、従来のような画像の概要を示すファイルサイズの小さい画像データと、画像の詳細を示すファイルサイズの大きい画像データとをリンクさせる管理手段が画像ファイルとは別のファイル（リンクファイルやハイパーリンクなど）から構成されている場合、画像の概要を示すファイルとともに、詳細を示す画像ファイルの格納先を記す別の管理ファイルをあわせて流通させる必要があり、管理面での制約が大きい問題があった。この点に鑑み、出願人は上記のようなＤＣＦ／Ｅｘｉｆ形式の画像フォーマットを考慮して、第１のオリジナル画像ファイルのうち、第１の画像よりも低解像度であるサムネイルのみを有する第２の画像ファイルを第１の画像ファイルから切り分けることにより、通常は第２の低解像度の画像を取り扱い、必要に応じて第１の高解像度の画像データを利用することで、高解像度なデータと低解像度なデータを別々に管理する画像の分割管理方法を提案している（上記の特許文献２）。
【００１３】
しかしながら、特許文献２は、主に画像の分割管理方法に関する画像フォーマットの規定を取り扱っており、特許文献２では画像ファイルを作成する手順については記載されているが、分割された画像ファイルを用いて低解像度なデータから高解像度なデータを取得する手順については具体的に示されていなかった。
【００１４】
本発明の課題は、上述の事情を考慮し、簡単安価な構成によって、高解像度なデータと低解像度なデータを両者の関連性を保ったまま別々に確実性をもって管理でき、特に、ユーザ／クライアントが低解像度なデータから極めて容易に高解像度なデータを取得できるようにすることにある。
【課題を解決するための手段】
【００１５】
上記課題を解決するため、本発明では、画像処理装置のハードウェアを用いて画像データを分割記録する画像データ処理方法、画像処理装置、および画像処理プログラムにおいて、前記画像データを含みリモートホストないしローカルホスト上の所定の格納位置に格納された第１の画像ファイルと、第１の画像ファイルの格納位置を示すアドレスタグと、第１の画像ファイルが含む前記画像データの内容を表現した画像データを含む第２の画像ファイルを用い、第２の画像ファイルのアドレスタグに基づき第１の画像ファイルを転送するか、または、第２の画像ファイルを転送する構成を採用した。
【発明の効果】
【００１６】
上記構成によれば、簡単安価な構成により高解像度なデータと低解像度なデータを両者の関連性を保ったまま別々に確実性をもって管理できる。たとえば、画像の概要を知りたいときにはファイルサイズの小さい第２の画像ファイルの画像データのみを利用し、画像の詳細を知りたいときには、第２の画像ファイルのみを手がかりに、第１の画像ファイルの高解像度の画像データを利用できるという優れた効果がある。特に、第２の画像ファイルそれ自体に第１の画像ファイルの格納場所がアドレスタグとして含まれているため、たとえば第２の画像ファイルを送信したメール本文などを紛失してしまっても第２の画像ファイルのみから第１の画像ファイルに到達することができる、という優れた効果がある。
【００１７】
特に、第１の画像ファイルの所在位置を示すアドレスタグと第２の画像を含んだ第２の画像ファイルのそれぞれを異なった位置に分割して格納することができ、その場合、たとえば、第１および第２の画像ファイルはそれぞれ画像処理装置とサーバのように異なるホストで管理したり、画像処理装置のファイルシステムの異なるフォルダでそれぞれ管理したりすることができる。
【００１８】
さらに、第１の画像ファイルと、そのアドレスタグを含む第２の画像ファイルを用い、画像データを分割記録し、データ利用（転送：表示、印刷、セーブ（コピー））に際して第２の画像ファイルのアドレスタグに基づき第１の画像ファイルを転送するか、条件に応じて、たとえば第１の画像ファイルが転送不可の場合（たとえば第１の画像ファイルを保有するサーバ／ホストに到達不能、あるいは該サーバ／ホストから第１の画像ファイルが消去されているような場合）第２の画像ファイルを転送するようにしているため、第１の画像ファイルが転送不可の場合は、元の画像情報にアクセスできないにしても、最低限の情報を第２の画像ファイルから取得でき、第２の画像ファイルを画像データのバックアップ用途に利用できる、という優れた効果がある。
【発明を実施するための最良の形態】
【００１９】
以下ではデジタルカメラやパーソナルコンピュータなどの画像処理装置において、画像データを管理する実施例を示す。
【実施例１】
【００２０】
以下、図面を参照して、本発明の実施の形態を詳細に説明する。
【００２１】
図９は、本実施例の画像データの管理方式を適用可能な処理環境を示している。図９において符号９０１はターミナルで、具体的にはこのターミナルはＰＣ端末、スキャナやデジタルカメラ（以下ＤＣＳという）などから構成される。
【００２２】
以下では、ターミナル９０１はＰＣ端末であるものとし、ターミナル９０１はＣＰＵ９０４、メモリ９０５、ＨＤＤ９０６などから構成され、ネットワークインターフェース９１０を介してネットワーク９０３と接続できるようになっている。ネットワーク９０３上にはオンラインフォトアルバムサービス等を提供するサーバ９０２が設けられている。サーバ９０２のハードウェア構成については図示を省略するが、実際にはこの種のサーバはターミナル９０１のものとして示したＰＣと同等のハードウェアを用いて構成されており、したがって、サーバ９０２もターミナル９０１と同様にＣＰＵ、メモリ、ＨＤＤなどを用いて構成される。
【００２３】
本実施例において管理すべき画像データ（以下のオリジナル画像）は、ＵＳＢなどのインターフェース９０８で接続された画像入力手段９０７からターミナル９０１あるいはサーバ９０２に入力される。
【００２４】
また、ターミナル９０１が画像入力手段９０７から得た画像、あるいはサーバ９０２からダウンロードした画像はディスプレイやプリンタなどからなる画像出力手段９１１を介して出力することができる。
【００２５】
本実施例では、本願特許請求の範囲における第１の画像をオリジナル画像、第２の画像をショートカット画像と呼ぶ。このうち、オリジナル画像は元の高解像度の画像、ショートカット画像は、少なくともオリジナル画像の所在位置を示す情報と、さらにオリジナル画像のサムネイル画像を含む。
【００２６】
本実施例では、このような画像データの基本フォーマットとしてＤＣＦ／Ｅｘｉｆ形式を用いる。したがって、以下の説明では、画像ファイルの特定部分を示す用語として必要に応じてＤＣＦ／Ｅｘｉｆ規格（あるいはＪＰＥＧ規格）において対応する部分を示す用語を用いる。
【００２７】
ここで図１を用いてオリジナル画像とショートカット画像のデータフォーマットについて説明する。
【００２８】
図１において符号１００はオリジナル画像のファイルフォーマットを示している（図１上部）。ＳＯＩ（１０３）はＳｔａｒｔ  ｏｆ  Ｉｍａｇｅの略称で、圧縮画像データの先頭を示すマーカーコード（通常０ｘＦＦＤ８）である。ＥＯＩ（１０４）はＥｎｄ  ｏｆ  Ｉｍａｇｅの略称で、ＳＯＩと対をなす圧縮画像データの終了を示すマーカーコード（通常０ｘＦＦＤ９）である。ＤＣＦ規格においては、ＳＯＩから始まりＥＯＩでデータが終わるように規定されている。
【００２９】
ＡＰＰ１はアプリケーションマーカーセグメントで、主画像の付加情報と低解像度の画像データであるサムネイル画像がＡＰＰ１の領域に格納される。ＡＰＰ１のマーカー値は通常０ｘＦＦＥ１であり、このＡＰＰ１データセグメント１０５はこのマーカーの後に２バイトのサイズデータと、実際のデータ領域が続いて格納されることにより構成される。
【００３０】
高解像度の主画像（ＤＣＦ基本主画像）は符号１０６で示すように、ＡＰＰ１データセグメント１０５に続いて格納される。
【００３１】
また、サムネイル画像１１０はＡＰＰ１データセグメント１０５内に格納される。サムネイル画像１１０はＤＣＦ基本ファイルと同様にＳＯＩから始まりＥＯＩでデータが終わるように規定されている。そしてサムネイル画像データはサムネイル画像１１０の主画像（ＤＣＦ基本主画像）１０７として格納される、すなわち、サムネイル画像１１０自体もＤＣＦ形式で記述されている。なお、サムネイル画像１１０のＡＰＰ１データセグメント１０５はＤＣＦ基本ファイルのＡＰＰ１データセグメント１０５と同じ内容のデータを有してもよい。
【００３２】
サムネイル画像１１０に対し、ＤＣＦ基本主画像１０６は高解像度の画像データで構成される。
【００３３】
図１上部に示したＤＣＦ規格に準拠したオリジナル画像は、低解像度のサムネイル画像１１０と高解像度の主画像１０６とを有することで、画像の概要を知りたいときにはサムネイル画像１１０を、画像の詳細を知りたいときには主画像１０６を、それぞれ参照すればよい。サムネイル画像１１０は、デジタルカメラなどにおいては、ＬＣＤなどの表示器でサムネイル表示などを行なうために用いられている。
【００３４】
また図１下部には、本実施例のショートカット画像のファイルフォーマットを符号１０１に示してある。ショートカット画像１０１は、オリジナル画像と同様にＤＣＦ基本ファイルのフォーマットで構成され、オリジナル画像と同様にサムネイル画像を有するが、本実施例のショートカット画像１０１は、第１の特徴として、オリジナル画像のように高解像度のＤＣＦ基本画像データを有しない。あるいはショートカット画像１０１は、ＤＣＦ基本画像データを有していてもよいが、本実施例ではＤＣＦ規格においてＤＣＦ基本画像データが本来格納される位置にはＮＵＬＬデータ１１１を格納する。
【００３５】
あるいは、図１下部左側に示すように、上記ＮＵＬＬデータの代りに、オリジナル画像の主画像１０６を縮小して生成した縮小画像１０６ａを格納してもよい。この縮小画像１０６ａのサイズは、好ましくはＤＣＦ／Ｅｘｉｆ形式で用いられているサムネイル画像より大きいサイズとする。ＤＣＦ／Ｅｘｉｆ形式で用いられているサムネイル画像は、たとえばデジタルカメラのＬＣＤディスプレイなどの限定された表示画面で多数のサムネイル画像を表示できるよう非常に大きな縮小比率で生成されるため画像の細部を視認することが困難な場合があるが、ＤＣＦ／Ｅｘｉｆ形式で用いられているサムネイル画像よりも緩い縮小を行なった縮小画像１０６ａを用いるようにすればユーザは画像の細部を充分視認することができ、しかも、主画像１０６のかわりに縮小画像１０６ａを用いることによりショートカット画像のファイルサイズはオリジナル画像のファイルサイズよりも小さく抑えることができる。
【００３６】
また、本実施例のショートカット画像１０１は、第２の特徴として、ショートカット画像１０１のＤＣＦ基本ファイルとＤＣＦ基本サムネイルファイルのそれぞれのＡＰＰ１領域には、オリジナル画像１００の格納場所を示すアドレスタグ１０２が付加されている。
【００３７】
したがって、図１に示したショートカット画像１０１は、オリジナル画像１００からＤＣＦ基本主画像１０６を除去する（ＮＵＬＬデータを格納する場合）か、オリジナル画像１００からＤＣＦ基本主画像を縮小して、ショートカット画像の主画像として格納する（縮小画像１０６ａを格納する場合）とともに、オリジナル画像１００の格納場所を示すアドレスタグ１０２を付加することにより生成することができる。アドレスタグ１０２は、たとえば後述のようにＵＲＬ（あるいはＵＲＩ）形式により記述する。
【００３８】
このようにショートカット画像１０１は、たとえば、本発明における画像の管理方法においては、ＤＣＦ規格に準拠したオリジナル画像１００と、ショートカット画像１０１を用いた形式で元の画像データを分割記録する。
【００３９】
このようにオリジナル画像１００の格納場所を示すアドレスタグ１０２を含むショートカット画像１０１を用いることにより、ショートカット画像１０１さえあればオリジナル画像１００を取得することができる。たとえば、ショートカット画像１０１のみをメールで受信したユーザは、そのメール本文が無くてもショートカット画像１０１のみからアドレスタグ１０２を用いてオリジナル画像１００を取得することができる。
【００４０】
なお、本実施例において、一つのオリジナル画像に対して、ショートカット画像は複数存在してもかまわない。また、本実施例の規約では、画像ファイルにアドレスタグが存在すればその画像をショートカット画像であると判断するものとするが、ショートカット画像であるか否かを示す専用のタグを規定してもよい。また、ショートカット画像のサイズが大きくなる問題はあるが、ショートカット画像に主画像データが存在してもかまわない。また、主画像を有するオリジナル画像にアドレスタグが存在してもかまわない。
【００４１】
ここで図２によりショートカット画像１０２に付与されるアドレスタグのデータ構成を説明する。
【００４２】
アドレスタグは２００に示すように、Ｅｘｉｆ（ＤＣＦ）規約に基づきＥｘｉｆＩＦＤ内に記録する。アドレスタグのタグ番号には、Ｔｉｆｆのプライベートタグ番号（たとえば、本実施例では４３０００）を利用する。
【００４３】
アドレスタグの内容を示すタグのＶａｌｕｅは、Ｖａｌｕｅ  ｏｆ  ＥｘｉｆＩＦＤ内に記録する。Ｖａｌｕｅの格納位置は、アドレスタグのＶａｌｕｅＯｆｆｓｅｔに記される。アドレスタグのタグＴａｇ、Ｔｙｐｅ、Ｃｏｕｎｔ、ＶａｌｕｅＯｆｆｓｅｔは特に規定しないが、たとえばＴｙｐｅは“ＡＮＹ”、ＣｏｕｎｔはＡｎｙとしておけばよい。
【００４４】
アドレスタグのＶａｌｕｅ２０１の内容は次のように構成されている。すなわち、図２に示すように、アドレスタグのＶａｌｕｅの先頭には、以降続く文字コードを識別するための文字コード種別情報２０２を記録する。この文字コード種別情報２０２としては、たとえばＡＳＣＩＩコード、ＪＩＳコード、Ｕｎｉｃｏｄｅ、またはそれ以外の文字コードを指定する。
【００４５】
２０２の文字コード種別情報に続いて、オリジナル画像の格納場所を示すアドレス文字列２０３をＶａｌｕｅ２０１として記録する。アドレス文字列は、オリジナル画像の格納位置を示すパス名と、オリジナル画像のファイル名とで構成される。アドレスタグのＶａｌｕｅへのオフセットは、ＴＩＦＦの規定にしたがってアドレスタグのＶａｌｕｅＯｆｆｓｅｔに記される。
【００４６】
なお、アドレスタグのＶａｌｕｅ２０１には、文字コード種別情報２０２を記録せずに、オリジナル画像のアドレスを示す文字列２０３のみ記録してもかまわない。
【００４７】
たとえば、文字コードには一定のコード、たとえばＵＴＦ−８を固定的に用いるものとすれば、文字コード識別情報は必要無いが、ＵＴＦ−１６で符号化する場合は、ＩＳＯ／ＩＥＣ  １０６４６の附属書ＥおよびＵｎｉｃｏｄｅの付録Ｂで規定するバイト順マーク（ＺＥＲＯ  ＷＩＤＴＨ  ＮＯ−ＢＲＥＡＫ  ＳＰＡＣＥ文字，０ｘＦＥＦＦ、もしくは０ｘＦＦＦＥ）で始まらなければならない。また、明示的にＵＴＦ−８であることを識別するために、先頭の３バイトに識別コード（０ｘＥＦ  ０ｘＢＢ  ０ｘＢＦ）を入れてもよい。
【００４８】
また、アドレスタグのＶａｌｕｅ２０１は、ＵＤＦにしたがって記録されてもよい。このときは、Ｖａｌｕｅの先頭１バイトに文字コード種別、次の１バイトに文字列長、続けてオリジナル画像の格納場所を示すアドレス文字列を記録する。
【００４９】
このように、本実施例では図２で示したように、ショートカット画像にアクセス可能な任意のアプリケーションまたは画像制御装置は、ショートカット画像からアドレスタグを参照することによりオリジナル画像の格納位置を知ることができるため、ファイルサイズの大きいオリジナル画像とファイルサイズの小さいショートカット画像とを別々の格納場所に保存する画像の管理方法が実現される。
【００５０】
たとえば画像の概要だけわかればよい場合には、画像を格納するメモリエリアを圧迫しないファイルサイズの小さいショートカット画像を利用し、画像に対する詳細な情報を得たい場合には、オリジナル画像を利用することが考えられる。
【００５１】
次に、本実施例におけるオリジナル画像とショートカット画像を用いた画像データの管理の例を図３および図４に示す。
【００５２】
図３は、オリジナル画像がサーバ９０２上の所定アドレス、たとえば「ｈｔｔｐ：／／ｗｗｗ．ｘｘｘｘ．ｃｏ．ｊｐ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／」に格納され、各オリジナル画像（たとえばＡ、Ｂ、Ｃ、Ｄ）３０１に対するショートカット画像（たとえばａ、ｂ、ｃ、ｄ）３０２が、ターミナル７０１の所定格納位置、たとえば「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／ｓｈｏｒｔｃｕｔ−ｉｍａｇｅ／」に格納されている状態を示している。
【００５３】
３０１に示すファイル名「Ａ．ＪＰＧ」のオリジナル画像「Ａ」に対して、３０２に示すファイル名「ａ．ＪＰＧ」のショートカット画像「ａ」があるとすると、オリジナル画像「Ａ」の格納位置は「ｈｔｔｐ：／／ｗｗｗ．ｃａｎｏｎ．ｃｏ．ｊｐ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／  」、ファイル名は「Ａ．ＪＰＧ」であるため、ショートカット画像「ａ」のアドレスタグには、３０３のように「ｈｔｔｐ：／／ｗｗｗ．ｃａｎｏｎ．ｃｏ．ｊｐ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／Ａ．ＪＰＧ」が記録される。
【００５４】
たとえば、ユーザがＤＣＳで撮影した写真画像ファイル（オリジナル画像）３０１を、オンラインフォトアルバムサービス等で提供されるサーバ９０２に保存して、ユーザのＰＣ端末（ターミナル９０１）にはオリジナル画像３０１に対応したショートカット画像３０２を保存する（たとえば、サーバ９０２がメールでターミナル９０１に送信する）ことにより、ユーザはターミナルＰＣをサーバに接続しなくとも、ターミナル９０１のＨＤＤ９０６などに格納されたショートカット画像３０２のサムネイルを参照することでサーバに保存されているオリジナル画像３０１の概要を知ることができる。
【００５５】
また、たとえばターミナル９０１がＰＤＡや携帯端末のような、メモリエリアに制限のある装置であっても、ショートカット画像を保存しておけば、画像の概要を知ることはできる。そして、ユーザは画像の詳細を知りたいときだけオリジナル画像３０１をサーバ９０２から取得すればよい。
【００５６】
また、サーバ９０２にオリジナル画像３０１を格納することにより、サーバ９０２に接続可能な端末からは、ショートカット画像３０２さえあればオリジナル画像３０１の詳細を知ることが可能であることから、ユーザ間で画像ファイルをやりとりする場合にショートカット画像３０２のみ利用してもよい。
【００５７】
たとえば、電子メールに写真画像を添付するときには、ショートカット画像３０２を添付することで、電子メールのファイルサイズを小さくでき、ショートカット画像３０２を受け取ったユーザは、ショートカット画像３０２を用いて必要に応じて、サーバ９０２に格納されたオリジナル画像３０１を取得する、といった利用方法が考えられる。
【００５８】
なお、相手のユーザに小さいファイルサイズで画像をやりとりする手段として、従来技術におけるように電子メールの指示にしたがってオリジナル画像を取得する方法もあるが、本実施例によれば、ショートカット画像にオリジナル画像の格納位置の完全な情報が含まれているので、ショートカット画像を受けとったユーザは、任意のショートカット画像からオリジナル画像を取得したい場合に、わざわざメールの本文を参照する必要がない。
【００５９】
また、ショートカット画像を利用することにより、電子メール以外の手段でも、ファイルサイズの制限を少なくして、相手のユーザと画像をやりとりすることができる。たとえば、メモリカードにショートカット画像のみを格納させ、相手のユーザにメモリカードを渡せば、相手のユーザがそのメモリカードから任意のオリジナル画像を取得することができるが、この場合、相手のユーザは従来技術では必要であった電子メールの本文を必要としない。
【００６０】
図３では、オリジナル画像とショートカット画像が異なるホスト（サーバ９０２およびターミナル９０１）にそれぞれ格納されている状態を示したが、図４に示すように、オリジナル画像とショートカット画像は、同じターミナル（あるいはサーバ）の異なるフォルダ（ディレクトリ）に格納されている場合でも本実施例の管理方式を利用することができる。
【００６１】
図４では、オリジナル画像がターミナル９０１のフォルダＡ「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／」に格納（「／」はファイルのパス名のフォルダ（ディレクトリ）の区切りを示す。以下同様）され、各オリジナル画像（たとえばＡ、Ｂ、Ｃ、Ｄ）に対するショートカット画像（たとえばａ、ｂ、ｃ、ｄ）が、同じターミナル９０１の別フォルダＢ「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／ｓｈｏｒｔｃｕｔ−ｉｍａｇｅ／」、フォルダＣ「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／子供の写真／」、フォルダＤ「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／２００３年０１月撮影／」に格納されている。これらのフォルダ（ディレクトリ）は、たとえば図９の構成ではターミナル９０１のＨＤＤ９０６などに画成される。
【００６２】
図４において、符号４０２に示すファイル名「Ａ．ＪＰＧ」のオリジナル画像「Ａ」に対する、４０３に示すファイル名「ａ．ＪＰＧ」のショートカット画像「ａ」があるとすると、オリジナル画像「Ａ」の格納位置は「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／」、ファイル名は「Ａ．ＪＰＧ」であるため、ショートカット画像「ａ」のアドレスタグには、４０３のように「Ｃ：／Ｍｙ  Ｐｉｃｔｕｒｅｓ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／Ａ．ＪＰＧ」が記録される。
【００６３】
図４のような管理形態においては、たとえば、ユーザがＤＣＳで撮影した写真画像ファイル（オリジナル画像）を、ユーザのＰＣ端末（ターミナル）の任意のフォルダに保存しており、オリジナル画像に対応したショートカット画像を別のフォルダに保存することで、ユーザは常にオリジナルの写真画像ファイルは特定のフォルダに一括で保存しておき、撮影時刻やテーマ等のフォルダごとに整理するときはショートカット画像を利用することができる。
【００６４】
また、本実施例では、１つのオリジナル画像に対するショートカット画像が複数あってよいことから、たとえば、４０１に示すオリジナル画像「Ａ」は、２００３年の１月に作成された画像ファイルで、かつ、被写体に子供が含まれている場合は、画像ファイルに子供が写っていることを示すフォルダＣと、撮影時刻が２００３年０１月を示すフォルダＤの２つのフォルダに同じショートカット画像「ａ」がそれぞれ含まれてもよい（符号４０４および４０５）。
【００６５】
本実施例において、このように同一画像ファイルに対して複数のショートカット画像を生成することを許容するのは、次のような事情があるためである。
【００６６】
たとえば、ＰＣ等における画像ファイルの管理において、ひとつの画像ファイルに対して「被写体が子供である」、「２００３年１月に撮影した画像である」というように、異なるカテゴリーで管理したいという需要が発生することが考えられるが、この場合、「被写体が子供である」というフォルダと、「２００３年１月に撮影した画像である」というフォルダを作成し、それぞれのフォルダに同じオリジナル画像をコピーして保存すると、メモリエリアが圧迫されてしまう。そこで、従来では、オリジナル画像を特定の場所に保存し、それらのショートカットファイル（たとえばＷｉｎｄｏｗｓ（商品名）の「ショートカット」）を利用して管理するような方法が用いられていたが、このようなショートカットファイルを用いる方法ではＯＳのシステムファイルを利用しないと画像の概要を知ることができないため、画像を管理するアプリケーションによってはショートカットファイルから画像の概要を容易に知ることができない。また、システムファイルを利用する場合でも、管理する画像ファイルが増加するにしたがって、システムファイルのサイズも肥大化する問題があった。また、このファイルサイズの問題を回避するために、任意のタイミングごとにシステムファイルから使われていない縮小画像を消去することで、システムファイルの肥大化を抑えることもできるが、システムファイルを更新するたびに画像処理が発生してしまう。
【００６７】
しかしながら、図４のような管理形態によれば、ショートカット画像はオリジナル画像と比べて小さいファイルサイズであることから、複数のカテゴリに同一のオリジナル画像から関連付けられたショートカット画像が重複しても、ファイルサイズの増加を抑えることができ、また、ショートカット画像は独立しているため、システムファイルを使用する必要も生じない。
【００６８】
以上のように本実施例のショートカット画像を利用すれば、効率よくカテゴリ別に写真画像を分類する利用方法が可能となる。
【００６９】
次に、上述のようなファイルフォーマットを有するショートカット画像からオリジナル画像の画像データ（またはショートカット画像の画像データ）を転送する手法につき説明する。ここでは、図３のようにショートカット画像「ａ」がターミナルに、オリジナル画像「Ａ」がサーバに格納されている場合を例に説明する。
【００７０】
図５〜図７は、本発明における画像転送手順の一例を示している。図５〜図７では、便宜上ターミナルとサーバに５００、６００および７００番台の符号を用いるが、これらのターミナルとサーバは図９に示したターミナル９０１とサーバ９０２に対応するものである。
【００７１】
図５は、ターミナルとサーバのソフトウェア構成を示しており、図示のように、ターミナル５０１ではアプリケーションＡとアプリケーションＢが、サーバ５０２ではアプリケーションＣが動作している。
【００７２】
本実施例では、これらアプリケーションＡ〜Ｃについて特に具体的に規定しないが、たとえばアプリケーションＡはユーザが画像を閲覧したり印刷指示を出すような画像の制御を行なうために使用するアプリケーション、アプリケーションＢはターミナルに格納されたショートカット画像「ａ」を管理するアプリケーション、アプリケーションＣはサーバに格納されているショートカット画像「ａ」に対応したオリジナル画像「Ａ」を管理するアプリケーションであるものとする。
【００７３】
もちろん、これらのショートカット画像「ａ」およびオリジナル画像「Ａ」は図１〜図４で説明した構造により関係づけられている。
【００７４】
本実施例では、ターミナルで動作するアプリケーションＡが、アプリケーションＢ、またはアプリケーションＣからショートカット画像「ａ」の画像データやオリジナル画像「Ａ」の画像データを取得する。
【００７５】
図６（ａ）はターミナル６０１上で、アプリケーションＡがショートカット画像「ａ」の画像データを取得する手順、図６（ｂ）はアプリケーションＡとアプリケーションＢにおいてショートカット画像ファイルの転送手順シーケンスを示している。
【００７６】
ここでは、図６（ａ）のように、ターミナル６０１のアプリケーションＡがアプリケーションＢの管理下にあるショートカット画像「ａ」の画像データを取得しようとしている。
【００７７】
この場合、符号６０３のショートカット画像の転送手順シーケンスに示すように、アプリケーションＡからのショートカット画像取得要求（ショートカット画像データ転送要求）に応じて（６０４）、アプリケーションＢはショートカット画像「ａ」の画像データをアプリケーションＡへ転送する（６０５）。この転送の詳細な手順については後述する。
【００７８】
図６（ａ）、（ｂ）の転送は、たとえばアプリケーションＡを操作するユーザが、画像「Ａ」の概要だけを知りたいときに行なわれる。具体的には、ターミナル６０１のアプリケーションＡを閲覧ブラウザ、アプリケーションＢをターミナル上で動作するＯＳであるとすると、図６は、たとえば、このブラウザでＰＣのローカルディスクに格納されたショートカット画像「ａ」を閲覧する動作を示す。
【００７９】
このときブラウザに表示されるショートカット画像「ａ」は、ＤＣＦの規定に従ったサムネイル画像であり、サムネイル画像はファイルサイズが小さいため、ブラウザからショートカット画像を展開して表示する際の処理が、主画像を展開する処理と比べて軽くて済む。
【００８０】
また、図６（ａ）、（ｂ）の転送では、ショートカット画像の画像データ転送処理のみが行なわれるので、サーバ６０２のアプリケーションＣおよびオリジナル画像「Ａ」は関与しない。したがって、ターミナル６０１において、ユーザが画像の概要だけを知ればよいとき、たとえば、いくつかの画像ファイルの概要だけを閲覧したいときには、ファイルサイズの小さいショートカット画像だけを参照すればよいため、ハード資源の乏しいターミナル環境において快適に複数の画像ファイルを閲覧（あるいは管理）する点でメリットがある。
【００８１】
図７（ａ）はターミナル７０１のアプリケーションＡがオリジナル画像「Ａ」の画像データを取得する手順を、図７（ｂ）はターミナル７０１のアプリケーションＡとアプリケーションＢのショートカット画像のアドレスタグ情報転送手順シーケンス、およびターミナル７０１のアプリケーションＡおよびサーバ７０２のアプリケーションＣのオリジナル画像ファイルの転送手順シーケンスを示している。
【００８２】
アプリケーションＡがショートカット画像「ａ」の画像データよりも高解像度なオリジナル画像「Ａ」の画像データを取得する場合、ターミナル７０１は、まずアプリケーションＢの管理下にあるショートカット画像「ａ」のアドレスタグを取得し、続いてこのアドレスデータからサーバ７０２のアプリケーションＣが管理するオリジナル画像「Ａ」の画像データを取得する。
【００８３】
図７（ｂ）は図７（ａ）に示したショートカット画像の転送手順シーケンスを示している。アプリケーションＡからのアドレスタグ取得要求（アドレスタグデータ転送要求）に応じて（７０４）、アプリケーションＢはショートカット画像「ａ」のアドレスタグデータをアプリケーションＡへ転送する（７０５）。続いてアプリケーションＡは取得したアドレスタグを解析し、アドレスタグに記述されたアドレスにしたがって、サーバ７０２のアプリケーションＣへオリジナル画像「Ａ」の画像データ取得要求（オリジナル画像データ転送要求）を発行する（７０６）。アプリケーションＣはこれを受けてオリジナル画像「Ａ」の画像データをアプリケーションＡへ転送する（７０７）。このときの詳細な手順については後述する。
【００８４】
図７の処理は、たとえばアプリケーションＡを操作するユーザがショートカット画像「ａ」に示される画像の詳細を知りたいときに行なう。図６と同様にターミナル７０１をＰＣ、アプリケーションＡを閲覧ブラウザ、アプリケーションＢをターミナル７０１で動作するＯＳであるとすると、たとえば、先の図６ではブラウザでショートカット画像「ａ」を閲覧したり印刷する動作が可能であるが、図７の処理によれば、ユーザがブラウザからショートカット画像「ａ」を閲覧し、その画像を印刷する場合に、低解像度のショートカット画像「ａ」よりも高解像度のオリジナル画像「Ａ」を印刷対象としたほうが、印字品位を高めることができる。
【００８５】
すなわち、図６のような処理により、ユーザはショートカット画像「ａ」を閲覧し、さらに印刷などの必要があれば、図７に示したようにショートカット画像「ａ」に記録されたアドレスタグから、オリジナル画像「Ａ」を参照し高解像度の画像データを取得することができる。
【００８６】
なお、以上ではアプリケーションＡ、Ｂ、Ｃの役割を切り分けて説明したが、本発明では画像を管理するアプリケーションの役割について特に規定しない。たとえば、ターミナル、サーバ共にアクセス可能なアプリケーションＢとアプリケーションＣの役割を含むアプリケーションＡが、ショートカット画像「ａ」オリジナル画像「Ａ」に直接アクセスして画像データを取得してもかまわない。また、ターミナル、サーバの区別についても特に上記の通りである必要はなく、ターミナル間やサーバ間で同様の処理が行われてもかまわない。
【００８７】
次に、図８を参照して図５〜図７に示した画像データの転送手順を詳細に説明する。図８はターミナル（上記の９０１、５０１、６０１、７０１）が実行する画像データの転送手順を示している。図８の手順は、ＣＰＵ（９０４）の制御プログラムとしてＨＤＤ（９０６）やメモリ（９０５）に格納されていればよい。図８の制御手順に相当するプログラムの供給経路は任意であり、製品出荷時からこれらの記憶媒体に格納しておく他、ＭＯやＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの記憶媒体を介して供給する、あるいはネットワーク経由で供給する方法を採用することができる。
【００８８】
図８のステップＳ８０１でショートカット画像に対して画像データ転送要求が発生すると、ステップＳ８０２以降の処理が行なわれる。
【００８９】
たとえば本実施例では、図５〜図７に示したようにアプリケーションＡ（たとえばブラウザやイメージビューワ）がショートカット画像を管理するアプリケーションＢ（たとえばＯＳ）やサーバのアプリケーションＣ（たとえばＨＴＴＰサーバ）に対して画像転送要求を行なう。
【００９０】
次に、ステップＳ８０２で、要求された画像データが低解像度のサムネイル画像と高解像度のオリジナル画像のいずれであるかの判別を行なう。
【００９１】
ステップＳ８０２の判別は、ユーザが所定のユーザーインターフェースを介して行なった要求する画像データの解像度指定に基いて行なう、アプリケーションのデフォルトに応じて行なう（たとえばあるアプリケーションでは低解像度のサムネイル画像のみを取り扱うようなデフォルト設定が可能である）、などの方法が考えられる。また、たとえばＷＥＢブラウザの場合は、ＨＴＴＰの＜ＩＭＧ＞のようなタグで配置されたイメージを当該ＷＥＢページ中に表示するような場合は低解像度のサムネイル画像が、また、ＷＥＢブラウザのメニューなどから、「画像を表示」や「Ｖｉｅｗ  Ｉｍａｇｅ」（画像のみを１ページ内に表示する）、あるいは「画像をセーブ（ダウンロード）」や「Ｓａｖｅ  Ｉｍａｇｅ」のようなメニューアイテムが選択された場合は高解像度のオリジナル画像が選択されたものとして取り扱う実装が考えられる。
【００９２】
ステップＳ８０２で要求する画像データが低解像度の画像データである場合はステップＳ８０３で画像の画像データを転送する処理を行なう。たとえば、図６のようにアプリケーションＡがショートカット画像「ａ」の概要のみを知ればよい場合（オリジナル画像「Ａ」の画像データが不必要な場合）は、ステップＳ８０３でショートカット画像「ａ」に含まれる画像データを転送する。すなわちステップＳ８０３でショートカット画像「ａ」のサムネイル画像がアプリケーションＡに転送される。たとえばＷＥＢブラウザの場合は、ＨＴＴＰの＜ＩＭＧ＞のようなタグで配置されたイメージを当該ＷＥＢページ中に表示するような場合がこれにあたる。
【００９３】
なお、このとき、ステップＳ８０２で要求している画像ファイルが低解像度のサムネイル画像で、かつ対象画像がＤＣＦ規格に準拠していれば、ショートカット画像フォーマットであるか否かの区別をすることなく、画像のサムネイル画像を転送すればよい。また、対象画像がＤＣＦ規格に準拠しておらず、サムネイルを含まない画像ファイルであったとしても、必要な解像度にアプリケーションＡが縮小すればよい。
【００９４】
なお、本実施例では画像データ転送の詳細については特に規定しないが、たとえば、アプリケーションＢがショートカット画像「ａ」の画像ファイルにおいて、ＤＣＦ規定に従ったサムネイル画像ファイルを展開し、画像データのみをアプリケーションＡに転送してもよい。
【００９５】
一方、ステップＳ８０２で要求する画像データが高解像度の画像データである場合は、ステップＳ８０４以降で対象画像がショートカット画像フォーマットであるときはオリジナル画像を取得する処理（Ｓ８０５〜）を行い、対象画像がショートカット画像フォーマットでないときは、その画像の主画像を転送する処理（Ｓ８０６）を行なう。たとえば、ＷＥＢブラウザにおいては、「画像を表示」や「Ｖｉｅｗ  Ｉｍａｇｅ」（画像のみを１ページ内に表示する）、あるいは「画像をセーブ（ダウンロード）」や「Ｓａｖｅ  Ｉｍａｇｅ」のようなメニューアイテムが選択された場合、このような処理を行なう。
【００９６】
まず、ステップＳ８０４で対象とする画像が、本発明の分割管理フォーマットに対応したショートカット画像であるか否かを判別する。本実施例ではショートカット画像であるか否かの判別基準について特に規定しないが、たとえば、対象画像ファイルの任意のＥｘｉｆタグ（たとえばメーカーノーツタグ）に、ショートカット画像である旨の情報が記録されているか否かで判別してもよいし、対象画像ファイルにアドレスタグが存在するか否かで判別してもよい。
【００９７】
ステップＳ８０４で対象とする画像ファイルがショートカット画像のフォーマットでなければ、オリジナル画像を取得する必要がないため、ステップＳ８０６で当該画像の主画像データを転送する一般的な画像ファイルの展開処理が行われる。また、対象画像がショーカット画像であっても、その画像が主画像を有していれば、ステップＳ８０５以降のオリジナル画像転送処理を行わずに、ステップＳ８０６でショートカット画像の有する主画像データを転送してもよい。もちろん、対象画像がショートカット画像フォーマットであり、かつ、主画像を有していても、主画像データを無視してステップＳ８０５以降のオリジナル画像を取得する処理を行ってもよい。
【００９８】
ステップＳ８０４で対象画像がショートカット画像フォーマットでありオリジナル画像を取得するのであれば、ステップＳ８０５でそのショートカット画像からアドレスタグを取得する。具体的には図２〜４で説明したようなファイルフォーマットのアドレスタグに記録されるＶａｌｕｅからオリジナル画像へのアドレスを示す文字列を取得する。たとえば、本実施例では、ショートカット画像「ａ」のアドレスタグから「ｈｔｔｐ：／／ｗｗｗ．ｃａｎｏｎ．ｃｏ．ｊｐ／ｏｒｉｇｉｎａｌ−ｉｍａｇｅ／  Ａ．ＪＰＧ」をオリジナル画像のアドレスを示す文字列として取得する。
【００９９】
このあとステップＳ８０７で、取得したアドレスが有効な値であるか否かの判別を行なうことができる（実装によってはこのステップＳ８０７の判定を省略してもよい）。もし、ステップＳ８０７で取得したアドレスの値が無効である（たとえば、ＤＮＳ検索などによりサーバのアドレスを解決できないような場合がこれにあたる）と判別されれば、ステップＳ８０９でエラー処理を行なう。本実施例では、ステップＳ８０９において転送できないオリジナル画像データの代替にショートカット画像の画像データを転送する。また、たとえば「有効なアドレスタグがありませんでした」旨のエラー通知を行って、処理を終了してもよい。
【０１００】
ステップＳ８０７で有効なアドレスタグであることが判別されれば、取得したオリジナル画像へのアドレスにしたがって、ステップＳ８０８でオリジナル画像を取得するための処理が行われる。本実施例では、オリジナル画像への取得処理については特に規定しないが、たとえばアプリケーションＡからアプリケーションＣへ向けてＦＴＰ（あるいはＨＴＴＰなど任意のデータ転送プロトコル）によるデータ転送要求を行なうものとする。
【０１０１】
ステップＳ８１０でオリジナル画像へのアクセスに失敗（サーバのアプリケーションＣが該当のオリジナル画像のファイルを指定された位置に発見できないなどの場合がこれにあたる）した場合にはステップＳ８１２でエラー処理を行なう。本実施例では、ステップＳ８１２においてオリジナル画像データの代替にショートカット画像の画像データを転送する。あるいは、たとえば「オリジナル画像へのアクセスに失敗しました」旨の処理、たとえば、「オリジナル画像にアクセスできませんでした」等の表示を行って処理を終了してもよい。
【０１０２】
なお、本実施例では、アクセスができたか否かを判別する基準について特に規定しないが、たとえばアドレスの示す領域にオリジナル画像が存在しなかったり、何らかの理由によりアドレスの示す領域にアクセスできなかったときに、ステップＳ８１０でアクセスができなかったと判定することができる。これらの判定は、たとえばＦＴＰやＨＴＴＰにおいて、サーバから返送される（２００、４０３、４０４といった）リザルトコードを識別することにより可能である。
【０１０３】
ステップＳ８１０でアプリケーションＡからオリジナル画像「Ａ」のＦＴＰ（あるいはＨＴＴＰなど任意のデータ転送プロトコル）による転送要求がアプリケーションＣに許可されたら、ステップＳ８１１でアプリケーションＡにオリジナル画像「Ａ」の画像データを転送する処理が行われる。なお、本実施例で画像データの詳細な転送処理については特に規定しないが、たとえばアプリケーションＣがオリジナル画像「Ａ」の画像ファイルにおいて、ＤＣＦ規定に従った主画像ファイルを展開し、画像データのみをアプリケーションＡに転送してもよい。
【０１０４】
上記のようにして、ステップＳ８０３、Ｓ８０６、Ｓ８０９、Ｓ８１１、Ｓ８１２で転送された画像データは、この転送の要因となったユーザ指令に応じて処理されるのはいうまでもない。たとえば、ＷＥＢブラウザの場合は、上記のイメージのＷＥＢページ中への通常表示、ユーザ指令の「画像を表示」や「Ｖｉｅｗ  Ｉｍａｇｅ」（画像のみを１ページ内に表示する）に対応した画像表示、あるいはユーザ指令の「画像をセーブ（ダウンロード）」や「Ｓａｖｅ  Ｉｍａｇｅ」に対応した画像ファイルデータのセーブなどが実行される。
【０１０５】
以上のように、本実施例によれば、アプリケーションＡはショートカット画像「ａ」のアドレスタグからオリジナル画像「Ａ」の格納位置を取得して、必要があればオリジナル画像「Ａ」の画像データを取得することができる。また、アプリケーションＡがショートカット画像「ａ」のサムネイル画像データのみを取得したいときや、オリジナル画像「Ａ」の画像データを取得したかったが、ショートカット画像のアドレスタグがなかったり、オリジナル画像がアドレスタグの示す格納位置に存在しなかった等の理由から、処理が中断されたときには、ショートカット画像「ａ」の画像データを転送することができる。
【０１０６】
本実施例の転送手順によれば、ショートカット画像のアドレスタグには、オリジナル画像の保存されているアドレスが記録されているため、ショートカット画像にアクセス可能なアプリケーションまたは画像制御装置は、必要に応じてオリジナル画像の格納場所へアクセスすることが可能である。
【０１０７】
なお、ショートカット画像にアクセス可能な画像処理装置やＰＣのアプリケーションがショートカット画像に付与されたオリジナル画像のアドレスを利用してオリジナル画像を取得する手段や手順は任意に当業者が実装できる。たとえば、これらの装置やアプリケーションは、ショートカット画像に格納されたオリジナル画像のアドレスタグを抽出し、任意のインターフェースを経由してオリジナル画像をダウンロード、あるいはコピー、読み取ることができればよく、また、アドレスタグの抽出に関しては、アドレスタグはＤＣＦ／Ｅｘｉｆ形式のＡＰＰ１データとして格納されているため、たとえばアドレスタグのタグ番号を認識し、その内容を取り出すだけでよく、既存のソフトウェアを大きく変更することなくアドレスタグを抽出することができる。
【０１０８】
また、上記実施例では、アドレスタグをＵＲＬ（ＵＲＩ）形式で格納するようにしているので、オリジナル画像の格納場所はリモートホストの格納場所だけではなく、ローカルフォルダの格納場所も表現でき、非常に柔軟な運用が可能である。また、ＵＲＬ（ＵＲＩ）形式によれば、そのアクセス方法も指定できるため、種々のアクセスメソッド（以上の例ではオリジナル画像がＨＴＴＰを介してアクセスされる例を示したが、ＵＲＬ（ＵＲＩ）形式によればもちろんＦＴＰその他のアクセスメソッドを指定できるのはいうまでもない）を介してオリジナル画像をユーザに入手させることができる。
【０１０９】
本実施例では、ショートカット画像ファイルのサムネイル画像は新たに生成する他、既にデジタルカメラなどで用いられているＤＣＦ／Ｅｘｉｆ形式のＡＰＰ１データとして格納されたサムネイルデータがあればそれを用いる（主画像はＮＵＬＬデータとする）ようにしているため、少ない計算コストで高速にショートカット画像ファイルを生成することができる。
【０１１０】
あるいは、本実施例では、ショートカット画像ファイルの主画像として縮小画像（図１の１０６ａ）を用いるようにしてもよい。このようにショートカット画像ファイルの主画像として縮小画像を格納しておけば、ショートカット画像ファイルのサイズを抑えながら、しかもユーザは充分画像の細部を認識することができる（特別な改造をしなくても通常のＥメールアプリケーションあるいは画像ビューワはこのショートカットファイルに主画像として格納された縮小画像の方を表示できると考えられる）。
【０１１１】
また、ショートカット画像ファイルの主画像として縮小画像（１０６ａ）を格納しておく方式によれば、抽出したアドレスタグを参照してオリジナル画像のダウンロードを行なおうとしたがリモートホストやサーバなどに格納しているはずのオリジナル画像が消去されてしまっているような場合においても、ショートカット画像に含まれているサムネイル画像より大きいサイズの縮小画像をオリジナル画像の代わりにユーザに利用させることもできる。縮小画像（１０６ａ）の縮小比率をＤＣＦ／Ｅｘｉｆ形式で用いられているサムネイル画像よりも小さくしておけば、オリジナル画像が消去されてしまっている場合でもユーザの画像利用の目的を達成できる可能性を高めることができる。また、比較的大きいサイズのディスプレイを有する携帯端末などにおいてはＤＣＦ／Ｅｘｉｆ形式で用いられているサムネイル画像では小さすぎ、画像の細部を充分視認できない場合があるが、この縮小画像を利用すれば大きいサイズのディスプレイを有効に活用することができる。
【０１１２】
以上のように、本実施例によれば、第１のオリジナル画像ファイルのうち、第１の画像よりも低解像度な第２の画像ファイル（ショートカット画像ファイル）を、第１の画像ファイルから切り分け、あるいは新たに第２の画像ファイルを生成し、この第２の画像ファイルに第１の画像ファイルの格納場所を付加する構成を採用しており、画像の概要を知りたいときにはファイルサイズの小さい第２の画像ファイルの画像データのみを利用し、画像の詳細を知りたいときには、第２の画像ファイルのみを手がかりに、第１の画像ファイルの高解像度の画像データを利用できるという優れた効果がある。特に、第２の画像ファイルそれ自体に第１の画像ファイルの格納場所がアドレスタグとして含まれているため、たとえば第２の画像ファイルを送信したメール本文などを紛失してしまっても第２の画像ファイルのみから第１の画像ファイルに到達できる、という優れた効果がある。
【０１１３】
さらに、第２の画像ファイルのフォーマットとしては、ショートカット、エイリアス、シンボリックリンクなどとは異なり、それ自体、画像ファイルとして通用するＤＣＦ／Ｅｘｉｆ形式を用いているため、ＪＰＥＧ形式の画像ファイルを取り扱える通常のアプリケーション（画像ビューワ、ＷＥＢブラウザその他）であれば、第２の画像ファイルを表示したり、あるいは必要であれば編集したりすることができる、という優れた効果がある。
【０１１４】
特に、本実施例におけるショートカット画像ファイルのサムネイル画像ないし縮小画像を用いる格納形式を利用する画像データの転送においては、リモートホストやサーバなどに格納しているはずのオリジナル画像が消去されてしまっているような場合においても、最低限のバックアップ用途に利用することができる。
【０１１５】
一般に、ＰＣなどで利用されているメイラー（あるいはメイラー機能を有するブラウザなど）は、オリジナル画像ファイルのリンクをメールなどで受信したが、そのリンク先のオリジナル画像ファイルが消去されてしまっている場合は、全く画像を表示することができない。
【０１１６】
しかしながら、本実施例におけるようにサムネイル画像ないし縮小画像を含むショートカット画像ファイルによれば、オリジナル画像ファイルが消去されてしまっている場合でも、ショートカット画像ファイルのサムネイル画像ないし縮小画像を表示することができ、通信の目的を達成する可能性を高めることができる。
【０１１７】
図８の転送手順の説明で示したようにオリジナル画像ファイルが消去されてしまっている場合にショートカット画像ファイルのサムネイル画像ないし縮小画像をバックアップ表示（あるいはセーブ／記録出力）に用いるためには現行のメイラー（あるいはメイラー機能を有するブラウザなど）を多少改造する必要があるかもしれないが、たとえば上記図８の転送手順の説明において例示したようにＷＥＢブラウザを改造する、すなわち、オリジナル画像ファイルが取得不可能な場合にショートカット画像ファイルのサムネイル画像ないし縮小画像を表示するサブルーチンを追加するだけで良いから、この改造に必要なコストはそれ程大きくない。
【０１１８】
すなわち、本実施例によれば、オリジナル画像ファイルと、そのアドレスタグを含むショートカット画像ファイルを用い、画像データを分割記録し、データ利用（転送：表示、印刷、セーブ（コピー））に際してショートカット画像ファイルのアドレスタグに基づきオリジナル画像ファイルを転送するか、条件に応じて、たとえばオリジナル画像ファイルが転送不可の場合（たとえばオリジナル画像ファイルを保有するサーバ／ホストに到達不能、あるいは該サーバ／ホストからオリジナル画像ファイルが消去されているような場合）ショートカット画像ファイルを転送するようにしているため、オリジナル画像ファイルが転送不可の場合は、元の画像情報にアクセスできないにしても、最低限の情報をショートカット画像ファイルから取得でき、ショートカット画像ファイルを画像データのバックアップ用途に利用できる、という優れた効果がある。
【産業上の利用可能性】
【０１１９】
本発明のうち装置発明は任意の画像処理装置に実施することができる。また、本発明の方法ないしプログラムは適当な記憶媒体経由、あるいはネットワーク経由で対象の画像処理装置（ＰＣ、デジタルカメラ、など任意の画像処理装置）に導入することができる。
【図面の簡単な説明】
【０１２０】
【図１】本発明の画像の分割管理に使用されるオリジナル画像とショートカット画像の構成を示した説明図である。
【図２】図１のショートカット画像に付与されるアドレスタグの構成を示した説明図である。
【図３】本発明の画像の分割管理方式の一例を示した説明図である。
【図４】本発明の画像の分割管理方式の一例を示した説明図である。
【図５】本発明の画像の分割管理方式における転送処理の一例を示した説明図である。
【図６】本発明の画像の分割管理方式における転送処理の一例を示した説明図である。
【図７】本発明の画像の分割管理方式における転送処理の一例を示した説明図である。
【図８】本発明の画像の分割管理方式における転送制御手順を示したフローチャート図である。
【図９】本発明を実施可能な処理環境および画像処理装置の構成を示した説明図である。
【符号の説明】
【０１２１】
１００  オリジナル画像
１０１  ショートカット画像
１０５  ＡＰＰ１データセグメント
１０６  ＤＣＦ基本主画像
５０１、６０１、７０１、９０１  ターミナル
５０２、６０２、７０２、９０２  サーバ
９０３  ネットワーク
９０４  ＣＰＵ
９０５  メモリ
９０６  ＨＤＤ
９０７  画像入力手段
９０８  インターフェース
９１０  ネットワークインターフェース
【図１】
2006139632.tif 000003
【図２】
2006139632.tif 000004
【図３】
2006139632.tif 000005
【図４】
2006139632.tif 000006
【図５】
2006139632.tif 000007
【図６】
2006139632.tif 000008
【図７】
2006139632.tif 000009
【図８】
2006139632.tif 000010
【図９】
2006139632.tif 000011