JP2023068006A - 撮像装置、及び、撮像装置の制御方法 - Google Patents

Abstract

【課題】 ＨＤＲ画像のようにデータ量が大きい画像を記録する際に、記録および再生に適した記録形態で画像を記録することを目的とする。【解決手段】 撮影して得られたＨＤＲ（ハイダイナミックレンジ）画像データを記録する撮像装置であって、撮像センサにより撮影して得られたＨＤＲ画像データを符号化する際に、符号化対象となる符号化領域のＨＤＲ画像データを複数の分割ＨＤＲ画像データに分割し、複数の分割ＨＤＲ画像データを符号化手段によりそれぞれ符号化し、符号化された複数の分割ＨＤＲ画像データを所定の記録フォーマットで記録媒体に記録するように制御する。【選択図】 図３

Description

本発明は、撮像装置、記録装置及び表示制御装置に関する。

画像データを圧縮符号化する画像処理装置として撮像装置が知られている。このような画像処理装置は、撮像部によって動画像信号を取得し、取得した動画像信号を圧縮符号化し、圧縮符号化が行われた画像ファイルを記録媒体に記録する。従来、圧縮符号化前の画像データは１００ｎｉｔｓの輝度レベルを上限とするＳＤＲ（Ｓｔａｎｄａｒｄ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）で表現されたものであった。しかしながら、近年では、輝度レベルの上限を１００００ｎｉｔｓ程度にまで拡張させたＨＤＲ（Ｈｉｇｈ Ｄｙｎａｍｉｃ Ｒａｎｇｅ）で表現され、人が知覚できる輝度範囲に近い輝度範囲を有する画像データが提供されている。

特許文献１では、ＨＤＲの画像を撮影して記録する際に、ＨＤＲに非対応の装置でも、ＨＤＲ画像を詳細に確認可能な画像データを生成して記録する画像データ記録装置について記載がある。

特開２０１７－１３９６１８号公報

特許文献１では、ＨＤＲの画像を記録することについては記載されているが、ＨＤＲ画像を記録する場合の最適な記録方式については考慮されていなかった。

そこで、本発明は、例えばＨＤＲ画像のようにデータ量が大きい画像を記録する際に、記録および再生に適した記録形態で画像を記録する装置を提供することを目的とする。

上述の課題を解決するため、本発明の撮像装置は、
撮影して得られたＨＤＲ（ハイダイナミックレンジ）画像データを記録する撮像装置であって、撮像センサと、撮像センサにより撮影して得られたＨＤＲ画像データを符号化する符号化手段と、撮像センサより撮影して得られたＨＤＲ画像データのうち、符号化対象となる符号化領域のＨＤＲ画像データを複数の分割ＨＤＲ画像データに分割し、複数の分割ＨＤＲ画像データを符号化手段によりそれぞれ符号化し、符号化された複数の分割ＨＤＲ画像データを所定の記録フォーマットで記録媒体に記録するように制御する記録制御手段と、を有することを特徴とする。

本発明によれば、データ量が大きく、かつ、高解像度の画像を記録する際に、記録および再生に適した記録形態で画像を記録する装置を提供することができる。

撮像装置１００の構成を示すブロック図である。 ＨＥＩＦファイルの構造を示す図。 ＨＤＲ撮影モードでの処理を示すフローチャート。 ＨＤＲ撮影モードにおける画像データの分割方法を決定する処理を示すフローチャート。 ＨＤＲ画像データ記録時の画像データの符号化領域および分割方法を示す図。 ＨＥＩＦファイルを構築する処理を示すフローチャート。 ＨＥＩＦファイルとして記録されたＨＤＲ画像データを再生する際の表示処理を示すフローチャート。 オーバーレイ画像作成処理を示すフローチャート。 画像アイテムのプロパティ取得処理を示すフローチャート。 画像アイテムのデータ取得処理を示すフローチャート。 主画像を構成する画像のアイテムＩＤ取得処理を示すフローチャート。 １画像アイテムの画像作成処理を示すフローチャート。 オーバーレイ画像と分割画像の位置関係を示す図。

本発明の実施の形態を、撮像装置１００を例に添付の図面を参照して以下に詳細に説明するが、本発明は、以下の実施形例に限定されるものではない。

＜撮像装置の構成＞
図１は、撮像装置１００を示すブロック図である。図１に示すように、撮像装置１００は、ＣＰＵ１０１と、メモリ１０２と、不揮発性メモリ１０３と、操作部１０４と、撮像部１１２と、画像処理部１１３と、符号化処理部１１４と、表示制御部１１５と、表示部１１６とを有している。更に、撮像装置１００は、通信制御部１１７と、通信部１１８と、記録媒体制御部１１９と、内部バス１３０とを有している。撮像装置１００は、撮影レンズ１１１を用いて被写体の光学像を撮像部１１２の画素アレイに結像するが、撮影レンズ１１１は、撮像装置１００のボディ（筐体、本体）から、着脱不能であってもよいし、着脱可能であってもよい。また、撮像装置１００は、記録媒体制御部１１９を介して画像データの書き込み及び読み出しを記録媒体１２０に対して行う。記録媒体１２０は、撮像装置１００に着脱可能であってもよいし、着脱不能であってもよい。

ＣＰＵ１０１は、不揮発性メモリ１０３に記憶されているコンピュータプログラムを実行することによって、内部バス１３０を介して撮像装置１００の各部（各機能ブロック）の動作を制御する。

メモリ１０２は、書き換え可能な揮発性メモリである。メモリ１０２は、撮像装置１００の各部の動作を制御するためのコンピュータプログラム、撮像装置１００の各部の動作に関するパラメータ等の情報、通信制御部１１７によって受信される情報等を一時的に記録する。また、メモリ１０２は、撮像部１１２によって取得された画像、画像処理部１１３、符号化処理部１１４等によって処理された画像及び情報を一時的に記録する。メモリ１０２は、これらを一時的に記録するために十分な記憶容量を備えている。

不揮発性メモリ１０３は、電気的に消去及び記録が可能なメモリであり、例えばＥＥＰＲＯＭ等が用いられる。不揮発性メモリ１０３は、撮像装置１００の各部の動作を制御するコンピュータプログラム及び撮像装置１００の各部の動作に関するパラメータ等の情報を記憶する。当該コンピュータプログラムにより、撮像装置１００によって行われる各種動作が実現される。

操作部１０４は、撮像装置１００を操作するためのユーザインターフェースを提供する。操作部１０４は、電源ボタン、メニューボタン、撮影ボタン等の各種ボタンを含んでおり、各種ボタンはスイッチ、タッチパネル等により構成される。ＣＰＵ１０１は、操作部１０４を介して入力されたユーザの指示に従って撮像装置１００を制御する。なお、ここでは、操作部１０４を介して入力される操作に基づいてＣＰＵ１０１が撮像装置１００を制御する場合を例に説明したが、これに限定されるものではない。例えば、不図示のリモートコントローラ、不図示の携帯端末等から通信部１１８を介して入力される要求に基づいて、ＣＰＵ１０１が撮像装置１００を制御してもよい。

撮影レンズ（レンズユニット）１１１は、ズームレンズ、フォーカスレンズ等を含む不図示のレンズ群、不図示のレンズ制御部、不図示の絞り等によって構成される。撮影レンズ１１１は、画角を変更するズーム手段として機能し得る。レンズ制御部は、ＣＰＵ１０１から送信される制御信号により、焦点の調整及び絞り値（Ｆ値）の制御を行う。撮像部１１２は、動画像を構成する複数の画像を順次取得する取得手段として機能し得る。撮像部１１２としては、例えば、例えばＣＣＤ（電荷結合素子）、ＣＭＯＳ（相補型金属酸化膜半導体）素子等でのエリアイメージセンサが用いられる。撮像部１１２は、被写体の光学像を電気信号に変換する不図示の光電変換部が行列状、すなわち、２次元的に配列された不図示の画素アレイを有している。当該画素アレイには、被写体の光学像が撮影レンズ１１１によって結像される。撮像部１１２は、撮像した画像を画像処理部１１３又はメモリ１０２に出力する。なお、撮像部１１２は、静止画像を取得することも可能である。

画像処理部１１３は、撮像部１１２から出力される画像データ、又は、メモリ１０２から読み出された画像データに対し、所定の画像処理を行う。当該画像処理の例としては、補間処理、縮小処理（リサイズ処理）、色変換処理等が挙げられる。また、画像処理部１１３は、撮像部１１２によって取得された画像データを用いて、露光制御、測距制御等のための所定の演算処理を行う。画像処理部１１３による演算処理によって得られた演算結果に基づいて、露光制御、測距制御等がＣＰＵ１０１によって行われる。具体的には、ＡＥ（自動露出）処理、ＡＷＢ（オートホワイトバランス）処理、ＡＦ（オートフォーカス）処理等がＣＰＵ１０１によって行われる。

符号化処理部１１４は、画像データに対してフレーム内予測符号化（画面内予測符号化）、フレーム間予測符号化（画面間予測符号化）等を行うことによって、画像データのサイズを圧縮する。符号化処理部１１４は、例えば、半導体素子等により構成された符号化装置である。符号化処理部１１４は、撮像装置１００の外部に設けられた符号化装置であってもよい。符号化処理部１１４は、例えば、Ｈ．２６５（ＩＴＵ Ｈ．２６５又はＩＳＯ／ＩＥＣ２３００８－２）方式によって符号化処理を行う。

