JP5841362B2

JP5841362B2 - 画像処理装置および画像処理方法

Info

Publication number: JP5841362B2
Application number: JP2011147739A
Authority: JP
Inventors: 高久　雅彦; 雅彦高久
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2011-07-01
Filing date: 2011-07-01
Publication date: 2016-01-13
Anticipated expiration: 2031-07-01
Also published as: JP2013017000A

Description

本発明は、撮影した画像データを記録する画像処理装置および画像処理方法に関する。

近年、デジタルカメラやデジタルカメラ付き携帯電話等、静止画像や動画像を撮影し、該撮影された画像データを記録する撮像装置の普及が目覚ましい。このような撮像装置における記録形式として、日本電子工業振興協会により制定されたカメラファイルシステム規格（DCF:Design rule for Camera File system）が広く利用されている。

従来、このDCF規格に従って画像データ等を記録するフォルダを新規に作成する方法として、例えば利用者が「毎日」や「毎週」等、記録フォルダの自動作成条件を日時単位で設定する方法が提案されている（例えば、特許文献１参照）。この方法において、例えば、利用者がカメラのユーザインターフェースを通じて記録先フォルダの自動作成条件を「毎日」と設定したとする。この場合、撮影時に、現在日時と同日に撮影された画像データが既に保存されている、現在日時に対応する記録先フォルダが存在しなければ、新規にフォルダを作成し、該作成されたフォルダに撮影画像を保存する。これにより利用者は、撮影した画像データについて、日付ごとや週ごとといったカレンダに従ってグループ化された記録を行うことが可能となり、画像データ管理の利便性が高められている。

ここで上記DCF規格によれば、既存の記録先フォルダ内に保存された画像データ数が規定された上限に達した場合、新たなフォルダが作成される。したがって、上述したような新規フォルダの自動作成条件を設定する方法では、例えば同日に撮影された画像データの全てが一つの記録先フォルダ内に保存しきれない場合が考えられる。このように、同日に撮影された画像データが複数の記録先フォルダに保存されてしまうと、これら画像データをカレンダに単純に対応させて管理することが困難となる。

そこで、異なる記録先フォルダに記録された画像データをその撮影日時に応じた仮想フォルダ上で管理することで、あたかもカレンダに対応しているかのような管理を可能とする技術が開示されている（例えば、特許文献２参照）。

特開2007-027992号公報特開2009-271983号公報

しかしながら、上記特許文献１に記載の技術においては、フォルダの自動作成条件は日時単位であるため、特定のイベントに対応した記録先を生成することは容易ではない。また、上記特許文献２に記載された仮想フォルダを用いて画像データを管理する場合にも、画像データの実データを他の記録媒体にコピーする等の管理が煩雑であるといった問題があった。

例えば、10月10日の9時30分〜15時に実施された運動競技会で撮影された画像データのみを特定の記録先に記録したい。そして、その他の同日に撮影された画像データについては従来通り、日付ごとに作成された記録先に記録したい、という要求が考えられる。この場合、当該日に撮影された全画像データに対して振り分け設定を行うことは必ずしも容易ではない。日付に従った仮想フォルダを利用する場合にも、この問題は同様に発生する。

本発明は上記問題を解決するためになされたものであり、撮影された画像データの記録先を、カレンダ情報として記録されたイベントの情報に応じて自動振り分けすることで、画像データ管理を容易に可能とする。

上記目的を達成するための一手段として、本発明の画像処理装置は以下の構成を備える。

すなわち、撮影した画像データとその撮影日時の情報を取得する画像データ取得手段と、カレンダ情報を取得するカレンダ情報取得手段と、前記カレンダ情報に含まれるイベントのイベント時間帯が前記撮影日時と重なるイベントがあるか否かを判定するイベント判定手段と、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを該イベント用の第１の記録先に記録し、該イベントがないと判定された画像データを第２の記録先に記録する記録制御手段とを有し、公開可の属性情報とともに前記第１の記録先として情報処理装置が前記カレンダ情報に設定されていた場合、前記記録制御手段は、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを公開可の画像データとし、前記情報処理装置との通信を行う通信部を介して、前記公開可の画像データを前記情報処理装置に記録することを特徴とする。

本発明によれば、撮影された画像データの記録先を、カレンダ情報として記録されたイベントの情報に応じて自動振り分けすることで、画像データ管理が容易に可能となる。

本実施形態におけるデジタルカメラの機能モジュール構成を示すブロック図、デジタルカメラの内部構成を示すブロック図、カレンダ情報の一例を示す図、撮影・記録処理を示すフローチャート、フォルダ作成用のユーザインターフェース例を示す図、カレンダ情報とフォルダの対応例を示す図、第２実施形態における動画像の撮影時間帯とイベントの対応例を示す図、第３実施形態におけるカレンダ情報とウェブサービスの対応例を示す図、第４実施形態におけるウェブ上の画像サービスの構成例を示すブロック図、である。

以下、本発明に係る実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

＜第１実施形態＞
●装置構成概要
まず、本実施形態にかかる画像処理装置としてデジタルカメラを例とし、その構成について説明する。図１は、本実施形態におけるデジタルカメラの機能モジュール構成を概念的に示すブロック図である。同図において、101は、静止画像や動画像等を撮影する撮像モジュールである。撮像モジュール101は、たとえばレンズを通して得た光学的な画像をデジタルデータに変換する。このデジタルデータとしては、静止画像であっても良いし、動画像であっても良い。あるいはまた、マイクロフォンを通して得られた音響データであっても良い。102は、得られたデジタルデータの処理やデジタルカメラの操作等を行うアプリケーションモジュールである。アプリケーションモジュール102は、デジタルデータを記録に最適な形式に成形する処理や、撮像モジュール101を制御して撮影の開始処理や終了処理を行う等、デジタルカメラの制御アプリケーションとして機能する。103は、アプリケーションモジュール102に対する利用者の操作や、該操作に応じた表示等を行うユーザインターフェース(以下、UI)である。UI103は例えば、デジタルカメラを操作してアプリケーションモジュール102への指示を入力とする。これにより、アプリケーションモジュール102が撮像モジュール101を制御し、撮影を開始する等の処理が行われる。UI103はまた、撮影中の画像を表示する機能を担う。

