JP7367130B2 - ファイルを生成する方法、装置、プログラム、ならびにファイルを処理することにより画像を再生する方法、装置、プログラム - Google Patents

Description

本発明は記述メタデータを備えたメディアコンテナ中への、静止画像、静止画像のバースト、または映像データなど、画像データのストレージに関する。かかるメタデータは、一般に、画像データおよび画像データの部分への容易なアクセスを提供する。

本セクションで記述されるアプローチのいくつかは追行されたものであるかもしれないが、必ずしも従来から考案または追求されてきたアプローチではない。したがって、本セクションに記載されるアプローチは、必ずしも本出願中の特許請求事項より以前の技術でなく、本セクションに包含することによって従来技術であることを認めない。

ＨＥＶＣ規格は、静止画像の符号化に対するプロフィールを定義し、単一の静止画像または静止画像のバーストを圧縮するための特定のツールを記載している。かかる種類の画像データに用いられるＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）の拡張版を、「画像ファイルフォーマット」の名の下にＩＳＯ／ＩＥＣ２３００９規格パート１２に包含することが提案されている。この規格は、相異なる使用状況に対応するストレージの２つの様式を網羅している：
－ デコーダで随意に使われるタイミングに対応する画像シーケンスのストレージであって、それらの画像は他の画像に依存することが可能なもの、および
－ 単一画像のストレージであって、個別に符号化された画像の収集。

最初のケースでは、カプセル化は、ＩＳＯベースメディアファイルフォーマットにおける映像トラックのカプセル化（文献＜＜情報技術－視聴覚オブジェクトの符号化－パート１２：ＩＳＯベースメディアファイルフォーマット＞＞、ＩＳＯ／ＩＥＣ１４４９６－１２：２００８、第三版、２００８年１０月を参照）に近く、記述のため「ｔｒａｋ」ボックスおよびサンプルグループ化など同じツールおよび概念が使われている。「ｔｒａｋ」ボックスは、トラックを記述するためのサブボックスを包含するファイルフォーマットボックス、言い換えれば、関連するサンプルの時間調節されたシーケンスである。

二番目のケースでは、ＩＳＯＢＭＦＦボックスのセット、「ｍｅｔａ」ボックスが使われる。これらのボックスおよびその階層は、「ｔｒａｃｋ」ボックスよりも少ない記述ツールを提供し、関連サンプルの代わりに「情報アイテム」または「アイテム」に関連する。

画像ファイルフォーマットは、マルチメディアファイルをローカルに表示するため、またはマルチメディアプレゼンテーションをストリーミングするために使うことができる。ＨＥＶＣ静止画像は、多くの問題を惹起する多くの用途を有する。

画像バーストは１つの用途である。画像バーストは、カメラによって取り込まれた静止ピクチャのシーケンスであり、（多くのピクチャアイテムがデータのブロックを参照する）単一の表現体として格納される。ユーザが、サムネイルまたは表紙として選ぶ、これらのピクチャに効果を適用するなど、これらのピクチャにいくつかの種類の処置を施すことを望むことがある。

しかして、データのブロック中のピクチャのリストをそれらの対応バイトとともに識別するための記述メタデータが必要とされている。

コンピュテーショナルフォトグラフィは別の用途である。コンピュテーショナルフォトグラフィでは、ユーザは、同じピクチャの異なる解像レベル（異なる露光、異なる焦点など）へのアクセスを有する。これらの異なる解像レベルは、その１つが選択でき、処理（レンダリング、編集、送信など）のため対応するデータ片を探索し抽出可能なように、メタデータとして格納される必要がある。

サイズに関連してピクチャの解像レベルが増大するに従って、これらの大きなピクチャの一部の空間的部分だけを容易に識別し抽出できるように、十分な記述を備えることが必要とされている。

用途の別の種類には、例えば、ビデオの要約、ビデオ監視データ中の証拠画像などのための、映像シーケンスの特定のピクチャへのアクセスがある。

かかる種類の用途に対し、圧縮映像データおよび映像トラッメタデータに加えて、主要画像への容易なアクセスを可能にする画像メタデータが必要とされている。

さらに、プロのカメラは高い空間解像レベルに達している。４Ｋ２Ｋ解像レベルを有する映像または画像は今や当たり前である。今日では、８ｋ４ｋの映像または画像でさえ一般的である。並行して、映像は、映像ストリーミング機能を備えた携帯および接続デバイス上で益々多く再生されている。しかして、携帯デバイスのユーザが、品質を保持、または向上さえさせながら、映像のサブ部分を表示することを望みまたはそれに焦点を合わせることを欲する場合に、映像をタイルに分割することが重要となる。タイルを用いることによって、ユーザは、映像の空間的サブ部分をインタラクティブに要求することができる。

しかして、単にメタデータボックスを構文解析すること以外の追加的な処理なしにアクセス可能にするために、ファイルフォーマットのコンパクトな形式で映像のこれら空間的サブ部分を記述することが必要とされている。また、斯く記述された映像に対応する画像に対しても、空間的サブ部分へのアクセスはユーザの関心事項である。

ＩＳＯ／ＩＥＣ２３００９規格は、静止画像を最近討議されたファイルフォーマット中にカプセル化するための２つの仕方を取り上げている。

１つの仕方は、「ｔｒａｃｋ」ボックス、および関連する記述ツールの関係付けられた関連サンプルの時間調節されたシーケンスの概念に基づいており、別の１つは、サンプルの代わりに情報アイテムに基づく「ｍｅｔａ」ボックスに基づいていて、特に対象の領域の記述およびタイル化のサポートに対し、記述がより少ないツールを提供する。

斯くのごとく、新規の画像ファイルフォーマットにおけるタイル化のサポートを提供することが必要とされている。

タイルの使用、特に圧縮時における使用は、従来技術でもよく知られている。ＩＳＯベースメディアファイルフォーマットにおけるこれらのインデクゼーションに関し、ＩＳＯ／ＩＥＣ１４４９６規格「Ｃａｒｒｉａｇｅ ｏｆ ＮＡＬ ｕｎｉｔ ｓｔｒｕｃｔｕｒｅｄ ｖｉｄｅｏ ｉｎ ｔｈｅ ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＩＳＯベースメディアファイルフォーマットにおけるＮＡＬユニット構造化映像のキャリッジ）」のパート１５の改正版のドラフト中にも、タイル化記述子が存在する。

しかしながら、これらの記述子は、「ｔｒａｃｋ」ボックスおよびサンプルグループ化ツールに依存し、「ｍｅｔａ」ベースのアプローチを用いる場合、静止画像ファイルフォーマット中では使うことができない。かかる記述子なしでは、このファイルフォーマット中に格納された符号化ピクチャからタイルを選んで抽出することが面倒になる。

図１は、ＭＰＥＧの寄稿ｍ３２２５４中で開示されている、ＩＳＯベースメディアファイルフォーマットの「ｍｅｔａ」ボックス（１００）中の、タイルを使って符号化された静止画像の記述を示す。

各タイルピクチャ（１０２、１０３、１０４、および１０５）に対するそれぞれの情報アイテムに加え、全体ピクチャ１０１に対する情報アイテムが定義されている。これらの情報アイテムは「ＩｔｅｍＩｎｆｏＢｏｘ（アイテム情報ボックス）」（ｉｉｎｆ）と呼ばれるボックス中に格納される。ＩＳＯ ＢＭＦＦ規格からの「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ（アイテム参照ボックス）」と呼ばれるボックス（１０６）が、全体ピクチャの情報アイテムとタイルピクチャに対応する４つの情報アイテム（１０８）との間に「タイル」関係性（１０７）が存在することを示すために使われている。「ＩｔｅｍＬｏｃａｔｉｏｎＢｏｘ（アイテム配置ボックス）」と呼ばれるボックス（１０９）が、各情報アイテムを表す符号化データ（１１０）中のバイト範囲（群）を規定するのに、各情報アイテムの識別子が用いられる。別のボックス「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」（１１２）が、ＥＸＩＦメタデータ（１１１）を全体ピクチャ（１０１）に対する情報アイテムに関連付けるために使われ、対応するデータブロック（１１１）がメディアデータボックス（１１０）中に生成される。また、ＥＸＩＦメタデータを識別するためにさらなる情報アイテム（１１３）が生成される。

たとえ、全体ピクチャおよびそのタイルが情報アイテムとして導入されても、ここではタイル化情報は提供されない。さらに、追加のメタデータを（ＥＸＩＦのような）情報アイテムと関連付ける際に、追加の「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」を使って参照されるデータブロックが生成されない。

静止画像ファイルフォーマットドラフト中で定義されている、ＥＸＩＦからのタイル化の情報の再利用およびメカニズムの再利用では、既存のＥＸＩＦタグ使って不規則なグリッドを記述することができないであろう。

しかして、静止画像、とりわけＨＥＶＣ静止画像に対するファイルフォーマットの改良がさらに必要とされている。具体的には、このファイルフォーマットを使って格納された静止画像中の対象の領域を抽出するための方法が必要とされている。

本発明は、上記のコンテキストの範囲内にある。

本発明の第一態様によれば、１つ以上の画像を表現する符号化ビットストリームをカプセル化する方法が提供され、本方法は、
－ 画像エリアを１つ以上のタイルに分割するための空間パラメータを含むタイル記述情報を備えるステップと、
－ 単一画像のタイルを表現するビットストリームの部分を識別するタイルピクチャアイテム情報を備えるステップと、
－ 前記タイルピクチャアイテムを前記タイル記述情報にリンクする参照情報を備えるステップと、
－ 前記ビットストリームを前記備えられた情報と一緒にカプセル化データファイルとして出力するステップと、
を含む。

この出力は、定義された標準に従って行うことができ、読み取り可能で復号可能である。

第一態様による方法は、面倒な計算なしにシンタックス要素を構文解析することによって、例えば、超高解像レベル画像（４Ｋ２Ｋ、８Ｋ４Ｋ…）から、タイルを容易に識別し、選択し、抽出することを可能にする。

ＩＳＯベースメディアファイルフォーマットのメタデータボックスのこれら記述ツールは拡張することが可能である。具体的には、これは、タイル記述を情報アイテムに関連付けることを可能にする。

「ｍｅｔａ」ボックス階層の諸部分は、追加の記述ツールを提供し、特に静止画像内でのタイルベースのアクセスをサポートするように拡張することができる。

第一態様による方法は、符号化ＨＥＶＣ静止画像から、ＨＥＶＣタイルに基づく対象の領域を容易に抽出することを可能にする。

本発明の諸実施形態は、ＨＥＶＣ規格によって符号化された静止画像に対するタイル記述サポートおよびタイルアクセスを提供する。

これは、静止画像に対する映像トラックのため利用可能な対象特徴の領域を保つことを可能にする。一般に、ユーザ定義の対象領域に対応する静止ピクチャの諸部分は、識別し、レンダリングまたはメディアプレイヤーへの送信のため容易に抽出できる。

また、例えば、前記カプセル化された符号化ビットストリームは、映像シーケンスに対応する前記データストリームの時間調節された部分を識別する情報も包含する。

したがって、この映像の部分である一部の静止画像において、映像への同じアクセスの便宜を提供する二重インデキシングを単一のデータ片上に設けることができる。

例えば、タイル記述情報は、各タイルピクチャアイテムに対する空間パラメータのセットを含む。

例えば、タイル記述情報は、複数のタイルピクチャアイテムに共通の空間パラメータを含む。

例えば、タイル記述情報は、ビットストリーム中に組み込まれる。

例えば、タイル記述情報は、メタデータとして備えられる。

例えば、参照情報は、参照の型と、前記タイル記述情報を含む追加の記述メタデータとを含む。

例えば、参照情報は、参照の型と、前記タイル記述情報に関する参照パラメータとを含む。

本方法は、ビットストリーム中の前記タイル記述情報を参照するためのメタデータアイテムを備えるステップ、をさらに含むことができる。

例えば、タイルピクチャアイテムがグループ化され、タイルピクチャアイテムのグループを前記タイル記述情報にリンクするための参照情報を備えることが可能である。

例えば、メタデータアイテムを別のアイテムにリンクする全ての参照が、カプセル化データファイル中の単一の参照ボックスの中に含まれる。

例えば、任意の種類の１アイテムからの全ての関係性が、単一のアイテム情報記述子中に格納される。

例えば、前記出力が、適応ストリーミング用のサーバモジュールによって行われる。

例えば、前記出力が、メモリ中へのストレージのために行われる。

例えば、前記出力が、表示のため表示モジュールに向けて行われる。

例えば、前記出力が、送信のため通信モジュールによって行われる。

例えば、前記カプセル化データファイルが、標準化されたファイルフォーマットに対応する。

例えば、前記カプセル化データファイルが、復号可能で再生可能である。

本発明の第二態様によれば、１つ以上の画像に対応する符号化ビットストリームを含むカプセル化データファイルと、画像のエリアを１つ以上のタイルに分割するための空間パラメータを含むタイル記述情報を包含する情報とを処理する方法が提供され、本方法は、－ 対象の画像領域を選択するステップと、
－ 前記タイル記述情報から、選択された対象のエリアに対応するタイルを識別するステップと、
－ 前記識別されたタイルにリンクされた１つ以上のタイルピクチャアイテムを選択するステップであって、各タイルピクチャアイテムは単一画像の一タイルを表現するビットストリームの部分を識別する、該選択するステップと、
－ 選択されたタイルピクチャアイテム（群）によって識別されたビットストリームの部分を抽出するステップと、
－ 前記抽出されたビットストリーム部分を出力するステップと、
を含む。