表示制御部１１５は、表示部１１６を制御する。表示部１１６は、不図示の表示画面を備える。表示制御部１１５は、画像データに対してリサイズ処理、色変換処理等を行うことにより、表示部１１６の表示画面に表示可能な画像を生成し、当該画像、すなわち、画像信号を表示部１１６に出力する。表示部１１６は、表示制御部１１５から送られてくる画像信号に基づいて、表示画面に画像を表示する。表示部１１６は、表示画面にメニュー等の設定画面を表示する機能であるＯＳＤ（Ｏｎ Ｓｃｒｅｅｎ Ｄｉｓｐｌａｙ）機能を備えている。表示制御部１１５は、画像信号にＯＳＤ画像を重畳して表示部１１６に画像信号を出力し得る。表示部１１６は、液晶ディスプレイ、有機ＥＬディスプレイ等により構成されており、表示制御部１１５から送られてきた画像信号を表示する。表示部１１６は、例えばタッチパネルであってもよい。表示部１１６がタッチパネルである場合、表示部１１６は、操作部１０４としても機能し得る。

通信制御部１１７は、ＣＰＵ１０１に制御される。通信制御部１１７は、ＩＥＥＥ８０２．１１等によりあらかじめ定められた無線通信規格に適合する変調信号を生成して、当該変調信号を通信部１１８に出力する。また、通信制御部１１７は、無線通信規格に適合する変調信号を、通信部１１８を介して受信し、受信した変調信号を復号し、復号した信号に応じた信号をＣＰＵ１０１に出力する。通信制御部１１７は、通信設定を記憶するためのレジスタを備えている。通信制御部１１７は、ＣＰＵ１０１からの制御によって、通信時の送受信感度を調整し得る。通信制御部１１７は、所定の変調方式で送受信を行うことができる。通信部１１８は、通信制御部１１７から供給される変調信号を撮像装置１００の外部にある情報通信機器等の外部機器１２７へ出力し、また、外部機器１２７からの変調信号を受信するアンテナを備えている。また、通信部１１８には、通信用の回路等が備えられている。なお、ここでは、通信部１１８によって無線通信が行われる場合を例に説明したが、通信部１１８によって行われる通信は無線通信に限定されるものではない。例えば、配線等を用いた電気的な接続によって通信部１１８と外部機器１２７とが接続されてもよい。

記録媒体制御部１１９は、記録媒体１２０を制御する。記録媒体制御部１１９は、ＣＰＵ１０１からの要求に基づいて、記録媒体１２０を制御するための制御信号を記録媒体１２０に出力する。記録媒体１２０としては、例えば不揮発性メモリや磁気ディスク等が用いられる。記録媒体１２０は、上述したように、着脱可能であってもよいし、着脱不能であってもよい。記録媒体１２０は、符号化された画像データ等を記録する。記録媒体１２０のファイルシステムに適合した形式で画像データ等がファイルとして保存される。ファイルとしては、例えば、ＭＰ４ファイル（ＩＳＯ／ＩＥＣ １４４９６－１４：２００３）、ＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）ファイル等が挙げられる。各々の機能ブロック１０１～１０４、１１２～１１５、１１７、１１９は、内部バス１３０を介して互いにアクセス可能となっている。

ここで、本実施例の撮像装置１００の通常の動作について説明する。

撮像装置１００は、ユーザが操作部１０４の電源ボタンを操作すると、操作部１０４からＣＰＵ１０１に起動の指示が出される。この指示を受けて、ＣＰＵ１０１は、不図示の電源供給部を制御して、撮像装置１００の各ブロックに対して電源を供給させる。電源が供給されると、ＣＰＵ１０１は、例えば、操作部１０４のモード切り換えスイッチが、例えば、静止画撮影モード、再生モード等のどのモードであるかを操作部１０２からの指示信号により確認する。

通常の静止画撮影モードでは、撮像装置１００は、撮影待機状態でユーザが操作部１０４の静止画記録ボタンを操作することで撮影処理を行う。撮影処理では、撮像部１１２で撮影した静止画の画像データについて、画像処理部１１３で画像処理を施し、符号化処理部１１４で符号化処理し、記録媒体制御部１１９により符号化された画像データを画像ファイルとして記録媒体１２０に記録する。なお、撮影待機状態では、撮像部１１２で所定のフレームレートで画像を撮影し、画像処理部で表示用の画像処理を施して表示制御部１１５により表示部１１６に表示させることによりライブビュー画像の表示を行う。

再生モードでは、記録媒体１２０に記録されている画像ファイルを記録媒体制御部１１９により読み出し、読み出した画像ファイルの画像データを符号化処理部１１４で復号する。つまり、符号化処理部１１４はデコーダの機能も有している。そして、画像処理部１１３で表示用の処理を施し、表示制御部１１５により表示部１１６に表示させる。

通常の静止画の撮影および再生については、上記のように実行されるが、本実施形例の撮像装置では、通常の静止画だけでなく、ＨＤＲ静止画を撮影するためのＨＤＲ撮影モードを有し、また、撮影したＨＤＲ静止画を再生することができる。

以降、ＨＤＲ静止画像の撮影および再生の処理について説明する。

＜ファイル構造＞
まずは、ＨＤＲ静止画像を記録する際のファイル構造について説明する。

最近、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｉｍａｇｅ Ｆｉｌｅ Ｆｏｒｍａｔ（以下、ＨＥＩＦと称す）と呼ばれる静止画ファイルフォーマットが策定された。（ＩＳＯ／ＩＥＣ ２３００８－１２：２０１７）

これは、ＪＰＥＧのような従来の静止画ファイルフォーマットと比べ、以下のような特徴を持つ。
・ＩＳＯベースメディアファイルフォーマット（以下、ＩＳＯＢＭＦＦと称す）に準拠したファイル形式である。（ＩＳＯ／ＩＥＣ １４４９６－１４：２００３）
・単一の静止画像だけでなく、複数の静止画像を格納できる。
・ＨＥＶＣ／Ｈ．２６５やＡＶＣ／Ｈ．２６４など、動画の圧縮に用いられる圧縮形式で圧縮された静止画を格納できる。

本実施形例では、ＨＤＲ静止画像の記録ファイルとして、ＨＥＩＦを採用する。

最初に、ＨＥＩＦが格納するデータについて説明する。

ＨＥＩＦは、格納する個々のデータを、アイテムという単位で管理する。

各アイテムは、データ自身の他に、ファイル内で一意となる整数値アイテムＩＤ（ｉｔｅｍ＿ＩＤ）と、アイテムの種別を表すアイテムタイプ（ｉｔｅｍ＿ｔｙｐｅ）を持つ。

アイテムは、データが画像を表す画像アイテム（ｉｍａｇｅ ｉｔｅｍ）と、データがメタデータであるメタデータアイテム（ｍｅｔａｄａｔａ ｉｔｅｍ）に分けることができる。

画像アイテムには、データが符号化された画像データである符号化画像アイテム（ｃｏｄｅｄ ｉｍａｇｅ ｉｔｅｍ）と、１個以上の他の画像アイテムを操作した結果の画像を表す、導出画像アイテム（ｄｅｒｉｖｅｄ ｉｍａｇｅ ｉｔｅｍ）がある。

導出画像アイテムの例として、オーバーレイ形式の導出画像アイテムであるオーバーレイ画像がある。これは、ＩｍａｇｅＯｖｅｒｌａｙ構造体（オーバーレイ情報）用いて、任意個の画像アイテムを任意の位置に配置して合成された結果のオーバーレイ画像である。

メタデータアイテムの例として、Ｅｘｉｆデータを格納することができる。

前述のように、ＨＥＩＦは複数の画像アイテムを格納することができる。

複数の画像間に関係がある場合、それらの関係を記述することができる。

複数の画像間の関係の例は、導出画像アイテムとそれを構成する画像アイテムの関係、本画像とサムネイル画像の関係、などである。

また、画像アイテムとメタデータアイテムの関係も、同様に記述することができる。

ＨＥＩＦ形式は、ＩＳＯＢＭＦＦ形式に準拠している。そのため、まず、ＩＳＯＢＭＦＦについて、簡単に説明する。

ＩＳＯＢＭＦＦ形式は、ボックスと呼ばれる構造でデータを管理する。

ボックスは、４バイトのデータ長フィールドと、４バイトのデータタイプフィールドから始まり、それ以降に任意長のデータを持つデータ構造である。

データ部の構造は、データタイプによって決定する。ＩＳＯＢＭＦＦの仕様書やＨＥＩＦの仕様書では、いくつかのデータタイプ及びそのデータ部の構造が規定されている。

また、ボックスは、別のボックスをデータに持つこともある。すなわち、ボックスの入れ子が可能である。ここで、あるボックスのデータ部に入れ子にされたボックスを、サブボックスと呼ぶ。

また、サブボックスではないボックスを、ファイルレベルのボックスと呼ぶ。これは、ファイルの先頭から、順次アクセス可能なボックスである。

図２を用いて、ＨＥＩＦ形式のファイルについて説明する。

まず、ファイルレベルのボックスについて説明する。

データタイプが’ｆｔｙｐ’であるファイルタイプボックスには、ファイルの互換性に関する情報を格納する。ＩＳＯＢＭＦＦ準拠のファイル仕様は、その仕様が規定するファイルの構造や、ファイルが格納するデータを、ブランドと呼ぶ４バイトのコードで宣言し、それらをファイルタイプボックスに格納する。ファイルの先頭にファイルタイプボックスを配置することにより、ファイルのリーダは、ファイルタイプボックスの内容をチェックすることで、さらにファイルの内容を読み出して解釈することなく、ファイルの構造を知ることができる。

ＨＥＩＦの仕様では、’ｍｉｆ１’というブランドでそのファイル構造を表す。また、格納する符号化画像データがＨＥＶＣ圧縮されたデータの場合、ＨＥＶＣ圧縮のプロファイルに従って、’ｈｅｉｃ’または’ｈｅｉｘ’というブランドで表す。

データタイプが’ｍｅｔａ’であるメタデータボックスは、いろいろなサブボックスを含み、各アイテムに関するデータを格納する。内訳については、後述する。

