特許 7626125 ファイル処理装置、ファイル処理方法、及び、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-01-27

(45)【発行日】2025-02-04

(54)【発明の名称】ファイル処理装置、ファイル処理方法、及び、プログラム

(51)【国際特許分類】

   H04N 5/92 20060101AFI20250128BHJP

   H04N 5/76 20060101ALI20250128BHJP

   H04N 23/60 20230101ALI20250128BHJP

【ＦＩ】

H04N5/92 010

H04N5/76

H04N23/60 300

【請求項の数】 20

(21)【出願番号】P 2022505894

(86)(22)【出願日】2021-02-22

(86)【国際出願番号】 JP2021006575

(87)【国際公開番号】W WO2021182090

(87)【国際公開日】2021-09-16

【審査請求日】2024-01-10

(31)【優先権主張番号】P 2020039881

(32)【優先日】2020-03-09

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】100121131

【弁理士】

【氏名又は名称】西川 孝

(74)【代理人】

【氏名又は名称】稲本 義雄

(74)【代理人】

【識別番号】100168686

【弁理士】

【氏名又は名称】三浦 勇介

(72)【発明者】

【氏名】椎名 裕樹

【審査官】鈴木 順三

(56)【参考文献】

【文献】国際公開第２０１９／１９３０９７（ＷＯ，Ａ１）

【文献】国際公開第２０１９／１９２８７０（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１９／５２９３７（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ５／７６ － ５／９５６

Ｈ０４Ｎ ２３／４０ － ２３／７６

(57)【特許請求の範囲】

【請求項1】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備える
ファイル処理装置。

【請求項2】

前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータである
請求項１に記載のファイル処理装置。

【請求項3】

前記ファイル制御部は、前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置する
請求項２に記載のファイル処理装置。

【請求項4】

前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含む
請求項３に記載のファイル処理装置。

【請求項5】

前記修復用データは、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復するデータを含む
請求項２に記載のファイル処理装置。

【請求項6】

前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
前記ファイル制御部は、前記画像の修復用データと、前記関連画像の修復用データとを書き込む
請求項１に記載のファイル処理装置。

【請求項7】

前記関連画像は、前記画像より画素数が少ない画像である
請求項６に記載のファイル処理装置。

【請求項8】

前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納される
請求項１に記載のファイル処理装置。

【請求項9】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含む
ファイル処理方法。

【請求項10】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部
として、コンピュータを機能させるためのプログラム。

【請求項11】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備える
ファイル処理装置。

【請求項12】

前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータであり、
前記ファイル制御部は、前記修復用データを用いて、前記管理用メタデータを生成する
請求項１１に記載のファイル処理装置。

【請求項13】

前記ファイル制御部は、前記HEIFファイルから、書き込みが中断された中断箇所の前記画像を削除し、前記修復用データを用いて、前記中断箇所よりも先に書き込まれた前記画像が格納された前記HEIFファイルを生成する
請求項１２に記載のファイル処理装置。

【請求項14】

前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置し、
前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含み、
前記ファイル制御部は、前記修復用データの先頭から、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを合わせたサイズのシークに失敗した場合、前記画像を前記中断箇所として検出する
請求項１３に記載のファイル処理装置。

【請求項15】

前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
前記ファイル制御部は、前記画像及び前記関連画像のいずれかが前記中断箇所として検出された場合、前記画像及び前記関連画像を削除する
請求項１３に記載のファイル処理装置。

【請求項16】

前記関連画像は、前記画像より画素数が少ない画像である
請求項１５に記載のファイル処理装置。

【請求項17】

前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納され、
前記ファイル制御部は、前記画像及び前記メタデータのいずれかが前記中断箇所として検出された場合、前記画像及び前記メタデータを削除する
請求項１３に記載のファイル処理装置。

【請求項18】

前記ファイル制御部は、前記修復用データを用いて、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復する
請求項１２に記載のファイル処理装置。

【請求項19】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含む
ファイル処理方法。

【請求項20】

静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部
として、コンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本技術は、ファイル処理装置、ファイル処理方法、及び、プログラムに関し、特に、例えば、ユーザが失う画像を少なくすることができるようにするファイル処理装置、ファイル処理方法、及び、プログラムに関する。

【背景技術】

【0002】

画像を、効率的に格納するファイルフォーマットとして、HEIF(High Efficiency Image File Format)がある（非特許文献１を参照）。

【先行技術文献】

【非特許文献】

【0003】

【文献】ISO/IEC 23008-12:2017, Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 12: Image File Format

【発明の概要】

【発明が解決しようとする課題】

【0004】

HEIFファイルには、例えば、連写で撮像された画像等の、複数枚の静止画の画像を格納することができる。HEIFファイルに、複数枚の画像を格納する場合、画像の枚数が多いほど、HEIFファイルの書き込み（記録）に要する書き込み時間が長くなる。書き込み時間が長い場合、HEIFファイルの書き込み中に、バッテリが抜かれることや、コンセントが抜かれることによる電源断や、メディアが抜かれること等によって、正常でないHEIFファイルが生成される可能性が高くなることが予想される。正常でないHEIFファイルとは、HEIFファイルとしてのフォーマットを有していないファイルである。

【0005】

正常でないHEIFファイルについては、再生をすることができず、ユーザは、HEIFファイルに格納されるはずの画像すべてを失うことになる。

【0006】

本技術は、このような状況に鑑みてなされたものであり、ユーザが失う画像を少なくすることができるようにするものである。

【課題を解決するための手段】

【0007】

本技術の第１のファイル処理装置、又は、プログラムは、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備えるファイル処理装置、又は、そのようなファイル処理装置として、コンピュータを機能させるためのプログラムである。

【0008】

本技術の第１のファイル処理方法は、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含むファイル処理方法である。

【0009】

本技術の第１のファイル処理装置、ファイル処理方法、及び、プログラムにおいては、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データが書き込まれる。

【0010】

本技術の第２のファイル処理装置、又は、プログラムは、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備えるファイル処理装置、又は、そのようなファイル処理装置として、コンピュータを機能させるためのプログラムである。

【0011】

本技術の第２のファイル処理方法は、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含むファイル処理方法である。

【0012】

本技術の第２のファイル処理装置、ファイル処理方法、及び、プログラムにおいては、静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルが、前記修復用データを用いて修復される。

【0013】

なお、ファイル処理装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。

【0014】

また、プログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して提供することができる。

【図面の簡単な説明】

【0015】

【図1】本技術を適用したディジタルカメラの一実施の形態の構成例を示すブロック図である。

【図2】JPEG(Joint Photographic Experts Group)に準拠したJPEGファイルのフォーマットの例を示す図である。

【図3】ISOベースメディアファイルフォーマットの例を示す図である。

【図4】HEIFに準拠したHEIFファイルのフォーマットの例を示す図である。

【図5】イメージアイテム形式のHEIFファイルのフォーマットの例を示す図である。

【図6】iprpボックスの例を示す図である。

【図7】イメージシーケンス形式のHEIFファイルのフォーマットの例を示す図である。

【図8】trakボックスの例を示す図である。

【図9】主画像及びサムネイル画像が格納されたコレクションファイルの例を示す図である。

【図10】主画像のトラック及びその主画像のサムネイル画像のトラックが格納されたシーケンスファイルの例を示す図である。

【図11】タイル画像が格納されたHEIFファイルの例を示す図である。

【図12】ファイル制御部４３により生成される修復機能付きHEIFファイルの概要を説明する図である。

【図13】修復用データを用いた正常でない（修復機能付き）HEIFファイルの修復の概要を説明する図である。

【図14】修復機能付きHEIFファイルの生成の処理の例を説明するフローチャートである。

【図15】正常でない修復機能付きHEIFファイルの例を示す図である。

【図16】中断箇所の検出後の修復処理の例を説明する図である。

【図17】中断箇所の画像、及び、その画像の修復用データの削除後の修復処理の例を説明する図である。

【図18】正常なmetaボックスの生成後の修復処理の例を説明する図である。

【図19】修復処理の例を説明するフローチャートである。

【図20】修復用データの具体例を示す図である。

【図21】修復用データのうちのグリッド情報（フィールド）grid_listの具体例を示す図である。

【図22】修復処理において、少なくとも修復用データを用いて生成（修復）されるメタデータが格納されるボックスを示す図である。

【図23】修復処理において、少なくとも修復用データを用いて生成される管理用メタデータが格納されるボックスの生成（修復）方法を説明する図である。

【図24】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。

【発明を実施するための形態】

【0016】

＜本技術を適用したディジタルカメラの一実施の形態＞

【0017】

図１は、本技術を適用したディジタルカメラの一実施の形態の構成例を示すブロック図である。

【0018】

ディジタルカメラ１０は、光学系１１、イメージセンサ１２、信号処理部１３、メディア１４、I/F(Interface)１５及び１６、ボタン／キー１７、タッチパネル１８、液晶パネル１９、ビューファインダ２０、並びに、I/F２１等を有する。

【0019】

光学系１１は、被写体からの光を、イメージセンサ１２に集光する。

【0020】

イメージセンサ１２は、光学系１１からの光を受光し、光電変換する撮像を行うことで、電気信号としての画像のデータを生成し、信号処理部１３に供給する。

【0021】

信号処理部１３は、光学系／イメージセンサ制御部４１、符号化制御部４２、ファイル制御部４３、メディア制御部４４、操作制御部４５、表示制御部４６、及び、UI制御部４７を有する。

【0022】

光学系／イメージセンサ制御部４１は、光学系１１及びイメージセンサ１２を制御し、その制御に従って行われる撮像により得られる画像（のデータ）を、符号化制御部４２に供給する。

【0023】

符号化制御部４２は、光学系／イメージセンサ制御部４１からの画像を表示制御部４６に供給するとともに、必要に応じて符号化し、ファイル制御部４３に供給する。また、符号化制御部４２は、ファイル制御部４３から供給される画像を必要に応じて復号し、表示制御部４６に供給する。

【0024】

ファイル制御部４３は、符号化制御部４２から供給される画像を格納したファイルを生成し、メディア制御部４４に供給する。また、ファイル制御部４３は、メディア制御部４４から供給されるファイルの再生、すなわち、ファイルに格納された画像等のデータの読み出し等を行う。例えば、ファイルから読み出された画像は、ファイル制御部４３から符号化制御部４２に供給される。

【0025】

メディア制御部４４は、メディア１４、並びに、I/F１５及び１６との間でのファイルのやりとりを制御する。例えば、メディア制御部４４は、ファイル制御部４３からのファイルを、メディア１４に記録させ、又は、I/F１５及び１６から送信させる。また、メディア制御部４４は、メディア１４からファイルを読み出し、又は、I/F１５及び１６にファイルを受信させ、ファイル制御部４３に供給する。

【0026】

操作制御部４５は、ユーザによるボタン／キー１７やタッチパネル１８の操作に応じて、その操作に対応する操作信号を、必要なブロックに供給する。

【0027】