104は、得られたデジタルデータ、すなわち画像データを記録ユニット105に記録する記録制御処理を行う記録モジュールである。詳細は後述するが記録モジュール104は、予め設定されたイベントと記録ユニット105内のフォルダとの対応関係を保持しており、記録対象となるフォルダへの記録を制御する。106は、カレンダ情報107を制御するカレンダモジュールであって、本実施形態における特徴的な構成である。カレンダモジュール106のより詳しい機能については後述する。カレンダ情報107は、イベント等の詳細な日時情報を予め記録したものであり、その詳細については後述する。カレンダ情報107はカレンダモジュール106によって参照されるが、本実施形態におけるカレンダ情報は選択的に利用される情報であり、必ずしも永続的に存在するものではない。108は、デジタルカメラに通信機能を与える通信モジュールであり、例えばインターネット等によるネットワーク通信を行うための無線LAN(Local Area Network)機能等を提供する。この通信モジュール108によりデジタルカメラは、撮像モジュール101で撮影した画像データを外部に通信したり、外部から様々な情報を取得したりすることが可能となる。もちろん、通信モジュール108が提供するネットワーク通信機能は無線LAN機能に限定されず、有線LANであっても良いし、携帯電話網等の公衆無線通信であっても良い。109は、デジタルカメラが通信モジュール108により接続されるネットワークであり、理解を容易にするため、模式的な雲型のイラストとして表現している。110は、カレンダ情報107と同様のカレンダ情報であるが、例えば他の情報処理装置内に保持され、ネットワーク109を介してアクセスを可能とする。なお、通信モジュール108、ネットワーク109、カレンダ情報110のそれぞれも、カレンダ情報107と同様に選択的に利用される情報である。

●一般的な撮影動作
まず、上記構成からなるデジタルカメラにおける一般的な動作として、静止画像の撮影および記録を行う処理の流れを簡単に説明する。利用者は、まずUI103を操作して撮影を指示する。これは、たとえばデジタルカメラにおけるシャッターボタンの押下に相当する。アプリケーションモジュール102はこの操作を検知し、撮像モジュール101に対して撮影を指示する。すると撮像モジュール101は、例えばレンズ駆動等の光学的な動作を行ってデジタルデータを出力する。撮像モジュール101より出力されたデジタルデータは再びアプリケーションモジュール102で検知され、記録用の形式に変換される。アプリケーションモジュール102は次に、記録モジュール104より記録先を取得する。この記録先としては、例えばカメラファイルシステム規格(DCF)で定義される記録フォルダが取得される。ここで、デジタルカメラにおけるフォルダの作成条件として、新規フォルダを毎日生成する旨が設定されているとする。もし、取得された記録フォルダが、撮影を行った日、すなわち本日のフォルダではない場合、アプリケーションモジュール102は記録モジュール104に対し、新たなフォルダを生成するよう指示を行う。記録モジュール104は該指示に応じて、新たなフォルダを生成する。フォルダ生成後、アプリケーションモジュール102は記録モジュール104に対し、記録用形式に変換されたデジタルデータである静止画像の記録を行うよう、指示する。記録モジュール104は、指示されたデジタルデータを本日のフォルダに記録する。

●内部構成詳細
以上、図１に示すデジタルカメラの機能モジュール構成に基づく一般的な撮影・記録処理について説明した。次に、本実施形態において特徴的な、カレンダ情報を用いた撮影・記録処理について説明するが、それに先立ち、図２にデジタルカメラの詳細な内部構成を示し、説明する。なお、図１を用いて静止画像を例とした撮影動作について説明したため、以下では動画像を例として説明する。

図２において、撮影対象となる被写体の画像は、光学系を形成する撮影レンズユニット201を通って光学センサ205に結像する。撮影レンズユニット201は、例えば焦点を合わせるために不図示のモーター等によりレンズ群を移動する仕組みになっており、その直接の制御は、撮影レンズユニット駆動回路202によって行われる。撮影レンズユニット201が駆動される際、絞りを含む絞りユニット203が絞りユニット駆動回路204によって操作されることで、光学センサ205に結像する光量が適切に調整されるようになっている。光学センサ205は、固体撮像素子(CCDやCMOS等)によって構成され、入射した光を光学量に応じて電荷に変換、蓄積する性質をもっている。この電荷を読み出し、A/Dコンバータ207でデジタル化することにより、圧縮されていないデジタル画像が生成される。光学センサ205は、光学センサ駆動回路206の出力するパルス信号等によって制御され、指示されたタイミングで指示された時間内に蓄積された電荷を読み出す一連の動作を繰り返すことで、デジタル画像が連続して得られる。このように連続して取得されたデジタル画像はもちろん動画像であるが、本実施形態は静止画像に対しても同様に適用可能であることは言うまでもない。

次に、連続して取得されたデジタル画像すなわち動画像は、圧縮符号化を行うために、まず画像信号処理回路208でホワイトバランス補正やガンマ補正等の画像補正処理が施された後、圧縮回路209に渡される。このような各構成間におけるデジタル画像の受け渡しは、たとえばDMA(Direct Memory Access)回路を利用したメモリ210に対する高速アクセスにより行われる。

圧縮回路209は、動画像を圧縮する所定の符号化アルゴリズムを実装している。例えば、連続したJPEG(ISO/IEC 10918)符号化によるいわゆるモーションJPEG符号化を行う。この場合、画像信号処理回路208から入力されたデジタル画像がRGB信号であれば、まず輝度信号Yとクロマ信号CbCrからなるYC信号への変換を行う。そして、8ｘ8画素のブロックに分割した後、離散コサイン変換、量子化、ハフマン符号化等の処理を施すことで、最終的な圧縮画像が生成される。また、圧縮回路209においてMPEG-2(ISO/IEC 13818)やMPEG-4(ISO/IEC 14496)等のフレーム間予測を伴う符号化を行う場合も考えられる。この場合、圧縮対象となる特定の１枚の画像(フレーム)に対し、前後のフレームを参照しながら、動き補償予測、マクロブロック処理等を行うことで、前後が相互に依存した圧縮画像(ビットストリーム)が出力される。圧縮回路209から出力された動画像の圧縮画像は、メモリ210に一時保存されて記録ファイル形式に成形された後、外部記憶I/F回路212を介してメモリカード等の記録媒体に出力される。なお、ここでは圧縮画像を出力する記録媒体をメモリカード等の外部記録媒体として説明したが、これは内蔵フラッシュメモリであっても良いし、CD-RやDVD-R等の記録型光学ディスク、光磁気ディスク等であっても良い。