データタイプが’ｍｄａｔ’であるメディアデータボックスには、各アイテムのデータを格納する。例えば、符号化画像アイテムの符号化画像データや、メタデータアイテムのＥｘｉｆデータ、である。

次に、メタデータボックスのサブボックスについて説明する。

データタイプが’ｈｄｌｒ’であるハンドラボックスは、メタデータボックスが管理するデータのタイプを表す情報を格納する。ＨＥＩＦ仕様では、ハンドラボックスのｈａｎｄｌｅｒ＿ｔｙｐｅは‘ｐｉｃｔ’である。

データタイプが’ｄｉｎｆ’であるデータ情報ボックスは、このファイルが対象とするデータが存在するファイルを指定する。ＩＳＯＢＭＦＦでは、あるファイルが対象とするデータを、そのファイル以外のファイルに格納することが可能である。その場合、データ情報ボックス内のデータリファレンスに、データが存在するファイルのＵＲＬを記述したデータエントリＵＲＬボックスを格納する。対象とするデータが同じファイルに存在する場合、それを表すフラグのみを有するデータエントリＵＲＬボックスを格納する。

データタイプが’ｐｉｔｍ’であるプライマリアイテムボックスは、主画像を表す画像アイテムのアイテムＩＤを格納する。

データタイプが’ｉｉｎｆ’であるアイテム情報ボックスは、以下の、アイテム情報エントリを格納するためのボックスである。

データタイプが’ｉｎｆｅ’であるアイテム情報エントリは、各アイテムの、アイテムＩＤやアイテムタイプ、フラグを格納する。

符号化画像データがＨＥＶＣ圧縮されたデータである画像アイテムのアイテムタイプは、’ｈｖｃ１’であり、画像アイテムである。

オーバーレイ形式の導出画像アイテム、つまり、ＩｍａｇｅＯｖｅｒｌａｙ構造体（オーバーレイ情報）のアイテムタイプは、’ｉｏｖｌ’であり、画像アイテムに分類である。

Ｅｘｉｆ形式のメタデータアイテムのアイテムタイプは、’Ｅｘｉｆ’であり、メタデータアイテムである。

また、画像アイテムには、フラグフィールドの最下位ビットが立っている場合、その画像アイテムは隠し画像（ｈｉｄｄｅｎ ｉｍａｇｅ）であることを指定することができる。このフラグが立っている場合、その画像アイテムは、再生時に表示対象として扱われず、非表示となる。

データタイプが’ｉｒｅｆ’であるアイテム参照ボックスは、各アイテム間の参照関係を、参照関係の種類、参照元アイテムのアイテムＩＤ、１個以上の参照先アイテムのアイテムＩＤ、で格納する。

オーバーレイ形式の導出画像アイテムの場合、参照関係の種類に’ｄｉｍｇ’、参照元アイテムのアイテムＩＤに導出画像アイテムのアイテムＩＤ、参照先アイテムのアイテムＩＤにオーバーレイを構成する各画像アイテムのアイテムＩＤ、を格納する。

サムネイル画像の場合、参照関係の種類に’ｔｈｍｂ’、参照元アイテムのアイテムＩＤにサムネイル画像のアイテムＩＤ、参照先アイテムのアイテムＩＤに本画像のアイテムＩＤ、を格納する。

データタイプが’ｉｐｒｐ’であるアイテムプロパティボックスは、以下の、アイテムプロパティコンテナボックスとアイテムプロパティ関連ボックスを格納するためのボックスである。

データタイプが’ｉｐｃｏ’であるアイテムプロパティコンテナボックスは、個々のプロパティデータのボックスを格納するボックスである。

各画像アイテムは、その画像の特徴、属性を表すプロパティデータを持つことができる。

プロパティデータボックスには、以下のようなものがある。

デコーダ構成・初期化データ（Ｄｅｃｏｄｅｒ ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ ｉｎｉｔｉａｌｉｚａｔｉｏｎ。ＨＥＶＣの場合、タイプは’ｈｖｃＣ’）は、デコーダの初期化に使われるデータである。ＨＥＶＣのパラメータセットデータ（ＶｉｄｅｏＰａｒａｍｅｔｅｒＳｅｔ、ＳｅｑｕｅｎｃｅＰａｒａｍｅｔｅｒＳｅｔ、ＰｉｃｔｕｒｅＰａｒａｍｅｔｅｒＳｅｔ）は、ここに格納する。

画像空間範囲（Ｉｍａｇｅ ｓｐａｔｉａｌ ｅｘｔｅｎｔｓ。タイプは’ｉｓｐｅ’）は、画像の大きさ（幅、高さ）である。

色空間情報（Ｃｏｌｏｕｒ ｉｎｆｏｒｍａｔｉｏｎ。タイプは’ｃｏｌｒ’）は、画像の色空間情報である。

画像回転情報（Ｉｍａｇｅ ｒｏｔａｔｉｏｎ。タイプは’ｉｒｏｔ’）が、画像を回転して表示する際の、回転方向である。

画像のピクセル情報（タイプは’ｐｉｘｉ’）は、画像を構成するデータのビット数を示す情報である。

また、本実施例では、ＨＤＲメタデータとして、マスターディスプレイカラーボリューム情報（Ｍａｓｔｅｒｉｎｇ ｄｉｓｐｌａｙ ｃｏｌｏｕｒ ｖｏｌｕｍｅ。タイプは’ＭＤＣＶ’）や、コンテンツライトレベル情報（Ｃｏｎｔｅｎｔｓ ｌｉｇｈｔ ｌｅｖｅｌ ｉｎｆｏｒｍａｔｉｏｎ。タイプは’ＣＬＬＩ’）を、プロパティデータボックスとして格納している。

上記以外プロパティも存在するが、ここでは明記しない。

データタイプが’ｉｐｍａ’であるアイテムプロパティ関連ボックスは、各アイテムとプロパティの関連付けを、アイテムＩＤと、関連するプロパティの’ｉｐｃｏ’におけるインデックスの配列、の形式で格納する。

データタイプが’ｉｄａｔ’であるアイテムデータボックスは、データサイズが小さいアイテムデータを格納するボックスである。

オーバーレイ形式の導出画像アイテムのデータは、構成画像の位置情報などを格納したＩｍａｇｅＯｖｅｒｌａｙ構造体（オーバーレイ情報）を’ｉｄａｔ’に格納することができる。オーバーレイ情報には、背景色情報であるｃａｎｖａｓ＿ｆｉｌｌ＿ｖａｌｕｅパラメータや、オーバーレイで合成した際の最終的な合成後の再生画像サイズであるｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔパラメータ等がある。さらに、合成要素となる画像毎に、合成画像内での配置位置を水平位置座標、垂直位置座標を示すｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔパラメータがある。オーバーレイ情報に含まれるこれらのパラメータを用いることにより、指定した背景色、サイズの１つの画像内の任意の位置に複数の画像を配置した合成画像を再生することができる。 データタイプが’ｉｌｏｃ’であるアイテムロケーションボックスは、各アイテムのデータの位置情報を、オフセット基準（ｃｏｎｓｔｒｕｃｔｉｏｎ＿ｍｅｔｈｏｄ）、オフセット基準からのオフセット値、長さ、の形式で格納する。

オフセット基準は、ファイルの先頭、または、’ｉｄａｔ’、である。

なお、メタデータボックスには上記以外のボックスも存在するが、ここでは明記しない。

図２では、２つの符号化画像アイテムがオーバーレイ形式の画像を構成している構造を図示している。オーバーレイ形式の画像を構成する符号化画像アイテム数は２に限定されない。オーバーレイ形式の画像を構成する符号化画像アイテム数が増加すると、以下のボックス、項目、がその分増加する。
・アイテム情報ボックスに、符号化画像アイテムの、アイテム情報エントリが追加。
・アイテム参照ボックスの参照関係種類‘ｄｉｍｇ’の参照先アイテムＩＤに、符号化画像アイテムのアイテムＩＤが増加。
・アイテムプロパティコンテナボックスにおける、デコーダ構成・初期化データ、画像空間範囲、など。
・アイテムプロパティ関連ボックスに、符号化画像アイテムとその関連プロパティのインデックスの項目が追加。
・アイテムロケーションボックスに符号化画像アイテムの位置情報の項目が追加。
・メディアデータボックスに、符号化画像データが追加。

＜ＨＤＲ画像の撮影＞
次に、ＨＤＲ画像を撮影して記録する際の撮像装置１００での処理について説明する。

記録する画像の幅や高さが昨今大きくなってきているが、あまりに大きいサイズを符号化すると他機種での復号時に互換性が失われたり、システムの規模が大きくなったりする。具体的に本実施例では符号・復号にＨ．２６５を用いた例を説明する。Ｈ．２６５には規格として、ＰｒｏｆｉｌｅやＬｅｖｅｌといったパラメータがあり、画像符号化方法や、画像サイズが大きくなるとこれらのパラメータが変化する。これらの値は復号時の機器で再生対象の可否を判断するパラメータであり、このパラメータを判定して再生不可として弾かれる場合がある。本実施例では大きな画像サイズを記録する場合、複数の画像表示領域に分割して、ＨＥＩＦ規格が謳うオーバーレイの方法を用い、それらの符号データをＨＥＩＦファイルに格納して管理する方法について述べる。このように複数の画像表示領域に分けることで１つあたりの画像表示領域のサイズが小さくなり他の機種での再生互換性が高まる。以下、符号化領域の１辺のサイズを４０９６以下と定めて説明する。なお符号化形式はＨ．２６５以外のものであってもよいし、１辺のサイズを４０９６以外のサイズに規定してもよい。