例えば、前記出力が、適応ストリーミング用のサーバモジュールによって行われる。

例えば、前記出力が、メモリ中へのストレージのために行われる。

例えば、前記出力が、表示のため表示モジュールに向けて行われる。

例えば、前記出力が、送信のため通信モジュールによって行われる。

例えば、前記カプセル化データファイルが、標準化されたファイルフォーマットに対応する。

例えば、前記カプセル化データファイルが、復号可能で再生可能である。

本発明の第三態様によれば、カプセル化ファイルの中にカプセル化するため、少なくとも１つの画像を表現する画像データを処理する方法が提供され、本方法は、
－ 前記少なくとも１つの画像の複数の画像部分への空間的サブ分割を得るステップと、－ 前記複数のうちの一画像部分を表現する、前記画像データ内のデータ部分を識別する少なくとも１つの部分識別データを判断するステップと、
－ 前記画像データを、少なくとも、
○ 前記少なくとも１つの画像の前記サブ分割を表現するサブ分割記述データ、
○ 前記部分識別データ、および
○ 前記サブ分割記述データと前記部分識別データとをリンクする参照データ、
と共に、前記カプセル化ファイル中にカプセル化するステップと、
を含む。

例えば、前記画像データは、映像シーケンスの複数の画像を表現し、本方法は、前記映像シーケンスの時間部分を表す、前記画像データ内のデータ部分を識別する少なくとも１つの時間識別データを判断するステップをさらに含み、前記画像データは、前記時間識別データと共にカプセル化される。

例えば、複数の部分識別データが、それぞれ、前記映像シーケンスの前記時間部分の画像の同じ画像部分を表現していると判断される。

例えば、少なくとも前記サブ分割記述データが、画像データに対するメタデータとしてカプセル化される。

例えば、前記空間的サブ分割が、前記画像データを包含するビットストリーム中に組み込まれる。

例えば、各画像部分に対する、それぞれの部分識別データが判断される。

例えば、複数の画像部分に対する共通の部分識別データが判断される。

本方法は、サーバデバイスによって、前記カプセル化ファイルを、適応ストリーミングのためのビットストリーム中に出力するステップをさらに含むことが可能である。

本方法は、前記画像データを表示するため表示デバイスに送信するべく、前記カプセル化ファイルをビットストリーム中に出力するステップをさらに含むことができる。

本方法は、クライアントデバイスへの送信のため、前記カプセル化ファイルをビットストリーム中に出力するステップをさらに含むことが可能である。

本方法は、前記カプセル化ファイルをストレージデバイス中に格納するステップをさらに含むことが可能である。

例えば、参照データが、参照の型と、前記サブ分割記述データを含む追加の記述メタデータとを含む。

例えば、参照データが、参照の型と、前記サブ分割記述データに関する参照パラメータとを含む。

例えば、前記サブ分割記述データが、メタデータアイテム中で参照される。

例えば、部分識別データがグループ化され、参照データが、部分識別データのグループを前記部分識別データにリンクする。

例えば、前記カプセル化ファイルが、画像データに対する全ての参照データを包含する単一の参照ボックスを含む。

例えば、前記カプセル化ファイルが、前記サブ分割記述データと、部分識別データと、参照データとの間の関係性の表現を包含する記述を含む。

本発明の第四態様によれば、カプセル化ファイルを処理する方法が提供され、該ファイルは、
－ 少なくとも１つの画像を表現する画像データと、
－ 前記少なくとも１つの画像の、複数の画像部分への空間的サブ分割を表現するサブ分割記述データと、
－ 前記画像データ内の、前記複数のうちの一画像部分を表現するデータ部分を識別する少なくとも１つの部分識別データと、
－ 前記サブ分割記述データと前記部分情報とをリンクする参照情報と、
を含み、
本方法は、
－ 前記少なくとも１つの画像中の対象の領域を判断するステップと、
－ 前記サブ分割記述データに基づいて、前記対象の領域に属する少なくとも１つの画像部分を判断するステップと、
－ 前記参照データに基づいて、前記対象の領域に属する前記少なくとも１つの画像部分を表現する、前記画像データ内のデータ部分を識別する少なくとも１つの部分識別データにアクセスするステップと、
－ 前記画像データ内の前記データ部分を抽出するステップと、
を含む。

例えば、前記画像データが、映像シーケンスの複数の画像を含み、前記カプセル化ファイルが、前記映像シーケンスの時間部分を表す、前記画像データ内のデータ部分を識別する少なくとも１つの時間識別データをさらに含み、前記映像シーケンスの前記時間部分の画像に対する対象の領域が判断され、前記映像シーケンスの前記時間部分の複数の画像中の、前記対象の領域に対応するデータ部分が抽出される。

例えば、複数の部分識別データが、それぞれ、前記映像シーケンスの前記時間部分の画像の同じ画像部分を表現する。

例えば、少なくとも前記サブ分割データが、画像データに対するメタデータとしてカプセル化される。

例えば、各画像部分に対して、それぞれの部分識別データが判断される。

例えば、複数の画像部分に対して、共通の部分識別データが判断される。

本方法は、サーバデバイスによって、適応的にストリームされたビットストリームとして前記カプセル化ファイルを受信するステップをさらに含むことが可能である。

本方法は、前記対象の領域を表示するステップをさらに含むことが可能である。

例えば、参照データが、参照の型と、前記サブ分割記述データを包含するさらなる記述メタデータとを含む。

例えば、参照データが、参照の型と、前記サブ分割記述データに関する参照パラメータとを含む。

例えば、前記サブ分割記述データが、メタデータアイテム中で参照される。

例えば、部分識別データがグループ化され、参照データが、部分識別データのグループを前記部分識別データにリンクする。

例えば、前記カプセル化ファイルが、画像データに対する全ての参照データを包含する単一の参照ボックスを含む。

例えば、前記カプセル化ファイルが、前記サブ分割記述データと、部分識別データと、参照データとの間の関係性の表現を包含する記述を含む。

本発明の第五態様によれば、上記第一態様による方法を実装するよう構成されたデバイスが提供される。

本デバイスは、
－ 画像エリアを１つ以上のタイルに分割するための空間パラメータを含むタイル記述情報を備え、単一画像のタイルを表現するビットストリームの部分を識別するタイルピクチャアイテム情報を備え、前記タイルピクチャアイテムを前記タイル記述情報にリンクする参照情報を備えるよう構成された処理ユニットと、
－ 前記ビットストリームを、前記備えられた情報と一緒にカプセル化データファイルとして出力するよう構成された通信ユニットと、
を含むとよい。

本発明の第六態様によれば、上記第二態様による方法を実装するよう構成されたデバイスが提供される。

本デバイスは、１つ以上の画像に対応する符号化ビットストリームを含むカプセル化データファイルと、画像エリアを１つ以上のタイルに分割するための空間パラメータを含むタイル記述情報を包含する情報と、を処理するように構成することができる。また、本デバイスは、
－ 対象の画像領域を選択し、前記タイル記述情報から、選択された対象のエリアに対応するタイルを識別し、前記識別されたタイルにリンクされた１つ以上のタイルピクチャをアイテム選択し、各タイルピクチャアイテムは単一の画像のタイルを表現するビットストリーム部分を識別しており、選択されたタイルピクチャアイテム（群）によって識別されたビットストリーム部分を抽出するよう構成された処理ユニットと、
－ 前記抽出されたビットストリーム部分を出力するよう構成された通信ユニットと、を含むことが可能である。

本発明の第七態様によれば、上記第三態様による方法を実装するよう構成されたデバイスが提供される。

本デバイスは、カプセル化ファイル中へのカプセル化のために、少なくとも１つの画像を表現する画像データを処理するよう構成することが可能であり、本デバイスは、前記少なくとも１つの画像の、複数の画像部分への空間的サブ分割を得、前記画像データ内の、前記複数のうちの一画像部分を表現するデータ部分を識別する少なくとも１つの部分識別データを判断し、前記画像データを、少なくとも、
－ 前記少なくとも１つの画像の前記サブ分割を表現するサブ分割記述データと、
－ 前記部分識別データと、
－ 前記サブ分割記述データと前記部分識別データとをリンクしている参照データと、共に、前記カプセル化ファイル中にカプセル化するよう構成された処理ユニットを含むことが可能である。

本発明の第八態様によれば、上記第四態様による方法を実装するよう構成されたデバイスが提供される。

本デバイスは、
－ 少なくとも１つの画像を表現する画像データと、
－ 前記少なくとも１つの画像の複数の画像部分への空間的サブ分割を表現するサブ分割記述データと、
－ 前記画像データ内の、前記複数のうちの一画像部分を表現するデータ部分を識別する少なくとも１つの部分識別データと、
－ 前記サブ分割記述データと前記部分情報とをリンクする参照データと、
を含むカプセル化ファイルを処理するように構成することが可能である。

また本デバイスは、前記少なくとも１つの画像中の対象の領域を判断し、前記サブ分割記述データに基づいて、前記対象の領域に属する少なくとも１つの画像部分を判断し、前記参照データに基づいて、前記画像データ内の、前記対象の領域に属する前記少なくとも１つの画像部分を表現するデータ部分を識別する少なくとも１つの部分識別データにアクセスし、前記画像データ内の前記データ部分を抽出するよう構成された処理ユニット、を含むことができる。

本発明の第九態様によれば、
－ 第五～第七態様による第一デバイスと、
－ 前記第一デバイスからのファイルを処理するための第六～第八態様による第二デバイスと、
を含むシステムが提供される。

本発明の第十態様によれば、プログラム可能な装置のコンピュータ手段上にロードされ実行されたとき、本発明の第一、第二、第三および／または第四態様（群）による方法を実装するための命令を含む、コンピュータプログラムおよびコンピュータプログラム製品が提供される。

本発明の第十一態様によれば、符号化ビットストリームが格納されたメディアデータ部とメタデータ部とを有する、ＩＳＯＢＭＦＦで定義されたファイルを生成する方法が提供され、本方法は、
１枚の画像あるいは１枚の画像のサブ画像を表す、メディアデータ部の部分を特定するための画像アイテム情報を取得するステップと、
１枚の画像あるいはサブ画像の幅と高さに関するプロパティを有する画像プロパティを取得するステップと、
画像アイテム情報および画像プロパティ、ならびに画像アイテム情報および画像プロパティに対応する１枚の画像の符号化ビットストリームを有するファイルを生成するステップとを有し、
メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
画像プロパティは、メタデータ部の所定のボックスに格納され、
所定のボックスは、画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと画像プロパティとを関連付けるために用いられる。

或る実施形態において、画像記述情報中に含まれる各パラメータは、
－ 型情報、および／または
－ 画像アイテム情報を前記パラメータにリンクするため使われる識別子、
を含む追加データに関連付けられる。

或る実施形態において、メタデータ部分は、ＩＳＯＢＭＦＦの「ｍｅｔａ」データボックス中に含まれる。

或る実施形態において、追加データはヘッダである。

或る実施形態において、追加データは仮想アイテムである。

別の実施形態において、画像記述情報中に含まれる各変換オペレータは、変換されたアイテムを前記変換オペレータにリンクするために使われる識別子を含む追加データに関連付けられる。

或る実施形態において、メタデータ部分中に格納された或るボックスが、少なくとも１つの変換オペレータを含む。

或る実施形態において、カプセル化ビットストリームのデータ部分は、１つ以上の変換オペレータに関連付けられた被変換アイテムを含み、メタデータ部分は、
－ 変換オペレータが適用された当初の画像を識別するための情報と、
－ データ部分中の被変換アイテムをローカライズするための情報と、
をさらに含む。

或る実施形態において、被変換アイテムは、少なくとも１つの変換インデックス、すなわち、メタデータ部分中の変換オペレータの１つを識別することを可能にするインデックスを含む。

本発明の第十二態様によれば、メディアデータ部とメタデータ部とを有するＩＳＯＢＭＦＦで定義されたファイルを処理することにより、画像を再生する方法が提供され、本方法は、
ファイルのメタデータ部から、１枚の画像あるいは１枚の画像のサブ画像を表す、メディアデータ部の部分を特定するための画像アイテム情報を取得するステップと、
ファイルのメタデータ部から、１枚の画像あるいはサブ画像の幅と高さに関するプロパティを有する画像プロパティを取得するステップと、
画像アイテム情報および画像プロパティに基づいて、１枚の画像を再生するステップとを有し、
メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
画像プロパティは、メタデータ部の所定のボックスに格納され、
所定のボックスは、画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと画像プロパティとを関連付けるために用いられる。

或る実施形態において、本方法は、上記識別するステップの前に、前記パラメータ群中に含まれる追加データを読み取るステップをさらに含み、前記追加データは、
－ 型情報、および／または
－ 画像またはサブ画像アイテム情報を前記パラメータにリンクするのに使われる識別子、
を含む。

或る実施形態において、メタデータ部分は、ＩＳＯＢＭＦの「ｍｅｔａ」データボックス中に含まれる。

或る実施形態において、追加データはヘッダである。

或る実施形態において、追加データは仮想アイテムである。

別の実施形態において、画像記述情報に含まれている各変換オペレータは、被変換アイテムを前記変換オペレータにリンクするのに使われる識別子を含む追加データに関連付けられる。

或る実施形態において、メタデータ部分に格納された或るボックスが、少なくとも１つの変換オペレータを含む。

或る実施形態において、カプセル化ビットストリームのデータ部分は、１つ以上の変換オペレータに関連付けられた被変換アイテムを含み、メタデータ部分は、
－ 変換オペレータが適用された当初の画像を識別するための情報と、
－ データ部分中の被変換アイテムをローカライズするための情報と、
をさらに含む。