以上説明した一連の撮影・記録動作をリアルタイムに制御し、各ブロックの処理を最適化する処理は、CPU215によって行われる。CPU215はすなわち、所謂制御プログラム（ファームウェア）によるプログラム動作を実行する。制御プログラムは、静的な情報として、通常ROM214に格納されている。本実施形態のデジタルカメラは、起動時から必要に応じてROM214より制御プログラムを読み出し、CPU215で処理することによって、全体の動作が行われる。CPU215で処理される制御プログラムは、その他の処理機能も担っており、例えば、撮影レンズユニット201に対する動作指示を行って、ズーム動作(焦点距離の移動)やオートフォーカス等の処理を行う。また、図１を用いて説明したように、UI103において録画の開始/停止を操作するボタンが押された旨を検知し、動画撮影の一連の処理を開始するといった処理も、CPU215において制御される。

不揮発性メモリ211は、フォルダ作成条件や、カレンダ情報107等を保管する目的で利用される。なお、このフォルダ作成条件やカレンダ情報107は、外部記憶I/F回路212を介してアクセスされるメモリカード等の外部記憶装置に保管されても良い。通信回路213は、図１に示す通信モジュール108に相当する回路であり、デジタルカメラにおける通信処理を制御する。システムクロック216は、デジタルカメラにおける現在の日時情報を提供する。

●カレンダ情報
以下、本実施形態の特徴であるカレンダ情報を用いた撮影処理について、詳細に説明する。まず図３に、本実施形態におけるカレンダ情報107(またはカレンダ情報110)の具体例を示す。図３の例では便宜上、「行番号」や「内容」の項目名の記載と、行番号そのもの(「01」〜「14」)の記載があるが、カレンダ情報107としては必ずしもこれらが含まれていなくても良い。また、一部の行間には、見やすさのために空白を空けてある。

図３に例示するカレンダ情報107の表記は、IETF(Internet Engineering Task Force)におけるRFC2445番に従う。すなわち、標準提案されたInternet Calendaring and Scheduling Core Object Specification(iCalendar)の形式である。以下、図３におけるいわゆるiCalendar形式の記載ついて、簡単に説明する。まず01行および14行は、この間に記載された内容がカレンダ情報である旨を示す。02行および03行は、カレンダ情報の形式を示す。そして04〜13行が、カレンダ情報としての実質的な内容であり、この例では、04〜08行と09〜13行の２つの情報(以下、イベントと称する)が含まれている。まず１つ目のイベントは、「東京」の時刻で「2010年10月10日の9時30分」から「2010年10月10日の14時」までの時間帯であり、内容は「運動会」であることを示している。次に２つ目のイベントは、「2010年10月11日」から「2010年10月21日」の前日までの10日にわたる時間帯であり、内容は「海外旅行」であることを示している。

本実施形態においては、この図３に示す内容のカレンダ情報107を、カレンダモジュール106が取得するとする。一方、アプリケーションモジュール102は、デジタルカメラ内に内蔵されたシステムクロック216より現在時刻を取得する。もし、現在時刻が2010年10月10日の11時15分であれば、これは図３に例示したカレンダ情報107の１つ目のイベントである運動会の時間帯に含まれることが分かる。利用者がUI103を操作して撮影指示を行うと、上述したような、撮影データをデジタル化して記録用形式に成形する処理が行われる。本実施形態ではこの時、カレンダ情報107と撮影日時との比較を行う。その結果、撮影日時があるイベントに合致する場合、アプリケーションモジュール102は、該イベントに対応する記録ユニット105内のフォルダを、記録モジュール104が管理する対応関係情報より取得する。もしもイベントに対応するフォルダの実体が存在しない場合には、これを新規に作成する。そして撮影データは、イベントに対応する記録先フォルダに記録される。例えば、上記例のように撮影時の現在時刻が2010年10月10日の11時15分であれば、運動会のイベントに対応するフォルダが記録先となる。

ここで、図３の例において撮影時の現在時刻が例えば2010年10月9日の12時30分である場合には、いずれのイベントにも該当していないため上記とは異なる処理が行われる。すなわち、イベントが存在しない時間帯の撮影データについては、上記従来通りの方法による記録処理が行われる。

なお、図３ではいわゆるiCalendarの形式でのカレンダ情報の例を示したが、カレンダ情報はこの形式に限定されない。例えば時刻とイベントを記録する形式としては、Dublin Coreと呼ばれる形式も存在する。あるいは、W3C(World Wide Web Consortium)等で検討されたRDF(Resource Description Framework)形式のカレンダも知られている。また、カレンダ情報が独自の形式であっても良く、日付、曜日、時間等の時間に関する情報と、イベントを特定する情報とが記載されていれば良い。

●撮影・記録処理
以下、本実施形態における撮影・記録処理について、図４のフローチャートを用いて詳細に説明する。図４に示すフローチャートは、利用者によってシャッターボタン等の撮影ボタンが押下され、画像データが記録可能な形式として取得可能となった状態を起点として記されている。

まず、アプリケーションモジュール102が、撮像モジュール101等を介して画像データを取得する(S401)。ここでは画像データとして静止画像を想定し、例えばJPEG圧縮されたファイル形式のデータが取得されたものとする。次に、撮影日時情報として、システムクロック216から現在時刻を取得する(S402)。なお、撮影日時情報としては、必ずしもシステムクロック216から新規に現在時刻を取得する必要はなく、撮影時に取得された日時情報をメモリ上に一時記憶しておき、S402で該一時記憶された日時情報を取得しても良い。あるいは、静止画像データに撮影日時を示す情報が含まれている場合には、該静止画像データから該撮影日時情報を取得しても良い。