表示制御部４６は、符号化制御部４２から供給される画像等を、液晶パネル１９や、ビューファインダ２０、I/F２１に供給して表示させる表示制御等を行う。

【0028】

UI制御部４７は、UI(User Interface)制御をつかさどる。

【0029】

メディア１４は、例えば、SDカード等の記憶媒体である。I/F１５は、例えば、WiFi（登録商標）やイーサネット（登録商標）等のLAN(Local Area Network)のI/Fである。I/F１６は、例えば、USB(Universal Serial Bus)のI/Fである。ボタン／キー１７及びタッチパネル１８は、ディジタルカメラ１０に指令その他の情報を入力するときに、ユーザによって操作される。タッチパネル１８は、液晶パネル１９と一体的に構成することができる。液晶パネル１９及びビューファインダ２０は、表示制御部４６から供給される画像等を表示する。I/F２１は、HDMI(High-Definition Multimedia Interface)（登録商標）やDP(Display Port)等の少なくとも画像を伝送するI/Fである。

【0030】

以上のように構成されるディジタルカメラ１０では、光学系／イメージセンサ制御部４１は、イメージセンサ１２の撮像により得られるRAWデータの画像（以下、RAW画像ともいう）から、例えば、そのRAW画像と同一の解像度（画素数）（サイズ）のYUVの画像を生成し、RAW画像とともに、符号化制御部４２に供給する。符号化制御部４２は、光学系／イメージセンサ制御部４１からのYUVの画像から、HEIFファイルの主画像(master image)等を生成する。例えば、光学系／イメージセンサ制御部４１からのYUVの画像を、そのままHEIFファイルの主画像とすることができる。

【0031】

符号化制御部４２は、YUVの主画像から、液晶パネル１９や外部のディスプレイでの表示の用途用に、主画像に基づく第１の他の画像としての、例えば、主画像よりも解像度が低いYUVの画像（以下、スクリーンネイル画像ともいう）を生成するとともに、インデクス表示（一覧表示）の用途用に、主画像に基づく第２の他の画像としての、例えば、スクリーンネイル画像よりも解像度が低いYUVの画像（以下、サムネイル画像ともいう）を生成する。符号化制御部４２は、例えば、スクリーンネイル画像を、表示制御部４６を介して、液晶パネル１９に供給し、いわゆるスルー画として表示させる。サムネイル画像としては、例えば、長辺が320ピクセル以下のサイズの画像を採用することができる。主画像と、主画像に基づく第１の他の画像としてのスクリーンネイル画像、又は、主画像に基づく第２の他の画像としてのサムネイル画像とのサイズ（ピクセル数）の比率は、例えば、200倍以下にすることができる。主画像に基づく第１の他の画像としてのスクリーンネイル画像と、主画像に基づく第２の他の画像としてのサムネイル画像とのサイズの比率も、同様に、200倍以下とすることができる。スクリーンネイル画像としては、例えば、解像度が4K以上の画像を採用することができる。また、スクリーンネイル画像としては、例えば、ユーザの選択に応じて、4K（QFHD）又はFHDの画像を採用することができる。さらに、主画像とスクリーンネイル画像としては、同一の解像度の画像を採用することができる。主画像とスクリーンネイル画像として、同一の解像度の画像を採用する場合、HEIFファイルには、主画像とスクリーンネイル画像との両方を格納することもできるし、スクリーンネイル画像を格納せずに、主画像を格納することができる。HEIFファイルに、スクリーンネイル画像を格納せずに、主画像を格納する場合には、主画像をリサイズして、スクリーンネイル画像として用いることができる。

【0032】

また、符号化制御部４２は、RAW画像に対応する主画像、スクリーンネイル画像、及び、サムネイル画像（同一のRAW画像から生成された主画像、スクリーンネイル画像、及び、サムネイル画像）を、必要に応じて符号化し、RAW画像とともに、ファイル制御部４３に供給する。

【0033】

ファイル制御部４３は、必要に応じて、RAW画像が格納されたRAWファイルや、対応する主画像、スクリーンネイル画像、及び、サムネイル画像（同一のRAW画像から生成された主画像、スクリーンネイル画像、及び、サムネイル画像）が格納されたHEIFファイル、及び／又は、JPEGファイル等を生成し、メディア制御部４４に供給する。HEIFファイルとは、HEIF(High Efficiency Image File Format)に準拠したファイルであり、JPEGファイルとは、JPEG(Joint Photographic Experts Group)に準拠したファイルである。

【0034】

メディア制御部４４は、ファイル制御部４３からのRAWファイルや、HEIFファイル、JPEGファイルを、メディア１４に記録し、あるいは、I/F１５又は１６から送信させる。

【0035】

ファイル制御部４３において生成するファイルの種類（例えば、RAWファイルや、HEIFファイル、JPEGファイル等）は、例えば、ユーザの操作（指定）に応じて選択することができる。また、HEIFファイルには、後述するように、イメージアイテム形式とイメージシーケンス形式とがあるが、イメージアイテム形式とイメージシーケンス形式とのいずれを採用するかは、例えば、ユーザの操作に応じて選択することができる。さらに、ファイル制御部４３では、ユーザの操作に応じて、HEIFファイルとJPEGファイルとの間の相互変換を行うことができる。

【0036】

また、ファイル制御部４３では、コーデックや、画像のサイズ（解像度）、カラーフォーマット、ビット深度が異なる、同一の画像内容の複数のファイルを生成することができる。

【0037】

ファイル制御部４３において、同一の画像内容の複数のファイルを生成する場合、符号化制御部４２では、光学系／イメージセンサ制御部４１からのYUVの画像から、複数のファイルそれぞれに格納される画像のストリーム（ファイルストリーム）が生成される。

【0038】

符号化制御部４２では、コーデックや、画像のサイズ（解像度）、カラーフォーマット、ビット深度が異なる画像のストリームを生成することができる。

【0039】

例えば、符号化制御部４２では、光学系／イメージセンサ制御部４１から供給されるYUVの画像から、所定のサイズ、所定のカラーフォーマット、及び、所定のビット深度の画像を生成し、その画像を、所定のコーデック（符号化方式）で符号化した第１のストリームを生成することができる。さらに、符号化制御部４２では、光学系／イメージセンサ制御部４１から供給される同一のYUVの画像から、他のサイズ、他のカラーフォーマット、及び、他のビット深度の画像を生成し、その画像を、他のコーデックで符号化した第２のストリームを生成することができる。

【0040】

そして、ファイル制御部４３では、第１のストリームを格納したファイルと、第２のストリームを格納したファイルとを生成することができる。

【0041】

＜JPEGファイル＞

【0042】

図２は、JPEG(Joint Photographic Experts Group)に準拠したJPEGファイルのフォーマットの例を示す図である。

【0043】

JPEGファイルは、例えば、Exif(EXIF)のメタデータ、サムネイル画像、XMP(Extensible Metadata Platform)（登録商標）のメタデータ、主画像及び簡易表示用画像の格納場所（位置）等を表すMPF、主画像、並びに、簡易表示用画像が格納されて構成される。簡易表示用画像としては、例えば、スクリーンネイル画像を採用することができる。

【0044】

＜ISOベースメディアファイルフォーマット＞

【0045】

図３は、ISOベースメディアファイルフォーマットの例を示す図である。

【0046】

HEIF(ISO/IEC 23008-12)は、ISOベースメディアファイルフォーマット(ISO/IEC 14496-12)に準拠したファイルフォーマットであり、したがって、HEIFファイルは、ISOベースメディアファイルフォーマットに準拠する。

【0047】

ISOベースメディアファイルフォーマットは、データを格納するコンテナとしてのボックス(box)と呼ばれる単位で構成され、ボックス構造と呼ばれる構造を有する。

【0048】

ボックスは、タイプ(box type)、及び、実データ(data)等を有する。タイプは、ボックス内の実データの種類を表す。実データとしては、画像（静止画、動画）や、オーディオ、字幕（サブタイトル）等の再生可能なメディアデータ、属性名（フィールド名）とその属性名（で表される変数）の属性値（フィールド値）、その他の各種のデータを採用することができる。

【0049】

さらに、実データとしては、ボックスを採用することができる。すなわち、ボックスは、実データとして、ボックスを持つことができ、これにより、階層構造にすることができる。

【0050】

ISOベースメディアファイルフォーマットに準拠したベースメディアファイルは、ftypボックス、moovボックス(MovieBox)、metaボックス(MetaBox)、及び、mdatボックス(MediaDataBox)等を有することができる。ftypボックスには、ファイルフォーマットを識別する識別情報が格納される。moovボックスは、trakボックス等を格納することができる。metaボックスは、iinfボックス、iprpボックス、irefボックス、ilocボックス等を格納することができる。mdatボックスは、メディアデータ（AVデータ）、その他任意のデータを格納することができる。

【0051】

HEIFは、以上のようなISOベースメディアファイルフォーマットに準拠する。

【0052】

＜HEIFファイル＞

【0053】

図４は、HEIFに準拠したHEIFファイルのフォーマットの例を示す図である。

【0054】

HEIFファイルには、大きく分けて、イメージアイテム形式と、イメージシーケンス形式とがある。さらに、イメージアイテム形式には、後述するアイテムを１つだけ有するシングルイメージ形式と、アイテムを複数有するイメージコレクション形式とがある。

【0055】

イメージアイテム形式のHEIFファイルは、ftypボックス、metaボックス、及び、mdatボックスを有する。

【0056】

イメージシーケンス形式のHEIFファイルは、ftypボックス、moovボックス、及び、mdatボックスを有する。

【0057】

なお、HEIFファイルは、metaボックス及びmoovボックスのうちの一方だけでなく、両方を有することもできる。

【0058】

ftypボックスには、ファイルフォーマットを識別する識別情報、例えば、ファイルがイメージアイテム形式又はイメージシーケンス形式のHEIFファイルであること等が格納される。

【0059】

metaボックス及びmoovボックスには、mdatボックスに格納されるメディアデータの再生や管理等に必要な、例えば、メディアデータの格納場所等のメタデータが格納される。

【0060】

mdatボックスには、メディアデータ（AVデータ）等が格納される。

【0061】

ディジタルカメラ１０において、イメージアイテム形式とイメージシーケンス形式とのHEIFファイルのうちのいずれのHEIFファイルを生成するかは、例えば、ユーザの操作に応じて選択することができる。また、HEIFファイルのmdatボックスに、画像を符号化して格納する場合には、イメージアイテム形式については、イントラ符号化のみが許され、イメージシーケンス形式については、イントラ符号化及びインター符号化が許される。したがって、例えば、HEIFファイルに格納されたデータへの高速アクセスを優先する場合には、イメージアイテム形式のHEIFファイルの生成を選択し、HEIFファイルのサイズ（データ量）を小さくすることを優先する場合には、イメージシーケンス形式のHEIFファイルの生成を選択することができる。

【0062】

図５は、イメージアイテム形式のHEIFファイルのフォーマットの例を示す図である。

【0063】