或る実施形態において、被変換アイテムは、少なくとも１つの変換インデックスを含み、インデックスはメタデータ部分中の変換オペレータの１つを識別することを可能にする。

本発明の第十三態様によれば、本発明の上記第十一態様によるカプセル化方法を実装するよう構成された、１つ以上の画像を表現する符号化ビットストリームをカプセル化するサーバデバイスが提供される。

本発明の第十四態様によれば、本発明の上記第十二態様による処理方法を実装するよう構成された、１つ以上の画像を表現する符号化ビットストリームをカプセル化するクライアントデバイスが提供される。

本発明の第十五態様によれば、プログラム可能装置のコンピュータ手段上にロードされ実行されたとき、本発明の第十一および第十二態様による方法を実装するための命令を含む、コンピュータプログラムおよびコンピュータプログラム製品が提供される。

本発明の他の特徴および利点は、添付の図面を参照しつつ、以下の非限定の例示的な諸実施形態の説明から明らかとなろう。

ＭＰＥＧの寄稿ｍ３２２５４中で開示されている、ＩＳＯベースメディアファイルフォーマットの「ｍｅｔａ」ボックス中の、タイルを使って符号化された静止画像の記述を示す。 タイル化された映像の一例を示す。 ＨＥＶＣ中の様々なタイル／スライス構成を示す。 「ｔｒａｃｋ」ボックスを使うＩＳＯベースメディアファイルフォーマットによるタイルカプセル化を示す。 ＩＳＯＢＭＦＦの「ｍｅｔａ」ボックス中の、情報アイテムを記述するための標準的メタデータを示す。 情報アイテム記述に対する例示的な拡張を示す。 情報アイテムの間の参照のメカニズムを示す。 本発明の諸実施形態の実装のコンテキストを示す。 本発明の１つ以上の実施形態を実装するためのコンピューティングデバイスの概略ブロック図である。

以降で、本発明の諸実施形態を説明する。

技術的コンテキストをよりよく理解するために連続する時間的フレームを有する映像（２００）を示す図２を参照しながら、映像のタイル化を説明する。各フレーム（２０１）は、「タイル」Ｔ１～Ｔ８と称される８つの部分（ここでは矩形部分）に分割される。これらタイルの数および形状は異なるものとすることも可能である。以下では、映像フレームのインデックスの如何に関わらず、タイル化は同様であると見なすものとする。

このタイル化の結果は８つの独立したサブ映像（２０２）である。これらのサブ映像は全体的映像の区分を表す。各独立のサブ映像は、例えばＡＶＣまたはＨＥＶＣ規格に従って独立したビットストリームとして符号化することができる。また、このサブ映像は、例えばＨＥＶＣ規格のタイルまたはＡＶＣ規格のスライスのような、１つの単一映像ビットストリームの部分であってよい。

ＨＥＶＣ規格は、ピクチャの各種の空間サブ分割、タイル、スライス、およびスライスセグメントを定義している。これらの各種のサブ分割（または区分）は、異なる目的のため導入されたもので、スライスはストリーミングの流れに関連し、一方、タイルおよびスライスセグメントは、並列処理のため定義されている。

タイルは、整数の符号化ツリーユニット（ＣＴＵ：Ｃｏｄｉｎｇ Ｔｒｅｅ Ｕｎｉｔ）を包含するピクチャの矩形領域を定義する。図３は、行および列の境界（３０１、３０２）によって定義された、画像（３００）のタイル化を示す。これは、位置およびサイズに関し、対象領域の記述のためタイルの良好な候補を形成する。但し、ＨＥＶＣ規格のビットストリーム編成は、シンタックスおよびネットワーク抽象層（ＮＡＬ：Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔ Ｌａｙｅｒ）ユニット中へのそのカプセル化に関し、むしろ（ＡＶＣ規格におけるように）スライスに基づいている。

ＨＥＶＣ規格によれば、スライスは、スライスセグメントのセットであって、少なくとも最初のスライスセグメントは独立スライスセグメントであり、存在する場合、他のものは従属スライスセグメントである。スライスセグメントは、（ラスタースキャン順での）整数の連続するＣＴＵを包含する。これは必ずしも矩形形状を有しない（しかして、対象の領域の表現に対しタイルよりも適切性が低い）。「ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ（スライスセグメントヘッダ）」と呼ばれるヘッダとしてＨＥＶＣビットストリーム中に符号化され、その後に「ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｄａｔａ（スライスセグメントデータ）」と呼ばれるデータが配置される。独立スライスセグメントと従属セグメントとはそれらのヘッダが異なり、従属スライスセグメントは、それらが独立スライスセグメントのヘッダからの情報を再利用するので、より短いヘッダを有する。独立および従属スライスセグメントの両方は、ビットストリーム中に、タイルもしくはエントロピー復号同期ポイント、いずれかへのエントリーポイントのリストを包含する。

図３は、スライス、スライスセグメント、およびタイルの相異なる構成の画像３１０と３２０とを示す。これらの構成は、１つのタイルが１つのスライス（１つだけの独立スライスセグメントを包含する）を有する画像３００の構成とは異なる。画像３１０は、２つの垂直タイル（３１１、３１２）および（５つのスライスセグメントを有する）１つのスライスに区分されている。画像３２０は、２つのタイル（３２１、３２２）に分割され、左タイル３２１は（それぞれが２つのスライスセグメントを有する）２つのスライスを有し、右タイル３２２は（２つのスライスセグメントを有する）１つのスライスを有する。ＨＥＶＣ規格は、タイルとスライスセグメントの間の編成ルールを定義しており、これは次のように要約できる（１つまたは両方の条件が満たされなければならない）：
－ 一スライスセグメント中の全てのＣＴＵが同一のタイルに属する、および
－ 一タイル中の全てのＣＴＵが同一のスライスセグメントに属する。

対象の領域をサポートおよび移送に適合させるためには、１タイルが１独立セグメントを有する１スライスを包含する構成３００が好ましい。但し、本カプセル化ソリューションは他の構成３１０または３２０でも機能するであろう。

このタイルは、対象の領域に対する適切なサポートであるが、ネットワーク上の移送のために実際はＮＡＬユニットの中に入れられ、アクセスユニット（ファイルフォーマットレベルの符号化ピクチャまたはサンプル）を形成するために集合される。ＨＥＶＣ規格によれば、ＮＡＬユニットの型はＮＡＬユニットヘッダ中で指定される。ＮＡＬユニット型「符号化スライスセグメント」に対し、ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒが、「ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ａｄｄｒｅｓｓ（スライスセグメントアドレス）」シンタックス要素を介して、スライスセグメント中の最初の符号化ツリーブロックのアドレスを示す。タイル化情報は、ＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ピクチャパラメータセット））ＮＡＬユニット中に備えられる。こうして、スライスセグメントとタイルとの間の関係は、これらのパラメータから導出することができる。

定義により、タイル境界上で空間的予測がリセットされる。但し、或るタイルが、参照フレーム（群）中の異なるタイルからの時間的予測子を使用することが妨げられることはない。符号化時に、独立タイルを構築するために、タイル内部の予測ユニットに対する動きベクトルが、参照フレーム（群）中の同一場所配置されたタイルの中に留まるよう制約される。さらに、インループフィルタ（デブロッキングおよびＳＡＯ）は、１つだけのタイルを復号する際にエラードリフトが導入されないように、タイル境界上で失活される必要がある。インループフィルタのこの制御は、ＨＥＶＣ規格で既に利用可能であり、「ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（タイル横断ループフィルタ有効化フラグ）」と呼ばれるフラグを使ってスライスセグメントのヘッダ中に設定される。このフラグを明示で０に設定することによって、タイル境界の画素が、隣接のタイルの境界上に位置する画素に依存することはない。動きベクトルおよびインループフィルタに対するこれら２つの条件が満たされたとき、これらタイルは「独立的に復号可能」または「独立的」と言われる。

映像シーケンスが独立タイルのセットとして符号化される場合、参照データ喪失のリスク、または再構成エラーの伝搬なしに、１つのフレームから別のフレームへとタイルベースの復号を使って、該映像を復号することが可能である。この構成は、例えば対象の領域に対応する当初の映像の空間的部分だけを再構成することを可能にする。

以降で、独立タイルについて検討する。

図４を参照すると、タイルのＩＳＯＢＭＦＦファイルフォーマット中へのカプセル化が表されている。例えば、各タイルが専用のトラック中にカプセル化される。全てのタイルに共通のセットアップおよび初期化情報は、例えば、「タイルベーストラック」と呼ばれる、特定のトラック中にカプセル化される。全体映像は、しかして、これら全てのトラック、すなわち、タイルのベーストラックと、タイルトラックのセットとの合成体としてカプセル化される。

図４は、例示的なカプセル化を示す。ＩＳＯＢＭＦＦ規格によってタイル化された映像をカプセル化する１つのやり方は、各タイルを専用のトラックに分割し、全タイルに共通なセットアップおよび初期化情報を、例えば「タイルベーストラック」と呼ばれる特定のトラックにカプセル化し、全体映像をこれら全トラックの合成体、すなわちベーストラックプラスタイルトラックのセットとしてカプセル化することである。このカプセル化は、しかして「多重トラックタイルカプセル化」と言われる。多重トラックタイルカプセル化の一例が図４中に提示されている。

ボックス４０１は、主ＩＳＯＢＭＦＦボックス「ｍｏｏｖ」を表し、トラックの全リストをそれらの識別子と併せ包含する。例えば、ボックス４１１～４１４は、タイルトラック（本例では４つのタイル）を表し、ボックス４２０はタイルベーストラックを表す。音声またはテキストトラックなどの追加のトラックは、同じファイルの中で用い、カプセル化することができる。但し、簡明化のため、かかる追加トラックはここでは説明しない。

図４に表されているように、タイルデータは、復号および表示のため、これらタイルトラックを参照しているタイルベーストラックからタイルトラック（群）の任意の組み合せが容易に再構成できるように、独立したアドレス可能なトラック中に分割されている。また、タイルベーストラックは、これが、１つの、多くの、または全てのタイルなど任意のタイルの組み合せを可能にするので「合成トラック」または「参照トラック」と言われることもある。タイルベーストラック４２０は、全タイルトラックに共通の情報、および「ｍｄａｔ」ボックス中にサンプルのリスト４５０（図４では最初のものだけが表されている）を包含する。タイルベーストラック４２０の各サンプル４５０は、抽出子（４５１～４５４のそれぞれ１つが各タイルに対する１つの抽出子を表す）の使用を介した各タイルトラックへの参照によって構築される。各タイルトラック４１１～４１４は、全体映像または全体フレーム映像の空間部分を表す。タイル記述（位置、サイズ、バンド幅など）は、各タイルトラック４１１～４１４のトラックヘッダボックス（図示せず）中に格納される。タイルベーストラックと各タイルトラックとは、各トラック中の「ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘ（トラック参照ボックス）」を使って相互参照される（４０５）。各タイルトラック４１１～４１４は、「ｔｂａｓ」トラックとしてタイルベーストラック４２０を参照する（「ｔｂａｓ」は、具体的には、ファイルフォーマットの構文解析から得られる基本ストリームを処理することになる映像デコーダのセットアップを可能にするパラメータ「ＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ（ＨＥＶＣデコーダ設定記録）」を見出す際に、各タイルトラックからタイルベーストラックへの符号化依存性を示す特定のコードである）。逆に、全体映像の再構成を可能にするために、タイルベーストラック４２０は、各タイルトラック（４０５）への型「ｓｃａｌ」の依存性を示す。これは、符号化依存性を示し、タイルベーストラックのサンプル４５０の定義をタイルトラックのデータに対する抽出子として反映するためである。これらの抽出子は、構文解析時にデータの欠如に対応することのできる特有の抽出子である。図４では、ファイルのストリーム可能なバージョンを設けるために、各トラックは、メディアセグメント（タイルトラック対する４３１～４３４、およびタイルベーストラックに対する４６０）に分解される。各メディアセグメントは、「ｍｏｏｆ」ボックスプラスデータによって示される１つ以上のムービーフラグメントを含む。タイルトラックに対し、データ部分は映像の空間サブ部分に対応し、一方、タイルベーストラックに対しては、これは、パラメータのセット、存在する場合ＳＥＩメッセージ、および抽出子のリストを包含する。「ｍｏｏｖ」ボックス４０１は、ストリーミング応用の場合に、初期化セグメントに適合することになろう。図４は１つのセグメントだけを示しているが、これらトラックは任意の数のセグメントに分解することが可能で、制約は、タイルトラックおよびタイルベーストラックに対するセグメントが同じ時間的分解に従う（すなわち、これらが時間的に整列される）ということであり、これによって、全体映像からタイルまたはタイルのセットへの切り替えが可能になる。簡明化のため、この時間的分解の粒度についてはここでは説明しない。

このファイルフォーマットは、１つのタイル、タイルの組み合せ、または全タイルに対応するデータが、記述メタデータの構文解析によって容易に識別可能なように、トラック間の関係性を記述する（例えば、「ＶｉｓｕａｌＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｉｅｓ（視覚サンプルグループエントリ）」、または「ｔｒｅｆ」ボックス中のトラック参照型などの」）記述メタデータを有する。

以降に、静止画像を同じレベルで説明する。このように、ユーザの、ピクチャの任意のタイル、タイルの組み合わせまたは全タイルの選択に際して、識別および抽出が容易化される。ピクチャが映像データに混合されている場合、その記述は、映像に対する記述メタデータと並行してもたらされる。しかして、同一のデータセットに対し、（映像および音声に対するインデクセーション層に加え）ピクチャのための追加のインデクセーション層が設けられる。