撮影日時情報を取得した後、カメラ内に記憶されたカレンダ情報107を取得し(S403)、該カレンダ情報107に含まれるイベントを抽出する(S404)。図３の例であれば、「運動会」と「海外旅行」の２つのイベントが抽出される。

そして、以上のように得られた撮影日時情報とイベント情報に基づき、撮影日時と関連付けられるイベントがあるか否かを判定する(S405)。詳細には、撮影日時がイベント情報に設定されたイベント時間帯に重なるものがあるか否かを判定する。以下、撮影日時がイベント時間帯に重なるイベントを、ターゲットイベントと称する。

ターゲットイベントがあると判定された場合には、該ターゲットイベント用の記録先(第１の記録先)を取得する(S406)。この記録先取得処理としては、予め各イベント用に設定された記録先として不揮発性メモリ211等に記憶された情報からの取得を行っても良いし、その他の手段による取得を行っても良い。この取得方法の詳細については後述する。取得された記録先は、実際の記録動作のために記録先として設定される(S407)。一方、S405においてターゲットイベントが無いと判定された場合には、通常の記録先(第２の記録先)を設定する(S408)。ここで通常の記録先とは、上記従来の方法において使用される、例えば日時ごとに作成されたフォルダである。この通常の記録先としては、所定の規則により生成されたフィルタであれば、日時毎に作成されたフォルダに限定されない。

そして最後に、設定された記録先が存在するか否かを判定し(S409)、存在しなければ新規に作成して(S410)、S401で取得した画像データ413を該記録先に記録する(S411)。この記録制御は一般的には、記録ユニット105上のファイルシステムへの記録がこの動作に相当する。

なお、図４のフローチャートに示す処理は一例にすぎず、その一部が異なっていても実施可能であることは言うまでもない。例えば、撮影日時の取得処理(S402)がカレンダ情報の取得処理(S403)の後であっても良い。

本実施形態においては上述したように、カレンダ情報107に基づいて関連付けられるイベント(ターゲットイベント)に応じた記録先へ記録する方式(以下、カレンダ方式と称する)を採用する例を示した。本実施形態によるカレンダ方式を、従来の日時に応じて自動作成されたフォルダへの無条件記録を行う方式(以下、従来方式と称する)と選択的に適用することも可能である。例えばUIによって、カレンダ方式と従来方式を利用者が選択できるように示してもよい。図５は、このような選択手段を提供するUI例を示す。このUIとしては、例えばデジタルカメラが備えるタッチセンサー付き液晶画面等において実現される。以下、図５に示すUI例について、詳細に説明する。図５に示すUI例においては、フォルダ作成画面として、新規作成方法の選択領域501と、カレンダ参照方法の選択領域502と、カレンダのイベントリストの領域503とが含まれている。

新規作成方法の選択領域501には、「自動作成」と「カレンダ参照」の２つの選択項目がある。「自動作成」が選択されている場合には、新規フォルダを従来方式により作成する旨が設定され、「カレンダ参照」が選択されている場合には、新規フォルダをカレンダ情報により作成する旨が設定される。この２つの選択は、簡易な操作性の観点からは排他的になされるように設計することが望ましい。すなわち、従来方式とカレンダ方式を択一とする。あるいは、この２つの選択を同時に行えるように設計することも可能である。この２つがともに選択されている場合には、カレンダ情報に適切なイベントが存在していればカレンダ方式でフォルダを生成し、適切なイベントがない場合には従来方式を適用する。あるいは、両方の方式を同時に行うようにしても良い。すなわち、この２つがともに選択されている場合には、まず従来方式で新規フォルダを作成し、これに画像データを保管する。加えて同時に、カレンダ方式でもフォルダを生成し、画像データのコピーもしくは画像データへの参照情報をこれに格納する。なお、UIのレイアウト設計およびレイアウトの解釈の仕方は設計上の仕様であり、本発明を限定するものではない。このように、記録先フォルダの新規作成方法を選択する領域501を設け、利用者の選択を例えば不揮発性メモリ211に格納することで、本実施形態のカレンダ方式を従来方式と選択的に適用することが可能となる。

さらに、カレンダ参照方法の選択領域502を用いることで、より詳細な処理の選択を行うことも可能である。カレンダ参照方法の選択領域502には、「全イベント」と「個別指定」の２つの選択項目がある。「全イベント」が選択されている場合には、すでに説明した通りに、カレンダ情報107における全イベントについて、ターゲットイベントであるか否かを判定し、該判定結果に応じた記録を行う。一方、「個別指定」が選択されている場合には、カレンダ情報107に含まれるイベント毎に、新規フォルダを生成するか否か、あるいはイベントに対応したフォルダに画像データを格納するか否かを設定する。具体的なイベント毎の設定は、カレンダのイベントリストの領域503において行われる。図５の例では、図３に例示したカレンダ情報107が表示されており、「運動会」に対応する表示504と、「海外出張」に対応する表示505として、当該イベントの日時情報が表示されている。図５の例では、「運動会」に対応する表示504が選択済みであり、「海外出張」に対応する表示505は選択されていない。なお、カレンダ情報107により多くのイベントが含まれている場合には、スクロールバー506を用いて全イベントが参照できるようになっている。図５のように「運動会」に対応する表示504が選択済みである場合には、「運動会」のイベントに対応する撮影時にのみ、新規フォルダの生成、または、該イベントに対応する既存フォルダへの画像データの保存が行われる。より具体的には、図４のS405における、ターゲットイベントの判定処理の際に、判定条件として、撮影日時が重なるか否かに加えてイベントの選択の有無を参照するようにすれば良い。

これまで説明してきたように本実施形態のカレンダ方式によれば、カレンダ情報107を参照し、そこに含まれるイベントから、該イベントに対応するフォルダを新規作成もしくは選択し、画像データを格納することができる。