イメージアイテム形式のHEIFファイルでは、ftypボックスに、イメージアイテム形式のHEIFファイルであることを表す情報、例えば、mif1等が（属性値として）格納される。

【0064】

metaボックスには、iinfボックス、irefボックス、iprpボックス、及び、ilocボックスが格納される。

【0065】

iinfボックスには、mdatボックスに格納されたメディアデータ（AVデータ）であるアイテムの数（を表す属性名と属性値）等が格納される。アイテムとは、イメージアイテム形式のHEIFファイルのmdatボックスに格納される１つのデータであり、例えば、１枚（画面）の画像が、アイテムである。本明細書では、静止画及び動画にかかわらず、画像の１枚を、フレームともいう。１フレームは、１アイテムである。

【0066】

irefボックスには、アイテムどうしの関連を表す情報が格納される。例えば、mdatボックスには、対応する主画像、スクリーンネイル画像、及び、サムネイル画像のそれぞれをアイテムとして格納することができる。mdatボックスに、主画像としてのアイテムI1、スクリーンネイル画像としてのアイテムI2、及び、サムネイル画像としてのアイテムI3が格納される場合、irefボックスには、アイテムI2がアイテムI1としての主画像のスクリーンネイル画像であることを表す情報や、アイテムI3がアイテムI1としての主画像のサムネイル画像であることを表す情報が格納される。

【0067】

iprpボックスには、アイテムのプロパティに関する情報が格納される。

【0068】

ilocボックスには、mdatボックスに格納されたアイテムの格納場所に関する情報が格納される。

【0069】

イメージアイテム形式の（HEIFファイルの）mdatボックスには、アイテムとしての、例えば、画像のフレームが格納される。mdatボックスには、１個以上のアイテムを格納することができる。また、mdatボックスには、アイテムとしてのフレームを符号化して格納することができる。但し、イメージアイテム形式のmdatボックスに格納するアイテムとしてのフレームの符号化は、イントラ符号化に制限される。アイテムとしてのフレームを符号化する符号化方式（コーデック）としては、例えば、HEVC等を採用することができる。

【0070】

図６は、図５のiprpボックスの例を示す図である。

【0071】

iprpボックスには、アイテムのプロパティに関するipcoボックス及びipmaボックスが格納される。ipcoボックスには、mdatボックスに格納されたアイテムのプロパティ、例えば、アイテムとしての画像のコーデックに関するコーデック情報やサイズに関する画サイズ情報が格納される。ipmaボックスには、mdatボックスに格納されたアイテムの、ipcoボックスに格納されたプロパティへのインデクス（ポインタ）が格納される。

【0072】

図７は、イメージシーケンス形式のHEIFファイルのフォーマットの例を示す図である。

【0073】

イメージシーケンス形式のHEIFファイルでは、ftypボックスに、イメージシーケンス形式のHEIFファイルであることを表す情報、例えば、msf1等が格納される。

【0074】

moovボックスには、trakボックスが格納される。trakボックスには、mdatボックスに格納されるトラックに関する情報が格納される。

【0075】

トラックは、画像や音声等の１つの独立した、タイムラインに従って再生されるメディアデータで構成される。例えば、トラックは、エレメンタリストリームとなる１フレーム以上の画像で構成される。mdatボックスに格納されるトラックについては、複数のトラック、例えば、同時に記録された画像及び音声それぞれのトラックを、同時に再生することができる。

【0076】

トラックのメディアデータは、サンプルと呼ばれる単位で構成される。サンプルとは、HEIFファイル内のメディアデータにアクセスする場合の、最小の単位（アクセス単位）である。したがって、サンプルより細かい単位で、HEIFファイル内のメディアデータにアクセスすることはできない。

【0077】

画像のメディアデータについては、例えば、１フレーム等が、１サンプルとなる。また、音声のメディアデータについては、例えば、その音声のメディアデータの規格で定められた１オーディオフレーム等が、１サンプルとなる。

【0078】

イメージシーケンス形式の（HEIFファイルの）mdatボックスにおいて、トラックのメディアデータは、チャンク(chunk)と呼ばれる単位で配置される。チャンクは、論理的に連続したアドレスに配置される１以上のサンプルの集合である。

【0079】

mdatボックスに、メディアデータとしての複数のトラックが格納される場合、その複数のトラックは、チャンク単位で、インターリーブして配置される。

【0080】

以上のように、イメージシーケンス形式のmdatボックスには、画像や音声等のメディアデータで構成される１以上のトラックが格納される。

【0081】

mdatボックスには、トラックを構成する画像のフレームを符号化して格納することができる。イメージシーケンス形式のmdatボックスに格納するトラックを構成するフレームの符号化には、GOP(Group of Picture)として、long GOPを採用するとともに、イントラ符号化及びインター符号化のいずれをも採用することができる。トラックを構成するフレームを符号化するコーデックとしては、例えば、HEVC等を採用することができる。

【0082】

図８は、trakボックスの例を示す図である。

【0083】

trakボックスには、tkhdボックス及びmdiaボックスを格納することができる。tkhdボックスには、trakボックスが管理するトラックの作成日時等の、トラックのヘッダ情報が格納される。mdiaボックスには、minfボックス等が格納される。minfボックスには、stblボックスが格納される。stblボックスには、トラックのサンプル、ひいては、チャンクにアクセスするための情報が格納されるstsdボックス、stscボックス、stszボックス、及び、stcoボックスが格納される。stsdボックスには、トラックのコーデックに関するコーデック情報が格納される。stscボックスには、チャンクサイズ（1チャンクのサンプル数）が格納される。stszボックスには、サンプルサイズが格納される。stcoボックスには、チャンクオフセット、すなわち、mdatボックスに格納されたトラックの各チャンクの配置位置のオフセットが格納される。

【0084】

ここで、イメージアイテム形式のHEIFファイルを、コレクションファイルともいい、イメージシーケンス形式のHEIFファイルを、シーケンスファイルともいう。

【0085】

ディジタルカメラ１０では、主画像、さらには、必要なスクリーンネイル画像、及び、サムネイル画像のうちの一方又は両方が格納されたHEIFファイルを生成することができる。

【0086】

＜コレクションファイル＞

【0087】

図９は、主画像及びサムネイル画像が格納されたコレクションファイルの例を示す図である。

【0088】

いま、コレクションファイルのmdatボックスには、フレーム（アイテム）がHEVCで符号化されて格納されることとする。

【0089】

ftypボックスには、ファイルフォーマットを識別する識別情報として、イメージアイテム形式であることと、コーデックがHEVCであることとを表すheicが格納される。

【0090】

iinfボックスには、mdatボックスに格納されたアイテムの数（アイテム数）が格納される。図９では、アイテムID#1で特定される主画像（以下、主画像Item#1のようにも記載する）、主画像Item#2、アイテムID#101で特定されるサムネイル画像（以下、サムネイル画像Item#101のようにも記載する）、サムネイル画像Item#102の合計で４個のアイテム（フレーム）が、mdatボックスに格納されている。したがって、アイテム数は４である。なお、サムネイル画像Item#101は、主画像Item#1のサムネイル画像であり、サムネイル画像Item#102は、主画像Item#2のサムネイル画像である。

【0091】

iinfボックスには、さらに、例えば、mdatボックスに格納されたアイテムごとに、infeボックスが格納される。infeボックスには、アイテムを特定するアイテムIDと、アイテムタイプとが登録される。図９では、主画像Item#1及びItem#2、並びに、サムネイル画像Item#101及びItem#102それぞれのinfeボックスが存在する。

【0092】

irefボックスには、mdatボックスに格納されたアイテムどうしを関連付ける情報として、例えば、thmbボックスが格納される。thmbボックスは、主画像とその主画像のサムネイル画像とを関連付ける情報としての参照元と参照先とが対応付けられて格納される。thmbボックスにおいて、参照元は、主画像のアイテムIDを表し、参照先は、参照元のアイテムIDで特定される主画像のサムネイル画像のアイテムIDを表す。したがって、参照元に対応付けられている参照先によれば、参照元が表すアイテムIDで特定される主画像のサムネイル画像のアイテムIDを認識することができる。また、参照先に対応付けられている参照元によれば、参照先が表すアイテムIDで特定されるサムネイル画像の主画像のアイテムIDを認識することができる。

【0093】

iprpボックスには、図６で説明したように、ipcoボックス及びipmaボックスが格納される。ipcoボックスには、図６で説明したように、mdatボックスに格納されたアイテムとしてのフレームのプロパティ、例えば、コーデックに関するコーデック情報やサイズに関する画サイズ情報が格納される。ipmaボックスには、図６で説明したように、mdatボックスに格納されたアイテムの、ipcoボックスに格納されたプロパティへのインデクスが格納される。

【0094】

ilocボックスには、図６で説明したようにmdatボックスにおけるアイテムの格納場所に関する情報が格納される。図９では、ilocボックスには、アイテム数が４であることが格納されている。さらに、ilocボックスには、mdatボックスに格納された主画像Item#1及びItem#2、並びに、サムネイル画像Item#101及びItem#102それぞれの格納場所へのオフセット及びサイズがアイテムIDと対応付けられて格納されている。

【0095】

＜シーケンスファイル＞

【0096】

図１０は、主画像のトラック及びその主画像のサムネイル画像のトラックが格納されたシーケンスファイルの例を示す図である。

【0097】

いま、シーケンスファイルのmdatボックスには、フレームがHEVCで符号化されて格納されることとする。

【0098】

ftypボックスには、ファイルフォーマットを識別する識別情報として、イメージシーケンス形式であることと、コーデックがHEVCであることとを表すhevcが格納される。

【0099】

moovボックスには、図７で説明したように、mdatボックスに格納されるトラックそれぞれを管理するtrakボックスが格納される。図１０では、トラックID#1で特定される主画像のトラック（以下、トラック#1のようにも記載する）、及び、トラック#1の主画像のサムネイル画像のトラック#2が、mdatボックスに格納されている。したがって、moovボックスには、トラック#1を管理するtrakボックスと、トラック#2を管理するtrakボックスとが格納される。トラック#2の（先頭から）n番目のサムネイル画像（のフレーム）は、トラック#1のn番目の主画像のサムネイル画像である。

【0100】

シーケンスファイルは、例えば、ディジタルカメラ１０で連写が行われた場合に、その連写で得られる複数フレームの主画像及びサムネイル画像を、それぞれ、1トラックとして記録する場合等に有用である。

【0101】

主画像のトラック#1を管理するtrakボックスのtkhdボックスには、トラック#1を特定するトラックID#1、トラック#1を構成する主画像の画サイズ、主画像が撮像されたときのディジタルカメラ１０の向きを表す回転情報、及び、トラック#1の作成日時が格納される。サムネイル画像のトラック#2を管理するtrakボックスのtkhdボックスには、トラック#2を特定するトラックID#2、及び、トラック#2の作成日時が格納される。

【0102】