「ｍｅｔａ」ボックスを用いる静止画像ファイルフォーマットにおいて、関連情報を有するピクチャは、情報アイテムとして記述される。図５に示されるように、これらの情報アイテムは、「ｍｅｔａ」ボックスの専用サブボックス「ＩｔｅｍＩｎｆｏＢｏｘ」５００中にリストされる。このサブボックスは、ファイル中に存在する情報アイテムの数を提示する。また、該サブボックスは、各アイテムに対し、「ＩｔｅｍＩｎｆｏＥｎｔｒｙ（アイテム情報エントリ）」５０１として表された記述メタデータも備えている。ＩＳＯ ＢＭＦＦ規格進展版によれば、このボックスのいくつかのバージョン５０２（０、１、２）が存在する。

「ｍｅｔａ」アイテムは、一ファイル中に切れ目なく格納することはできない。また、該アイテムデータのインターリービングに関する特定の制限はない。しかして、同一のファイル中の２つのアイテムが、１つまたはいくつかのデータブロックを共有してもよい。これは、独立的に復号可能なタイルごとに１つのアイテムを有することを容易にできるので、ＨＥＶＣタイルに対して特に有用である（タイルが連続的にまたは非連続に格納できる）。このアイテムは、ＩｔｅｍＬｏｃａｔｉｏｎＢｏｘ（アイテム配置ボックス）を介して、タイルに使われる、主ＨＥＶＣピクチャ中のデータのオフセット、およびスライス（群）の長さを示す。

諸実施形態によれば、タイルピクチャを記述する新規のアイテム型を加えることが可能で、例えば、「ｈｖｃｔ」または「ｔｉｌｅ」と名付けられ、あるいはＩＳＯ／ＩＥＣ１４４９６－１５「ｈｖｔ１」からのアイテム型が再利用される。タイルピクチャを表す各アイテム（選択された４文字コードが何であれ）は、それが抽出された「ｈｖｃ１」アイテムへの型「ｔｂａｓ」の参照を有することが可能である。各アイテムは、識別子「ｉｔｅｍ＿ＩＤ」５０３を有し、ピクチャに対する圧縮データを包含するメディアデータボックス中のバイトの位置およびサイズに関し、ボックス「ＩｔｅｍＬｏｃａｔｉｏｎＢｏｘ」中にさらに記述される。

かかるシンタックスは、ファイルフォーマットリーダー（または「パーサー」）が、情報アイテムのリスト介して、いくつの情報アイテムが、例えば、情報アイテムが全体ピクチャの一タイルピクチャであることを示す「ｔｉｌｅ」など、それらの型５０４に関する情報を使って利用可能であるかを判断することを可能にする。

しかして、これは、他のタイルをスキップしながら、画像の１つだけのタイル、および関連するデコーダ設定をダウンロードするために、情報アイテムのファイル、その組み合せわせ、または全セット中の情報アイテムのサブセットを選択することを可能にする。

復号するため、ＨＥＶＣタイルが別のＨＥＶＣタイルに依存する場合、ＩＳＯ／ＩＥＣ１４４９６－１５：２０１３ ＡＭＤ１のＷＤの文献ｗ１４１２３「Ｅｎｈａｎｃｅｄ ｃａｒｒｉａｇｅ ｏｆ ＨＥＶＣ ａｎｄ ｓｕｐｐｏｒｔ ｏｆ ＭＶＣ ｗｉｔｈｄｅｐｔｈ ｉｎｆｏｒｍａｔｉｏｎ（深度情報を使ったＨＥＶＣ改良型キャリッジおよびＭＶＣのサポート）」、ＭＰＥＧ１０７サンノゼ２０１４年１月、に記載されている型「ｄｐｎｄ」（または、符号化依存性を示す任意の特定な４文字コード）のアイテム参照によって、上記依存性が示されなければならない。

この文献は、（「ＴｉｌｅＲｅｇｉｏｎＧｒｏｕｐＥｎｔｒｙ（タイル領域グループエントリ）」記述子を使用して）、ＨＥＶＣタイルＮＡＬＵをタイルの空間的位置を示すサンプルグループの記述に関連付けるためのツールを定義している。また一方、メタデータ情報アイテムに対するサンプルのグループ化の直接的な同等記述子はなく、これによりこれらに記述子の再利用を可能にできよう。

したがって、諸実施形態によれば、タイル記述アイテムは、タイルごと定義され、そのタイルは、以下に説明するように「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」ボックスの修正バージョンを使ってその記述にリンクされる。

他の実施形態によれば、好ましくは一般的な方法で、１つだけのタイル化記述が設けられる。さすれば、アイテムリストが長すぎるようになることはない。

この設計は、次のようにすればよい：
－ いくつかのアイテムが、サンプルグループと同様にだが各アイテム型に固有に、メタデータのセットを記述することを可能にする、
－ 任意のアイテムに対し、アイテム参照の所与の型に対する１つのパラメータを記述する能力を加える。このときこのパラメータは、（グループ化の型と同様に）参照されるアイテムの型に応じて解釈されることになろう。

以降に図６を参照しながら説明するように、情報アイテムに対する記述メタデータのアップグレードが必要となり得る。

ＩＳＯＢＭＦＦ規格によれば、サンプルグループ化のメカニズムは、次のような「ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ（グループ化＿型）」パラメータを有する２つの主ボックスに基づく：
－ ボックス「ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘ（サンプルグループ記述ボックス）」は、プロパティのリスト（リスト「ＳａｍｐｌｅＧｒｏｕｐＥｎｔｒｙ（サンプルグループエントリ）」）を定義するパラメータ「ｓｇｐｄ」を有する。
－ ボックス「ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘ（サンプルからグループへボックス）」は、サンプルグループとそれらのプロパティへのマッピングとのリストを定義するパラメータ「ｓｂｇｐ」を有する。

「ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ」パラメータは、サンプルグループのリストをプロパティのリストにリンクし、一サンプルグループの、該リスト中の１つのプロパティへのマッピングは、ボックス「ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘ」中に指定される。

これらの情報アイテムに対し同じ機能を設けるために、情報アイテムグループのリストおよびプロパティのリストを記述する必要がある。また、情報アイテムの各グループをプロパティにマップできるようにする必要がある。

以降で、かかる記述メタデータをどのように静止画像ファイルフォーマットに組み込むことを可能にするかを説明する。言い換えれば、どのように記述子を画像アイテムにリンクするかである。たとえＨＥＶＣ静止画像ファイルフォーマットに対する使用の例が説明されていたとしても、以下の機能は、任意の種類の情報アイテムを追加の記述メタデータに関連付けるため、ＩＳＯ／ＩＥＣ１４４９６－１２など他の規格においても使用することが可能である。

諸実施形態によれば、パラメータ「ｉｎｆｅ」を備える既存の「ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＥｎｔｒｙ（アイテム情報エントリ）」ボックス６０１は、図６に示されるように「ｉｒｅｆ＿ｔｙｐｅ」６０４と呼ばれる新規のパラメータを介して各アイテムをプロパティにリンクするために、新規のバージョン番号（６０２および６０３）を使って拡張される。これは、新ボックスの生成を回避し、記述を短く保ちながらそれを改良することを可能にする。

ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＥｎｔｒｙボックスの当初の定義は、

で与えられる。

タイルピクチャをその記述にリンクさせる新規バージョンは次のようにすればよい：

ボックス「ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘ」により近い他の実施形態によれば、４文字コード「ｉｉｎｆ」を備えるボックス「ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘ（アイテム情報ボックス）」の定義は、例えば、このボックスの新規バージョンを導入することによって、次のように変更される：
現在バージョン：

は、
次の：

に変更される。

あるいは、グループが使われているかどうかをシグナリングするために、現在バージョンが、

に変更される。

「ｇｒｏｕｐ＿ｅｎｔｒｙ＿ｃｏｕｎｔ（グループ＿エントリ＿カウント）」パラメータは、メディアファイル中の情報アイテムグループの数を定義する。情報アイテムの各グループに対し、ｉｔｅｍ＿ＩＤ＝０から開始して情報アイテムの数が示される。サンプルと違って、情報アイテムは、時間制約および時間関係性がないので、カプセル化モジュールは、任意の順序で情報アイテム識別子を割り当てることができる。引き続くアイテムグループに従って増大する識別子に番号を割り当てることによって、グループ中の連続する情報アイテム識別子のランを識別するパラメータｉｔｅｍ＿ｒｕｎ（アイテム＿ラン）を使って、情報グループのリストをより効率的に表すことが可能である。

関連する情報アイテムは、例えば「ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘ（プロパティ＿インデックス）」と呼ばれるインデックスを有する。「ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ（グループ化＿型）」パラメータに関連付けられたこの「ｐｒｏｐｅｒｔｙ＿ｉｎｄｅｘ」パラメータは、ファイルフォーマットパーサー（またはリーダー）が記述メタデータへの参照もしくは記述メタデータ自体を識別することを可能にする。図７は、２つの例示的な実施形態を示す。

ボックス「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ（単一アイテム型参照ボックス）」７０１中のグループ機能は、ｆｒｏｍ＿ｉｔｅｍ＿ＩＤ（アイテム＿ＩＤ＿から）パラメータの値に対して通常使われる情報アイテム識別（ｉｔｅｍ＿ＩＤ）の代わりに、グループ識別「ｇｒｏｕｐ＿ＩＤ」と共に使用することができる。設計上、ボックス「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ」は、特定の種類のまたは特定のアイテムからの全ての参照を見出すことを容易にする。これを、「ｉｔｅｍ＿ＩＤ」の代わりに「ｇｒｏｕｐ＿ＩＤ」と共に使うことで、特定の型の全ての参照を容易に識別してアイテムのグループを見出すことが可能になる。有利には、カプセル化ファイルごとに最大で１つのボックス「ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘ」があるので、グループ識別を定義する必要はない。カプセル化モジュール（符号化の過程で）および構文解析モジュール（復号の過程で）は、グループが生成または読み取られると、情報アイテムグループのリストに対するそれぞれのカウンタ（ボックス「ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘ（アイテム情報ボックス）」中の「ｇ」変数として）を進めることができる。これに換えて、パーサーに対し、フラグ「ｇｒｏｕｐ＿ｕｓｅｄ＿ｆｌａｇ（グループ＿使用＿フラグ）」を使って、グループ識別カウンタを維持するかしないかを通知することも可能である。

タイルピクチャに対応する情報アイテムの１つのグループを使う例に戻って、１つのグループが４つのエントリを包含することが可能で、参照７００「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅ」は、４つのタイルピクチャ情報アイテムが依存し、特定の参照型７０３に対してもそうである、情報アイテムのリスト７０４を示すことが可能である。

他の例示的な実施形態によれば、情報アイテムは、以降で説明するように、１つのアイテム７２２から様々な他の情報アイテム７２４に対する複数の参照型７２３をリストすることを可能にする、新規種類のボックス「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」の中で使用される。

後者の場合に対しては、特定のボックス「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」７２１は次のように実装すればよい：

標準のボックス「ＩｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｏｘ」に対しては、アイテムエントリのリストが記述されるが、このときは、グループ化の如何によって異なる順序となる。
本タイルの例において、これは、「ｔｉｌｅ」と名付けることの可能なパラメータを使ってグループ中に集められたタイルピクチャに対応する４つの情報アイテムの最初のグループにつながり、その後には、構成情報、全体ピクチャの情報アイテム、および随意的にＥＸＩＦメタデータに対する非グループ化情報アイテムが続く。

しかして、１つのボックスは修正され、ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘの特定の種類である１つのボックスが生成される。以降で、この新規種類のＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘについて説明する。

また、このボックス「ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ」は、ＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘの一部であるボックス「ＦｕｌｌＢｏｘ（全体ボックス）」中のフラグパラメータを使って様々な種類のＩｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘの間を分別することによって、次のように拡張することが可能である：

ボックス「ＭｕｌｔｉｐｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ（複数アイテム型参照ボックス）」７２１を用いて、４つのタイルを有する１つのピクチャを次のように記述することができる：

この設計は、特定のアイテムから任意の種類の全ての参照を見出すことを極めて容易にする。

所与の型７１３を有する同じアイテム７１４、を参照するアイテムのリスト７１２に対する記述サポート７１１は次のようにすればよい：

４つのタイルを有するピクチャの例では、次のようにすることが可能である：

ボックス「ＳｈａｒｅｄＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ（共有アイテム型参照ボックス）」の本設計は、特定のアイテムをポイントする特定の型の全ての参照を見出すことをより容易にする。これは、ボックス「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ」と対照的である。しかし、トラック参照のために定義される「ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ（参照＿型）」のほとんどは双方向性でないので、ボックス「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘ」は、他のアイテムに対してこの参照型を有する全ノードへシグナリングするために、一部の単方向性の参照型と共には使えないことがある。上記に換えて、直接参照か、または逆参照かを示すために、「ＳｉｎｇｌｅＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅ」中にフラグを設け、これにより、新規のＳｈａｒｅｄＩｔｅｍＴｙｐｅＲｅｆｅｒｅｎｃｅＢｏｘに対する必要性を軽減することができる。

上記を考慮して、情報アイテムをタイル化情報と関連付けるとよい。ここで、このタイル化情報の記述を提示することとする。

例えば、各タイルは、拡張型「ＩｔｅｍＩｎｆｏＥｎｔｒｙ」６０１の「ｉｒｅｆ＿ｐａｒａｍｅｔｅｒ」６０５などのタイル記述子を使って記述することができる。或る特定の記述子は次のようにできよう：