●イベントとフォルダの対応関係
以下、本実施形態におけるイベントと、その記録先であるフォルダの対応関係について詳細に説明する。図６は、カレンダ情報におけるイベントとフォルダの対応例として、2つの例を示している。同図には、カレンダ情報107とカレンダ・フォルダ対応テーブル601、および画像データ記録フォルダ602が記載されている。カレンダ情報107については既にその詳細について説明済みであるため、ここでは説明を省略する。図６においてもカレンダ情報107をiCalendar形式で行番号とともに記載している。なお、その内容は、図３の例とほぼ同様であるが、イベントを「運動会」の1つのみに簡略化している。なお。図３の例とは異なる情報（07,09行）も含まれているが、これについては詳細な説明を後述する。また、カレンダ・フォルダ対応テーブル601は、カレンダ情報107に含まれるイベントと画像データを記録する記録先フォルダの対応関係を格納するテーブルであり、記録モジュール104に保持される。なお、カレンダ・フォルダ対応テーブル601は、アプリケーションモジュール102が保持しても良いし、カレンダモジュール106が保持しても良い。画像データ記録フォルダ602は、撮影された画像データを記録する記録先のフォルダ構造（ディレクトリ構造）例を示しており、記録ユニット105内に構成される。

上述したように、カレンダ情報107には、図３とは異なる情報として、07行と09行の情報が追加されている。以下、これらの行について説明する。

まず07行には、'UID'と記載された情報が含まれているが、これは、イベントを識別するIDである。このUIDについては、iCalendar形式で定義がなされている。ここで、カレンダ・フォルダ対応テーブル601には、UID605とDIR606の２つのエントリが存在している。UID605はカレンダ情報107に含まれる07行のUIDに相当し、DIR606は、画像データ記録フォルダ602内のフォルダを示している。図６に示すカレンダ・フォルダ対応テーブル601の例では、UIDとして'default'と記載されたデータレコードと、これ以外のUIDが記載された２つのデータレコードの、計３つが存在する。３つ目のデータレコードにある'uid2@sample.com'と記載されたUIDは、カレンダ情報107の07行に記載されたUIDと同じである。同様に、３つ目のデータレコードにある'//DCIM/102cano/'の記載は、画像データ記録フォルダ602内のフォルダ610を示している。なお、カレンダ・フォルダ対応テーブル601の２番目のデータレコードは、画像データ記録フォルダ602内のフォルダ609を示している。

すなわち図６に示す例においては、まずカレンダ情報107からカレンダ・フォルダ対応テーブル601への対応関係として、イベントに対応するUIDから矢印603に示すような参照がなされ、その記録先となるフォルダ名が特定される。そして、カレンダ・フォルダ対応テーブル601から画像データ記録フォルダ602への対応関係として、矢印604に示すような参照がなされ、記録先となるフォルダ名と実際の記録先(フォルダ実体)が特定される。本実施形態ではこのようなUID構成を用いることで、イベントとフォルダを対応付けることが可能となる。なお、イベントとフォルダの対応制御はこの例に限らず、他の方法を適用しても構わない。

次にカレンダ情報107の09行には、'LOCATION'と記載された情報が含まれている。これは、画像データの記録場所を示すディレクトリ情報であり、'DIR="file://DCIM/102cano/"'」の文字列が含まれている。この文字列そのものは、画像データ記録フォルダ602におけるフォルダ構成の一部を示すものである。すなわち、カレンダ情報107から画像データ記録フォルダ602へ、矢印611に示すような参照がなされることで、カレンダ情報107に含まれるイベント情報から直接、該イベントに対応するフォルダが結びつけられる。なお、標準化されたiCalendar形式においては、このような'LOCATION'を用いた記載方法は定義されておらず、すなわち本実施形態に特有の記載である。

なお、ここではカレンダ情報107内において、イベント対応の記録先への関連付け形式として、07行のUID、09行のLOCATIONの２つを示したが、これら２つの形式をともに提供する必要はない。いずれか一方の形式が実現可能であると同時に、類似の異なる形式を適用しても良く、例えば、カレンダ・フォルダ対応テーブル601に代えて、フォルダ610等の記録フォルダ内にUIDを記録しても良い。さらには、カレンダ情報107に含まれるイベントにUID等の情報が存在しない場合には、これを新規作成しても良い。例えば、カレンダ・フォルダ対応テーブル601に新たなデータレコードを追加し、記録フォルダを新たに生成して、該イベントを特定するUIDをカレンダ情報107に追記する。この場合、カレンダ・フォルダ対応テーブル601におけるDIR606には、新たに生成された記録フォルダのパスが記載される。

なお、カレンダ・フォルダ対応テーブル601におけるUID605の'default'は、デフォルトとしてのフォルダ設定を示している。すなわち、カレンダ情報107にイベントが存在しない場合やイベント中にUID情報が含まれない場合、あるいは、利用者がイベントに対して新規フォルダの非生成を指示した場合等に、該'default'のデータレコードの情報を用いる。

また、カレンダ情報107において、UIDの代わりに08行の'SUMMARY'に記載された情報を用いて、イベントとフォルダの結びつけを実現することも可能である。また、現在広く使われているカメラファイルシステム規格(DCF)に特に準拠しない場合には、フォルダ名そのものをUIDやSUMMARYなどの情報で構成しても良い。

●ネットワークを介したカレンダ情報へのアクセス
以上は、本実施形態のデジタルカメラ内に存在するカレンダ情報107を参照する例について説明したが、本実施形態は、ネットワーク109を介してアクセスされるカレンダ情報110を用いることによっても同様に実現可能である。すなわち本実施形態においては、カレンダ情報として必要な情報が含まれており、アクセス可能でありさえすれば、カレンダ情報はどこに存在していても構わない。

以下、カレンダ情報が、ネットワーク109を介してアクセスされる場所、例えば他の情報処理装置内に存在する例について補足する。この場合、カレンダモジュール106は、カレンダ情報107を参照するのではなく、通信モジュール108を介してカレンダ情報110を参照することになる。具体的には、実際の処理を行うアプリケーションモジュール102がカレンダモジュール106に指示を行って、カレンダ情報110をカレンダ情報107と同様に扱うことができれば良い。

一般に、ネットワーク上の他の情報処理装置に記録されたカレンダ情報110を取り扱う方法としては、HTTP等のプロトコル上に独自の通信手順を付与したカレンダサービス等、様々な方法が知られている。汎用化された標準的な手法としては、IETFがRFC4791として標準化提案しているCalendaring Extensions to WebDAV(CalDAV)と呼ばれる方式がある。これは、IETFがRFC4918として標準化提案しているWeb-based Distributed Authoring and Versioning（WebVAV）と呼ばれる方式でカレンダ情報を取り扱うものである。この方法によれば、通信の手順そのものが追加されるだけで、他の情報処理装置内にあるカレンダ情報110を、あたかも自装置内にあるカレンダ情報107のように扱うことができる。