次に符号化領域の開始位置や符号化領域の幅・高さ、また、再生領域の開始位置や再生領域の幅・高さについてのアライメント制約について説明する。撮像装置としては、分割後の画像を符号化する際に、符号化領域の垂直・水平符号化開始アライメントや、再生時の再生幅・高さアライメント等がハードウエア制約として一般的に存在する。つまり１つ以上の符号化領域のそれぞれの符号化開始位置、再生領域の開始位置や幅・高さを計算して符号化する必要がある。撮像装置はユーザからの指示で複数の画像サイズを切り替えて記録するため、画像サイズごとにそれらを切り替える必要がある。

本実施例で説明する符号化処理部１１４は符号化時に横方向（以後ｘ方向）に６４画素単位、縦方向（以後ｙ方向）に１画素単位の開始位置のアライメント制約がある。また符号化する幅、高さのアライメント制約にそれぞれ３２画素単位、１６画素単位の制約がある。再生領域の開始位置はｘ方向に２画素単位、ｙ方向に１画素単位の開始位置のアライメント制約がある。また、再生領域の幅・高さのアライメント制約はそれぞれ、２画素、１画素単位の制約がある。なお、ここでアライメント制約について例を述べたが、一般的にはこれ以外のアライメント制約であってもよい。

次にＨＤＲ記録モード（ＨＤＲ撮影モード）でＨＤＲ画像データを撮影し、撮影したＨＤＲ画像データをＨＥＩＦファイルとして記録するまでのフローについて図３を用いて説明する。ＨＤＲモードでは撮像部１１２と画像処理部１１３においてＨＤＲを示す色域ＢＴ．２０２０と、ＰＱガンマカーブを用いてＨＤＲの色空間を表現する処理を行う。ＨＤＲのための記録については本実施例では割愛する。

Ｓ１０１ではＣＰＵ１０１がユーザによるＳＷ２の押下の有無を判定する。ユーザが被写体を捉え、ＳＷ２まで押下した場合（Ｓ１０１のＹＥＳ）、ＣＰＵ１０１はＳＷ２が押されたことを検知し、Ｓ１０２に遷移する。ＳＷ２が押されるまでＣＰＵ１０１はこの検出を続ける（Ｓ１０１のＮＯ）。

Ｓ１０２ではＣＰＵ１０１が、ユーザが捉えた画角の画像をＨＥＩＦファイルに保存するため、符号化領域を縦横方向にいくつに分割するか（分割数Ｎ）、どのように分割するかを決定する。この結果をメモリ１０２に保存する。Ｓ１０２については図４を用いながら後述する。Ｓ１０３に進む。

Ｓ１０３ではＣＰＵ１０１がメモリ１０２にある変数ＭをＭ＝１に初期化する。その後Ｓ１０４に進む。

Ｓ１０４ではＣＰＵ１０１が、Ｓ１０２で決定した分割数Ｎ回分ループしたかを監視する。ループ回数が分割数Ｎに到達した場合（Ｓ１０４のＹＥＳ）Ｓ１０９に進み、そうでなければ（Ｓ１０４のＮＯ）Ｓ１０５に進む。

Ｓ１０５ではＣＰＵ１０１が分割画像Ｍの符号開始領域、再生領域の情報を先のメモリ１０２から読み出しておく。Ｓ１０６に進む。

Ｓ１０６ではＣＰＵ１０１が符号化処理部１１４にメモリ１０２に配置された画像全体のうち、どの領域を符号化するかを伝え、符号化させる。Ｓ１０７に進む。

Ｓ１０７では符号化処理部１１４が符号化した結果の符号データと、符号時に発生する付随情報をＣＰＵ１０１がメモリ１０２に一時保存する。具体的にＨ．２６５の例では、のちにＨＥＩＦファイルに格納しなければならない、ＶＰＳ、ＳＰＳ、ＰＰＳ等のＨ．２６５規格情報のことである。本実施例とは直接関係ないため割愛するが、Ｈ．２６５のＶＰＳ、ＳＰＳ、ＰＰＳは、符号データのサイズや、ビット深度、表示・非表示領域の指定、フレーム情報等復号に必要な様々な情報である。その後Ｓ１０８に進む。

Ｓ１０８ではＣＰＵ１０１が変数ＭをインクリメントしＳ１０４に戻る。

Ｓ１０９ではＣＰＵ１０１がＨＥＩＦファイルに格納するメタデータを生成する。ＣＰＵ１０１は、撮像部１１２、画像処理部１１３、符号化処理部１１４等から、再生時に必要な情報を引出し、メタデータとしてメモリ１０２に一旦保存する。具体的にはＥｘｉｆ形式に成形されたデータである。Ｅｘｉｆデータの詳細についてはすでに一般的であるため本実施例での説明は割愛する。Ｓ１１０に進む。

Ｓ１１０ではＣＰＵ１０１がサムネイルを符号化する。メモリ１０２にある画像全体を画像処理部１１３が縮小しサムネイルサイズにして一旦メモリ１０２に配置する。このメモリ１０２にあるサムネイル画像をＣＰＵ１０１が符号化処理部１１４に指示して符号化する。ここでサムネイルは先に述べたアライメント制約を満たすようなサイズで符号化するが、符号化領域と再生領域とが異なる方式でもよい。このサムネイルもＨ．２６５で符号化される。Ｓ１１１に進む。

Ｓ１１１では符号化処理部１１４がサムネイルを符号化した結果の符号データと、符号時に発生する付随情報をＣＰＵ１０１がメモリ１０２に一時保存する。先のＳ１０７の説明と同様にＶＰＳ、ＳＰＳ、ＰＰＳ等のＨ．２６５規格情報のことである。次にＳ１１２に進む。

Ｓ１１２では、ここまでのステップでＣＰＵ１０１が各種データをメモリ１０２に保存した。ＣＰＵ１０１はこのメモリ１０２に保存したデータを順序良く結合しＨＥＩＦファイルを完成させ、メモリ１０２に保存する。このＨＥＩＦファイルを完成させるためのフローは、図６を用いてのちに説明する。Ｓ１１３に進む。

Ｓ１１３でＣＰＵ１０１は、メモリ１０２にあるＨＥＩＦファイルを記録媒体制御部１１９によって記録媒体 １２０に書き出すよう指示する。その後Ｓ１０１に戻る。

このようなステップで撮影が行われてからＨＥＩＦファイルが記録媒体１２０に記録される。

次に、先に説明したＳ１０２での分割の方法決定について、図４、図５（ａ）を用いて説明する。以下センサ画像領域の左上を原点（０、０）とし、座標を（ｘ、ｙ）、幅高さをそれぞれｗ、ｈで表す。また領域については開始座標の（ｘ、ｙ）と幅高さのｗ、ｈを合わせて［ｘ、ｙ、ｗ、ｈ］と表現する。

Ｓ１２１でＣＰＵ１０１は撮影時の記録モードをメモリ１０２から取得する。記録モードとは例えば画像サイズ、画像のアスペクト比、画像の圧縮率などが決定した記録方法を決めたもので、ユーザはこの記録モードから１つを選択して撮影を行う。例えば、Ｌサイズ、３：２アスペクトなどの設定のことである。記録モードに応じて撮影画角が異なるため、撮影の画角を決定する。Ｓ１２２に進む。

Ｓ１２２ではセンサ画像領域［０、０、Ｈ、Ｖ］の中から、再生画像の開始座標位置（ｘ０、ｙ０）を取得する。次にＳ１２３に進む。

Ｓ１２３では再生画像の領域［ｘ０、ｙ０、Ｈｐ、Ｖｐ］をメモリ１０２から取得する。次にＳ１２４に進む。

Ｓ１２４では再生画像の領域を含むように符号化する必要がある。先に述べたように符号開始位置のアライメントはｘ方向に６４画素のアライメントをとるため、再生画像の領域を含むように符号化しようとすると（Ｅｘ０、Ｅｙ０）の位置から符号化しなければならない。このようにしてＬｅｘのサイズが求まる。このＬｅｘのオフセットが０であれば（Ｓ１２４のＮＯ）Ｓ１２６に進み、必要であれば（Ｓ１２４のＹＥＳ）Ｓ１２５に進む。

Ｓ１２５では、Ｌｅｘを求める。Ｌｅｘは先に述べたように再生画像領域と符号化開始位置のアライメントによって決定される。ＣＰＵ１０１はＬｅｘを以下のようにして決定する。ｘ０を水平方向の符号化開始位置の画素アライメント６４画素で除し、その商に先の６４画素を乗じて求める。余りを含めず計算するため、再生画像領域の開始位置よりも左側に位置する座標が得られる。よってＬｅｘは、再生画像領域のｘ座標から先の計算によって求めた符号化開始位置のｘ座標の差で求まる。Ｓ１２６に進む。

Ｓ１２６では再生画像の最上位ラインの右端の最終位置の座標を計算する。これを（ｘＮ、ｙ０）とする。ｘＮはｘ０にＨｐを加算して求める。Ｓ１２７に進む。

Ｓ１２７では再生画像の右端を含むように符号化領域の右端を求める。符号化領域の右端ｗの求めるためには、符号化の幅のアライメント制約が必要である。先に述べたように符号化の幅・高さの制約はそれぞれ３２画素の倍数の制約がある。この制約と（ｘＮ、ｙ０）との関係から再生画像の右端より先にＲｅｘのオフセットが必要かどうかをＣＰＵ１０１が計算する。Ｒｅｘが必要であれば（Ｓ１２７のＹＥＳ）Ｓ１２８に進み、不要であれば（Ｓ１２７のＮＯ）Ｓ１２９に進む。

Ｓ１２８では、ＣＰＵ１０１が再生画像右端座標（ｘＮ、ｙ０）の右側に３２画素のアライメントになるようにＲｅｘを付加し、符号化の終了位置（ＥｘＮ、Ｅｙ０）を求める。Ｓ１２９に進む。