諸実施形態によれば、格納対象の１つ以上のピクチャに適用するために、記述子をタイルのグリッドに対し用いることが可能である。

かかる記述子は次のようにすればよい：

この記述子「ＴｉｌｅＩｎｆｏＤａｔａＩｔｅｍ（タイル情報データアイテム）」は、（規則的または不規則な）タイル化グリッドを記述することを可能にする。グリッドは、左最上部から始まり行から行へと記述される。

この記述子は、型「ｔｉｌｅ」のアイテムとして格納する必要がある。別のアイテムがこのアイテムを参照する場合、そのアイテムは、この記述への型「ｔｉｌｅ」の参照を用いなければならず、該アイテムは、パラメータ「ｉｒｅｆ＿ｐａｒａｍｅｔｅｒ」を指定する必要があり、その値は、該記述子によって定義された、グリッド中のセルの０ベースのインデックスであって、０は最上部左のアイテムであり、１はセル０の直接右のセルでありそのように続く。

本記述子において、
－ 「ｖｅｒｓｉｏｎ」は、ＴｉｌｅＩｎｆｏＤａｔａＩｔｅｍに対するシンタックスのバージョンを示す。値０だけが定義される。
－ 「ｒｅｇｕｌａｒ＿ｓｐａｃｉｎｇ（規則的＿間隔）」は、グリッド中の全てのタイルが同じ幅且つ同じ高さを有するかどうかを示す。
－ 「ｒｅｆｅｒｅｎｃｅ＿ｗｉｄｔｈ（参照＿幅）、ｒｅｆｅｒｅｎｃｅ＿ｈｅｉｇｈｔ（参照＿高さ）」は、グリッドが中に表示されるユニットを示す。これらのユニットは、このアイテムを参照する画像の画素の解像レベルと一致してもしなくてもよい。グリッドが規則的な場合、「ｒｅｆｅｒｅｎｃｅ＿ｗｉｄｔｈ」（それぞれの「ｒｅｆｅｒｅｎｃｅ＿ｈｅｉｇｈｔ」）は、「ｎｂ＿ｃｅｌｌ＿ｈｏｒｉｚ」（それぞれの「ｎｂ＿ｃｅｌｌ＿ｖｅｒｔ」）の倍数でなければならない。
－ 「ｃｅｌｌ＿ｗｉｄｔｈ（セル＿幅）」は、非規則的タイル中のグリッドの左から始まる水平区分を示す。
－ 「ｃｅｌｌ＿ｈｅｉｇｈｔ（セル＿高さ）」は、非規則的タイル中のグリッドの上から始まる垂直区分を示す。

上記のアプローチは、全タイルに対するタイル化情報を共有することを可能にする。

さらに、同じタイル化を共有している複数ピクチャがある場合、タイルのグリッド中のセルを単に参照することによって、さらに多くの記述さえ共有することが可能である。

このタイル化構成は、タイル情報アイテム群の間で（参照によって）共有されているメディアデータボックスまたは専用のボックス中に配置することができる。

上記の記述子は、これらがより大きな画像中のサブ画像（群）に対する空間位置およびサイズだけを提供するという意味において、純粋の空間記述子である。例えば、画像収集または画像合成を用いる一部の使用例において、典型的には画像がオーバーラップしている場合、画像を記述するために、空間的配置は十分ではない。これが、上記のＴｉｌｅＩｎｆｏＤａｔａＢｌｏｃｋ（タイル情報データブロック）記述子の１つの限界である。画像が何であれ、すなわちタイルであれまたは独立した／完全な画像であれ、画像の合成を可能にするためには、一方で画像の位置およびサイズ（空間的関係）を、他方でそのピクチャに対する表示情報（色、クロッピング…）を包含する記述子を定義するのが有用であり得る。例えば、サブ画像を表示のため或る色空間から別の色空間に変換するための色情報を備えるとよい。この種の情報は、ＩＳＯＢＭＦＦのＣｏｌｏｒＩｎｆｏｒｍａｔｉｏｎＢｏｘ（色情報ボックス）の「ｃｏｌｒ」中で伝達することができる。技術的緻密性のためには、２つの異なる当該変換ピクチャを伝達するよりも、むしろ、単に適用する変換パラメータ群を備えることによって、異なる種類の表示に対応する同じデータを有する方が有用であろう。同様に、各ピクチャの符号化された幅および高さと異なり得る幅および高さを再定義するため、ＩＳＯＢＭＦＦパート１２中に定義されたＰｉｘｅｌＡｓｐｅｃｔＲａｔｉｏ（画素アスペクト比）ボックスの「ｐａｓｐ」のような画素のアスペクト比をこの記述子中に配置することができる。これは、画像の復号後の表示によって適用されるスケール比を示すことになろう。その後に、映像サンプルエントリ（例えば、「ｓｔｓｄ」ボックス）中に格納された符号化サイズ、および「ｐａｓｐ」ボックスから導出された表示のサイズを用いることになろう。表示のための別の可能な情報は、これもＩＳＯＢＭＦＦ中に定義されたクリーンアパーチュア情報ボックス「ｃｌａｐ」とすることができよう。規格ＳＭＰＴＥ２７４Ｍによれば、クリーンアパーチュアは、エリアの内側では、ピクチャ情報が、全てのエッジ過渡歪み（アナログからデジタルへの転換の後の画像の境界にあり得るリンギング効果）によって自覚可能に汚染されることのない或るエリアを定義する。表示のため有用なパラメータのこのリストは制限的でなく、サブ画像記述子の任意の他の記述メタデータボックス中に随意的なコンポーネントとして配置することができよう。これらのパラメータは、これらが既に該規格の一部なので、明示で記述することができ、画像クロッピング、サンプルアスペクト比修正、および色調整を示すための汎用ツールを提供する。残念ながら、これらの使用はメディアトラックのためだけに可能であって、「ｍｅｔａ」ボックスに依存する画像ファイルフォーマットには使えなかった。そこで、本発明者らは、クリーンアパーチュアまたはサンプルアスペクト比など他のプロパティと共に、画像アイテムの空間記述をサポートするために、例えば「ＳｉｍｐｌｅＩｍａｇｅＭｅｔａＤａｔａ（単純画像メタデータ）」と呼ばれる新規の記述子を提案する。これは、より大きな画像への合成を意図された、またはより大きな画像から逆抽出された、任意のサブ画像（タイルまたは独立的画像）に適用される：

または、（例えばｅｘｔｒａ＿ｂｏｘｅｓ（追加＿ボックス）を介して）表示処理を助力するための拡張パラメータを検討するときのその別形は：

上記シンタックスのＩｍａｇｅＳｐａｔｉａｌＲｅｌａｔｉｏｎＢｏｘ（画像空間関係ボックス）は、以下で説明するようにＴｉｌｅＩｎｆｏＤａｔａＢｌｏｃｋ（タイル情報データブロック）の拡張型である。検討対象の別の有用なパラメータは、画像を層として構成する可能性である。そこで、本発明者らはこの層化された構成中の画像に関連付けられたレベルを示すためパラメータを挿入することを提案する。これは、一般に、画像がオーバーラップするときに有用である。これは、例えば層情報表示と合わせ「ｌａｙｅｒ」と名付ければよい。かかる記述に対する例示のシンタックスを提示する：
定義：
ボックス型： 「ｉｓｒｅ」
コンテナ： 単純画像メタデータアイテム（「ｉｓｒｅ」）
強制： 否
数： アイテムごとにゼロまたは１
シンタックス：

関連する意味定義：
ｈｏｒｉｚｏｎｔａｌ＿ｄｉｓｐｌａｙ＿ｏｆｆｓｅｔ（水平方向＿表示＿オフセット）は、画像の水平オフセットを指定する。
ｖｅｒｔｉｃａｌ＿ｄｉｓｐｌａｙ＿ｏｆｆｓｅｔ（垂直方向＿表示＿オフセット）は、画像の垂直オフセットを指定する。
ｄｉｓｐｌａｙ＿ｗｉｄｔｈ（表示＿幅）は、画像の幅を指定する。
ｄｉｓｐｌａｙ＿ｈｅｉｇｈｔ（表示＿高さ）は、画像の高さを指定する。
ｌａｙｅｒ（層）は、画像の前から後ろへの順序付けを指定する；低位の番号の画像ほど視聴者に近い。０は通常値であり、－１は層０の前に在ってそのように続く

この新規の「ｉｓｒｅ」ボックス型は、画像収集体中の一画像の他の画像との相対位置を記述する機能を与える。これは、通常、メディアファイルのムービーまたはトラックヘッダボックス中に存在する変換マトリックスの機能性のサブセットを提供する。ＩｍａｇｅＳｐａｔｉａｌＲｅｌａｔｉｏｎＢｏｘ中の座標は、プログラム作者の意図した収集体の表示サイズを与える平方グリッド上で表現され、これらのユニットは、画像の符号化サイズと一致してもしなくてもよい。意図された表示サイズは、
－ 水平方向に： 全ての「ｉｓｒｅ」ボックスに対し（ｈｏｒｉｚｏｎｔａｌ＿ｄｉｓｐｌａｙ＿ｏｆｆｓｅｔ＋ｄｉｓｐｌａｙ＿ｗｉｄｔｈ（水平＿表示＿オフセット＋表示＿幅））の最大値
－ 垂直方向に： 全ての「ｉｓｒｅ」ボックスに対し（ｖｅｒｔｉｃａｌ＿ｄｉｓｐｌａｙ＿ｏｆｆｓｅｔ＋ｄｉｓｐｌａｙ＿ｈｅｉｇｈｔ）（垂直＿表示＿オフセット＋表示＿高さ））の最大値
によって定義される。

一部の画像が関連付けられたいかなる「ｉｓｒｅ」を有せず、一方、そのファイル中の他の画像は関連付けられた「ｉｓｒｅ」を有する場合、いかなる「ｉｓｒｅ」もないデフォルト画像は、あたかも、それらの水平および垂直方向オフセットが０であり、それらの表示サイズが意図された表示サイズであってそれらの層が０であるかのように取り扱うものとする。

このＩｍａｇｅＳｐａｔｉａｌＲｅｌａｔｉｏｎＢｏｘは、一切のクロッピングまたはサンプルアスペクト比が画像群に適用された後の画像の相対的空間位置を示す。これは、「ｉｓｒｅ」が、ＳｉｍｐｌｅＩｍａｇｅＭｅｔａＤａｔａ中の「ｐａｓｐ」などと組み合せられたとき、画像が復号され、「ｐａｓｐ」、「ｃｌａｐ」、「ｃｏｌｒ」が存在すれば適用され、次いで、画像は、該「ｉｓｒｅ」ボックス中で宣言されたオフセットおよびサイズに移動されてスケールされる。

この新規の記述子は、画像を表現するアイテム情報と該記述子を表現するアイテム情報との間の関連性を定義することによって画像（タイルまたは単一画像）の記述として用いることができる（ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ定義に対する型「ｓｉｍｄ」を与えれば、ｍｐ４パーサーに対し、それが現在処理しているメタデータの種類を容易に識別するため、任意の予約４文字コードが受け入れ可能となろう。この関連付けは、ＩｔｅｍＲｅｆｅｒｅｒｅｎｃｅＢｏｘを使い、「空間的画像の関係」を示す新規の参照型「ｓｉｍｒ」を使ってなされる。下記の例示の記述は、合成自体が関連付けられたアイテムを有さない場合の、４つの画像の合成の例を示す。各画像アイテムは、型「ｓｉｍｒ」のアイテム参照を介してＳｉｍｐｌｅＩｍａｇｅＭｅｔａＤａｔａアイテムに関連付けられており、専用の「ｈｖｃＣ」アイテム中のＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ情報を共有する。

上記のデータの編成は、一例として提示されている。画像およびメタデータは、例えば、画像プラスそのメタデータを単一のバイト範囲としてアドレス可能にするために、メタデータボックス中に組み合わせることができよう。この記述を受信したとき、パーサーは、「ｓｉｍｄ」アイテム中の情報を構文解析することによって、サブ画像が全体ピクチャからクロップされたものかどうか、または逆に、全体ピクチャがサブ画像からの合成なのかどうかを通知される。クロップの場合、全体ピクチャアイテムとクロップされた画像とは、下記の例におけるように、同じデータ範囲および同じデコーダ設定情報を共有することになろう。このとき、サブ画像は、位置なしに、この場合は「ｉｓｒｅ」なしに、「ｃｌａｐ」情報だけを有する「ｓｉｍｄ」アイテムに関連付けられることになろう。

合成の場合：この場合は、全体ピクチャはアイテム、「ｉｓｒｅ」情報だけを包含する「ｓｉｍｄ」アイテムに関連付けられ、サブ画像は、全体画像中のその位置を反映する「ｓｉｍｄ」アイテムに関連付けられることになろう。

下記の例は、４つの画像がより大きな画像に合成される場合を示す。合成されたものを含め全ての画像は、提案された記述子を用い、再生可能アイテムとして可視化される。

この別の例は、全体ピクチャが実際はタイル化ＨＥＶＣピクチャ（４つのタイル）である場合を示す。

使用例の如何によって、例えば、全ての画像に同じクロッピングを適用する場合などには、いくつかの画像アイテムに同じメタデータを共有させることも可能であろう。また、例えば、画像の間でクロッピングが共有されるが、空間情報はされない場合などに、一画像アイテムが、相異なるＳｉｍｐｌｅＩｍａｇｅＭｅｔａＤａｔａへの複数の「ｓｉｍｒ」参照を有することも可能である。