上述したように、本実施形態におけるカレンダの表現形式は、必ずしもiCalendar形式の直接アクセスファイルである必要はなく、同様の情報が得られれば他の形式であっても良い。また、ネットワーク上のカレンダ情報110と、デジタルカメラに内蔵されたカレンダ情報107の両方が存在しても良く、そのような場合には例えば優先順位等を予め設定しておけば良い。

以上説明したように本実施形態によれば、撮影された画像データを、イベント情報等、単なる日時情報以外のより詳細な条件に従って作成されたフォルダに自動振り分けして、記録することが可能となる。これにより、イベント中に撮影された画像データについて、時間設定等の煩雑な振り分け設定を行うことなく、容易に管理可能となる。

＜第２実施形態＞
以下、本発明に係る第２実施形態について説明する。第２実施形態においては、記録される画像データが特に時間軸を有する動画像データである場合について説明する。

●動画像の撮影タイミング
図７は、動画像データを撮影する時間帯とイベントの関係例を示す図である。ここでは、上述した第１実施形態で図６に例示したカレンダ情報107を参照する例を示している。図７において横軸は時間であり、例として「運動会」のイベント'uid2@sample.com'が定義されている、2010年10月10日の一日を模式化して示している。同図において、'uid2@sample.com'と記載された矩形701はイベントの時間帯を示し、09:30〜14:00が「運動会」のイベントであることを示している。また、動画A702〜動画E706の５つの矩形は、動画像データの撮影開始から終了までの時間帯を示している。一般に動画像は静止画像と異なり、撮影時間が撮影日時で表わされる瞬間ではなく、時間の幅を持っているため、撮影の開始日時と終了日時は異なる時刻となる。以下、動画A702〜動画E706を、単に動画A〜動画Eと表わすとする。

ここで注目すべきは、動画像データは、時間帯、すなわち時間の幅を持つため、必ずしもカレンダ情報107に記録されたイベントの時間帯の中か外かの二者択一とはならない点である。例えば動画Bは、撮影開始日時はイベント時間帯の外であるが、撮影終了日時は該時間帯の中にある。逆に動画Dは、撮影開始日時はイベント時間帯の中にあるが、撮影終了日時はイベント時間帯の外である。また動画Cは画像データの全てがイベント時間帯の中にあり、動画Aおよび動画Eは、イベント時間帯に全く存在しない。第２実施形態では、このように画像データが必ずしもイベントの時間帯内に収まらない場合に、利用者の指定または予め定められた方法によって画像の記録先を判断する。

●動画像の撮影・記録処理
上述した第１実施形態の図４に示すフローチャートにおいては、撮影日時がイベント時間帯に重なるターゲットイベントが有る場合に(S405)、該ターゲットイベントに対応した記録先を取得する処理(S406)を行う例を示した。第２実施形態ではこのS405のイベント判定処理において、以下のような制御を行う。

まずS402で、撮影日時情報として現在時刻のみならず、撮影開始日時と撮影終了日時を取得する。これによりS405におけるターゲットイベントの判定を、撮影開始日時および撮影終了日時によって示される撮影期間に応じて行うことができる。

ここで、ターゲットイベントの判定方法について、いくつかの例を示す。なお、実際に適用されるターゲットイベントの判定方法は、利用者によってUI等より指定されている、またはデジタルカメラ内で予め定められているものとする。

まず、画像データの全てがイベント時間帯に含まれる場合にのみ、当該イベントをターゲットイベントと判定するような設定がなされている場合が考えられる。このような場合には、撮影開始日時および撮影終了日時がともにイベント時間帯内である場合に、S405でターゲットイベントとして判定される。この例には、図７に示す動画Cが相当する。また、少なくとも画像データの一部がイベント時間帯に含まれる場合にターゲットイベントと判定する設定では、撮影開始日時または終了日時の少なくとも一方がイベントの時間帯内であれば、ターゲットイベントとして判定される。この例には、図７に示す動画Bと動画C、動画Dが相当する。また、画像データがイベント時間帯内にはなくとも、該イベントと同日であればターゲットイベントと判定する設定がなされている場合、撮影開始日時または終了日時の日付がイベントと同じである場合に、ターゲットイベントとなる。この例には、動画A〜動画Eの全てが相当する。また、不図示であるが、撮影された動画像データが複数のイベントに含まれるような場合には、より多くの時間が重なるイベントをターゲットイベントとして判定するように設定しても良い。

以上説明したように第２実施形態によれば、動画像データについてはその撮影開始日時および撮影終了日時を考慮して記録先を設定することができるため、さらにきめの細かい管理が可能となる。

＜第３実施形態＞
以下、本発明に係る第３実施形態について説明する。第３実施形態においては、画像データをネットワーク上の画像共有サービスやストレージサービス等に保存する例について説明する。

例えば、Local Area Network(LAN)等で接続された、所謂リモートディスクやリモートストレージに対する保存を可能とする構成を取り得ることは周知である。このような構成としては、ネットワークファイルシステムといった、ネットワーク上の記録装置をあたかも直接接続しているかのように取り扱う方法が知られている。第３実施形態ではさらに、所謂ウェブサービスと呼ばれるインターネット上のストレージサービスに対して本発明を適用する例を示す。

図８は、第３実施形態におけるウェブ上のカレンダ情報110とウェブサービスの対応例を示す図である。カレンダ情報110としては、上述した第１実施形態で図６に例示したカレンダ情報107と同様であるとする。カレンダ・サービス対応テーブル801は、カレンダ情報110に含まれるイベントと画像データを記録する記録先フォルダ、およびウェブサービスへの接続ユーザIDの対応関係を格納するテーブルである。カレンダ・サービス対応テーブル801において、UID803は図６で示したカレンダ・フォルダ対応テーブル601におけるUID605と同等であり、同様にDIR804もDIR606と同等のものである。しかしながら第３実施形態では、DIR804として画像共有サービス等のウェブサービスへの接続情報が記録されている。例えば、UIDが'uid2@sample.com'であるデータについては、このウェブサービス上での相対接続パスが記録されている。このように、記録先としてネットワーク上のサービスへの接続パスを設定することにより、カレンダと連動した画像共有サービスへの画像記録が可能となる。