Ｓ１２９では、ＣＰＵ１０１が表示領域の右下の座標を求める。再生画像のサイズが自明のためこの座標は（ｘＮ、ｙＮ）となる。Ｓ１３０に進む。

Ｓ１３０では再生画像の下端を含むように符号化領域の下端を求める。符号化領域の下端を求めるためには、符号化の高さのアライメント制約が必要である。先に述べたように符号化の高さの制約はそれぞれ１６画素の倍数の制約がある。この制約と再生画像の右下座標（ｘＮ、ｙＮ）との関係から再生画像の下端より先にＶｅｘのオフセットが必要かどうかをＣＰＵ１０１が計算する。Ｖｅｘが必要であれば（Ｓ１３０のＹＥＳ）Ｓ１３１に進み、不要であれば（Ｓ１３０のＮＯ）Ｓ１３２に進む。

Ｓ１３１ではＣＰＵ１０１がＶｅｘを先の制約と再生画像の右下座標（ｘＮ、ｙＮ）との関係から計算し、符号化領域の右下の座標（ＥｘＮ、ＥｙＮ）を求める。Ｖｅｘの計算方法は、垂直方向の符号化開始位置であるｙ０からｙＮを含むように符号化の高さアライメントである１６画素の倍数の位置に設定する。具体的には、ｙ０＝０であったとして、Ｖｐを符号化の高さアライメントの１６画素で除し、商と余りを求める。再生領域を含むように符号化領域をとらなければならないため、余りがある場合は商に１を加算し、先の１６画素を乗じる。これによって１６画素の倍数でありながらＶｐを含む符号化領域の下端のｙ座標のＥｙＮが得られる。ＶｅｘはＥｙＮからｙＮの差で求まる。なお、ＥｙＮはｙＮからＶｅｘだけ下方向にオフセットさせた値であり、ＥｘＮはＳ１２８で既に求めた値である。Ｓ１３２に進む。

Ｓ１３２では、ＣＰＵ１０１が、符号化領域のサイズＨｐ’ｘＶｐ’を以下のように求める。水平サイズＨｐに、アライメント制約から求めたＬｅｘとＲｅｘを加算して、Ｈｐ’を求める。また、垂直サイズＶｐに、アライメント制約から求めたＶｅｘを加算して、Ｖｐ’を求める。Ｈｐ’とＶｐ’から符号化領域のサイズＨｐ’×Ｖｐ’が求まる。Ｓ１３３に進む。

Ｓ１３３では、ＣＰＵ１０１が符号化対象の水平サイズＨｐ’が分割すべき４０９６画素を超えるか否かを判断し、超える場合は（Ｓ１３３のＹＥＳ）Ｓ１３４に進み、超えない場合（Ｓ１３３のＮＯ）はＳ１３５に進む。

Ｓ１３４では、符号化対象の水平サイズＨｐ’を４０９６画素以下になるように２つ以上の領域に分割する。例えば６０００画素であれば２分割であるし、９０００画素であれば３分割となる。

２分割の場合は、先の符号化の幅に関するアライメント３２画素を満足するおおよその中心位置で分割する。均等にならない場合は左の分割画像を大きくする。また３分割に分割する場合で均等にならない場合、先の符号化の幅に関するアライメントに注意しながら、Ａ、Ｂ、Ｃと分割領域を分け、分割領域ＡとＢのサイズが等しくなるようにし、分割領域Ｃをそれよりも若干小さくなるように分割する。３分割以上であっても同じアルゴリズムによって分割位置、サイズを決定する。Ｓ１３５に進む。

Ｓ１３５では、ＣＰＵ１０１が符号化対象の垂直サイズＶｐ’が分割すべき４０９６画素を超えるか否かを判断し、超える場合（Ｓ１３５のＹＥＳ）はＳ１３６に進み、超えない場合（Ｓ１３５のＮＯ）は処理を終了する。

Ｓ１３６では、Ｓ１３４と同様にＶｐ’を複数の分割領域に分割し処理を終了する。

Ｓ１０２での分割の例について、図５（ｂ）、（ｃ）、（ｄ）、（ｅ）を用いて具体的な数値で説明する。図５は、画像データの分割方法だけでなく、符号化領域および再生領域の関係も示している。

図５（ｂ）について説明する。図５（ｂ）は左右二つの領域に画像を分割し再生領域の左右と下端にＬｅｘ、Ｒｅｘ、Ｖｅｘが付与されるケースである。まず、再生画像領域は［２５６＋４８、０、４８６４、３２４２］が撮像装置で記録したい最終的な画像の領域である。この再生画像領域の左上の座標は（２５６＋４８、０）であり、先に述べた符号化の開始アライメントである６４画素単位の倍数ではない。よって、ここより４８画素左側にＬｅｘを設け、符号化開始位置の左端はｘ＝２５６の位置となる。次に再生領域の幅についてはｗ＝４８＋４８６４となるが、これは符号化の幅のアライメントの３２画素の倍数になっておらず符号化時の幅の制約アライメントを鑑みて、再生画像領域の右端に１６画素Ｒｅｘを付与する。同様に垂直方向も計算するとＶｅｘ＝４画素となる。この再生画像は横方向のサイズが４０９６を超えているため、横方向を符号化の幅のアライメントを鑑みつつおおよそ中心の位置で２分割し、結果として分割画像１の符号化領域は［２５６、０、２４９６、３２４２＋８］、分割画像２の符号化画像領域は［２５６＋２４９６、０、２４３２、３２４２＋８］が求まる。

図５（ｃ）について説明する。図５（ｃ）は左右二つの領域に画像を分割し、再生領域の右と下端にＲｅｘ、Ｖｅｘが付与されるケースである。再生画像領域のｘ位置がｘ＝０のため、符号化領域の開始アライメントである６４画素とも一致するためＬｅｘ＝０となる。以後、先に述べた計算方法と同様であり、結果として分割画像１の符号化領域は［０、０、２２４０、３２４５６＋８］、分割画像２の符号化画像領域は［２２４０、０、２１４４、２４５６＋８］が求まる。

図５（ｄ）について説明する。図５（ｄ）は左右二つの領域に画像を分割し、再生領域の左右にＬｅｘ、Ｒｅｘが付与されるケースである。再生画像領域の縦サイズｈ＝３６４８であり、これは符号化時の画像高さの制約である１６画素の倍数となるため、Ｖｅｘ＝０となる。以後、先に述べた計算方法と同様であり、結果として分割画像１の符号化領域は［２５６＋４８、０、２２４０、３６４８］、分割画像２の符号化画像領域は［２５６＋２２４０、０、２１４４、３６４８］が求まる。

図５（ｄ）について説明する。図５（ｄ）は上下左右に４つの領域に画像を分割し、再生領域の左右にＬｅｘ、Ｒｅｘが付与されるケースである。このケースは符号化領域が、縦方向も横方向も４０９６を超えるため、田の字に分割を実施する。以後、先に述べた計算方法と同様であり、結果として分割画像１の符号化領域は［０、０、４０３２、３００８］、分割画像２の符号化画像領域は［４０３２、０、４０３２、３００８］、分割画像３の符号化画像領域は［０、３００８、４０３２、２９０２］、分割画像４の符号化画像領域は［４０３２、３００８、４０３２、２９０２］が求まる。

このようにしてＣＰＵ１０１は記録モードに応じて再生画像の領域が決定し、それごとに分割領域の計算を行う必要がある。他の方法として、これらの計算をあらかじめ実施しておき、その結果をメモリ１０２保存しておく。ＣＰＵ１０１は記録モードに応じた分割領域、再生領域の情報をメモリ１０２から読みだして符号化処理部１１４に設定してもよい。

本実施例のように撮影画像を複数の分割画像に分割して記録する場合、記録した画像から撮影画像を復元するには、複数の表示領域を合成する必要がある。合成画像を生成する際に、各々の分割画像に重複領域がないほうが、余分なデータの符号化や記録をしなくてよいため、効率的となる。そのため、本実施例では分割画像間で接する境界には重なる部分（重複領域）を持たないように、各再生領域、各符号化領域を設定した。ただし、ハードウエアのアライメント制約などの条件によっては分割画像間に重複領域を設けても構わない。

次に、先のＳ１１２で述べたＨＥＩＦファイルの構築方法について図６を用いながら説明する。ＨＥＩＦファイルは図２で示す構造であるから、ＣＰＵ１０１はファイルの先頭から順にメモリ１０２上に構築する。

Ｓ１４１で’ｆｔｙｐ’ボックスを生成する。このボックスはファイルの互換性を知るためのボックスでファイルの先頭におかれる。ＣＰＵ１０１はこのボックスのメジャーブランドに’ｈｅｉｃ’、コンパチブルブランドに’ｍｉｆ１’、’ｈｅｉｃ’を格納する。本実施例ではこれらの値を使用するがこれ以外であってもよい。Ｓ１４２に進む。

Ｓ１４２で’ｍｅｔａ’ボックスを生成する。このボックスは以下に記載の複数のボックスを格納するボックスである。ＣＰＵ１０１はこのボックスを生成してＳ１４３に進む。

Ｓ１４３では、’ｉｉｎｆ’ボックス内に格納する’ｈｄｌｒ’ボックスを生成する。このボックスは先に述べた’ｍｅｔａ’ボックスの属性を示すものである。ＣＰＵ１０１はこのタイプに’ｐｉｃｔ’を格納して、Ｓ１４４に進む。なお’ｐｉｃｔ’は、メタデータボックスが管理するデータのタイプを表す情報であり、ＨＥＩＦ仕様では、ハンドラボックスのｈａｎｄｌｅｒ＿ｔｙｐｅは‘ｐｉｃｔ’と規定されている。