（図６中に示されるように）ＩｔｅｍＩｎｆｏＥｎｔｒｙの新規バージョンに対する別の実施形態は、情報アイテムエントリおよび参照ごとに、１より多いパラメータ（６０５）を定義することである。図６の実施形態において、ｉｒｅｆ＿ｐａｒａｍｅｔｅｒは、タイルインデックスがタイル化グリッド中のセルを参照する場合に有用な４バイトコードである。但し、より豊かな記述を有し、（ｍｄａｔボックス中の）データを使うよりむしろアイテム情報エントリ自体の中にリンクされた記述の組み込みを可能にするためには、以下の拡張が有用であり得る：

上記の拡張において、
－ ｉｔｅｍ＿ｉｒｅｆ＿ｐａｒａｍｅｔｅｒ＿ｃｏｕｎｔはパラメータが付与される対象の参照型の数を指定する。これは、図６中のアイテム６０５とは対照的に、変更はされない。
－ ｉｒｅｆ＿ｔｙｐｅは、「ｉｒｅｆ」ボックス中に示され、当アイテムにパラメータが適用される参照型を指定する。これは、図６中のアイテム６０５とは対照的に、変更はされない。
－ 上記中のｐａｒａｍｅｔｅｒは、新規ボックスＩｔｅｍＲｅｆｅｒｅｎｃｅＰａｒａｍｅｔｅｒＥｎｔｒｙ（アイテム参照パラメータエントリ）を介して拡張手段を提供するので、ｉｒｅｆ＿ｐａｒａｍｅｔｅｒ（図６中のアイテム６０５）とは異なる。（タイル化タイルインデックスに対する構成の中のＴｉｌｅＩｎｄｅｘＩｔｅｍＲｅｆｅｒｅｎｃｅＰａｒａｍｅｔｅｒＥｎｔｒｙ（タイルインデックスアイテム参照パラメータエントリ）によって上記でなされたように）この新規ボックスを特殊化することによって、カプセル化モジュールおよび構文解析モジュールがこの特殊化ボックスの構造を知っていることを前提として、任意の種類の追加のメタデータを情報アイテムエントリと関連付けることができる。これは、ＩｔｅｍＲｅｆｅｒｅｎｃｅＰａｒａｍｅｔｅｒＥｎｔｒｙの標準型によって、または、構築によりもしくはネゴシエーションステップで、パラメータエントリの構造体を設けることによって、成就することが可能である。このパラメータの意味定義は、型ｉｒｅｆ＿ｔｙｐｅを有するアイテムの意味定義によって与えられる。

以降に、４タイルを有するピクチャを記述する情報アイテムに対する例示的な記述メタデータおよび全体ピクチャのＥＸＩＦメタデータを提示する。

下記に示すように、従来技術では、いかなる対応する記述の提示もなしに、タイルピクチャが情報アイテムとしてリストされていた。さらに、「ｈｖｃＣ」型として表されるセットアップ情報はアイテムとして記述されていなかった。これは、全てのタイルピクチャおよび全体ピクチャに適用されるＨＥＶＣパラメータおよびＳＥＩメッセージに関する共通データを要素分解することを可能にする。

ＩｔｅｍＩｎｆｏＥｎｔｒｙボックス（６０１）のバージョン３（図６の６０２、６０３を参照）による拡張を用いる諸実施形態によれば、タイルピクチャ情報が、タイル化構成の部分への関連参照と共にリストされており、該情報もまた情報アイテム（ＩＤ＝８）として記述されている。

図８は、本発明の諸実施形態の実装のコンテキストを示す。最初に、例えば、ステップ８００ａの過程で音声、ステップ８００ｂの過程で映像、および８００ｃの過程で１つ以上のピクチャなど、各種のメディアが収録される。各メディアはそれぞれステップ８０１ａ、８０１ｂ、および８０１ｃの過程で圧縮される。これらの圧縮ステップの過程で、基本ストリーム８０２ａ、８０２ｂ、および８０２ｃが生成される。次の、適用レベル（グラフィカルユーザインターフェースからのユーザの選択、マルチメディア生成システムの設定など）で、これら全ての基本ストリームを融合すべきかどうかを決めるためにカプセル化モードが選択される。「融合」モードが有効化された場合（判断８０３が「はい」）、ステップ８０６ｃの過程で、前述のように、音声、映像、および静止画像に対するデータが同じファイル中にカプセル化される。「融合」モードが有効化されない場合（判断８０３が「いいえ」）、ステップ８０６ａおよび８０６ｂの過程で、連続的にまたは並行して２つのカプセル化ファイルが生成され、これにより、それぞれ、ステップ８０７ａの過程で同期化時間のメディアデータに対する１つのファイル、および静止画像だけを有する追加のファイル９０７ｂの生成がもたらされる。前述のようにタイル記述および対象の領域の特徴を設定するため、ステップ８０６ａの過程でＩＳＯＢＭＦＦ規格に従って音声および映像の基本ストリームがカプセル化され、ステップ８０６ｂの過程で静止画像がカプセル化される。最後に、メディア表現８０７が得られ、これは、ストリーミングのための用意をするべくＤＡＳＨジェネレータに供給されるか（ステップ８２０ａ）、またはメモリ中に格納されるか（ステップ８２０ｂ）、または表示ユニット上でレンダリングされるか（ステップ８２０ｃ）、または、全体的に、もしくは記述メタデータを構文解析して一部の部分（タイルなど）を抽出した後、遠隔のエンティティに送信されるか（ステップ８２０ｄ）することができる。

諸実施形態の前の説明では、例えば、（静止画像ファイルフォーマットスペシフィケーションの最新のバージョン中ではＩＳＯＢＭＦＦＭｅｔａＤａｔａ（ＩＳＯＢＭＦＦメタデータ）とも呼ばれる）ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ（「ｓｉｍｄ」）ボックスなどの記述メタデータが完熟したアイテムとして説明されていることに留意する。また、追加の記述的または規範的メタデータも、ＩＳＯ／ＩＥＣ２３００８－１２：２０１３第一エディション、「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ－ＭＰＥＧ ｓｙｓｔｅｍｓ ｔｅｃｈｎｏｌｏｇｉｅｓ－Ｐａｒｔ １２：Ｉｍａｇｅ Ｆｉｌｅ Ｆｏｒｍａｔ（情報技術－ＭＰＧＥシステム技術－パート１２画像ファイルフォーマット）」ＭＰＥＧ１１０、ストラスブール２０１４年１０月、の委員会調査ドラフト文献ｗ１４８７８中に記載された静止画像ファイルフォーマットスペシフィケーションによって定義されている。記述的または規範的メタデータの例には、ＣｌｅａｎＡｐｅｒｔｕｒｅＢｏｘ（「ｃｌａｐ」）、ＩｍａｇｅＲｏｔａｔｉｏｎ（画像回転）（「ｉｒｏｔ」）、ＥｘｉｆＤａｔａＢｌｏｃｋ（エグジフデータブロック）（「ｅｘｉｆ」）、またはＩｍａｇｅＯｖｅｒｌａｙ（画像オーバーレイ）（「ｉｏｖｌ」）がある。さらに一般的に言えば、記述的メタデータは、画像またはサブ画像（例えばエグジフメタデータ）のようなアイテムに対する追加の情報または記述を提供するメタデータであり、規範的メタデータは、アイテムに適用されるオペレーションまたは変換（例えば、回転、クロップ、または変換オペレータを形成するいくつかのアイテムの組み合せ）である。

しかしながら、かかる記述的または規範的メタデータを、完備されたアイテムとしてスペシフィケーション中の格納しておくのは、極めて面倒と思われ、これらは単なる疑似アイテムであって、記述的または規範的メタデータは符号化データと共にｍｄａｔボックス（１１０）中に格納する必要があり、ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（ｉｌｏｃ）（１０９）、ｉｔｅｍＩｎｆｏＢｏｘ（ｉｉｎｆ）、およびｉｔｅｍＰｒｏｔｅｃｔｉｏｎＢｏｘ（アイテム保護ボックス）（ｉｐｒｏ）中へのエントリを定義することが必要である。
このためのｉｌｏｃ、ｉｉｎｆ、およびｉｐｒｏへのこれらのエントリの必要は、相当なオーバーヘッドである。例えば、ｉｔｅｍＩｎｆｏＢｏｘ中へのエントリは、最小１２バイトのヘッダを有するボックス全体の使用を必要とし、加えて、ｉｔｅｍＩｎｆｏＢｏｘ（ｉｉｎｆ）中へのエントリごとに合計１５バイトの追加コストに対し、ｉｔｅｍ＿ｐｒｏｔｅｃｔｉｏｎ＿ｉｎｄｅｘ（アイテム＿保護＿インデックス）（１６ビット）プラス空のｉｔｅｍ＿ｎａｍｅ（アイテム＿名称）（８ビット）を定義しなければならない。また、ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（ｉｌｏｃ）中へのエントリも、良好な場合（ｂａｓｅ＿ｏｆｆｓｅｔ＿ｓｉｚｅ＝ｏｆｆｓｅｔ＿ｓｉｚｅ＝ｌｅｎｇｔｈ＿ｓｉｚｅ＝１、１エクステント）で最小９バイトを必要とする。実際上は、ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘエントリは、ｂａｓｅ＿ｏｆｆｓｅｔ＿ｓｉｚｅ＝ｏｆｆｓｅｔ＿ｓｉｚｅ＝ｌｅｎｇｔｈ＿ｓｉｚｅ＝２または４として、すなわち１２または１８バイトの追加コストで用いられる。さらに、このメタデータは、通常は小さく、他のアイテムの効率的な読み取りを可能にする。これらを専用のアイテムとして格納するのは、ファイル構文解析、特にファイル（例えば、ＨＴＴＰ要求の増加）の部分的取得を面倒にする可能性がある。

別の実施形態において、全ての記述的および規範的メタデータは、ｍｄａｔボックス（１１０）でなく、むしろ他のボックスの一部として、ｍｅｔａボックス（１００）中に格納が可能な組み込みアイテムとして定義することができ、しかして、ｉｔｅｍＩｎｆｏＢｏｘおよびｉｔｅｍＬｏｃａｔｉｏｎＢｏｘエントリを定義する追加コストを回避することが可能である。

記述的および規範的メタデータをｍｅｔａボックス中に格納するために、「ＶｉｒｔｕａｌＩｔｅｍＢｏｘ（仮想アイテムｂｏｘ）」と呼ばれる仮想アイテムボックスが定義される。この実施形態によれば、全ての記述的および規範的メタデータボックスは、この仮想アイテムクラスから受け継がれる。

仮想アイテムは、ｉｔｅｍ＿ＩＤと、ボックスのセットと共に該ＩＤに割り当てられたｉｔｅｍ＿ｔｙｐｅとを有する。仮想アイテムは、他のアイテムに関連付けられることになるメタデータを記述するため一般に使われる追加データである。例えば、該仮想アイテムは、或るアイテム（画像またはサブ画像）を識別するｉｔｅｍＩｎｆｏＢｏｘのエントリと、そのアイテムに適用されることになるオペレーションまたは変換とを関連付けることを可能にする。通常、この関連付けは、該画像のｉｔｅｍ＿ＩＤから、メタデータオペレーションまたは変換記述ボックスのｉｔｅｍ＿ＩＤへの、ｉｔｅｍＲｅｆｅｒｅｎｃｅＢｏｘ中への型「ｓｉｍｒ」のエントリを定義することによって記述することができる。仮想アイテムは、アイテム参照ボックスおよび一次アイテムボックス中でだけ参照することが可能で、一切の他のボックス（例えば、ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（ｉｌｏｃ）、ｉｔｅｍＩｎｆｏＢｏｘ（ｉｉｎｆ）、ｉｔｅｍＰｒｏｔｅｃｔｉｏｎＢｏｘ（ｉｐｒｏ））において宣言または参照されてはならない。この「ＶｉｒｔｕａｌＩｔｅｍＢｏｘ」は次のように定義される：

上記のパラメータに対する意味定義は以下による：
ｉｔｅｍ＿ＩＤ：このアイテムのＩＤ（または識別子）。同じｉｔｅｍ＿ＩＤ値を使ってｉｉｎｆ、ｉｌｏｃ、またはｉｐｒｏ中にエントリを有することはルール違反である。ｉｔｅｍ＿ｔｙｐｅは３２ビット値で、通常４つの印刷可能文字であり、「ｍｉｍｅ」などの定義された有効なアイテム型インジケータである。

随意的に、或る別形において、「ＶｉｒｔｕａｌＩｔｅｍＢｏｘ」は、「ｄｅｓｃｒｉｐｔｏｒ＿ｆａｍｉｌｙ（記述子ファミリ）」と呼ばれる追加のパラメータを含むことが可能である。該記述子ファミリは、メタデータボックスが、記述的なメタデータか、または規範的なメタデータかどうかを示す。或る別形において、記述ファミリは、所定の値のリストから、メタデータボックスの型を示す。例えば、ｔｒａｎｓｆｏ＿ｏｐｅｒａｔｏｒ（変換＿オペレータ）、ｃｏｍｐｏｓｅｄ＿ｉｍａｇｅ（合成＿画像）、ｄｅｓｃｒｉｐｔｉｖｅ＿ｍｅｔａｄａｔａ（記述＿メタデータ）等々。

この仮想アイテムボックスを受け継ぐことにより、全ての記述的および規範的メタデータボックスは、ｉｔｅｍＩｎｆｏＢｏｘ（ｉｉｎｆ）およびｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（ｉｌｏｃ）中に関連するエントリを定義する必要なしに、ｍｅｔａボックス中に格納することができ、それでもこれらは、アイテム参照ボックスによってアドレス可能である利点をまだ保持する。