trakボックスには、図７で説明したtkhdボックス及びmdiaボックスの他に、trefボックスを格納することができる。trefボックスには、そのtrefボックスが格納されたtrakボックスが管理するトラックと関連する他のトラックを特定するトラックID、及び、トラックの内容を表す情報等が格納される。図１０では、トラック#2を管理するtrakボックスの中に、trefボックスが設けられている。そして、そのtrefボックスには、トラック#2と関連する他のトラックがトラック#1であること(track_ID=1)、及び、トラック#2を構成するデータがサムネイル画像であること（トラック#2がサムネイル画像のトラックであること）(type=thmb)を表す情報が格納されている。

【0103】

trakボックスのmdiaボックスには、図８で説明したminfボックスの他、hdlrボックスを格納することができる。hdlrボックスには、そのhdlrボックスが格納されたtrakボックスが管理するトラックを構成するデータの種別を表す情報が格納される。主画像のトラック#1を管理するtrakボックスに（格納されるmdiaボックスに）格納されるhdlrボックスには、トラック#1を構成するデータがピクチャ（フレーム）であることを表す情報(pict)が格納され、サムネイル画像のトラック#2を管理するtrakボックスに格納されるhdlrボックスには、トラック#2を構成するデータがピクチャであることを表す情報が格納される。

【0104】

minfボックスについては、図８で説明した通りである。

【0105】

＜タイル画像が格納されたHEIFファイル＞

【0106】

図１１は、タイル画像が格納されたHEIFファイルの例を示す図である。

【0107】

ここで、HEIFのアイテムタイプの１つとして、gridがある。アイテムタイプがgridの画像（アイテム）であるグリッド画像は、１以上のタイル画像をタイリングすることにより形成される。

【0108】

タイル画像としては、例えば、ディジタルカメラ１０等で撮像された画像を分割して得られる分割画像を採用することができる。

【0109】

また、タイル画像としては、ディジタルカメラ１０等で撮像された画像そのものを採用し、そのようなタイル画像の１以上から、グリッド画像を形成することができる。例えば、複数のカメラで撮像された複数の画像をタイル画像として、そのような複数のタイル画像からグリッド画像を形成することができる。

【0110】

以下では、説明を分かりやすくするため、特に断らない限り、ディジタルカメラ１０等で撮像された画像を分割して得られる分割画像を、タイル画像として採用することとする。

【0111】

アイテムタイプがgridのグリッド画像については、そのグリッド画像を形成する（１以上の）タイル画像それぞれがアイテムとして、HEIFファイルに格納される。

【0112】

なお、グリッド画像については、グリッド画像そのものがHEIFファイルに格納されるのではなく、グリッド画像を形成するタイル画像がHEIFファイルに格納される。但し、本明細書では、便宜上、タイル画像が格納されたHEIFファイルを、そのタイル画像から形成されるグリッド画像が格納されたHEIFファイルともいう。

【0113】

図１１は、グリッド画像（を形成するタイル画像）が格納されたHEIFファイルの例を示している。

【0114】

図１１のHEIFファイルでは、例えば、ディジタルカメラ１０で撮像された画像（以下、撮像画像ともいう）を３×３（横×縦）個に分割することにより得られる９個の画像をタイル画像Item#1ないしItem#9として、そのタイル画像Item#1ないしItem#9が、アイテムとして、mdatボックスに格納されている。

【0115】

図１１において、mdatボックスに格納されたアイテムは、タイル画像Item#1ないしItem#9の９個のアイテムであるが、iinfボックス及びilocボックス内のアイテム数は１０になっている。これは、タイル画像Item#1ないしItem#9の９個のアイテムの他に、そのタイル画像Item#1ないしItem#9から形成されるグリッド画像（再構成画像）をアイテムとしてカウントするためである。図１１では、グリッド画像のアイテムIDは10になっており、説明の便宜上、かかるグリッド画像を、グリッド画像Item#10とも記載する。

【0116】

グリッド画像Item#10については、メディアデータがmdatボックスに格納されず、代わりに、metaボックスに、idatボックスが格納される。idatボックスには、タイル数横、タイル数縦、output_width、及び、output_height等のグリッド画像のメタデータが格納される。

【0117】

タイル数横及びタイル数縦は、グリッド画像Item#10を構成するタイル画像#1ないし#9の横方向及び縦方向の数をそれぞれ表す。

【0118】

output_width、及び、output_heightは、グリッド画像を形成するタイル画像がタイリング（配置）される画像領域であるキャンバスの横及び縦のサイズ（画素数）を表す。タイル画像の横及び縦の画素数を、tile_width及びtile_heightとそれぞれ表すこととすると、tile_width×タイル数横は、output_width以上であり、tile_height×タイル数縦は、output_height以上である必要がある。

【0119】

さらに、グリッド画像Item#10については、ilocボックスに、そのグリッド画像Item#10の格納場所に関する情報（オフセット及びサイズ）が格納されるが、この情報は、グリッド画像Item#10のidatボックスの格納場所を表す。

【0120】

図１１のHEIFファイルは、タイル画像Item#1ないしItem#9と、そのタイル画像Item#1ないしItem#9から形成されるタイル画像Item#10との10個のアイテムが格納されていることに応じて、10個のinfeボックスを有する。図９で説明したように、infeボックスには、アイテムを特定するアイテムIDと、アイテムタイプとが格納（登録）されるが、グリッド画像Item#10のinfeボックスには、グリッド画像Item#10のアイテムタイプとして、グリッドアイテムを表すgridが格納される。アイテムタイプがgridのアイテム、ここでは、グリッド画像Item#10は、グリッドアイテムと呼ばれる。

【0121】

グリッドアイテムが格納されるHEIFファイルでは、irefボックスに、dimgボックスが格納される。dimgボックスには、グリッドアイテムと、そのグリッドアイテムを構成するタイル画像とを関連付ける情報が格納される。例えば、dimgボックスには、タイル画像のアイテムIDが参照先として格納されるとともに、そのタイル画像から形成されるグリッド画像のアイテムIDが参照元として格納される。図１１では、タイル画像Item#1ないしItem#9のアイテムID#1ないし#9が参照先として格納され、グリッド画像Item#10のアイテムID#10が参照元として格納されている。その他、dimgボックスには、グリッド画像を形成するタイル画像の数を表す参照カウンタが格納される。

【0122】

以上のようなHEIFファイルについては、ファイル制御部４３は、グリッド画像Item#10のinfeボックスに格納されたアイテムタイプgridから、グリッド画像Item#10が１以上のタイル画像から形成されるグリッドアイテム（再構成画像）であることを認識することができる。さらに、ファイル制御部４３は、dimgボックスに格納された参照元と参照先とから、タイル画像から形成されるグリッド画像Item#10のアイテムID#10と、そのグリッド画像Item#10の形成に用いられるタイル画像Item#1ないしItem#9のアイテムID#1ないし#9とを特定することができる。また、ファイル制御部４３は、idatボックスに格納されたタイル数横及びタイル数縦、並びに、output_width及びoutput_heightから、グリッド画像#10を形成するタイル画像#1ないし#9の横方向及び縦方向の数、並びに、グリッド画像#10を形成する際にタイル画像#1ないし#9を配置するキャンバスの横方向及び縦方向のサイズを特定することができる。

【0123】

ファイル制御部４３は、dimgボックスから特定されたアイテムID#1ないし#9のタイル画像Item#1ないしItem#9から、idatボックスから特定された横方向及び縦方向の数のタイル画像を、idatボックスから特定されたサイズのキャンバスに配置することで、dimgボックスから特定されたアイテムID#10のグリッド画像Item#10を形成することができる。

【0124】

＜修復機能付きHEIFファイル＞

【0125】

図１２は、ファイル制御部４３により生成される修復機能付きHEIFファイルの概要を説明する図である。

【0126】

HEIFファイルには、例えば、連写で撮像された画像等の、複数枚の静止画としての画像（主画像）を格納することができる。HEIFファイルに、複数枚の画像を格納する場合、画像の枚数が多いほど、HEIFファイルのメディア１４への書き込み（記録）に要する書き込み時間が長くなる。ここでいう複数枚の画像とは、例えば、主画像及びサムネイル画像のように、同一内容の複数枚の画像を意味するのではなく、連写で撮像された画像のように、別に撮像された複数枚の画像を意味する。

【0127】

書き込み時間が長い場合、HEIFファイルのメディア１４への書き込み中の不慮の事象の発生によって、正常でないHEIFファイル、すなわち、HEIFファイルとしてのフォーマットを有していないファイルが生成される可能性が高くなることが予想される。ここで、メディア１４への書き込み中の不慮の事象とは、例えば、ユーザによってメディア１４が取り外しされることや、バッテリが抜かれること又はコンセントが抜かれることによる電源断等である。

【0128】

正常でないHEIFファイルについては、再生をすることができず、ユーザは、HEIFファイルに格納されるはずの画像すべてを失うことになる。

【0129】

そこで、ファイル制御部４３では、正常でないHEIFファイルを、正常なHEIFファイル、すなわち、HEIFファイルとしてのフォーマットを有するファイルに修復する機能を有するHEIFファイルである修復機能付きHEIFファイルを生成することができる。

【0130】

修復機能付きHEIFファイルには、画像とともに、その画像の再生や管理等のためにmetaボックスに格納されるメタデータ（以下、管理用メタデータともいう）の生成（修復）に用いられる、HEIFファイルを修復するための修復用データが格納される。

【0131】

図１２では、３枚の画像と、各画像の修復用データ、すなわち、３枚の画像それぞれについて、画像の管理用メタデータを生成するための修復用データとが格納された修復機能付きHEIFファイルが生成されている。また、図１２の修復機能付きHEIFファイルでは、画像の修復用データは、その画像の直前に配置されている。すなわち、修復用データの直後に、その修復用データを用いて管理用メタデータが修復（生成）される画像が配置されている。

【0132】

ファイル制御部４３は、修復機能付きHEIFファイルのメディア１４への書き込み中の不慮の事象の発生によって、正常でない修復機能付きHEIFファイルが生成された場合、修復用データを用いて、正常でない修復機能付きHEIFファイルを、正常な（修復機能付き）HEIFファイルに修復する。

【0133】

すなわち、ファイル制御部４３は、正常でない修復機能付きHEIFファイルに格納された、正常な書き込みが行われた画像について、その画像に対応する修復用データを用いて、管理用メタデータを生成する。さらに、ファイル制御部４３は、その管理用メタデータがmetaボックスに格納された正常なHEIFファイルを生成する。

【0134】

したがって、修復機能付きHEIFファイルのメディア１４への書き込み中に、メディア１４が取り外しされること、又は、バッテリが抜かれること等による正常でない電源断等の不慮の事象が発生した場合に、ユーザが失う画像を少なくすることができる。

【0135】

図１３は、修復用データを用いた正常でない（修復機能付き）HEIFファイルの修復の概要を説明する図である。

【0136】

