以下、本発明の実施形態について添付の図面を参照して具体的に説明する。
(第1の実施形態)
先ず、本発明の第1の実施形態について説明する。図1は、本発明の第1の実施形態に係る画像ファイル管理方法の実行に用いられる画像ファイル管理システムを示す図である。
図1に示すように、この画像データ処理システムには、サーバ1401と、ネットワーク1405を介してこのサーバ1401に接続されたターミナル(端末装置)1406とが含まれている。サーバ1401の内部には、CPU1402、メモリ1403及びHDD1404等が含まれている。また、HDD1404には、例えば、オンラインフォトアルバムサービス等の提供に関するプログラムが記録されている。ターミナル1406は、例えば、パーソナルコンピュータであり、その内部には、CPU1407、メモリ1408、HDD1409等が含まれている。本実施形態では、サーバ1401及びターミナル1406が画像ファイル管理装置として機能する。なお、ターミナル1406として、スキャナ、デジタルカメラ又はPDA等を用いてもよい。なお、サーバ1401として、プリンタ等を用いてもよい。また、ネットワーク1405として、USB等のローカル環境における通信等を用いてもよい。
また、サーバ1401及びターミナル1406に入力インタフェースが設けられており、画像ファイルを格納した画像記録装置1410がサーバ1401及びターミナル1406に接続可能となっている。画像記録装置1410は、例えばデジタルカメラである。
ここで、本実施形態において処理される画像ファイルのフォーマットについて説明する。本実施形態では、オリジナル画像ファイル(派生元画像ファイル)及びショートカット画像ファイル(画像ファイル)の2種類の画像ファイルが処理対象となっている。オリジナル画像ファイルは、例えばデジタルカメラ(撮像装置)による撮影により得られた画像(オリジナル画像)データを含むファイルであって解像度が高い画像データ(オリジナル画像データ)を含む。一方、ショートカット画像ファイルは、オリジナル画像データに基づいて作成されたオリジナル画像データよりも解像度が低い画像(ショートカット画像)データを含むファイルである。ショートカット画像ファイルには、少なくとも、オリジナル画像データのサムネイル画像のデータ及びオリジナル画像ファイルの所在位置を示す情報が含まれている。
また、本実施形態では、画像ファイルの基本フォーマットとしてDCF/Exif形式を用いる。従って、以下の説明では、画像ファイルの特定部分を示す用語として必要に応じてDCF/Exif(Exchangeable Image File)規格(又はJPEG規格)において対応する部分を示す用語を用いる。
図2は、オリジナル画像ファイル(派生元画像ファイル)及びショートカット画像ファイルのフォーマットを示す模式図である。
先ず、オリジナル画像ファイル100について説明する。オリジナル画像ファイル100のDCF基本ファイルのフォーマットには、「SOI(Start of Image)」102、「APP1」103、DCF基本主画像データ104及び「EOI(End of Image)」105が含まれている。「SOI」102は、圧縮画像データの先頭を示すマーカーコード(通常0xFFD8)である。「EOI」105は、「SOI」102と対をなして圧縮画像データの終了を示すマーカーコード(通常0xFFD9)である。DCF規格においては、SOIから始まりEOIでデータが終わるように規定されている。「APP1」103はアプリケーションマーカーセグメントであり、主画像の付加情報及び低解像度の画像データであるサムネイル画像データ106が「APP1」103のデータ領域に格納される。サムネイル画像データ106のファイルのフォーマットには、「SOI」102、「APP1」107、DCF基本サムネイル画像データ108及び「EOI」105が含まれている。そして、DCF基本ファイルと同様に、SOIから始まりEOIでデータが終わるように規定されている。なお、サムネイル画像データ106の「APP1」107はDCF基本ファイルの「APP1」103と同じ内容のデータを有していてもよい。DCF基本サムネイル画像データ108に対し、DCF基本主画像データ104は高解像度の画像データとなっている。
このように、本実施形態におけるDCF規格に準拠したオリジナル画像ファイル100には、低解像度のDCF基本サムネイル画像データ108と高解像度のDCF基本主画像データ104(第1の画像データ)とが含まれている。従って、ユーザは、画像の概要を知りたいときにはDCF基本サムネイル画像データ108を参照し、画像の詳細を知りたいときにはDCF基本主画像データ104を、夫々参照すればよい。
次に、ショートカット画像ファイル101について説明する。ショートカット画像ファイル101のDCF基本ファイルのファイルフォーマットには、「SOI」102、「APP1」113、ヌル(NULL)データ114及び「EOI」105が含まれている。「APP1」113のデータ領域には、サムネイル画像データ116が格納される。更に、オリジナル画像ファイル100の格納場所を示すアドレスタグ121、及び、ショートカット画像ファイル101に対応するオリジナル画像ファイル100の削除に関する情報を示す削除タグ122も、「APP1」113のデータ領域に格納される。削除タグ122が「可」を示している場合、当該ショートカット画像ファイル101が削除されると、これに対応するオリジナル画像ファイル100も削除される。つまり、削除タグ122がオリジナル画像ファイル100の削除を肯定している場合には、オリジナル画像ファイル100も削除される。一方、削除タグ122が「否」を示している場合には、当該ショートカット画像ファイル101が削除されても、これに対応するオリジナル画像ファイル100は削除されない。このように、オリジナル画像ファイル100とは異なり、DCF基本主画像データが必要とされず、その代りにNULLデータ114が格納されている。サムネイル画像データ116(第2の画像データ)のファイルのフォーマットには、「SOI」102、「APP1」117、DCF基本サムネイル画像データ118及び「EOI」105が含まれている。そして、DCF基本ファイルと同様に、SOIから始まりEOIでデータが終わるように規定されている。なお、サムネイル画像データ116の「APP1」117はDCF基本ファイルの「APP1」113と同じ内容のデータを有していてもよい。
このように、本実施形態におけるショートカット画像ファイル101はDCF規格に準拠しつつ、その「APP1」113のデータ領域に、アドレスタグ121及び削除タグ122が付与されている。また、主画像データは不要である。
なお、ショートカット画像ファイル101に主画像データが含まれていてもよい。また、一つのオリジナル画像ファイル100に対して、複数のショートカット画像ファイル101が存在していてもよい。また、アドレスタグ121が含まれていれば、当該ファイルがショートカット画像ファイル101であると認識できるが、その他に、当該ファイルをオリジナル画像データと識別するためのタグ等の標識が付されていてもよい。
次に、アドレスタグ121のデータ構成について説明する。図3は、アドレスタグ121のデータ構成を示す図である。
アドレスタグ121に相当するアドレスタグ200は、Exif(DCF)規約に基づき「Exif IFD」内に記録される。アドレスタグ200のタグ番号としては、Tiffのプライベートタグ番号(例えば、43000)が利用される。
アドレスタグ200の内容を示すタグのValueは、「Value of Exif IFD」内に記録される。Valueの格納場所は、アドレスタグ200の「Value Offset」に記される。アドレスタグ200の「Tag」、「Type」、「Count」、「Value Offset」は特に規定しないが、例えば「Type」は「ANY」、「Count」も「Any」としておく。
アドレスタグ200の内容201(アドレスタグのValue)は、例えば次のように構成されている。即ち、図3に示すように、「アドレスタグのValue」の先頭には、以降続く文字コードを識別するための文字コード種別情報202が記録される。この文字コード種別情報202としては、例えばASCIIコード、JISコード、Unicode、又はそれ以外の文字コードが指定される。
文字コード種別情報202に続いて、オリジナル画像ファイル100の格納場所を示すアドレス文字列203が「アドレスタグのValue」に記録される。アドレス文字列203には、オリジナル画像ファイル100の格納場所を示すパス名と、オリジナル画像ファイルのファイル名とが含まれる。「アドレスタグのValue」へのオフセットは、TIFFの規定に従ってアドレスタグ200の「Value Offset」に記される。
なお、「アドレスタグのValue」に、文字コード種別情報202が記録されずに、オリジナル画像ファイル100のアドレスを示す文字列203のみが記録されてもよい。例えば、文字コードとして一定のコード(例えばUTF−8)を固定的に用いる場合には、文字コード種別情報202は必要ない。一方、UTF−16で符号化する場合は、ISO/IEC 10646の附属書E及びUnicodeの付録Bで規定するバイト順マーク(「ZERO WIDTH NO−BREAK SPACE文字」、0xFEFF又は0xFFFE)で始まらなければならない。また、明示的にUTF−8であることを識別するために、先頭の3バイトに識別コード(0xEF 0xBB 0xBF)を入れてもよい。
また、「アドレスタグのValue」は、UDFに従って記録されてもよい。このときは、Valueの先頭1バイトに文字コード種別、次の1バイトに文字列長、続けてオリジナル画像の格納場所を示すアドレス文字列が記録される。
本実施形態では、このようなアドレスタグ121が各ショートカット画像ファイル101に付与されている。このため、ショートカット画像ファイル101にアクセス可能なアプリケーション又は画像制御装置は、ショートカット画像ファイル101から、これに対応するオリジナル画像ファイル100の格納場所を取得することができる。従って、例えば、オリジナル画像ファイル100をファイルサイズが大きい場合でも、これをサーバ1401等に格納しておけば、ファイルサイズの小さいショートカット画像ファイル101を介して容易にオリジナル画像ファイル100を使用することができる。即ち、ターミナル1406の記憶容量が小さい場合でも、容易にかつ的確にオリジナル画像ファイル100にアクセスすることができる。
また、画像データの概要だけわかればよい場合には、画像を格納するメモリエリアを圧迫しないファイルサイズの小さいショートカット画像ファイル101を利用すればよい。また、画像に対する詳細な情報を得たい場合には、オリジナル画像ファイル100を利用すればよい。
次に、削除タグ122のデータ構成について説明する。図4は、削除タグ122のデータ構成を示す図である。
削除タグ122に相当する削除タグ700は、Exif(DCF)規約に基づき「Exif IFD」内に記録される。削除タグ700のタグ番号としては、Tiffのプライベートタグ番号(例えば、43001)が利用される。
削除タグ700の内容を示すタグのValueは、「Value of EXIF IFD」内に記録される。Valueの格納場所は、削除タグ700の「Value Offset」に記される。削除タグ700の「Tag」、「Type」、「Count」、「Value Offset」は特に規定しないが、例えば「Type」は「ANY」、「Count」も「Any」としておく
削除タグ700の内容701(削除タグのValue)は、例えば次のように構成されている。即ち、図4に示すように、「削除タグのValue」の先頭には、以降続く文字コードを識別するための文字コード種別情報702が記録される。この文字コード種別情報702にとして、例えばASCIIコード、JISコード、Unicode、又はそれ以外の文字コードが指定される。
文字コード種別情報702に続いて、オリジナル画像ファイル100の削除の可否を示す文字列703が「削除タグのValue」に記録される。「削除タグのValue」へのオフセットは、TIFFの規定に従って削除タグ700の「Value Offset」に記される。
なお、「削除タグのValue」には、文字コード種別情報702が記録されずに、オリジナル画像ファイル100の削除に関する情報を示す文字列703のみが記録されてもよい。例えば、文字コードとして一定のコード(例えばUTF−8)を固定的に用いる場合には、文字コード種別情報702は必要ない。一方、UTF−16で符号化する場合は、ISO/IEC 10646の附属書E及びUnicodeの付録Bで規定するバイト順マーク(「ZERO WIDTH NO−BREAK SPACE文字」、0xFEFF又は0xFFFE)で始まらなければならない。また、明示的にUTF−8であることを識別するために、先頭の3バイトに識別コード(0xEF 0xBB 0xBF)を入れてもよい。
また、「削除タグのValue」は、UDFに従って記録されてもよい。このときは、Valueの先頭1バイトに文字コード種別、次の1バイトに文字列長、続けてオリジナル画像の格納場所を示すアドレス文字列が記録される。
本実施形態では、このような削除タグ122が各ショートカット画像ファイル101に付与されている。このため、ショートカット画像ファイル101にアクセス可能なアプリケーション又は画像制御装置は、ショートカット画像ファイル101から、これに対応するオリジナル画像ファイル100の削除に関する情報を取得することができる。従って、ショートカット画像ファイル101を削除しようとする際に、これに対応するオリジナル画像ファイル100を削除してよいかどうかを容易に判断することができる。
次に、オリジナル画像ファイル100からショートカット画像ファイル101を作成する方法について説明する。図5は、ショートカット画像ファイル101を作成する方法を示すフローチャートである。ショートカット画像ファイル101の作成は、サーバ1401、ターミナル1406及び画像記録装置1410のいずれにおいても可能であるが、以下の説明では、サーバ1401において作成されるものとする。なお、ターミナル1406又は画像記録装置1410において作成される場合にも同様の処理が実行される。
先ず、CPU1402が、ショートカット画像ファイルを作成しようとするオリジナル画像ファイル100を参照する(ステップS500)。以下の説明では、オリジナル画像ファイル100のファイル名が「IMG_0011.JPG」であるとする。なお、オリジナル画像ファイル100の格納場所は、CPU1402がアクセス可能な範囲内であれば、特に限定されない。例えば、サーバ1401内に格納されていてもよく、ターミナル1406又は画像記録装置1410内に格納されていてもよい。
次に、CPU1402は、当該オリジナル画像ファイル100に対応するサムネイル画像データ106が存在するか否かを判別する(ステップS501)。
そして、ステップS501の結果、当該オリジナル画像ファイル100にサムネイル画像データ106が存在すれば、CPU1402は、当該サムネイル画像データ106を抽出する(ステップS504)。次いで、CPU1402は、当該サムネイル画像データ106をサムネイル画像データ116とすると決定する(ステップS505)。
一方、ステップS501の結果、当該オリジナル画像ファイル100にサムネイル画像データ106が存在しなければ、CPU1402は、オリジナル画像ファイル100の主画像データ104から任意の間引きを行う。つまり、CPU1402は、主画像データ104から縮小画像データを作成する(ステップS502)。次いで、CPU1402は、当該縮小画像データをサムネイル画像データ116とすると決定する(ステップS503)。
このようにして、オリジナル画像ファイル100のサムネイル画像データ106、又はオリジナル画像ファイル100の主画像データ104を縮小した画像データがサムネイル画像データ116として取得される。
ステップS503又はS505の後、CPU1402は、当該オリジナル画像ファイル100の格納予定場所を示すアドレスタグ121を生成する。そして、CPU1402はこれをサムネイル画像データ116(ステップS503又はS505)に付与する(ステップS506)。この処理の詳細については後述する。
その後、CPU1402は、当該オリジナル画像ファイル100の削除に関する情報を示す削除タグ122を生成する。そして、CPU1402は、これをサムネイル画像データ116(ステップS503又はS505)に付与する(ステップS507)。この削除タグ作成の処理の詳細については後述する。
このようにして、ショートカット画像ファイル101のファイル作成が行われる。ファイル名が「IMG_0011.JPG」のオリジナル画像ファイル100に対して作成されたショートカット画像ファイル101のファイル名は、例えば「img_0011.JPG」とする。
なお、ショートカット画像ファイル101に、オリジナル画像ファイル100と同じ主画像データ104を含ませてもよい。
また、デジタルカメラ(画像記録装置1410)における写真撮影に伴うオリジナル画像ファイル100の作成に続けて、図5に示すフローに従ってショートカット画像ファイル101が作成されてもよい。つまり、ショートカット画像ファイル101の作成処理がオリジナル画像ファイル100の作成処理と一連のものとなっていてもよい。
次に、ステップS506におけるアドレスタグ121を作成する方法について説明する。図6は、アドレスタグ121を作成する方法を示すフローチャートである。
アドレスタグ121には、オリジナル画像ファイル100の格納場所を示すパス名(文字列B)602、オリジナル画像ファイル100のファイル名(文字列C)603、並びに文字列B及びCの文字コードを示す文字コード種別情報(文字列A)601が含まれる。なお、上述のように、文字コード種別情報(文字列A)601が含まれていなくてもよい。
先ず、CPU1402は、当該オリジナル画像ファイル100のアドレスをどのように決定するのかを判別する(ステップS604)。ここでは、オリジナル画像ファイル100の現在の格納場所をオリジナル画像ファイル100の格納予定場所とするか、それ以外の任意の場所をオリジナル画像ファイル100の格納予定場所とするか判断する。
そして、ステップS604の結果、現在の格納場所をオリジナル画像ファイル100の格納予定場所とする場合、CPU1402は、現在のオリジナル画像ファイル100の格納場所(アドレス)をパス名(文字列B)602として取得する(ステップS605)。
一方、ステップS604の結果、任意の格納場所をオリジナル画像ファイル100の格納予定場所とするのであれば、当該任意の格納場所を示す文字列をパス名(文字列B)602として取得する(ステップS606)。任意の格納場所は、例えば、サーバ1401上で動作するアプリケーション等を用いてユーザが設定する。例えば、オリジナル画像ファイル100が常にサーバ1401の「http://www.canon.co.jp/original-image/」に格納されることが設定される。
ここでは、オリジナル画像ファイル100の格納予定場所として、予め「http://www.canon.co.jp/original-image/」が設定されているとする。従って、「http://www.canon.co.jp/original-image/」がパス名(文字列B)602として取得される。
ステップS605又はS606の後、CPU1402は、オリジナル画像ファイル100のファイル名(文字列C)603を取得する(ステップS607)。ここでは、「IMG_0011.JPG」がファイル名(文字列C)603として取得される。
次いで、CPU1402は、文字コード種別情報(文字列A)601、パス名(文字列B)602、及びファイル名(文字列C)603を結合させて、オリジナル画像ファイル100のアドレスを示す文字列を作成する(ステップS608)。このとき、文字コード種別情報(文字列A)601を含ませなくてもよい。例えば、文字列B及び文字列CをUTF−8で符号化して記述する場合には、文字列Aは不要となる。
その後、CPU1402は、ステップS607で作成した文字列をValueとするアドレスタグ121を作成し、これをサムネイル画像データ116(ステップS503又はS505)に付与する(ステップS609)。ここでは、「http://www.canon.co.jp/original-image/ IMG_0011.JPG」をValueとするアドレスタグ121が、ファイル名が「img_0011.JPG」であるショートカット画像ファイル101に付与される。
次に、ステップS507における削除タグ122を作成する方法について説明する。図7は、削除タグ122を作成する方法を示すフローチャートである。
削除タグ122には、オリジナル画像ファイル100の削除に関する情報を示す削除情報(文字列B)802、及び文字列Bの文字コードを示す文字コード種別情報(文字列A)801が含まれる。なお、上述のように、文字コード種別情報(文字列A)801が含まれていなくてもよい。
先ず、CPU1402は、削除タグ122を付与しようとしているショートカット画像ファイル101が、当該オリジナル画像ファイル100にとって最初に作成されるショートカット画像ファイル101であるかどうかを判別する(ステップS803)。言い換えると、CPU1402は、当該オリジナル画像ファイル100から初めてショートカット画像ファイル101が作成されている過程にあるかどうかを判別する。
そして、ステップS803の結果、最初のショートカット画像ファイル101であれば、CPU1402は、削除情報(文字列B)802を「可」に決定する(ステップS805)。
一方、ステップS803の結果、最初のショートカット画像ファイル101ではなければ、CPU1402は、削除情報(文字列B)802を「否」に決定する(ステップS804)。これは、オリジナル画像ファイル100を削除できるショートカット画像ファイル101が複数存在する状態になることを防止するためである。
ここでは、ファイル名が「IMG_0011.JPG」のオリジナル画像ファイル100に最初のショートカット画像ファイル101が作成されていることとする。従って、「可」が削除情報(文字列B)802として決定される。
ステップS804又はS805の後、CPU1402は、文字コード種別情報(文字列A)801、及び削除情報(文字列B)802を結合させて、削除の可否に関する文字列を作成する(ステップS806)。このとき、文字コード種別情報(文字列A)801を含ませなくてもよい。
その後、CPU1402は、ステップS806で作成した文字列をValueとする削除タグ122を作成し、これをサムネイル画像データ116(ステップS503又はS505)に付与する(ステップS807)。ここでは、「可」をValueとする削除タグ122が付与される。
このようにして(図5〜図7)、オリジナル画像ファイル100からショートカット画像ファイル101が作成される。例えば、サーバ1401に保存されるファイル名が「IMG_0011.JPG」のオリジナル画像ファイル100に対応するファイル名が「img_0011.JPG」のショートカット画像ファイル101が作成される。そして、このショートカット画像ファイル101のアドレスタグ121には、オリジナル画像ファイル100が保存されている場所(「http://www.canon.co.jp/original-image/ IMG_0011.JPG」)を示すアドレスタグ121が記録されている。このため、ショートカット画像ファイル101にアクセス可能なアプリケーション又は画像制御装置は、必要に応じてオリジナル画像ファイル100の格納場所へアクセスすることが可能である。
次に、上述のようにして作成されたオリジナル画像ファイル100及びこれに対応するショートカット画像ファイル101に対する、図1に示す画像データ処理システムにおける管理の方法の例について説明する。図8は、オリジナル画像ファイルとショートカット画像ファイルとの関係の一例を示す図である。
上述のようにしてサーバ1401においてショートカット画像ファイル101が作成されると、当該ショートカット画像ファイル101は、例えば電子メール等を用いてターミナル1406に送信される。この結果、図8に示すように、サーバ1401にオリジナル画像ファイル100が格納され、ターミナル1406にショートカット画像ファイル101が格納される。ここでは、4種類のオリジナル画像ファイル100(A、B、C、D)がサーバ1401の所定の格納予定場所(「http://www.canon.co.jp/original-image/」)に格納されているとする。また、上記4種類のオリジナル画像ファイル100に夫々対応するショートカット画像ファイル101(a、b、c、d)が、ターミナル1406の格納場所、例えば「C:\My Pictures\shortcut-image\」で表わされる場所に格納されているとする。
この例の場合、図8に示すように、ファイル名が「IMG_0011.JPG」の「D」のオリジナル画像ファイル301の格納場所が「http://www.canon.co.jp/original-image/」である。このため、「d」のショートカット画像ファイル302のアドレスタグ121には、「http://www.canon.co.jp/original-image/IMG_0011.JPG」303が記録されている。「a」、「b」及び「c」のショートカット画像ファイルについても、これに準じたアドレスタグ121が記録される。
また、「d」のショートカット画像ファイル302は、「D」のオリジナル画像ファイル301から最初に作成されたショートカット画像ファイルであるとする。従って、「d」のショートカット画像ファイル302の削除タグ122には、「可」304が記録されている。「a」〜「c」のショートカット画像ファイルについては、当該ショートカット画像ファイルがこれらに対応する「A」〜「C」のオリジナル画像ファイルから最初に作成されたものであるか否かに応じて「可」又は「否」が記録されている。
このような状態が形成されると、ユーザはターミナル1406のHDD1409等に格納されたショートカット画像ファイル302のサムネイル画像を参照するだけで、サーバ1401に保存されているオリジナル画像ファイル301の概要を取得することができる。つまり、ユーザは、ターミナル1406をサーバ1401に接続せずとも、所望の情報を取得することができる。例えば、ユーザがデジタルカメラ(画像記録装置1410)における写真撮影によってオリジナル画像ファイル100を取得し、オンラインフォトアルバムサービス等を提供するサーバ1401に保存したとする。また、サーバ1401上においてオリジナル画像ファイル100からショートカット画像ファイル101を作成したとする。このような場合、ユーザは、ターミナル1406のHDD1409等に格納されたショートカット画像ファイル101のサムネイル画像を参照するだけで、当該オリジナル画像ファイル100に関する所望の情報を取得することができるのである。
また、PDA等の携帯端末ではメモリエリアに制限があるが、このような環境下においても、ショートカット画像ファイル101さえ保存しておけば、画像の概要を知ることはできる。また、ユーザが画像の詳細情報の取得を希望する場合には、サーバ1401からオリジナル画像ファイル100を取得すればよい。
また、オリジナル画像ファイル100の格納場所は限定されない。但し、特にサーバ1401にオリジナル画像ファイル100が格納されている場合には、サーバ1401に接続可能なターミナル1406からは、ショートカット画像ファイル101があれば、オリジナル画像ファイル100の詳細を取得することが可能である。従って、この場合には、ユーザ間で画像データの授受を行う際にショートカット画像ファイル101を利用してもよい。例えば、電子メールを用いて写真画像データを送信しようとする際に、主画像データを含まないショートカット画像ファイル101を添付すれば、オリジナル画像ファイル100自体を添付する場合と比較して電子メールのファイルサイズを小さくすることができる。そして、ショートカット画像ファイル101を受け取ったユーザは、希望する場合には、ショートカット画像ファイル101からサーバ1401にアクセスしてオリジナル画像ファイル100を取得したり、その詳細情報を取得したりすることができる。
なお、他のユーザとの間で、小さいファイルサイズで画像を授受する方法として、先に述べた特許文献1のように電子メールの指示に従ってオリジナル画像を取得する方法もある。しかしながら、この従来の方法では、その都度、電子メールの指示を参照する必要がある。これに対し、本実施形態によれば、ショートカット画像ファイル101にオリジナル画像ファイル100の格納場所が記録されているため、そのような煩雑な作業が不要となる。
また、本実施形態によれば、電子メール以外の手段でも、ファイルサイズの制限を少なくして、他のユーザとの間で画像データの授受を行うことができる。例えば、メモリカードにショートカット画像ファイル101のみを格納し、相手にメモリカードを渡せば、相手はそのメモリカードから任意のオリジナル画像ファイル100を取得することができる。このため、特許文献1のような電子メール自体が不要となる。
なお、詳細は後述するが、「d」のショートカット画像ファイル101の削除タグ122のValueは「可」304であるため、ショートカット画像ファイル101が削除されると、これに付随して「D」のオリジナル画像ファイル100も削除される。
次に、オリジナル画像ファイル100及びこれに対応するショートカット画像ファイル101に対する管理の方法の他の例について説明する。図9は、オリジナル画像ファイルとショートカット画像ファイルとの関係の他の一例を示す図である。図8に示す例では、オリジナル画像ファイル100及びショートカット画像ファイル101が互いに異なるホスト(サーバ1401、ターミナル1406)に夫々格納されている。これに対し、図9に示す例では、オリジナル画像ファイル100及びショートカット画像ファイル101が、一つのホスト(ターミナル1406)内の互いに異なるフォルダ(ディレクトリ)に格納されている。なお、オリジナル画像ファイル100及びショートカット画像ファイル101が、一つのサーバ1401内の互いに異なるフォルダに格納されていてもよい。
例えば、ターミナル1406にオリジナル画像ファイル100がユーザにより入力され、ターミナル1406においてショートカット画像ファイル101が作成され、オリジナル画像ファイル100とは異なるフォルダに格納されたとする。ここでは、オリジナル画像ファイル100(A、B、C、D)がフォルダAに格納され、これらのオリジナル画像ファイル100に対するショートカット画像ファイル101(a、b、c、d)が、同じターミナル1406内の他のフォルダに格納されているとする。例えば、「a」〜「d」のショートカット画像ファイル101がフォルダBに格納され、「a」、「b」のショートカット画像ファイル101がフォルダCに格納され、「a」、「c」及び「d」のショートカット画像ファイル101がフォルダBに格納されているとする。また、フォルダAは「C:\My Pictures\original-image\」で表わされ、フォルダBは「C:\My Pictures\shortcut-image\」で表わされるとする。また、フォルダCは「C:\My Pictures\子供の写真\」で表わされあり、フォルダDは「C:\My Pictures\2003年01月撮影\」で表わされるとする。
この例の場合、図9に示すように、ファイル名が「IMG_0011.JPG」の「D」のオリジナル画像ファイル401の格納場所が「C:\My Pictures\original-image\」である。このため、「d」のショートカット画像ファイル402のアドレスタグ121には、「C:\My Pictures\original-image\ IMG_0011.JPG」403が記録されている。「a」、「b」及び「c」のショートカット画像ファイルについても、これに準じたアドレスタグ121が記録される。
また、フォルダB内の「d」のショートカット画像ファイル402は、「D」のオリジナル画像ファイル401から第2番目以降に作成されたショートカット画像ファイルであるとする。従って、「d」のショートカット画像ファイル402の削除タグ122には、「否」404が記録されている。「a」〜「c」のショートカット画像ファイルについては、当該ショートカット画像ファイルがこれらに対応する「A」〜「C」のオリジナル画像ファイルから最初に作成されたものであるか否かに応じて「可」又は「否」が記録されている。
このような状態が形成されると、ユーザはターミナル1406のHDD1409等に格納されたショートカット画像ファイル402のサムネイル画像を参照するだけで、他のフォルダAに格納されているオリジナル画像ファイル401の概要を取得することができる。つまり、ユーザは、オリジナル画像ファイル401を探し出さずとも、所望の情報を取得することができる。例えば、ユーザがデジタルカメラ(画像記録装置1410)における写真撮影によってオリジナル画像ファイル100を取得し、フォルダAに保存したとする。また、このオリジナル画像ファイル100に対応する。ショートカット画像ファイル101を他のフォルダに保存したとする。このような場合、ユーザは、常にオリジナル画像ファイル100を特定のフォルダに一括して保存しておき、撮影時刻及び/又はテーマ等のフォルダごとに整理するときはショートカット画像ファイル101を利用することができる。
そして、一つのオリジナル画像ファイル100に対して複数のショートカット画像ファイル101が作成されてもよい。例えば、「A」のオリジナル画像ファイル100が2003年1月に作成された画像データを含み、かつ、その被写体に子供が含まれているとする。この場合、ユーザは、画像に子供が写っていることを示すフォルダC、及び撮影時刻が2003年1月を示すフォルダDの2つのフォルダに、同一の「a」のショートカット画像ファイルを含ませることができる。このような分類を行っておけば、2003年1月に撮影した写真を検索する場合にも、子供が写った写真を検索する場合にも、「A」のオリジナル画像ファイル100に対応する「a」のショートカット画像ファイル101にたどり着くことができる。そして、ショートカット画像ファイル101のファイルサイズは、主画像データを含ませなければ小さくすることが可能である。このため、複数のカテゴリに同一のオリジナル画像ファイル100から関連付けられたショートカット画像ファイル101が重複していても、ファイルサイズの増加が抑えられる。
なお、詳細は後述するが、フォルダB内の「d」のショートカット画像ファイル101の削除タグ122のValueは「否」404であるため、ショートカット画像ファイル101が削除されても、「D」のオリジナル画像ファイル100は削除されない。
次に、第1の実施形態におけるオリジナル画像ファイル100及びショートカット画像ファイル101の削除方法について説明する。図10は、オリジナル画像ファイル100及びショートカット画像ファイル101を削除する方法を示すフローチャートである。ここでは、図11に示すように、ターミナル1406においてアプリケーションA及びBが動作し、サーバ1401においてアプリケーションCが動作することとする。アプリケーションAは、例えば、ユーザが画像を閲覧したり削除したり印刷指示を出すような画像の制御を行うために使用するアプリケーションである。アプリケーションBは、例えば、ターミナル1406に格納されたショートカット画像ファイルを管理するアプリケーションである。アプリケーションCは、例えば、サーバ1401に格納されたオリジナル画像ファイルを管理するアプリケーションである。
先ず、ユーザの指示により、ショートカット画像ファイル101の削除要求が発生する(ステップS1201)。例えば、ユーザの指示に基づいて、アプリケーションAがショートカット画像を管理するアプリケーションBに対してショートカット画像削除要求を行う。
次いで、CPU1407が、タグ判断手段として、アプリケーションBに基づいてショートカット画像ファイル101の削除タグ122を確認する(ステップS1202)。
ステップS1202の結果、削除タグ122が「可」の場合、CPU1407は、アプリケーションBに基づいてオリジナル画像ファイル100の削除が必要であると判断する。そして、CPU1407は、アプリケーションBに基づいて当該ショートカット画像ファイル101のアドレスタグ121の情報を取得する(ステップS1203)。この結果、当該ショートカット画像ファイル101に対応するオリジナル画像ファイル100の削除要求の発行が可能となる。
その後、CPU1407は、削除命令手段として、アプリケーションBに基づいてステップS1203において取得したアドレス情報を参照してオリジナル画像ファイル100の削除要求を発行する(ステップS1204)。例えば、ショートカット画像ファイル101を管理するアプリケーションBがオリジナル画像ファイルを管理するアプリケーションCに対してオリジナル画像削除要求を行う。
続いて、CPU1402が、アプリケーションCに基づいてオリジナル画像削除要求の対象となっているオリジナル画像ファイル100を削除できるかどうかを判断する(ステップS1205)。例えば、他のターミナル等からアプリケーションCを用いて当該オリジナル画像ファイル100が使用されている場合には、これを削除することができないと判断される。
そして、ステップS1205の結果、削除が可能であれば、CPU1402は、アプリケーションCに基づいてオリジナル画像ファイル100を削除する(ステップS1206)。
その後、CPU1402は、アプリケーションCに基づいてオリジナル画像削除要求への応答をアプリケーションBに返却する(ステップS1207)。この応答には、オリジナル画像ファイル100の削除が実行されたか否かの情報、及び削除されなかった場合の理由等が含まれる。削除されなかった場合には、例えば「オリジナル画像ファイルの削除に失敗した」旨の情報が含まれる。
一方、ステップS1202の結果、削除タグ122が「否」の場合、CPU1407は、アプリケーションBに基づいてオリジナル画像ファイル100の削除が不要であると判断する。そして、CPU1407は、アプリケーションBに基づいてショートカット画像ファイル101を削除できるかどうかを判断する(ステップS1208)。このステップS1208の処理は、ステップS1207の後にも行われる。例えば、ターミナル1406内の他のアプリケーションによっても当該ショートカット画像ファイル101が使用されている場合には、これを削除することができないと判断される。
そして、ステップS1205の結果、削除が可能であれば、CPU1407は、アプリケーションBに基づいてショートカット画像ファイル101を削除する(ステップS1209)。
その後、CPU1407は、アプリケーションBに基づいてショートカット画像削除要求への応答をアプリケーションAに返却する(ステップS1210)。この応答には、ショートカット画像ファイル101の削除が実行されたか否かの情報、及び削除されなかった場合の理由等が含まれる。
このように、本実施形態では、削除タグ122からオリジナル画像ファイル100の削除の必要性を判断することが可能であり、必要な場合には、アドレスタグ121からオリジナル画像ファイル100の格納場所を取得して削除することができる。
なお、オリジナル画像削除応答の結果が「失敗」の場合、ステップS1208及びS1209の処理を省略してもよい。この場合、ステップS1210のショートカット画像削除応答の際に、オリジナル画像ファイル100の削除の失敗に伴ってショートカット画像ファイルの削除を省略した旨の情報を応答に含ませることが好ましい。このような情報を応答に含ませることにより、後に、ユーザに通知することが可能となるからである。
オリジナル画像ファイル100の削除の失敗の原因としては、上記のような既に使用状態となっていることの他に、アプリケーションBとアプリケーションCとの間の通信の不具合が挙げられる。また、オリジナル画像ファイル100が所定の格納場所に存在しないことも原因の一つとして挙げられる。更に、何らかの理由によりアドレスの示す領域にアクセスできないことも原因の一つとしてあげられる。
また、オリジナル画像ファイル100に、その格納場所を示すアドレスタグが存在していてもよい。このような構成は、サーバ及びターミナル(クライアント)の両方にオリジナル画像ファイルが存在する場合に有効である。例えば、クライアントから印刷を行う場合に、クライアントの持つアドレスタグの情報からサーバにアクセスし、サーバ側でオリジナル画像が変更されていないかという確認を行うことによって、クライアントに印刷を許可するような構成を採用する場合に有効である。ここで、オリジナル画像が変更されていないかという確認に代えて、正式なクライアントとしての認証を行ってもよい。このような構成では、クライアントにショートカット画像ファイルが格納されている場合、確認又は認証の後にオリジナル画像ファイルを読み込む必要があるが、クライアントにオリジナル画像ファイルが格納されていれば、読み込みのためのダウンロードが不要となる。つまり、確認又は認証の後に、オリジナル画像ファイルのダウンロードを行わずともクライアントに格納されているオリジナル画像ファイルを用いて印刷を行うことができる。このため、ダウンロードに必要な時間が省略され、印刷にかかる時間が短縮される。
ここで、「d」のショートカット画像ファイル101がターミナル1406に格納され、「D」のオリジナル画像ファイル100がサーバ1401に格納されている場合の具体的な削除処理について説明する。
先ず、「d」のショートカット画像ファイル101の削除タグ122が「否」である場合の処理について説明する。図12は、削除タグ122が「否」である場合の処理を示す図である。特に、図12(a)は、各アプリケーション間の要求を示す模式図であり、図12(b)は、削除手順インタフェースを示す応答図である。
図12(a)及び(b)に示すように、ステップS1201において、アプリケーションAがアプリケーションBに対し、その管理下にある「d」のショートカット画像ファイル101の削除の要求1003を行う。
この要求を受けたアプリケーションBは、ステップS1202において、「d」のショートカット画像ファイル101の削除タグ122を確認する。この例では、削除タグ122が「否」であるため、ステップS1202に続いて、アプリケーションBは、ステップS1208の処理を行う。即ち、アプリケーションBは、「d」のショートカット画像ファイル101を削除してよいかどうかの判定1004を行う。例えば、ターミナル1406内の他のアプリケーションによっても「d」のショートカット画像ファイル101が使用されている場合、削除することができないと判断される。
そして、アプリケーションBは、判定の結果、削除可能ならば、「d」のショートカット画像ファイル101を削除する。その後、アプリケーションBは、ショートカット画像削除応答1005で、アプリケーションAに対して「d」のショートカット画像ファイル101の削除の可否及び不可の場合の理由等を通知する。
なお、この例では、ステップS1203〜S1207の処理が行われないため、サーバ1401内での処理は生じず、オリジナル画像ファイル100への影響はない。
次に、「d」のショートカット画像ファイル101の削除タグ122が「可」である場合の処理について説明する。図13は、削除タグ122が「可」である場合の処理を示す図である。特に、図13(a)は、各アプリケーション間の要求を示す模式図であり、図13(b)は、削除手順インタフェースを示す応答図である。
図13(a)及び(b)に示すように、ステップS1201において、アプリケーションAがアプリケーションBに対し、その管理下にある「d」のショートカット画像ファイル101の削除の要求1103を行う。
この要求を受けたアプリケーションBは、ステップS1202において、「d」のショートカット画像ファイル101の削除タグ122を確認する。この例では、削除タグ122が「可」であるため、ステップS1202に続いて、アプリケーションBは、ステップS1203の処理を行う。即ち、アプリケーションBは、「d」のショートカット画像ファイル101のアドレスタグ121の情報を取得し、その後、これを用いてオリジナル画像削除要求1104をアプリケーションCに発行する(ステップS1204)。
次いで、アプリケーションCは、「d」のオリジナル画像ファイル100を削除してよいかどうかの判定1105を行う(ステップS1205)。例えば、他のターミナル等からアプリケーションCを用いて「D」のオリジナル画像ファイル100が使用されている場合、削除することができないと判断される。
そして、アプリケーションCは、判定1105の結果、削除可能ならば、「D」のオリジナル画像ファイル100を削除する。その後、アプリケーションCは、オリジナル画像削除応答1106で、アプリケーションBに対して「D」のオリジナル画像ファイル100の削除の可否及び不可の場合の理由等を通知する。
次いで、アプリケーションBは、「d」のショートカット画像ファイル101を削除してよいかどうかの判定1107を行う。
そして、アプリケーションBは、判定の結果、削除可能ならば、「d」のショートカット画像ファイル101を削除する。その後、アプリケーションBは、ショートカット画像削除応答1108で、アプリケーションAに対して「d」のショートカット画像ファイル101の削除の可否及び不可の場合の理由等を通知する。
なお、削除の命令を受けたショートカット画像ファイルに削除タグが付されていない場合には、そのままオリジナル画像ファイルを削除することとしてもよい。
(第2の実施形態)
次に、本発明の第2の実施形態について説明する。第1の実施形態では、一つのオリジナル画像ファイル100に対して一つのショートカット画像ファイル101のみに「可」の削除タグ122が付与される。これに対し、第2の実施形態では、一つのオリジナル画像ファイル100に対して複数のショートカット画像ファイル101に「可」の削除タグ122が付与され得る構成となっている。以下、第1の実施形態と相違する点を中心にして説明する。先ず、第2の実施形態における削除タグ122を作成する方法について説明する。図14は、削除タグ122を作成する方法を示すフローチャートである。
先ず、CPU1402は、削除タグ122を付与しようとしているショートカット画像ファイル101が、削除タグ122のValueを「可」とすべきものであるか判別する(ステップS1303)。この判別に当たり、CPU1402はユーザに入力を求めてもよく、また、第1の実施形態と同様に、最初のショートカット画像ファイル101であるかという基準を用いてもよい。
そして、ステップS1303の結果、「可」とすべきものであれば、CPU1402は、削除情報(文字列B)802を「可」に決定する(ステップS1305)。
次いで、CPU1402は、当該オリジナル画像ファイル100作成したショートカット画像ファイル101のうち、削除情報(文字列B)802を「可」と決定したものの数を記録する(ステップS1306)。
一方、ステップS1303の結果、「可」とすべきものでなければ、CPU1402は、削除情報(文字列B)802を「否」に決定する(ステップS1304)。
ステップS804又はS805の後、CPU1402は、第1の実施形態と同様の処理を行う。
次に、第2の実施形態におけるオリジナル画像ファイル100及びショートカット画像ファイル101の削除方法について説明する。ここでは、ステップS1202の内容が第1の実施形態と相違する。
本実施形態のステップS1202では、CPU1407が、削除タグ122が「可」であり、かつ、当該オリジナル画像ファイル100に関してその時点で「可」の削除タグ122が付されているショートカット画像ファイル101の数が1個であるか判断する。つまり、CPU1407がタグ解析ステップとして削除タグ122が示す情報を解析し、所定の条件を満たすショートカット画像ファイル101の数が1こであるか判断する。そして、これらの条件が満たされた場合に限り、CPU1407は、アプリケーションBに基づいてオリジナル画像ファイル100の削除が必要であると判断する。
一方、CPU1407は、削除タグ122が「否」であれば、第1の実施形態と同様に、そのままステップS1208〜S1210の処理を行う。また、削除タグ122が「可」であり、かつ、「可」の削除タグ122が付されているショートカット画像ファイル101の数が2個以上の場合には、CPU1407は、削除タグ122を「否」に変更する。この結果、「可」の削除タグ122が付されているショートカット画像ファイル101の数が1個減る。そして、CPU1407は、オリジナル画像削除要求1104を発行することなく、ステップS1208〜S1210の処理を行う。つまり、CPU1407は、当該ショートカット画像ファイル101を削除してよいかどうかの判定1107及びショートカット画像削除応答1108の発行を行う。
他の構成は第1の実施形態と同様である。
このような第2の実施形態では、オリジナル画像ファイル100の削除の権限が複数のショートカット画像ファイル101に付与されるが、全てのショートカット画像ファイル101を介して削除要求があった場合に限りオリジナル画像ファイル100が削除される。従って、「可」の削除タグ122が付与されたショートカット画像ファイル101を保持しているにも拘わらず、知らない間にオリジナル画像ファイル100が削除されていたという不都合を回避することができる。
なお、「可」の削除タグ122が付与されたショートカット画像ファイル101の数は、例えばアプリケーションBにより管理されるが、アプリケーションCが管理してもよい。アプリケーションCが管理している場合には、ステップS1202の判断の際にCPU1407がサーバ1401にアクセスして、その数を取得すればよい。このような場合には、複数のユーザがアプリケーションBを使用する場合でも、容易に処理することができる。
例えば、アプリケーションBが5個のターミナルに個別にインストールされていて、いずれにも同一のオリジナル画像ファイルから作成されたショートカット画像ファイルが格納されているとする。そして、5個のターミナルのうちの1個においてオリジナル画像削除要求が生じたとする。このような場合、他のターミナルの起動状態に拘わらず、サーバ1401において、「可」の削除タグが付与されたショートカット画像ファイルの数が5個から4個に減らされる。「可」の削除タグ122が付与されたショートカット画像ファイル101の数はサーバ1401により管理されるからである。従って、容易な処理が可能となる。また、その後に、他のターミナルにおいてオリジナル画像削除要求が生じると、サーバ1401において、「可」の削除タグが付与されたショートカット画像ファイルの数が4個から3個に減らされる。
(第3の実施形態)
次に、本発明の第3の実施形態について説明する。第3の実施形態は、第2の実施形態とオリジナル画像ファイル100及びショートカット画像ファイル101の削除方法が相違している。ここでは、ステップS1202の内容が第1の実施形態と同一であるが、ステップS105の内容が第1の実施形態と相違している。
即ち、本実施形態のステップS1205では、CPU1402が、当該オリジナル画像ファイル100に関してその時点で「可」の削除タグ122が付されているショートカット画像ファイル101の数が1個であるか判断する。そして、このようなショートカット画像ファイル101の数が1個である場合に限り、CPU1402は、アプリケーションCに基づいてオリジナル画像ファイル100の削除が必要であると判断する。
一方、CPU1402は、「可」の削除タグ122が付されているショートカット画像ファイル101の数が2個以上の場合には、「可」の削除タグ122が付されているショートカット画像ファイル101の数を1個減らし、ステップS1207の処理を行う。つまり、CPU1402は、オリジナル画像削除応答1106の発行を行う。
他の構成は第1の実施形態と同様である。
このような第3の実施形態でも、オリジナル画像ファイル100の削除の権限が複数のショートカット画像ファイル101に付与されるが、全てのショートカット画像ファイル101を介して削除要求があった場合に限りオリジナル画像ファイル100が削除される。従って、「可」の削除タグ122が付与されたショートカット画像ファイル101を保持しているにも拘わらず、知らない間にオリジナル画像ファイル100が削除されていたという不都合を回避することができる。
なお、「可」の削除タグ122が付与されたショートカット画像ファイル101の数は、例えばアプリケーションCにより管理される。
なお、いずれの実施形態においても、オリジナル画像ファイル100の削除に先立ち、ユーザに削除の確認を行うことが好ましい。例えば、アプリケーションBにおいて、オリジナル画像削除要求1104を発行する際に、「本当にオリジナル画像ファイルを削除してもよいですか?」等のダイアログを表示し、外部のユーザに「はい」又は「いいえ」を選択させる。そして、ユーザが許可した場合に限り、オリジナル画像削除要求1104を発行する。また、次のような処理を行ってもよい。即ち、アプリケーションCにおいて、オリジナル画像ファイル100を削除してよいかどうかの判定1105の際に、「本当にオリジナル画像ファイルを削除してもよいですか?」等のダイアログをアプリケーションBを介して表示する。そして、ユーザに「はい」又は「いいえ」を選択させ、この結果をアプリケーションBを介して取得する。そして、ユーザが同意した場合に限り、オリジナル画像ファイル100を削除する。
このような処理を行うことにより、誤った操作に伴うオリジナル画像ファイル100の削除を抑制することができる。
但し、このような処理を行うと、ユーザがオリジナル画像ファイル100の削除を拒否した場合に、オリジナル画像ファイル100が削除されずに、「可」の削除タグ122が付与されたショートカット画像ファイル101が削除されることがある。つまり、オリジナル画像ファイル100とショートカット画像ファイル101との対応がとれなくなる可能性がある。そこで、アプリケーションA又はBに、ショートカット画像ファイルから独立してオリジナル画像ファイルを削除する機能を設けておいてもよい。また、ユーザがオリジナル画像ファイル100の削除を拒否した場合には、このオリジナル画像ファイル100から作成されたショートカット画像ファイル101の削除を省略してもよい。
また、オリジナル画像ファイル100が削除されると、「否」の削除タグ122が付与されたショートカット画像ファイル101が、これに関連するオリジナル画像ファイル100が存在しないにも拘らず、そのまま残存することもあり得る。このような場合、当該ショートカット画像ファイル101からオリジナル画像ファイル100を使用としても、それは不可能である。このため、ターミナル1406とサーバ1401の接続時に、アプリケーションBを用いて管理されているショートカット画像ファイル101とアプリケーションCを用いて管理されているオリジナル画像ファイル100との整合性の確認を行うことが好ましい。そして、この確認の結果、「否」の削除タグ122が付与されたショートカット画像ファイル101のうちで、それに該当するオリジナル画像ファイル100が存在しないものがあれば、当該ショートカット画像ファイル101を削除してもよい。また、削除せずとも、アプリケーションBを介してオリジナル画像ファイル100が存在しない旨をユーザに通知し、その後の削除等の処理をユーザに委ねてもよい。
なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したCD−ROM等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記の印刷処理用のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。