この実施形態によれば、ＩｍａｇｅＯｖｅｒｌａｙ（ｉｏｖｌ）、ＳｕｂＳａｍｐｌｅＩｔｅｍＤａｔａ（サブサンプルアイテムデータ）（ｓｕｂｓ）、ＡｕｘｉｌｉａｒｙＣｏｎｆｉｇｕｒａｔｉｏｎ（補助構成）（ａｕｘＣ）、ＥｘｉｆＤａｔａＢｌｏｃｋ（ｅｘｉｆ）、ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ（ｓｉｍｄ）および導出画像アイテムは、仮想アイテムクラスから受け継がれている。

さらにこの実施形態によれば、「ｄｉｍｇ」と呼ばれる単一の汎用アイテム型が、型「ｓｉｍｄ」のアイテムへの型「ｓｉｍｒ」のアイテム参照によって導入される。このアプローチは、適切な場合、プロパティの再利用を可能にし、アイテムおよびアイテム参照の数を低減する。ＩｍａｇｅＲｏｔａｔｉｏｎＢｏｘが、ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ（ｓｉｍｄ）中に加えられる。「ｓｉｍｒ」参照型は、画像記述メタデータへの直接アクセスを提供するように、画像アイテムから「ｓｉｍｄ」アイテムに向けたリンクを定義する。

さらに、ＩｍａｇｅＯｖｅｒｌａｙ（ｉｏｖｌ）メタデータボックスは、該ボックスが参照順序にもはや依存しないように、次のように再設計される。

合成されるアイテムを明確に識別するために、明示のｉｔｅｍ＿ＩＤがループ中の各エントリに対して加えられる。

別の実施形態において、ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ（ｓｉｍｄ）の中に含まれる全てのボックスは、仮想アイテムボックスから受け継がれた独立メタデータボックスとして定義される。

別の実施形態において、単純画像回転は、以下のように、画像メタデータ記述子ＳｉｍｐｌｅＩｍａｇｅＭｅｔａｄａｔａ（「ｓｉｍｄ」）ボックス（静止画像ファイルフォーマットスペシフィケーションの最新バージョンではＩＳＯＢＭＦＦＭｅｔａＤａｔａとも呼ばれる）中に直接回転オペレーションを組み込むことによって宣言することが可能である：

回転ボックスは、「ｉｒｏｔ」アイテム（１２バイト）よりわずかに大きいが、このアプローチを用いる利益は、派生アイテムのカスケードに換えて１つの「ｓｉｍｄ」が必要なだけなので、回転およびＣｌｅａｎＡｐｐｅｒｔｕｒｅなど、変換を組み合せる場合に明らかである。

かかる場合において、（前述の）汎用導出アイテム「ｄｉｍｇ」が、画像アイテムおよびメタデータ記述の両方を参照するために使用可能である。かかるアイテムは、このとき、一次アイテムとしてＰｒｉｍａｒｙＩｔｅｍＢｏｘ（一次アイテムボックス）（「ｐｉｔｍ」）中にリストすることができよう。

このアプローチの別の利益は、プログラム作者が、回転されるアイテムだけが表示されるのを望んでいることを明瞭に示せることである。

以下の段落では、前述した実施形態の代替案を提案する。この代替案は、どのように変換（または「効果」）をＩＳＯ静止画像ファイルフォーマット中の画像に適用できるかに関し、有利に簡単である。具体的には、この代替実施形態を使って次の課題が解決される：－ 数多くのアイテム参照、
－ 効果をカスケードする際のアイテムの数の増加、および
－ アイテムの所与のセット、すなわち、対象の領域のような画像または画像の部分のセット、に対する効果の相互化の不可能性。

アイテムのいろいろなエクステント（すなわちデータ部分中のバイトのオフセット）として効果を相互化することが提案されている既存のソリューション。さらに詳しくは、エクステントとは、導出された画像がｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（「ｉｌｏｃ」）中にエクステントのリストとして記述されることになり、各エクステントはデータ部分（「ｍｄａｔ」）の断片を識別し、各断片が１つ以上の記述的もしは規範的なまたは変換メタデータに対応することを意味する。

しかしながら、このソリューションにはいくつかの短所が内在する：
－ カプセル化画像ファイルのオーサリングは相当に面倒であり、１つの導出画像アイテム中の１つの効果に手を加えることは、全ての導出画像が同じエクステントを共有しているかどうかをチェックするためそれらを検査し、潜在的にその一部を書き換えるためにそれらを検査することを意味する。
－ 画像ファイルリーダーが、変換／効果の連鎖が前記ファイル中の相異なるアイテムに対し同じかどうかを解明する必要がある（直接のシグナリングはない）ことになるので、構文解析もまた非常に簡単にはいかない。
－ 各変換／効果に対し、適用対象の変換／効果の連鎖中の変換／効果と共に新規変換／効果が連続的に格納されているのでなければ、常に、ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘ（「ｉｌｏｃ」）中に新規のエクステントが必要なことになる。さらに、効果の組み合せまたはカスケード化は、データ部分中の連続的なエクステント上に格納されていない場合、コスト高になり得る。

さらに、これらのソリューションは、効果の型（今までのところ、効果の型はｉｔｅｍ＿ｔｙｐｅによって与えられていた）を判断するために、効果を格納するためのボックスの生成を意味する実装ストレージを必要とした。より簡明なソリューションは、効果に対する新規ボックスを定義することによって、アイテムから分離して効果を定義することであり、いかなる追加コストもなしに、アイテムと効果との間に直接のマッピングを有することである。

本代替実施形態は、ファイルフォーマット中に明瞭な分離を有することによる効果の取り扱いの単純化を提案する：
－ 記述メタデータ（上記で提案されたような「ｉｎｉｔ」もしくは「ｓｉｍｒ」参照型、また記述メタデータを表す任意の参照型）にリンクされた標準的アイテム（画像または画像の部分）（例えば、ｈｖｃ１、…）；
－ 「導出画像」アイテムからソースアイテムへの「ｄｉｍｇ」アイテム参照を介して識別される１つ以上のソースアイテム（画像または画像の部分）に適用される効果（または変換）の収集体である、「導出画像」；、および
－ いくつかの相異なる効果の収集体を含む、変換／効果を表現する構造体。

この代替実施形態の利点は、
－ 効果の再利用性：１回だけ宣言され、潜在的には複数回参照される、
－ 効果の収集体を定義することによるよりコンパクトな記述（以下でさらに述べる）、－ ｉｔｅｍＬｏｃａｔｉｏｎＢｏｘの新規エクステントが不必要なことを含め、全体的読みやすさ、および
－ アイテム参照の数を少なく保つこと、
である。

この代替実施形態によれば、新規の単一の導出アイテムは、アイテム型「ｄｉｍｇ」を使って定義される。この単一の導出アイテムは、以下の構文によって具体的に表現される：

上記構文のｎｂ＿ｅｆｆｅｃｔｓは、導出画像を合成するために、ソース画像に適用されることになる効果の数を表し、ｅｆｆｅｃｔ＿ｉｄは適用される効果のカプセル化ファイル中の一意的識別子である。効果は、効果のリストに出現するのとは逆の順序で適用される。

「ＤｅｒｉｖｅｄＩｍａｇｅ（導出画像）」と名付けられた導出画像または変換アイテムは、例えば、ソース画像をユーザまたは表示画面に提示する前に、それに適用されることになる効果のセットとして画像を定義する。ソース画像は、導出されたアイテムからソース画像への型「ｄｉｍｇ」（または任意の予約された参照型）のアイテム参照によって識別される。ソース画像それ自体は、ＩＳＯ静止画像ファイルフォーマットスペシフィケーション中に定義された任意の画像アイテム（画像または画像の部分、画像オーバーレイ、導出画像）であってよい。同じアイテムからの「ｄｉｍｇ」アイテム参照は１を超えてはならない（但し、このアイテムが様々な合成のため何回も再利用される場合は、同じアイテムに対し複数であってもよい）。

導出アイテムは、ファイルのデータ部分に格納される。

カプセル化ファイルを編集する場合、例えば、画像ファイルから効果を除去する場合、この効果への全ての参照を諸導出画像から除去する必要がある。

効果は、ＤｅｒｉｖｅｄＩｍａｇｅアイテムを介して、画像、画像の部分、合成画像、または導出画像に適用することが可能である。各効果は、以下に示すＢａｓｅＥｆｆｅｃｔＢｏｘ（ベース効果ボックス）構造体から導出するボックスによって記述される。

上記の意味定義は以下による：
ｅｆｆｅｃｔ＿ｔｙｐｅは、このクラスから導出する効果のボックス型で、このボックスの種類を識別する一意的な４文字コードである。
ｅｆｆｅｃｔ＿ｉｄは、所与の効果または変換に対する一意的識別子である。この識別子は、「ｍｅｔａ」ボックス内で一意的でなければならない。
ｎｂ＿ｂｉｔｓ＿ｅｆｆｅｃｔは、バージョン値から導出され、ｅｆｆｅｃｔ＿ｉｄを表すために使われるビットの数を示す。

諸効果は、「ｍｅｔａ」ボックス中に包含される随意的なＥｆｆｅｃｔＤｅｃｌａｒａｔｉｏｎＢｏｘ（効果宣言ボックス）中で宣言すればよい。

ボックス型： 「ｅｆｆｄ」
コンテナ： ｍｅｔａ
強制： 否
数： ゼロまたは１

例えば以下のような効果を定義することが可能である（制限リストなし）：
－ 回転効果：この回転効果は、ソース画像を、９０度を単位として反時計周り方向に変換する。

ボックス型： 「ｅｒｏｔ」
コンテナ： ｅｆｆｄ
強制： 否
数： ゼロ以上

上記の意味定義は、
ａｎｇｌｅ＊９０：これは、度を単位とした（反時計周り方向の）角度を指定する
－ クリーンアパーチュア効果：クリーンアパーチュア効果は、ソース画像の可視部分を修飾する。

ボックス型： 「ｅｃｌａ」
コンテナ： ｅｆｆｄ
強制： 否
数： ゼロ以上

上記の意味定義は、
ｎｂ＿ｂｉｔｓ＿ｅｆｆｅｃｔは、親クラスＢａｓｅＥｆｆｅｃｔＢｏｘから導出され、ＣｌｅａｎＡｐｅｒｔｕｒｅＥｆｆｅｃｔＢｏｘ（クリーンアパーチュア効果ボックス）の各種フィールドを表すために使われるビットの数を示す。
ｈＳｐａｃｉｎｇ、ｖＳｐａｃｉｎｇ：画素の相対的幅および高さを定義する。
ｃｌｅａｎＡｐｅｒｔｕｒｅＷｉｄｔｈＮ、ｃｌｅａｎＡｐｅｒｔｕｒｅＷｉｄｔｈＤ：カウントされた画素中の画像の正確なクリーンアパーチュアの幅を定義する分数。
ｃｌｅａｎＡｐｅｒｔｕｒｅＨｅｉｇｈｔＮ、ｃｌｅａｎＡｐｅｒｔｕｒｅＨｅｉｇｈｔＤ：カウントされた画素中の画像の正確なクリーンアパーチュアの高さを定義する分数。
ｈｏｒｉｚＯｆｆＮ、ｈｏｒｉｚＯｆｆＤ：クリーンアパーチュアの中央マイナス（幅－１）／２の水平方向オフセット（通常は０）を定義する分数。
ｖｅｒｔＯｆｆＮ、ｖｅｒｔＯｆｆＤ：クリーンアパーチュアの中央マイナス（高さ－１）／２の垂直方向オフセット（通常は０）を定義する分数。

効果収集体：効果収集ボックスは、それを数個の画像に再利用し、これによりバイトに関して記述コストを低減するために、いくつかの効果のセットを単一の効果として定義することを可能にする。

ボックス型： 「ｅｃｏｌ」
コンテナ： ｅｆｆｄ
強制： 否
数： ゼロ以上

上記の意味定義は、
ｎｂ＿ｂｉｔｓ＿ｅｆｆｅｃｔは、親クラスＢａｓｅＥｆｆｅｃｔＢｏｘから導出され、ＥｆｆｅｃｔＣｏｌｌｅｃｔｉｏｎＢｏｘ（効果収集ボックス）の各種フィールドを表すために使われるビットの数を示す。
ａｐｐｌｙ＿ｅｆｆｅｃｔ＿ｉｄ：ソース画像に適用する効果のＩＤを示す。

効果収集体中の諸効果は、ＤｅｒｉｖｅｄＩｍａｇｅｄ（導出取得像）アイテム中の効果と同じ順序で適用される。例えば、各効果は、効果のリスト中のそれらの出現とは逆の順序で入力に適用されるものとする。

ＯｖｅｒｌａｙＥｆｆｅｃｔＢｏｘは、オーバーレイとしての画像の合成を宣言する。この特定の効果に対しては、得られた導出画像は、この効果が合成体の部分であるソース画像のリストを宣言しているので、どのソース画像への参照も有さない。