Ｓ１４４では、’ｉｉｎｆ’ボックス内に格納する’ｄｉｎｆ’ボックスを生成する。このボックスはこのファイルが対象とするデータの存在位置を示すものである。ＣＰＵ１０１はこのボックスを生成してＳ１４５に進む。

Ｓ１４５では、’ｉｉｎｆ’ボックス内に格納する’ｐｉｔｍ’ボックスを生成する。このボックスは、主画像を表す画像アイテムのアイテムＩＤを格納する。主画像となるのはオーバーレイで合成されたオーバーレイ画像であるからＣＰＵ１０１はオーバーレイ情報アイテムＩＤを、主画像のアイテムＩＤとして格納する。Ｓ１４６に進む。

Ｓ１４６では、’ｍｅｔａ’ボックス内に格納する’ｉｉｎｆ’ボックスを生成する。このボックスはアイテムのリストを管理するボックスである。ここではデータ長フィールドに初期値を入れ、データタイプフィールドに’ｉｉｎｆ’を保存しＳ１４７に進む。

Ｓ１４７では、’ｉｉｎｆ’ボックス内に格納する’ｉｎｆｅ’ボックスを生成する。この’ｉｎｆｅ’ボックスはファイル内に格納される各アイテムのアイテム情報を登録するボックスであり、アイテム毎に’ｉｎｆｅ’ボックスを生成する。分割画像については、それぞれの分割画像が１つのアイテムとしてこのボックスに登録される。他にも、複数の分割画像から主画像を構成するためのオーバーレイ情報や、Ｅｘｉｆ情報、サムネイル画像が、それぞれアイテムとして登録される。この際、前述したとおり、オーバーレイ情報、分割画像、サムネイル画像は、画像アイテムとして登録する。画像アイテムについては、隠し画像を示すフラグを付加することが可能であり、このフラグが付加することにより、再生時に画像が表示されないことになる。つまり、画像アイテムにこの隠し画像フラグを付加することにより、再生時に非表示とする画像を指定することができる。そこで、分割画像に関しては、隠し画像を示すフラグを立てておき、オーバーレイ情報のアイテムにはそのフラグを立てないでおく。これにより、個々の分割画像自体は表示対象外となり、オーバーレイ情報により複数の分割画像がオーバーレイ合成された結果の画像のみが表示対象となる。それぞれのアイテムについて個別に’ｉｎｆｅ’ボックスを生成し、それらを先の’ｉｉｎｆ’内に格納する。Ｓ１４８に進む。

Ｓ１４８では、’ｉｉｎｆ’ボックス内に格納する’ｉｒｅｆ’ボックスを生成する。このボックスはオーバーレイで構成される画像（主画像）、その画像を構成する分割画像の関係を示す情報を格納する。先に説明したＳ１０２で分割方法が決定しているため、決定された分割方法に基づいてＣＰＵ１０１はこのボックスを生成する。Ｓ１４９に進む。

Ｓ１４９では、’ｉｉｎｆ’ボックス内に格納する’ｉｐｒｐ’ボックスを生成する。このボックスはアイテムのプロパティを格納するボックスであり、Ｓ１５０で生成される’ｉｐｃｏ’ボックスや、Ｓ１５１で生成される’ｉｐｍａ’ボックスを格納するボックスである。Ｓ１５０に進む。

Ｓ１５０では、’ｉｐｒｐ’ボックス内に格納する’ｉｐｃｏ’ボックスを生成する。このボックスはアイテムのプロパティコンテナボックスであり、各種プロパティを保存する。プロパティは複数存在し、ＣＰＵ１０１は以下のプロパティコンテナボックスを生成して’ｉｐｃｏ’ボックス内に格納する。プロパティは、画像アイテム毎に生成されるものと複数の画像アイテムに共通して生成されるものがある。主画像となるオーバーレイ情報により構成されるオーバーレイ画像および分割画像とで共通する情報として、’ｃｏｌｒ’ボックスを生成する。’ｃｏｌｒ’ボックスには、主画像（オーバーレイ画像）、分割画像の色空間情報として、ＨＤＲのガンマカーブ等の色情報を格納する。分割画像については、それぞれ、’ｈｖｃＣ’ボックス、’ｉｓｐｅ’ボックスを生成する。先に説明したＳ１０７やＳ１１１で、メモリ１０２に格納してある符号化時の付随情報をＣＰＵ１０１が読み出し、’ｈｖｃＣ’のプロパティコンテナボックスを生成する。この’ｈｖｃＣ’に格納する付随情報は、符号化領域を符号化したときの情報や、符号化領域のサイズ（幅、高さ）だけでなく、再生領域のサイズ（幅、高さ）や、符号化領域中の再生領域の位置情報等も含む。これらの付随情報がゴロム圧縮されて’ｈｖｃＣ’のプロパティコンテナボックスに記録される。ゴロム圧縮については一般的な圧縮方法のためここでは説明を割愛する。また、’ｉｓｐｅ’ボックスには、分割画像の再生領域のサイズ（幅、高さ）情報（例として２２４０ｘ２４５０等）を格納する。主画像となるオーバーレイ画像の回転を表す情報を格納した’ｉｒｏｔ’ボックス、画像のデータのビット数を示す‘ｐｉｘｉ’ボックスを生成する。‘ｐｉｘｉ’ボックスについては、主画像（オーバーレイ画像）と分割画像とで個別に生成してもよいが、本実施例においてはオーバーレイ画像と分割画像は同じビット数、つまり１０ビットであるので１つだけ生成する。またＨＤＲの補足情報が格納される’ＣＬＬＩ’や’ＭＤＣＶ’ボックスも生成する。さらに、サムネイル画像のプロパティとして、主画像（オーバーレイ画像）とは別に、色空間情報を格納した’ｃｏｌｒ’ボックス、符号化時の情報を格納した’ｈｖｃＣ’ボックス、画像サイズを格納した’ｉｓｐｅ’ボックス、画像データのビット数の情報を格納した‘ｐｉｘｉ’ボックス、ＨＤＲの補足情報を格納した’ＣＬＬＩ’ボックスを生成する。これらのプロパティコンテナボックスを生成し、’ｉｐｃｏ’ボックス内に格納する。Ｓ１５１に進む。

Ｓ１５１で’ｉｐｍａ’ボックスを生成する。このボックスはアイテムとプロパティの関係性を示すボックスであり、アイテム毎に先に述べたどのプロパティと関連性があるのかを示す。ＣＰＵ１０１はメモリ１０２に保存された各種データからアイテムとプロパティの関係性を判断し、このボックスを生成する。Ｓ１５２に進む。

Ｓ１５２で’ｉｄａｔ’ボックスを生成する。このボックスには各分割画像の再生領域をどのように配置してオーバーレイ画像を生成するかを示すオーバーレイ情報を格納する。オーバーレイ情報には、背景色情報であるｃａｎｖａｓ＿ｆｉｌｌ＿ｖａｌｕｅパラメータや、オーバーレイ画像全体のサイズであるｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔパラメータがある。また、合成要素となる分割画像一つずつに対して、分割画像を合成する水平位置座標、垂直位置座標を示すｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔパラメータがある。これらのパラメータに対してＣＰＵ１０１は、Ｓ１０２で決定した分割方法に基づいてこれらの情報を記載する。具体的には、オーバーレイ画像のサイズを示すｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔパラメータに、再生領域全体のサイズを記載する。そして、各分割画像の位置情報を示すｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔパラメータには、再生領域左上の開始座標位置（ｘ０、ｙ０）から、分割画像の左上の位置までの幅方向および高さ方向のオフセット値をそれぞれ記載する。このようにしてオーバーレイ情報を生成することにより、画像の再生時に、分割画像をｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔパラメータに基づいて配置して分割画像を合成することにより、分割前の状態の画像を再生することができるようになる。本実施例では、分割画像に重複領域を設けていないため、各分割画像が重ならないように配置されるように位置情報が記載されることになる。そして、分割画像を合成して得られた画像のうち、ｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔパラメータにより表示される領域を指定することにより、再生領域のみを表示対象として再生することができる。このように生成されたオーバーレイ情報が格納された’ｉｄａｔ’ボックスを生成する。Ｓ１５３に進む。

Ｓ１５３で’ｉｌｏｃ’ボックスを生成する。このボックスは各種データがファイルのどの位置に配置されるかを示すボックスである。各種情報がメモリ１０２に保存されているため、これらのサイズからこのボックスを生成する。具体的に、オーバーレイを示す情報は先の’ｉｄａｔ’に格納するが、この’ｉｄａｔ’内部の位置とサイズ情報である。また、サムネイルデータ、符号データ１２は’ｍｄａｔ’ボックスに格納するが、この位置とサイズ情報を格納する。Ｓ１５４に進む。

Ｓ１５４で’ｍｄａｔ’ボックスを生成する。このボックスは以下に記載の複数のボックスを含むボックスである。ＣＰＵ１０１は’ｍｄａｔ’ボックスを生成しＳ１５５に進む。

Ｓ１５５でＥｘｉｆデータを’ｍｄａｔ’ボックスに格納する。先のＳ１０９で、メタデータのＥｘｉｆがメモリ１０２に保存されているので、ＣＰＵ１０１はこれをメモリ１０２から読み出し’ｍｄａｔ‘ボックスに追記する。Ｓ１５６に進む。

Ｓ１５６でサムネイルデータを’ｍｄａｔ’ボックスに格納する。先のＳ１１０で、サムネイルデータはメモリ１０２に保存されているので、ＣＰＵ１０１はこれをメモリ１０２から読み出し、‘ｍｄａｔ’ボックスに追記する。Ｓ１５７に進む。

