(57)【要約】実施形態は、ＩＳＯベースメディアファイルフォーマットと互換性があるファイルフォーマットでビジュアルデータを受信することと、１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理することと、前記検出された１つ以上のコンテンツ要素、及び使用されたプロセスに関する情報を、メタデータとして記憶することと、前記ビジュアルデータに対応付けて前記メディアファイルに前記メタデータを含めることと、を含む方法に関する。実施形態はまた、この方法を実施するための技術機器に関する。【選択図】図６
2022501891.tif 000002
【特許請求の範囲】
【請求項１】
コンテナファイルフォーマットでビジュアルデータを受信することと、
１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理することと、
前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶することと、
前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含めることと、
を含む、方法。
【請求項２】
前記コンテナファイルは、処理アルゴリズムについてのメタデータを含む第１のボックスを含む、請求項１に記載の方法。
【請求項３】
前記コンテナファイルは、前記１つ以上のコンテンツ要素についてのメタデータを含む第２のボックスを含む、請求項１又は２に記載の方法。
【請求項４】
前記コンテナファイルは、複数の処理アルゴリズムのプロセスについてのメタデータを含む第３のボックスを含む、請求項１から３のいずれかに記載の方法。
【請求項５】
前記コンテナファイルは画像シーケンス又は動画であり、
前記コンテナファイルは、前記メタデータを含むメディアトラックについてのメディアサンプル定義を含む、請求項１から４のいずれかに記載の方法。
【請求項６】
前記コンテナファイルは、前記コンテナファイル内の情報を搬送する他のエンティティにコンテナを関連付けるための関係定義を含む、請求項１から５のいずれかに記載の方法。
【請求項７】
前記ビジュアルデータは、前記１つ以上のコンテンツ要素を検出するために、１つ以上のニューラルネットワーク又は１つ以上の非ニューラルネットワークベースのアルゴリズムによって処理される、請求項１から６のいずれかに記載の方法。
【請求項８】
コンテナファイルフォーマットでビジュアルデータを受信する手段と、
１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理する手段と、
前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶する手段と、
前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含める手段と、
を備える、装置。
【請求項９】
前記コンテナファイルは、処理アルゴリズムについてのメタデータを含む第１のボックスを含む、請求項８に記載の装置。
【請求項１０】
前記コンテナファイルは、前記１つ以上のコンテンツ要素についてのメタデータを含む第２のボックスを含む、請求項８又は９に記載の装置。
【請求項１１】
前記コンテナファイルは、複数の処理アルゴリズムのプロセスについてのメタデータを含む第３のボックスを含む、請求項８から１０のいずれかに記載の装置。
【請求項１２】
前記コンテナファイルは、画像シーケンス又は動画であり、
前記コンテナファイルは、前記メタデータを含むメディアトラックについてのメディアサンプル定義を含む、
請求項８から１１のいずれかに記載の装置。
【請求項１３】
前記コンテナファイルは、前記コンテナファイル内の情報を搬送する他のエンティティにコンテナを関連付けるための関係定義を含む、請求項８から１２のいずれかに記載の装置。
【請求項１４】
前記１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理するために、１つ以上のニューラルネットワーク又は１つ以上の非ニューラルネットワークベースのアルゴリズムを更に含む、請求項８から１３のいずれかに記載の装置。
【請求項１５】
少なくとも１つのプロセッサと、コンピュータプログラムコードを含むメモリと、を更に備える、請求項８から１４のいずれかに記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本ソリューションは、一般に、人工知能（Artificial Intelligence：ＡＩ）に関する。特に、本ソリューションは、人工知能メタデータを記憶及びシグナリングするための装置及び方法に関する。
【背景】
【０００２】
多くの実用的用途が、画像、動画などのメディアのコンテンツに関するセマンティック情報の利用可能性に依存する。セマンティック情報は、シーンのタイプ、特定の動作／行動の発生、特定の物体の存在などを表し得るメタデータによって表される。当該セマンティック情報は、メディアを分析することによって取得され得る。
【０００３】
近年、様々なニューラルネットワーク技術の発展により、生の画像データから直接、画像／動画コンテンツの様々な要素を認識するための学習が可能になってきている。例えば、それぞれのコンテンツからの視覚的又は聴覚的要素を認識するためのコンピュータの能力について説明するとき、「人工知能」（ＡＩ）という用語が用いられるが、それは、ニューラルネットワーク及び機械学習を含む一般的な用語である。
【摘要】
【０００４】
現在、改良された方法及び本方法を実施する技術機器が発明されており、それによって上記問題が緩和される。様々な態様は、方法、装置、及び内部に記憶されたコンピュータプログラムを含むコンピュータ可読媒体を含み、それらは、独立請求項で示されることを特徴とする。様々な実施形態は、従属請求項で開示される。
【０００５】
第１の態様によると、方法が提供される。当該方法は、コンテナファイルフォーマットでビジュアルデータを受信することと、１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理することと、前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶することと、前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含めることと、を含む。
【０００６】
第２の態様によると、装置が提供される。当該装置は、コンテナファイルフォーマットでビジュアルデータを受信する手段と、１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理する手段と、前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶する手段と、前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含める手段と、を備える。
【０００７】
第３の態様によると、装置が提供される。当該装置は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含むメモリと、を備え、前記コンピュータプログラムコードは、命令を含む。当該命令は、前記プロセッサによって実行されると、前記装置に、コンテナファイルフォーマットでビジュアルデータを受信させ、１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理させ、前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶させ、前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含ませる。
【０００８】
第４の態様によると、コンピュータプログラムコードを含むコンピュータプログラム製品が提供される。当該コンピュータプログラムコードは、少なくとも１つのプロセッサで実行されると、装置又はシステムに、コンテナファイルフォーマットでビジュアルデータを受信させ、１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理させ、前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶させ、前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含ませるように構成される。
【０００９】
一実施形態によると、前記コンテナファイルは、処理アルゴリズムについてのメタデータを含む第１のボックスを含む。
【００１０】
一実施形態によると、前記コンテナファイルは、前記１つ以上のコンテンツ要素についてのメタデータを含む第２のボックスを含む。
【００１１】
一実施形態によると、前記コンテナファイルは、複数の処理アルゴリズムのプロセスについてのメタデータを含む第３のボックスを含む。
【００１２】
一実施形態によると、前記コンテナファイルは、画像シーケンス又は動画であり、前記コンテナファイルは、前記メタデータを含むメディアトラックについてのメディアサンプル定義を含む。
【００１３】
一実施形態によると、前記コンテナファイルは、前記コンテナファイル内の情報を搬送する他のエンティティにコンテナを関連付けるための関係定義を含む。
【００１４】
一実施形態によると、前記ビジュアルデータは、前記１つ以上のコンテンツ要素を検出するために、１つ以上のニューラルネットワーク又は１つ以上の非ニューラルネットワークベースのアルゴリズムによって処理される。
【００１５】
一実施形態によると、前記コンピュータプログラム製品は、非一時的コンピュータ可読媒体に実装される。
【図面の簡単な説明】
【００１６】
以下、添付図面を参照して、様々な実施形態をより詳細に記載する。
【図１】実施形態に係る装置を示す。
【図２】畳み込みニューラルネットワークの例を示す。
【図３】ＨＥＩＦ（High Efficiency Image File Format）形式のＡＩプロパティストレージについての第１の実施形態を示す。
【図４】ＨＥＩＦ形式のＡＩプロパティストレージについての第２の実施形態を示す。
【図５】インテリジェントコンテンツについてのメディアフォーマットとしてのＨＥＩＦの例を示す。
【図６】ビジュアルコンテンツ認識についてのプロセスの例を示す。
【図７】実施形態に係る方法を示すフローチャートである。
【例示的な実施形態の説明】
【００１７】
以下、人工知能の文脈でいくつかの実施形態を記載する。特に、これらの実施形態は、メディアファイル内の人工知能メタデータの記憶及びシグナリングを可能にする。
【００１８】
図１は、一実施形態に係るデータ処理で使用されるのに好適なコンピュータシステムを示す。このコンピュータシステムの全体的な構造は、システムの機能ブロックに従って説明される。いくつかの機能は、単一の物理デバイスで実行され得、例えば、すべての計算手順は、必要があれば単一のプロセッサで実行され得る。図１の例に係る装置のデータ処理システムは、メイン処理ユニット１００と、メモリ１０２と、記憶デバイス１０４と、入力デバイス１０６と、出力デバイス１０８と、グラフィクスサブシステム１１０と、を備え、これらはすべてデータバス１１２を介して互いに接続されている。
【００１９】
メイン処理ユニット１００は、データ処理システム内でデータを処理するように配置された従来の処理ユニットである。メイン処理ユニット１００は、１つ以上のプロセッサもしくはプロセッサ回路を備え得るか、又は１つ以上のプロセッサもしくはプロセッサ回路として実装され得る。メモリ１０２、記憶デバイス１０４、入力デバイス１０６、及び出力デバイス１０８は、当業者によって認識されるような従来の構成要素を含み得る。メモリ１０２及び記憶デバイス１０４は、データ処理システム１００内のデータを記憶する。メモリ１０２には、例えば、機械学習プロセスを実施するためのコンピュータプログラムコードがある。入力デバイス１０６は、システム内にデータを入力し、一方、出力デバイス１０８は、データ処理システムからデータを受信し、例えば、ディスプレイにデータを転送する。データバス１１２は、従来のデータバスであり、単一のラインとして示されているが、プロセッサバス、ＰＣＩバス、グラフィカルバス、ＩＳＡバスの任意の組合せであってもよい。したがって、当業者は、この装置が、コンピュータデバイス、パーソナルコンピュータ、サーバコンピュータ、携帯電話、スマートフォン、又はインターネットアクセスデバイス、例えば、インターネットタブレットコンピュータなどの任意のデータ処理デバイスであり得ることを容易に認識する。
【００２０】
異なる実施形態によって、異なる部分が異なる要素で実行されることが可能になることが理解される必要がある。例えば、コンピュータシステムの様々なプロセスは、１つ以上の処理デバイス、例えば、１つのコンピュータデバイスで完全に、又は１つのサーバデバイスで、もしくは複数のユーザデバイス間で実行され得る。機械学習プロセスの要素は、１つのデバイス上にあるソフトウェア構成要素として実装され得るか、又は、例えば、複数のデバイスがいわゆるクラウドを形成するように、上述のように、これらのデバイス間で分配され得る。
【００２１】
多くのメディアファイルフォーマットのシンタックスは、タイプの階層リスト、及び長さプレフィックスデータチャンク又はボックスに基づいている。ここで、命名は、問題となるフォーマットに依存する。ＩＳＯベースメディアファイルフォーマット（ISO Base Media File Format：ＩＳＯＢＭＦＦ）（ＩＳＯ／ＩＥＣ  １４４９６−１２）に従うコンテナファイルでは、メディアデータ及びメタデータは、様々なタイプのボックスで整理されている。多くのフォーマットがＩＳＯＢＭＦＦから導き出され、その例としてＨＥＩＦ（ＩＳＯ／ＩＥＣ  ２３００８−１２）、ＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ  １４４９６−１４）（「ＭＰ４フォーマット」としても知られている）、ＮＡＬユニット構造化動画についてのファイルフォーマット（ＩＳＯ／ＩＥＣ  １４４９６−１５）、及び３ＧＰＰファイルフォーマット（３ＧＰＰ  ＴＳ  ２６．２４４）（「３ＧＰフォーマット」としても知られている）が挙げられる。これらのフォーマットは、同じボックス構造化基本構造を使用する。
【００２２】
ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ  １４４９６−１２）（「ＩＳＯＢＭＦＦ」と略され得る）のいくつかの概念、構造、及び仕様は、コンテナファイルフォーマットの例として以下に記載され、それに基づいて、各種実施形態が実装され得る。本発明の諸態様は、ＩＳＯＢＭＦＦに限定されず、むしろ、説明は、１つの可能性のある基盤に対して与えられ、本発明はこれに基づいて、部分的に又は完全に実現され得る。
【００２３】
ＩＳＯベースメディアファイルフォーマット内の基本構築ブロックは、ボックスと呼ばれる。各ボックスは、ヘッダ及びペイロードを有する。ボックスヘッダは、ボックスのタイプ及びサイズ（バイト）を示す。あるボックスは、他のボックスを囲ってもよく、ＩＳＯファイルフォーマットは、特定のタイプのボックス内のどのボックスタイプが可能にされるかを規定する。更に、一部のボックスの存在は、各ファイルで必須であり得るが、一方、他のボックスの存在は、オプションであり得る。更に、一部のボックスタイプについて、ファイル内に複数のボックスを存在させることが許容可能であり得る。したがって、ＩＳＯベースメディアファイルフォーマットは、複数のボックスの階層構造を規定すると考えられ得る。
【００２４】
ファイルフォーマットのＩＳＯファミリーによると、１つのファイルは、ボックス内に組み込まれるメディアデータ及びメタデータを含む。各ボックスは、４文字コード（Four Character Code：４ＣＣ）によって識別され、ボックスのタイプ及びサイズに関して知らせるヘッダで始まる。
【００２５】
ＩＳＯベースメディアファイルフォーマットに従うファイルでは、メディアデータは、メディアデータ「ｍｄａｔ」ボックスで提供され得、ムービー「ｍｏｏｖ」ボックスは、メタデータを取り込むために使用され得る。いくつかの場合、動作可能であるファイルについて、「ｍｄａｔ」及び「ｍｏｏｖ」ボックスの両方が存在するように要求され得る。ムービー「ｍｏｏｖ」ボックスは、１つ以上のトラックを含み得、各トラックは、１つの対応するトラック「ｔｒａｋ」ボックスにあり得る。トラックは、メディア圧縮フォーマット（及びＩＳＯベースメディアファイルフォーマットへのそのカプセル化）に従ってフォーマット化されたサンプルを指すメディアトラックを含む、多くのタイプのうちの１つであり得る。
【００２６】
ムービーフラグメントは、例えば、記録アプリケーションがクラッシュし、メモリスペースを使い切るか、又は他の何らかのインシデントが生じる場合にデータを失うのを回避するために、例えば、ＩＳＯファイルにコンテンツを記録するときに使用され得る。ムービーフラグメントがなければ、すべてのメタデータ、例えば、ムービーボックスがファイルの隣接する１つのエリアに書き込まれることをファイルフォーマットが要求し得るため、データ損失が生じ得る。更に、ファイルを記録するとき、利用可能なストレージのサイズについてムービーボックスをバッファリングするのに十分な量のメモリスペース（例えば、ランダムアクセスメモリＲＡＭ）がない場合があり、ムービーが閉じられるときのムービーボックスのコンテンツの再計算は、あまりにも遅い場合がある。更に、ムービーフラグメントは、正規のＩＳＯファイルパーサーを使用して、ファイルの同時の記録及び再生を可能にし得る。更に、より短い時間の初期バッファリングは、ムービーフラグメントが使用され、初期のムービーボックスが、同じメディアコンテンツを有するがムービーフラグメントなしで構造化されたファイルと比較してより小さいときに、プログレッシブダウンロード、例えば、ファイルの同時の受信及び再生のために必要とされ得る。
【００２７】
ムービーフラグメントの特徴によって、そうでなければムービーボックスにあり得るメタデータを複数のピースに分割することが可能となり得る。各ピースは、トラックの特定の期間に対応し得る。言い換えると、ムービーフラグメントの特徴によって、ファイルメタデータ及びメディアデータをインターリーブすることが可能となり得る。その結果、ムービーボックスのサイズが制限され、上述の使用ケースが実現され得る。
【００２８】
一部の例では、ムービーフラグメントについてのメディアサンプルは、ｍｏｏｖボックスと同じファイルにある場合、ｍｄａｔボックスにあり得る。しかしながら、ムービーフラグメントのメタデータについて、ｍｏｏｆボックスが提供され得る。ｍｏｏｆボックスは、以前はｍｏｏｖボックスにあった特定の時間の再生時間についての情報を含み得る。ｍｏｏｖボックスは、依然としてそれ自体、有効なムービーを表し得るが、更に、ムービーフラグメントが同じファイル内で続くことを示すｍｖｅｘボックスを含み得る。ムービーフラグメントは、ｍｏｏｖボックスに対応付けられる提示を時間的に拡張し得る。
【００２９】
ムービーフラグメント内で、トラックごとにゼロから複数まで任意の場所を含むトラックフラグメントのセットがあり得る。次いで、トラックフラグメントは、ゼロから複数のトラック実行まで任意の場所を含み得、そのドキュメントの各々は、そのトラックについてのサンプルの隣接する実行である。これらの構造内で、多くのフィールドは、オプションであり、デフォルトであり得る。ｍｏｏｆボックスに含まれ得るメタデータは、ｍｏｏｖボックスに含まれ得るメタデータのサブセットに限定され得、場合によって異なってコード化され得る。ｍｏｏｆボックスに含まれ得るボックスに関する詳細は、ＩＳＯベースメディアファイルフォーマット仕様に規定され得る。独立型ムービーフラグメントは、ファイルオーダーで連続するｍｏｏｆボックス及びｍｄａｔボックスからなるように定義され得る。ここで、ｍｄａｔボックスは、（ｍｏｏｆボックスがメタデータを提供する）ムービーフラグメントのサンプルを含み、他のムービーフラグメント（例えば、他のｍｏｏｆボックス）のサンプルを含まない。
【００３０】
トラックを互いに対応付けるためにトラック参照メカニズムが使用され得る。トラック参照ボックスは、ボックス（複数可）を含み、その各々は、含有トラック（containing track）から他のトラックのセットへの参照を提供する。これらの参照は、含有されたボックス（複数可）のボックスタイプ（すなわち、ボックスの４文字コード）を介してラベル付けされる。シンタックスは、以下のように規定され得る。
aligned(8) class TrackReferenceBox extends Box('tref') {
TrackReferenceTypeBox [];
}
aligned(8) class TrackReferenceTypeBox (unsigned int(32) reference_type) extends Box(reference_type) {
unsigned int(32) track_IDs[];
}
【００３１】
track_IDsは、参照されるトラックのトラック識別子、又は参照されるトラックグループのtrack_group_id値を提供する整数のアレイとして規定され得る。track_IDs[i]（iはtrack_IDs[]アレイについての有効なインデックスである）の各値は、含有トラックから、track_IDs[i]に等しいtrack_IDを有するトラック、又はtrack_IDs[i]に等しいtrack_group_id及び１に等しいトラックグループタイプボックスのフラグフィールドの特定のビット（例えば、最下位ビット）の両方を有するトラックグループへの参照を提供する整数である。track_group_id値が参照されるとき、トラック参照は、特定のトラック参照タイプのセマンティックで特に述べられない限り、参照されたトラックグループの各トラックに個々に適用される。値０は、存在することが許可されない場合がある。
【００３２】
トラックグルーピングメカニズムは、トラックのグループの標示を可能にする。ここで、各グループは、特定の特徴を共有するか、又はグループ内のトラックは、特定の関係を有する。トラックグループボックスは、トラックボックスに含まれ得る。トラックグループボックスは、トラックグループタイプボックスから導き出されるゼロ個以上のボックスを含む。特定の特徴又は関係は、含有されたボックスのボックスタイプによって示される。含有されたボックスは、トラックが同じトラックグループに属することを結論付けるために使用され得る識別子を含む。トラックグループボックス内の含有されたボックスの同じタイプを含み、これらの含有されたボックス内の同じ識別子値を有するトラックは、同じトラックグループに属する。
【００３３】
ＩＳＯベースメディアファイルフォーマットは、特定のサンプルに対応付けられ得る時間指定（timed）メタデータについての３つのメカニズム、すなわち、サンプルグループ、時間指定メタデータトラック、及びサンプル補助情報を含む。導き出された仕様は、これらの３つのメカニズムのうちの１つ以上による同様の機能を提供し得る。
【００３４】
ＡＶＣファイルフォーマット及びＳＶＣファイルフォーマットなどのＩＳＯベースメディアファイルフォーマット及びその派生物におけるサンプルグルーピングは、グルーピング基準に基づいて、１つのサンプルグループのメンバーであるように、トラック内の各サンプルの割り当てと定義され得る。サンプルグルーピングにおけるサンプルグループは、隣接するサンプルであることに限定されず、隣接しないサンプルを含み得る。トラック内のサンプルについて複数のサンプルグルーピングがあり得るため、各サンプルグルーピングは、グルーピングのタイプを示すためにタイプフィールドを有し得る。サンプルグルーピングは、次の２つのリンクデータ構造によって表され得る。（１）サンプル−グループボックス（SampleToGroupBox：ｓｂｇｐボックス）は、サンプルグループへのサンプルの割り当てを表し、（２）サンプルグループ記述ボックス（SampleGroupDescriptionBox：ｓｇｐｄボックス）は、グループのプロパティを記載する各サンプルグループについてのサンプルグループエントリーを含む。異なるグルーピング基準に基づくサンプル−グループボックス及びサンプルグループ記述ボックスの複数のインスタンスがあり得る。これらは、グルーピングのタイプを示すために使用されたタイプフィールドによって区別され得る。サンプル−グループボックスは、例えば、グルーピングのサブタイプを示すために使用され得るgrouping_type_parameterフィールドを含み得る。
【００３５】
ＩＳＯベースメディアファイルフォーマット規格に対する修正ドラフトは、以下のようにコンパクトなサンプル−グループマッピングを説明する。
ボックスタイプ：  「ｃｓｇｐ」
コンテナ：        サンプルテーブルボックス又はトラックフラグメントボックス
必須：            いいえ
量：              ゼロ以上
【００３６】
コンパクトなサンプル−グループボックスは、特に、繰り返しパターンがある場合、及び特定のタイプのサンプルグループがほとんどないときに、サンプルからグループへのマッピングを表す、よりコンパクトな方法を提供する。
【００３７】
設計においては、つながったパターンのベクトルを使用し、そのパターンの各々は、その繰り返しにサンプルの実行を対応付けるマッピングアレイによって一度使用される。これは、以下の例によって示される。以下の各文字は、異なるサンプルグループ説明インデックス値（０かもしれない）を表す。
【００３８】
あるトラックが最初のサンプルから始まる以下の対応付けを有する場合、
a b c b  a b c b  a b c x x  a b c b  a b d b
これらの対応付けは、以下によって表され得る。
１．pattern_length=4、sample_count=11、
２．pattern_length=1、sample_count=2、
３．pattern_length=4、sample_count=6、
４．pattern_length=2、sample_count=2、
pattern=[
a b c b                //長さ４のパターン１
x                //長さ１のパターン２
a b c b                //長さ４のパターン３
d b                //長さ２のパターン４
]                //したがって、pattern_lengthは、4+1+4+2=11である。
【００３９】
sample_count[i]がpattern_length[i]に等しいとき、パターンは繰り返されない。
【００４０】
sample_count[i]がpattern_length[i]よりも大きいとき、ｉ番目のパターンのsample_group_description_index値は、sample_count[i]値をマッピングするために繰り返し使用される。必ずしもsample_count[i]がpattern_length[i]の倍数であるわけではなく、繰り返しは、パターンの途中で終わり得る。
【００４１】
１からpattern_countまでの範囲でｉのすべての値についてのsample_count[i]値の合計が、合計のサンプルカウントよりも小さいとき、リーダー（reader）は、明示的なグループ対応付けを有しないサンプルを、（もしあれば）サンプル記述グループボックスで定義されるデフォルトグループと対応付け、そうでなければ、グループなしと対応付けるべきである。
【００４２】
sample_count[i]値の合計が、包含するトラックボックス又はトラックフラグメントボックスによって記載される実際のサンプルの合計のカウントよりも大きいのはエラーであり、よって、リーダー挙動は定義されない。
【００４３】
シンタックス
aligned(8) class CompactSampleToGroupBox
extends FullBox('csgp', version, 0)
{
unsigned int(32) grouping_type;        unsigned int(1)         index_msb_indicates_fragment_local_description;
unsigned int(1) grouping_type_parameter_present;
unsigned int(6) field_size_minus_1;
if (grouping_type_parameter_present == 1) {
unsigned int(32) grouping_type_parameter;
}
unsigned int(32) pattern_count;
totalPatternLength = 0;
for (i=1; i <= pattern_count; i++) {
unsigned int(32) pattern_length[i];
unsigned int(32) sample_count[i];
totalPatternLength += pattern_length[i];
}
for (j=1; j <= pattern_count; j++) {
for (k=1; k <= pattern_length[j]; k++) {
unsigned int(field_size) sample_group_description_index[j][k];
//そのｍｓｂはfragment_local又はグローバルを示し得る
}
}
}
【００４４】
セマンティクス
versionは、このボックスのバージョンを規定する整数であり、現在０である。
【００４５】
grouping_typeは、サンプルグルーピングのタイプ（すなわち、サンプルグループを形成するために使用された基準）を識別し、それを、グルーピングタイプについての同じ値でそのサンプルグループ記述テーブルにリンクさせる、整数である。grouping_type（及び使用される場合、grouping_type_parameter）についての同じ値での「ｃｓｇｐ」又は「ｓｂｇｐ」のいずれかの多くて１回の発生が、あるトラックについて存在する。
【００４６】
grouping_type_parameterは、グルーピングのサブタイプの標示である。
【００４７】
index_msb_indicates_fragment_local_descriptionは、このボックスが「ｔｒａｋ」ボックス内で現れるときにゼロでなければならないが、このボックスが「ｔｒａｆ」ボックス内で現れるときに０又は１であり得るフラグである。これが１であるとき、それは、すべてのsample_group_description_indexの最上位ビット（Most Significant Bit：ＭＳＢ）がインデックス数の一部を形成しないことを示すが、代わりにグループ記述がどの「ｓｇｐｄ」ボックスで見出されるかを示す。ＭＳＢが０である場合、インデックスは、「ｔｒａｋ」ボックスの「ｓｇｐｄ」ボックスからグループ記述を識別する。ＭＳＢが１である場合、インデックスは、「ｔｒａｆ」ボックスの「ｓｇｐｄ」ボックスからグループ記述を識別する。
【００４８】
field_sizeは、sample_group_description_index値のアレイにおいてエントリーのビットでサイズを規定する整数である。それぞれ、４、８、１６、３２のフィールドサイズを示す、値３、７、１５、又は３１を取る。フィールドサイズ４が使用される場合、各バイトは、２つの値（entry[i]<<4 + entry[i+1]）を含む。サイズが整数のバイトを満たさない場合、最後のバイトは、ゼロで詰められる。
【００４９】
pattern_countは、それに続くパターンアレイ内の対応付けられたパターンの長さを示す。含まれるsample_count値の合計は、マッピングされたサンプルの数を示す。
【００５０】
pattern_length[i]は、sample_group_description_index[j]値の第２のアレイ内のパターンに対応する。pattern_length[i]の各インスタンスは、０よりも大きい。
【００５１】
sample_count[i]は、ｉ番目のパターンを使用するサンプルの数を規定する。sample_count[i]は、ゼロよりも大きく、sample_count[i]は、pattern_length[i]以上である。
【００５２】
sample_group_description_index[j][k]は、このグループ内のサンプルを記載するサンプルグループエントリーのインデックスを与える整数である。インデックスは、１から、サンプルグループ記述ボックス内のサンプルグループエントリーの数までの範囲であるか、又はこのサンプルがこのタイプのグループなしのメンバーであることを示す値０を取る。
【００５３】
説明及び実施形態では、コンパクトなサンプル−グループのボックスなどは、サンプル−グループのボックス（sample-to-group box）又はサンプル−グループボックス（SampleToGroupBox）が参照されるときに同等に使用され得る。
【００５４】
サブサンプルは、サンプルのバイトの隣接する範囲と定義され得る。サブサンプルに関する情報は、サンプルテーブルボックス及び／又はトラックフラグメントボックス（複数可）に含まれ得るサブサンプル情報ボックス（複数可）で与えられ得る。サブサンプルの特定の定義は、所与のコーディングシステム及び／もしくはコーディングシステムの所与のカプセル化フォーマット（例えば、特定のサンプルエントリータイプ）についてであり得、ならびに／又は含有サブサンプル情報ボックスのフラグフィールドを使用して更に規定され得る。例えば、ＨＥＶＣについてのフラグフィールドの値は、サブサンプル情報ボックスによってアドレス指定されるサブサンプルがＮＡＬユニット、デコーディングユニット、タイル、コーディングツリーユニット列、スライス、又はコード化されたピクチャであることを示し得る。複数のサブサンプル情報ボックスが同じコンテナボックスに存在するとき、フラグの値は、これらのサブサンプル情報ボックスの各々で異なることが要求され得る。
【００５５】
サブサンプル情報ボックスのシンタックスは、以下のように規定され得る。
aligned(8) class SubSampleInformationBox
extends FullBox('subs', version, flags) {
unsigned int(32) entry_count;
int i,j;
for (i=0; i < entry_count; i++) {
unsigned int(32) sample_delta;
unsigned int(16) subsample_count;
if (subsample_count > 0) {
for (j=0; j < subsample_count; j++) {
if(version == 1)
{
unsigned int(32) subsample_size;
}
else
{
unsigned int(16) subsample_size;
}
unsigned int(8) subsample_priority;
unsigned int(8) discardable;
unsigned int(32) codec_specific_parameters;
}
}
}
}
【００５６】
サブサンプル情報ボックスのシンタックス要素のセマンティクスは、以下のように規定され得る。versionは、このボックスのバージョンを規定する整数である。entry_countは、後続のテーブル内のエントリーの数を示す整数である。sample_deltaは、サブサンプル構造を有するサンプルを示す整数であり、デコーディング順で、所望のサンプル数と以前のエントリーで示されるサンプル数との間の差としてコード化される。現在のエントリーがトラック内の最初のエントリーである場合、この値は、サブサンプル情報を有する最初のサンプルのサンプル数を示し、すなわち、値は、サンプル数とゼロ（０）との間の差である。現在のエントリーが、先行の空でないトラックフラグメントを有するトラックフラグメント内の最初のエントリーである場合、値は、サブサンプル情報を有する最初のサンプルのサンプル数と、以前のトラックフラグメント内の最後のサンプルのサンプル数との間の差を示す。現在のエントリーが、いかなる先行のトラックフラグメントもないトラックフラグメント内の最初のエントリーである場合、値は、サブサンプル情報を有する最初のサンプルのサンプル数を示し、すなわち、値は、サンプル数とゼロ（０）との間の差である。これは、トラック又はトラックフラグメント内の最初のサンプルを記述する最初のエントリーについてのsample_deltaが常に１であることを意味する。subsample_countは、現在のサンプルについてのサブサンプルの数を規定する整数である。サブサンプル構造がない場合、このフィールドは、値０を取る。subsample_sizeは、現在のサブサンプルのサイズ（バイト）を規定する整数である。subsample_priorityは、各サブサンプルについての低下優先度を規定する整数である。subsample_priorityのより高い値は、重要であるサブサンプルを示し、デコードされた品質においてより大きい影響を与える。０に等しいdiscardableは、サブサンプルが現在のサンプルをデコードすることを要求されることを意味し、一方、１に等しいことは、サブサンプルが現在のサンプルをデコードすることを要求されないが、拡張のために使用され得ることを示し、例えば、サブサンプルは、付加拡張情報（Supplemental Enhancement Information：ＳＥＩ）で構成されている。codec_specific_parametersは、使用中のコーデック及び／又はそのカプセル化フォーマット（例えば、サンプルエントリータイプ）によって定義される。当該定義が利用可能でない場合、このフィールドは０に設定される。
【００５７】
ＨＥＩＦは、画像及び画像シーケンス（動画など）の記憶のためのムービングピクチャエクスパーツグループ（ＭＰＥＧ）によって開発された規格である。ＨＥＩＦは、他の画像ファイルフォーマットと比較して、特徴に関してＨＥＩＦを優れたものにする、広く使用されるＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）の上で構築される豊富なセットの特徴を含む。本開示では、「ＨＥＩＦ」、「ＩＳＯＢＭＦＦ」、及び「ファイルフォーマット」という用語は、交換可能に使用され得る。
【００５８】
ＩＳＯＢＭＦＦ構造及び特徴は、広範囲でＨＥＩＦの設計において使用される。ＨＥＩＦについての基本設計は、静止画像がアイテムとして記憶され、画像シーケンスがトラックとして記憶されることを含む。
【００５９】
ＨＥＩＦのコンテキストでは、以下のボックスが、ルートレベル「ｍｅｔａ」ボックス内に含まれ得、以下に説明されるように使用され得る。ＨＥＩＦでは、「ｍｅｔａ」ボックスのハンドラボックスのハンドラ値は「ｐｉｃｔ」である。（同じファイル内であろうと、ＵＲＩ（Uniform Resource Identifier）によって識別される外部ファイル内であろうと）コード化されたメディアデータを含むリソースは、データ情報（「ｄｉｎｆ」）ボックスを介して解明され、一方、アイテムロケーション（「ｉｌｏｃ」）ボックスは、参照されたファイル内のすべてのアイテムの位置及びサイズを記憶する。アイテム参照（「ｉｒｅｆ」）ボックスは、タイプによる（typed）参照を使用してアイテム間の関係を記録する。ある点で他のものと比較して最も重要であると考えられるアイテムの集合内でのアイテムがある場合、このアイテムは、プライマリアイテム（「ｐｉｔｍ」）ボックスによってシグナリングされる。ここで言及されるボックスとは別に、「ｍｅｔａ」ボックスはまた、アイテムを記述するのに必要であり得る他のボックスを含むようにフレキシブルである。
【００６０】
任意の数の画像アイテムが、同じファイルに含まれ得る。「ｍｅｔａ」ボックスアプローチを使用することによって記憶される集合画像を考慮すると、画像間の特定の関係を適格とすることが時には必須である。当該関係の例としては、ある集合についてのカバー画像を示すことと、その集合における画像の一部又はすべてについてのサムネイル画像を提供することと、ある集合における画像の一部又はすべてをアルファ面などの補助画像と対応付けることが挙げられる。画像の集合内のカバー画像は、「ｐｉｔｍ」ボックスを使用して示される。サムネイル画像又は補助画像は、タイプ「ｔｈｍｂ」又は「ａｕｘｌ」のアイテム参照をそれぞれ使用してプライマリ画像アイテムとリンクされる。
【００６１】
アイテムプロパティボックスは、アイテムプロパティの順序集合との任意のアイテムの対応付けを可能にする。アイテムプロパティは、小さいデータ記録である。アイテムプロパティボックスは、アイテムプロパティの黙示的なインデックスリストを含むアイテムプロパティコンテナボックス、及びアイテムをアイテムプロパティと対応付ける１つ以上のアイテムプロパティアソシエーションボックスの２つの部分からなる。アイテムプロパティは、ボックスとしてフォーマット化される。
【００６２】
記述的なアイテムプロパティは、対応付けられたアイテムを変えるのではなく記述するアイテムプロパティと定義され得る。変形的なアイテムプロパティは、画像アイテムコンテンツの再構築された表示を変えるアイテムプロパティと定義され得る。
【００６３】
ニューラルネットワーク（Neural Network：ＮＮ）は、いくつかの層の計算で構成された計算グラフである。各層は、１つ以上のユニットで構成されており、ここで、各ユニットは、基本計算を実行する。ユニットは、１つ以上の他のユニットに接続されており、接続は、ウェイトを対応付け得る。ウェイトは、対応付けられた接続を通る信号のスケーリングのために使用され得る。ウェイトは、通常、学習可能パラメータ、すなわち、訓練データから学習され得る値である。ニューラルネットワークについての最も広く使用されるアーキテクチャは、フィードフォワード及びリカレントアーキテクチャの２つである。フィードフォワードニューラルネットワークは、フィードバックループがないものであり、各層は、前の層のうちの１つ以上から入力を取り、その出力を後の層のうちの１つ以上についての入力として提供する。また、特定の層内のユニットは、先行の層のうちの１つ以上におけるユニットから入力を取り、出力を次の層のうちの１つ以上に提供する。初期の層（入力データに近いもの）は、画像内のエッジ及びテクスチャなどの低レベルの特徴をセマンティックに抽出し、中間の層及び最終の層は、より高レベルの特徴を抽出する。特徴抽出層の後、分類、セマンティックセグメンテーション、物体検出、ノイズ除去、スタイル変換、超解像などの特定のタスクを実行する１つ以上の層があり得る。リカレントニューラルネットでは、フィードバックループがあり、その結果、ネットワークはステートフルになり、すなわち、情報又は状態を記憶することが可能である。
【００６４】
ニューラルネットワークは、携帯電話などの多くの異なるタイプのデバイスについての、ますます多くの用途で利用されている。この例としては、画像及び動画の分析及び処理、ソーシャルメディアデータ分析、デバイス使用データ分析などが挙げられる。
【００６５】
深層学習技術における特徴抽出器の例は、図２に示される畳み込みニューラルネットワーク（Convolutional Neural Network ：ＣＮＮ）に含まれる。ＣＮＮは、１つ以上の畳み込み層、全結合層、及びトップの分類層で構成されている。ＣＮＮは、他の深層ニューラルネットワークよりも訓練するのが容易であり、推定されるパラメータがより少ない。したがって、ＣＮＮは、特に、画像及びスピーチの用途において使用するのに非常に魅力的なアーキテクチャである。
【００６６】
図２の例では、ＣＮＮへの入力は、画像であるが、任意の他のデータが同様に使用され得る。ＣＮＮの各層は、特定の抽象（又はセマンティック）レベルを表し、ＣＮＮは、複数の特徴マップを抽出する。特徴マップは、例えば、抽出された特徴の値を表す実数の密行列を含み得る。図２におけるＣＮＮは、単純化のために３つの特徴（又は抽象もしくはセマンティック）層Ｃ１、Ｃ２、Ｃ３のみを有するが、ＣＮＮは、４つ又は更に多い畳み込み層を有し得る。
【００６７】
ＣＮＮの第１の畳み込み層Ｃ１は、第１の層から（すなわち、入力画像から）４つの特徴マップを抽出することを含み得る。これらのマップは、エッジ及びコーナーなどの、入力画像において見出される低レベルの特徴を表し得る。ＣＮＮの第２の畳み込み層Ｃ２は、その前の層からの６つの特徴マップの抽出で構成され、抽出された特徴のセマンティックレベルを増加させる。同様に、第３の畳み込み層Ｃ３は、エッジ及びコーナーの組合せ、形状などの、画像において見出されるより抽象概念を表し得る。ＣＮＮの最後の層は、全結合多層パーセプトロン（Multi-Layer Perceptron：ＭＬＰ）と称され、１つ以上の全結合（すなわち、密）層及び最終の分類層を含み得る。ＭＬＰは、例えば、物体クラスを予測（認識）するために、最後の畳み込み層からの特徴マップを使用する。例えば、ＭＬＰは、画像内の物体が家であることを予測し得る。
【００６８】
ニューラルネットワークの目的は、入力データをより有用な出力に変換することである。一例は分類であり、ここで、入力データはＮ個の可能性のあるクラスのうちの１つに分類される（例えば、ある画像が猫又は犬を含むかを分類する）。別の例は回帰であり、ここで、入力データは実数に変換される（例えば、歌のミュージックビートを決定する）。
【００６９】
本説明では、「モデル」及び「ニューラルネットワーク」という用語は、交換可能に使用される。更に、「ニューラルネットワークのウェイト」は、時には、「学習可能パラメータ」又は「パラメータ」と称される。
【００７０】
人工知能（ＡＩ）は、ニューラルネットワーク及び機械学習を含む一般的な用語である。コンピュータビジョン、イメージング、ビッグデータ、及び／又はビジュアル分析などの異なるマーケットセグメントに機械学習ベースのサービスを提供するクラウドベースのＡＩサービスがある。更に、既に市販のスマートフォンの一部にニューラル処理ユニットが搭載されているが、この数は数年以内に著しく増加するものと見込まれる。
【００７１】
ニューラルネットワークの最も重要な用途のうちの１つは、画像／動画分析及び操作にある。画像及び／又は画像シーケンスは、リアルタイム又はバッチモードのいずれかで、携帯電話において異なる機械学習ベースのアルゴリズムで処理される。この処理では、ほとんどの時間において、オリジナル画像ファイルと異なるファイルとして記憶される追加のメタデータを生成する。これについての１つの理由としては、ＪＰＥＧ（Joint Photographic Experts Group）、ＰＮＧ（Portable Network Graphics）、ＴＩＦＦ（Tagged Image File Format）などの現在の画像フォーマットの制限、及びメディアファイルに当該アルゴリズムの結果を記憶するための標準メカニズムの欠如が挙げられる。ＨＥＩＦは、メタデータがファイルの外側にあるのではなく、処理チェーンにおける画像／動画消費の一部になるように構造化された方法で当該情報を含むのに必要な拡張可能性を提供する。
【００７２】
ＡＩベースのメディア処理パイプラインは、メディアデータを操作して結果を「ベイクイン」する（例えば、画像の曝露を変更し、ピクセル値を書き換えることによって）か、又はＡＩアルゴリズムの推測された結果（例えば、顔検出アルゴリズムの結果として検出される顔の境界ボックス）を表す追加のメタデータファイルを生成する。更に、ＡＩアルゴリズム間に特定の依存関係があり得る。一例は、システムがまず顔を検出し、次いで、特有の名前又はＩＤを検出された顔に付与するために、検出された顔の境界ボックスにおいて人認識アルゴリズムを適用することであり得る。このようなカスケーディング動作は、特に、複数のベンダーからの複数のシステムが一緒に動作する必要があるときに、現在、相互に動作可能でない、所有者のインターフェース及びアプリケーションプログラミングインターフェース（Application Programming Interface：ＡＰＩ）を要する。
【００７３】
更に、メディアデータに関連する当該ＡＩメタデータを記憶及びシグナリングするためのメカニズムはない。ＨＥＩＦなどのＭＰＥＧの現在のＩＳＯベースのメディアファイルフォーマット及び派生物、又はＩＳＯベースメディアファイルフォーマットと互換性のある他のフォーマットは、以下についてのいかなる標準化メカニズムも有しない。
１．画像、画像シーケンス、又は動画についてのＡＩ及び機械学習アルゴリズムインターフェース結果の記憶
２．特定の動作を実行する（例えば、複数の顔を検出し、次いで、別々のプロセスとして複数の顔を認識し、それらの関連メタデータを記憶する）ために次々に実行しなければならないカスケードプロセスに関する情報の記憶
３．任意の他のエンティティが、アルゴリズム（又はアルゴリズムの新しいバージョン）を再実行し、次いで、メディアファイル内の関連メタデータを更新し得るように利用されるアルゴリズムに関する情報の記憶
４．データが、結果を利用する他者によって適切に解析され得るように、適用されたＡＩベースのアルゴリズムの結果として記憶されるデータのフォーマットに関する情報の記憶
【００７４】
上述の記憶及びシグナリングメカニズムの欠如は、ＡＩベースのメディア操作サービス及びアルゴリズムの使用及び相互動作可能性を制限し得る。そのようなＡＩベースのアルゴリズムを記憶、交換、操作、及びフィードフォワードするための標準的かつ明確に定義されたメカニズムが欠如していると、現在の業界における問題のいずれかにつながるおそれがあり、エコシステム及び所有者のフォーマット定義が隔離され閉じられたものになる。
【００７５】
レプリゼンテーショナルステートトランスファーＡＰＩ（Representational State Transfer Application Programming Interface：ＲＥＳＴ  ＡＰＩ）ベースのビジュアルＡＩベースの画像及び動画処理サービスを有する既知のクラウドベースのサービスは統合されず、それらは、マルチアルゴリズム動作のカスケーディング及びフィードフォワードタイプではなく、単一の動作に隔離されている。
【００７６】
本実施形態の目的は、ビジュアルＡＩメタデータについての記憶及び相互動作可能な能力を有するように利用され得る、（特にＨＥＩＦについての）ＩＳＯベースのメディアファイルフォーマット及び他のメディアファイルフォーマットについて記憶及びシグナリングメカニズムを定義することである。当該メカニズムを提供することによって、本発明は、相互に動作可能で標準の方法でアルゴリズムの記憶、シグナリング、非破壊編集、及びカスケーディングを可能にする。
【００７７】
本実施形態は、例えば、以下のビジュアルＡＩメタデータ及びプロセスで適用可能である。
・物体検出
・顔検出及び認識
・人の感情
・性別及び年齢予測
・顔ランドマーク分析
・顔ポーズ検出
・光学文字認識（Optical Character Recognition：ＯＣＲ）（ＨＥＩＦでの正確なテキスト及び保存）
・不適切なコンテンツ分析（オートコンテンツフィルタ）
・コンテキスト検出
・コンテキストベースの物体及びセマンティック解析（例えば、ウェディング、ディナー、誕生日、パーティ、スポーツなど）
・動作認識
・ロゴ及び製品検出
・一般的な画像属性（色、光、雰囲気など）
・シーンセマンティック解析
・画像キャプショニング
・セグメンテーション及びアルファマスク
・デプスマップ
・非破壊画像操作（例えば、スタイル変換、アルファマスキング及び画像ブレンディング、「レンズ」、フィルタ、...）
【００７８】
前述のように、本実施形態は、標準的及び効率的な方法で、ＩＳＯＢＭＦＦ準拠ファイルフォーマットでＡＩメタデータの記憶及びシグナリングを可能にする。それを達成するために、以下のファイルフォーマットボックス（すなわち、コンピュータ可読オブジェクト指向構築ブロック）及び関係が、ＩＳＯベースメディアファイルフォーマット準拠アプローチでＡＩ関連メタデータを記憶及びシグナリングするために定義される。
１．ＡＩベースのアルゴリズムに関する記述的メタデータを含む、新しいプロパティボックス
２．ＡＩベースのアルゴリズムメタデータ出力を記憶する新しいボックス。このボックスは、一般的なペイロード定義を有し得るため、任意のＡＩアルゴリズム出力に準拠する。追加のサービス及びスキーム情報が、アルゴリズム出力のセマンティック及びシンタックス情報を提供する。
３．定義されたデータフローで実行する複数のアルゴリズムで構成されたＡＩプロセスに関する情報を含む新しいボックス。
４．時間的に変化する方法でＡＩベースのアルゴリズム出力メタデータを含む、時間指定メタデータトラックについての新しいメディアサンプル定義。
５．上述の新しいボックスを、ＩＳＯベースのメディアファイルフォーマットの他の情報搬送エンティティに関連付けるための関係定義。
【００７９】
本実施形態について、データ搬送メカニズムは、データシンタックスから分離され得る。同時に、ＡＩ特有データを生成するために利用されるＡＩサービスへのポインタが示され得る。これらを達成するために、ＡＩプロパティは、以下のシンタックス要素を含み得る。
１．サービス定義インジケータ
２．サービスのどのバージョンがＡＩデータを生成するために利用されるかを示すサービスバージョン
３．ＡＩサービスに関する更なる詳細を提供するサービス記述
４．記憶されたＡＩデータを解析するためにシンタックス定義を提供するサービススキーマロケーション。このスキーマは、ＡＩデータについての一般的なコンテナを有するのに必要なフレキシビリティを提供する。
５．ＡＩデータを搬送するための一般的なデータ構造。
６．異なるＡＩプロセス間で入力／出力依存性を関連付けるための一般的なメカニズム。例えば、顔認識ＡＩプロセスは、画像内の顔に境界ボックスを提供するために、まず顔検出器に依存する。
７．利用されたニューラルネットワークモデルを記憶するか、又は指し示すための一般的なメカニズム。
【００８０】
本実施形態は、以下の方法に従って上記で表されるシンタックス要素について新しいアイテムプロパティ又は新しいボックスを定義する。
【００８１】
アイテム５：
アイテム５は、ＡＩデータを搬送するための一般的なデータ構造に関する。これは、ＶＡＩデータボックスと呼ばれる新しいボックスを定義することによって実施され得る。このボックスは、アイテムプロパティコンテナボックス、又はメタボックスもしくはメディアボックス内の任意の他の場所に記憶され得る。
【００８２】
ＶＡＩデータボックスのシンタックス定義は、以下のとおりである。
aligned(8) class VAIDataBox
extends FullBox('vaid', version = 0, flags = 0) {
unsigned int(8)vai_data[];
}
【００８３】
vai_dataは、不透明なデータであり、その形式は、存在する場合、schema_locationでリストされるスキーマ、又はサービスによって定義される。
【００８４】
ＶＡＩデータボックスの使用の代わりに、含有構造で直接vai_data[]アレイを含む（例えば、vai_data[]は、以下の実施形態におけるＶＡＩＩプロパティで直接含まれ得る）。
【００８５】
アイテム１、２、３、及び４：
アイテム１、２、３、及び４は、サービス定義インジケータ、サービスバージョン、サービス記述、及びサービススキーマロケーションに関する。これらについて、新しいアイテムプロパティが定義され得る。当該定義は、以下のとおりであり得る。
aligned(8) class VAIIProperty
extends ItemFullProperty('vaii', version = 0, flags = 0)
{
string service;
string service_version;  // オプション
string service_description;  // オプション
string schema_location;  // オプション
VAIDataBox();
}
【００８６】
serviceは、ＶＡＩデータボックスのvai_dataを生成したサービスを識別するために使用された、例えば、ＵＴＦ−８文字を使用するヌル終端文字列としてのＵＲＬ又はＵＲＮエントリーであり得る。
【００８７】
service_versionは、ＵＴＦ−８文字を使用するヌル終端文字列によって定義されるサービスのバージョンであり、空のヌル終端文字列であり得る。
【００８８】
service_descriptionは、ＶＡＩデータボックスを生成した、サービスの人間可読記述を含むヌル終端文字列であり、空のヌル終端文字列であり得る。
【００８９】
schema_locationは、ＶＡＩデータボックスのデータが従うスキーマについての０個以上のＵＲＬのＵＴＦ−８文字における空間分離リストで構成されたヌル終端文字列であり、空のヌル終端文字列であり得る。
【００９０】
上記で使用されるデータタイプは例であり、実施形態は、他のデータタイプでも同様に実現され得ることが理解される必要がある。例えば、サービスを識別するためにＵＲＩを使用する代わりに、ＵＵＩＤ又は登録されたタイプ値（例えば、４文字コード）が識別子として使用され得る。別の例では、service_versionは、符号なし整数値又は符号なし整数値のシーケンス（例えば、メジャーバージョン及びマイナーバージョン）として規定され得る。
【００９１】
実施形態は、上述の１つ以上の要素（service、service_version、service_description、schema_location、ＶＡＩデータボックス）などの任意のセットに適用されるが、それに限定されないことが理解される必要がある。
【００９２】
アイテム６：
アイテム６は、異なるＡＩプロセス間で入力／出力依存性を関連付けるための一般的なメカニズムに関する。これについて、アイテムプロパティリレーションボックスと呼ばれる新しいボックスが、プロパティの入力／出力関係を記憶するために定義され得る。このボックスは、アイテムプロパティボックス（「ｉｐｒｐ」）は、メタボックス内の任意の他のボックス内であり得る。
【００９３】
アイテムプロパティリレーションボックスについてのシンタックス定義は、以下のとおりである。
aligned(8) class ItemPropertyRelationBox
extends FullBox('iprl', version = 0, flags = 0) {
unsigned int (8) input_count;
for (i=0; i<input_count; i++) {
unsigned int(16) property_index;
}
unsigned int (8) output_count;
for (i=0; i< output_count; i++) {
unsigned int(16) property_index;
}
}
【００９４】
input_countは、このプロセスが取り込んだ入力プロパティの数（１からｎ）である。
【００９５】
output_countは、このプロセスが生成した出力プロパティの数（１からｎ）である。
【００９６】
property_indexは、このプロセスの入力又は出力のいずれかによって使用される同じアイテムプロパティボックスに含まれるアイテムプロパティコンテナボックスにおけるプロパティの１ベースのインデックスである。
【００９７】
実施形態では、ボックス「アイテムプロパティリレーションボックス」は、以下のようにアイテムプロパティアソシエーションの新しいバージョン内にあり得る。
aligned(8) class ItemPropertyAssociationBox
extends FullBox('ipma', version, flags)
{
unsigned int(32) entry_count;
for (i = 0; i < entry_count; i++) {
if (version < 1)
unsigned int(16)    item_ID;
else
unsigned int(32)    item_ID;
unsigned int(8) association_count;
for (i=0; i<association_count; i++) {
bit(1) essential;
if (flags & 1)
unsigned int(15) property_index;
else
unsigned int(7) property_index;
}
If (flags & 2)
ItemPropertyRelationBox relation;
}
}
【００９８】
relationは、リストされたitem_IDについてのプロパティ入力／出力関係を定義する。
【００９９】
別の実施形態では、アイテムプロパティ関係は、例えば以下のように、アイテムプロパティアソシエーションボックスの終わりに追加され得る。この実施形態は、従来のパーサーとより互換性があり得る。
【０１００】
aligned(8) class ItemPropertyAssociationBox
extends FullBox('ipma', version, flags)
{
unsigned int(32) entry_count;
for (i = 0; i < entry_count; i++) {
if (version < 1)
unsigned int(16)        item_ID;
else
unsigned int(32)        item_ID;
unsigned int(8) association_count;
for (i=0; i<association_count; i++) {
bit(1) essential;
if (flags & 1)
unsigned int(15) property_index;
else
unsigned int(7) property_index;
}
}
if (flags & 2) {
unsigned int[16] relation_count;
ItemPropertyRelationBox
relation[relation_count];
}
}
【０１０１】
一実施形態によると、アイテムプロパティリレーションボックスは、上記に代わって、データ構造（すなわち、ボックスヘッダなし）であり得る。
【０１０２】
ＡＩペイロードデータは、メタボックス又はメディアデータ（ｍｄａｔ）ボックス内に記憶され得る。
【０１０３】
１．ＡＩペイロードデータは、図３に示されるように、ＡＩプロパティと密に連動して記憶及びシグナリングされるか、又は
２．ＡＩペイロードデータは、図４に示されるように、アイテムとして記憶及びシグナリングされる。
【０１０４】
ＡＩペイロードが、ＡＩプロパティと密に連動して記憶及びシグナリングされるとき、ＶＡＩＩプロパティボックスは、ＶＡＩデータボックスを含み得る。この例では、ＡＩプロパティは、関連ＡＩペイロードデータを含む。図３は、当該記憶メカニズムを有するＨＥＩＦメディアファイル３００を示す。メディアファイル３００は、メディアデータ、すなわち、画像メディアデータを搬送するための「ｍｄａｔ」ボックスを含む。更に、メディアファイル３００は、すべての関連ＡＩメタデータ及びＡＩペイロードデータを搬送するための「ｍｅｔａ」ボックスを含む。したがって、メタデータの修正は、メディアデータオフセットにおいて最小の効果を有し得、それは、再編集の使用ケースで望ましい場合がある。
【０１０５】
ＡＩペイロードがアイテムとして記憶及びシグナリングされるとき、ＡＩペイロードは、メタ又はメディアデータボックスでアイテムとして記憶され得る。この例では、ＡＩプロパティは、メタデータ（例えば、ＡＩペイロードを生成するために使用されたサービスについてのＵＲＩ）を含むが、ＡＩペイロードを含まない。図４は、ＨＥＩＦファイル４００内で当該記憶がどのように見えるかを示す。
【０１０６】
図４に示され得るように、ＡＩペイロード４１０は、「ｍｅｔａ」ボックス内の「ｉｔｅｍ」によって表される不透明なデータとして「ｍｄａｔ」ボックスに記憶され得る。一実施形態では、「ｍｅｔａ」ボックス４１５内の「ｉｄａｔ」ボックス４２０を使用することによって同じ表示が行われ得、不透明なデータとしてのＡＩペイロードの記憶は、「ｍｅｔａ」ボックス４１５内で達成され得る。そのような場合、アイテムロケーションボックス（「ｉｌｏｃ」）４３０で示されるようなＡＩアイテムのconstruction_methodは、１に設定され、それは、idat_offsetに対応する。「ｍｄａｔ」操作が煩雑であるか、又は望ましくない場合に、これが望ましい場合がある。
【０１０７】
このオプションでは、アイテムプロパティリレーションボックスによって以前に表されたＡＩプロセスは、アイテム参照メカニズムによって（「ｉｒｅｆ」ボックスを利用することによって）特定のアイテム参照タイプ（「ｖａｉ」である場合がある）に置き換えられ得る。アイテム参照ボックスは、ＨＥＩＦ仕様（ＩＳＯ／ＩＥＣ  ２３００８−１２）で以下のように定義される。
aligned(8) class SingleItemTypeReferenceBox(referenceType) extends Box(referenceType) {
unsigned int(16) from_item_ID;
unsigned int(16) reference_count;
for (j=0; j<reference_count; j++) {
unsigned int(16) to_item_ID;
}
}
aligned(8) class SingleItemTypeReferenceBoxLarge(referenceType) extends Box(referenceType) {
unsigned int(32) from_item_ID;
unsigned int(16) reference_count;
for (j=0; j<reference_count; j++) {
unsigned int(32) to_item_ID;
}
}
aligned(8) class ItemReferenceBox extends FullBox('iref', version, 0) {
if (version==0) {
SingleItemTypeReferenceBox references[];
} else if (version==1) {
SingleItemTypeReferenceBoxLarge references[];
}
}
【０１０８】
一実施形態によると、「ｖａｉ」と呼ばれる新しいアイテム参照タイプが定義され得る。この参照タイプでは、from_item_IDは、ＡＩペイロードを含むアイテムを表し得、to_item_IDは、ＡＩ結果を生成するための入力としてそれを使用し得るＡＩアイテムＩＤを参照し得る。
【０１０９】
一実施形態によると、参照は、from_item_IDがto_item_IDでリストされるアイテムから入力を要求するＡＩアイテムを表す、「依存」関係であり得る。
【０１１０】
アイテム７：
アイテム７は、利用されたニューラルネットワークモデルを記憶するか、又は指し示すための一般的なメカニズムに関する。これは、ＮＮプロパティと呼ばれ得る新しいプロパティによって、及びこのプロパティボックスに適用されたニューラル情報を記憶することによって実施され得る。このプロパティのシンタックスは、以下のとおりであり得る。
aligned(8) class NNProperty
extends ItemFullProperty('nnpr', version = 0, flags = 0) {
string nn_description;
string nn_representation;
string nn_URL;
NNModelBox();
}
【０１１１】
nn_descriptionは、ニューラルネットワークモード（例えば、「Ｙｏｌｏ検出器」）のテキストの記述である。
【０１１２】
nn_representationは、ニューラルネットワークの（ＮＮ）表示詳細を含む、テキスト又は列挙され十分にフォーマット化された文字列フィールドである。可能性のある値は、［「ｒａｗ」、「ｏｎｎｘ」、「ｈ５」、「ｍｅｔａ」、「ｚｉｐ」など］であり得るが、これらに限定されない。このフィールドは、ニューラルネットワークの表示フォーマットに関する情報を提供する。このフィールドを確認することによって、ＮＮユーザは、どのデコンプレッサ又はフォーマットリーダーを、記憶された又は指し示されたニューラルネットワークモデルにおいて使用しなければならないかを知り得る。
【０１１３】
nn_URLは、ポインタをニューラルネットワークモデルに提供し得るＵＲＩ又はＵＲＬである。nn_URLがヌルであるとき、ＮＮモデルボックスは、存在しなければならず、ニューラルネットワークを含むことが予期される。
【０１１４】
ニューラルネットワークデータモデルは、以下のようにＮＮモデルボックスに記憶され得る。
aligned(8) class NNModelBox
extends FullBox('nnmb', version = 0, flags = 0) {
unsigned int(8)nn_model_data[];
}
【０１１５】
nn_model_dataは、ニューラルネットワークの表示を含む不透明なデータアレイである。
【０１１６】
別の実施形態によると、ＮＮモデルデータは、ＨＥＩＦにおける別のアイテムであり得る。このシナリオでは、ニューラルネットワークモデルデータは、コンテンツクリエータの好みに基づいて、メディアボックス又は「ｍｅｔａ」ボックス内の「ｉｄａｔ」ボックスに記憶され得る。当該シナリオでは、ＮＮモデルアイテムは、タイプ「ｎｎｒｆ」のアイテム参照で画像アイテムにリンクし得る。この４文字コードは一例であり、別のこのようなコードが使用され得る。
【０１１７】
別の実施形態によると、ＮＮモデルボックスなし、又はありのＮＮプロパティが、ニューラルネットワークモデルアイテムに付加され得る。
【０１１８】
時間指定メタデータトラックにおけるＡＩメタデータの記憶：
ＡＩメタデータが、画像シーケンスのサンプル又はビデオトラックのサンプルに属する場合、ＡＩメタデータは、時間指定メタデータトラックのサンプルとして記憶され得る。サンプルは、不透明なデータ又はデータブロブとして記憶され得る。メタデータサンプルについてのサンプル記述は、以下のように定義され得る。
class AIMetaDataSampleEntry() extends MetaDataSampleEntry('aise') {
AIInfoBox();  // オプションで存在し得る
Box[] other_boxes;  // オプション
}
【０１１９】
ＡＩ情報ボックスは、先に定義されたＶＡＩＩプロパティボックスと同じ構造を有し得る。
【０１２０】
各ＡＩメタデータサンプルは、異なるＡＩアルゴリズム又はサービス結果を含み得、ここで、各サービスは、別々のＡＩメタデータサンプルエントリーで定義され、サンプル−チャンクボックス（SampleToChunkBox）内のsample_description_indexフィールドを介してサンプルに割り当てられ得る。
【０１２１】
一実施形態によると、利用されたニューラルネットワークモデル及び関連情報は、メタボックスに記憶され、エンティティ−グループボックス（EntitytoGroup box）を介してメディアトラックに関連付けられた状態になり得る。
【０１２２】
ＡＩベースのアルゴリズムの出力としてもたらされたプレ導出コード化画像についてのメタデータ
以下で記載される実施形態は、ＡＩベースのアルゴリズムの出力によって、修正されたある画像が、次いでコード化され、ＨＥＩＦファイルに記憶された場合に適用可能である。
【０１２３】
プレ導出画像プロパティは、プレ導出コード化画像を生成するために、参照された画像アイテムにおいて適用された導出動作のタイプを示す。この記述的アイテムプロパティは、プレ導出コード化画像に適用可能である。プレ導出画像プロパティは、対応付けられたプレ導出コード化画像のすべての「ｂａｓｅ」参照画像アイテムが、プレ導出コード化画像を生成するためにプレ導出プロパティでリストされるすべての導出動作で利用されたことを示す。
【０１２４】
一実施形態によると、プレ導出アイテムプロパティのシンタックスは、プレ導出で使用されたアルゴリズム（複数可）に関連するメタデータを含むように、以下のように追加される。
aligned aligned(8) class PreDerivationProperty
extends ItemFullProperty('prdp', version = 0, flags = 0) {
unsigned int(8) entry_count;
for (i = 0; i < entry_count; i++) {
unsigned int(32) pre_derivation_4cc;
}
string service;  // オプション
string service_version;  // オプション
string service_description;  // オプション
string schema_location;  // オプション
VAIDataBox();
}
【０１２５】
service、service_version、service_description、schema_location、及びVAIDataBox()のセマンティクスは、上記のように規定され得るか、又はＡＩベースのアルゴリズムだけではなく任意のプレ導出動作に適用されるために一般化され得る。
【０１２６】
「ｖａｉ」などのpre_derivation_4ccの新しい値は、ＡＩアルゴリズムに基づいてプレ導出を示すように定義され得る。あるいは、「ｓｒｖｃ」などのpre_derivation_4ccの新しい値は、示されたサービスに基づいてプレ導出を示すように定義され得る。
【０１２７】
pre_derivation_4ccが新しいタイプ（例えば、「ｖａｉ」又は「ｓｒｖｃ」）に等しいときに、service、service_version、service_description、schema_location、及びVAIDataBox()が存在することが要求され得る。別のアプローチでは、pre_derivation_4ccが新しいタイプに等しいときにのみ、service、service_version、service_description、schema_location、及びVAIDataBox()が条件付きで存在するように、シンタックスが変更される。
【０１２８】
entry_countは、任意のデータがpre_derivation_4cc値のループに従うときに１に等しいことが要求され得る。その結果、サービス関連シンタックス要素がどのプレ導出動作を記載するかが明白になる。
【０１２９】
図５は、インテリジェントコンテンツについてのメディアフォーマットとしてのＨＥＩＦの例を示す。ビジュアルコンテンツ、この例では画像は、撮影デバイス５１０、例えばスマートフォンによって撮影される。この画像は、ＨＥＩＦコンテナに記憶され、ビジュアルＡＩ処理５１５のために、クラウドサービスか、又は撮影デバイスのＡＩ処理ユニットのいずれかに提供される。最初に、ビジュアルコンテンツのコンテキストが、ＡＩ処理５２０で検出される。この例では、コンテキストは、「パーティ」、「誕生日」、「子どもたち」、「楽しい時間」、...のキーワードで定義され得る。コンテキストデータは、メタデータとしてＨＥＩＦコンテナに記憶される。コンテキスト検出の後、画像は処理５２５されて、物体（例えば、「ケーキ」、「キャンディ」、「マフィン」、「キャンドル」、...）及び顔を検出する。顔及び物体についてのデータもまた、メタデータとしてＨＥＩＦコンテナに記憶される。
【０１３０】
実施形態に係るＡＩアルゴリズムのプロセスを、図６を参照してより詳細に説明する。図６に示されるように、プロセスは、例えば、ＨＥＩＦ形式の画像データを受信することによって開始する。最初に、画像プロパティが検出され、その後、コンテキスト、物体、及び顔が検出される。次いで、可能な場合、顔が認識、すなわち、識別される。認識されているそのような人々は、セグメント化される。デプスマップが生成され得、それに基づいて、ボケ効果が、認識された人々について生成され得る。ＡＩアルゴリズムの結果、すなわち、すべての検出／生成されたデータは、メタデータとしてＨＥＩＦファイルに保存され、出力される。ここで出力されているＨＥＩＦコンテナは、画像ファイルだけでなく、ＡＩ処理アルゴリズムから生じた画像の識別されたコンテンツを定義するメタデータも含む。
【０１３１】
図７は、実施形態に係る方法を示すフローチャートである。方法は、コンテナファイルフォーマットでビジュアルデータを受信すること７１０と、１つ以上のコンテンツ要素を検出するためにビジュアルデータを処理すること７２０と、検出された１つ以上のコンテンツ要素、及び上記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶すること７３０と、ビジュアルデータに対応付けてコンテナファイルにメタデータを含めること７４０と、を含む。一実施形態によると、ビジュアルデータは、１つ以上のニューラルネットワークによって処理され得る。あるいは、非ニューラルネットワークベースのアルゴリズムが代わりに、１つ以上のコンテンツ要素を検出するために使用され得る。
【０１３２】
実施形態に係る装置は、コンテナファイルフォーマットでビジュアルデータを受信する手段と、１つ以上のコンテンツ要素を検出するためにビジュアルデータを処理する手段と、検出された１つ以上のコンテンツ要素、及び上記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶する手段と、ビジュアルデータに対応付けてコンテナファイルにメタデータを含める手段と、を備える。前記手段は、少なくとも１つのプロセッサと、コンピュータプログラムコードを含むメモリと、を備え、プロセッサは、プロセッサ回路を更に備え得る。メモリ及びコンピュータプログラムコードは、少なくとも１つのプロセッサによって、様々な実施形態に係る図７の方法を装置に実行させるように構成されている。
【０１３３】
様々な実施形態は、メモリ内にあり、かつ関連装置に前記方法を実行させるコンピュータプログラムコードを利用して実施され得る。例えば、デバイスが、データを処理、受信、及び送信するための回路及び電子機器と、メモリ内のコンピュータプログラムコードと、コンピュータプログラムコードを実行しているときに、デバイスに一実施形態の特徴を実行させるプロセッサと、を備え得る。また更に、サーバのようなネットワークデバイスが、データを処理、受信、及び送信するための回路及び電子機器と、メモリ内のコンピュータプログラムコードと、コンピュータプログラムコードを実行しているときに、ネットワークデバイスに一実施形態の特徴を実行させるプロセッサと、を備え得る。コンピュータプログラムコードは、１つ以上の動作特性を含む。上記動作特性は、上記プロセッサのタイプに基づいて上記コンピュータによって構成を介して定義されており、システムがバスによって上記プロセッサに接続可能であり、システムのプログラム可能な動作特性は、コンテナファイルフォーマットでビジュアルデータを受信することと、１つ以上のコンテンツ要素を検出するためにビジュアルデータを処理することと、検出された１つ以上のコンテンツ要素、及び上記１つ以上のコンテンツ要素を検出するために使用されたプロセスに関する情報を、メタデータとして記憶することと、ビジュアルデータに対応付けてコンテナファイルにメタデータを含めることと、を含む。
【０１３４】
必要があれば、本明細書で説明された異なる機能が、異なる順序及び／又は他と同時に実行され得る。更に、必要があれば、上述の機能及び実施形態のうちの１つ以上は、オプションであってもよく、又は組み合わされてもよい。
【０１３５】
実施形態の様々な態様は、独立請求項で述べられているが、他の態様は、請求項で明示的に述べられる組合せのみではなく、記載された実施形態及び／又は独立請求項の特徴を有する従属請求項からの特徴の他の組合せを含む。
【０１３６】
上記は、例示的な実施形態を記載しているが、これらの説明は、限定する意味で考えられるべきでないことも本明細書で留意されたい。むしろ、いくつかの変形及び修正があり、それは、添付の請求項で定義される本開示の範囲から逸脱することなく行われ得る。
【図１】
2022501891.tif 000003
【図２】
2022501891.tif 000004
【図３】
2022501891.tif 000005
【図４】
2022501891.tif 000006
【図５】
2022501891.tif 000007
【図６】
2022501891.tif 000008
【図７】
2022501891.tif 000009
【手続補正書】
【提出日】令和3年4月21日(2021.4.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテナファイルフォーマットと互換性を有するコンテナファイルでビジュアルデータを受信することと、
１つ以上のコンテンツ要素を検出するために複数のプロセスを用いて前記ビジュアルデータを処理することと、
前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用された前記複数のプロセスに関する情報を、メタデータとして記憶することと、
前記複数のプロセスの間の依存関係を第１の標識及び第２の標識によって示すことであって、前記第１の標識は１つ又は複数の入力を必要とする１つのアイテムを表し、前記第２の標識は前記１つ又は複数の入力を含む複数のアイテムを表す、前記示すことと、
前記ビジュアルデータに対応付けられた前記コンテナファイルに前記メタデータを含めることと、
を含む、方法。
【請求項２】
前記コンテナファイルは、処理アルゴリズムについてのメタデータを含む第１のボックスを含む、請求項１に記載の方法。
【請求項３】
前記コンテナファイルは、前記１つ以上のコンテンツ要素についてのメタデータを含む第２のボックスを含む、請求項１又は２に記載の方法。
【請求項４】
前記コンテナファイルは、複数の処理アルゴリズムのプロセスについてのメタデータを含む第３のボックスを含む、請求項１から３のいずれかに記載の方法。
【請求項５】
前記コンテナファイルは画像シーケンス又は動画を含み、
前記コンテナファイルは、前記メタデータを含むメディアトラックについてのメディアサンプル定義を含む、請求項１に記載の方法。
【請求項６】
前記コンテナファイルは、前記コンテナファイル内の情報を含む他のエンティティとコンテナとの関係を定義するための関係定義を含む、請求項１から５のいずれかに記載の方法。
【請求項７】
前記ビジュアルデータは、前記１つ以上のコンテンツ要素を検出するために、１つ以上のニューラルネットワーク又は１つ以上の非ニューラルネットワークベースのアルゴリズムによって処理される、請求項１から６のいずれかに記載の方法。
【請求項８】
コンテナファイルフォーマットと互換性を有するコンテナファイルでビジュアルデータを受信する手段と、
１つ以上のコンテンツ要素を検出するために複数のプロセスを用いて前記ビジュアルデータを処理する手段と、
前記検出された１つ以上のコンテンツ要素、及び前記１つ以上のコンテンツ要素を検出するために使用された複数のプロセスに関する情報を、メタデータとして記憶する手段と、
異なるプロセス間の依存関係を第１の標識及び第２の標識によって示すことであって、前記第１の標識は１つ又は複数の入力を必要とする１つのアイテムを表し、前記第２の標識は前記１つ又は複数の入力を含む複数のアイテムを表す、前記示すことと、
前記ビジュアルデータに対応付けて前記コンテナファイルに前記メタデータを含める手段と、
を備える、装置。
【請求項９】
前記コンテナファイルは、処理アルゴリズムについてのメタデータを含む第１のボックスを含む、請求項８に記載の装置。
【請求項１０】
前記コンテナファイルは、前記１つ以上のコンテンツ要素についてのメタデータを含む第２のボックスを含む、請求項８又は９に記載の装置。
【請求項１１】
前記コンテナファイルは、複数の処理アルゴリズムのプロセスについてのメタデータを含む第３のボックスを含む、請求項８から１０のいずれかに記載の装置。
【請求項１２】
前記コンテナファイルは、画像シーケンス又は動画であり、
前記コンテナファイルは、前記メタデータを含むメディアトラックについてのメディアサンプル定義を含む、
請求項８に記載の装置。
【請求項１３】
前記コンテナファイルは、前記コンテナファイル内の情報を含む他のエンティティとコンテナとの関係を定義するための関係定義を含む、請求項８から１２のいずれかに記載の装置。
【請求項１４】
前記１つ以上のコンテンツ要素を検出するために前記ビジュアルデータを処理するために、１つ以上のニューラルネットワーク又は１つ以上の非ニューラルネットワークベースのアルゴリズムを更に含む、請求項８から１３のいずれかに記載の装置。
【請求項１５】
少なくとも１つのプロセッサと、コンピュータプログラム命令を有するメモリとを備える装置であって、前記コンピュータプログラム命令は、前記少なくとも１つのプロセッサに実行されると、前記装置に、請求項１から７のいずれかに記載の方法を遂行させるように構成される、装置。
【請求項１６】
装置の処理手段に実行されると、前記装置に、請求項１から７のいずれかに記載の方法を遂行させるように構成されるコンピュータプログラム命令を備える、コンピュータプログラム。
【国際調査報告】
2022501891.tif 000010
2022501891.tif 000011
2022501891.tif 000012
2022501891.tif 000013