上記の意味定義は以下による：
ｎｂ＿ｂｉｔｓ＿ｅｆｆｅｃｔは、親クラスＢａｓｅＥｆｆｅｃｔＢｏｘから導出され、ＯｖｅｒｌａｙＥｆｆｅｃｔＢｏｘの各種フィールドを表すために使われるビットの数を示す。
ｆｉｌｌ＿ｒｅｑｕｉｒｅｄ（充填＿必要性）は、得られた合成画像中にバックラウンド値で充填すべき穴部があるかどうかを示す。
ｃａｎｖａｓ＿ｆｉｌｌ＿ｖａｌｕｅ（キャンバス＿充填＿値）は、いずれかの入力画像の画素が特定の画素の場所に配置されていない場合に、使われるチャネルごとの画素値を示す。入力画像が３つのチャネルより少ないチャネルを包含する場合、入力画像中に存在しないチャネルに対応するｃａｎｖａｓ＿ｆｉｌｌ＿ｖａｌｕｅのセマンティックスは指定解除される。

ｎｂ＿ｉｍａｇｅｓは、ｉｍａｇｅ＿ｉｔｅｍ＿ＩＤパラメータによって示されるそれらのｉｔｅｍ＿ＩＤによって各々が識別される、合成対象の画像の数を示す。

ｏｕｔｐｕｔ＿ｗｉｄｔｈ、ｏｕｔｐｕｔ＿ｈｅｉｇｈｔ：入力画像が組み入れられた出力画像の幅および高さをそれぞれ指定する。

出力画像のピクチャエリアはカンバスと言われる。

ｈｏｒｉｚｏｎｔａｌ＿ｏｆｆｓｅｔ、ｖｅｒｔｉｃａｌ＿ｏｆｆｓｅｔ：入力画像が配置される、カンバスの最上部左からのオフセットを指定する。負のオフセット値を有する画素位置は、出力画像中には含まれない。ｏｕｔｐｕｔ＿ｗｉｄｔｈ以上の大きさの水平方向画素位置は、出力画像中には含まれない。ｏｕｔｐｕｔ＿ｈｅｉｇｈｔ以上の大きさの垂直方向画素位置は、出力画像中には含まれない。

図９は、本発明の１つ以上の実施形態を実装するためのコンピューティングデバイス９００の簡略ブロック図である。コンピューティングデバイス９００は、マイクロコンピュータ、ワークステーション、または軽量携帯デバイスであってよい。コンピューティングデバイス９００は、以下に接続された通信バスを含む：
－ マイクロプロセッサなど、ＣＰＵと称される中央処理装置９０１：
－ 本発明の実施形態の方法の実行可能コード、ならびに、マニフェストを読み取り書き込みする方法を実装するべく、および／または映像を符号化するべく、および／または所与のファイルフォーマットの下でデータを読み取りまたは生成するべく、必要な変数およびパラメータを記録するようになされたレジスタを格納するためのＲＡＭと称されるランダムアクセスメモリ９０２であって、そのメモリ容量は、例えば拡張ポートに接続された随意的ＲＡＭによって拡大可能である：
－ 本発明の実施形態を実装するためのコンピュータプログラムを格納するための、ＲＯＭと称される読み取り専用メモリ９０３：
－ ネットワークインターフェース９０４は、通常、通信ネットワークに接続され、それを介して処理対象のデジタルデータが送信または受信される。ネットワークインターフェース９０４は単一のネットワークインターフェースとすることも、各種のネットワークインターフェース（例えば、有線およびワイヤレスインターフェース、または各種の有線またはワイヤレスインターフェース群）のセットで構成することも可能である。ＣＰＵ９０１中で実行されるソフトウェアアプリケーションの制御の下で、データが、送信のためネットワークインターフェースに書き込まれ、あるいは受信のためネットワークインターフェースから読み取られる；
－ ユーザからの入力を受信するためまたはユーザに情報を表示するためのユーザインターフェース９８０５；
－ ＨＤと称されるハードディスク９０６：
－ 映像ソースまたはディスプレイなどの外部デバイスとの間でデータを受信／送信するためのＩ／Ｏモジュール９０７。

実行可能コードは、読み取り専用メモリ９０３中、ハードディスク９０６上、または例えばディスクなどのリムーバブルデジタル媒体上のいずれかに格納すればよい。別形によれば、プログラムの実行可能コードは、実行される前に、ハードディスク９０６など、通信デバイス９００のストレージ手段の１つの中に格納すべく、ネットワークインターフェース９０４を介し、通信ネットワークを用いて受信することができる。

中央処理ユニット９０１は、本発明の実施形態によるプログラムまたはプログラム群の命令またはソフトウェアコードの部分の実行を制御および命令するようになされており、これら命令は、前述のストレージ手段の１つの中に格納される。電源投入後、ＣＰＵ９０１は、当該命令が、例えばプログラムＲＯＭ９０３またはハードディスク（ＨＤ：ｈａｒｄ－ｄｉｓｃ）９０６などからロードされた後、ソフトウェアアプリケーションに関する主ＲＡＭメモリ９０２からの命令を実行することができる。かかるソフトウェアアプリケーションは、ＣＰＵ９０１に実行されると、諸実施形態による方法のステップを遂行させる。

あるいは、本発明は、（例えば、特定用途向け集積回路またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）の形で）ハードウェア中に実装することができる。

本発明は、例えば、対象の特定の領域上にズームインするために、カメラ、スマートフォン、またはＴＶのためのリモートコントローラとして機能するタブレットのようなデバイス中に組み込むことが可能である。また、本発明は、特定の関心エリアを選択することによって、ＴＶ番組の個人的なブラウジング体験を持つために、同じデバイスで用いることもできる。ユーザによるこれらのデバイスによる別の利用は、他の接続されたデバイスと、自分の好みの映像のいくつかの選ばれたサブ部分を共有することである。また、監視カメラが本発明の生成部分をサポートしていることを前提として、監視の下に置かれている建物の特定の場所で発生したことをモニタするため、スマートフォンまたはタブレットにおいて本発明を使用することも可能である。

本発明を、諸図面および前述の記載の中で詳細に示し説明してきたが、かかる提示および説明は、例証または例示であって限定ではないと見なされるべきであり、本発明は開示された実施形態に限定はされない。請求された発明の実践において、当業者は、これら図面、開示、および添付の特許請求の範囲の学習から、開示された実施形態に対する他の別形を推測し、生成することが可能である。

特許請求の範囲中の、語「含む（ｃｏｍｐｒｉｓｉｎｇ）」は他の要素またはステップを除外するものでなく、不定冠詞「一または或る（ａまたはａｎ）」は複数を除外しない。
単一のプロセッサまたは他のユニットが、特許請求の範囲に記載のいくつかのアイテムの機能を遂行することが可能である。相異なる特徴が相互に異なる従属請求項に記載されているという単なる事実は、それらの特徴の組み合わせを有利に用いることができないことを示すものではない。特許請求の範囲中のいかなる参照符号も、本発明の範囲を限定していると解釈されるべきではない。

Claims (22)

1. 符号化ビットストリームが格納されたメディアデータ部とメタデータ部とを有する、ＩＳＯＢＭＦＦで定義されたファイルを生成する方法であって、
   １枚の画像あるいは１枚の画像のサブ画像を表す、前記メディアデータ部の部分を特定するための画像アイテム情報を取得するステップと、
   前記１枚の画像あるいはサブ画像の幅と高さに関するプロパティを有する画像プロパティを取得するステップと、
   前記画像アイテム情報および前記画像プロパティ、ならびに前記画像アイテム情報および前記画像プロパティに対応する前記１枚の画像の符号化ビットストリームを有するファイルを生成するステップとを有し、
   前記メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
   前記画像プロパティは、前記メタデータ部の所定のボックスに格納され、
   前記所定のボックスは、前記画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと前記画像プロパティとを関連付けるために用いられる、
   ことを特徴とする方法。
2. 前記画像プロパティは、
   前記１枚の画像あるいはサブ画像の位置、
   前記１枚の画像あるいはサブ画像のピクセルアスペクト比、および
   前記１枚の画像あるいはサブ画像の色情報、
   のうちの少なくともいずれかをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記画像プロパティは、
   前記１枚の画像あるいはサブ画像のクロッピングまたは回転の少なくともいずれかのプロパティを含むことを特徴とする請求項１または２に記載の方法。
4. 前記所定のボックスは、前記１枚の画像あるいはサブ画像の識別子を含むことを特徴とする請求項１から３のいずれか１項に記載の方法。
5. メディアデータ部とメタデータ部とを有するＩＳＯＢＭＦＦで定義されたファイルを処理することにより、画像を再生する方法であって、
   前記ファイルのメタデータ部から、１枚の画像あるいは１枚の画像のサブ画像を表す、前記メディアデータ部の部分を特定するための画像アイテム情報を取得するステップと、
   前記ファイルのメタデータ部から、前記１枚の画像あるいは前記サブ画像の幅と高さに関するプロパティを有する画像プロパティを取得するステップと、
   前記画像アイテム情報および前記画像プロパティに基づいて、前記１枚の画像を再生するステップとを有し、
   前記メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
   前記画像プロパティは、前記メタデータ部の所定のボックスに格納され、
   前記所定のボックスは、前記画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと前記画像プロパティとを関連付けるために用いられる、
   ことを特徴とする方法。
6. 前記画像プロパティは、
   前記１枚の画像あるいはサブ画像の位置、
   前記１枚の画像あるいはサブ画像のピクセルアスペクト比、および
   前記１枚の画像あるいはサブ画像の色情報、
   のうちの少なくともいずれかをさらに含むことを特徴とする請求項５に記載の方法。
7. 前記画像プロパティは、
   前記１枚の画像あるいはサブ画像のクロッピングまたは回転の少なくともいずれかのプロパティを含むことを特徴とする請求項５または６に記載の方法。
8. 前記所定のボックスは、前記１枚の画像あるいはサブ画像の識別子を含むことを特徴とする請求項５から６のいずれか１項に記載の方法。
9. 符号化ビットストリームが格納されたメディアデータ部とメタデータ部とを有する、ＩＳＯＢＭＦＦで定義されたファイルを生成する装置であって、
   １枚の画像あるいは１枚の画像のサブ画像を表す、前記メディアデータ部の部分を特定するための画像アイテム情報を取得する手段と、
   前記１枚の画像あるいはサブ画像の幅と高さに関するプロパティを有する画像プロパティを取得する手段と、
   前記画像アイテム情報および前記画像プロパティ、ならびに前記画像アイテム情報および前記画像プロパティに対応する前記１枚の画像の符号化ビットストリームを有するファイルを生成する手段とを有し、
   前記メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
   前記画像プロパティは、前記メタデータ部の所定のボックスに格納され、
   前記所定のボックスは、前記画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと前記画像プロパティとを関連付けるために用いられる、
   ことを特徴とする装置。
10. 前記画像プロパティは、
    前記１枚の画像あるいはサブ画像の位置、
    前記１枚の画像あるいはサブ画像のピクセルアスペクト比、および
    前記１枚の画像あるいはサブ画像の色情報、
    のうちの少なくともいずれかをさらに含むことを特徴とする請求項９に記載の装置。
11. 前記画像プロパティは、
    前記１枚の画像あるいはサブ画像のクロッピングまたは回転の少なくともいずれかのプロパティを含むことを特徴とする請求項９または１０に記載の装置。
12. 前記所定のボックスは、前記１枚の画像あるいはサブ画像の識別子を含むことを特徴とする請求項９から１１のいずれか１項に記載の装置。
13. 前記１枚の画像のサブ画像は、前記１枚の画像を分割して得られる複数のサブ画像であることを特徴とする請求項９から１２のいずれか１項に記載の装置。
14. 前記ファイルを格納するためのメモリを有することを特徴とする請求項９から１３のいずれか１項に記載の装置。
15. メディアデータ部とメタデータ部とを有するＩＳＯＢＭＦＦで定義されたファイルを処理することにより、画像を再生する装置であって、
    前記ファイルのメタデータ部から、１枚の画像あるいは１枚の画像のサブ画像を表す、前記メディアデータ部の部分を特定するための画像アイテム情報を取得する手段と、
    前記ファイルのメタデータ部から、前記１枚の画像あるいは前記サブ画像の幅と高さに関するプロパティを有する画像プロパティを取得する手段と、
    前記画像アイテム情報および前記画像プロパティに基づいて、前記１枚の画像を再生する手段とを有し、
    前記メタデータ部はＩＳＯＢＭＦＦで定義された’ｍｅｔａ’ ｂｏｘに包含され、
    前記画像プロパティは、前記メタデータ部の所定のボックスに格納され、
    前記所定のボックスは、前記画像アイテム情報を特定するＩＳＯＢＭＦＦで定義された’ｉｔｅｍＩｎｆｏＢｏｘ’のエントリと前記画像プロパティとを関連付けるために用いられる、
    ことを特徴とする装置。
16. 前記画像プロパティは、
    前記１枚の画像あるいはサブ画像の位置、
    前記１枚の画像あるいはサブ画像のピクセルアスペクト比、および
    前記１枚の画像あるいはサブ画像の色情報、
    のうちの少なくともいずれかをさらに含むことを特徴とする請求項１５に記載の装置。
17. 前記画像プロパティは、
    前記１枚の画像あるいはサブ画像のクロッピングまたは回転の少なくともいずれかのプロパティを含むことを特徴とする請求項１５または１６に記載の装置。
18. 前記所定のボックスは、前記１枚の画像あるいはサブ画像の識別子を含むことを特徴とする請求項１５から１７のいずれか１項に記載の装置。
19. 前記１枚の画像のサブ画像は、前記１枚の画像を分割して得られる複数のサブ画像であることを特徴とする請求項１５から１８のいずれか１項に記載の装置。
20. 前記ファイルを格納するためのメモリを有することを特徴とする請求項１５から１９のいずれか１項に記載の装置。
21. 請求項１から４のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。
22. 請求項５から８のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。

Images