(57)【要約】  本開示は、処理を簡潔に行うことができるようにする情報処理装置および情報処理方法、並びにプログラムに関する。３次元構造を表すPoint Cloudを２次元に変換することによってgeometry画像およびtexture画像と、geometry画像およびtexture画像を３次元に構築するのに必要な３次元情報メタデータとが得られる。そして、特定時刻に表示されるPoint Cloudを構成する1 PC sampleが、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを格納して生成される。Point Cloudを配信するためのデータを生成するデータ生成装置に適用できる。
2020008758.tif 000002
【特許請求の範囲】
【請求項１】
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部
を備える情報処理装置。
【請求項２】
前記第１の画像および前記第２の画像を符号化して、第１の画像ストリームおよび第２の画像ストリームを生成する符号化部
をさらに備え、
前記ファイル生成部は、前記第１の画像ストリームおよび前記第２の画像ストリームがそれぞれ復号された後に、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元構造として再構築されるのに必要な復号順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して前記ファイルを生成する
請求項１に記載の情報処理装置。
【請求項３】
前記符号化部は、前記第１の画像および前記第２の画像をnon-layered codingで符号化する
請求項２に記載の情報処理装置。
【請求項４】
前記３次元情報メタデータは、前記第１の画像および前記第２の画像を指し示す情報を含む
請求項３に記載の情報処理装置。
【請求項５】
前記３次元情報メタデータは、Group of Framesを示す情報を含む
請求項３に記載の情報処理装置。
【請求項６】
前記３次元情報メタデータは、同時刻に表示するlayer数およびcomponent数を示す情報を含む
請求項３に記載の情報処理装置。
【請求項７】
前記３次元情報メタデータは、前記３Ｄデータの前記３次元構造の構成要素ごとのコーデック情報を含む
請求項３に記載の情報処理装置。
【請求項８】
前記符号化部は、前記第１の画像および前記第２の画像をlayered codingで符号化する
請求項２に記載の情報処理装置。
【請求項９】
複数の画像を１つのパッキング画像にパッキングするパッキング処理部
をさらに備え、
前記ファイル生成部は、前記パッキング画像、前記３次元情報メタデータ、および、前記パッキングの方法を示すパッキング情報を前記ファイルに格納する
請求項１に記載の情報処理装置。
【請求項１０】
前記パッキング処理部は、同一のlayerの前記第１の画像どうし、および、同一のlayerの前記第２の画像どうしをパッキングする
請求項９に記載の情報処理装置。
【請求項１１】
前記パッキング処理部は、前記第１の画像と前記第２の画像との同一のlayerどうしをパッキングする
請求項９に記載の情報処理装置。
【請求項１２】
前記パッキング処理部は、前記第１の画像および前記第２の画像の全てのlayerをパッキングする
請求項９に記載の情報処理装置。
【請求項１３】
前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、ISOBMFF（ISO Base Media File Format）の1 sampleとして格納することで前記ファイルを生成する
請求項１に記載の情報処理装置。
【請求項１４】
前記第１の画像および前記第２の画像のいずれか一方が前記３次元情報メタデータを含み、前記第１の画像および前記第２の画像で、それぞれが前記1 sampleとして格納される
請求項１３に記載の情報処理装置。
【請求項１５】
前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、異なるトラックに格納することで前記ファイルを生成する
請求項１に記載の情報処理装置。
【請求項１６】
前記３次元情報メタデータは、前記トラックの間の関係性を示す情報を含む
請求項１５に記載の情報処理装置。
【請求項１７】
前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、ISOBMFFでシグナルされる
請求項１５に記載の情報処理装置。
【請求項１８】
前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、DASH（Dynamic Adaptive St reaming over HTTP）のMPD（Media Presentation Description）でシグナルされる
請求項１５に記載の情報処理装置。
【請求項１９】
情報処理装置が、
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
を含む情報処理方法。
【請求項２０】
情報処理装置のコンピュータに、
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
を含む情報処理を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および情報処理方法、並びにプログラムに関し、特に、処理を簡潔に行うことができるようにした情報処理装置および情報処理方法、並びにプログラムに関する。
【背景技術】
【０００２】
従来、非特許文献１で開示されているように、３次元空間上に位置情報および属性情報（特に色情報）を同時に持った点の集合であるPoint Cloudの圧縮方法が規定されている。【０００３】
また、非特許文献２には、Point Cloudの圧縮方法の一つとして、Point Cloudを複数の領域に分割（以下、セグメンテーションと称する）し、領域毎に平面投影してtexture画像およびgeometry画像を生成した後、それらを動画コーデックにより符号化する方法が開示されている。ここで、geometry画像は、Point Cloudを構成する点群のdepth情報から構成される画像である。【０００４】
このようなPoint Cloudの圧縮方法は、PCC TMC2（Point Cloud Coding Test Model Category 2）と呼ばれている。また、PCC TMC2によって生成されたPoint Cloudのstream（以下、PC streamとも称する）の構造は、非特許文献３に開示されている。【０００５】
そして、このようなPC streamを、over IP networkで配信するユースケースが期待されている。そこで、非特許文献４で開示されているように、既存の配信プラットフォームへのインパクトを抑制し、早期のサービス実現を目指すべく、MPEG（Moving Picture Experts Group）において、既存の枠組みであるISOBMFF/DASH（ISO Base Media File Format / Dynamic Adaptive St reaming over HTTP）による配信技術についての検討が開始された。【０００６】
また、特許文献１では、３次元画像データを、サイドバイサイド方式やトップアンドボトム方式などでパッキングして記録する画像処理装置が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−１４２５８６号公報
【非特許文献】
【０００８】
【非特許文献１】MPEG-I Part5 Point Cloud Compression (ISO/IEC 23090-5)
【非特許文献２】w17348, PCC Test Model Category 2 v1, January 2018, Gwangju, Korea
【非特許文献３】w17374, First Working Draft for PCC Category 2, January 2018, Gwangju, Korea
【非特許文献４】w17675, First idea on Systems technologies for Point Cloud Coding, April 2018, San Diego, US
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、上述の非特許文献３で開示されているようなPC streamの構造では、通常再生時にランダムアクセスが多量に発生することになり、Point Cloudを再生するクライアント側における処理が複雑なものとなるため、処理が遅延したり、処理コストが増大したりすることが懸念される。【００１０】
本開示は、このような状況に鑑みてなされたものであり、処理を簡潔に行うことができるようにするものである。
【課題を解決するための手段】
【００１１】
本開示の一側面の情報処理装置は、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部を備える。【００１２】
本開示の一側面の情報処理方法またはプログラムは、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成することを含む。【００１３】
本開示の一側面においては、３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、第１の画像および第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される３Ｄデータを構成する１単位のファイルが、第１の画像および第２の画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、第１の画像および第２の画像と３次元情報メタデータとを格納して生成される。
【発明の効果】
【００１４】
本開示の一側面によれば、処理を簡潔に行うことができる。【００１５】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１６】
【図１】Point Cloudの圧縮方法を説明する図である。
【図２】PC streamの構造を示す図である。
【図３】GOFの構造を示す図である。
【図４】geometry video streamおよびtexture video streamの構造を示す図である。
【図５】新たに定義するPC sampleの構造を示す図である。
【図６】PC sampleの一例を示す図である。
【図７】PC headerに格納される情報の一例を示す図である。
【図８】headerに格納される情報の一例を示す図である。
【図９】GOF headerに格納される情報の一例を示す図である。
【図１０】PC streamをISOBMFFの1 trackに格納する際の一例を示す図である。
【図１１】codec_specific_parametersの定義を示す図である。
【図１２】PCSampleEntryの構造を示す図である。
【図１３】PCHeaderBoxの一例を示す図である。
【図１４】SubSampleEntryBoxの一例を示す図である。
【図１５】LayerCompositionBoxの一例を示す図である。
【図１６】num_layer_composed=2かつnum_of_component=2のPC sampleの一例を示す図である。
【図１７】PCファイル生成処理を実行する情報処理装置の第１の構成例を示すブロック図である。
【図１８】Point Cloud再生処理を実行する情報処理装置の第１の構成例を示すブロック図である。
【図１９】PCファイル生成処理の第１の処理例を説明するフローチャートである。
【図２０】Point Cloud再生処理の第１の処理例を説明するフローチャートである。
【図２１】第１の格納方法におけるISOBMFF構造の一例を示す図である。
【図２２】enhancement trackからbase trackへ、track referenceによる紐づけについて説明する図である。
【図２３】パッキングのバリエーションを示す図である。
【図２４】elementary streamのシグナリングの一例を示す図である。
【図２５】新たに定義するSEIの一例を示す図である。
【図２６】packing_arrangementおよびframe0_is_geometryの定義を説明する図である。
【図２７】frame0の定義を示す図である。
【図２８】PC streamをISOBMFFの1 trackに格納する際の一例を示す図である。
【図２９】PCPackingInfoBoxの一例を示す図である。
【図３０】packed PCファイル生成処理を実行する情報処理装置の第２の構成例を示すブロック図である。
【図３１】Point Cloud再生処理を実行する情報処理装置の第２の構成例を示すブロック図である。
【図３２】packed PCファイル生成処理の第２の処理例を説明するフローチャートである。
【図３３】Point Cloud再生処理の第２の処理例を説明するフローチャートである。
【図３４】PCPackingInfoBoxの変形例を示す図である。
【図３５】第２の格納方法におけるISOBMFF構造の一例を示す図である。
【図３６】elementary streamのシグナリングの一例を示す図である。
【図３７】ISOBMFFのシグナリングの一例を示す図である。
【図３８】GOFEntry()の定義を示す図である。
【図３９】PCFrameEntry()の定義を示す図である。
【図４０】ComponentGroupEntry()の定義を示す図である。
【図４１】sampleのインターリーブ周期の識別について説明する図である。
【図４２】第３の格納方法におけるISOBMFF構造の一例を示す図である。
【図４３】SEIを用いずにシグナルする例について説明する図である。
【図４４】ISOBMFFのシグナリングの一例を示す図である。
【図４５】PCMultiStreamBoxのシンタックスの一例を示す図である。
【図４６】PCMultiStreamBoxの変形例を示す図である。
【図４７】PCTextureTrackGroupのシンタックスの一例を示す図である。
【図４８】PCMultiStreamBoxの変形例を示す図である。
【図４９】track groupで紐づくgeometry trackとtexture trackをシグナルする例を示す図である。
【図５０】新たに定義されるPCStreamGroupBoxの一例を示す図である。
【図５１】第４の格納方法におけるISOBMFF構造の一例を示す図である。
【図５２】DASHのシグナリングについて説明する図である。
【図５３】DASHのシグナリングについて説明する図である。
【図５４】SubSampleInformationBoxの概要を示す図である。
【図５５】Sample Groupの概要を示す図である。
【図５６】データ生成装置の構成例を示すブロック図である。
【図５７】データ再生装置の構成例を示すブロック図である。
【図５８】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００１７】
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００１８】
＜従来の符号化方法＞
本技術を適用した符号化方法について説明する前に、図１乃至図４を参照して、従来の符号化方法について説明する。
【００１９】
図１は、上述した非特許文献２で開示されているPoint Cloudの圧縮方法を、簡略的に説明するための図である。
【００２０】
図１に示すように、まず、３次元構造を表すPoint Cloudが入力され、そのPoint Cloudがセグメンテーションされる。図１に示す例では、半球形状と円錐形状とが組み合わされた３次元構造を表すPoint Cloudが入力され、半球形状を１領域に、円錐形状を２領域に分割した３つの領域にセグメンテーションが行われる。次に、領域ごとに平面投影が行われ、それぞれの領域の表面の見た目を表す色情報からなるtexture画像、および、それぞれの領域の表面までの奥行（depth）を表す位置情報からなるgeometry画像が生成される。そして、texture画像およびgeometry画像が、例えば、AVC（Advanced Video Coding）やHEVC（High Efficiency Video Coding）などの動画像コーデックで符号化される。
【００２１】
図２は、PC streamの構造を示す図である。
【００２２】
図２に示すように、PC streamは1 streamで構成されており、Group of Frames（GOF）という単位において、特定の時間幅で連続的に表示される複数のPoint Cloud frameの構成要素がまとめられている。ここで、Point Cloud frame（以下、PC frameとも称する）は、同時刻に表示されるPoint Cloudのことである。
【００２３】
そして、GOFは、texture画像が符号化されたtexture video stream、geometry画像が符号化されたgeometry video stream、および、2D3D変換に用いる３次元情報メタデータ（auxiliary patch infoおよびoccupancy map）から構成される。ここで、geometry video streamおよびtexture video streamは、（PC streamのframe rate）×（GOF時間幅）×N個（layerの数）の複数のframeを持つ。そして、PC streamの1 frameにつき、geometry video streamおよびtexture video streamは、それぞれN個のframeを持つという特徴がある。これは、Point Cloudの厚み方向の層構造を表現するためである。つまり、それぞれN個のframeから、PC frameが構成されることを意味する。
【００２４】
例えば、クライアントは、PC stream内のgeometry video streamおよびtexture video streamをデコードし、occupancy mapを用いてgeometryパッチとtextureパッチを生成する。その後、クライアントは、auxiliary patch infoを用いて、まずはgeometryパッチから色のないPoint Cloudを生成し、続いて、そのPoint Cloud に対してtextureパッチにより色を付ける。
【００２５】
図３には、従来のPC streamにおけるGOFの構造が示されており、layer数が２である例が示されている。
【００２６】
図３に示すように、従来、特定の時間幅の中で表示されるPC frameがストリーム内で連続配置されない構造となっている。つまり、従来のPC streamでは、PC frame#1の再生に必要な要素と、PC frame#2の再生に必要な要素とが、互いに前後になるように配置される構造となっている。このため、例えば、PC frame#1の再生に必要な要素であるgeometry frame#1 layer0，geometry frame#1 layer1，auxiliary patch info & occupancy map#1，texture frame#1 layer0，texture frame#1 layer1にアクセスし、その後、PC frame#2の再生に必要な要素にアクセスする場合、texture frame#1 layer1より前方の位置に配置されているgeometry frame#2 layer0からアクセスを開始するような処理が発生してしまう。従って、上述したように、通常再生時にランダムアクセスが多量に発生してしまう。
【００２７】
この点で、図３に示すPC stream構造は、既存のビデオコーデックのストリーム構成とも異なっており、ISOBMFFへの格納およびover IP（Internet Protocol）での配信に適していない。
【００２８】
例えば、上述した非特許文献４では、geometry video streamとtexture video streamとを、streamごとに独立したものとして取り扱い、個別のtrackに格納する手法が開示されている。しかしながら、この手法においても、通常再生時にランダムアクセスが多量に発生することになってしまう。
【００２９】
また、この非特許文献４で開示されている手法は、図４に示すように、geometry video streamおよびtexture video streamを取得する際、各streamのbitrateをネットワーク帯域幅に応じて選択し、最適な品質のPCCを再構成するというユースケースに有用である。これは、サーバに多数のsingle stream（bitrateの異なるgeometry video streamとtexture video streamとの組み合わせ）を配置する負担がなくなるからである。
【００３０】
そこで、以下で説明する実施の形態は、このようなユースケースを実現する上で、PC streamを構成するgeometry video streamとtexture video streamとの紐づけ方法を新たに定義することで、クライアントにおける処理を簡潔に行うことができるようにするものである。
【００３１】
＜ISOBMFF格納のためのPC sample定義＞
図５を参照して、ISOBMFF格納のために新たに定義するPoint Cloud sample（以下、PC sampleと称する）について説明する。
【００３２】
図５は、新たに定義するPC sampleの構造を示す図である。
【００３３】
まず、同時刻に表示されるPoint Cloudを構成する単位を1 PC frameと呼び、1 PC frameは1 PC sampleから構成されると定義する。そして、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを、ISOBMFFの1 trackに格納する。このように定義することで、クライアントは、1 PC sampleをデコードすることによって同時刻に表示されるPoint Cloudを構成可能となる。これにより、クライアントは、上述したような通常再生中に多量のランダムアクセスが発生することを回避することができ、処理を簡潔に行うことができるため、例えば、処理の遅延や処理コストの増大などを回避することができる。
【００３４】
このように定義されたPC streamは、複数のPC sampleの連続で構成される。
【００３５】
図５に示すように、1 PC sampleは、複数のcomponentと３次元情報メタデータとで構成される。ここで、componentには、texture画像およびgeometry画像が含まれる。また、３次元情報メタデータは、auxiliary patch infoおよびoccupnacy map、並びにPC headerからなる。
【００３６】
また、１つのcomponentは、複数のsubsampleから構成される。つまり、１つのcomponentは、Ｎ個（layer）のgeometry subsample、および、Ｎ個（layer）のtexture subsampleから構成される。
【００３７】
そして、geometry subsamplesおよびtexture subsamplesは、それぞれ個別に動画コーデックで符号化される。ここで、subsampleは、geometry video streamおよびtexture video streamの1 pictureを構成する単位となる。
【００３８】
また、PC headerは、componentのlayer構造を示す情報を持つ。また、occupancy mapは、componentのピクチャ内のパッチ位置情報を持ち、auxiliary patch infoは、パッチを３Ｄオブジェクトに張り付けるための2D3D変換情報を持つ。
【００３９】
なお、GOF情報は、PC header内に含まれるが、PC sample内に個別にGOF headerをシグナルしてもよい。また、PC headerやauxiliary patch infoおよびoccupancy mapなどのような３次元情報メタデータを、subsampleとしてもよい。
【００４０】
＜第１の格納方法＞
図６乃至図１９を参照して、ISOBMFFの1 trackにPC streamを格納する方法である第１の格納方法について説明する。
【００４１】
図６乃至図９を参照して、elementary streamのシグナリングについて説明する。
【００４２】
図６には、layer数が２であり、かつ、符号化に用いた動画コーデックがAVCまたはHEVCである場合におけるPC sample（即ち、ISOBMFFのsample）の一例が示されている。ここで、図６に示されているAUD（Access Unit Delimiter）は、AVCまたはHEVCのaccess unit境界にシグナルされるNAL（Network Abstraction Layer） unitである。
【００４３】
図６に示すPC sampleは、PC headerに続いて、layer0のgeometry subsample、layer1のgeometry subsample、layer0のtexture subsample、およびlayer1のtexture subsampleが連続的に配置された構成となっている。
【００４４】
図７には、図６のPC headerに格納される情報の一例が示されている。
【００４５】
図７に示すように、PC headerには、例えば、PC sampleのサイズを示す情報（size_of_pc_frame）、および、1PC frameを構成するtexture画像またはgeometry画像のlayer数を示す情報（number_of_layer）が格納される。また、PC headerには、geometry画像またはtexture画像の幅を示す情報（frameWidth）、geometry画像またはtexture画像の高さを示す情報（frameHeight）、および、occupnacy mapの解像度を示す情報（occupancyResolution）が格納される。さらに、PC headerには、平滑化のための近傍点を検出する半径を示す情報（radiusToSmoothing）、平滑化に使用する近傍点の最大数を示す情報（neighborCountSmoothing）、境界点を検出する半径を示す情報（radius2BoundaryDetection）、および、平滑化閾値を示す情報（thresholdSmoothing）が格納される。
【００４６】
図８には、図６のheaderに格納される情報の一例が示されている。
【００４７】
図８に示すように、headerには、texture画像またはgeometry画像のsubsampleのサイズを示す情報（size_of_sample）、subsampleのタイプを示す情報（type）、および、subsampleのlayer識別子（layer_id）が格納される。例えば、subsampleのタイプを示す情報が０である場合、subsampleがgeometry画像であることを示し、subsampleのタイプを示す情報が１である場合、subsampleがtexture画像であることを示す。
【００４８】
また、occupancy mapおよびauxiliary patch infoは、geometry subsampleにSEI (Supplemental Enhancement Infromation)として含まれる。
【００４９】
これらのシグナリングによれば、クライアントは、PC headerからPC sampleの境界を識別可能であり、headerから各componentのsubsampleの境界を識別可能である。従って、クライアントは、それらの境界に従って、PC sampleからgeometry video streamおよびtexture video streamを抽出し、それぞれデコーダに入力してデコード処理を実施することができる。
【００５０】
なお、occupancy mapおよびauxiliary patch infoは、layer間で同じであれば同一の情報が各layerのsubsampleにシグナルされる。但し、layerごとに、その情報が異なっていてもよい。また、SEIは、texture subsampleにシグナルされてもよい。
【００５１】
また、PC streamのGOF先頭に、公知のGOF headerをシグナルしてもよい。
【００５２】
図９には、GOF headerに格納される情報の一例が示されている。
【００５３】
図９に示すように、GOF headerには、例えば、Group of Frames内のフレーム数を示す情報（group0fFramesSize）が格納される。その他、GOF headerには、図７に示したPC headerと同じ情報が格納される。
【００５４】
なお、occupancy mapを動画コーデックで符号化し、componentの一種として、occupancy subsampleとしてもよい。
【００５５】
図１０乃至図１６を参照して、ISOBMFFのシグナリングについて説明する。
【００５６】
図１０には、PC streamをISOBMFFの1 trackに格納する際の一例が示されている。
【００５７】
例えば、ISOBMFFのmoovには、新たに定義するPCSampleEntry（図１２参照）が格納され、PCSampleEntryは、図１３に示すPCHeaderBox、図１４に示すSubSampleEntryBox、および、図１５に示すLayerCompositionBoxからなる。
【００５８】
また、ISOBMFFのmoofには、subs（SubSampleInformationBox）が格納され、図１０に示すように、SubSampleInformationBoxを利用して、PC sample内のgeometry subsampleとtexture subsampleとの境界をシグナルすることができる。なお、SubSampleInformationについては、後述の図５４に示すSubSampleInformationBoxの概要を参照して説明する。
【００５９】
そして、ISOBMFFのmdatに格納されるsampleとして、図６に示したようなPC sampleが格納される。
【００６０】
ここで、SubSampleInformationBoxにおいて、符号化コーデックごとに決まるsubsampleの情報であるcodec_specific_parametersが定義される。
【００６１】
即ち、図１１に示すように、codec_specific_parametersの値が０であるとき、subsampleはgeometry subsampleであることを示し、codec_specific_parametersの値が１であるとき、subsampleはtexture subsampleであることを示す。
【００６２】
なお、codec_specific_parametersにlayer識別子の情報を含んでもよい。また、subsample informationは、連続するgeometry subsample群、texture subsample群の単位で提供されてもよい。さらに、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種としsubsampleとしてシグナルする場合は、subsample informationに、それぞれのsubsampleを示す値を追加してもよい。
【００６３】
図１２には、本開示で新たに定義するPCSampleEntryの構造が示されている。
【００６４】
図１２に示す構成において、PC streamを格納するISOBMFFのtrackのsample entryは、例えば、'pcbs'となる。
【００６５】
図１３に示すように、PCHeaderBoxには、図７に示したPC headerと同一の情報が記述される。
【００６６】
例えば、PC stream内でPC header情報が変化する場合、PCHeaderBoxの情報をsample groupとしてシグナルしてもよい。また、GOF headerの情報は、PCHeaderBoxと個別に、sample entryやsample groupなどにシグナルしてもよい。なお、Sample Groupについては、後述の図５５に示すSample Groupの概要を参照して説明する。
【００６７】
また、このとき、PC sample内のPC headerおよびheaderはシグナルされなくてもよい。
【００６８】
そして、これらのシグナリングによれば、クライアントはsubsampleの中身をパースすることなく、PC sampleの境界および各componentのsubsampleの境界を識別可能である。つまり、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC sampleからgeometry video streamおよびtexture video streamを抽出し、それぞれデコーダに入力してデコード処理を実施することができる。
【００６９】
図１４に示すように、SubSampleEntryBoxは、連続するsubsampleで構成されるtexture video stream、geometry video streamのコーデック、および、decoder configuration情報をシグナルする。
【００７０】
図１４に示すnum_of_componentは、trackに格納されるcomponentの総数を示し、typeフィールドは、sub sample entryが対応するcomponentの種類を表す。例えば、typeフィールドが０である場合、sub sample entryが対応するcomponentの種類はgeometry画像であることを示し、typeフィールドが１である場合、sub sample entryが対応するcomponentの種類はtexture画像であることを示す。SampleEntry()は、componentの符号化コーデックに応じて変化し、例えば、HEVC符号化されている場合にはHEVCSampleEntryとなる。
【００７１】
また、各sub sample entryが対応するsubsampleへの紐づけは、sub sample informationのcodec_specific_parametersおよびsub sample entryのtypeでシグナルされるcomponentの種類によって行われる。なお、componentのtypeごとに、符号化コーデックを変更してもよい。
【００７２】
このシグナリングによれば、クライアントは、geometry video streamおよびtexture video streamのコーデックを識別し、正しくデコード処理を実行することができる。
【００７３】
図１５に示すように、LayerCompositionBoxは、composition timeが同一となるlayer数、および、PC sampleを構成するcomponentの数をシグナルする。
【００７４】
例えば、num_layer_composedは、output orderで1 PC frameを構成するdecoded picture数を示す。また、num_of_componentは、1 PC frameを構成するcomponent数を示す。
【００７５】
なお、上述したようにsample entryにシグナルする例について説明したが、この場所に限らず、例えばSubSampleEntryBoxにシグナルされてもよい。このシグナリングによれば、異なるcomposition timeが割り当てられている各componentの各layerのsubsampleにおいて、同時刻に表示されるPoint Cloudを構成し、同時にレンダリングすべきsubsampleを明示的に示すことができる。これにより、クライアントは、正しくPoint Cloudを構成してレンダリングすることができる。
【００７６】
図１６には、output orderで1 PC frameを構成するdecoded picture数が２（num_layer_composed=2）であって、かつ、1 PC frameを構成するcomponent数がgeometry画像とtexture画像との２（num_of_component=2）である、合計4 subsamplesから構成されるPC sampleの一例が示されている。このようなPC sampleについては、図１５に示したLayerCompositionBoxの情報により、4 subsamplesから構成されることが示される。
【００７７】
なお、component数が１であって、layer数が２である構成は、従来の技術、例えば、ステレオ映像におけるtemporal interleavingと同様の考え方となる。しかしながら、本技術は、component数が複数であって、layer数が複数である構成への対応を可能としている点で、そのような構成への対応ができない従来の技術とは異なるものである。
【００７８】
＜情報処理装置の第１の構成例＞
図１７は、コンテンツを提供するサーバ側で、Point CloudコンテンツからPC streamを生成し、そのPC streamをISOBMFFに格納したPCファイルを生成するPCファイル生成処理を実行する情報処理装置の第１の構成例を示すブロック図である。
【００７９】
図１７に示すように、情報処理装置１１は、3D2D変換部２１、符号化部２２、PC stream生成部２３、およびファイル生成部２４を備えて構成される。
【００８０】
3D2D変換部２１は、入力されるPoint Cloudを２次元に変換することによって、geometry画像およびtexture画像と、３次元情報メタデータ（auxiliary patch infoおよびoccupancy map）とを生成して、符号化部２２に供給する。
【００８１】
符号化部２２は、geometry画像と３次元情報メタデータから、３次元情報メタデータをSEIとして含むgeometry video streamを符号化し、texture画像からtexture video streamを符号化する。例えば、符号化部２２AVCおよびHEVCといったnon-layered coding、または、SVCやSHEVCなどのようなlayered codingで符号化を行う。このとき、符号化部２２は、２台のエンコーダ２５−１および２５−２によって、geometry画像の符号化とtexture画像の符号化とを並列的に行うことができる。
【００８２】
PC stream生成部２３は、符号化部２２により符号化されたgeometry video streamおよびtexture video streamを、PC frameを構成する単位でインターリーブし、図５に示したようなPC sampleを生成する。そして、PC stream生成部２３は、複数のPC sampleからなるPC streamを生成して、ファイル生成部２４に供給する。
【００８３】
ファイル生成部２４は、geometry画像およびtexture画像を３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、geometry画像およびtexture画像と３次元情報メタデータとを、ISOBMFFの1 trackに格納し、PCファイルを生成する。
【００８４】
このように構成される情報処理装置１１は、Point CloudコンテンツからPC streamを生成し、そのPC streamをISOBMFFの1 trackに格納したPCファイルを出力することができる。
【００８５】
図１８は、コンテンツを再生するクライアント側で、PCファイルから表示画像を生成してPoint Cloudを再生するPoint Cloud再生処理を実行する情報処理装置の第１の構成例を示すブロック図である。
【００８６】
図１８に示すように、情報処理装置１２は、抽出部３１、復号部３２、2D3D変換部３３、および表示処理部３４を備えて構成される。
【００８７】
抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、PCファイルから、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出して復号部３２に供給する。
【００８８】
復号部３２は、抽出部３１から供給されるgeometry video streamおよびtexture video streamを復号して、2D3D変換部３３に供給する。このとき、復号部３２は、２台のデコーダ３５−１および３５−２によって、geometry画像の復号とtexture画像の復号とを並列的に行うことができる。
【００８９】
2D3D変換部３３は、geometry video streamに含まれるSEI情報をもとに、Point Cloudを構築する。
【００９０】
表示処理部３４は、2D3D変換部３３により構築されたPoint Cloudを、クライアントの表示デバイスに合わせてレンダリングし、表示画像を生成して、図示しない表示デバイスに表示させる。
【００９１】
このように構成される情報処理装置１２は、PCファイルからPoint Cloudを再生して、Point Cloudをレンダリングした表示画像を表示させることができる。
【００９２】
＜PCファイル生成処理およびPoint Cloud再生処理の第１の処理例＞
図１９は、図１７の情報処理装置１１が、Point CloudからPCファイルを生成するPCファイル生成処理を説明するフローチャートである。
【００９３】
例えば、情報処理装置１１にPoint Cloudの入力が行われると処理が開始され、ステップＳ１１において、3D2D変換部２１は、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する。
【００９４】
ステップＳ１２において、符号化部２２は、ステップＳ１１で3D2D変換部２１により生成されたgeometry画像および３次元情報メタデータから、３次元情報メタデータをSEIとして含むgeometry video streamを符号化し、texture画像からtexture video streamを符号化する。
【００９５】
ステップＳ１３において、PC stream生成部２３は、PC frameを構成する単位（PC sample）でインターリーブし、PC streamを生成する。
【００９６】
ステップＳ１４において、ファイル生成部２４は、PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納し、PCファイルを生成する。このとき、ISOBMFFのsampleはPC sampleとなる。
【００９７】
図２０は、図１８の情報処理装置１２が、PCファイルから表示画像を生成して再生するPoint Cloud再生処理を説明するフローチャートである。
【００９８】
例えば、情報処理装置１２へPCファイルの先端から供給が始まると処理が開始され、ステップＳ２１において、抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、PCファイルから、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出する。
【００９９】
ステップＳ２２において、復号部３２は、geometry video streamおよびtexture video streamを、それぞれ個別に復号する。このとき、geometry video streamおよびtexture video streamは２デコーダインスタンスによる個別のデコードとなる。
【０１００】
ステップＳ２３において、2D3D変換部３３は、geometry video streamに含まれるSEI情報をもとに、Point Cloudを構築する。
【０１０１】
ステップＳ２４において、表示処理部３４は、クライアントの表示デバイスに合わせ、Point Cloudをレンダリングして表示画像を表示させる。
【０１０２】
ステップＳ２５において、抽出部３１は、PC streamの終端か否かを判定し、PC streamの終端でない場合には処理はステップＳ２１に戻り、PC streamの終端である場合には、処理は終了される。
【０１０３】
以上のようなPCファイル生成処理およびPoint Cloud再生処理によって、クライアント側における処理が簡潔に行えるようにすることができる。
【０１０４】
ここで、図２１には、第１の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
【０１０５】
なお、変形例として、第１の格納方法でPC streamをISOBMFFの構造に格納する際に、後述の第３の格納方法におけるISOBMFFのシグナリングと同様に、Group of Framesの境界を、sample groupを用いてシグナルしてもよい。また、elementary streamの符号化において、AVCおよびHEVCといったnon-layered codingではなく、SVC（Scalable Video Coding）やSHEVC（Scalable High Efficiency Video Coding）などのようなlayered codingを用いてもよい。
【０１０６】
例えば、geometry video streamおよびtexture video streamのlayer 0はbase layerとして符号化され、geometry video streamおよびtexture video streamのlayer 1はenhancement layerとして符号化される。
【０１０７】
即ち、図２２に示すように、ISOBMFFの1 trackに1 layerが格納される場合には、enhancement trackには、enhancement layerのgeometry video streamおよびtexture video streamが格納され、base trackには、base layerのgeometry video streamおよびtexture video streamが格納される。そして、enhancement trackからbase trackへ、track reference（参照タイプ'sbas'）で紐づけが行われる。このとき、base trackのsample entryはPCSampleEntry（'pcbs'）とし、enhancement trackのsample entryはPCEnhancementSampleEntry（'penh'）とする。例えば、enhancement trackは、layer数分に応じて存在する。
【０１０８】
ここで、例えば、各trackに格納されているlayerが、layer 0およびlayer 1のどちらであるかを示すために、PC sample内のheaderでシグナルされるlayer識別子（例えば、図８のlayer_id）を、各trackのsample entryでシグナルしてもよい。または、PC sample内のheaderそのものを、各trackのsample entryに格納してもよい。
【０１０９】
＜第２の格納方法＞
【０１１０】
図２３乃至図３５を参照して、geometry/texture video streamを1 streamにパッキングしてISOBMFFの1 trackに格納する方法である第２の格納方法について説明する。
【０１１１】
上述した第１の格納方法では、符号化前のtexture画像およびgeometry画像をインターリーブし、一つのvideo streamとして符号化することで、１デコーダによるデコード処理を実現することは可能である。しかしながら、そのような符号化では、texture画像とgeometry画像との間に相関が少ないことより、圧縮効率が悪化してしまう。
【０１１２】
また、第１の格納方法では、生成されたシングルストリームを１デコーダでデコードすることも可能である。しかしながら、符号化されたtexture画像とgeometry画像との境界でデコーダの初期化が必要となることより、オーバーヘッドが大きくなってしまう。
【０１１３】
つまり、第１の格納方法では、PCファイル生成処理において、texture video streamおよびgeometry video streamを個別に符号化し、Point Cloud再生処理において、geometry video streamおよびtexture video streamに対して２デコーダインスタンスによる個別のデコードが必要であった。このため、第１の格納方法を、１デコーダインスタンスによるデコードに適用すると、圧縮効率が悪化してしまい、また、オーバーヘッドが大きくなってしまう。
【０１１４】
そこで、第２の格納方法では、複数の画像を、上述した特許文献１に記載の方法などで１つの画像にパッキングし、符号化してPC streamを構成する。例えば、複数componentの画像を１つの画像にパッキングしたり、複数layerの画像を１つの画像にパッキングしたり、複数componentの複数layerの画像を１つの画像にパッキングすることができる。これにより、上述したような圧縮効率の悪化を回避しつつ、クライアントによる１デコーダインスタンスでのデコード処理を可能にする。なお、パッキングの方法としては、side by sideやtop & bottomなどの方法を採用するだけでなく、その他の方法を採用してもよい。
【０１１５】
図２３を参照して、パッキングのバリエーションについて説明する。
【０１１６】
図２３のＡには、side by sideの方法で、同一のlayerを異なるcomponentどうしで１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 0のgeometry画像とをside by sideで１つの画像にパッキングし、layer 1のtexture画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。
【０１１７】
図２３のＢには、side by sideの方法で、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 1のtexture画像とをside by sideで１つの画像にパッキングし、layer 0のgeometry画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。
【０１１８】
なお、図２３のＢに示すパッキングでは、１デコーダインスタンスでのデコード処理は可能であるものの、上述したようにtexture画像とgeometry画像との間に相関が少ないため、圧縮効率の悪化を改善することにはならない。しかしながら、layer間で画像の相関が高い場合においては、パッキングされた画像内で参照関係を持たせることで、符号化効率の向上を図ることができる。なお、図２３のＢに示すパッキングは、後述する第４の格納方法のように、geometry video streamおよびtexture video streamを分割してtrackに格納する場合において有効なパッキングとなる。
【０１１９】
図２３のＣには、side by sideの方法で、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングした２枚の画像を、top & bottomの方法で１つの画像にパッキングすることで、全てのcomponentにおける全てのlayerの画像を１つの画像にパッキングする例が示されている。即ち、layer 0のtexture画像とlayer 1のtexture画像とをside by sideで１つの画像にパッキングするとともに、layer 0のgeometry画像とlayer 1のgeometry画像とをside by sideで１つの画像にパッキングする。そして、それらの２つの画像を、top & bottomで１つの画像にパッキングすることで、layer 0のtexture画像、layer 1のtexture画像、layer 0のgeometry画像、およびlayer 1のgeometry画像が１つの画像にパッキングされる。
【０１２０】
ここで、以下、図２３を参照して説明したように、複数の画像をパッキングした１枚の画像をpacked PC画像と称する。そして、packed PC画像の連続を符号化したものを、packed PC streamと称し、packed PC streamをISOBMFFに格納したものをpacked PCファイルと称する。
【０１２１】
なお、ここで説明した第２の格納方法におけるパッキング方法は、geometry画像およびtexture画像のように、それぞれ大きく異なる画像をパッキングする点で、例えば、視差を利用した立体視に関する先行技術であるステレオパッキングとは異なる技術である。
【０１２２】
以下では、図２３のＡに示したように、同一のlayerの画像を異なるcomponentどうしで１つの画像にパッキングしたpacked PC画像を用いた例について説明する。
【０１２３】
図２４には、elementary streamのシグナリングの一例が示されている。
【０１２４】
図２４では、layer数が２であり、かつ、符号化に用いた動画コーデックがAVCまたはHEVCの場合におけるPC sampleの一例が示されている。
【０１２５】
図２４に示すように、geometry画像およびtexture画像を１つの画像にパッキングしたpacked PC streamを構成する１つのpacked PC画像を1 subsampleとしている点で、第１の格納方法（上述の図６参照）とは異なる。
【０１２６】
また、第２の格納方法では、headerは、第１の格納方法で定義した情報に加え、subsampleのタイプとしてgeometry+textureをシグナルする。
【０１２７】
例えば、図２５に示すように、SEIとして、point cloud frame packing SEIを新たに定義してシグナルすることができる。図２５に示されているSEIは、geometry画像およびtexture画像のパッキング方法についての情報を持つ。
【０１２８】
例えば、図２６に示すように、SEIにおいて、packing_arrangementが０である場合、パッキングがside by sideであることを示し、packing_arrangementが１である場合、パッキングがtop & bottomであることを示す。また、packing_arrangementが、その他である場合、パッキングがreservedであることを示す。同様に、SEIにおいて、frame0_is_geometryが０である場合、frame0がgeometryであることを示し、frame0_is_geometryが１である場合、frame0がtextureであることを示す。
【０１２９】
ここで、frame0の定義は、図２７に示すようになる。例えば、side by sideの場合には、図２７のＡに示すように、frame0が左側、かつ、frame1が右側となるようにパッキングされる。また、top & bottomの場合には、図２７のＢに示すように、frame0が上側、かつ、frame1が下側となるようにパッキングされる。
【０１３０】
なお、この情報のシグナルはSEIに限らず他の場所でシグナルしてもよく、例えばPC headerでシグナルしてもよい。また、パッキング方法には、side by sideおよびtop & bottom以外の方法を用いてもよい。
【０１３１】
また、クロマサブサンプリングが4:2:2や4:2:0などである場合、色差信号間引きを考慮し、パッキングされる各componentの幅および高さを２の倍数のピクセル数とすることで、エンコード処理やcomponent切り出し処理などを容易に行うことができる。また、パッキングされる各componentの幅および高さを、８または１６の倍数のピクセル数とすることで、エンコード時のブロックサイズとの親和性を高めることができ、エンコード処理やcomponent切り出し処理などを容易に行うことができる。
【０１３２】
以上のように、これらのシグナリングによれば、PC headerからPC sampleの境界を識別可能であり、headerでsubsampleの境界を識別可能である。また、point cloud frame packing SEIからtexture画像およびgeometry画像の分離が可能となる。これにより、クライアントは、subsampleをデコードした後、正しくPoint Cloudを構成してレンダリングが可能となる。
【０１３３】
図２８には、packed PC画像を符号化したpacked PC streamをISOBMFFの1 trackに格納する際の一例が示されている。
【０１３４】
図２８に示すように、SubSampleInformationBox（'subs'）のcodec_specific_parametersの値が２であるとき、subsampleはgeometry&texture subsampleであることを示す。即ち、第２の格納方法では、codec_specific_parametersの値について、図１１を参照して説明した０および１に追加して２が用いられる点で、第１の格納方法とは相違する。このように、SubSampleInformationBoxを利用して、PC sample内のgeometry&texture subsampleの境界をシグナルすることができる。なお、SubSampleInformationについては、後述の図５４に示すSubSampleInformationBoxの概要を参照して説明する。
【０１３５】
また、図２９に示すように、図２５に示したpoint cloud frame packing SEIと同様に、texture画像およびgeometry画像のパッキング方法についての情報を持つPCPackingInfoBoxがsample entryにシグナルされる。
【０１３６】
なお、第２の格納方法においても、第１の格納方法で説明した変形例を、同様に適用することができる。
【０１３７】
また、第２の格納方法は、例えば、第１の格納方法でのrestricted schemeとして運用され、sample entryは'resv'となり、SchemeTypeBoxのscheme_typeは'pacp'となる。このとき、ポストデコード処理に使用されるPCPackingInfoBoxは、図２８に示したように、rinf/schi下にシグナルされる。
【０１３８】
＜情報処理装置の第２の構成例＞
図３０は、コンテンツを提供するサーバ側で、Point CloudコンテンツからPCファイルを生成するPCファイル生成処理を実行する情報処理装置の第２の構成例を示すブロック図である。なお、図３０に示す情報処理装置１１Ａにおいて、図１７の情報処理装置１１と共通する構成については、同一の符号を付し、その詳細な説明は省略する。
【０１３９】
図２０に示すように、情報処理装置１１Ａは、3D2D変換部２１、符号化部２２Ａ、PC stream生成部２３、ファイル生成部２４、およびパッキング処理部２６を備えて構成される。
【０１４０】
即ち、情報処理装置１１Ａは、パッキング処理部２６を備え、符号化部２２Ａが１台のエンコーダ２５を有する点で、図１７の情報処理装置１１と異なる構成となっている。
【０１４１】
パッキング処理部２６は、上述したようなパッキング方法で、texture画像およびgeometry画像、並びに、それらの各layerをパッキングして、packed PC画像を符号化部２２Ａに供給する。
【０１４２】
符号化部２２Ａは、１台のエンコーダ２５でpacked PC画像を符号化することができる。
【０１４３】
図３１は、コンテンツを再生するクライアント側で、packed PCファイルから表示画像を生成してPoint Cloudを再生するPoint Cloud再生処理を実行する情報処理装置の第２の構成例を示すブロック図である。なお、図３１に示す情報処理装置１２Ａにおいて、図１８の情報処理装置１２と共通する構成については、同一の符号を付し、その詳細な説明は省略する。
【０１４４】
即ち、情報処理装置１２Ａは、復号部３２Ａが１台のデコーダ３５を有する点で、図１８の情報処理装置１２と異なる構成となっている。
【０１４５】
情報処理装置１２Ａでは、抽出部３１が、ISOBMFFのBoxでシグナルされる情報をもとに、packed PCファイルから、再生時刻に対応するpacked PC streamを抽出し、復号部３２Ａが、１台のデコーダ３５でpacked PC streamを復号することができる。
【０１４６】
＜packed PCファイル生成処理およびPoint Cloud再生処理の処理例＞
図３２は、図３０の情報処理装置１１Ａが、Point Cloudからpacked PC streamを生成し、そのpacked PC streamをISOBMFFに格納したpacked PCファイルを生成するpacked PCファイル生成処理を説明するフローチャートである。
【０１４７】
例えば、情報処理装置１１ＡにPoint Cloudの入力が行われると処理が開始され、ステップＳ３１において、3D2D変換部２１は、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する。
【０１４８】
ステップＳ３２において、パッキング処理部２６は、texture画像およびgeometry画像、並びに、それらの各layerをパッキングして、packed PC画像を生成する。
【０１４９】
ステップＳ３３において、符号化部２２Ａは、ステップＳ３２で3D2D変換部２１により生成されたpacked PC画像を符号化する。
【０１５０】
ステップＳ３４において、PC stream生成部２３は、packed PC streamを構成する単位でインターリーブし、３次元情報メタデータおよびパッキング情報をSEIとして含むpacked PC streamを生成する。
【０１５１】
ステップＳ３５において、ファイル生成部２４はpacked PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納して、packed PCファイルを生成する。このとき、ISOBMFFのsampleはPC sampleとなる。
【０１５２】
図３３は、図３１の情報処理装置１２Ａが、packed PCファイルから表示画像を生成して再生するPoint Cloud再生処理を説明するフローチャートである。
【０１５３】
例えば、情報処理装置１２ＡへPC streamの先端から供給が始まると処理が開始され、ステップＳ４１において、抽出部３１は、ISOBMFFのBoxでシグナルされる情報をもとに、packed PCファイルから、再生時刻に対応するpacked PC streamを抽出する。
【０１５４】
ステップＳ４２において、復号部３２Ａは、packed PC streamを復号する。このとき、packed PC streamは１デコーダインスタンスによるデコードとなる。
【０１５５】
ステップＳ４３において、2D3D変換部３３は、パッキング情報と、packed PC streamに含まれるSEI情報をもとに、Point Cloudを構築する。
【０１５６】
ステップＳ４４において、表示処理部３４は、クライアントの表示デバイスに合わせ、Point Cloudをレンダリングして表示画像を表示させる。
【０１５７】
ステップＳ４５において、抽出部３１は、PC streamの終端か否かを判定し、PC streamの終端でない場合には処理はステップＳ４１に戻り、PC streamの終端である場合には、処理は終了される。
【０１５８】
以上のようなpacked PCファイル生成処理およびPoint Cloud再生処理によって、クライアント側における処理が簡潔に行えるようにすることができる。
【０１５９】
ここで、図３４には、第２の格納方法でpacked PC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
【０１６０】
これらのシグナリングによれば、クライアントは、subsampleの中身をパースすることなく、PC sampleの境界および各componentのsubsampleの境界を識別可能である。そして、クライアントは、PCPackingInfoBoxからtexture画像とgeometry画像の分離に必要な情報を取得することができる。従って、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC sampleからpacked PC streamを抽出してデコード処理を実施する。その後、クライアントは、packed PC画像からgeometry画像とtexture画像とを分離し、Point Cloudを構成してレンダリングを実行することができる。
【０１６１】
なお、図２３のＡに示したパッキングと同様に、例えば、図２３のＢに示したパッキング、および、図２３のＣに示したパッキングについても、point cloud frame packing SEI（図２５）およびPCPackingInfoBox（図２９）によりパッキング方法をシグナルすることができる。これにより、クライアントは、texture画像およびgeometry画像の各layerを分離することが可能となる。
【０１６２】
また、point cloud frame packing SEIおよびPCPackingInfoBoxにより、例えば、各componentおよび各layerのピクチャ内における配置や位置、サイズなどをシグナルすることで、自由度のあるパッキングを行うことができる。
【０１６３】
図３５には、PCPackingInfoBoxの変形例が示されている。
【０１６４】
図３５に示すように、PCPackingInfoBoxには、例えば、packed PC画像を構成するcomponent数を示す情報（component_num）、packed PC画像を構成するlayer数を示す情報（layer_num）、および、componentの種類を示す情報（component_type）が記述される。例えば、component_typeが０である場合、componentの種類はgeometry画像であること示し、component_typeが１である場合、componentの種類はtexture画像であることを示す。また、PCPackingInfoBoxには、layer識別子（layer_id）、並びに、packed PC画像内においてcomponent_typeおよびlayer_idで示される画像が配置される位置を示す情報（left/top）と、それらのサイズを示す情報（width/height）とが記述される。
【０１６５】
なお、例えば、これまで説明したようにgeometry画像およびtexture画像をcomponentとして扱うのに加えて、occupancy mapをcomponentとして扱ってもよい。この場合、occupancy mapも、geometry画像およびtexture画像とともにパッキングすることができる。
【０１６６】
＜第３の格納方法＞
図３６乃至図４３を参照して、PC sampleを定義せずPC streamをISOBMFFの1 trackに格納する方法である第３の格納方法について説明する。ここで、第３の格納方法は、上述したようなPC sampleという概念を用いずに、texture subsampleおよびgeometry subsampleをISOBMFFのsampleとして格納する点で、第１の格納方法および第２の格納方法に対する変形例となる。
【０１６７】
従って、第３の格納方法におけるelementary streamのシグナリングは、第１の格納方法におけるelementary stream（図６参照）および第２の格納方法におけるelementary stream（図２４参照）と同一の構造となる。但し、第３の格納方法では、1SOBMFFにおけるsampleをgeometry subsampleおよびtexture subsampleと定義する。そして、1SOBMFFにおけるsampleと定義されたgeometry subsampleをgeometry sampleと称し、1SOBMFFにおけるsampleと定義されたtexture subsampleをtexture sampleと称する。
【０１６８】
図３６には、第３の格納方法におけるelementary streamのシグナリングの一例として、第１の格納方法におけるelementary streamと同様の構造が示されている。
【０１６９】
図３７には、ISOBMFFのシグナリングの一例が示されている。
【０１７０】
例えば、図３７に示すように、sample groupを用いて、Group of Framesの境界(GOFEntry)、PC frameの境界(PCFrameEntry)、texture samplesの境界、geometry samplesの境界、およびtexture&geometry samplesの境界(ComponentGroupEntry)をシグナルすることができる。なお、Sample Groupについては、後述の図５５に示すSample Groupの概要を参照して説明する。
【０１７１】
そして、各sampleは、SampleToGroupBox ('sbgp')を通じて、SampleGroupDescriptionBox ('sgpd')でシグナルされる各SampleGroupEntryに紐づけられる。なお、sgpdは、MovieBox ('moov')内のSampleTableBox ('stbl')にシグナルされてもよい。
【０１７２】
ここで、図３８乃至図４０に、新たに定義したGroupEntryを示す。
【０１７３】
図３８に示すようにGOFEntryは定義され、grouping_type_parameter='gofg'とする。
【０１７４】
なお、GOFEntryの各fieldのセマンティクスは、上述の図９に示したGOF headerの各fieldと同一である。
【０１７５】
図３９に示すようにPCFrameEntryは定義され、grouping_type_parameter='pcfg'とする。
【０１７６】
例えば、PCFrameEntryにおけるsize_of_pc_frameフィールドは、PC frameのサイズを示す。また、number_of_componentフィールドは、PC frameを構成するcomponentの数を示し、具体的には、geometry画像およびtexture画像から構成される場合には、２となる。
【０１７７】
図４０に示すようにComponentGroupEntryは定義され、grouping_type_parameter='cmpg'とする。
【０１７８】
例えば、ComponentGroupEntryにおけるtypeフィールドは、このsample groupに属するsampleのcomponentの種類を示す。具体的には、typeフィールドが０である場合には、componentの種類がgeometry画像であることを示し、typeフィールドが１である場合には、componentの種類がtexture画像であることを示す。また、typeフィールドが２である場合には、componentの種類がgeometry&texture（第２の格納方法）であることを示す。
【０１７９】
なお、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせずにcomponentの一種として扱う場合、typeフィールドに、それぞれのcomponentの種類を示す値を追加してもよい。
【０１８０】
また、ComponentGroupEntryにおけるnumber_of_layerフィールドは、componentのlayer数を示す。
【０１８１】
さらに、ComponentGroupEntryの代わりに、GeometryGroupEntryおよびTextureGroupEntryを定義してもよい。そして、GeometryGroupEntryによりgeometry samplesの境界をシグナルし、TextureGroupEntryによりtexture samplesの境界をシグナルすることができる。
【０１８２】
また、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種とし、sampleとしてシグナルする場合は、それぞれのsamplesの境界をシグナルするGroupEntryを定義してもよい。そして、GroupEntryにより、それぞれのsamplesの境界を示してもよい。
【０１８３】
なお、第２の格納方法のように、各componentおよび各layerが１つの画像にパッキングされた場合には、sample entryにPCPackingInfoBoxがシグナルされる。
【０１８４】
ここで、第３の格納方法において、ISOBMFFに格納されるストリームはAVCやHEVC，SVC，SHEVCなどに準拠させることができ、その場合、これらのコーデックのrestricted schemeとして運用することができる。例えば、sample entryは'resv'になり、SchemeTypeBoxのscheme_typeは'pcbs'になり、OriginalFormatBoxのdata_formatは用いられたコーデックによって、avc1やhev1などになる。
【０１８５】
そして、これらの新たに定義された複数のBoxは、ポストデコード処理に使用されるという位置づけになり、図３７に示すrinf/schi下にシグナルされる。さらに、このrinf/schiには、第１の格納方法で説明したPCHeaderBoxおよびLayerCompositionBoxも、図示するようにシグナルされる。
【０１８６】
また、例えば、texture video streamおよびgeometry video streamが各2 layerで構成されている場合、120pのvideo streamは30pのPC streamに相当する。
【０１８７】
これにより、図４１に示すように、クライアントは、（LayerCompositionBoxのnum_layer_composed × num_of_component）の値から、sampleのインターリーブ周期である4 samplesを識別することができる。
【０１８８】
そして、これらのシグナリングによれば、クライアントはsampleの中身をパースすることなく、sample groupの情報を通じて、Group of Framesの境界、PC sampleの境界および各componentのsampleの境界を識別可能である。つまり、クライアントは、PCPackingInfoBoxからtexture画像とgeometry画像との分離に必要な情報を取得できる。
【０１８９】
従って、クライアントは、システムレイヤのシグナリングのみを参照するという簡略化された処理で、geometry video streamおよびtexture video streamを抽出してデコード処理を実施する。その後、クライアントは、geometry画像とtexture画像とを分離し、Point Cloudを構成してレンダリングを実行することができる。
【０１９０】
ここで、第１の格納方法のようにパッキングを適用しない場合、生成処理および再生処理は、それぞれ図１９および図２０のフローチャートを参照して上述したのと同様に行われる。このとき、図１９のステップＳ１４において、PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納する際、ISOBMFFのsampleは各componentのsampleとなる。また、図２０のステップＳ２２において、geometry video streamおよびtexture video streamは、２デコーダインスタンスによる個別のデコードとなる。
【０１９１】
また、第２の格納方法のようにパッキングを適用する場合、生成処理および再生処理は、それぞれ図３２および図３３のフローチャートを参照して上述したのと同様に行われる。このとき、図３２のステップＳ３５において、packed PC streamを、３次元情報メタデータを含むBoxをシグナルしたISOBMFFに格納する際、ISOBMFFのsampleはpacked PC streamの1 pictureとなる。また、図３３のステップＳ４２において、packed PC streamは１デコーダインスタンスによるデコードとなる。
【０１９２】
ここで、図４２には、第３の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
【０１９３】
なお、図４３を参照して、SEIを用いずにシグナルする例について説明する。
【０１９４】
ここまで、PC frame内の３次元情報メタデータについて、SEIを用いてシグナルする例について説明した。これに対し、例えば、ISOBMFFで規定されるsample auxiliary informationを利用して３次元情報メタデータをシグナルしてもよい。
【０１９５】
即ち、図４３に示すように、SampleAuxiliaryInformationOffsetBox ('saio')のoffsetフィールドでsample auxiliary infromationの位置をシグナルする。同様に、SampleAuxiliaryInformationSizeBox ('saiz')のsample_info_sizeフィールドで、各sampleに紐づくsample auxiliary informationのサイズをシグナルする。例えば、SampleAuxiliaryInformationOffsetBoxおよびSampleAuxiliaryInformationSizeBoxは、aux_info_type='pcmd'で関連づけられる。
【０１９６】
SEIは、AVCやHEVCなどのような符号化コーデックで用いられる要素であるため、SEIを用いた場合には、コーデックに依存したシグナリングとなってしまう。これに対し、sample auxiliary informationを用いた場合には、符号化コーデックに依存することなく３次元情報メタデータをシグナルすることが可能となる。
【０１９７】
＜第４の格納方法＞
図４４乃至図５３を参照して、PC streamをgeometry video streamおよびtexture video streamに分け、ISOBMFFの2 tracksに格納する方法である第４の格納方法について説明する。
【０１９８】
図４４には、第４の格納方法におけるISOBMFFのシグナリングの一例が示されている。
【０１９９】
図４４に示すように、PC streamをgeometry video streamとtexture video streamとに分離し、それぞれをISOBMFFの1 trackに格納する。ここで、geometry video streamを格納するtrackをgeometry track（または主track）と称し、texture video streamを格納するtrackをtexture track（または副track）と称する。また、geometry trackには、auxiliary patch infoおよびoccupancy mapも格納される。
【０２００】
そして、geometry trackおよびtexture trackの関係性を、track referenceと、新たに定義したPCMultiStreamBoxでシグナルする。
【０２０１】
なお、第４の格納方法においても、第３の格納方法と同様に、Group of Frames、およおび、PC frameの境界を示すsample groupをシグナルしてもよい。
【０２０２】
また、第１の格納方法の変形例と同様に、ISOBMFFの1 trackに、1 layerが格納される構成としてもよい。ここで、例えば、各trackに格納されているlayerが、layer 0およびlayer 1のどちらであるかを示すために、PC sample内のheaderでシグナルされるlayer識別子（例えば、図８のlayer_id）を、各trackのsample entryでシグナルしてもよい。または、PC sample内のheaderそのものを、各trackのsample entryに格納してもよい。
【０２０３】
ここで、第４の格納方法において、ISOBMFFに格納されるストリームはAVCやHEVC，SVC，SHEVCなどに準拠させることができ、その場合、これらのコーデックのrestricted schemeとして運用できる。例えば、sample entryは'resv'になり、SchemeTypeBoxのscheme_typeは'pcbs'になり、OriginalFormatBoxのdata_formatは用いられたコーデックによって、avc1やhev1などになる。
【０２０４】
そして、これらの新たに定義された複数のBoxは、ポストデコード処理に使用されるという位置づけになり、図４４に示すrinf/schi下にシグナルされる。さらに、このrinf/schiには、第１の格納方法で説明したPCHeaderBoxおよびLayerCompositionBoxも、図示するようにシグナルされる。
【０２０５】
なお、occupancy mapやauxiliary patch infoなどのような３次元情報メタデータをSEIとしてシグナルせず、componentの一種とした場合は、3次元メタデータをISOBMFFの1 trackに格納してもよい。この場合、3次元メタデータを格納するtrackのsample entryにも、geometry trackやtexture trackなどと同様のBoxおよび情報がシグナルされてもよい。
【０２０６】
また、例えば、texture video streamおよびgeometry video streamが各2 layerで構成され、個別trackに格納されている場合、各60pのvideo streamは30pのPC streamに相当する。これにより、クライアントは、（LayerCompositionBoxのnum_layer_composed × num_of_component）の値から、sampleのインターリーブ周期を識別することができる。
【０２０７】
なお、第４の格納方法における手法は、上述した第３の格納方法のみでなく、第１の格納方法および第２の格納方法において同一のcomponentの異なるlayerのパッキングの構成に対しても、適用可能である。特に、第２の格納方法において、図２３のＢを参照して説明したように、同一のcomponentの画像を異なるlayerどうしで１つの画像にパッキングする手法において、geometry video streamとtexture video streamとを分割してtrackに格納することで、texture画像とgeometry画像との間に相関が少ないのに起因して、圧縮効率が悪化してしまうのを回避することができる。
【０２０８】
さらに、１つのgeometry trackに対して、例えば、bitrateの異なる複数のtexture trackが紐づくような構成としてもよい。
【０２０９】
図４５には、PCMultiStreamBoxのシンタックスの一例が示されている。
【０２１０】
例えば、isGeometryStream＝１である場合にはgeometry trackであることを示し、それ以外の場合にはtexture trackであることを示す。また、geometry trackであれば、紐づくtexture trackのtrack_idをシグナルする。
【０２１１】
このようなシグナリングによれば、クライアントはtrack referenceが示されていることで、任意の1 trackのTrackReferenceBoxをパースするだけで、どのtrackがgeometry trackか識別可能である。その後、クライアントは、geometry trackのPCMultiStreamBoxをパースし、全ての関連texture trackを識別することができる。つまり、クライアントは、最大でも2 trackをパースするだけで全体の構成を識別可能であり、特に複数のtexture trackが紐づくケースにおいて処理を簡易化することが可能となる。
【０２１２】
ここで、PCMultiStreamBoxのシンタックスの変形例として、bitrateの異なるtexture trackをまとめてtrack groupでシグナルし、図４６に示すように、texture_track_group_idでtexture track groupに紐づけてもよい。
【０２１３】
この場合、track groupは、図４７に示すように、PCTextureTrackGroupBoxを新たに定義し、rack_group_typeは'pctg'である。
【０２１４】
なお、texture_track_idで、PCTextureTrackGroupのtrack_group_idに紐づけてもよい。
【０２１５】
また、図４８に示すように、PCMultiStreamBoxに、textureがgeometryと同じtrackに格納されているか否かを示すisInGeometryStreamを追加してもよい。これにより、第１乃至第３の格納方法でも、シグナル可能なBoxとすることができる。
【０２１６】
さらに、PCMultiStreamBoxの代わりに、図４９に示すように、track groupで紐づくgeometry trackとtexture trackをシグナルしてもよい。
【０２１７】
そして、図５０に示すように、track groupは、PCStreamGroupBoxを新たに定義し、rack_group_typeは'pcgp'である。このとき、track_group_idが等しいpcgpを有するtrackは、一つのPC streamを構成する。例えば、isGeometry=0であれば、そのtrackはtexture trackであることを示し、isGeometry=1であれば、そのtrackはgeometry trackであることを示す。
【０２１８】
ここで、図５１には、第４の格納方法でPC streamをISOBMFFの構造に格納したときのISOBMFF構造の一例が示されている。
【０２１９】
＜DASHのシグナリング＞
図５２および図５３を参照して、DASHのシグナリングについて説明する。
【０２２０】
例えば、texture画像およびgeometry画像と３次元情報メタデータとは、DASHのMPDでシグナルされる。そして、図５２に示すように、SupplementalProperty or EssentialProperty@schemeIdUri=="urn:mpeg:mpegI:pointcloud"をPC Component Descriptorと定義し、Representationが、texture画像およびgeometry画像のどちらであるかを示す。
【０２２１】
また、図５２に示すように、texture representationからgeometry representationへの紐づけをRepresentation@dependencyIdで行う。これは、presentation時に、geometry画像および３次元情報メタデータがないとtexture画像をマッピングできないという依存関係があるためである。
【０２２２】
これらのシグナリングによれば、クライアントがDASH配信コンテンツを取得する際、PC Component Descriptorを参照し、PC streamを構成するgeometry video streamとtexture video streamを適切に取得することができる。また、ネットワーク帯域幅に応じて、適切なtexture video streamの切り替えも可能となる。
【０２２３】
なお、geometry representationからtexture representationへの紐づけをRepresentation@associationIdで行ってもよい。
【０２２４】
この場合、図５３に示すように、associationTypeは"ptex"となる。geometryは単独で色のないpoint cloudのpresentationを可能とするため、associationIdを用いた紐づけが適切である。
【０２２５】
その他、上述した第１乃至第４の格納方法において、layer 0以外のtexture subsampleおよびgeometry subsample、または、layer 0以外のtexture sampleおよびgeometry subsampleを、layer 0のsubsample、または、sampleのSEIとして、全て格納してもよい。
【０２２６】
ここで、図５４には、SubSampleInformationBoxの概要が示されている。
【０２２７】
図５４に示すように、sample中の、連続した特定byte領域をsub-sampleと定義している。また、sub-sampleの定義は符号化コーデックごとに決まっており、例えばHEVCなら、NAL unitがsub-sampleとなる。また、SubSampleInformationBoxでは、sub-sampleごとに情報を付加することができる。
【０２２８】
また、図５５には、Sample Groupの概要が示されている。
【０２２９】
図５５に示すように、Sample To Group Boxのgrouping_typeは、紐づけられるSample Group Description Boxのgrouping_typeを示す。1 entryにつき、sample_countとgroup_description_indexがシグナルされる。そして、group_description_indexは、紐づくGroup Entryのindexを示し、sample_countは、そのGroup Entryに属するsample数を示す。
【０２３０】
＜システム構成＞
図５６および図５７を参照して、本技術を適用したデータ生成装置およびデータ再生装置のシステム構成について説明する。
【０２３１】
図５６には、データ生成装置の構成例を示すブロック図が示されている。
【０２３２】
図５６に示すように、データ生成装置５１は、制御部６１およびファイル生成部６２を備えており、ファイル生成部６２は、データ入力部７１、データ符号化・生成部７２、MPD（Media Presentation Description）ファイル生成部７３、記録部７４、およびアップロード部７５を備えて構成される。そして、データ符号化・生成部７２は、前処理部７６、符号化部７７、およびセグメントファイル生成部７８を有している。
【０２３３】
例えば、前処理部７６は、上述の3D2D変換部２１（図１７または図３０）に対応し、入力されるPoint Cloudから、geometry画像、texture画像、および３次元情報メタデータを生成する処理を実行する。
【０２３４】
また、符号化部７７は、上述の符号化部２２（図１７）に対応し、geometry video streamおよびtexture video streamを符号化する処理を実行する。または、符号化部７７は、上述の符号化部２２Ａ（図３０）に対応し、packed PC画像を符号化する処理を実行する。
【０２３５】
また、セグメントファイル生成部７８は、上述のPC stream生成部２３およびファイル生成部２４（図１７または図３０）に対応し、PC streamを生成し、そのPC streamをISOBMFFに格納したPCファイルを生成する処理を実行する。
【０２３６】
図５７には、データ再生装置の構成例を示すブロック図が示されている。
【０２３７】
図５７に示すように、データ再生装置５２は、制御部８１および再生処理部８２を備えており、再生処理部８２は、MPDファイル取得部９１、MPDファイル処理部９２、セグメントファイル取得部９３、表示制御部９４、データ解析・復号部９５、および表示部９６を備えて構成さる。そして、データ解析・復号部９５は、セグメントファイル処理部９７、復号部９８、および表示情報生成部９９を有している。
【０２３８】
例えば、セグメントファイル処理部９７は、上述の抽出部３１（図１８）に対応し、再生時刻に対応するgeometry video streamおよびtexture video streamを抽出する処理を実行する。または、セグメントファイル処理部９７は、上述の抽出部３１（図３１）に対応し、再生時刻に対応するpacked PC streamを抽出する処理を実行する。
【０２３９】
また、復号部９８は、上述の復号部３２（図１８）に対応し、geometry video streamおよびtexture video streamを、それぞれ個別に復号する処理を実行する。または、復号部９８は、上述の復号部３２Ａ（図３１）に対応し、packed PC streamを復号する処理を実行する。
【０２４０】
また、表示情報生成部９９は、2D3D変換部３３および表示処理部３４（図１８または図３１）に対応し、Point Cloudを構築しPoint Cloudをレンダリングして表示画像を表示させる。
【０２４１】
以上のように、本技術によれば、ISOBMFF格納に適したPC stream構造(PC sample)を定義し、PC streamをISOBMFFの1 trackに格納することができる。これにより、クライアントによる再生時、システムレイヤのシグナリングのみを参照するという簡略化された処理で、PC streamのデコード処理の実行を可能とし、通常再生時のstream内ランダムアクセスの発生を抑制することができる。
【０２４２】
また、第３の格納方法のように、PC sampleの定義を用いず、PC streamをISOBMFFの1 trackに格納することによっても、同様に、簡略化された処理で、PC streamのデコード処理の実行を可能とすることができる。
【０２４３】
さらに、第２の格納方法のように、PC streamのgeometry video streamおよびtexture video streamを1 streamにパッキングしてISOBMFFの1 trackに格納することができる。これにより、クライアントによる再生時、1 デコーダインスタンスでのPC streamのデコード処理の実行を可能にすることができる。
【０２４４】
また、第４の格納方法のように、PC streamをgeometry video streamとtexture video streamに分け、ISOBMFFの2 tracksに格納することができる。これにより、geometry video streamを格納するtrackとtexture video streamを格納するtrackの紐づけを効率的に行うことができる。従って、ネットワーク帯域に応じたPC stream画質の最適化するためのクライアントにおけるstream取得処理を容易に行うことができる。
【０２４５】
＜コンピュータの構成例＞
次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
【０２４６】
図５８は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
【０２４７】
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５やROM１０３に予め記録しておくことができる。
【０２４８】
あるいはまた、プログラムは、ドライブ１０９によって駆動されるリムーバブル記録媒体１１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体１１１は、いわゆるパッケージソフトウェアとして提供することができる。ここで、リムーバブル記録媒体１１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
【０２４９】
なお、プログラムは、上述したようなリムーバブル記録媒体１１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク１０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
【０２５０】
コンピュータは、CPU(Central Processing Unit)１０２を内蔵しており、CPU１０２には、バス１０１を介して、入出力インタフェース１１０が接続されている。
【０２５１】
CPU１０２は、入出力インタフェース１１０を介して、ユーザによって、入力部１０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)１０３に格納されているプログラムを実行する。あるいは、CPU１０２は、ハードディスク１０５に格納されたプログラムを、RAM(Random Access Memory)１０４にロードして実行する。
【０２５２】
これにより、CPU１０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU１０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース１１０を介して、出力部１０６から出力、あるいは、通信部１０８から送信、さらには、ハードディスク１０５に記録等させる。
【０２５３】
なお、入力部１０７は、キーボードや、マウス、マイク等で構成される。また、出力部１０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
【０２５４】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
【０２５５】
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０２５６】
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０２５７】
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０２５８】
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０２５９】
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
【０２６０】
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
【０２６１】
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
【０２６２】
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
【０２６３】
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成するファイル生成部
を備える情報処理装置。
（２）
前記第１の画像および前記第２の画像を符号化して、第１の画像ストリームおよび第２の画像ストリームを生成する符号化部
をさらに備え、
前記ファイル生成部は、前記第１の画像ストリームおよび前記第２の画像ストリームがそれぞれ復号された後に、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元構造として再構築されるのに必要な復号順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して前記ファイルを生成する
上記（１）に記載の情報処理装置。
（３）
前記符号化部は、前記第１の画像および前記第２の画像をnon-layered codingで符号化する
上記（２）に記載の情報処理装置。
（４）
前記３次元情報メタデータは、前記第１の画像および前記第２の画像を指し示す情報を含む
上記（１）から（３）までのいずれかに記載の情報処理装置。
（５）
前記３次元情報メタデータは、Group of Framesを示す情報を含む
上記（１）から（４）までのいずれかに記載の情報処理装置。
（６）
前記３次元情報メタデータは、同時刻に表示するlayer数およびcomponent数を示す情報を含む
上記（１）から（５）までのいずれかに記載の情報処理装置。
（７）
前記３次元情報メタデータは、前記３Ｄデータの前記３次元構造の構成要素ごとのコーデック情報を含む
上記（１）から（６）までのいずれかに記載の情報処理装置。
（８）
前記符号化部は、前記第１の画像および前記第２の画像をlayered codingで符号化する
上記（２）に記載の情報処理装置。
（９）
複数の画像を１つのパッキング画像にパッキングするパッキング処理部
をさらに備え、
前記ファイル生成部は、前記パッキング画像、前記３次元情報メタデータ、および、前記パッキングの方法を示すパッキング情報を前記ファイルに格納する
上記（１）から（８）までのいずれかに記載の情報処理装置。
（１０）
前記パッキング処理部は、同一のlayerの前記第１の画像どうし、および、同一のlayerの前記第２の画像どうしをパッキングする
上記（９）に記載の情報処理装置。
（１１）
前記パッキング処理部は、前記第１の画像と前記第２の画像との同一のlayerどうしをパッキングする
上記（９）に記載の情報処理装置。
（１２）
前記パッキング処理部は、前記第１の画像および前記第２の画像の全てのlayerをパッキングする
上記（９）に記載の情報処理装置。
（１３）
前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、ISOBMFF（ISO Base Media File Format）の1 sampleとして格納することで前記ファイルを生成する
上記（１）から（１２）までのいずれかに記載の情報処理装置。
（１４）
前記第１の画像および前記第２の画像のいずれか一方が前記３次元情報メタデータを含み、前記第１の画像および前記第２の画像で、それぞれが前記1 sampleとして格納される
上記（１３）に記載の情報処理装置。
（１５）
前記ファイル生成部は、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを少なくとも含むストリームを、異なるトラックに格納することで前記ファイルを生成する
上記（１）から（１４）までのいずれかに記載の情報処理装置。
（１６）
前記３次元情報メタデータは、前記トラックの間の関係性を示す情報を含む
上記（１５）に記載の情報処理装置。
（１７）
前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、ISOBMFFでシグナルされる
上記（１）から（１６）までのいずれかに記載の情報処理装置。
（１８）
前記第１の画像および前記第２の画像と前記３次元情報メタデータとは、DASH（Dynamic Adaptive St reaming over HTTP）のMPD（Media Presentation Description）でシグナルされる
上記（１）から（１６）までのいずれかに記載の情報処理装置。
（１９）
情報処理装置が、
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
を含む情報処理方法。
（２０）
情報処理装置のコンピュータに、
３次元構造を表す３Ｄデータを２次元に変換することによって、少なくとも第１の画像および第２の画像と、前記第１の画像および前記第２の画像を３次元に構築するのに必要な３次元情報メタデータとが得られ、特定時刻に表示される前記３Ｄデータを構成する１単位のファイルを、前記第１の画像および前記第２の画像を前記３次元情報メタデータに基づいて３次元に再現して再生する際に必要な再生順に従って、前記第１の画像および前記第２の画像と前記３次元情報メタデータとを格納して生成すること
を含む情報処理を実行させるためのプログラム。
【０２６４】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【符号の説明】
【０２６５】
１１および１２  情報処理装置，  ２１  3D2D変換部，  ２２  符号化部，  ２３  PC stream生成部，  ２４  ファイル生成部，  ３１  抽出部，  ３２  復号部，  ３３  2D3D変換部，  ３４  表示処理部，  ５１  データ生成装置，  ５２  データ再生装置，  ６１  制御部，  ６２  ファイル生成部，  ７１  データ入力部，  ７２  データ符号化・生成部，  ７３  MPDファイル生成部，  ７４  記録部，  ７５  アップロード部，  ７６  前処理部，  ７７  符号化部，  ７８  セグメントファイル生成部，  ８１  制御部，  ８２  再生処理部，  ９１  MPDファイル取得部，  ９２  MPDファイル処理部，  ９３  セグメントファイル取得部，  ９４  表示制御部，  ９５  データ解析・復号部，  ９６  表示部，  ９７  セグメントファイル処理部，  ９８  復号部，  ９９  表示情報生成部
【図１】
2020008758.tif 000003
【図２】
2020008758.tif 000004
【図３】
2020008758.tif 000005
【図４】
2020008758.tif 000006
【図５】
2020008758.tif 000007
【図６】
2020008758.tif 000008
【図７】
2020008758.tif 000009
【図８】
2020008758.tif 000010
【図９】
2020008758.tif 000011
【図１０】
2020008758.tif 000012
【図１１】
2020008758.tif 000013
【図１２】
2020008758.tif 000014
【図１３】
2020008758.tif 000015
【図１４】
2020008758.tif 000016
【図１５】
2020008758.tif 000017
【図１６】
2020008758.tif 000018
【図１７】
2020008758.tif 000019
【図１８】
2020008758.tif 000020
【図１９】
2020008758.tif 000021
【図２０】
2020008758.tif 000022
【図２１】
2020008758.tif 000023
【図２２】
2020008758.tif 000024
【図２３】
2020008758.tif 000025
【図２４】
2020008758.tif 000026
【図２５】
2020008758.tif 000027
【図２６】
2020008758.tif 000028
【図２７】
2020008758.tif 000029
【図２８】
2020008758.tif 000030
【図２９】
2020008758.tif 000031
【図３０】
2020008758.tif 000032
【図３１】
2020008758.tif 000033
【図３２】
2020008758.tif 000034
【図３３】
2020008758.tif 000035
【図３４】
2020008758.tif 000036
【図３５】
2020008758.tif 000037
【図３６】
2020008758.tif 000038
【図３７】
2020008758.tif 000039
【図３８】
2020008758.tif 000040
【図３９】
2020008758.tif 000041
【図４０】
2020008758.tif 000042
【図４１】
2020008758.tif 000043
【図４２】
2020008758.tif 000044
【図４３】
2020008758.tif 000045
【図４４】
2020008758.tif 000046
【図４５】
2020008758.tif 000047
【図４６】
2020008758.tif 000048
【図４７】
2020008758.tif 000049
【図４８】
2020008758.tif 000050
【図４９】
2020008758.tif 000051
【図５０】
2020008758.tif 000052
【図５１】
2020008758.tif 000053
【図５２】
2020008758.tif 000054
【図５３】
2020008758.tif 000055
【図５４】
2020008758.tif 000056
【図５５】
2020008758.tif 000057
【図５６】
2020008758.tif 000058
【図５７】
2020008758.tif 000059
【図５８】
2020008758.tif 000060
【手続補正書】
【提出日】令和1年11月5日(2019.11.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する単位であるＰＣ  Ｓａｍｐｌｅにおいて、
ＰＣ  Ｓａｍｐｌｅは、前記前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記ＰＣ  Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣ  ｈｅａｄｅｒが含まれ、
前記ＰＣ  ｈｅａｄｅｒには、前記ＰＣ  Ｓａｍｐｌｅ内における前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成するファイル生成部
を備える情報処理装置。
【請求項２】
前記ファイルはＩＳＯＢＭＦＦ（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ）であって、
前記Ｌａｙｅｒ数の情報は、前記ファイルのメタデータ領域であるｍｏｏｖＢｏｘに格納される
請求項１に記載の情報処理装置。
【請求項３】
前記Ｌａｙｅｒ数の情報は、前記ファイルに格納される前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅおよび前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅに対応するＴｒａｃｋのＳａｍｐｌｅ  Ｅｎｔｒｙに格納される
請求項２に記載の情報処理装置。
【請求項４】
前記ＰＣ  ｈｅａｄｅｒには、さらに前記Ｓｕｂ  ＳａｍｐｌｅがＧｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅか、Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅかを示すＴｙｐｅ情報、および、前記Ｓｕｂ  Ｓａｍｐｌｅが対応するＬａｙｅｒを示すＬａｙｅｒ識別子が含まれる
請求項１に記載の情報処理装置。
【請求項５】
前記Ｔｙｐｅ情報が０であるとき、前記Ｓｕｂ  ＳａｍｐｌｅはＧｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅであることを示し、前記Ｔｙｐｅ情報が１であるとき、前記Ｓｕｂ  ＳａｍｐｌｅはＴｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅであることを示す
請求項４に記載の情報処理装置。
【請求項６】
前記Ｔｙｐｅ情報は、ＳｕｂＳａｍｐｌｅＩｎｆｏｒｍａｔｉｏｎとしてシグナルされる
請求項５に記載の情報処理装置。
【請求項７】
前記Ｔｙｐｅ情報は、ＳｕｂＳａｍｐｌｅＥｎｔｒｙＢｏｘにシグナルされる
請求項５に記載の情報処理装置。
【請求項８】
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する複数のＳａｍｐｌｅにおいて、
前記複数のＳａｍｐｌｅは、前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣｈｅａｄｅｒが含まれ、
前記ＰＣｈｅａｄｅｒには、特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成するファイル生成部
を備える情報処理装置。
【請求項９】
前記ファイルはＩＳＯＢＭＦＦ（ＩＳＯ  Ｂａｓｅ  Ｍｅｄｉａ  Ｆｉｌｅ  Ｆｏｒｍａｔ）であって、
前記Ｌａｙｅｒ数の情報は、前記ファイルのメタデータ領域であるｍｏｏｖＢｏｘに格納される
請求項８に記載の情報処理装置。
【請求項１０】
前記Ｌａｙｅｒ数の情報は、前記ファイルに格納される前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅおよび前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅに対応するＴｒａｃｋのＳａｍｐｌｅ  Ｅｎｔｒｙに格納される
請求項９に記載の情報処理装置。
【請求項１１】
前記ＰＣ  ｈｅａｄｅｒには、さらに前記ＳａｍｐｌｅがＧｅｏｍｅｔｒｙ画像のＳａｍｐｌｅか、Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅかを示すＴｙｐｅ情報、および、前記Ｓａｍｐｌｅが対応するＬａｙｅｒを示すＬａｙｅｒ識別子が含まれる
請求項９に記載の情報処理装置。
【請求項１２】
前記Ｌａｙｅｒ識別子は、ＳａｍｐｌｅＥｎｔｒｙでシグナルされる
請求項１１に記載の情報処理装置。
【請求項１３】
前記Ｔｙｐｅ情報が０であるとき、前記ＳａｍｐｌｅはＧｅｏｍｅｔｒｙ画像のＳａｍｐｌｅであることを示し、前記Ｔｙｐｅ情報が１であるとき、前記ＳａｍｐｌｅはＴｅｘｔｕｒｅ画像のＳａｍｐｌｅであることを示す
請求項１１に記載の情報処理装置。
【請求項１４】
前記Ｔｙｐｅ情報は、ＳｕｂＳａｍｐｌｅＩｎｆｏｒｍａｔｉｏｎとしてシグナルされる
請求項１３に記載の情報処理装置。
【請求項１５】
前記Ｔｙｐｅ情報は、ＳｕｂＳａｍｐｌｅＥｎｔｒｙＢｏｘにシグナルされる
請求項１３に記載の情報処理装置。
【請求項１６】
前記３次元情報メタデータは、前記複数のＳａｍｐｌｅの間の関係性を示す情報を含む
請求項８に記載の情報処理装置。
【請求項１７】
前記Ｇｅｏｍｅｔｒｙ画像および前記Ｔｅｘｔｕｒｅ画像と前記３次元情報メタデータとは、ＩＳＯＢＭＦＦでシグナルされる
請求項８に記載の情報処理装置。
【請求項１８】
前記Ｇｅｏｍｅｔｒｙ画像および前記Ｔｅｘｔｕｒｅ画像と前記３次元情報メタデータとは、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔ  ｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）のＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）でシグナルされる
請求項８に記載の情報処理装置。
【請求項１９】
情報処理装置が、
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する単位であるＰＣ  Ｓａｍｐｌｅにおいて、
ＰＣ  Ｓａｍｐｌｅは、前記前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記ＰＣ  Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣ  ｈｅａｄｅｒが含まれ、
前記ＰＣ  ｈｅａｄｅｒには、前記ＰＣ  Ｓａｍｐｌｅ内における前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成すること
を含む情報処理方法。
【請求項２０】
情報処理装置のコンピュータに、
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する単位であるＰＣ  Ｓａｍｐｌｅにおいて、
ＰＣ  Ｓａｍｐｌｅは、前記前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記ＰＣ  Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣ  ｈｅａｄｅｒが含まれ、
前記ＰＣ  ｈｅａｄｅｒには、前記ＰＣ  Ｓａｍｐｌｅ内における前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳｕｂ  Ｓａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳｕｂ  Ｓａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成すること
を含む情報処理を実行させるためのプログラム。
【請求項２１】
情報処理装置が、
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する複数のＳａｍｐｌｅにおいて、
前記複数のＳａｍｐｌｅは、前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣｈｅａｄｅｒが含まれ、
前記ＰＣｈｅａｄｅｒには、特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成すること
を含む情報処理方法。
【請求項２２】
情報処理装置のコンピュータに、
特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する複数のＳａｍｐｌｅにおいて、
前記複数のＳａｍｐｌｅは、前記Ｐｏｉｎｔ  Ｃｌｏｕｄに対応する３Ｄデータを２次元に変換することにより得られるＧｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および３次元情報メタデータで構成され、
前記３次元情報メタデータには、前記Ｓａｍｐｌｅのｈｅａｄｅｒ情報であるＰＣｈｅａｄｅｒが含まれ、
前記ＰＣｈｅａｄｅｒには、特定時刻に表示されるＰｏｉｎｔ  Ｃｌｏｕｄを構成する前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ数または前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ数であるＬａｙｅｒ数の情報が含まれており、
前記Ｇｅｏｍｅｔｒｙ画像のＳａｍｐｌｅ、前記Ｔｅｘｔｕｒｅ画像のＳａｍｐｌｅ、および前記３次元情報メタデータを格納してファイルを生成すること
を含む情報処理を実行させるためのプログラム。
【国際調査報告】
2020008758.tif 000061
2020008758.tif 000062
2020008758.tif 000063
2020008758.tif 000064