図１３は、仮データのmetaボックスが書き込まれ、その後、mdatボックスに、１枚目の画像の修復用データ、１枚目の画像、２枚目の画像の修復用データ、２枚目の画像、及び、３枚目の画像の修復用データが書き込まれてから、３枚目の画像の書き込みが行われている途中で、メディア１４が取り外しされる等の不慮の事象が発生した場合のHEIFファイルの修復の例を示している。ここで、仮データのmetaボックスとは、metaボックスの書き込みの時点で確定しているメタデータ（以下、確定メタデータともいう）が書き込まれ、かつ、確定していないメタデータについては、そのメタデータを書き込む領域が確保された固定長（固定サイズ）のmetaボックスを意味する。metaボックス以外のボックスについても同様である。

【0137】

図１３では、３枚目の画像の書き込みが行われている途中で、不慮の事象が発生している。このため、図１３の修復機能付きHEIFファイルは、１枚目の画像及び２枚目の画像、並びに、１枚目の画像及び２枚目の画像の修復用データが正常（完全）に書き込まれているが、３枚目の画像が完全には書き込まれておらず、かつ、metaボックスが仮データの状態の正常でないHEIFファイルになっている。

【0138】

以上のような正常でないHEIFファイルの修復において、ファイル制御部４３は、途中まで書き込まれた３枚目の画像を削除する（切り捨てる）。さらに、ファイル制御部４３は、正常に書き込まれた１枚目の画像及び２枚目の画像の修復用データと、仮データのmetaボックスに格納されたメタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外のメタデータを生成し、そのメタデータと確定メタデータとが格納された正常なmetaボックスを生成する。そして、ファイル制御部４３は、仮データのmetaボックスに代えて、正常なmetaボックスを、HEIFファイルに書き込むことで、正常なHEIFファイルの生成（正常でないHEIFファイルの修復）を行う。

【0139】

なお、本明細書では、修復機能付きHEIFファイルとして、イメージアイテム形式のHEIFファイルを採用した場合について説明するが、修復機能付きHEIFファイルとしては、イメージシーケンス形式のHEIFファイルを採用することもできる。修復機能付きHEIFファイルとして、イメージシーケンス形式のHEIFファイルを採用する場合、mdatボックスに格納されるデータのメタデータが格納されるmetaボックスは、moovボックスとなる。

【0140】

＜修復機能付きHEIFファイルの生成＞

【0141】

図１４は、修復機能付きHEIFファイルの生成の処理の例を説明するフローチャートである。

【0142】

なお、ディジタルカメラ１０は、1回の撮像に対して、主画像、スクリーンネイル画像、及び、サムネイル画像の３枚の画像を生成し、この３枚の画像（主画像、スクリーンネイル画像、及び、サムネイル画像）と、この３枚の画像の（撮像の）メタデータとしてのEXIF及びXMPを、１枚の主画像に関連する画像関連データとしてまとめて格納したHEIFファイルを生成することができる。

【0143】

但し、図１４では、説明を簡単にするため、主画像と、EXIF及びXMPとを、１枚の主画像に関連する画像関連データとしてまとめて格納したHEIFファイルを生成することとする。

【0144】

ステップＳ１１１において、ファイル制御部４３は、撮像回数を表す変数capnumを、１つの（修復機能付き）HEIFファイルに格納する主画像を撮像した撮像回数に設定する。例えば、ユーザがレリーズボタン（図示せず）を1回だけ操作して、1回の撮像が行われた場合、変数capnumは、１に設定される。また、例えば、ユーザが連写を行った場合、変数capnumは、連写による撮像が行われた回数に設定される。

【0145】

さらに、ステップＳ１１１では、ファイル制御部４３は、HEIFファイルに格納する主画像の数をカウントする変数nを、初期値としての１に設定し、処理は、ステップＳ１１２に進む。

【0146】

ステップＳ１１２では、ファイル制御部４３は、ｎ枚目の主画像（ｎ回目の撮像で生成された主画像）及び撮像情報を、図示せぬ画像用メモリに記憶させるとともに、コーデック情報を、図示せぬmeta用メモリに記憶させ、処理は、ステップＳ１１３に進む。ここで、撮像情報とは、EXIF及びXMPの生成に用いられる、主画像（の撮像）に関連する情報、例えば、主画像の撮像時のＦ値や、焦点距離、撮像日時等である。コーデック情報とは、主画像等のコーデックに関連する情報で、例えば、SPS(Sequence Parameter Set)や、PPS(Picture Parameter Set)、VPS(Video Parameter Set)の情報等である。コーデック情報は、正常なmetaボックスの生成に用いられる。

【0147】

ステップＳ１１３では、ファイル制御部４３は、符号化制御部４２に、ｎ枚目の主画像を符号化させ、処理は、ステップＳ１１４に進む。

【0148】

ステップＳ１１４では、ファイル制御部４３は、ｎ枚目の主画像の修復用データ、すなわち、ｎ枚目の主画像のメタデータ（管理用メタデータ）を修復するための修復用データを生成し、処理は、ステップＳ１１５に進む。

【0149】

ステップＳ１１５では、ファイル制御部４３は、ｎ枚目の主画像の撮像情報を用いて、ｎ枚目の主画像のEXIF及びXMPを生成し、処理は、ステップＳ１１６に進む。

【0150】

ステップＳ１１６では、ファイル制御部４３は、変数nが１であるかどうかを判定する。

【0151】

ステップＳ１１６において、変数nが１であると判定された場合、すなわち、まだ、１枚目の主画像の画像関連データがメディア１４に書き込まれる前である場合、処理は、ステップＳ１１７に進む。

【0152】

ステップＳ１１７では、ファイル制御部４３は、仮データのftypボックス及びmetaボックスを生成する。さらに、ステップＳ１１７では、ファイル制御部４３は、メディア制御部４４を制御することにより、仮データのftypボックス及びmetaボックスを、その順で、HEIFファイルの先頭から配置する形で、メディア１４に書き込み、処理は、ステップＳ１１８に進む。

【0153】

ステップＳ１１８では、ファイル制御部４３は、ｎ枚目の主画像のEXIF及びXMPを、HEIFファイルのmdatボックスに直前に書き込まれたデータの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１１９に進む。なお、１枚目の主画像のEXIF及びXMPは、直前に書き込まれた仮データのftypボックス及びmetaボックスの直後のmdatボックスの先頭から配置する形で書き込まれる。

【0154】

ステップＳ１１９では、ファイル制御部４３は、ｎ枚目の主画像の修復用データを、HEIFファイルのmdatボックスに直前に書き込まれたｎ枚目の主画像のEXIF及びXMPの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１２０に進む。

【0155】

ステップＳ１２０では、ファイル制御部４３は、ｎ枚目の主画像を、HEIFファイルのmdatボックスに直前に書き込まれたｎ枚目の主画像の修復用データの直後に配置する形で、メディア１４に書き込み、処理は、ステップＳ１２１に進む。

【0156】

ステップＳ１２１では、ファイル制御部４３は、変数nを１だけインクリメントして、処理は、ステップＳ１２２に進む。

【0157】

ステップＳ１２２では、ファイル制御部４３は、変数nが撮像回数（を表す変数）capnum以下であるかどうかを判定する。

【0158】

ステップＳ１２２において、変数nが撮像回数capnum以下であると判定された場合、すなわち、撮像回数capnumの撮像で撮像された主画像すべてが、まだ、メディア１４に書き込まれていない場合、処理は、ステップＳ１１２に戻る。そして、以下、同様の処理が繰り返される。

【0159】

また、ステップＳ１２２において、変数nが撮像回数capnum以下でないと判定された場合、すなわち、撮像回数capnumの撮像で撮像された主画像すべてが、メディア１４に書き込まれた場合、処理は、ステップＳ１２３に進む。

【0160】

ステップＳ１２３では、ファイル制御部４３は、meta用メモリの記憶内容を用い、メディア１４に正常に書き込まれた主画像を含む画像関連データについて、正常なftypボックスとmetaボックスとを生成し、処理は、ステップＳ１２４に進む。

【0161】

ステップＳ１２４では、ファイル制御部４３は、メディア１４に書き込まれた仮データのftypボックスとmetaボックスとを、正常なftypボックスとmetaボックスとで上書きする。これにより、ファイル制御部４３は、正常なftypボックス及びmetaボックス、並びに、正常な画像関連データ（を有するmdatボックス）が格納された修復機能付きHEIFファイルを生成して、処理を終了する。

【0162】

なお、図１４では、HEIFファイルにおいて、画像関連データとしての主画像、EXIF、及び、XMPを、EXIF、XMP、主画像の順で配置することとしたが、主画像、EXIF、及び、XMPの配置順は、これに限定されるものではない。

【0163】

また、図１４では、HEIFファイルにおいて、主画像の直前に、その主画像の修復用データを配置することとしたが（主画像の修復用データの直後に、その主画像を配置することとしたが）、主画像とその主画像の修復用データとの配置関係は、これに限定されるものではない。例えば、修復用データ、並びに、画像関連データとしての主画像、EXIF、及び、XMPについては、最初に、修復用データを配置し、その後に、画像関連データとしての主画像、EXIF、及び、XMPを、EXIF、XMP、主画像の順で配置することができる。なお、修復用データを、主画像の直前に配置する場合には、修復用データを検出することができれば、修復用データの直後に続く主画像の先頭を、容易に検出することができる。

【0164】

上述したように、ここでは、説明を簡単にするために、主画像と、EXIF及びXMPとを、１枚の主画像に関連する画像関連データとすることとした。但し、１枚の主画像に関連する画像関連データとしては、主画像、及び、主画像に関連する関連画像、すなわち、主画像と同一内容の画像で、画素数が少ないスクリーンネイル画像、及び、サムネイル画像と、主画像等のメタデータであるEXIF及びXMPとを採用することができる。この場合、修復用データは、画像ごとに生成される。すなわち、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データが生成される。

【0165】

また、この場合、画像関連データ及び修復用データの配置順としては、例えば、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順を採用することができる。その他、例えば、最初に、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データをまとめて配置し、その後に、画像関連データを配置する配置順を採用することができる。

【0166】

＜修復機能付きHEIFファイルの修復＞

【0167】

図１５は、正常でない修復機能付きHEIFファイルの例を示す図である。

【0168】

なお、図１５では、説明を簡単にするため、mdatボックスには、画像及びその画像の修復用データのみが、修復用データ、画像の順で配置され、また、ftypボックについては、考慮しないこととする。後述する図１６ないし図１９でも同様である。

【0169】

図１５では、仮データのmetaボックスが書き込まれ、その後、１枚目の画像の修復用データ、１枚目の画像、２枚目の画像の修復用データ、２枚目の画像、３枚目の画像の修復用データが、その順で、mdatボックスに書き込まれている。そして、３枚目の画像の修復用データに続いて、３枚目の画像がmdatボックスに書き込まれている最中に、不慮の事象の発生、例えば、修復機能付きHEIFファイルの書き込みが行われているメディア１４がディジタルカメラ１０から取り外しされることによって、３枚目の画像の書き込みの途中で、書き込みが中断され、正常でない修復機能付きHEIFファイルが生成されている。