Ｓ１５７で符号化画像１のデータを’ｍｄａｔ’ボックスに格納する。先のＳ１０６のループ１回目で、分割画像１のデータはメモリ１０２に保存されているので、ＣＰＵ１０１はこれをメモリ１０２から読み出し、‘ｍｄａｔ’ボックスに追記する。これを符号化画像Ｎまで繰り返して符号化画像１－Ｎをすべて’ｍｄａｔ’ボックスに追記する。このようなステップでＣＰＵ１０１はＨＥＩＦファイルを構築する。

以上の処理により、図２のようなＨＥＩＦフォーマットでＨＤＲ画像を記録媒体１２０に記録することができる。

＜ＨＤＲ画像の再生＞
次に、記録媒体１２０にＨＥＩＦフォーマットで記録されたＨＤＲ画像ファイルを再生する際の撮像装置１００での処理について説明する。なお、本実施形例では、撮像装置１００で再生する場合について説明するが、撮像部を有さない画像処理装置において、記録媒体１２０に記録されたＨＥＩＦフォーマットで記録されたＨＤＲ画像を再生する場合に、同様の処理を実現するようにしてもよい。

図７を用いて、主画像がオーバーレイ画像時のＨＥＩＦの再生（表示）処理について説明する。

ステップＳ７０１で、ＣＰＵ１０１は、記録媒体制御部１１９を使用して、記録媒体１２０に存在する指定ファイルの先頭部分をメモリ１０２に読み出す。そして、読み出したファイルの先頭部分に、正しい構造のファイルタイプボックスが存在するか、さらに、その中のブランドに、ＨＥＩＦを表す’ｍｉｆ１’が存在するかをチェックする。

また、独自のファイル構造に対応したブランドを記録してある場合、そのブランドの存在チェックを行う。そのブランドが特定の構造を保証する限りにおいて、このブランドのチェックにより、これ以降のいくつかの構造チェック、例えば、ステップＳ７０３、ステップＳ７０４、を省略することも可能である。

ステップＳ７０２で、ＣＰＵ１０１は、記録媒体１２０から指定ファイルのメタデータボックスをメモリ１０２に読み出す。

ステップＳ７０３で、ＣＰＵ１０１は、ステップＳ７０２で読み出したメタデータボックスからハンドラボックスを探し、構造をチェックする。ＨＥＩＦの場合、ハンドラタイプは’ｐｉｃｔ’でなければならない。

ステップＳ７０４で、ＣＰＵ１０１は、ステップＳ７０２で読み出したメタデータボックスからデータ情報ボックスを探し、構造をチェックする。本実施例では、同一ファイル内にデータが存在することを前提としているため、データエントリＵＲＬボックスに、そのむねを表すフラグが立っていることをチェックする。

ステップＳ７０５で、ＣＰＵ１０１は、ステップＳ７０２で読み出したメタデータボックスからプライマリアイテムボックスを探し、主画像のアイテムＩＤを取得する。

ステップＳ７０６で、ＣＰＵ１０１は、ステップＳ７０２で読み出したメタデータボックスからアイテム情報ボックスを探し、ステップＳ７０５で取得した主画像のアイテムＩＤに対応したアイテム情報エントリを取得する。上述のＨＤＲ画像の撮影処理により記録されたＨＥＩＦ形式の画像ファイルの場合、オーバーレイ情報が主画像として指定されていることになる。つまり、主画像のアイテムＩＤに対応したアイテム情報エントリには、そのアイテムタイプがオーバーレイを表す‘ｉｏｖｌ’となっている。

ステップＳ７０７で、ＣＰＵ１０１は、オーバーレイ画像作成処理を実行する。これについては、図８を用いて、後に説明する。

ステップＳ７０８で、ＣＰＵ１０１は、ステップＳ７０７で作成したオーバーレイ画像を、表示制御部１１５を経由して、表示部１１６に表示する。

なお、作成したオーバーレイ画像を表示する際には、画像の色空間情報を指定する必要があることがある。画像の色空間情報は、色空間プロパティ’ｃｏｌｒ’のｃｏｌｏｕｒ＿ｐｒｉｍａｒｉｅｓで色域が、ｔｒａｎｓｆｅｒ＿ｃｈａｒａｃｔｅｒｉｓｔｉｃｓで変換特性（ガンマ相当）が指定されているので、それらの値を用いる。ＨＤＲ画像の例として、色域がＲｅｃ．ＩＴＵ－Ｒ ＢＴ．２０２０、変換特性がＲｅｃ．ＩＴＵ－Ｒ ＢＴ．２１００（ＰＱ）、などが用いられる。

また、アイテムプロパティコンテナボックスに、’ＭＤＣＶ’、’ＣＬＬＩ’などのＨＤＲ用メタデータが存在する場合、それを使用することも可能である。

次に、図８を用いて、オーバーレイ画像作成処理について説明する。

ステップＳ８０１で、ＣＰＵ１０１は、オーバーレイ画像のプロパティ取得処理を実行する。これについては、図９を用いて、後に説明する。

ステップＳ８０２で、ＣＰＵ１０１は、オーバーレイ画像のオーバーレイ情報取得処理を実行する。オーバーレイ情報は、‘ｉｄａｔ‘ボックスに記録されているので、‘ｉｄａｔ‘ボックスに格納されているデータを取得することになる。

オーバーレイ情報には、オーバーレイ画像の画像サイズ（ｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔパラメータ）、オーバーレイ画像を構成する個々の画像アイテム（分割画像アイテム）の位置情報（ｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔ）、などが存在する。

オーバーレイ情報は、アイテムタイプがオーバーレイ’ｉｏｖｌ’である画像アイテムの、画像アイテムデータ扱いである。

この取得処理については、図１０を用いて、後に説明する。

ステップＳ８０３で、ＣＰＵ１０１は、分割画像アイテムのすべてのアイテムＩＤ取得処理を実行する。これについては、図１１を用いて、後に説明する。

ステップＳ８０４で、ＣＰＵ１０１は、ステップＳ８０２で取得したオーバーレイ情報のオーバーレイ画像サイズを用いて、そのサイズの画像データを格納するメモリを確保する。このメモリ領域をキャンバスと呼ぶこととする。

ステップＳ８０５で、ＣＰＵ１０１は、分割画像カウンタｎを０に初期化する。

ステップＳ８０６で、ＣＰＵ１０１は、分割画像カウンタｎが分割画像アイテム数と等しいかチェックする。等しい場合、ステップＳ２２１０に進む。等しくない場合、ステップＳ８０７に進む。

ステップＳ８０７で、ＣＰＵ１０１は、ｎ番目の分割画像アイテムに関して、１個の画像アイテムの画像作成処理を実行する。これについては、図１２を用いて、後に説明する。

ステップＳ８０８で、ＣＰＵ１０１は、ステップＳ８０７で作成した、ｎ番目の分割画像アイテムの画像（分割画像）を、ステップＳ８０２で取得したオーバーレイ情報に従い、ステップＳ８０４で確保したキャンバス上に配置する。

オーバーレイでは、オーバーレイを構成する分割画像は、キャンバス上の任意の位置に配置することが可能であり、その位置はオーバーレイ情報に記述されている。しかし、オーバーレイ画像の外側は表示対象外である。そのため、ここで、分割画像をキャンバスに配置する際に、分割画像の符号化領域のうち、オーバーレイ画像の領域と重複する領域、すなわち、分割画像の再生領域、のみを配置するようにする。

以下、図１３を用いて、説明する。

座標系は、オーバーレイ画像の左上を原点（０，０）とし、Ｘ座標は右方向に増加、Ｙ座標は下方向に増加するとする。

オーバーレイ画像の大きさを、幅Ｗｏ、高さＨｏとする（０＜Ｗｏ、０＜Ｈｏ）。

従って、オーバーレイ画像は、左上の座標が（０，０）で、右下の座標が（Ｗｏ－１、Ｈｏ－１）である。

また、分割画像の大きさを、幅Ｗｎ、高さＨｎとする（０＜Ｗｎ、０＜Ｈｎ）。

分割画像の左上の位置を、（Ｘｎ、Ｙｎ）とする。

従って、分割画像は、左上座標が（Ｘｎ、Ｙｎ）、右下座標が（Ｘｎ＋Ｗｎ－１、Ｙｎ＋Ｈｎ－１）である。

分割画像における、オーバーレイ画像（キャンバス）との重複領域は、以下の方法で求めることができる。

以下の場合は、重複領域が存在しない場合である。
Ｗｏ－１＜Ｘｎ（分割画像の左端が、オーバーレイ画像の右端より右）
Ｘｎ＋Ｗｎ－１＜０（分割画像の右端が、オーバーレイ画像の左端より左）
Ｈｏ－１＜Ｙｎ（分割画像の上端が、オーバーレイ画像の下端より下）
Ｙｎ＋Ｈｎ－１＜０（分割画像の下端が、オーバーレイ画像の上端より上）
この場合、この画像は、処理対象外となる。

また、以下の場合、分割画像全体が、重複領域となる。
０＜＝Ｘｎかつ（Ｘｎ＋Ｗｎ－１）＜＝（Ｗｏ－１）かつ０＜＝Ｙｎかつ（Ｙｎ＋Ｈｎ－１）＜＝（Ｈｏ－１）
この場合、分割画像全体を、キャンバス上の指定位置（Ｘｎ、Ｙｎ）に配置する。