カレンダ・サービス対応テーブル801には、さらにUSER805のデータ列が含まれている。これは、サービスへの接続ユーザID等を保存する領域である。カレンダ情報110からカレンダ・サービス対応テーブル801へ、矢印802に示すような参照がなされることで、カレンダ情報110に含まれるイベント情報から、該イベントに対応するフォルダおよび接続ユーザIDが結びつけられる。

なお、実装の際には各種ウェブサービス等に固有の手順や情報を保持する必要がある場合も多く、したがって、図８は汎用的に適用可能な例であるとは言えない。しかしながら、ウェブサービス等への接続手順等は本発明の本質ではなく、第３実施形態ではウェブサービスへの接続情報を保持することで、ネットワーク上の該サービスに画像を保管可能である例を示しているに過ぎない。各種ウェブサービスへのアクセス等に適用可能な情報を与えることにより、イベント毎に画像データを保管するサービスや、サービス内での記録フォルダの決定が可能であることは明らかである。

さらに、図８に示したカレンダ情報110の例では、09行目に'CLASS'として新たな属性情報が付与されている。この'CLASS:PUBLIC'の文字列は、このイベントが公開されたものである旨を示している。カレンダ情報110にこのような公開可否の属性情報を記載することにより、ウェブサービスに対して、画像データを公開可として保存するように制御することが可能となる。なお、図８に示すカレンダ・サービス対応テーブル801においては、UID803として'public'と記載したデータレコードが存在する。このように、カレンダ情報110でUIDとして'public'が指定されたイベントに対しては公開属性を有するとして、公開可の画像データとして記録する旨を予め設定しておくことも可能である。また、共有属性を有する画像データの記録には、記録先のフォルダを共有属性のものとする方法と、画像データそのものを共有属性とする方法とが考えられるが、いずれの方法を用いるかは実装の条件に依存する。

以上説明したように第３実施形態によれば、ウェブ上の画像共有サービスやストレージサービスへの画像データの記録を制御することが可能となる。

＜第４実施形態＞
以下、本発明に係る第４実施形態について説明する。上述した第１乃至第３実施形態では、本発明をデジタルカメラに適用する例について説明した。第４実施形態においては、本発明をウェブサービス内、すなわちネットワーク上のコンピュータ等で実施することで、画像管理サービスを提供する例を示す。

●システム構成
図９は、第４実施形態におけるウェブ上の画像管理サービスへの本発明の適用例を示すブロック図である。同図においては、通信機能を備えたデジタルカメラ901が、ネットワーク109を介してウェブサービス902に接続された構成を示している。なお、以下ではウェブサービスを単にサービスと記述する場合もある。

デジタルカメラ901は通信機能を備えるため、一般的なデジタルカメラの機能に加えて通信モジュールを内蔵している。なお、ここではデジタルカメラ901を例としているが、画像管理サービスに画像データをアップロード可能な機器であれば、他の機器であっても適用可能である。例えば、カメラ機能付き携帯電話等においても、撮影した画像データをネットワーク上のサービスにアップロードする機能が知られている。また、パーソナルコンピュータ(PC)等に撮影した画像データを保管し、このPCから画像データをネットワーク上のサービスにアップロードする機能も広く使用されている。

ウェブサービス902は、通信プロトコル処理を行うHTTPサーバー903と、実際のサービスを提供するための複数のモジュール等によって構成されている。例えばウェブアプリケーション904は、Common Gateway Interface(CGI)と呼ばれるサーバー上でアプリケーションを動作させる仕組み等を用いて、利用者にサービスを提供する。ユーザ管理モジュール905は、ウェブアプリケーション904への利用者のアクセスに対して認証処理などを提供する。例えば、サーバー上に保管されたユーザ情報906等からユーザIDやパスワード等の利用者情報を用いて、ウェブサービスへのアクセス認証や利用者の特定等の機能を提供する。カレンダサーバーモジュール907は、カレンダ情報110にアクセスしてイベント情報等の追加、更新、削除、参照、等の各種機能を提供する。なお、カレンダ情報110は、上述した第１乃至第３実施形態と同様の構成からなる。単にスケジュール管理機能を提供するウェブサービスとしては、様々なものが知られている。第４実施形態ではこのようなウェブサービスを、HTTPサーバー903、ウェブアプリケーション904、ユーザ管理モジュール905、ユーザ情報906、カレンダサーバーモジュール907、カレンダ情報110、の組み合わせによって実現する。そして、いわゆるウェブブラウザを用いてアクセスすることで、スケジュール管理サービスが提供されている。

画像保管モジュール908は、画像ストレージ909にアクセスして、画像データの追加、更新、削除、等の機能を提供する。画像配信モジュール910は、画像ストレージ909にアクセスして、保存された画像データの配信機能を提供する。単に画像データの配信機能を提供するサービスとしても、様々なものが知られている。上述したスケジュール管理サービスと同様に、画像データの通信サービスも、図９に示す構成の以下のような組み合わせによって実現される。すなわち、HTTPサーバー903、ウェブアプリケーション904、ユーザ管理モジュール905、ユーザ情報906、画像保管モジュール908、画像ストレージ909、画像配信モジュール910、の組み合わせである。通信サービスの具体例としては、利用者がPCに保存した画像データをウェブサービスにアップロードして、これを保存したり、フォルダ分けしたり、あるいはアルバムのような形式で表示したりするサービスがある。また、特定のフォルダに共有や公開の属性を与えることにより、アップロードした本人とは異なるユーザIDでアクセスする利用者に公開するといったサービスも提供されている。さらには、画像データは静止画像とは限らず、動画データを広く一般に公開するサービス等も広く利用されている。

●画像管理
以下、第４実施形態における画像管理サービスの利用例について説明する。ここでは、カレンダ情報110は予め登録済みであるものとする。