【0170】

このような正常でない修復機能付きHEIFファイルが記録されたメディア１４が、ディジタルカメラ１０に再び装着され、正常でない修復機能付きHEIFファイルが検出されると、ディジタルカメラ１０では、正常でない修復機能付きHEIFファイルを修復する修復処理が開始される。

【0171】

修復処理では、まず、書き込みが中断された中断箇所が検出される。

【0172】

中断箇所の検出では、ファイル制御部４３は、正常でない修復機能付きHEIFファイルのmetaボックスの先頭から、仮データのmetaボックスのサイズである固定長だけシークする（ファイルの読み書き位置を表す変数であるファイルポインタに、所望の読み書き位置を設定すること等を行う）。シーク後の位置は、１枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から１枚目の画像の修復用データを読み出す。

【0173】

なお、修復機能付きHEIFファイルの生成において、修復用データの前に、例えば、EXIFが配置されている場合、シークは、そのEXIFのサイズ分だけ多く行われる。この場合、EXIFのサイズは、固定長であることとする。

【0174】

また、修復機能付きHEIFファイルの生成において、修復用データの書き込み中に不慮の事象が発生し、正常な修復用データが書き込まれていないために、修復用データを読み出すことができなかった場合、mdatボックスの先頭に配置された画像から、読み出すことができなかった修復用データの直前に配置された画像まで（の管理用メタデータ）が、修復の対象となる。

【0175】

ファイル制御部４３は、１枚目の画像の修復用データ（の先頭部分）を読み出すことができた場合、その１枚目の画像の修復用データを用いて、その１枚目の画像の修復用データと、その後に続く１枚目の画像とのサイズを認識する。

【0176】

修復用データは、その修復用データのサイズを表すフィールドrecovery_data_size、及び、その修復用データに続く画像のサイズを表すフィールドimage_sizeを、その先頭部分に有する。ファイル制御部４３は、１枚目の画像の修復用データのフィールドrecovery_data_size及びimage_sizeから、１枚目の画像の修復用データのサイズ及び１枚目の画像のサイズを認識する。

【0177】

ファイル制御部４３は、１枚目の画像の修復用データのサイズ及び１枚目の画像のサイズを合わせたサイズだけシークする。シーク後の位置は、２枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から２枚目の画像の修復用データを読み出す。

【0178】

ファイル制御部４３は、１枚目の画像の修復用データと同様にして、２枚目の画像の修復用データを用いて、その２枚目の画像の修復用データと、その後に続く２枚目の画像とのサイズを認識する。

【0179】

ファイル制御部４３は、２枚目の画像の修復用データのサイズ及び２枚目の画像のサイズを合わせたサイズだけシークする。シーク後の位置は、３枚目の画像の修復用データの先頭の位置になるので、ファイル制御部４３は、シーク後の位置から３枚目の画像の修復用データを読み出す。

【0180】

ファイル制御部４３は、１枚目の画像の修復用データと同様にして、３枚目の画像の修復用データを用いて、その３枚目の画像の修復用データと、その後に続く３枚目の画像とのサイズを認識する。

【0181】

ファイル制御部４３は、３枚目の画像の修復用データのサイズ及び３枚目の画像のサイズを合わせたサイズだけシークする。

【0182】

シーク後の位置は、正常な修復機能付きHEIFファイルであれば、４枚目の画像の修復用データの先頭の位置（又は修復機能付きHEIFファイルの終わり）になる。しかしながら、図１５では、３枚目の画像の途中で書き込みが中断されているために、４枚目の画像の修復用データの先頭の位置にシークすることができず、シークに失敗する。

【0183】

ファイル制御部４３は、３枚目の画像の修復用データのサイズ及び３枚目の画像のサイズを合わせたサイズだけのシークの失敗により、書き込みが中断された中断箇所が、３枚目の画像（の位置）であることを検出する。

【0184】

図１６は、中断箇所の検出後の修復処理の例を説明する図である。

【0185】

ファイル制御部４３は、中断箇所を検出すると、中断箇所の画像、及び、その画像の修復用データを、修復機能付きHEIFファイルのmdatボックスから削除する。

【0186】

その結果、修復機能付きHEIFファイルのmdatボックスは、正常に書き込みが行われたデータのみが格納された状態、ここでは、中断箇所よりも先に書き込まれた１枚目及び２枚目の画像と、その１枚目及び２枚目の画像の修復用データが格納された状態になる。

【0187】

なお、中断箇所が、３枚目の画像ではなく、例えば、３枚目の画像が書き込まれる前の３枚目の画像の修復用データである場合、３枚目の画像の修復用データだけが削除される。

【0188】

また、１枚の主画像に関連する画像関連データとして、例えば、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用され、その画像関連データとともに、主画像、スクリーンネイル画像、及び、サムネイル画像それぞれの修復用データが書き込まれる場合、これらの画像関連データ及び修復用データのいずれかが中断箇所として検出されたときには、中断箇所を含む画像関連データ及び修復用データのすべてを削除することができる。この場合、例えば、サムネイル画像が中断箇所として検出されたときや、EXIFが中断箇所として検出されたときには、そのサムネイル画像又はEXIFを含む画像関連データ及び修復用データがすべて削除される。

【0189】

さらに、画像関連データ及び修復用データが、例えば、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順で配置される場合において、例えば、スクリーンネイル画像が中断箇所として検出されたときには、スクリーンネイル画像と、その直前に配置されたスクリーンネイル画像の修復用データだけを削除し、その前に配置されたEXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、及び、主画像は残すことができる。

【0190】

図１７は、中断箇所の画像、及び、その画像の修復用データの削除後の修復処理の例を説明する図である。

【0191】

ファイル制御部４３は、中断箇所の画像、及び、その画像の修復用データを削除すると、その削除後の修復機能付きHEIFファイルに正常に書き込まれた画像の修復用データを用いて、その画像の管理用メタデータが格納された正常なmetaボックスを生成（修復）する。

【0192】

すなわち、ファイル制御部４３は、正常に書き込まれた１枚目の画像及び２枚目の画像の修復用データと、仮データのmetaボックスに格納されたメタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外の管理用メタデータを生成し、その管理用メタデータと確定メタデータとを、meta用メモリに書き込むことで、正常なmetaボックスを生成する。

【0193】

図１８は、正常なmetaボックスの生成後の修復処理の例を説明する図である。

【0194】

ファイル制御部４３は、正常なmetaボックスを生成すると、修復機能付きHEIFファイルの仮データのmetaボックスの先頭の位置にシークし、シーク後の位置から、meta用メモリの正常なmetaボックスを、上書きの形で書き込む。これにより、ファイル制御部４３は、正常な（修復機能付き）HEIFファイルを生成する（正常でないHEIFファイルを修復する）。

【0195】

図１９は、修復処理の例を説明するフローチャートである。

【0196】

ファイル制御部４３は、例えば、メディア１４に記録された修復機能付きHEIFファイルの中から、正常でない修復機能付きHEIFファイルが検出されると、修復処理を開始する。HEIFファイルが、修復機能付きHEIFファイルであるかどうかは、例えば、metaボックスに、修復機能付きHEIFファイルであることを表す新規のフィールド又はボックスを設け、その新規のフィールド又はボックスに応じて判定することができる。

【0197】

修復処理では、ステップＳ１４１において、ファイル制御部４３は、メディア１４に記録された正常でない修復機能付きHEIFファイルをオープンする（HEIFファイルにアクセするためのファイルポインタの生成等を行う）。さらに、ファイル制御部４３は、オープンした正常でない修復機能付きHEIFファイルのmetaボックスの先頭から、仮データのmetaボックスのサイズである固定長だけシークし、処理は、ステップＳ１４１からステップＳ１４２に進む。

【0198】

ステップＳ１４２では、ファイル制御部４３は、シーク後の位置、すなわち、修復用データの先頭の位置から、その修復用データを読み出し、処理は、ステップＳ１４３に進む。

【0199】

ここで、修復用データでは、その修復用データのサイズを表すフィールドrecovery_data_sizeが、固定の位置、例えば、修復用データの先頭部分に配置されている。修復用データの読み出しにあたって、修復用データのサイズは、フィールドrecovery_data_sizeから認識することができる。

【0200】

ステップＳ１４３では、ファイル制御部４３は、修復用データの読み出しに成功したかどうかを判定する。

【0201】

ステップＳ１４３において、修復用データの読み出しに成功しなかったと判定された場合、すなわち、修復用データの書き込み中に不慮の事象が発生し、修復用データが正常（完全）に書き込まれずに、正常でない修復用データが書き込まれたために、修復用データを読み出すことができなかった場合、ファイル制御部４３は、その正常でない修復用データの位置を、書き込みが中断された中断箇所として検出し、処理は、ステップＳ１４７に進む。

【0202】

また、ステップＳ１４３において、修復用データの読み出しに成功したと判定された場合、処理は、ステップＳ１４４に進む。

【0203】

ステップＳ１４４では、ファイル制御部４３は、直前のステップＳ１４２で読み出した修復用データ（以下、最新の修復用データともいう）を、meta用メモリに記憶させ、処理は、ステップＳ１４５に進む。

【0204】

ステップＳ１４５では、ファイル制御部４３は、meta用メモリに記憶された最新の修復用データからフィールドrecovery_data_size及びimage_sizeを取得する。さらに、ファイル制御部４３は、recovery_data_size及びimage_sizeから、最新の修復用データのサイズ、及び、正常でない修復機能付きHEIFファイルにおいて、最新の修復用データの直後に配置されている画像のサイズを認識する。そして、ファイル制御部４３は、（修復機能付きHEIFファイルの最新の修復用データの先頭から）最新の修復用データのサイズ、及び、その最新の修復用データの直後に配置されている画像のサイズを合わせたサイズだけシークして、処理は、ステップＳ１４５からステップＳ１４６に進む。

【0205】

ステップＳ１４６では、ファイル制御部４３は、直前のステップＳ１４５で行われたシークに成功したかどうかを判定する。

【0206】

ステップＳ１４６において、シークに成功したと判定された場合、すなわち、シークによって、最新の修復用データの直後に配置されている画像の直後に配置された修復用データの先頭に到達した場合、処理は、ステップＳ１４２に戻る。ステップＳ１４２では、ファイル制御部４３は、上述したように、シーク後の位置、すなわち、修復用データの先頭の位置から、その修復用データを読み出し、以下、同様の処理が繰り返される。

【0207】

一方、ステップＳ１４６において、シークに失敗したと判定された場合、すなわち、最新の修復用データの直後に配置されている画像の書き込み中に不慮の事象が発生し、その画像の書き込みが中断された場合、ファイル制御部４３は、その書き込みが中断された、シークに失敗した画像の位置を、中断箇所として検出し、処理は、ステップＳ１４７に進む。

【0208】

ステップＳ１４７では、ファイル制御部４３は、中断箇所の画像及び修復用データを、修復機能付きHEIFファイルから削除し、処理は、ステップＳ１４８に進む。

【0209】