上記以外の場合、分割画像の一部が配置対象となる。
重複領域の左上座標を（Ｘｌ、Ｙｔ）、右下座標を（Ｘｒ、Ｙｂ）とする。
左端Ｘｌは、以下の通り。
ｉｆ（０＜＝Ｘｎ）
Ｘｌ＝Ｘｎ；
ｅｌｓｅ
Ｘｌ＝０；
右端Ｘｒは、以下の通り。
ｉｆ（Ｘｎ＋Ｗｎ－１＜＝Ｗｏ－１）
Ｘｒ＝Ｘｎ＋Ｗｎ－１；
ｅｌｓｅ
Ｘｒ＝Ｗｏ－１；
上端Ｙｔは、以下の通り。
ｉｆ（０＜＝Ｙｎ）
Ｙｔ＝Ｙｎ；
ｅｌｓｅ
Ｙｔ＝０；
下端Ｙｂは、以下の通り。
ｉｆ（Ｙｎ＋Ｈｎ－１＜＝Ｈｏ－１）
Ｙｂ＝Ｙｎ＋Ｈｎ－１；
ｅｌｓｅ
Ｙｂ＝Ｈｏ－１；
この重複領域の大きさは、幅Ｘｒ－Ｘｌ＋１、高さＹｂ－Ｙｔ＋１、である。

この重複領域の左上座標（Ｘｌ、Ｙｔ）、右下座標（Ｘｒ、Ｙｂ）は、前述のように、キャンバスの左上を原点（０，０）とした座標系である。

重複領域の左上座標（Ｘｌ、Ｙｔ）を、分割画像の左上を原点とする座標系で表すと、以下のようになる。
Ｘｌ’＝Ｘｌ－Ｘｎ；
Ｙｔ’＝Ｙｔ－Ｙｎ；

まとめると、以下のようになる。
分割画像の左上から（Ｘｌ’、Ｙｔ’）離れた位置から幅（Ｘｒ－Ｘｌ＋１）、高さ（Ｙｂ－Ｙｔ＋１）の矩形を切り出し、キャンバスの（Ｘｌ、Ｙｔ）の位置に配置する。

これにより、分割画像のうちの再生領域を、キャンバス上の適切な位置に配置することが可能である。

ステップＳ８０９で、ＣＰＵ１０１は、分割画像カウンタｎに１加算し、ステップＳ８０６に戻る。

ステップＳ８１０で、ＣＰＵ１０１は、ステップＳ８０１で取得したオーバーレイ画像のプロパティ中に回転プロパティ’ｉｒｏｔ’が存在するか調べ、存在する場合、回転角を調べる。回転プロパティが存在しない場合、または、回転プロパティが存在するが回転角が０の場合、処理を終了する。回転プロパティが存在し、回転角が０以外の場合、ステップＳ８１１に進む。

ステップＳ８１１で、ＣＰＵ１０１は、ステップＳ８０６～ステップＳ８０９で作成したキャンバスの画像を、ステップＳ８１０で取得した角度だけ回転し、それを作成画像とする。

これにより、オーバーレイ画像を作成することが可能である。

なお、上記説明では、ステップＳ８０６～ステップＳ８０９の処理を分割画像数分ループで繰り返しているが、並行処理可能な環境では、ステップＳ８０６～ステップＳ８０９の処理を、分割画像数分並行処理しても良い。

次に、図９を用いて、画像アイテムのプロパティ取得処理について説明する。

ステップＳ９０１で、ＣＰＵ１０１は、メタデータボックス内のアイテムプロパティボックス内のアイテムプロパティ関連ボックスから、指定画像アイテムＩＤのエントリを探し、そこに格納されている、プロパティインデックスの配列を取得する。

ステップＳ９０２で、ＣＰＵ１０１は、配列カウンタｎを０に初期化する。

ステップＳ９０３で、ＣＰＵ１０１は、配列カウンタｎが配列要素数と等しいかチェックする。等しい場合、終了する。等しくない場合、ステップＳ９０４に進む。

ステップＳ９０４で、ＣＰＵ１０１は、メタデータボックス内のアイテムプロパティボックス内のアイテムプロパティコンテナボックスから、配列のｎ番目の要素のインデックスのプロパティを取得する。

ステップＳ９０５で、ＣＰＵ１０１は、配列カウンタｎに１加算し、ステップＳ９０３に戻る。

次に、図１０を用いて、画像アイテムのデータ取得処理について説明する。

ステップＳ１００１で、ＣＰＵ１０１は、メタデータボックス内のアイテムロケーションボックスから、指定画像アイテムＩＤのエントリを探し、オフセット基準（ｃｏｎｓｔｒｕｃｔｉｏｎ＿ｍｅｔｈｏｄ）、オフセット、長さ、を取得する。

ステップＳ１００２で、ＣＰＵ１０１は、ステップＳ１００１で取得したオフセット基準をチェックする。オフセット基準は、値０がファイルの先頭からのオフセット、値１がアイテムデータボックス内のオフセット、を表す。オフセット基準が０の場合、ステップＳ１００３に進む。オフセット基準が１の場合、ステップＳ１００４に進む。

ステップＳ１００３で、ＣＰＵ１０１は、ファイルの先頭からオフセットバイトの位置から長さバイト分を、メモリ１０２に読み出す。

ステップＳ１００４で、ＣＰＵ１０１は、メタデータボックス内のアイテムデータボックスのデータ部の先頭からオフセットバイトの位置から長さバイト分を、メモリ１０２に読み出す。

次に、図１１を用いて、主画像を構成する画像のアイテムＩＤ取得処理について説明する。

ステップＳ１１０１で、ＣＰＵ１０１は、メタデータボックス内のアイテム参照ボックスから、参照タイプが‘ｄｉｎｇ’で、参照元アイテムＩＤが主画像のアイテムＩＤであるエントリを探す。

ステップＳ１１０２で、ＣＰＵ１０１は、ステップＳ１１０１で取得したエントリの、参照先アイテムＩＤの配列を取得する。

次に、図１２を用いて、１個の符号化画像アイテムの画像作成処理について説明する。

ステップＳ１２０１で、ＣＰＵ１０１は、その画像アイテムのプロパティを取得する。これは、図９を用いて、説明済みである。

ステップＳ１２０２で、ＣＰＵ１０１は、その画像アイテムのデータを取得する。これは、図１０を用いて、説明済みである。画像アイテムのデータとは、符号化された画像データである。

ステップＳ１２０３で、ＣＰＵ１０１は、ステップＳ１２０１で取得したプロパティのうちのデコーダ構成・初期化データを用いて、デコーダを初期化する。

ステップＳ１２０４で、ＣＰＵ１０１は、ステップＳ１２０２で取得した符号化された画像データをデコーダでデコードし、デコード結果を取得する。

ステップＳ１２０５で、ＣＰＵ１０１は、ピクセル形式変換が必要かどうかチェックする。

不要な場合、終了する。必要な場合、ステップＳ１２０６に進む。

デコーダの出力データのピクセル形式と、表示装置がサポートしている画像のピクセル形式が異なる場合、ピクセル形式変換が必要である。

例えば、デコーダの出力データのピクセル形式がＹＣｂＣｒ（輝度色差）形式であり、表示装置の画像のピクセル形式がＲＧＢ形式の場合、ＹＣｂＣｒ形式からＲＧＢ形式へのピクセル形式変換が必要である。また、同じＹＣｂＣｒ形式でも、ビット深度（８ビット、１０ビット、など）や色差サンプル（４：２：０、４：２：２、など）が異なる場合も、ピクセル形式変換が必要である。

なお、色空間情報プロパティ’ｃｏｌｒ’のｍａｔｒｉｘ＿ｃｏｅｆｆｉｃｉｅｎｔｓで、ＲＧＢ形式からＹＣｂＣｒ形式へ変換する際の係数が指定されているので、ＹＣｂＣｒ形式からＲＧＢ形式へ変換するためには、その係数の逆数を用いればよい。

ステップＳ１２０６で、ＣＰＵ１０１は、ステップＳ１２０４で取得したデコーダ出力データを、所望のピクセル形式に変換する。

これにより、指定された符号化画像アイテムの画像を作成することが可能である。

以上の処理により、記録媒体１２０に図２のようなＨＥＩＦフォーマットで記録されたＨＤＲ画像を再生することができる。

＜その他の実施形態＞
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。

また、上記の実施の形態の機能を制御方法として、この制御方法を画像処理装置に実行させるようにすればよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、当該制御プログラムを画像処理装置が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記憶媒体に記録される。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給する。そして、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

上述の課題を解決するため、本発明の撮像装置は、
撮影して得られたＨＤＲ（ハイダイナミックレンジ）画像データを記録する撮像装置であって、撮像センサと、前記撮像センサにより撮影して得られたＨＤＲ画像データを符号化する符号化手段と、前記撮像センサより撮影して得られたＨＤＲ画像データを所定の記録フォーマットで１つの画像ファイルとして記録媒体に記録するように制御する記録制御手段と、記録モードを設定する設定手段と、を有し、前記記録制御手段は、前記設定手段により設定された記録モードに対応する画像サイズに応じて、前記撮影して得られたＨＤＲ画像データを複数の分割ＨＤＲ画像データに分割して前記符号化手段によりそれぞれ符号化し、当該符号化された複数の分割ＨＤＲ画像データと当該複数の分割ＨＤＲ画像データを分割前の状態に結合するための画像構造体情報とを前記画像ファイル内に記録するか、前記撮影して得られたＨＤＲ画像データを分割せずに前記符号化手段により符号化し、当該符号化されたＨＤＲ画像データを前記画像ファイル内に記録するか、を切り替える、ことを特徴とする。

Claims (1)

1. 撮影して得られたＨＤＲ（ハイダイナミックレンジ）画像データを記録する撮像装置であって、
   撮像センサと、
   前記撮像センサにより撮影して得られたＨＤＲ画像データを符号化する符号化手段と、
   前記撮像センサより撮影して得られたＨＤＲ画像データのうち、符号化対象となる符号化領域のＨＤＲ画像データを複数の分割ＨＤＲ画像データに分割し、前記複数の分割ＨＤＲ画像データを前記符号化手段によりそれぞれ符号化し、前記符号化された複数の分割ＨＤＲ画像データを所定の記録フォーマットで記録媒体に記録するように制御する記録制御手段と、を有することを特徴とする撮像装置。

Images