まず利用者は、デジタルカメラ901より、HTTPサーバー903に接続してウェブアプリケーション904にアクセスする。この時、ウェブアプリケーション904は、ユーザ管理モジュール905を介してユーザIDによる認証を行う。認証処理の際には、デジタルカメラ901とウェブアプリケーション904間で複数回の通信処理を行うようにしても良いし、アクセス文字列等を参照することで1回の通信処理で済ませても良い。この認証処理により、利用者がウェブアプリケーション904上で特定される。

利用者の認証後、デジタルカメラ901は、保存する画像データをウェブアプリケーション904に対してアップロードする。アップロードの方法としてはHTTPを用いてもよいし、他の通信プロトコルを用いても良い。アップロードされた画像データは、ウェブアプリケーション904から画像保管モジュール908に渡される。画像保管モジュール908において画像データを取得する処理は、上述した第１実施形態で図４に示した画像データ取得処理(S401)と同等である。

画像保管モジュール908は、アップロードされた画像データを参照して、画像データの撮影日時情報を取得する。この撮影日時情報の取得処理についても、図４に示した撮影日時取得処理(S402)と同等である。ここで、画像データの撮影日時情報としては、該画像データに含まれる撮影日時を参照しても良いし、デジタルカメラ901から該画像データとともにその撮影日時情報を送信するようにしても良い。また、画像データが動画像であれば、該画像データに含まれる撮影開始日時と終了日時を取得しても良いし、さらに撮影終了日時を撮影日時と動画の再生時間(撮影時間)から算出しても良い。

次に、すでに特定された利用者に応じたカレンダ情報110を取得するため、画像保管モジュール908は、カレンダサーバーモジュール907にカレンダ情報取得を依頼する。この処理は、図４に示したカレンダ情報取得処理(S403)に相当する。

ここまでの一連の処理により、画像保管モジュール908は、撮影日時情報に対応するターゲットイベントを判定(S405)することができる。ターゲットイベントがあると判定される場合には、アップロードされた画像データを該ターゲットイベントに結び付けられた領域に保存する。これ以降の処理は、上述した第１実施形態における画像データの記録処理と同様であるため、ここでは説明を省略する。

なお、第４実施形態における画像データの記録先としては、ファイルシステムとして定められた位置であっても良いし、物理的な記録先と実際にウェブサービスとして提供される仮想的な記録先とが異なっていても良い。すなわち、利用者に対して提示される記録先が、予めフォルダ構成として見える形式になっていれば良い。

また、以上はカレンダ情報110が予め登録済みである場合を例として説明したが、カレンダ情報を後から設定することも可能である。この場合例えば、アップロードされた画像を一旦、通常の画像データ保存先に保存しておく。そして、カレンダ情報を設定あるいは更新した後に、利用者の操作により、または自動的に、該カレンダ情報を参照して画像データを適切なフォルダに保存し直せば良い。また、ウェブサービスとして画像データの配信機能が提供される場合には、カレンダ情報の共有属性に応じて画像データを公開するよう設定しても良い。これについては、上述した第３実施形態において説明した通りである。

また、第４実施形態におけるカレンダ情報110は、利用者が所有するカレンダ情報とは限らない。一般にスケジュール管理機能を提供するサービスにおいては、他者が所有するカレンダ情報を共有する機能が利用されている。したがって、カレンダ情報110としては、利用者がアクセス可能な公開されたカレンダ情報であっても良い。このような公開されたカレンダ情報を参照する場合、アップロードされた画像データを共有された画像データとして、利用者用の保存先または共有される保存先に保存するようにしても良い。利用者用の保存先を用いる場合には、共有されたカレンダ情報のアクセス権をこの保存先に付与しておく。

以上説明したように第４実施形態によれば、ウェブサービスとしての画像管理サービスを提供することが可能となる。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

撮影した画像データとその撮影日時の情報を取得する画像データ取得手段と、
カレンダ情報を取得するカレンダ情報取得手段と、
前記カレンダ情報に含まれるイベントのイベント時間帯が前記撮影日時と重なるイベントがあるか否かを判定するイベント判定手段と、
前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを該イベント用の第１の記録先に記録し、該イベントがないと判定された画像データを第２の記録先に記録する記録制御手段とを有し、
公開可の属性情報とともに前記第１の記録先として情報処理装置が前記カレンダ情報に設定されていた場合、前記記録制御手段は、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを公開可の画像データとし、前記情報処理装置との通信を行う通信部を介して、前記公開可の画像データを前記情報処理装置に記録することを特徴とする画像処理装置。
前記情報処理装置は、画像データを保管するウェブサービスを提供することを特徴とする請求項1に記載の画像処理装置。
前記記録制御手段は、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データの前記第１の記録先である前記ウェブサービス内の記録フォルダを前記カレンダ情報に含まれる情報に従って決定することを特徴とする請求項2に記載の画像処理装置。
画像データ取得手段、カレンダ情報取得手段、イベント判定手段、および記録制御手段を有する画像処理装置における画像処理方法であって、
前記画像データ取得手段が、撮影した画像データとその撮影日時の情報を取得し、
前記カレンダ情報取得手段が、カレンダ情報を取得し、
前記イベント判定手段が、前記カレンダ情報に含まれるイベントのイベント時間帯が前記撮影日時と重なるイベントがあるか否かを判定し、
前記記録制御手段が、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを該イベント用の第１の記録先に記録し、該イベントがないと判定された画像データを第２の記録先に記録し、
公開可の属性情報とともに前記第１の記録先として情報処理装置が前記カレンダ情報に設定されていた場合、前記記録制御手段が、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データを公開可の画像データとし、前記情報処理装置との通信を行う通信部を介して、前記公開可の画像データを前記情報処理装置に記録することを特徴とする画像処理方法。
前記情報処理装置は、画像データを保管するウェブサービスを提供することを特徴とする請求項4に記載の画像処理方法。
前記記録制御手段が、前記イベント時間帯が前記撮影日時と重なるイベントがあると判定された画像データの前記第１の記録先である前記ウェブサービス内の記録フォルダを前記カレンダ情報に含まれる情報に従って決定することを特徴とする請求項5に記載の画像処理方法。
コンピュータを請求項１乃至3のいずれか１項に記載の画像処理装置の各手段として機能させるためのプログラム。