すなわち、ステップＳ１４７では、中断箇所が修復用データの位置である場合、その修復用データが削除される。また、中断箇所が画像の位置である場合、その画像と、その画像の直前に配置された修復用データとが削除される。

【0210】

ステップＳ１４８では、ファイル制御部４３は、meta用メモリに記憶された修復用データ、すなわち、修復機能付きHEIFファイルに正常に書き込まれた修復用データと、仮データのmetaボックスに格納された必要な管理用メタデータとを用いて、正常なHEIFファイルに必要な、確定メタデータ以外の管理用メタデータを生成し、その管理用メタデータと確定メタデータとを、meta用メモリに書き込むことで、正常なmetaボックスを生成する。

【0211】

その後、処理は、ステップＳ１４８からステップＳ１４９に進み、ファイル制御部４３は、修復機能付きHEIFファイルの仮データのmetaボックスの先頭の位置にシークし、処理は、ステップＳ１５０に進む。ステップＳ１５０では、ファイル制御部４３は、シーク後の位置から、meta用メモリの正常なmetaボックスを上書きすることで、修復機能付きHEIFファイルを修復して（正常な修復機能付きHEIFファルを生成して）、修復処理を終了する。

【0212】

＜修復用データの例＞

【0213】

図２０は、修復用データの具体例を示す図である。

【0214】

修復用データは、例えば、図２０に示すように、フィールドrecovery_data_size，image_size，next_image_exist，info_type，target_size_x，target_size_y，num_of_grid_x，num_of_grid_y，grid_width，grid_height，grid_list，capture_gamma，colormetory，hvcc_infoが、その順で配置されて構成される。

【0215】

フィールドrecovery_data_sizeは、そのフィールドrecovery_data_sizeを有する修復用データのサイズ（データ量）をバイト単位で表す。

【0216】

フィールドimage_sizeは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像のサイズ（データ量）をバイト単位で表す。

【0217】

フィールドnext_image_existは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像の後に、次の画像（及びその画像の修復用データ）が存在するかどうかを表す。次の画像が存在する場合、フィールドnext_image_existは、０及び１のうちの一方の、例えば、１に設定され、存在しない場合、フィールドnext_image_existは、他方の０に設定される。

【0218】

フィールドinfo_typeは、そのフィールドrecovery_data_sizeを有する修復用データの直後の配置される画像のピクチャタイプ（INFO種別）を表す。

【0219】

フィールドtarget_size_x及びtarget_size_yは、そのフィールドtarget_size_x及びtarget_size_yを有する修復用データの直後に配置された画像の縦及び横のサイズ（画素数）をそれぞれ表す。

【0220】

フィールドnum_of_grid_x及びnum_of_grid_yは、そのフィールドnum_of_grid_x及びnum_of_grid_yを有する修復用データの直後に配置された画像が、グリッドアイテムであるグリッド画像（を形成するタイル画像）である場合に、そのグリッド画像の縦及び横の分割数、すなわち、グリッド画像を構成するタイル画像の縦及び横の数をそれぞれ表す。

【0221】

フィールドgrid_width及びgrid_heightは、そのフィールドgrid_width及びgrid_heightを有する修復用データの直後に配置された画像がグリッド画像である場合に、そのグリッド画像を構成するタイル画像の縦及び横のサイズ（画素数）をそれぞれ表す。

【0222】

フィールドgrid_listは、そのフィールドgrid_listを有する修復用データの直後に配置された画像に関する後述するグリッド情報を表す。

【0223】

フィールドcapture_gammaは、そのフィールドcapture_gammaを有する修復用データの直後に配置された画像のガンマに関するガンマ情報を表す。

【0224】

フィールドcolormetoryは、そのフィールドcolormetoryを有する修復用データの直後に配置された画像のカラリメトリに関するカラリメトリ情報を表す。

【0225】

フィールドhvcc_infoは、そのフィールドhvcc_infoを有する修復用データの直後に配置された画像に関するhvcc情報であって、SPS，PPS，VPS等を含まないhvcc情報を表す。

【0226】

図２１は、修復用データのうちのグリッド情報としてのフィールドgrid_listの具体例を示す図である。

【0227】

フィールドgrid_listは、例えば、図２１に示すように、フィールドparam_addr，param_size，data_addr，data_size，total_vps_size，num_vps，vps_id，total_sps_size，num_sps，sps_id，total_pps_size，num_pps，pps_idが、その順で配置されて構成される。

【0228】

フィールドparam_addr及びparam_sizeは、画像に関するパラメータとしてのVPS，SPS，PPSのアドレス及びサイズ（データ量）をそれぞれ表す。

【0229】

フィールドdata_addr及びdata_sizeは、画像に関するES(Elementary Stream)のアドレス及びサイズ（データ量）をそれぞれ表す。

【0230】

フィールドtotal_vps_size，num_vps、及び、vps_idは、VPSのサイズ（データ量）、数、及び、ID（NAL(Network Abstraction Layer)ユニットのID）をそれぞれ表す。

【0231】

フィールドtotal_sps_size，num_sps、及び、sps_idは、SPSのサイズ（データ量）、数、及び、ID（NALユニットのID）をそれぞれ表す。

【0232】

フィールドtotal_pps_size，num_pps、及び、pps_idは、PPSのサイズ（データ量）、数、及び、ID（NALユニットのID）をそれぞれ表す。

【0233】

VPS，SPS、及び、PPSの数は、イメージアイテム形式のHEIFファイルでは１個であるが、イメージシーケンス形式のHEIFファイルでは複数である場合がある。

【0234】

図２２は、修復処理において、少なくとも修復用データを用いて生成（修復）されるメタデータが格納されるボックスを示す図である。

【0235】

ここで、修復用データ（のフィールド）を用いて管理用メタデータが生成（修復）されることを、その管理データが格納されるボックスが生成（修復）される、とも表現する。

【0236】

修復用データを用いて生成され得る、metaボックスに格納されるボックスとしては、pitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、ilocボックスがある。

【0237】

なお、metaボックスに格納されるボックスのうちのiinfボックス、iprpボックス、ipcoボックス、及び、impaボックスは、確定メタデータが格納されるボックスであるか、又は、他のボックスから生成することができる管理用メタデータが格納されるボックスであり、修復用データなしで生成することができる。

【0238】

pitmボックス（に格納される管理用メタデータ）は、フィールドgrid_width及びgrid_heightを用いて生成することができる。

【0239】

infeボックス及びdimgボックスは、フィールドnum_of_grid_x及びnum_of_grid_yを用いて生成することができる。

【0240】

thumボックスは、フィールドtarget_size_x及びtarget_size_yを用いて生成することができる。

【0241】

colrボックスは、フィールドcapture_gamma及びcolormetoryを用いて生成することができる。

【0242】

hvccボックスは、フィールドgrid_list及びhvcc_infoを用いて生成することができる。

【0243】

ipseボックスは、フィールドtarget_size_x及びtarget_size_yを用いて生成することができる。

【0244】

idatボックスは、フィールドnum_of_grid_x，num_of_grid_y，grid_width，grid_height、及び、grid_listを用いて生成することができる。

【0245】

ilocボックスは、フィールドgrid_listを用いて生成することができる。

【0246】

なお、mdatボックスは、metaボックスに格納されるボックスではないが、mdatボックス内の、中断箇所の修復用データの削除後のデータ、又は、中断箇所の画像、及び、その画像の修復用データの削除後のデータのサイズ（データ量）については、フィールドgrid_listを用いて生成することができる。

【0247】

図２３は、修復処理において、少なくとも修復用データを用いて生成される管理用メタデータが格納されるボックスの生成（修復）方法を説明する図である。

【0248】

なお、図２３では、修復処理において、修復用データを用いて生成されるボックス以外の修復機能付きHEIFファイルを構成するボックスの生成方法も示されている。

【0249】

また、図２３において、関連フィールドとは、ボックス（に格納される管理用メタデータ）を生成するのに用いられる修復用データのフィールドを表す。

【0250】

さらに、図２３では、１枚の主画像に関連する画像関連データとして、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPとを採用するとともに、画像関連データ及び修復用データのmdatボックス内の配置順として、EXIF、サムネイル画像の修復用データ、サムネイル画像、主画像の修復用データ、主画像、スクリーンネイル画像の修復用データ、スクリーンネイル画像、XMPの順を採用することとする。

【0251】

修復機能付きHEIFファイルは、ftypボックス、metaボックス、及び、mdatボックスを有する。

【0252】

metaボックスには、hdlrボックス、pitmボックス、iinfボックス、irefボックス、iprpボックス、idatボックス、及び、ilocボックスが格納され得る。

【0253】

iinfボックスには、infeボックスが格納され得る。

【0254】

irefボックスには、dimgボックス、thumボックス、及び、cdscボックスが格納され得る。

【0255】

iprpボックスには、ipcoボックス、及び、ipmaボックスが格納され得る。iprpボックスに格納され得るipcoボックスには、colrボックス、hvccボックス、ispeボックス、及び、irotボックスが格納され得る。

【0256】

ftypボックスは、（あらかじめ決められた）固定の値を用いて生成することができる。

【0257】

metaボックスは、metaボックスに格納される各ボックスのサイズ（データ量）を求め、そのサイズを用いて生成することができる。

【0258】

hdlrボックスは、固定の値を用いて生成することができる。

【0259】

pitmボックスは、修復用データの直後に配置された画像がグリッド画像でない場合、主要アイテムのアイテムIDを１に設定し、その主要アイテムのアイテムIDを用いて生成することができる。また、pitmボックスは、修復用データの直後に配置された画像がグリッド画像（を構成するタイル画像）である場合、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、主要アイテムのアイテムIDを、式num_of_grid_x×num_of_grid_y + 1に従って求め、その主要アイテムのアイテムIDを用いて生成することができる。

【0260】

iinfボックスは、iprpに格納される各ボックスのサイズ（データ量）と、infeボックスの数（合計数）とを求め、そのサイズと数とを用いて生成することができる。なお、iinfボックスには、mdatボックスに格納されたアイテムの数が格納されるが、画像関連データについて、アイテムの数は、以下のようにカウントされる。１枚の主画像に関連する画像関連データとして、例えば、主画像、EXIF、及び、XMPが採用される場合、１つの画像関連データに対するアイテム数は、主画像、EXIF、及び、XMPの３個になる。また、１枚の主画像に関連する画像関連データとして、例えば、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用される場合、１つの画像関連データに対するアイテム数は、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPの５個になる。例えば、１枚の主画像に関連する画像関連データとして、主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPが採用され、mdatボックスに、２枚の主画像の画像関連データが格納されている場合、iinfボックスに格納されるアイテムの数は、１０（＝５×２）個となる。

【0261】

infeボックスは、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、グリッド画像を構成するタイル画像の数（gridの構成要素数）num_of_grid_x×num_of_grid_yを求め、そのタイル画像の数num_of_grid_x×num_of_grid_yに、１枚の主画像に関連する画像関連データとしての主画像、スクリーンネイル画像、サムネイル画像、EXIF、及び、XMPのうちの、主画像以外の構成要素の数、すなわち、スクリーンネイル画像(SCN)、サムネイル画像(thumb)、EXIF、及び、XMPの数である４個を加算した加算値を用いて生成することができる。

【0262】

irefボックスは、irefに格納される各ボックスのサイズ（データ量）を求め、そのサイズを用いて生成することができる。

【0263】

dimgボックスは、修復用データのフィールドnum_of_grid_x及びnum_of_grid_yを用いて、グリッド画像を構成するタイル画像の数（gridの構成要素数）num_of_grid_x×num_of_grid_yを求め、その数num_of_grid_x×num_of_grid_yを用いて生成することができる。

【0264】

thmbボックスは、スクリーンネイル画像(SCN)及びサムネイル画像(thumb)それぞれについて、修復用データのフィールドtarget_size_x及びtaget_size_yを用いて、target_size_x及びtaget_size_yがスクリーンネイル画像又はサムネイル画像のサイズ（画素数）になっているアイテム（画像）のアイテムIDを、スクリーンネイル画像又はサムネイル画像のアイテムIDとして求め、そのアイテムIDを用いて生成することができる。

【0265】

cdscボックスは、ここでは、画像関連データ及び修復用データの配置順が決まっているので、画像関連データにおいてサムネイル画像のサイズ（画素数）になっているアイテム（画像）のアイテムIDを基準として、EXIF及びXMPのアイテムIDを求めることができ、そのEXIF及びXMPのアイテムIDを用いて生成することができる。

【0266】

iprpボックスは、iprpボックスに格納される各ボックスのサイズを求め、そのサイズを用いて生成することができる。

【0267】

ipcoボックスは、ipcoボックスに格納される各ボックスのサイズを求め、そのサイズを用いて生成することができる。

【0268】

colrボックスは、修復用データのフィールドcapture_gamma及びcolormetoryを用いて生成することができる。

【0269】

hvccボックスは、修復用データのフィールドhvcc_info及びgrid_listを用いて生成することができる。

【0270】

ispeボックスは、修復用データのフィールドtarget_size_x及びtaget_size_yを用いて生成することができる。

【0271】

irotボックスは、固定の値を用いて生成することができる。

【0272】

ipmaボックスは、各アイテムのinfeボックスと、ipco内の各プロパティとの紐づけを行うことができるように、例えば、各アイテムのinfeボックスの順番をあらかじめ決められた順番に固定することで、infeボックスとそのinfeボックスに紐づくipcoボックス内の各プロパティとを用いて生成することができる。
ここで、各アイテムのinfeボックスの順番を固定することで、infeボックスと、ipco内の、そのinfeボックスに対応するアイテムのプロパティとを紐付けることができる。
例えば、infeボックスの順番を、アイテムIDが1のアイテムとしての主画像、アイテムIDが2のアイテムとしてのスクリーンネイル画像、アイテムIDが3のアイテムとしてのサムネイル画像、EXIF、XMPの（infeボックスの）順に固定することとする。
また、ipcoボックスに、プロパティとしての、主画像、スクリーンネイル画像、及び、サムネイル画像に共通の情報、主画像のコーデック情報、主画像の画サイズ情報、スクリーンネイル画像のコーデック情報、スクリーンネイル画像の画サイズ情報、サムネイル画像のコーデック情報、サムネイル画像の画サイズ情報が、その順番で格納されることとする。
この場合、アイテムIDが1の主画像のプロパティは、ipcoボックス内の1番目、2番目、3番目のプロパティとなる。アイテムIDが2のスクリーンネイル画像のプロパティは、ipcoボックス内の1番目、4番目、5番目のプロパティとなる。アイテムIDが3のサムネイル画像のプロパティは、ipcoボックス内の1番目、6番目、7番目のプロパティとなる。
したがって、infeボックスと、そのinfeボックスに対応するアイテムのプロパティとを紐付けることができる。
そして、infeボックスと、そのinfeボックスに紐付けられたプロパティ（infeボックスに対応するアイテムのプロパティ）とを用いて、ipcoボックス内の各アイテムのプロパティへのインデクスを格納したipmaボックスを生成することができる。
なお、HEIFの規格書には、
・infeボックスにitemの種類とIDが記載されること、
・ipcoボックスにコーデック情報(hvcc)や画サイズ(ipse)の情報があること、
・ipmaボックスにIDに紐づくプロパティが何かが明記されること
が記載されている。

【0273】

idatボックスは、修復用データのフィールドgrid_list，grid_width，grid_height num_of_grid_x、及び、num_of_gird_yを用いて生成することができる。

【0274】

ilocボックスは、修復用データのフィールドgrid_listを用いて生成することができる。

【0275】

なお、図２２で説明したように、mdatボックス内の（実際に使用する）データのサイズについては、フィールドgrid_listを用いて生成することができる。

【0276】

＜本技術を適用したコンピュータの説明＞

【0277】

次に、上述した一連の処理は、ハードウエアにより行うこともできるし、ソフトウエアにより行うこともできる。一連の処理をソフトウエアによって行う場合には、そのソフトウエアを構成するプログラムが、汎用のコンピュータ等にインストールされる。

【0278】

図２４は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。

【0279】

プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク９０５やROM９０３に予め記録しておくことができる。

【0280】

あるいはまた、プログラムは、ドライブ９０９によって駆動されるリムーバブル記録媒体９１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体９１１は、いわゆるパッケージソフトウエアとして提供することができる。ここで、リムーバブル記録媒体９１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。

【0281】

なお、プログラムは、上述したようなリムーバブル記録媒体９１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク９０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。

【0282】

コンピュータは、CPU(Central Processing Unit)９０２を内蔵しており、CPU９０２には、バス９０１を介して、入出力インタフェース９１０が接続されている。

【0283】

CPU９０２は、入出力インタフェース９１０を介して、ユーザによって、入力部９０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)９０３に格納されているプログラムを実行する。あるいは、CPU９０２は、ハードディスク９０５に格納されたプログラムを、RAM(Random Access Memory)９０４にロードして実行する。

【0284】

これにより、CPU９０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU９０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース９１０を介して、出力部９０６から出力、あるいは、通信部９０８から送信、さらには、ハードディスク９０５に記録等させる。

【0285】

なお、入力部９０７は、キーボードや、マウス、マイク等で構成される。また、出力部９０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。

【0286】

ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。

【0287】

また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。

【0288】

さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。

【0289】

なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。

【0290】

例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。

【0291】

また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。

【0292】

さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。

【0293】

また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。

【0294】

なお、本技術は、以下の構成をとることができる。

【0295】

＜１＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部を備える
ファイル処理装置。
＜２＞
前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータである
＜１＞に記載のファイル処理装置。
＜３＞
前記ファイル制御部は、前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置する
＜２＞に記載のファイル処理装置。
＜４＞
前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含む
＜３＞に記載のファイル処理装置。
＜５＞
前記修復用データは、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復するデータを含む
＜２＞ないし＜４＞のいずれかに記載のファイル処理装置。
＜６＞
前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
前記ファイル制御部は、前記画像の修復用データと、前記関連画像の修復用データとを書き込む
＜１＞ないし＜５＞のいずれかに記載のファイル処理装置。
＜７＞
前記関連画像は、前記画像より画素数が少ない画像である
＜６＞に記載のファイル処理装置。
＜８＞
前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納される
＜１＞ないし＜７＞のいずれかに記載のファイル処理装置。
＜９＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むことを含む
ファイル処理方法。
＜１０＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルに、前記HEIFファイルを修復する修復用データを書き込むファイル制御部
として、コンピュータを機能させるためのプログラム。
＜１１＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部を備える
ファイル処理装置。
＜１２＞
前記修復用データは、前記HEIFファイルにおいて前記画像を管理するための管理用メタデータを修復するためのデータであり、
前記ファイル制御部は、前記修復用データを用いて、前記管理用メタデータを生成する
＜１１＞に記載のファイル処理装置。
＜１３＞
前記ファイル制御部は、前記HEIFファイルから、書き込みが中断された中断箇所の前記画像を削除し、前記修復用データを用いて、前記中断箇所よりも先に書き込まれた前記画像が格納された前記HEIFファイルを生成する
＜１２＞に記載のファイル処理装置。
＜１４＞
前記画像の前記管理用メタデータを修復する前記修復用データを、前記画像の直前に配置し、
前記修復用データは、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを含み、
前記ファイル制御部は、前記修復用データの先頭から、前記修復用データのサイズ、及び、前記修復用データの直後に配置される前記画像のサイズを合わせたサイズのシークに失敗した場合、前記画像を前記中断箇所として検出する
＜１３＞に記載のファイル処理装置。
＜１５＞
前記HEIFファイルには、前記画像と前記画像に関連する関連画像とが格納され、
前記ファイル制御部は、前記画像及び前記関連画像のいずれかが前記中断箇所として検出された場合、前記画像及び前記関連画像を削除する
＜１３＞又は＜１４＞に記載のファイル処理装置。
＜１６＞
前記関連画像は、前記画像より画素数が少ない画像である
＜１５＞に記載のファイル処理装置。
＜１７＞
前記HEIFファイルには、前記画像と、前記画像のメタデータとが格納され、
前記ファイル制御部は、前記画像及び前記メタデータのいずれかが前記中断箇所として検出された場合、前記画像及び前記メタデータを削除する
＜１３＞ないし＜１６＞のいずれかに記載のファイル処理装置。
＜１８＞
前記ファイル制御部は、前記修復用データを用いて、前記HEIFファイルのmetaボックスに格納されるpitmボックス、infeボックス、dimgボックス、thmbボックス、colrボックス、hvccボックス、ipseボックス、idatボックス、及び、ilocボックスに格納される前記管理用メタデータを修復する
＜１２＞ないし＜１７＞のいずれかに記載のファイル処理装置。
＜１９＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復することを含む
ファイル処理方法。
＜２０＞
静止画の画像が格納されるHEIF(High Efficiency Image File Format)ファイルを修復する修復用データが書き込まれた前記HEIFファイルを、前記修復用データを用いて修復するファイル制御部
として、コンピュータを機能させるためのプログラム。

【符号の説明】

【0296】

１０ ディジタルカメラ， １１ 光学系， １３ 信号処理部， １４ メディア， １５，１６ I/F， １７ ボタン／キー， １８ タッチパネル， １９ 液晶パネル， ２０ ビューファインダ， ２１ I/F， ４１ 光学系／イメージセンサ制御部， ４２ 符号化制御部， ４３ ファイル制御部， ４４ メディア制御部， ４５ 操作制御部， ４６ 表示制御部， ４７ UI制御部， ９０１ バス， ９０２ CPU， ９０３ ROM， ９０４ RAM， ９０５ ハードディスク， ９０６ 出力部， ９０７ 入力部， ９０８ 通信部， ９０９ ドライブ， ９１０ 入出力インタフェース， ９１１ リムーバブル記録媒体

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】