画像処理装置および方法
【課題】所望の解像度や画質に応じて、必要なデータをより容易に得ることができるようにする。
【解決手段】配信用データ生成装置１０１は、画像データを符号化し、IPネットワークを介して配信可能なネットワークパケット化する。このとき、配信用データ生成装置１０１は、各ネットワークパケットにNORMヘッダを付加し、そのNORMヘッダの拡張パラメータ領域に、そのネットワークパケットに含まれる分割コードストリームの先頭と末端について、解像度とレイヤを示すアトリビュート番号を記述する。配信サーバ１０３は、各ネットワークパケットのNORMヘッダを参照し、アトリビュート番号から、所望の解像度と画質の画像を得るために必要なデータを含むネットワークパケットを選択し、抽出する。本発明は、例えば、画像処理装置に適用することができる。
【解決手段】配信用データ生成装置１０１は、画像データを符号化し、IPネットワークを介して配信可能なネットワークパケット化する。このとき、配信用データ生成装置１０１は、各ネットワークパケットにNORMヘッダを付加し、そのNORMヘッダの拡張パラメータ領域に、そのネットワークパケットに含まれる分割コードストリームの先頭と末端について、解像度とレイヤを示すアトリビュート番号を記述する。配信サーバ１０３は、各ネットワークパケットのNORMヘッダを参照し、アトリビュート番号から、所望の解像度と画質の画像を得るために必要なデータを含むネットワークパケットを選択し、抽出する。本発明は、例えば、画像処理装置に適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置および方法に関し、特に、所望の特徴量に応じて、必要なデータをより容易に得ることができるようにした画像処理装置および方法に関する。
【背景技術】
【０００２】
2000年にISO（International Organization for Standardization）/IEC（International Electrotechnical Commission）で標準化されたJPEG2000（Joint Photographic Experts Group 2000）は、高圧縮率で符号化することができ、可逆と非可逆圧縮の両方に対応することができ、解像度や画質をスケラビリティに復号することができるように符号化することができ、さらに、エラー耐性を向上させるように符号化することができる等、様々な特徴を有する技術として、JPEGの代替技術としての期待が高まっている（例えば、特許文献１参照）。
【０００３】
2004年にはデジタルシネマの標準規格（DCI（Digital Cinema Initiative））によって、標準コーデックとしてJPEG2000 Part-1が選ばれた。これによってデジタルシネマの映像撮影から、画像編集、画像配信まで、符号化方式をすべてJPEG2000で統一することが可能になった。
【０００４】
また、このようにJPEG2000で符号化されたデジタルシネマコンテンツは、さらに、ライブイベントや小規模の映画館に２次配信を行ったり、仮想空間提供サービスのユーザに対して提供（例えば仮想空間上の映画館で上映）したり、携帯電話機やノート型パーソナルコンピュータ等のような携帯型電子機器に配信を行ったりすることも考えられている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−３１１３２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、元々の高画質高解像度のデジタルシネマコンテンツはデータ量が大きく、仮想空間上での上映や、低性能の携帯型電子機器等への配信には不向きである。
【０００７】
そのため配信先等に応じて解像度や画質を調整したデータを予め用意することも考えられるが、配信方法、伝送路、および配信先等の多様性はさらに増大する傾向にあり、全ての条件に対応するようにデータを用意することは困難であった。
【０００８】
そこで、配信時に解像度や画質を適切な値に調整する方法も考えられるが、データの復号や符号化を伴う作業は容易ではなく、短時間で行うことは困難であった。
【０００９】
本発明は、このような状況に鑑みて提案されたものであり、例えば解像度や画質等、所望の特徴量に応じて、必要なデータをより容易に得ることができるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一側面は、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成するヘッダ情報生成手段と、前記ヘッダ情報生成手段により生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化するバケット生成手段とを備える画像処理装置である。
【００１１】
前記画像データを符号化し、前記プログレッション順の構造を有する前記コードストリームを生成する符号化手段をさらに備え、前記ヘッダ情報生成手段は、前記符号化手段により前記画像データが符号化されて生成された前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成することができる。
【００１２】
前記符号化手段により前記画像データが符号化されて生成された前記コードストリームを所定のデータ長毎に分割する分割手段をさらに備え、前記ヘッダ情報生成手段は、前記分割手段により前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成することができる。
【００１３】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものであるようにすることができる。
【００１４】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含むようにすることができる。
【００１５】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度であるようにすることができる。
【００１６】
前記ヘッダ情報生成手段は。各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する抽出手段と、前記アドレス抽出手段により抽出された前記先頭アドレスおよび前記末端アドレス、並びに、前記プログレッション順に基づいて、各分割コードストリームの先頭および末端の特徴量を算出する特徴量算出手段と、前記特徴量算出手段により算出された、各分割コードストリームの先頭および末端の前記特徴量から、前記特徴量を他と識別する識別番号であるアトリビュート番号を算出するアトリビュート番号算出手段と、前記ヘッダ情報を生成し、前記ヘッダ情報に、前記アトリビュート番号算出手段により算出された前記アトリビュート番号を記述する記述手段とを備えることができる。
【００１７】
前記アトリビュート番号算出手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号を算出する算出処理手段とを備えることができる。
【００１８】
本発明の一側面は、また、画像処理装置の画像処理方法であって、前記画像処理装置のヘッダ情報生成手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成し、前記画像処理装置のパケット生成手段が、生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化する画像処理方法である。
【００１９】
本発明の他の側面は、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定する特徴量特定手段と、前記特徴量特定手段により特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行うパケット選択手段とを備える画像処理装置である。
【００２０】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものであるようにすることができる。
【００２１】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含むようにすることができる。
【００２２】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度であるようにすることができる。
【００２３】
前記パケットは、前記パケットに含まれる前記分割コードストリームの先頭および末端の、前記特徴量を他と識別する識別番号であるアトリビュート番号を含み、前記特徴量特定手段は、前記アトリビュート番号から前記特徴量を求めることができる。
【００２４】
前記特徴量特定手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号から前記特徴量を算出する算出処理手段とを備えることができる。
【００２５】
前記パケット選択手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の判定式を用いて、前記パケットの選択を行う選択処理手段とを備えることができる。
【００２６】
本発明の他の側面は、また、画像処理装置の画像処理方法であって、前記画像処理装置の特徴量特定手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定し、前記画像処理装置のパケット選択手段が、特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行う画像処理方法である。
【００２７】
本発明の一側面においては、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、分割コードストリームの先頭および末端の、画像データの画像の特徴量を含むヘッダ情報が生成され、生成されたヘッダ情報を用いて、各分割コードストリームがパケット化される。
【００２８】
本発明の他の側面においては、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、分割コードストリームの先頭および末端の、画像データの画像の特徴量に関する情報に基づいて、分割コードストリームの先頭および末端の特徴量が特定され、特定された分割コードストリームの先頭および末端の特徴量に基づいて、所望の特徴量に応じたパケットの選択が行われる。
【発明の効果】
【００２９】
本発明によれば、画像を処理することができる。特に、所望の特徴量に応じて必要なデータをより容易に得ることができる。
【図面の簡単な説明】
【００３０】
【図１】本発明を適用したコンテンツ配信システムの主な構成例を示すブロック図である。
【図２】図１の配信用データ生成装置の主な構成例を示すブロック図である。
【図３】図２のJPEG2000エンコーダの主な構成例を示すブロック図である。
【図４】サブバンドの構成例を示す図である。
【図５】サブバンドの構成例を示す図である。
【図６】各サブバンド中のコードブロックの例を示す図である。
【図７】ビットプレーンの例を説明する図である。
【図８】符号化パスの例を説明する図である。
【図９】係数の走査の例を説明する図である。
【図１０】図２のNORMヘッダ生成部の主な構成例を示すブロック図である。
【図１１】レイヤを説明する図である。
【図１２】L-Rタイプの符号化コードストリームの構成例を説明する図である。
【図１３】L-Rタイプの場合の復号画像の復元の様子の例を説明する図である。
【図１４】R-Lタイプの符号化コードストリームの構成例を説明する図である。
【図１５】R-Lタイプの場合の復号画像の復元の様子の例を説明する図である。
【図１６】L-Rタイプのネットワークパケット生成の様子の例を説明する図である。
【図１７】NORMヘッダの構成例を説明する図である。
【図１８】R-Lタイプのネットワークパケット生成の様子の例を説明する図である。
【図１９】配信データ生成処理の流れの例を説明するフローチャートである。
【図２０】符号化処理の流れの例を説明するフローチャートである。
【図２１】NORMヘッダ生成処理の流れの例を説明するフローチャートである。
【図２２】アトリビュート番号算出処理の流れの例を説明するフローチャートである。
【図２３】図１の配信サーバの主な構成例を示すブロック図である。
【図２４】ネットワークパケット配信処理の流れの例を説明するフローチャートである。
【図２５】解像度レイヤ算出処理の流れの例を説明するフローチャートである。
【図２６】選択処理の流れの例を説明するフローチャートである。
【図２７】本発明を適用したパーソナルコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３１】
以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（コンテンツ配信システム）
２．第２の実施の形態（パーソナルコンピュータ）
【００３２】
＜１．第１の実施の形態＞
［コンテンツ配信システムの構成］
図１は、本発明を適用したコンテンツ配信システムの一実施の形態の構成を表している。
【００３３】
図１に示されるコンテンツ配信システム１００は、画像や音声等よりなるコンテンツのデータを配信するシステムである。コンテンツ配信システム１００においては、配信するコンテンツの画像の特徴量（例えば解像度や画質等）が、その配信先となる端末装置の性能等の各種条件に応じて適切になるように調整されて配信される。
【００３４】
このコンテンツは、例えば、デジタルシネマ用のデジタルシネマコンテンツである。一般的には、コンテンツのデータには、画像データだけでなく音声データやその他のデータも含まれるが、以下においては、説明の便宜上、本発明に関連する画像データについてのみ説明する。
【００３５】
コンテンツ配信システム１００は、例えば、配信用データ生成装置１０１、コンテンツサーバ１０２、配信サーバ１０３、端末装置１０４、および端末装置１０５を有する。
【００３６】
配信用データ生成装置１０１は、生成したり、外部から供給されたりしたコンテンツの画像データを、配信用データに作り替える。より具体的には、配信用データ生成装置１０１は、画像データを、インターネット等のIP（Internet Protocol）ネットワークを介して配信可能なネットワークパケット化する。
【００３７】
配信用データ生成装置１０１は、生成したネットワークパケットをコンテンツサーバ１０２に供給し（矢印１１１）、格納する。
【００３８】
コンテンツサーバ１０２は、配信用データ生成装置１０１により生成されたネットワークパケットを、コンテンツの配信用データとして保持し、管理する。コンテンツサーバ１０２は、配信サーバ１０３からの要求に基づいて、このように管理しているネットワークパケットを配信サーバ１０３に供給する（矢印１１２）。
【００３９】
配信サーバ１０３は、例えば、端末装置１０４や端末装置１０５から要求されたコンテンツをコンテンツサーバ１０２に要求する。配信サーバ１０３は、その要求に基づいてコンテンツサーバ１０２から供給される、要求したコンテンツのネットワークパケットを取得すると、要求元の端末装置にそのネットワークパケットを供給（配信）する（矢印１１３若しくは矢印１１４）。
【００４０】
端末装置１０４および端末装置１０５は、ネットワークパケットを受信し、コンテンツを再生し、出力（画像表示や音声出力等）する装置である。端末装置１０４や端末装置１０５としては、例えば、映画館のデジタルシネマ上映装置、イベント会場等に特設される小型の上映装置、仮想空間上での仮想的な上映装置、テレビジョン受像機やハードディスクレコーダ等の一般家庭に設置されるAV機器、パーソナルコンピュータ、または、携帯電話機やノート型パーソナルコンピュータ等の携帯型電子機器等、通信機能を有する任意の装置が想定される。
【００４１】
なお、配信用データ生成装置１０１とコンテンツサーバ１０２、コンテンツサーバ１０２と配信サーバ１０３、並びに、配信サーバ１０３と端末装置１０４および端末装置１０５は、インターネット等を含む任意のネットワークを介して互いに接続されており、そのネットワークを介して情報の授受を行う。
【００４２】
つまり、矢印１１１乃至矢印１１４により示される各装置間の情報の授受は、そのネットワークを介して行われる。
【００４３】
IPネットワークにデータを伝送する際に、どのようなプロトコルを用いるかが重要である。TCP（Transmission Control Protocol）は汎用性の高いプロトコルであるが送信側から受信側に正しくデータが伝送されないと何度でも再送を繰り返すので、即時的（リアルタイム）な配信が必要なシステムには適さない。
【００４４】
これに対して、マルチキャスト（Multicast）プロトコルは、高いビットレートのデータ伝送や、低いパケットロスでの伝送に適したプロトコルである。解像度の大きいデジタルシネマのデータ伝送には好適である。
【００４５】
しかしながら、マルチキャスト（Multicast）プロトコルでは、UDP（User Datagram Protocol）を使用するため、TCPのようなデータ到着信頼性を実現されていない。データ到着信頼性をマルチキャスト（Multicast）プロトコルに付与するものとしてNACK（不到達確認要求）をしてパケットを回復するNORM（NACK（Negative Acknowledgment） Oriented Reliable Multicast）プロトコルがIETF（Internet Engineering Task Force）で提案されている。
【００４６】
コンテンツ配信システム１００においては、このようなNORMプロトコルを採用する。
【００４７】
以上のように、コンテンツ配信システム１００においては、配信サーバ１０３は、ネットワークパケットをコンテンツサーバ１０２から取得し、それを端末装置１０４や端末装置１０５に配信する。
【００４８】
このような配信に備えて、配信用データ生成装置１０１は、例えば解像度や画質等の、画像の特徴量に関する情報をNORMヘッダの拡張領域に記述し、そのNORMヘッダを含むネットワークパケットを生成する。
【００４９】
配信サーバ１０３は、このようなNORMヘッダを含むネットワークパケットをコンテンツサーバ１０２から取得する。配信サーバ１０３は、そのネットワークパケットに含まれるNORMヘッダを参照することにより、そのネットワークパケットに含まれる画像データ（符号化データ）の画像特徴量（解像度や画質等）を容易に把握することができる。
【００５０】
そこで、配信サーバ１０３は、その画像特徴量に関する情報に基づいて、配信先の端末装置の性能、配信方法、若しくは伝送路等に対して、例えば解像度や画質等の画像特徴量が適切なネットワークパケットのみを選択し、配信する。
【００５１】
このように、配信サーバ１０３は、NORMヘッダの情報に従って、ネットワークパケット（画像データ）を取捨選択するのみで、より容易に、配信先等の各種条件に対して適切な画像特徴量の画像データを配信することができる。つまり、配信サーバ１０３は、目的に応じた適切な（すなわち、所望の）画像特徴量の画像データを、より容易に得ることができる。
【００５２】
換言すれば、配信用データ生成装置１０１は、配信サーバ１０３が、所望の画像特徴量に応じて必要な画像データをより容易に得ることができるような配信用データ（ネットワークパケット）を生成することができる。
【００５３】
さらに換言すれば、このような方法を用いることにより、コンテンツ配信システム１００は、コンテンツサーバ１０２に保持する配信用データ（ネットワークパケット）のデータ量の不要な増大を抑制することができる。つまり、コンテンツ配信システム１００は、コストの増大を抑制しつつより多様な用途に適用可能とすることができる。
【００５４】
以下に、各装置や方法等についてより具体的に説明する。
【００５５】
［配信用データ生成装置の構成］
図２は、図１の配信用データ生成装置１０１の主な構成例を示すブロック図である。
【００５６】
図２に示されるように、配信用データ生成装置１０１は、例えば、JPEG2000エンコーダ１２１、コードストリーム分割部１２２、NORMヘッダ生成部１２３、およびネットワークパケット生成部１２４を有する。
【００５７】
外部よりベースバンドの画像データ等が供給されると（矢印１３１）、JPEG2000エンコーダ１２１は、その画像データをJPEG2000方式で符号化し、符号化コードストリームを生成する。JPEG2000エンコーダ１２１は、生成した符号化コードストリームをコードストリーム分割部１２２に供給する（矢印１３２）。
【００５８】
コードストリーム分割部１２２は、供給された符号化コードストリームを、ネットワークパケットに格納する所定のデータ長毎に分割する。通常、JPEG2000の符号化コードストリームのデータ長は、ネットワークに伝送する際のIPパケットのデータ長よりも遥かに大きい。したがって、JPEG2000エンコーダ１２１において生成された符号化コードストリームは、基本的に、IPパケット長に合わせて複数個のパケットに分割する必要がある。
【００５９】
コードストリーム分割部１２２は、符号化コードストリームを分割して得られた各分割コードストリームをネットワークパケット生成部１２４に供給する（矢印１３３）。コードストリーム分割部１２２は、さらに、各分割コードストリームをNORMヘッダ生成部１２３に供給する（矢印１３４）。
【００６０】
また、JPEG2000エンコーダ１２１は、生成した符号化コードストリームについての、データ構成（解像度やレイヤ等の画像特徴量を変数とする符号化データの順序）を示すプログレッションオーダ情報を生成し、それをNORMヘッダ生成部１２３に供給する（矢印１３５）。
【００６１】
NORMヘッダ生成部１２３は、コードストリーム分割部１２２から供給された各分割コードストリームについて、NORMヘッダを生成する。NORMヘッダ生成部１２３は、さらに、JPEG2000エンコーダ１２１から供給されたプログレッションオーダ情報等に基づいて、各分割コードストリームの画像特徴量（解像度やレイヤ等）を特定し、それらの情報を、NORMヘッダの拡張領域に記述する。
【００６２】
NORMヘッダ生成部１２３は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【００６３】
ネットワークパケット生成部１２４は、コードストリーム分割部１２２から供給される各分割コードストリームに対して、NORMヘッダ生成部１２３から供給されるNORMヘッダを用いて、ヘッダを生成し、ネットワークパケットを生成する。
【００６４】
ネットワークパケット生成部１２４は、生成したネットワークパケットを出力し（矢印１３７）、例えばコンテンツサーバ１０２に供給して蓄積させる。
【００６５】
［JPEG2000エンコーダの構成］
図３は、図２のJPEG2000エンコーダの主な構成例を示すブロック図である。
【００６６】
JPEG2000エンコーダ１２１は、画像データをウェーブレット変換し、得られた係数を、コードブロック毎にビットプレーンに展開し、ビットプレーン毎にエントロピ符号化する。
【００６７】
JPEG2000エンコーダ１２１は、特にJPEG2000規格で定められたEBCOT(Embedded Coding with Optimized Truncation)と呼ばれるエントロピ符号化を行う（参考文献：ISO/IEC 15444-1, Information technology-JPEG 2000, Part 1:Core coding system）。
【００６８】
このEBCOT（Embedded Block Coding with Optimized Truncation）と呼ばれるエントロピ符号化は、ビットプレーン展開されたバイナリデータを１ピクセル単位にモデリングしながら算術符号化する技術である。
【００６９】
図１に示されるように、JPEG2000エンコーダ１２１は、ウェーブレット変換部１５１、量子化部１５２、コードブロック化部１５３、ビットプレーン展開部１５４、EBCOT１５５、および符号化コードストリーム生成部１５６を有する。
【００７０】
ウェーブレット変換部１５１は、通常、低域フィルタと高域フィルタから構成されるフィルタバンクによって実現される。また、デジタルフィルタは通常複数タップ長のインパルス応答（フィルタ係数）を有するので、ウェーブレット変換部１５１は、フィルタリングが行えるだけの入力画像を予めバッファリングするバッファを有する。
【００７１】
ウェーブレット変換部１５１は、入力された画像データ（矢印１３１）を、フィルタリングに最低限必要なデータ量以上取得する。ウェーブレット変換部１５１は、その画像データに対して、例えば５×３ウェーブレット変換フィルタを用いてフィルタリングを行い、ウェーブレット係数を生成する。なお、ウェーブレット変換部１５１は、画像の垂直方向および水平方向のそれぞれに対して、画像データを低域成分と高域成分に分離するフィルタリングを行う。
【００７２】
そして、ウェーブレット変換部１５１は、このようなフィルタリング処理を、垂直方向および水平方向の両方において低域成分として分離されたサブバンドに対して再帰的に所定回数繰り返す。これは、図４に示されるように、画像のエネルギーの多くが低域成分に集中しているからである。
【００７３】
図４は、サブバンドの構成例を示す図である。図４に示されるように、分割レベル数１の状態においても分割レベル数３の状態においても、画像のエネルギーの多くは、低域成分に集中している。
【００７４】
図５は、分割レベル数４のウェーブレット変換処理により生成されるサブバンドの構成例を示す図である。
【００７５】
この場合、ウェーブレット変換部１５１は、まず、画像全体をフィルタリングし、サブバンド1LL（図示せず）、1HL、1LH、および1HHを生成する。次に、ウェーブレット変換部１５１は、生成されたサブバンド1LLに対して再度フィルタリングを行い、2LL（図示せず）、2HL、2LH、および2HHを生成する。さらに、ウェーブレット変換部１５１は、生成されたサブバンド2LLに対して再度フィルタリングを行い、3LL、3HL、3LH、および3HHを生成する。さらに、ウェーブレット変換部１５１は、生成されたサブバンド3LLに対して再度フィルタリングを行い、4LL、4HL、4LH、および4HHを生成する。
【００７６】
このように、分割レベル数４まで分析フィルタリングが行われると、１３個のサブバンドが生成される。図５に示されるように、分割レベルが１つ上位に進むごとに、サブバンドのサイズは、縦方向および横方向にそれぞれ２分の１となる。
【００７７】
つまり、例えば横方向に１９２０画素の画像のベースバンドの画像データが１回分析フィルタリングされると、横方向に９６０画素のサブバンドが４つ（1LL,1HL,1LH,1HH）生成される。さらに、サブバンド1LLが１回分析フィルタリングされると、横方向に４８０画素のサブバンドが４つ（2LL,2HL,2LH,2HH）が生成される。さらに、サブバンド2LLが１回分析フィルタリングされると、横方向に２４０画素のサブバンドが４つ（3LL,3HL,3LH,3HH）が生成される。さらに、サブバンド3LLが１回分析フィルタリングされると、横方向に１２０画素のサブバンドが４つ（4LL,4HL,4LH,4HH）が生成される。
【００７８】
なお、ウェーブレット変換の分割レベル数は任意である。
【００７９】
図３に戻り、ウェーブレット変換部１５１は、フィルタリングにより得られた係数データ（ウェーブレット係数）を、サブバンド毎に、量子化部１５２に供給する（矢印１７２）。
【００８０】
量子化部１５２は、供給された係数データ（ウェーブレット係数）を量子化する。量子化部１５２は、得られた係数データ（量子化係数）を、コードブロック化部１５３に供給する（矢印１７３）。なお、JPEG2000の規格では、可逆圧縮の場合、量子化処理は省略される。その場合、ウェーブレット変換部１５１より出力された係数データ（ウェーブレット係数）は、コードブロック化部１５３に供給される（矢印１７４）。この場合、量子化部１５２は省略可能である。
【００８１】
コードブロック化部１５３は、供給された各係数データ（量子化された係数データ）を、予め定められた所定の大きさの矩形の、エントロピ符号化の処理単位であるコードブロックに分割する。JPEG2000の規格上の定義によって、コードブロックの縦・横サイズはどのサブバンドにおいても一定である。但し画像（サブバンド）の両端や上端・下端などでは、同じサイズのコードブロックが取れないケースも多々ある。
【００８２】
図６は、各サブバンド中のコードブロックの位置関係の例を示したものである。ここでは分割レベル数３の場合について説明する。例えば64×64画素程度のサイズのコードブロックが、分割後のすべてのサブバンド中に生成される。例えば、最も分割レベルが低い1HHのサブバンドの大きさが例えば640×320画素であるとすると、64×64画素のコードブロックは合計５０個存在することになる。後段の各処理部は、このコードブロック毎に処理を行う。もちろん、このコードブロックのサイズ（画素数）は任意である。
【００８３】
図３に戻り、コードブロック化部１５３は、係数データをコードブロック毎にビットプレーン展開部１５４に供給する（矢印１７５）。
【００８４】
ビットプレーン展開部１５４は、供給されたコードブロック毎の係数データを、ビットの位毎のビットプレーンに展開する。
【００８５】
ビットプレーンは、所定の数のウェーブレット係数よりなる係数群（例えば後述するコードブロック）を、１ビット毎、つまり位毎に分割（スライス）したものである。つまり、ビットプレーンは、それぞれが複数ビットのビット深度を持つ複数のデータの、互いに同一の位のビット（係数ビット）の集合である。したがって、展開されるビットプレーン数は、各係数のビット深度に依存する。
【００８６】
図７にその具体例を示す。図７の左図は縦４個、横４個の計１６個の係数を示している。この１６個の係数のうち、絶対値が最大のものは１３で、２進数で１１０１と表現される。ビットプレーン展開部１５４は、このような係数群を、絶対値を示す４枚のビットプレーン（絶対値のビットプレーン）と、符号を示す１枚のビットプレーン（符号のビットプレーン）に展開する。つまり、図７中左の係数群は、図７中右に示されるように、４枚の絶対値のビットプレーンと１枚の符号のビットプレーンに展開される。ここで、絶対値のビットプレーンの要素はすべて０か１の値をとる。また、符号を示すビットプレーンの要素は、係数の値が正であることを示す値、係数の値が０であることを示す値、または係数の値がマイナスを示す値のいずれかをとる。
【００８７】
なお、このようにビットプレーンとされる係数群における係数の数は任意である。以下においては、処理単位を統一することで各部における処理を容易にするために、ビットプレーン展開部１５４が、係数をコードブロック毎にビットプレーン展開するものとして説明する。
【００８８】
図３に戻り、ビットプレーン展開部１５４は、このように展開したビットプレーンを、係数の最上位ビット（MSB：Most Significant Bit）から最下位ビット（LSB：Less Significant Bit）に向かう順に、EBCOT１５５に供給する。つまり、ビットプレーン展開部１５４は、ビット深度の上位側から下位側に向かう順に、展開したビットプレーンをEBCOT１５５に供給する（矢印１７６）。
【００８９】
EBCOT１５５は、所定の大きさのブロック毎にそのブロック内の係数の統計量を測定しながら符号化を行う。EBCOT１５５は、係数データ（量子化係数）をコードブロック単位に、エントロピ符号化する。各コードブロックは、最上位ビット（MSB）から最下位ビット（LSB）方向にビットプレーン毎に独立して符号化される。コードブロックの縦横のサイズは４から256までの２のべき乗で、通常使用される大きさは、32x32、64x64、または128x32等がある。量子化係数値がｎビットの符号付き２進数で表されていて、bit 0からbit n-1がLSBからMSBまでのそれぞれのビットを表すとする。残りの１ビットは符号である。コードブロックの符号化は、MSB側のビットプレーンから順番に、次の３種類の符号化パスによって行われる。
【００９０】
（１）Significant Propagation Pass
（２）Magnitude Refinement Pass
（３）Cleanup Pass
【００９１】
３つの符号化パスの用いられる順序は、図８で示される。最初にBit-plane（n-1）（MSB）がCleanup Passによって符号化される。続いて順次LSB側に向かい、各ビットプレーンの符号化が、３つの符号化パスをSignificant Propagation Pass、Magnitude Refinement Pass、Cleanup Passの順序で用いて行われる。
【００９２】
ただし、実際にはMSB側から何番目のビットプレーンで初めて１が出てくるかをヘッダに書き、MSB側から連続するオール０のビットプレーン（ゼロビットプレーンと呼ぶ）は符号化しない。この順序で３種類の符号化パスを繰返し用いて符号化し、任意のビットプレーンの、任意の符号化パス迄で符号化を打ち切ることにより、符号量と画質のトレードオフを取る（レート制御を行う）。
【００９３】
次に、係数の走査（スキャニング）について図９を用いて説明する。コードブロックは高さ４個の係数毎にストライプ（stripe）に分けられる。ストライプの幅はコードブロックの幅に等しい。スキャン順とは、１個のコードブロック内の、すべての係数をたどる順番で、コードブロック中では上のストライプから下のストライプへの順序、ストライプの中では、左の列から右の列へ向かっての順序、列の中では上から下へという順序である。各符号化パスにおいてコードブロック中のすべての係数が、このスキャン順で処理される。
【００９４】
以下、３つの符号化パスについて述べる。以下はいずれもJPEG-2000規格書（参考文献：ISO/IEC 15444-1, Information technology-JPEG 2000, Part 1:Core coding system）に記述されている内容である。
【００９５】
（１）Significance Propagation Pass（SPパス）：
あるビットプレーンを符号化するSignificance Propagation Passでは、８近傍の少なくとも１つの係数が有意（significant）であるようなnon-significant係数のビットプレーンの値を算術符号化する。その符号化したビットプレーンの値が１である場合は、符号が＋であるか、−であるかを続けてMQ符号化する。
【００９６】
ここでsignificanceというJPEG2000特有の用語について説明する。significanceとは、各係数に対して符号化器が持つ状態で、significanceの初期値はnon-significantを表す０、その係数で１が符号化されたときにsignificantを表す１に変化し、以降常に１であり続けるものである。従って、significanceとは有効桁の情報を既に符号化したか否かを示すフラグとも言える。あるビットプレーンでsignificantになれば、以降のビットプレーンではsignificantになったままである。
【００９７】
（２）Magnitude Refinement Pass（MRパス）：
ビットプレーンを符号化するMagnitude Refinement Passでは、ビットプレーンを符号化する Significance Propagation Passで、且つ符号化していないsignificantな係数のビットプレーンの値をMQ符号化する。
【００９８】
（３）Cleanup Pass（CUパス）：
ビットプレーンを符号化するCleanup Passでは、ビットプレーンを符号化するSignificance Passで、且つ符号化していないnon-significantな係数のビットプレーンの値をMQ符号化する。その符号化したビットプレーンの値が１である場合は符号が＋であるか−であるか（Sign情報）を続けてMQ符号化する。
【００９９】
尚、以上の３つの符号化パスでのMQ符号化では、ケースに応じて、ZC（Zero Coding）、RLC（Run-Length Coding）、SC（Sign Coding）、およびMR（Magnitude Refinement）が使い分けられる。ここでMQ符号化と呼ばれる算術符号が用いられる。MQ符号化は、JBIG2（参考文献：ISO/IEC FDIS 14492, “Lossy/Lossless Coding of Bi-level Images”, March 2000）で規定された学習型の２値算術符号である。
【０１００】
図３に示されるように、EBCOT１５５は、ビットモデリングを行うビットモデリング部１６１と、算術符号化を行うMQ符号化部１６２とを有する。ビットモデリング部１６１は、ビットモデリングを行うと、制御情報、シンボル、およびコンテキスト等の情報をMQ符号化部１６２に供給する（矢印１７７）。MQ符号化部１６２は、供給されたデータ群を用いてMQ符号化を行う。MQ符号化部１６２は、MQ符号化により生成された符号化データを符号化コードストリーム生成部１５６に供給する（矢印１７８）。
【０１０１】
符号化コードストリーム生成部１５６は、EBCOT１５５（MQ符号化部１６２）から供給された符号化データを整列し、１つの符号化コードストリームとして出力する（矢印１７９）。より具体的には、符号化コードストリーム生成部１５６は、符号化データを並べ替え、JPEG2000の特徴であるResolution（解像度）とLayer（レイヤ）のスケーラブルな構造のパケット群よりなる符号化コードストリームを生成する。図２を参照して説明したように、符号化コードストリーム生成部１５６から出力された符号化コードストリームは、コードストリーム分割部１２２に供給される。
【０１０２】
なお、符号化コードストリーム生成部１５６は、さらに、生成した符号化コードストリームについて、その構造を示すプログレッションオーダ情報をNORMヘッダ生成部１２３に供給する（矢印１８０）。
【０１０３】
［NORMヘッダ生成部の構成例］
次に、図２のNORMヘッダ生成部１２３について説明する。上述したように、JPEG2000エンコーダ１２１において生成された符号化コードストリームは、コードストリーム分割部１２２により分割され、分割された複数の分割コードストリームとして、NORMヘッダ生成部１２３に供給される。また、NORMヘッダ生成部１２３には、JPEG2000エンコーダ１２１からプログレッションオーダ情報が供給される。
【０１０４】
図１０は、図２のNORMヘッダ生成部の主な構成例を示すブロック図である。
【０１０５】
図１０に示されるように、NORMヘッダ生成部１２３は、アドレス抽出部１９１、解像度・レイヤ算出部１９２、アトリビュート番号算出部１９３、およびヘッダ記述部１９４を有する。
【０１０６】
アドレス抽出部１９１は、コードストリーム分割部１２２から供給される（矢印１３４）各分割コードストリームの先頭のアドレス（先頭アドレス）と、末端のアドレス（末端アドレス）とを抽出する。アドレス抽出部１９１は、抽出した各分割コードストリームの先頭アドレスと末端アドレスとを解像度・レイヤ算出部１９２に供給する（矢印２１１）。
【０１０７】
解像度・レイヤ算出部１９２は、JPEG2000エンコーダ１２１から供給されるプログレッションオーダ情報により示される符号化コードストリームの構造に基づいて、プログレッションに関する変数となる画像特徴量である解像度とレイヤとを、アドレス抽出部１９１から供給された先頭アドレスおよび末端アドレスのそれぞれについて算出する。
【０１０８】
［レイヤ］
ここで、レイヤについて説明する。上述したように、画像データは、コードブロック毎にビットプレーンに展開されて符号化される。つまり、コードブロック内の符号化パスはビットプレーンの順に並んでいる。レイヤは、このようにコードブロック毎に符号化されたデータを、１つまたは複数のビットプレーン毎に分割したものである。すなわち、各レイヤは、１つまたは複数のビットプレーンにより形成される。換言すれば、コードブロック毎に符号化されたデータは、コードストリーム中の１個または複数個のレイヤに渡って展開される。
【０１０９】
レイヤ中の符号化パス数は、ブロック毎に設定することができる。符号化パス数を０に設定することもできる。
【０１１０】
画像データは、一般的に、レイヤ数が増える程画質が向上する。換言すれば、分割したレイヤを減らしたり増やしたりすることにより、画像データの画質を調整することができる。
【０１１１】
図１１の例においては、１ピクチャがレイヤ１乃至レイヤＮのＮ個のレイヤに分割され、１つのレイヤが４個のパケットから構成されている。この１レイヤ当たりのパケット数は（ウェーブレット分解レベル数＋１）で定義される。
【０１１２】
以上のように、符号化コードストリームは、レイヤ（画質）について、スケーラブルに符号化されている。また、図５を参照して説明したように、画像データは、複数のサブバンドに分割され、そのサブバンド毎に符号化される。したがって、符号化コードストリームは、解像度についても、スケーラブルに符号化されている。つまり、JPEG2000方式で符号化された符号化コードストリームにおいては、解像度およびレイヤについてスケーラブルになるように、符号化データが所定の単位毎にパケット化されて並べられている。
【０１１３】
このような符号化データ（パケット）の並びをプログレッションと称する。JPEG2000方式の場合、符号化データは、解像度とレイヤについて並べられている。したがって、この場合の解像度とレイヤ（画像特徴量）を、プログレッションに関する変数と称する。
【０１１４】
JPEG2000方式においては、このような符号化データの並べ方は、２通り存在する。
【０１１５】
［タイプ］
第１の並べ方は、各レイヤの符号化データを解像度毎に並べる方法である。このような並べ方が採用された符号化コードストリームのタイプをL-Rタイプ（Layer-Resolution Type）と称する。図１２は、そのL-Rタイプの符号化コードストリームの構成例を説明する図である。
【０１１６】
図１２に示されるように、符号化コードストリーム２３１は、SOC（Start of Codestream）、メインヘッダ（Main header）、およびタイルパートヘッダ（Tile-part header）に続いて、各レイヤの符号化データが解像度順に並べられている。なお、図１２においてＬおよびＲは、それぞれ任意の自然数である。
【０１１７】
つまり、このL-Rタイプでは、最初の上位階層にレイヤ（Layer）があり、次の階層に解像度（Resolution）が存在する。従ってこのコードストリームを先頭から順番にデコードすると図１３の様な画像を復元することができる。
【０１１８】
より具体的に説明すると、Layer-1はResolution番号１からＲまでのすべての解像度のパケットを包含しており、このLayer-1をデコードすることで、原画像と同じ解像度の画像の最初のレイヤだけを復元することが出来る。同様にLayer-2をデコードしてLayer−1のデコード済みの画像に合わせることで、画質が向上する。これを最後のLayer-Lまで繰り返して行うことで最終的な復号画像を出力することになる。
【０１１９】
つまり、このように復元するレイヤを向上させることにより、画像は、解像度が一定のまま画質が向上する。広義において「画質」は様々な事象を示すが、ここでは、復元するレイヤに依存するものを「画質」と称する。
【０１２０】
画像の「解像度」および「画質」は、画像の特徴量である。符号化コードストリームにおける「解像度」および「レイヤ」は、これらの特徴量に対応する変数である。したがって、以下においては、この符号化コードストリームにおける「解像度」および「レイヤ」を、それぞれ、画像の「解像度」および「画質」と等価とみなし、「画像の特徴量」と称する場合もある。
【０１２１】
第２の並べ方は、各解像度の符号化データをレイヤ毎に並べる方法である。このような並べ方が採用された符号化コードストリームのタイプをR-Lタイプ（Resolution-Layer Type）と称する。図１４は、そのR-Lタイプの符号化コードストリームの構成例を説明する図である。
【０１２２】
図１４に示されるように、符号化コードストリーム２４１は、SOC（Start of Codestream）、メインヘッダ（Main header）、およびタイルパートヘッダ（Tile-part header）に続いて、各解像度の符号化データがレイヤ順に並べられている。なお、図１４においてＬおよびＲは、それぞれ任意の自然数である。
【０１２３】
つまり、このR-Lタイプでは、最初の上位階層に解像度（Resolution）があり、次の階層にレイヤ（Layer）が存在する。従ってこのコードストリームを先頭から順番にデコードすると図１５の様な画像を復元することができる（３分解のウェーブレット分解のケースでＲ＝４の場合）。
【０１２４】
Res-1はLayer番号１からLまでのすべてのレイヤのパケットを包含しており、このRes-1をデコードすることで、最高画質の画像の最小の解像度だけを復元することが出来る。同様にRes-2をデコードしてRes−1のデコード済みの画像に合わせることで、解像度が水平・垂直共に２倍だけ向上する。これを最後のRes-Rまで繰り返して行うことで最終的な復号画像を出力することになる。
【０１２５】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報から、符号化コードストリームのタイプを特定する。タイプを特定すると符号化ストリームにおける解像度やレイヤの構造が分かるので、解像度・レイヤ算出部１９２は、先頭アドレスおよび末端アドレスのそれぞれに対応する解像度やレイヤを求めることができる。
【０１２６】
［L-Rタイプ］
まず、符号化コードストリームがL-Rタイプの場合について説明する。図１６は、L-Rタイプのネットワークパケット生成の様子の例を説明する図である。
【０１２７】
コードストリーム分割部１２２において、L-Rタイプの符号化コードストリーム２３１が分割され、分割コードストリーム２５１および分割コードストリーム２５２が生成されるとする。
【０１２８】
分割コードストリーム２５１は、１番目のネットワークパケット（Network Packet 1）のBody（本体データ部）となる。分割コードストリーム２５２は、２番目のネットワークパケット（Network Packet 2）のBody（本体データ部）となる。
【０１２９】
もちろん３番目以降のネットワークパケットも生成されるが、ここでは説明の便宜上、省略する。
【０１３０】
NORMヘッダ生成部１２３のアドレス抽出部１９１は、分割コードストリーム２５１の先頭アドレス（Start-1）と末端アドレス（End-1）を求める。また、アドレス抽出部１９１は、分割コードストリーム２５２の先頭アドレス（Start-2）と末端アドレス（End-2）も求める。
【０１３１】
この時、分割コードストリーム２５１の先頭アドレス（Start-1）は、元の符号化コードストリーム２３１のSOCマーカの先頭アドレスに等しく、末端アドレス（End-1）は、（レイヤ１、解像度１）（Layer-1，Res-1）のパケットの途中のアドレスに等しい。
【０１３２】
同様に、分割コードストリーム２５２の先頭アドレス（Start-2）は、分割コードストリーム２５１の末端アドレス（End-1）の直後のアドレスに等しく、末端アドレス（End-2）は、（レイヤ１、解像度Ｒ）（Layer-1，Res-R）の途中のアドレスに等しい。
【０１３３】
プログレッションオーダ情報には、図１６の最上段に示されるような符号化コードストリームの構造（どのアドレスからどのアドレスまでがどのようなヘッダやパケットにより構成されるか）が示されている。
【０１３４】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報によって、符号化コードストリームがL-Rタイプであることを確認すると、その構造に基づいて、上述したように各分割コードストリームの先頭アドレスと末端アドレスに対応するレイヤ番号（Layer番号）および解像度番号（Resolution番号）を求める。
【０１３５】
解像度・レイヤ算出部１９２は、
（R_f,R_t）＝（Resolution番号の先頭値、Resolution番号の末端値）
（L_f,L_t）＝（Layer番号の先頭値、Layer番号の末端値）
と定義し、各分割コードストリーム（各ネットワークパケット）について、これらの変数の値を求める。
【０１３６】
例えば、図１６の例において、分割コードストリーム２５１（Network Packet 1）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（０，１）
（L_f,L_t）＝（０，１）
【０１３７】
また、分割コードストリーム２５２（Network Packet 2）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（１，Ｒ）
（L_f,L_t）＝（１，１）
【０１３８】
なお、図１６に示される各ネットワークパケットのヘッダ（HDR）は、UDPヘッダとNORMヘッダを合わせたものである。UDPはTCPと異なり送達確認などを行わないため、データ比率が高まる。従って途中で一部のデータが欠損（Loss）しても問題が少ない画像のストリーミング等に多用されている。
【０１３９】
図１０に戻り、解像度・レイヤ算出部１９２は、上述した変数（R_f,R_t）および（L_f,L_t）の値を算出すると、それらをアトリビュート番号算出部１９３に供給する（矢印２１２）。アトリビュート番号算出部１９３は、変数（R_f,R_t）および（L_f,L_t）の値を用いて、各分割コードストリーム（各ネットワークパケット）の先頭と末端について、その画像特徴量（解像度やレイヤ）を他と識別するための識別番号であるアトリビュート番号を算出する。
【０１４０】
図１０に示されるように、アトリビュート番号算出部１９３は、タイプ判定部２０１、L-R用算出部２０２、およびR-L用算出部２０３を有する。
【０１４１】
タイプ判定部２０１は、解像度・レイヤ算出部１９２から供給されるプログレッションオーダ情報に基づいて、符号化コードストリームのタイプを判定する。タイプ判定部２０１は、符号化コードストリームのタイプがL-Rタイプである場合、解像度・レイヤ算出部１９２から供給される、各分割コードストリームの変数（R_f,R_t）および（L_f,L_t）の値をL-R用算出部２０２に供給する（矢印２２１）。
【０１４２】
L-R用算出部２０２は、以下の式（１）に示されるようなL-R用の算出式を用いて、各分割コードストリームについて、変数（R_f,R_t）および（L_f,L_t）の値から、先頭と末端のアトリビュート番号（Attribute Number）（先頭値と末端値）を求める。
【０１４３】
Attribute Number＝（Layer-number）×（Resolution level数）
＋（Resolution-number＋１） ・・・（１）
【０１４４】
なお、Layer-numberは、レイヤ番号を示し、Resolution level数は、解像度番号の最大値（ウェーブレット変換の分割レベル数）を示し、Resolution-numberは、解像度番号を示す。
【０１４５】
例えば、図１６の例において、Resolution level数Ｒ＝４とすると、分割コードストリーム２５１のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１４６】
先頭値＝L_f×（Res-R）＋R_f＋１＝０×４＋０＋１＝１
末端値＝L_t×（Res-R）＋R_t＋１＝１×４＋１＋１＝６
【０１４７】
また、分割コードストリーム２５２のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１４８】
先頭値＝L_f×（Res-R）＋R_f＋１＝１×４＋１＋１＝６
末端値＝L_t×（Res-R）＋R_t＋１＝１×４＋４＋１＝９
【０１４９】
L-R用算出部２０２は、以上のように、変数（R_f,R_t）および（L_f,L_t）の値が供給される全ての分割コードストリームについて、アトリビュート番号の先頭値と末端値を求める。L-R用算出部２０２は、求めたアトリビュート番号の先頭値および末端値をヘッダ記述部１９４に供給する（矢印２１３）。
【０１５０】
ヘッダ記述部１９４は、L-R用算出部２０２から供給されたアトリビュート番号の先頭値および末端値の分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダの拡張パラメータ領域に、そのアトリビュート番号の先頭値および末端値を記述する。
【０１５１】
［NORMヘッダの構成］
図１７は、NORMヘッダの構成例を説明する図である。
【０１５２】
ヘッダ記述部１９４は、図１７に示されるような構成のNORMヘッダ２６１を生成し、その拡張パラメータ領域（reserved）に、Ｘ、Attribyute type、FROM、およびTO等の値を記述する。
【０１５３】
これらの変数の内容については、図１７の表２６２に示される。Ｘは、NORMヘッダ２６１にアトリビュート番号が記述されているか否かを示すアトリビュート拡張フラグ（Attribute extension flag）である。アトリビュート拡張フラグのデータ長は任意であるが、例えば１ビットであってもよい。また、アトリビュート拡張フラグの値は任意であるが、例えば、NORMヘッダ２６１にアトリビュート番号の値が記述される場合のアトリビュート拡張フラグＸの値を「１」とし、アトリビュート番号の値が記述されない場合のアトリビュート拡張フラグＸの値を「０」としてもよい。
【０１５４】
アトリビュートタイプ（Attribyute type）は、上述した符号化コードストリームのタイプを示す。アトリビュートタイプのデータ長は任意であるが、例えば８ビットであってもよい。また、アトリビュートタイプの値は任意であるが、例えば、符号化コードストリームがL-Rタイプの場合のアトリビュートタイプの値を「０」とし、符号化コードストリームがR-Lタイプの場合のアトリビュートタイプの値を「１」としてもよい。さらに、L-RタイプおよびR-Lタイプ以外のタイプが存在する場合、他の値を割り当てることもできる。
【０１５５】
FROMは、アトリビュート番号の先頭値を示す。TOは、アトリビュート番号の末端値を示す。これらの値のデータ長は任意であるが、例えば８ビットであってもよい。
【０１５６】
例えば、ヘッダ記述部１９４は、L-R用算出部２０２からアトリビュート番号の先頭値および末端値を供給されると、NORMヘッダを生成し、アトリビュート拡張フラグＸに値「１」をセットし、アトリビュートタイプの値を「０」にセットする。さらに、ヘッダ記述部１９４は、L-R用算出部２０２から供給されたアトリビュート番号の先頭値をFROMに記述し、L-R用算出部２０２から供給されたアトリビュート番号の末端値をTOに記述する。
【０１５７】
図１０に戻り、ヘッダ記述部１９４は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【０１５８】
符号化コードストリームがL-Rタイプの場合、以上のように処理が行われる。
【０１５９】
［R-Lタイプ］
次に、符号化コードストリームがR-Lタイプの場合について説明する。図１８は、R-Lタイプのネットワークパケット生成の様子の例を説明する図である。
【０１６０】
コードストリーム分割部１２２において、R-Lタイプの符号化コードストリーム２４１が分割され、分割コードストリーム２７１および分割コードストリーム２７２が生成されるとする。
【０１６１】
分割コードストリーム２７１は、１番目のネットワークパケット（Network Packet 1）のBody（本体データ部）となる。分割コードストリーム２７２は、２番目のネットワークパケット（Network Packet 2）のBody（本体データ部）となる。
【０１６２】
もちろん３番目以降のネットワークパケットも生成されるが、ここでは説明の便宜上、省略する。
【０１６３】
NORMヘッダ生成部１２３のアドレス抽出部１９１は、分割コードストリーム２７１の先頭アドレス（Start-1）と末端アドレス（End-1）を求める。また、アドレス抽出部１９１は、分割コードストリーム２７２の先頭アドレス（Start-2）と末端アドレス（End-2）も求める。
【０１６４】
この時、分割コードストリーム２７１の先頭アドレス（Start-1）は、元の符号化コードストリーム２４１のSOCマーカの先頭アドレスに等しく、末端アドレス（End-1）は、（レイヤ１、解像度１）（Layer-1，Res-1）のパケットの途中のアドレスに等しい。
【０１６５】
同様に、分割コードストリーム２７２の先頭アドレス（Start-2）は、分割コードストリーム２７１の末端アドレス（End-1）の直後のアドレスに等しく、末端アドレス（End-2）は、（レイヤＬ、解像度１）（Layer-L，Res-1）の途中のアドレスに等しい。
【０１６６】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報によって、符号化コードストリームがR-Lタイプであることを確認すると、その構造に基づいて、上述したように各分割コードストリーム（各ネットワークパケット）について、変数（R_f,R_t），（L_f,L_t）の値を求める。
【０１６７】
例えば、図１８の例において、分割コードストリーム２７１（Network Packet 1）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（０，１）
（L_f,L_t）＝（０，１）
【０１６８】
また、分割コードストリーム２７２（Network Packet 2）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（１，１）
（L_f,L_t）＝（１，Ｌ）
【０１６９】
図１０に戻り、解像度・レイヤ算出部１９２は、上述した変数（R_f,R_t）および（L_f,L_t）の値を算出すると、それらをアトリビュート番号算出部１９３に供給する（矢印２１２）。アトリビュート番号算出部１９３は、各分割コードストリーム（各ネットワークパケット）の先頭と末端について、アトリビュート番号を算出する。
【０１７０】
タイプ判定部２０１は、符号化コードストリームのタイプがR-Lタイプである場合、解像度・レイヤ算出部１９２から供給される、各分割コードストリームの変数（R_f,R_t）および（L_f,L_t）の値をR-L用算出部２０３に供給する（矢印２２２）。
【０１７１】
R-L用算出部２０３は、以下の式（２）に示されるようなR-L用の算出式を用いて、各分割コードストリームについて、変数（R_f,R_t）および（L_f,L_t）の値から、先頭と末端のアトリビュート番号（Attribute Number）（先頭値と末端値）を求める。
【０１７２】
Attribute Number＝（Resolution-number）×（全Layer数）
＋（Layer-number＋１） ・・・（２）
【０１７３】
なお、全Layer数は、レイヤの総数を示す。
【０１７４】
例えば、図１８の例において、全Layer数Ｌ＝５とすると、分割コードストリーム２５１のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１７５】
先頭値＝R_f×（L）＋L_f＋１＝０×５＋０＋１＝１
末端値＝R_t×（L）＋L_t＋１＝１×５＋１＋１＝７
【０１７６】
また、分割コードストリーム２７２のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１７７】
先頭値＝R_f×（L）＋L_f＋１＝１×５＋１＋１＝７
末端値＝R_t×（L）＋L_t＋１＝１×５＋５＋１＝１１
【０１７８】
R-L用算出部２０３は、以上のように、変数（R_f,R_t）および（L_f,L_t）の値が供給される全ての分割コードストリームについて、アトリビュート番号の先頭値と末端値を求める。R-L用算出部２０３は、求めたアトリビュート番号の先頭値および末端値をヘッダ記述部１９４に供給する（矢印２１３）。
【０１７９】
ヘッダ記述部１９４は、R-L用算出部２０３から供給されたアトリビュート番号の先頭値および末端値の分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダの拡張パラメータ領域に、そのアトリビュート番号の先頭値および末端値を記述する。
【０１８０】
この方法は、基本的に、上述したL-Rタイプの場合と同様である。例えば、ヘッダ記述部１９４は、R-L用算出部２０３からアトリビュート番号の先頭値および末端値を供給されると、NORMヘッダを生成し、アトリビュート拡張フラグＸに値「１」をセットし、アトリビュートタイプの値を「１」にセットする。さらに、ヘッダ記述部１９４は、R-L用算出部２０３から供給されたアトリビュート番号の先頭値をFROMに記述し、R-L用算出部２０３から供給されたアトリビュート番号の末端値をTOに記述する。
【０１８１】
図１０に戻り、ヘッダ記述部１９４は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【０１８２】
［処理の流れ］
以上のような各処理の流れの例を説明する。最初に、図１９のフローチャートを参照して、配信用データ生成装置１０１により実行される配信データ生成処理の流れの例を説明する。
【０１８３】
例えば、ユーザから処理実行を指示されたり、外部から画像データが供給されたり、画像データが生成されたりすると、配信用データ生成装置１０１は、配信データ生成処理を開始し、その画像データ（コンテンツデータ）から配信用のデータを生成する。
【０１８４】
配信データ生成処理が開始されると、JPEG2000エンコーダ１２１は、ステップＳ１０１において、配信用データを作成する画像データをJPEG2000方式で符号化する。
【０１８５】
ステップＳ１０２において、コードストリーム分割部１２２は、符号化されて得られた符号化コードストリームを所定のデータ長毎に分割し、分割コードストリームを生成する。
【０１８６】
ステップＳ１０３において、NORMヘッダ生成部１２３は、各分割コードストリームについてNORMヘッダを生成し、その拡張パラメータ領域にアトリビュート番号の先頭値および末端値を記述する。
【０１８７】
ステップＳ１０４において、ネットワークパケット生成部１２４は、生成されたNORMヘッダを用いて、各分割コードストリームをパケット化し、ネットワークパケットを生成する。ステップＳ１０５において、ネットワークパケット生成部１２４は、生成したネットワークパケットを出力する。
【０１８８】
配信用データ生成装置１０１から出力されたネットワークパケットはコンテンツサーバ１０２に供給され、格納される。
【０１８９】
次に、図１９のステップＳ１０１において実行される符号化処理の詳細な流れの例について、図２０のフローチャートを参照して説明する。
【０１９０】
符号化処理が開始されると、ウェーブレット変換部１５１は、ステップＳ１２１において、１ピクチャ分の画像データをウェーブレット変換する。ステップＳ１２２において、量子化部１５２は、ステップＳ１２１において生成された係数データを量子化する。なお、可逆符号化の場合、このステップＳ１２２の処理は省略される。
【０１９１】
ステップＳ１２３において、コードブロック化部１５３は、係数データをコードブロック化する。ステップＳ１２４において、ビットプレーン展開部１５４は、各コードブロックの係数データをビットプレーン展開する。
【０１９２】
ステップＳ１２５において、EBCOT１５５のビットモデリング部１６１は、ビットモデリング処理を実行する。ステップＳ１２６において、EBCOT１５５のMQ符号化部１６２は、MQ符号化処理を行う。
【０１９３】
ステップＳ１２７において、符号化コードストリーム生成部１５６は、EBCOT１５５において生成された符号化データを整列して符号化コードストリームを生成する。また、ステップＳ１２８において、符号化コードストリーム生成部１５６は、生成した符号化コードストリームについてプログレッションオーダ情報を生成する。
【０１９４】
ステップＳ１２９において、符号化コードストリーム生成部１５６は、符号化コードストリームを出力する。また、ステップＳ１３０において、符号化コードストリーム生成部１５６は、プログレッションオーダ情報を出力する。
【０１９５】
ステップＳ１３０の処理が終了すると、符号化処理が終了され、図１９のステップＳ１０１に戻り、ステップＳ１０２以降の処理が実行される。
【０１９６】
次に、図１９のステップＳ１０３において実行されるNORMヘッダ生成処理の詳細な流れの例について、図２１のフローチャートを参照して説明する。
【０１９７】
NORMヘッダ生成処理が開始されると、ステップＳ１５１において、アドレス抽出部１９１は、各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する。
【０１９８】
ステップＳ１５２において、解像度・レイヤ算出部１９２は、プログレッションオーダ情報に基づいて、先頭アドレスおよび末端アドレスから、各分割コードストリームの先頭および末端の解像度およびレイヤ（画像特徴量）を求める。
【０１９９】
ステップＳ１５３において、アトリビュート番号算出部１９３は、各分割コードストリームの先頭および末端の解像度およびレイヤから、各分割コードストリームのアトリビュート番号の先頭値および末端値を求める。
【０２００】
ステップＳ１５４において、ヘッダ記述部１９４は、各分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダにアトリビュート番号の先頭値および末端値を記述する。
【０２０１】
ステップＳ１５４の処理が終了すると、図１９のステップＳ１０３に戻り、ステップＳ１０４以降の処理が実行される。
【０２０２】
次に、図２２のフローチャートを参照して、図２１のステップＳ１５３において実行されるアトリビュート番号算出処理の詳細な流れの例について説明する。
【０２０３】
アトリビュート番号算出処理が開始されると、ステップＳ１７１において、タイプ判定部２０１は、プログレッションオーダ情報から符号化コードストリームのタイプを判定する。
【０２０４】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部２０１は、ステップＳ１７２において処理をステップＳ１７３に進める。ステップＳ１７３において、L-R用算出部２０２は、L-R用算出式（例えば式（１））を用いて、解像度番号およびレイヤ番号からアトリビュート番号を求める。
【０２０５】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部２０１は、ステップＳ１７２において処理をステップＳ１７４に進める。ステップＳ１７４において、R-L用算出部２０３は、R-L用算出式（例えば式（２））を用いて、解像度番号およびレイヤ番号からアトリビュート番号を求める。
【０２０６】
アトリビュート番号が求められると、アトリビュート番号算出処理が終了され、図２１のステップＳ１５３に戻り、ステップＳ１５４以降の処理が実行される。
【０２０７】
以上のように、NORMヘッダ生成部１２３が、NORMヘッダの拡張パラメータ領域に、ネットワークパケット（分割コードストリーム）の先頭と末端のそれぞれについて、解像度とレイヤ（画像特徴量）を示す情報として、アトリビュート番号等を記述する。詳細については後述するが、このネットワークパケットを処理（配信）する配信サーバ１０３は、このNORMヘッダの情報に基づいて、取捨選択するだけで所望の画像特徴量に応じて必要なデータをより容易に得ることができる。
【０２０８】
つまり、配信用データ生成装置１０１は、アトリビュート番号に関する情報（例えば解像度やレイヤ等の画像特徴量に関する情報）をネットワークパケットに付加することにより、配信サーバ１０３が所望の画像特徴量（解像度や画質等）に応じて必要なデータをより容易に得ることができるネットワークパケットを生成することができる。
【０２０９】
なお、このアトリビュート番号に関する情報（画像特徴量に関する情報）は、上述した拡張パラメータ領域以外の任意の位置（NORMヘッダ以外も含む）に付加する（記述する）ことができる。
【０２１０】
ただし、アトリビュート番号等を付加する領域として、既存のNORMヘッダの、従来使用されていない拡張パラメータ領域を利用することにより、不要なデータ量の増大を抑制することができる。また、従来の規格に準拠したまま、アトリビュート番号等を付加することができる。つまり、このアトリビュート番号に関する情報を処理することが出来ない従来の装置であっても、ネットワークパケットのそれ以外の部分については、従来どおり処理することができる。
【０２１１】
また、解像度・レイヤ算出部１９２は、プログレッションオーダ情報に基づいて、符号化コードストリームの構造を把握するので、符号化コードストリームのタイプに依らず、解像度番号とレイヤ番号を正しく求めることができる。
【０２１２】
さらに、アトリビュート番号算出部１９３は、符号化コードストリームのタイプを判定し、タイプに応じた算出式を用いてアトリビュート番号を求めるので、符号化コードストリームのタイプに依らず、アトリビュート番号を正しく求めることができる。
【０２１３】
さらに、ヘッダ記述部１９４が、符号化コードストリームのタイプを示すアトリビュートタイプをNORMヘッダに記述するので、後述するように、このネットワークパケットを処理（配信）する配信サーバ１０３は、このNORMヘッダの情報に基づいて、容易に、符号化コードストリームのタイプを把握することができる。つまり、配信サーバ１０３は、符号化コードストリームのタイプに依らず、容易に適切な処理を行うことができる。
【０２１４】
なお、以上においては、NORMヘッダ生成部１２３がアトリビュート番号をNORMヘッダに記述するように説明したが、アトリビュート番号の代わりに、画像特徴量（例えば解像度番号とレイヤ番号）を記述するようにしてもよい。ただし、アトリビュート番号は１つの値であり、解像度番号とレイヤ番号よりもデータ量が少ない。つまり、NORMヘッダにアトリビュート番号を記述する場合の方が、解像度番号とレイヤ番号の両方を記述する場合よりも、ネットワークパケットのデータ量を低減させることができる。
【０２１５】
また、符号化コードストリームのタイプとして、上述したL-RタイプおよびR-Lタイプ以外のタイプを設けるようにしてもよい。例えば、プログレッションに関する変数として、解像度とレイヤ以外の画像特徴量を適用するようにしてもよい。さらに、適用されるタイプの数は任意であり、例えば３つ以上であってもよいし、１つであってもよい。
【０２１６】
どのようなタイプが設定されるとしても、プログレッションオーダ情報には、適用される全てのタイプについて、符号化コードストリームの構造が示されている。したがって、解像度・レイヤ算出部１９２は、適用される全てのタイプの符号化コードストリームの構造を、プログレッションオーダ情報を参照することにより把握することができる。なお、解像度およびレイヤ以外の画像特徴量をプログレッションに関する変数として適用する場合、解像度・レイヤ算出部１９２は、解像度番号やレイヤ番号の場合と同様に、その画像特徴量の識別番号を求める。
【０２１７】
また、アトリビュート番号算出部１９３は、適用される全てのタイプについて、各タイプ専用の算出式を用いてアトリビュート番号を算出する算出部を有している。タイプ判定部２０１は、判定したタイプの算出部に、各分割コードストリームの解像度番号およびレイヤ番号等の情報を供給する。
【０２１８】
さらに、ヘッダ記述部１９４が記述するアトリビュートタイプは、適用される全てのタイプについて、互いに異なる値が予め用意されている。
【０２１９】
［配信サーバの構成例］
次に、以上のように生成されたネットワークパケットを利用する装置について説明する。上述したように、配信サーバ１０３は、コンテンツサーバ１０２からネットワークパケットを取得し、それを端末装置１０４や端末装置１０５に配信する。
【０２２０】
このとき、配信サーバ１０３は、各ネットワークパケットのNORMヘッダに含まれるアトリビュート番号に基づいて、所望の画像特徴量に応じて必要なデータのネットワークパケットのみを選択し、配信する。
【０２２１】
図２３は、図１の配信サーバ１０３の主な構成例を示すブロック図である。
【０２２２】
図２３に示されるように、配信サーバ１０３は、選択対象解像度・レイヤ決定部３０１、プログレッションオーダ情報取得部３０２、ネットワークパケット取得部３０３、解像度・レイヤ算出部３０４、ネットワークパケット選択部３０５、および、ネットワークパケット送信部３０６を有する。
【０２２３】
選択対象解像度・レイヤ決定部３０１は、各種情報に基づいて、配信する画像の（選択対象とする）解像度およびレイヤ（画像特徴量）を決定する。
【０２２４】
例えば、選択対象解像度・レイヤ決定部３０１が配信する画像が、配信先となる端末装置１０４の性能や状況に対して不要に高解像度・高画質な場合、データ伝送や画像表示において不具合が発生する恐れがある。逆に、選択対象解像度・レイヤ決定部３０１が配信する画像が、配信先となる端末装置１０４の性能に対して不要に低解像度・低画質な場合、端末装置の性能を十分に生かした画像表示を行うことができない（不要に低解像度・低画質な画像表示しか行うことができない）。
【０２２５】
同様に、ネットワークパケットの伝送路となるネットワークの使用可能な帯域幅に対して、データ伝送量が多すぎても少なすぎても好ましくない。また、配信サーバ１０３自身の能力や状況に対しても、データ伝送量は適切であることが望ましい。さらに、コンテンツの配信に対して課金処理を行う場合、配信を要求する端末装置による代金の支払額に応じて、配信する画像の解像度や画質（レイヤ）を制御することも考えられる。
【０２２６】
このように、選択対象解像度・レイヤ決定部３０１は、例えば、受信処理能力、画像処理能力、バッファ容量、若しくはモニタの解像度等の、配信先の装置の性能や状態、ネットワークパケットの伝送路となるネットワークの使用可能帯域幅、配信サーバ１０３自身の性能や状態、配信に対する代金支払額、若しくはユーザの指示等、任意の条件に基づいて選択対象とする解像度およびレイヤ（画像特徴量）を決定する。
【０２２７】
選択対象解像度・レイヤ決定部３０１は、決定した解像度やレイヤの情報を、ネットワークパケット選択部３０５に通知する（矢印３３１）。
【０２２８】
プログレッションオーダ情報取得部３０２は、コンテンツサーバ１０２から取得するネットワークパケットに対応する符号化コードストリームのプログレッションオーダ情報を取得する。プログレッションオーダ情報取得部３０２は、取得したプログレッションオーダ情報を解像度・レイヤ算出部３０４に供給する（矢印３３２）。
【０２２９】
ネットワークパケット取得部３０３は、配信するコンテンツのネットワークパケットをコンテンツサーバ１０２から取得し、それを解像度・レイヤ算出部３０４に供給する（矢印３３３）。
【０２３０】
解像度・レイヤ算出部３０４は、ネットワークパケット取得部３０３から供給された各ネットワークパケットのNORMヘッダを参照し、アトリビュート番号の先頭値および末端値から、各ネットワークパケットの先頭および末端の解像度番号およびレイヤ番号（画像特徴量）を求める。
【０２３１】
解像度・レイヤ算出部３０４は、タイプ判定部３１１、L-R用算出部３１２、およびR-L用算出部３１３を有する。
【０２３２】
タイプ判定部３１１は、プログレッションオーダ情報取得部３０２から供給されたプログレッションオーダ情報（矢印３３２）に基づいて、ネットワークパケット取得部３０３から供給されるネットワークパケット（矢印３３３）に対応する符号化コードストリームのタイプを判定する。
【０２３３】
タイプ判定部３１１は、符号化コードストリームのタイプがL-Rタイプである場合、ネットワークパケット取得部３０３から供給される各ネットワークパケットをL-R用算出部３１２に供給する（矢印３４１）。
【０２３４】
L-R用算出部３１２は、上述した式（１）に示されるようなL-R用の算出式を用いて、各分割コードストリームについて、アトリビュート番号の先頭値と末端値から、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）をそれぞれ求める。
【０２３５】
なお、１つの値から２つの変数（R_fとL_f、若しくは、R_tとL_t）の値を求めることになるが、これらの変数はいずれも自然数であり、かつ、解像度番号（R_fおよびR_t）は、Resolution level数Ｒ（Res-R）以下である。したがって、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）はアトリビュート番号の先頭値と末端値によって一意に定まる。
【０２３６】
より具体的に説明すると、例えば分割コードストリームの末端の場合、L-R用算出部３１２は、アトリビュート番号の値から１を減算した値をResolution level数Ｒ（Res-R）で除算し、その商をレイヤ番号L_tとし、その余を解像度番号R_tとする。ただし、余は０以外の値でなければならない。つまりこの場合、L-R用算出部３１２は、商から１を減算した値をレイヤ番号L_tとし、その場合の余を解像度番号R_tとする。つまりこの場合、解像度番号R_tの値はＲとなる。
【０２３７】
なお、先頭については、１番目のネットワークパケット（Network Packet 1）の解像度番号R_fとレイヤ番号L_fはともに０である。２番目以降のネットワークパケットの場合、その先頭の解像度番号R_fとレイヤ番号L_fは、上述した末端の解像度番号R_tとレイヤ番号L_tの場合と同様に求めることができる。
【０２３８】
L-R用算出部３１２は、算出した解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）を、そのネットワークパケットとともにネットワークパケット選択部３０５に供給する（矢印３３４）
【０２３９】
また、タイプ判定部３１１は、符号化コードストリームのタイプがR-Lタイプである場合、ネットワークパケット取得部３０３から供給される各ネットワークパケットをR-L用算出部３１３に供給する（矢印３４２）。
【０２４０】
R-L用算出部３１３は、上述した式（２）に示されるようなR-L用の算出式を用いて、各分割コードストリームについて、アトリビュート番号の先頭値と末端値から、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）をそれぞれ求める。
【０２４１】
この場合も、L-Rタイプの場合と同様に、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）は、アトリビュート番号の先頭値と末端値によって一意に定まる。
【０２４２】
より具体的に説明すると、例えば分割コードストリームの末端の場合、R-L用算出部３１３は、アトリビュート番号の値から１を減算した値を全Layer数Ｌで除算し、その商を解像度番号R_tとし、その余をレイヤ番号L_tとする。ただし、余は０以外の値でなければならない。つまりこの場合、R-L用算出部３１３は、商から１を減算した値を解像度番号R_tとし、その場合の余をレイヤ番号L_tとする。つまりこの場合、レイヤ番号L_tの値はＬとなる。
【０２４３】
なお、先頭については、１番目のネットワークパケット（Network Packet 1）の解像度番号R_fとレイヤ番号L_fはともに０である。２番目以降のネットワークパケットの場合、その先頭の解像度番号R_fとレイヤ番号L_fは、上述した末端の解像度番号R_tとレイヤ番号L_tの場合と同様に求めることができる。
【０２４４】
R-L用算出部３１３は、算出した解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）を、そのネットワークパケットとともに、ネットワークパケット選択部３０５に供給する（矢印３３４）
【０２４５】
ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１から供給された解像度およびレイヤ（画像特徴量）の指定に基づいてネットワークパケットの取捨選択を行い、指定された解像度およびレイヤの画像を得るのに必要なネットワークパケットを選択する。
【０２４６】
選択対象解像度・レイヤ決定部３０１によって指定された解像度の画像を得るためには、その解像度より低い解像度番号の符号化データ（パケット）が全て必要である。同様に、選択対象解像度・レイヤ決定部３０１によって指定されたレイヤ（画質）の画像を得るためには、そのレイヤより低いレイヤ番号の符号化データ（パケット）が全て必要である。
【０２４７】
つまり、選択対象解像度・レイヤ決定部３０１によって指定された解像度およびレイヤ（画質）の画像を得るためには、指定された解像度より低い解像度番号の符号化データ（パケット）と、指定されたレイヤより低いレイヤ番号の符号化データ（パケット）とが全て必要である。
【０２４８】
したがって、ネットワークパケット選択部３０５は、これらの符号化データ（パケット）を含むネットワークパケットを全て選択する。つまり、ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１によって指定された解像度およびレイヤの画像に対応する画像データ（符号化データ）を含むネットワークパケットを選択する。
【０２４９】
図１６および図１８に示されるように、符号化コードストリームにおいて符号化データは、その画像の解像度およびレイヤ毎にパケット化されて所定順に整列されている。したがって、ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１による指定に該当する解像度およびレイヤのパケットを含む分割コードストリームをBodyとするネットワークパケットを選択すればよい。
【０２５０】
ネットワークパケットが該当する解像度およびレイヤのパケットを含むか否かは、分割コードストリームの先頭と末端の解像度番号およびレイヤ番号から判別することができる。
【０２５１】
ただし、図１６および図１８を参照して説明したように、符号化コードストリームの構造（パケットの並び）は、そのタイプによって異なる。
【０２５２】
したがって、ネットワークパケット選択部３０５は、符号化コードストリームのタイプに応じた判定式を用いてネットワークパケットの選択を行う。
【０２５３】
ネットワークパケット選択部３０５は、タイプ判定部３２１、L-R用選択部３２２、およびR-L用選択部３２３を有する。
【０２５４】
タイプ判定部３２１は、プログレッションオーダ情報に基づいて、ネットワークパケットに対応する符号化コードストリームのタイプを判定する。
【０２５５】
タイプ判定部３２１は、符号化コードストリームのタイプがL-Rタイプである場合、解像度・レイヤ算出部３０４から供給される各ネットワークパケットをL-R用選択部３２２に供給する（矢印３５１）。
【０２５６】
L-R用選択部３２２は、L-Rタイプ用に用意されたL-R用判定式を用いて各ネットワークパケットの取捨選択を行う。このL-R用判定式は、L-Rタイプの構造に対応している。つまり、L-R用選択部３２２は、このL-R用判定式を用いることにより、L-Rタイプの符号化コードストリームから作成されたネットワークパケットの先頭および末端の解像度番号およびレイヤ番号から、そのネットワークパケットが選択対象解像度・レイヤ決定部３０１において決定された解像度およびレイヤの画像を得るのに必要な符号化データ（パケット）を含むか否かを正しく特定することができる。
【０２５７】
L-R用選択部３２２は、このように、条件を満たすネットワークパケットを選択し、抽出する。L-R用選択部３２２は、抽出したネットワークパケットをネットワークパケット送信部３０６に供給する（矢印３３５）。
【０２５８】
また、タイプ判定部３２１は、符号化コードストリームのタイプがR-Lタイプである場合、解像度・レイヤ算出部３０４から供給される各ネットワークパケットをR-L用選択部３２３に供給する（矢印３５２）。
【０２５９】
R-L用選択部３２３は、R-Lタイプ用に用意されたR-L用判定式を用いて各ネットワークパケットの取捨選択を行う。このR-L用判定式は、R-Lタイプの構造に対応している。つまり、R-L用選択部３２３は、このR-L用判定式を用いることにより、R-Lタイプの符号化コードストリームから作成されたネットワークパケットの先頭および末端の解像度番号およびレイヤ番号から、そのネットワークパケットが選択対象解像度・レイヤ決定部３０１において決定された解像度およびレイヤの画像を得るのに必要な符号化データ（パケット）を含むか否かを正しく特定することができる。
【０２６０】
R-L用選択部３２３は、このように、条件を満たすネットワークパケットを選択し、抽出する。R-L用選択部３２３は、抽出したネットワークパケットをネットワークパケット送信部３０６に供給する（矢印３３５）。
【０２６１】
ネットワークパケット送信部３０６は、ネットワークパケット選択部３０５において選択されたネットワークパケットを、配信先となる端末装置１０４若しくは端末装置１０５に送信する。
【０２６２】
［処理の流れ］
以上のような各処理の流れの例を説明する。最初に、図２４のフローチャートを参照して、配信サーバ１０３により実行されるネットワークパケット配信処理の流れの例を説明する。
【０２６３】
例えば、端末装置１０４や端末装置１０５からの要求やユーザの指示等に基づいて、ネットワークパケットの配信が決定すると、配信サーバ１０３は、ネットワークパケット配信処理を開始する。
【０２６４】
ネットワークパケット配信処理が開始されると、選択対象解像度・レイヤ決定部３０１は、ステップＳ３０１において、選択対象の解像度およびレイヤを決定する。
【０２６５】
ステップＳ３０２において、プログレッションオーダ情報取得部３０２は、所望のコンテンツのプログレッションオーダ情報をコンテンツサーバ１０２から取得する。
【０２６６】
ステップＳ３０３において、ネットワークパケット取得部３０３は、コンテンツサーバ１０２から、所望のコンテンツのネットワークパケットを取得する。
【０２６７】
ステップＳ３０４において、解像度・レイヤ算出部３０４は、分割コードストリームの先頭および末端の解像度およびレイヤを算出する。
【０２６８】
ステップＳ３０５において、ネットワークパケット選択部３０５は、選択対象の解像度およびレイヤに基づいて、ネットワークパケットを選択する。
【０２６９】
ステップＳ３０６において、ネットワークパケット送信部３０６は、選択されたネットワークパケットを送信する。
【０２７０】
ステップＳ３０７において、ネットワークパケット取得部３０３は、全てのネットワークパケットを処理したか否かを判定する。所望のコンテンツに、未処理のネットワークパケットが存在すると判定された場合、ステップＳ３０３に戻り、それ以降の処理が繰り返される。
【０２７１】
また、ステップＳ３０７において、所望のコンテンツのネットワークパケットが全て処理されたと判定された場合、ネットワークパケット配信処理が終了される。
【０２７２】
次に、図２４のステップＳ３０４において実行される解像度レイヤ算出処理の詳細な流れの例を図２５のフローチャートを参照して説明する。
【０２７３】
解像度レイヤ算出処理が開始されると、ステップＳ３２１において、タイプ判定部３１１は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定する。
【０２７４】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部３１１は、ステップＳ３２２において処理をステップＳ３２３に進める。ステップＳ３２３において、L-R用算出部３１２は、L-R用算出式を用いて、アトリビュート番号から解像度番号およびレイヤ番号を求める。
【０２７５】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部３１１は、ステップＳ３２２において処理をステップＳ３２４に進める。ステップＳ３２４において、R-L用算出部３１３は、R-L用算出式を用いて、アトリビュート番号から解像度番号およびレイヤ番号を求める。
【０２７６】
解像度番号およびレイヤ番号が求められると、解像度レイヤ算出処理が終了され、図２４のステップＳ３０４に戻り、ステップＳ３０５以降の処理が実行される。
【０２７７】
次に、図２４のステップＳ３０５において実行される選択処理の詳細な流れの例を図２６のフローチャートを参照して説明する。
【０２７８】
選択処理が開始されると、ステップＳ３４１において、タイプ判定部３２１は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定する。
【０２７９】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部３２１は、ステップＳ３４２において処理をステップＳ３４３に進める。ステップＳ３４３において、L-R用選択部３２２は、L-R用判定式を用いて、パケットの選択を行う。
【０２８０】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部３２１は、ステップＳ３４２において処理をステップＳ３４４に進める。ステップＳ３４４において、R-L用選択部３２３は、R-L用判定式を用いて、パケットの選択を行う。
【０２８１】
パケットが選択されると、選択処理が終了され、図２４のステップＳ３０５に戻り、ステップＳ３０６以降の処理が実行される。
【０２８２】
以上のように、解像度・レイヤ算出部３０４が、各ネットワークパケットのNORMヘッダの拡張パラメータ領域に記述されたアトリビュート番号の先頭値および末端値から、そのネットワークパケットに含まれる分割コードストリームの先頭および末端の解像度番号およびレイヤ番号を求める。
【０２８３】
そして、ネットワークパケット選択部３０５は、その解像度番号およびレイヤ番号に基づいて、所望の解像度およびレイヤ（画質）の画像を得るのに必要なネットワークパケットを選択し、抽出する。
【０２８４】
このようにすることにより、配信サーバ１０３は、NORMヘッダに記述されたアトリビュート番号等の情報に基づいてネットワークパケットを取捨選択するだけで、所望の画像特徴量に応じて必要なデータをより容易に得ることができる。
【０２８５】
なお、このアトリビュート番号に関する情報（画像特徴量に関する情報）は、各ネットワークパケットのNORMヘッダに記述されているので、配信サーバ１０３は、従来と同様の方法でネットワークパケットを処理することができる。すなわち、配信サーバ１０３は、容易に、そのアトリビュート番号に関する情報を参照して処理することができる。
【０２８６】
また、解像度・レイヤ算出部３０４は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定し、そのタイプに応じた算出式を用いてアトリビュート番号から解像度番号やレイヤ番号を求めるので、符号化コードストリームのタイプに依らず、解像度番号やレイヤ番号を正しく求めることができる。
【０２８７】
さらに、ネットワークパケット選択部３０５は、符号化コードストリームのタイプに応じた判定式を用いてネットワークパケットの選択を行うので、符号化コードストリームのタイプに依らず、所望の解像度や画質に応じて必要なデータを正しく得ることができる。
【０２８８】
つまり、配信サーバ１０３は、符号化コードストリームのタイプを判別し、そのタイプに応じて適切な処理方法を選択することができるので、複数のタイプに対応することができる。
【０２８９】
もちろん、配信サーバ１０３は、上述したL-RタイプおよびR-Lタイプ以外のタイプにも対応することができる。例えば、符号化コードストリームは、解像度とレイヤ以外の画像特徴量をプログレッションに関する変数として適用するようにしてもよい。さらに、適用されるタイプの数は任意であり、例えば３つ以上であってもよいし、１つであってもよい。
【０２９０】
どのようなタイプが設定されるとしても、プログレッションオーダ情報には、適用される全てのタイプについて、符号化コードストリームの構造が示されている。したがって、解像度・レイヤ算出部３０４およびネットワークパケット選択部３０５は、適用される全てのタイプの符号化コードストリームの構造を、プログレッションオーダ情報を参照することにより把握することができる。
【０２９１】
なお、解像度・およびレイヤ以外の特徴量をプログレッションに関する変数として適用する場合、解像度・レイヤ算出部３０４は、解像度番号やレイヤ番号の場合と同様に、その特徴量についての識別番号を求める。選択対象解像度・レイヤ決定部３０１は、その特徴量について選択対象とする値を決定し、ネットワークパケット選択部３０５は、解像度やレイヤの場合と同様に、その特徴量の値を条件として、ネットワークパケットの選択を行う。
【０２９２】
また、解像度・レイヤ算出部３０４は、適用される全てのタイプについて、各タイプ専用の算出式を用いて解像度番号やレイヤ番号等の画像特徴量を算出する算出部を有している。タイプ判定部３１１は、判定したタイプの算出部に、各分割コードストリームのアトリビュート番号等の情報を供給する。
【０２９３】
同様に、ネットワークパケット選択部３０５は、適用される全てのタイプについて、各タイプ専用の判定式を用いてネットワークパケットの選択を行う選択部を有している。タイプ判定部３２１は、判定したタイプの選択部に、各ネットワークパケットを供給する。
【０２９４】
以上のように、コンテンツ配信システム１００は、例えば解像度や画質等、所望の特徴量に応じて、必要なデータをより容易に得ることができる。
【０２９５】
なお、図１においてコンテンツ配信システム１００の構成例を示したが、このコンテンツ配信システム１００を構成する各装置の数は任意である。また、コンテンツサーバ１０２を省略し、配信用データ生成装置１０１が生成したネットワークパケットを配信サーバ１０３に供給するようにしてもよい。
【０２９６】
また、この各装置が、図１で矢印により示される接続先以外の装置にさらに接続されているようにしても良い。例えば、配信用データ生成装置１０１が、コンテンツサーバ１０２だけでなく、さらに配信サーバ１０３や端末装置１０４および端末装置１０５と接続されるようにしても良い。その他の各装置についても同様である。
【０２９７】
さらに、以上においては、アトリビュート番号が付加されたネットワークパケットの利用方法としてそのネットワークパケットを送信（配信）する例について説明したが、ネットワークパケットの利用方法は任意である。
【０２９８】
また、以上においては、配信用データ生成装置１０１が、画像データをJPEG2000方式で符号化するように説明したが、符号化コードストリームがプログレッション順の構造を有するようにすればよく、画像データの符号化方式はJPEG2000方式に限定されない。
【０２９９】
＜２．第２の実施の形態＞
［パーソナルコンピュータ］
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。この場合、例えば、図２７に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０３００】
図２７において、パーソナルコンピュータ４００のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０３０１】
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
【０３０２】
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）ディスプレイやLCD（Liquid Crystal Display）等のディスプレイ、並びにスピーカなどよりなる出力部４１２、フラッシュメモリ等SSD（Solid State Drive）やハードディスクなどよりなる記憶部４１３、有線LAN（Local Area Network）や無線LANのインタフェースやモデムなどよりなる通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０３０３】
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
【０３０４】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０３０５】
この記録媒体は、例えば、図２７に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、若しくは半導体メモリなどよりなるリムーバブルメディア４２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM４０２や、記憶部４１３に含まれるハードディスクなどにより構成される。
【０３０６】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０３０７】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３０８】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
【０３０９】
また、以上において、１つの装置（または処理部）として説明した構成が、複数の装置（または処理部）として構成されるようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成が、まとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成が付加されるようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部が他の装置（または他の処理部）の構成に含まれるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【０３１０】
本発明は、例えば、デジタルシネマ用編集装置、アーカイブシステム、放送局の画像伝送装置、画像データベース、医用画像の記録システム、ネットワークサーバ、インターネット上の画像伝送装置、無線伝送装置、映画館からの２次映像配信装置、ノンリニア編集装置、ゲーム機、テレビ受像機システム、HDDレコーダ、PC上のオーサリング・ツールまたはそのソフトウェア・モジュール等に適用することができる。
【符号の説明】
【０３１１】
１００ コンテンツ配信システム， １０１ 配信用データ生成装置， １０２ コンテンツサーバ， １０３ 配信サーバ， １０４および１０５ 端末装置， １２１ JPEG2000エンコーダ， １２２ コードストリーム分割部， １２３ NORMヘッダ生成部， １２４ ネットワークパケット生成部， １９１ アドレス抽出部， １９２ 解像度・レイヤ算出部， １９３ アトリビュート番号算出部， １９４ ヘッダ記述部， ２０１ タイプ判定部， ２０２ L-R用算出部， ２０３ R-L用算出部， ３０１ 選択対象解像度・レイヤ決定部， ３０２ プログレッションオーダ情報取得部， ３０３ ネットワークパケット取得部， ３０４ 解像度・レイヤ算出部， ３０５ ネットワークパケット選択部， ３０６ ネットワークパケット送信部， ３１１ タイプ判定部， ３１２ L-R用算出部， ３１３ R-L用算出部， ３２１ タイプ判定部， ３２２ L-R用選択部， ３２３ R-L用選択部
【技術分野】
【０００１】
本発明は、画像処理装置および方法に関し、特に、所望の特徴量に応じて、必要なデータをより容易に得ることができるようにした画像処理装置および方法に関する。
【背景技術】
【０００２】
2000年にISO（International Organization for Standardization）/IEC（International Electrotechnical Commission）で標準化されたJPEG2000（Joint Photographic Experts Group 2000）は、高圧縮率で符号化することができ、可逆と非可逆圧縮の両方に対応することができ、解像度や画質をスケラビリティに復号することができるように符号化することができ、さらに、エラー耐性を向上させるように符号化することができる等、様々な特徴を有する技術として、JPEGの代替技術としての期待が高まっている（例えば、特許文献１参照）。
【０００３】
2004年にはデジタルシネマの標準規格（DCI（Digital Cinema Initiative））によって、標準コーデックとしてJPEG2000 Part-1が選ばれた。これによってデジタルシネマの映像撮影から、画像編集、画像配信まで、符号化方式をすべてJPEG2000で統一することが可能になった。
【０００４】
また、このようにJPEG2000で符号化されたデジタルシネマコンテンツは、さらに、ライブイベントや小規模の映画館に２次配信を行ったり、仮想空間提供サービスのユーザに対して提供（例えば仮想空間上の映画館で上映）したり、携帯電話機やノート型パーソナルコンピュータ等のような携帯型電子機器に配信を行ったりすることも考えられている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−３１１３２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、元々の高画質高解像度のデジタルシネマコンテンツはデータ量が大きく、仮想空間上での上映や、低性能の携帯型電子機器等への配信には不向きである。
【０００７】
そのため配信先等に応じて解像度や画質を調整したデータを予め用意することも考えられるが、配信方法、伝送路、および配信先等の多様性はさらに増大する傾向にあり、全ての条件に対応するようにデータを用意することは困難であった。
【０００８】
そこで、配信時に解像度や画質を適切な値に調整する方法も考えられるが、データの復号や符号化を伴う作業は容易ではなく、短時間で行うことは困難であった。
【０００９】
本発明は、このような状況に鑑みて提案されたものであり、例えば解像度や画質等、所望の特徴量に応じて、必要なデータをより容易に得ることができるようにすることを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一側面は、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成するヘッダ情報生成手段と、前記ヘッダ情報生成手段により生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化するバケット生成手段とを備える画像処理装置である。
【００１１】
前記画像データを符号化し、前記プログレッション順の構造を有する前記コードストリームを生成する符号化手段をさらに備え、前記ヘッダ情報生成手段は、前記符号化手段により前記画像データが符号化されて生成された前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成することができる。
【００１２】
前記符号化手段により前記画像データが符号化されて生成された前記コードストリームを所定のデータ長毎に分割する分割手段をさらに備え、前記ヘッダ情報生成手段は、前記分割手段により前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成することができる。
【００１３】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものであるようにすることができる。
【００１４】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含むようにすることができる。
【００１５】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度であるようにすることができる。
【００１６】
前記ヘッダ情報生成手段は。各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する抽出手段と、前記アドレス抽出手段により抽出された前記先頭アドレスおよび前記末端アドレス、並びに、前記プログレッション順に基づいて、各分割コードストリームの先頭および末端の特徴量を算出する特徴量算出手段と、前記特徴量算出手段により算出された、各分割コードストリームの先頭および末端の前記特徴量から、前記特徴量を他と識別する識別番号であるアトリビュート番号を算出するアトリビュート番号算出手段と、前記ヘッダ情報を生成し、前記ヘッダ情報に、前記アトリビュート番号算出手段により算出された前記アトリビュート番号を記述する記述手段とを備えることができる。
【００１７】
前記アトリビュート番号算出手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号を算出する算出処理手段とを備えることができる。
【００１８】
本発明の一側面は、また、画像処理装置の画像処理方法であって、前記画像処理装置のヘッダ情報生成手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成し、前記画像処理装置のパケット生成手段が、生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化する画像処理方法である。
【００１９】
本発明の他の側面は、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定する特徴量特定手段と、前記特徴量特定手段により特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行うパケット選択手段とを備える画像処理装置である。
【００２０】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものであるようにすることができる。
【００２１】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含むようにすることができる。
【００２２】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度であるようにすることができる。
【００２３】
前記パケットは、前記パケットに含まれる前記分割コードストリームの先頭および末端の、前記特徴量を他と識別する識別番号であるアトリビュート番号を含み、前記特徴量特定手段は、前記アトリビュート番号から前記特徴量を求めることができる。
【００２４】
前記特徴量特定手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号から前記特徴量を算出する算出処理手段とを備えることができる。
【００２５】
前記パケット選択手段は、前記プログレッション順を判定する判定手段と、前記判定手段により判定された前記プログレッション順専用の判定式を用いて、前記パケットの選択を行う選択処理手段とを備えることができる。
【００２６】
本発明の他の側面は、また、画像処理装置の画像処理方法であって、前記画像処理装置の特徴量特定手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定し、前記画像処理装置のパケット選択手段が、特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行う画像処理方法である。
【００２７】
本発明の一側面においては、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、分割コードストリームの先頭および末端の、画像データの画像の特徴量を含むヘッダ情報が生成され、生成されたヘッダ情報を用いて、各分割コードストリームがパケット化される。
【００２８】
本発明の他の側面においては、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、分割コードストリームの先頭および末端の、画像データの画像の特徴量に関する情報に基づいて、分割コードストリームの先頭および末端の特徴量が特定され、特定された分割コードストリームの先頭および末端の特徴量に基づいて、所望の特徴量に応じたパケットの選択が行われる。
【発明の効果】
【００２９】
本発明によれば、画像を処理することができる。特に、所望の特徴量に応じて必要なデータをより容易に得ることができる。
【図面の簡単な説明】
【００３０】
【図１】本発明を適用したコンテンツ配信システムの主な構成例を示すブロック図である。
【図２】図１の配信用データ生成装置の主な構成例を示すブロック図である。
【図３】図２のJPEG2000エンコーダの主な構成例を示すブロック図である。
【図４】サブバンドの構成例を示す図である。
【図５】サブバンドの構成例を示す図である。
【図６】各サブバンド中のコードブロックの例を示す図である。
【図７】ビットプレーンの例を説明する図である。
【図８】符号化パスの例を説明する図である。
【図９】係数の走査の例を説明する図である。
【図１０】図２のNORMヘッダ生成部の主な構成例を示すブロック図である。
【図１１】レイヤを説明する図である。
【図１２】L-Rタイプの符号化コードストリームの構成例を説明する図である。
【図１３】L-Rタイプの場合の復号画像の復元の様子の例を説明する図である。
【図１４】R-Lタイプの符号化コードストリームの構成例を説明する図である。
【図１５】R-Lタイプの場合の復号画像の復元の様子の例を説明する図である。
【図１６】L-Rタイプのネットワークパケット生成の様子の例を説明する図である。
【図１７】NORMヘッダの構成例を説明する図である。
【図１８】R-Lタイプのネットワークパケット生成の様子の例を説明する図である。
【図１９】配信データ生成処理の流れの例を説明するフローチャートである。
【図２０】符号化処理の流れの例を説明するフローチャートである。
【図２１】NORMヘッダ生成処理の流れの例を説明するフローチャートである。
【図２２】アトリビュート番号算出処理の流れの例を説明するフローチャートである。
【図２３】図１の配信サーバの主な構成例を示すブロック図である。
【図２４】ネットワークパケット配信処理の流れの例を説明するフローチャートである。
【図２５】解像度レイヤ算出処理の流れの例を説明するフローチャートである。
【図２６】選択処理の流れの例を説明するフローチャートである。
【図２７】本発明を適用したパーソナルコンピュータの構成例を示すブロック図である。
【発明を実施するための形態】
【００３１】
以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（コンテンツ配信システム）
２．第２の実施の形態（パーソナルコンピュータ）
【００３２】
＜１．第１の実施の形態＞
［コンテンツ配信システムの構成］
図１は、本発明を適用したコンテンツ配信システムの一実施の形態の構成を表している。
【００３３】
図１に示されるコンテンツ配信システム１００は、画像や音声等よりなるコンテンツのデータを配信するシステムである。コンテンツ配信システム１００においては、配信するコンテンツの画像の特徴量（例えば解像度や画質等）が、その配信先となる端末装置の性能等の各種条件に応じて適切になるように調整されて配信される。
【００３４】
このコンテンツは、例えば、デジタルシネマ用のデジタルシネマコンテンツである。一般的には、コンテンツのデータには、画像データだけでなく音声データやその他のデータも含まれるが、以下においては、説明の便宜上、本発明に関連する画像データについてのみ説明する。
【００３５】
コンテンツ配信システム１００は、例えば、配信用データ生成装置１０１、コンテンツサーバ１０２、配信サーバ１０３、端末装置１０４、および端末装置１０５を有する。
【００３６】
配信用データ生成装置１０１は、生成したり、外部から供給されたりしたコンテンツの画像データを、配信用データに作り替える。より具体的には、配信用データ生成装置１０１は、画像データを、インターネット等のIP（Internet Protocol）ネットワークを介して配信可能なネットワークパケット化する。
【００３７】
配信用データ生成装置１０１は、生成したネットワークパケットをコンテンツサーバ１０２に供給し（矢印１１１）、格納する。
【００３８】
コンテンツサーバ１０２は、配信用データ生成装置１０１により生成されたネットワークパケットを、コンテンツの配信用データとして保持し、管理する。コンテンツサーバ１０２は、配信サーバ１０３からの要求に基づいて、このように管理しているネットワークパケットを配信サーバ１０３に供給する（矢印１１２）。
【００３９】
配信サーバ１０３は、例えば、端末装置１０４や端末装置１０５から要求されたコンテンツをコンテンツサーバ１０２に要求する。配信サーバ１０３は、その要求に基づいてコンテンツサーバ１０２から供給される、要求したコンテンツのネットワークパケットを取得すると、要求元の端末装置にそのネットワークパケットを供給（配信）する（矢印１１３若しくは矢印１１４）。
【００４０】
端末装置１０４および端末装置１０５は、ネットワークパケットを受信し、コンテンツを再生し、出力（画像表示や音声出力等）する装置である。端末装置１０４や端末装置１０５としては、例えば、映画館のデジタルシネマ上映装置、イベント会場等に特設される小型の上映装置、仮想空間上での仮想的な上映装置、テレビジョン受像機やハードディスクレコーダ等の一般家庭に設置されるAV機器、パーソナルコンピュータ、または、携帯電話機やノート型パーソナルコンピュータ等の携帯型電子機器等、通信機能を有する任意の装置が想定される。
【００４１】
なお、配信用データ生成装置１０１とコンテンツサーバ１０２、コンテンツサーバ１０２と配信サーバ１０３、並びに、配信サーバ１０３と端末装置１０４および端末装置１０５は、インターネット等を含む任意のネットワークを介して互いに接続されており、そのネットワークを介して情報の授受を行う。
【００４２】
つまり、矢印１１１乃至矢印１１４により示される各装置間の情報の授受は、そのネットワークを介して行われる。
【００４３】
IPネットワークにデータを伝送する際に、どのようなプロトコルを用いるかが重要である。TCP（Transmission Control Protocol）は汎用性の高いプロトコルであるが送信側から受信側に正しくデータが伝送されないと何度でも再送を繰り返すので、即時的（リアルタイム）な配信が必要なシステムには適さない。
【００４４】
これに対して、マルチキャスト（Multicast）プロトコルは、高いビットレートのデータ伝送や、低いパケットロスでの伝送に適したプロトコルである。解像度の大きいデジタルシネマのデータ伝送には好適である。
【００４５】
しかしながら、マルチキャスト（Multicast）プロトコルでは、UDP（User Datagram Protocol）を使用するため、TCPのようなデータ到着信頼性を実現されていない。データ到着信頼性をマルチキャスト（Multicast）プロトコルに付与するものとしてNACK（不到達確認要求）をしてパケットを回復するNORM（NACK（Negative Acknowledgment） Oriented Reliable Multicast）プロトコルがIETF（Internet Engineering Task Force）で提案されている。
【００４６】
コンテンツ配信システム１００においては、このようなNORMプロトコルを採用する。
【００４７】
以上のように、コンテンツ配信システム１００においては、配信サーバ１０３は、ネットワークパケットをコンテンツサーバ１０２から取得し、それを端末装置１０４や端末装置１０５に配信する。
【００４８】
このような配信に備えて、配信用データ生成装置１０１は、例えば解像度や画質等の、画像の特徴量に関する情報をNORMヘッダの拡張領域に記述し、そのNORMヘッダを含むネットワークパケットを生成する。
【００４９】
配信サーバ１０３は、このようなNORMヘッダを含むネットワークパケットをコンテンツサーバ１０２から取得する。配信サーバ１０３は、そのネットワークパケットに含まれるNORMヘッダを参照することにより、そのネットワークパケットに含まれる画像データ（符号化データ）の画像特徴量（解像度や画質等）を容易に把握することができる。
【００５０】
そこで、配信サーバ１０３は、その画像特徴量に関する情報に基づいて、配信先の端末装置の性能、配信方法、若しくは伝送路等に対して、例えば解像度や画質等の画像特徴量が適切なネットワークパケットのみを選択し、配信する。
【００５１】
このように、配信サーバ１０３は、NORMヘッダの情報に従って、ネットワークパケット（画像データ）を取捨選択するのみで、より容易に、配信先等の各種条件に対して適切な画像特徴量の画像データを配信することができる。つまり、配信サーバ１０３は、目的に応じた適切な（すなわち、所望の）画像特徴量の画像データを、より容易に得ることができる。
【００５２】
換言すれば、配信用データ生成装置１０１は、配信サーバ１０３が、所望の画像特徴量に応じて必要な画像データをより容易に得ることができるような配信用データ（ネットワークパケット）を生成することができる。
【００５３】
さらに換言すれば、このような方法を用いることにより、コンテンツ配信システム１００は、コンテンツサーバ１０２に保持する配信用データ（ネットワークパケット）のデータ量の不要な増大を抑制することができる。つまり、コンテンツ配信システム１００は、コストの増大を抑制しつつより多様な用途に適用可能とすることができる。
【００５４】
以下に、各装置や方法等についてより具体的に説明する。
【００５５】
［配信用データ生成装置の構成］
図２は、図１の配信用データ生成装置１０１の主な構成例を示すブロック図である。
【００５６】
図２に示されるように、配信用データ生成装置１０１は、例えば、JPEG2000エンコーダ１２１、コードストリーム分割部１２２、NORMヘッダ生成部１２３、およびネットワークパケット生成部１２４を有する。
【００５７】
外部よりベースバンドの画像データ等が供給されると（矢印１３１）、JPEG2000エンコーダ１２１は、その画像データをJPEG2000方式で符号化し、符号化コードストリームを生成する。JPEG2000エンコーダ１２１は、生成した符号化コードストリームをコードストリーム分割部１２２に供給する（矢印１３２）。
【００５８】
コードストリーム分割部１２２は、供給された符号化コードストリームを、ネットワークパケットに格納する所定のデータ長毎に分割する。通常、JPEG2000の符号化コードストリームのデータ長は、ネットワークに伝送する際のIPパケットのデータ長よりも遥かに大きい。したがって、JPEG2000エンコーダ１２１において生成された符号化コードストリームは、基本的に、IPパケット長に合わせて複数個のパケットに分割する必要がある。
【００５９】
コードストリーム分割部１２２は、符号化コードストリームを分割して得られた各分割コードストリームをネットワークパケット生成部１２４に供給する（矢印１３３）。コードストリーム分割部１２２は、さらに、各分割コードストリームをNORMヘッダ生成部１２３に供給する（矢印１３４）。
【００６０】
また、JPEG2000エンコーダ１２１は、生成した符号化コードストリームについての、データ構成（解像度やレイヤ等の画像特徴量を変数とする符号化データの順序）を示すプログレッションオーダ情報を生成し、それをNORMヘッダ生成部１２３に供給する（矢印１３５）。
【００６１】
NORMヘッダ生成部１２３は、コードストリーム分割部１２２から供給された各分割コードストリームについて、NORMヘッダを生成する。NORMヘッダ生成部１２３は、さらに、JPEG2000エンコーダ１２１から供給されたプログレッションオーダ情報等に基づいて、各分割コードストリームの画像特徴量（解像度やレイヤ等）を特定し、それらの情報を、NORMヘッダの拡張領域に記述する。
【００６２】
NORMヘッダ生成部１２３は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【００６３】
ネットワークパケット生成部１２４は、コードストリーム分割部１２２から供給される各分割コードストリームに対して、NORMヘッダ生成部１２３から供給されるNORMヘッダを用いて、ヘッダを生成し、ネットワークパケットを生成する。
【００６４】
ネットワークパケット生成部１２４は、生成したネットワークパケットを出力し（矢印１３７）、例えばコンテンツサーバ１０２に供給して蓄積させる。
【００６５】
［JPEG2000エンコーダの構成］
図３は、図２のJPEG2000エンコーダの主な構成例を示すブロック図である。
【００６６】
JPEG2000エンコーダ１２１は、画像データをウェーブレット変換し、得られた係数を、コードブロック毎にビットプレーンに展開し、ビットプレーン毎にエントロピ符号化する。
【００６７】
JPEG2000エンコーダ１２１は、特にJPEG2000規格で定められたEBCOT(Embedded Coding with Optimized Truncation)と呼ばれるエントロピ符号化を行う（参考文献：ISO/IEC 15444-1, Information technology-JPEG 2000, Part 1:Core coding system）。
【００６８】
このEBCOT（Embedded Block Coding with Optimized Truncation）と呼ばれるエントロピ符号化は、ビットプレーン展開されたバイナリデータを１ピクセル単位にモデリングしながら算術符号化する技術である。
【００６９】
図１に示されるように、JPEG2000エンコーダ１２１は、ウェーブレット変換部１５１、量子化部１５２、コードブロック化部１５３、ビットプレーン展開部１５４、EBCOT１５５、および符号化コードストリーム生成部１５６を有する。
【００７０】
ウェーブレット変換部１５１は、通常、低域フィルタと高域フィルタから構成されるフィルタバンクによって実現される。また、デジタルフィルタは通常複数タップ長のインパルス応答（フィルタ係数）を有するので、ウェーブレット変換部１５１は、フィルタリングが行えるだけの入力画像を予めバッファリングするバッファを有する。
【００７１】
ウェーブレット変換部１５１は、入力された画像データ（矢印１３１）を、フィルタリングに最低限必要なデータ量以上取得する。ウェーブレット変換部１５１は、その画像データに対して、例えば５×３ウェーブレット変換フィルタを用いてフィルタリングを行い、ウェーブレット係数を生成する。なお、ウェーブレット変換部１５１は、画像の垂直方向および水平方向のそれぞれに対して、画像データを低域成分と高域成分に分離するフィルタリングを行う。
【００７２】
そして、ウェーブレット変換部１５１は、このようなフィルタリング処理を、垂直方向および水平方向の両方において低域成分として分離されたサブバンドに対して再帰的に所定回数繰り返す。これは、図４に示されるように、画像のエネルギーの多くが低域成分に集中しているからである。
【００７３】
図４は、サブバンドの構成例を示す図である。図４に示されるように、分割レベル数１の状態においても分割レベル数３の状態においても、画像のエネルギーの多くは、低域成分に集中している。
【００７４】
図５は、分割レベル数４のウェーブレット変換処理により生成されるサブバンドの構成例を示す図である。
【００７５】
この場合、ウェーブレット変換部１５１は、まず、画像全体をフィルタリングし、サブバンド1LL（図示せず）、1HL、1LH、および1HHを生成する。次に、ウェーブレット変換部１５１は、生成されたサブバンド1LLに対して再度フィルタリングを行い、2LL（図示せず）、2HL、2LH、および2HHを生成する。さらに、ウェーブレット変換部１５１は、生成されたサブバンド2LLに対して再度フィルタリングを行い、3LL、3HL、3LH、および3HHを生成する。さらに、ウェーブレット変換部１５１は、生成されたサブバンド3LLに対して再度フィルタリングを行い、4LL、4HL、4LH、および4HHを生成する。
【００７６】
このように、分割レベル数４まで分析フィルタリングが行われると、１３個のサブバンドが生成される。図５に示されるように、分割レベルが１つ上位に進むごとに、サブバンドのサイズは、縦方向および横方向にそれぞれ２分の１となる。
【００７７】
つまり、例えば横方向に１９２０画素の画像のベースバンドの画像データが１回分析フィルタリングされると、横方向に９６０画素のサブバンドが４つ（1LL,1HL,1LH,1HH）生成される。さらに、サブバンド1LLが１回分析フィルタリングされると、横方向に４８０画素のサブバンドが４つ（2LL,2HL,2LH,2HH）が生成される。さらに、サブバンド2LLが１回分析フィルタリングされると、横方向に２４０画素のサブバンドが４つ（3LL,3HL,3LH,3HH）が生成される。さらに、サブバンド3LLが１回分析フィルタリングされると、横方向に１２０画素のサブバンドが４つ（4LL,4HL,4LH,4HH）が生成される。
【００７８】
なお、ウェーブレット変換の分割レベル数は任意である。
【００７９】
図３に戻り、ウェーブレット変換部１５１は、フィルタリングにより得られた係数データ（ウェーブレット係数）を、サブバンド毎に、量子化部１５２に供給する（矢印１７２）。
【００８０】
量子化部１５２は、供給された係数データ（ウェーブレット係数）を量子化する。量子化部１５２は、得られた係数データ（量子化係数）を、コードブロック化部１５３に供給する（矢印１７３）。なお、JPEG2000の規格では、可逆圧縮の場合、量子化処理は省略される。その場合、ウェーブレット変換部１５１より出力された係数データ（ウェーブレット係数）は、コードブロック化部１５３に供給される（矢印１７４）。この場合、量子化部１５２は省略可能である。
【００８１】
コードブロック化部１５３は、供給された各係数データ（量子化された係数データ）を、予め定められた所定の大きさの矩形の、エントロピ符号化の処理単位であるコードブロックに分割する。JPEG2000の規格上の定義によって、コードブロックの縦・横サイズはどのサブバンドにおいても一定である。但し画像（サブバンド）の両端や上端・下端などでは、同じサイズのコードブロックが取れないケースも多々ある。
【００８２】
図６は、各サブバンド中のコードブロックの位置関係の例を示したものである。ここでは分割レベル数３の場合について説明する。例えば64×64画素程度のサイズのコードブロックが、分割後のすべてのサブバンド中に生成される。例えば、最も分割レベルが低い1HHのサブバンドの大きさが例えば640×320画素であるとすると、64×64画素のコードブロックは合計５０個存在することになる。後段の各処理部は、このコードブロック毎に処理を行う。もちろん、このコードブロックのサイズ（画素数）は任意である。
【００８３】
図３に戻り、コードブロック化部１５３は、係数データをコードブロック毎にビットプレーン展開部１５４に供給する（矢印１７５）。
【００８４】
ビットプレーン展開部１５４は、供給されたコードブロック毎の係数データを、ビットの位毎のビットプレーンに展開する。
【００８５】
ビットプレーンは、所定の数のウェーブレット係数よりなる係数群（例えば後述するコードブロック）を、１ビット毎、つまり位毎に分割（スライス）したものである。つまり、ビットプレーンは、それぞれが複数ビットのビット深度を持つ複数のデータの、互いに同一の位のビット（係数ビット）の集合である。したがって、展開されるビットプレーン数は、各係数のビット深度に依存する。
【００８６】
図７にその具体例を示す。図７の左図は縦４個、横４個の計１６個の係数を示している。この１６個の係数のうち、絶対値が最大のものは１３で、２進数で１１０１と表現される。ビットプレーン展開部１５４は、このような係数群を、絶対値を示す４枚のビットプレーン（絶対値のビットプレーン）と、符号を示す１枚のビットプレーン（符号のビットプレーン）に展開する。つまり、図７中左の係数群は、図７中右に示されるように、４枚の絶対値のビットプレーンと１枚の符号のビットプレーンに展開される。ここで、絶対値のビットプレーンの要素はすべて０か１の値をとる。また、符号を示すビットプレーンの要素は、係数の値が正であることを示す値、係数の値が０であることを示す値、または係数の値がマイナスを示す値のいずれかをとる。
【００８７】
なお、このようにビットプレーンとされる係数群における係数の数は任意である。以下においては、処理単位を統一することで各部における処理を容易にするために、ビットプレーン展開部１５４が、係数をコードブロック毎にビットプレーン展開するものとして説明する。
【００８８】
図３に戻り、ビットプレーン展開部１５４は、このように展開したビットプレーンを、係数の最上位ビット（MSB：Most Significant Bit）から最下位ビット（LSB：Less Significant Bit）に向かう順に、EBCOT１５５に供給する。つまり、ビットプレーン展開部１５４は、ビット深度の上位側から下位側に向かう順に、展開したビットプレーンをEBCOT１５５に供給する（矢印１７６）。
【００８９】
EBCOT１５５は、所定の大きさのブロック毎にそのブロック内の係数の統計量を測定しながら符号化を行う。EBCOT１５５は、係数データ（量子化係数）をコードブロック単位に、エントロピ符号化する。各コードブロックは、最上位ビット（MSB）から最下位ビット（LSB）方向にビットプレーン毎に独立して符号化される。コードブロックの縦横のサイズは４から256までの２のべき乗で、通常使用される大きさは、32x32、64x64、または128x32等がある。量子化係数値がｎビットの符号付き２進数で表されていて、bit 0からbit n-1がLSBからMSBまでのそれぞれのビットを表すとする。残りの１ビットは符号である。コードブロックの符号化は、MSB側のビットプレーンから順番に、次の３種類の符号化パスによって行われる。
【００９０】
（１）Significant Propagation Pass
（２）Magnitude Refinement Pass
（３）Cleanup Pass
【００９１】
３つの符号化パスの用いられる順序は、図８で示される。最初にBit-plane（n-1）（MSB）がCleanup Passによって符号化される。続いて順次LSB側に向かい、各ビットプレーンの符号化が、３つの符号化パスをSignificant Propagation Pass、Magnitude Refinement Pass、Cleanup Passの順序で用いて行われる。
【００９２】
ただし、実際にはMSB側から何番目のビットプレーンで初めて１が出てくるかをヘッダに書き、MSB側から連続するオール０のビットプレーン（ゼロビットプレーンと呼ぶ）は符号化しない。この順序で３種類の符号化パスを繰返し用いて符号化し、任意のビットプレーンの、任意の符号化パス迄で符号化を打ち切ることにより、符号量と画質のトレードオフを取る（レート制御を行う）。
【００９３】
次に、係数の走査（スキャニング）について図９を用いて説明する。コードブロックは高さ４個の係数毎にストライプ（stripe）に分けられる。ストライプの幅はコードブロックの幅に等しい。スキャン順とは、１個のコードブロック内の、すべての係数をたどる順番で、コードブロック中では上のストライプから下のストライプへの順序、ストライプの中では、左の列から右の列へ向かっての順序、列の中では上から下へという順序である。各符号化パスにおいてコードブロック中のすべての係数が、このスキャン順で処理される。
【００９４】
以下、３つの符号化パスについて述べる。以下はいずれもJPEG-2000規格書（参考文献：ISO/IEC 15444-1, Information technology-JPEG 2000, Part 1:Core coding system）に記述されている内容である。
【００９５】
（１）Significance Propagation Pass（SPパス）：
あるビットプレーンを符号化するSignificance Propagation Passでは、８近傍の少なくとも１つの係数が有意（significant）であるようなnon-significant係数のビットプレーンの値を算術符号化する。その符号化したビットプレーンの値が１である場合は、符号が＋であるか、−であるかを続けてMQ符号化する。
【００９６】
ここでsignificanceというJPEG2000特有の用語について説明する。significanceとは、各係数に対して符号化器が持つ状態で、significanceの初期値はnon-significantを表す０、その係数で１が符号化されたときにsignificantを表す１に変化し、以降常に１であり続けるものである。従って、significanceとは有効桁の情報を既に符号化したか否かを示すフラグとも言える。あるビットプレーンでsignificantになれば、以降のビットプレーンではsignificantになったままである。
【００９７】
（２）Magnitude Refinement Pass（MRパス）：
ビットプレーンを符号化するMagnitude Refinement Passでは、ビットプレーンを符号化する Significance Propagation Passで、且つ符号化していないsignificantな係数のビットプレーンの値をMQ符号化する。
【００９８】
（３）Cleanup Pass（CUパス）：
ビットプレーンを符号化するCleanup Passでは、ビットプレーンを符号化するSignificance Passで、且つ符号化していないnon-significantな係数のビットプレーンの値をMQ符号化する。その符号化したビットプレーンの値が１である場合は符号が＋であるか−であるか（Sign情報）を続けてMQ符号化する。
【００９９】
尚、以上の３つの符号化パスでのMQ符号化では、ケースに応じて、ZC（Zero Coding）、RLC（Run-Length Coding）、SC（Sign Coding）、およびMR（Magnitude Refinement）が使い分けられる。ここでMQ符号化と呼ばれる算術符号が用いられる。MQ符号化は、JBIG2（参考文献：ISO/IEC FDIS 14492, “Lossy/Lossless Coding of Bi-level Images”, March 2000）で規定された学習型の２値算術符号である。
【０１００】
図３に示されるように、EBCOT１５５は、ビットモデリングを行うビットモデリング部１６１と、算術符号化を行うMQ符号化部１６２とを有する。ビットモデリング部１６１は、ビットモデリングを行うと、制御情報、シンボル、およびコンテキスト等の情報をMQ符号化部１６２に供給する（矢印１７７）。MQ符号化部１６２は、供給されたデータ群を用いてMQ符号化を行う。MQ符号化部１６２は、MQ符号化により生成された符号化データを符号化コードストリーム生成部１５６に供給する（矢印１７８）。
【０１０１】
符号化コードストリーム生成部１５６は、EBCOT１５５（MQ符号化部１６２）から供給された符号化データを整列し、１つの符号化コードストリームとして出力する（矢印１７９）。より具体的には、符号化コードストリーム生成部１５６は、符号化データを並べ替え、JPEG2000の特徴であるResolution（解像度）とLayer（レイヤ）のスケーラブルな構造のパケット群よりなる符号化コードストリームを生成する。図２を参照して説明したように、符号化コードストリーム生成部１５６から出力された符号化コードストリームは、コードストリーム分割部１２２に供給される。
【０１０２】
なお、符号化コードストリーム生成部１５６は、さらに、生成した符号化コードストリームについて、その構造を示すプログレッションオーダ情報をNORMヘッダ生成部１２３に供給する（矢印１８０）。
【０１０３】
［NORMヘッダ生成部の構成例］
次に、図２のNORMヘッダ生成部１２３について説明する。上述したように、JPEG2000エンコーダ１２１において生成された符号化コードストリームは、コードストリーム分割部１２２により分割され、分割された複数の分割コードストリームとして、NORMヘッダ生成部１２３に供給される。また、NORMヘッダ生成部１２３には、JPEG2000エンコーダ１２１からプログレッションオーダ情報が供給される。
【０１０４】
図１０は、図２のNORMヘッダ生成部の主な構成例を示すブロック図である。
【０１０５】
図１０に示されるように、NORMヘッダ生成部１２３は、アドレス抽出部１９１、解像度・レイヤ算出部１９２、アトリビュート番号算出部１９３、およびヘッダ記述部１９４を有する。
【０１０６】
アドレス抽出部１９１は、コードストリーム分割部１２２から供給される（矢印１３４）各分割コードストリームの先頭のアドレス（先頭アドレス）と、末端のアドレス（末端アドレス）とを抽出する。アドレス抽出部１９１は、抽出した各分割コードストリームの先頭アドレスと末端アドレスとを解像度・レイヤ算出部１９２に供給する（矢印２１１）。
【０１０７】
解像度・レイヤ算出部１９２は、JPEG2000エンコーダ１２１から供給されるプログレッションオーダ情報により示される符号化コードストリームの構造に基づいて、プログレッションに関する変数となる画像特徴量である解像度とレイヤとを、アドレス抽出部１９１から供給された先頭アドレスおよび末端アドレスのそれぞれについて算出する。
【０１０８】
［レイヤ］
ここで、レイヤについて説明する。上述したように、画像データは、コードブロック毎にビットプレーンに展開されて符号化される。つまり、コードブロック内の符号化パスはビットプレーンの順に並んでいる。レイヤは、このようにコードブロック毎に符号化されたデータを、１つまたは複数のビットプレーン毎に分割したものである。すなわち、各レイヤは、１つまたは複数のビットプレーンにより形成される。換言すれば、コードブロック毎に符号化されたデータは、コードストリーム中の１個または複数個のレイヤに渡って展開される。
【０１０９】
レイヤ中の符号化パス数は、ブロック毎に設定することができる。符号化パス数を０に設定することもできる。
【０１１０】
画像データは、一般的に、レイヤ数が増える程画質が向上する。換言すれば、分割したレイヤを減らしたり増やしたりすることにより、画像データの画質を調整することができる。
【０１１１】
図１１の例においては、１ピクチャがレイヤ１乃至レイヤＮのＮ個のレイヤに分割され、１つのレイヤが４個のパケットから構成されている。この１レイヤ当たりのパケット数は（ウェーブレット分解レベル数＋１）で定義される。
【０１１２】
以上のように、符号化コードストリームは、レイヤ（画質）について、スケーラブルに符号化されている。また、図５を参照して説明したように、画像データは、複数のサブバンドに分割され、そのサブバンド毎に符号化される。したがって、符号化コードストリームは、解像度についても、スケーラブルに符号化されている。つまり、JPEG2000方式で符号化された符号化コードストリームにおいては、解像度およびレイヤについてスケーラブルになるように、符号化データが所定の単位毎にパケット化されて並べられている。
【０１１３】
このような符号化データ（パケット）の並びをプログレッションと称する。JPEG2000方式の場合、符号化データは、解像度とレイヤについて並べられている。したがって、この場合の解像度とレイヤ（画像特徴量）を、プログレッションに関する変数と称する。
【０１１４】
JPEG2000方式においては、このような符号化データの並べ方は、２通り存在する。
【０１１５】
［タイプ］
第１の並べ方は、各レイヤの符号化データを解像度毎に並べる方法である。このような並べ方が採用された符号化コードストリームのタイプをL-Rタイプ（Layer-Resolution Type）と称する。図１２は、そのL-Rタイプの符号化コードストリームの構成例を説明する図である。
【０１１６】
図１２に示されるように、符号化コードストリーム２３１は、SOC（Start of Codestream）、メインヘッダ（Main header）、およびタイルパートヘッダ（Tile-part header）に続いて、各レイヤの符号化データが解像度順に並べられている。なお、図１２においてＬおよびＲは、それぞれ任意の自然数である。
【０１１７】
つまり、このL-Rタイプでは、最初の上位階層にレイヤ（Layer）があり、次の階層に解像度（Resolution）が存在する。従ってこのコードストリームを先頭から順番にデコードすると図１３の様な画像を復元することができる。
【０１１８】
より具体的に説明すると、Layer-1はResolution番号１からＲまでのすべての解像度のパケットを包含しており、このLayer-1をデコードすることで、原画像と同じ解像度の画像の最初のレイヤだけを復元することが出来る。同様にLayer-2をデコードしてLayer−1のデコード済みの画像に合わせることで、画質が向上する。これを最後のLayer-Lまで繰り返して行うことで最終的な復号画像を出力することになる。
【０１１９】
つまり、このように復元するレイヤを向上させることにより、画像は、解像度が一定のまま画質が向上する。広義において「画質」は様々な事象を示すが、ここでは、復元するレイヤに依存するものを「画質」と称する。
【０１２０】
画像の「解像度」および「画質」は、画像の特徴量である。符号化コードストリームにおける「解像度」および「レイヤ」は、これらの特徴量に対応する変数である。したがって、以下においては、この符号化コードストリームにおける「解像度」および「レイヤ」を、それぞれ、画像の「解像度」および「画質」と等価とみなし、「画像の特徴量」と称する場合もある。
【０１２１】
第２の並べ方は、各解像度の符号化データをレイヤ毎に並べる方法である。このような並べ方が採用された符号化コードストリームのタイプをR-Lタイプ（Resolution-Layer Type）と称する。図１４は、そのR-Lタイプの符号化コードストリームの構成例を説明する図である。
【０１２２】
図１４に示されるように、符号化コードストリーム２４１は、SOC（Start of Codestream）、メインヘッダ（Main header）、およびタイルパートヘッダ（Tile-part header）に続いて、各解像度の符号化データがレイヤ順に並べられている。なお、図１４においてＬおよびＲは、それぞれ任意の自然数である。
【０１２３】
つまり、このR-Lタイプでは、最初の上位階層に解像度（Resolution）があり、次の階層にレイヤ（Layer）が存在する。従ってこのコードストリームを先頭から順番にデコードすると図１５の様な画像を復元することができる（３分解のウェーブレット分解のケースでＲ＝４の場合）。
【０１２４】
Res-1はLayer番号１からLまでのすべてのレイヤのパケットを包含しており、このRes-1をデコードすることで、最高画質の画像の最小の解像度だけを復元することが出来る。同様にRes-2をデコードしてRes−1のデコード済みの画像に合わせることで、解像度が水平・垂直共に２倍だけ向上する。これを最後のRes-Rまで繰り返して行うことで最終的な復号画像を出力することになる。
【０１２５】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報から、符号化コードストリームのタイプを特定する。タイプを特定すると符号化ストリームにおける解像度やレイヤの構造が分かるので、解像度・レイヤ算出部１９２は、先頭アドレスおよび末端アドレスのそれぞれに対応する解像度やレイヤを求めることができる。
【０１２６】
［L-Rタイプ］
まず、符号化コードストリームがL-Rタイプの場合について説明する。図１６は、L-Rタイプのネットワークパケット生成の様子の例を説明する図である。
【０１２７】
コードストリーム分割部１２２において、L-Rタイプの符号化コードストリーム２３１が分割され、分割コードストリーム２５１および分割コードストリーム２５２が生成されるとする。
【０１２８】
分割コードストリーム２５１は、１番目のネットワークパケット（Network Packet 1）のBody（本体データ部）となる。分割コードストリーム２５２は、２番目のネットワークパケット（Network Packet 2）のBody（本体データ部）となる。
【０１２９】
もちろん３番目以降のネットワークパケットも生成されるが、ここでは説明の便宜上、省略する。
【０１３０】
NORMヘッダ生成部１２３のアドレス抽出部１９１は、分割コードストリーム２５１の先頭アドレス（Start-1）と末端アドレス（End-1）を求める。また、アドレス抽出部１９１は、分割コードストリーム２５２の先頭アドレス（Start-2）と末端アドレス（End-2）も求める。
【０１３１】
この時、分割コードストリーム２５１の先頭アドレス（Start-1）は、元の符号化コードストリーム２３１のSOCマーカの先頭アドレスに等しく、末端アドレス（End-1）は、（レイヤ１、解像度１）（Layer-1，Res-1）のパケットの途中のアドレスに等しい。
【０１３２】
同様に、分割コードストリーム２５２の先頭アドレス（Start-2）は、分割コードストリーム２５１の末端アドレス（End-1）の直後のアドレスに等しく、末端アドレス（End-2）は、（レイヤ１、解像度Ｒ）（Layer-1，Res-R）の途中のアドレスに等しい。
【０１３３】
プログレッションオーダ情報には、図１６の最上段に示されるような符号化コードストリームの構造（どのアドレスからどのアドレスまでがどのようなヘッダやパケットにより構成されるか）が示されている。
【０１３４】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報によって、符号化コードストリームがL-Rタイプであることを確認すると、その構造に基づいて、上述したように各分割コードストリームの先頭アドレスと末端アドレスに対応するレイヤ番号（Layer番号）および解像度番号（Resolution番号）を求める。
【０１３５】
解像度・レイヤ算出部１９２は、
（R_f,R_t）＝（Resolution番号の先頭値、Resolution番号の末端値）
（L_f,L_t）＝（Layer番号の先頭値、Layer番号の末端値）
と定義し、各分割コードストリーム（各ネットワークパケット）について、これらの変数の値を求める。
【０１３６】
例えば、図１６の例において、分割コードストリーム２５１（Network Packet 1）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（０，１）
（L_f,L_t）＝（０，１）
【０１３７】
また、分割コードストリーム２５２（Network Packet 2）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（１，Ｒ）
（L_f,L_t）＝（１，１）
【０１３８】
なお、図１６に示される各ネットワークパケットのヘッダ（HDR）は、UDPヘッダとNORMヘッダを合わせたものである。UDPはTCPと異なり送達確認などを行わないため、データ比率が高まる。従って途中で一部のデータが欠損（Loss）しても問題が少ない画像のストリーミング等に多用されている。
【０１３９】
図１０に戻り、解像度・レイヤ算出部１９２は、上述した変数（R_f,R_t）および（L_f,L_t）の値を算出すると、それらをアトリビュート番号算出部１９３に供給する（矢印２１２）。アトリビュート番号算出部１９３は、変数（R_f,R_t）および（L_f,L_t）の値を用いて、各分割コードストリーム（各ネットワークパケット）の先頭と末端について、その画像特徴量（解像度やレイヤ）を他と識別するための識別番号であるアトリビュート番号を算出する。
【０１４０】
図１０に示されるように、アトリビュート番号算出部１９３は、タイプ判定部２０１、L-R用算出部２０２、およびR-L用算出部２０３を有する。
【０１４１】
タイプ判定部２０１は、解像度・レイヤ算出部１９２から供給されるプログレッションオーダ情報に基づいて、符号化コードストリームのタイプを判定する。タイプ判定部２０１は、符号化コードストリームのタイプがL-Rタイプである場合、解像度・レイヤ算出部１９２から供給される、各分割コードストリームの変数（R_f,R_t）および（L_f,L_t）の値をL-R用算出部２０２に供給する（矢印２２１）。
【０１４２】
L-R用算出部２０２は、以下の式（１）に示されるようなL-R用の算出式を用いて、各分割コードストリームについて、変数（R_f,R_t）および（L_f,L_t）の値から、先頭と末端のアトリビュート番号（Attribute Number）（先頭値と末端値）を求める。
【０１４３】
Attribute Number＝（Layer-number）×（Resolution level数）
＋（Resolution-number＋１） ・・・（１）
【０１４４】
なお、Layer-numberは、レイヤ番号を示し、Resolution level数は、解像度番号の最大値（ウェーブレット変換の分割レベル数）を示し、Resolution-numberは、解像度番号を示す。
【０１４５】
例えば、図１６の例において、Resolution level数Ｒ＝４とすると、分割コードストリーム２５１のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１４６】
先頭値＝L_f×（Res-R）＋R_f＋１＝０×４＋０＋１＝１
末端値＝L_t×（Res-R）＋R_t＋１＝１×４＋１＋１＝６
【０１４７】
また、分割コードストリーム２５２のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１４８】
先頭値＝L_f×（Res-R）＋R_f＋１＝１×４＋１＋１＝６
末端値＝L_t×（Res-R）＋R_t＋１＝１×４＋４＋１＝９
【０１４９】
L-R用算出部２０２は、以上のように、変数（R_f,R_t）および（L_f,L_t）の値が供給される全ての分割コードストリームについて、アトリビュート番号の先頭値と末端値を求める。L-R用算出部２０２は、求めたアトリビュート番号の先頭値および末端値をヘッダ記述部１９４に供給する（矢印２１３）。
【０１５０】
ヘッダ記述部１９４は、L-R用算出部２０２から供給されたアトリビュート番号の先頭値および末端値の分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダの拡張パラメータ領域に、そのアトリビュート番号の先頭値および末端値を記述する。
【０１５１】
［NORMヘッダの構成］
図１７は、NORMヘッダの構成例を説明する図である。
【０１５２】
ヘッダ記述部１９４は、図１７に示されるような構成のNORMヘッダ２６１を生成し、その拡張パラメータ領域（reserved）に、Ｘ、Attribyute type、FROM、およびTO等の値を記述する。
【０１５３】
これらの変数の内容については、図１７の表２６２に示される。Ｘは、NORMヘッダ２６１にアトリビュート番号が記述されているか否かを示すアトリビュート拡張フラグ（Attribute extension flag）である。アトリビュート拡張フラグのデータ長は任意であるが、例えば１ビットであってもよい。また、アトリビュート拡張フラグの値は任意であるが、例えば、NORMヘッダ２６１にアトリビュート番号の値が記述される場合のアトリビュート拡張フラグＸの値を「１」とし、アトリビュート番号の値が記述されない場合のアトリビュート拡張フラグＸの値を「０」としてもよい。
【０１５４】
アトリビュートタイプ（Attribyute type）は、上述した符号化コードストリームのタイプを示す。アトリビュートタイプのデータ長は任意であるが、例えば８ビットであってもよい。また、アトリビュートタイプの値は任意であるが、例えば、符号化コードストリームがL-Rタイプの場合のアトリビュートタイプの値を「０」とし、符号化コードストリームがR-Lタイプの場合のアトリビュートタイプの値を「１」としてもよい。さらに、L-RタイプおよびR-Lタイプ以外のタイプが存在する場合、他の値を割り当てることもできる。
【０１５５】
FROMは、アトリビュート番号の先頭値を示す。TOは、アトリビュート番号の末端値を示す。これらの値のデータ長は任意であるが、例えば８ビットであってもよい。
【０１５６】
例えば、ヘッダ記述部１９４は、L-R用算出部２０２からアトリビュート番号の先頭値および末端値を供給されると、NORMヘッダを生成し、アトリビュート拡張フラグＸに値「１」をセットし、アトリビュートタイプの値を「０」にセットする。さらに、ヘッダ記述部１９４は、L-R用算出部２０２から供給されたアトリビュート番号の先頭値をFROMに記述し、L-R用算出部２０２から供給されたアトリビュート番号の末端値をTOに記述する。
【０１５７】
図１０に戻り、ヘッダ記述部１９４は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【０１５８】
符号化コードストリームがL-Rタイプの場合、以上のように処理が行われる。
【０１５９】
［R-Lタイプ］
次に、符号化コードストリームがR-Lタイプの場合について説明する。図１８は、R-Lタイプのネットワークパケット生成の様子の例を説明する図である。
【０１６０】
コードストリーム分割部１２２において、R-Lタイプの符号化コードストリーム２４１が分割され、分割コードストリーム２７１および分割コードストリーム２７２が生成されるとする。
【０１６１】
分割コードストリーム２７１は、１番目のネットワークパケット（Network Packet 1）のBody（本体データ部）となる。分割コードストリーム２７２は、２番目のネットワークパケット（Network Packet 2）のBody（本体データ部）となる。
【０１６２】
もちろん３番目以降のネットワークパケットも生成されるが、ここでは説明の便宜上、省略する。
【０１６３】
NORMヘッダ生成部１２３のアドレス抽出部１９１は、分割コードストリーム２７１の先頭アドレス（Start-1）と末端アドレス（End-1）を求める。また、アドレス抽出部１９１は、分割コードストリーム２７２の先頭アドレス（Start-2）と末端アドレス（End-2）も求める。
【０１６４】
この時、分割コードストリーム２７１の先頭アドレス（Start-1）は、元の符号化コードストリーム２４１のSOCマーカの先頭アドレスに等しく、末端アドレス（End-1）は、（レイヤ１、解像度１）（Layer-1，Res-1）のパケットの途中のアドレスに等しい。
【０１６５】
同様に、分割コードストリーム２７２の先頭アドレス（Start-2）は、分割コードストリーム２７１の末端アドレス（End-1）の直後のアドレスに等しく、末端アドレス（End-2）は、（レイヤＬ、解像度１）（Layer-L，Res-1）の途中のアドレスに等しい。
【０１６６】
解像度・レイヤ算出部１９２は、プログレッションオーダ情報によって、符号化コードストリームがR-Lタイプであることを確認すると、その構造に基づいて、上述したように各分割コードストリーム（各ネットワークパケット）について、変数（R_f,R_t），（L_f,L_t）の値を求める。
【０１６７】
例えば、図１８の例において、分割コードストリーム２７１（Network Packet 1）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（０，１）
（L_f,L_t）＝（０，１）
【０１６８】
また、分割コードストリーム２７２（Network Packet 2）の場合、上述した変数（R_f,R_t），（L_f,L_t）の値は以下のようになる。
（R_f,R_t）＝（１，１）
（L_f,L_t）＝（１，Ｌ）
【０１６９】
図１０に戻り、解像度・レイヤ算出部１９２は、上述した変数（R_f,R_t）および（L_f,L_t）の値を算出すると、それらをアトリビュート番号算出部１９３に供給する（矢印２１２）。アトリビュート番号算出部１９３は、各分割コードストリーム（各ネットワークパケット）の先頭と末端について、アトリビュート番号を算出する。
【０１７０】
タイプ判定部２０１は、符号化コードストリームのタイプがR-Lタイプである場合、解像度・レイヤ算出部１９２から供給される、各分割コードストリームの変数（R_f,R_t）および（L_f,L_t）の値をR-L用算出部２０３に供給する（矢印２２２）。
【０１７１】
R-L用算出部２０３は、以下の式（２）に示されるようなR-L用の算出式を用いて、各分割コードストリームについて、変数（R_f,R_t）および（L_f,L_t）の値から、先頭と末端のアトリビュート番号（Attribute Number）（先頭値と末端値）を求める。
【０１７２】
Attribute Number＝（Resolution-number）×（全Layer数）
＋（Layer-number＋１） ・・・（２）
【０１７３】
なお、全Layer数は、レイヤの総数を示す。
【０１７４】
例えば、図１８の例において、全Layer数Ｌ＝５とすると、分割コードストリーム２５１のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１７５】
先頭値＝R_f×（L）＋L_f＋１＝０×５＋０＋１＝１
末端値＝R_t×（L）＋L_t＋１＝１×５＋１＋１＝７
【０１７６】
また、分割コードストリーム２７２のアトリビュート番号の先頭値および末端値は、それぞれ以下のようになる。
【０１７７】
先頭値＝R_f×（L）＋L_f＋１＝１×５＋１＋１＝７
末端値＝R_t×（L）＋L_t＋１＝１×５＋５＋１＝１１
【０１７８】
R-L用算出部２０３は、以上のように、変数（R_f,R_t）および（L_f,L_t）の値が供給される全ての分割コードストリームについて、アトリビュート番号の先頭値と末端値を求める。R-L用算出部２０３は、求めたアトリビュート番号の先頭値および末端値をヘッダ記述部１９４に供給する（矢印２１３）。
【０１７９】
ヘッダ記述部１９４は、R-L用算出部２０３から供給されたアトリビュート番号の先頭値および末端値の分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダの拡張パラメータ領域に、そのアトリビュート番号の先頭値および末端値を記述する。
【０１８０】
この方法は、基本的に、上述したL-Rタイプの場合と同様である。例えば、ヘッダ記述部１９４は、R-L用算出部２０３からアトリビュート番号の先頭値および末端値を供給されると、NORMヘッダを生成し、アトリビュート拡張フラグＸに値「１」をセットし、アトリビュートタイプの値を「１」にセットする。さらに、ヘッダ記述部１９４は、R-L用算出部２０３から供給されたアトリビュート番号の先頭値をFROMに記述し、R-L用算出部２０３から供給されたアトリビュート番号の末端値をTOに記述する。
【０１８１】
図１０に戻り、ヘッダ記述部１９４は、生成したNORMヘッダをネットワークパケット生成部１２４に供給する（矢印１３６）。
【０１８２】
［処理の流れ］
以上のような各処理の流れの例を説明する。最初に、図１９のフローチャートを参照して、配信用データ生成装置１０１により実行される配信データ生成処理の流れの例を説明する。
【０１８３】
例えば、ユーザから処理実行を指示されたり、外部から画像データが供給されたり、画像データが生成されたりすると、配信用データ生成装置１０１は、配信データ生成処理を開始し、その画像データ（コンテンツデータ）から配信用のデータを生成する。
【０１８４】
配信データ生成処理が開始されると、JPEG2000エンコーダ１２１は、ステップＳ１０１において、配信用データを作成する画像データをJPEG2000方式で符号化する。
【０１８５】
ステップＳ１０２において、コードストリーム分割部１２２は、符号化されて得られた符号化コードストリームを所定のデータ長毎に分割し、分割コードストリームを生成する。
【０１８６】
ステップＳ１０３において、NORMヘッダ生成部１２３は、各分割コードストリームについてNORMヘッダを生成し、その拡張パラメータ領域にアトリビュート番号の先頭値および末端値を記述する。
【０１８７】
ステップＳ１０４において、ネットワークパケット生成部１２４は、生成されたNORMヘッダを用いて、各分割コードストリームをパケット化し、ネットワークパケットを生成する。ステップＳ１０５において、ネットワークパケット生成部１２４は、生成したネットワークパケットを出力する。
【０１８８】
配信用データ生成装置１０１から出力されたネットワークパケットはコンテンツサーバ１０２に供給され、格納される。
【０１８９】
次に、図１９のステップＳ１０１において実行される符号化処理の詳細な流れの例について、図２０のフローチャートを参照して説明する。
【０１９０】
符号化処理が開始されると、ウェーブレット変換部１５１は、ステップＳ１２１において、１ピクチャ分の画像データをウェーブレット変換する。ステップＳ１２２において、量子化部１５２は、ステップＳ１２１において生成された係数データを量子化する。なお、可逆符号化の場合、このステップＳ１２２の処理は省略される。
【０１９１】
ステップＳ１２３において、コードブロック化部１５３は、係数データをコードブロック化する。ステップＳ１２４において、ビットプレーン展開部１５４は、各コードブロックの係数データをビットプレーン展開する。
【０１９２】
ステップＳ１２５において、EBCOT１５５のビットモデリング部１６１は、ビットモデリング処理を実行する。ステップＳ１２６において、EBCOT１５５のMQ符号化部１６２は、MQ符号化処理を行う。
【０１９３】
ステップＳ１２７において、符号化コードストリーム生成部１５６は、EBCOT１５５において生成された符号化データを整列して符号化コードストリームを生成する。また、ステップＳ１２８において、符号化コードストリーム生成部１５６は、生成した符号化コードストリームについてプログレッションオーダ情報を生成する。
【０１９４】
ステップＳ１２９において、符号化コードストリーム生成部１５６は、符号化コードストリームを出力する。また、ステップＳ１３０において、符号化コードストリーム生成部１５６は、プログレッションオーダ情報を出力する。
【０１９５】
ステップＳ１３０の処理が終了すると、符号化処理が終了され、図１９のステップＳ１０１に戻り、ステップＳ１０２以降の処理が実行される。
【０１９６】
次に、図１９のステップＳ１０３において実行されるNORMヘッダ生成処理の詳細な流れの例について、図２１のフローチャートを参照して説明する。
【０１９７】
NORMヘッダ生成処理が開始されると、ステップＳ１５１において、アドレス抽出部１９１は、各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する。
【０１９８】
ステップＳ１５２において、解像度・レイヤ算出部１９２は、プログレッションオーダ情報に基づいて、先頭アドレスおよび末端アドレスから、各分割コードストリームの先頭および末端の解像度およびレイヤ（画像特徴量）を求める。
【０１９９】
ステップＳ１５３において、アトリビュート番号算出部１９３は、各分割コードストリームの先頭および末端の解像度およびレイヤから、各分割コードストリームのアトリビュート番号の先頭値および末端値を求める。
【０２００】
ステップＳ１５４において、ヘッダ記述部１９４は、各分割コードストリームについて、NORMヘッダを生成し、そのNORMヘッダにアトリビュート番号の先頭値および末端値を記述する。
【０２０１】
ステップＳ１５４の処理が終了すると、図１９のステップＳ１０３に戻り、ステップＳ１０４以降の処理が実行される。
【０２０２】
次に、図２２のフローチャートを参照して、図２１のステップＳ１５３において実行されるアトリビュート番号算出処理の詳細な流れの例について説明する。
【０２０３】
アトリビュート番号算出処理が開始されると、ステップＳ１７１において、タイプ判定部２０１は、プログレッションオーダ情報から符号化コードストリームのタイプを判定する。
【０２０４】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部２０１は、ステップＳ１７２において処理をステップＳ１７３に進める。ステップＳ１７３において、L-R用算出部２０２は、L-R用算出式（例えば式（１））を用いて、解像度番号およびレイヤ番号からアトリビュート番号を求める。
【０２０５】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部２０１は、ステップＳ１７２において処理をステップＳ１７４に進める。ステップＳ１７４において、R-L用算出部２０３は、R-L用算出式（例えば式（２））を用いて、解像度番号およびレイヤ番号からアトリビュート番号を求める。
【０２０６】
アトリビュート番号が求められると、アトリビュート番号算出処理が終了され、図２１のステップＳ１５３に戻り、ステップＳ１５４以降の処理が実行される。
【０２０７】
以上のように、NORMヘッダ生成部１２３が、NORMヘッダの拡張パラメータ領域に、ネットワークパケット（分割コードストリーム）の先頭と末端のそれぞれについて、解像度とレイヤ（画像特徴量）を示す情報として、アトリビュート番号等を記述する。詳細については後述するが、このネットワークパケットを処理（配信）する配信サーバ１０３は、このNORMヘッダの情報に基づいて、取捨選択するだけで所望の画像特徴量に応じて必要なデータをより容易に得ることができる。
【０２０８】
つまり、配信用データ生成装置１０１は、アトリビュート番号に関する情報（例えば解像度やレイヤ等の画像特徴量に関する情報）をネットワークパケットに付加することにより、配信サーバ１０３が所望の画像特徴量（解像度や画質等）に応じて必要なデータをより容易に得ることができるネットワークパケットを生成することができる。
【０２０９】
なお、このアトリビュート番号に関する情報（画像特徴量に関する情報）は、上述した拡張パラメータ領域以外の任意の位置（NORMヘッダ以外も含む）に付加する（記述する）ことができる。
【０２１０】
ただし、アトリビュート番号等を付加する領域として、既存のNORMヘッダの、従来使用されていない拡張パラメータ領域を利用することにより、不要なデータ量の増大を抑制することができる。また、従来の規格に準拠したまま、アトリビュート番号等を付加することができる。つまり、このアトリビュート番号に関する情報を処理することが出来ない従来の装置であっても、ネットワークパケットのそれ以外の部分については、従来どおり処理することができる。
【０２１１】
また、解像度・レイヤ算出部１９２は、プログレッションオーダ情報に基づいて、符号化コードストリームの構造を把握するので、符号化コードストリームのタイプに依らず、解像度番号とレイヤ番号を正しく求めることができる。
【０２１２】
さらに、アトリビュート番号算出部１９３は、符号化コードストリームのタイプを判定し、タイプに応じた算出式を用いてアトリビュート番号を求めるので、符号化コードストリームのタイプに依らず、アトリビュート番号を正しく求めることができる。
【０２１３】
さらに、ヘッダ記述部１９４が、符号化コードストリームのタイプを示すアトリビュートタイプをNORMヘッダに記述するので、後述するように、このネットワークパケットを処理（配信）する配信サーバ１０３は、このNORMヘッダの情報に基づいて、容易に、符号化コードストリームのタイプを把握することができる。つまり、配信サーバ１０３は、符号化コードストリームのタイプに依らず、容易に適切な処理を行うことができる。
【０２１４】
なお、以上においては、NORMヘッダ生成部１２３がアトリビュート番号をNORMヘッダに記述するように説明したが、アトリビュート番号の代わりに、画像特徴量（例えば解像度番号とレイヤ番号）を記述するようにしてもよい。ただし、アトリビュート番号は１つの値であり、解像度番号とレイヤ番号よりもデータ量が少ない。つまり、NORMヘッダにアトリビュート番号を記述する場合の方が、解像度番号とレイヤ番号の両方を記述する場合よりも、ネットワークパケットのデータ量を低減させることができる。
【０２１５】
また、符号化コードストリームのタイプとして、上述したL-RタイプおよびR-Lタイプ以外のタイプを設けるようにしてもよい。例えば、プログレッションに関する変数として、解像度とレイヤ以外の画像特徴量を適用するようにしてもよい。さらに、適用されるタイプの数は任意であり、例えば３つ以上であってもよいし、１つであってもよい。
【０２１６】
どのようなタイプが設定されるとしても、プログレッションオーダ情報には、適用される全てのタイプについて、符号化コードストリームの構造が示されている。したがって、解像度・レイヤ算出部１９２は、適用される全てのタイプの符号化コードストリームの構造を、プログレッションオーダ情報を参照することにより把握することができる。なお、解像度およびレイヤ以外の画像特徴量をプログレッションに関する変数として適用する場合、解像度・レイヤ算出部１９２は、解像度番号やレイヤ番号の場合と同様に、その画像特徴量の識別番号を求める。
【０２１７】
また、アトリビュート番号算出部１９３は、適用される全てのタイプについて、各タイプ専用の算出式を用いてアトリビュート番号を算出する算出部を有している。タイプ判定部２０１は、判定したタイプの算出部に、各分割コードストリームの解像度番号およびレイヤ番号等の情報を供給する。
【０２１８】
さらに、ヘッダ記述部１９４が記述するアトリビュートタイプは、適用される全てのタイプについて、互いに異なる値が予め用意されている。
【０２１９】
［配信サーバの構成例］
次に、以上のように生成されたネットワークパケットを利用する装置について説明する。上述したように、配信サーバ１０３は、コンテンツサーバ１０２からネットワークパケットを取得し、それを端末装置１０４や端末装置１０５に配信する。
【０２２０】
このとき、配信サーバ１０３は、各ネットワークパケットのNORMヘッダに含まれるアトリビュート番号に基づいて、所望の画像特徴量に応じて必要なデータのネットワークパケットのみを選択し、配信する。
【０２２１】
図２３は、図１の配信サーバ１０３の主な構成例を示すブロック図である。
【０２２２】
図２３に示されるように、配信サーバ１０３は、選択対象解像度・レイヤ決定部３０１、プログレッションオーダ情報取得部３０２、ネットワークパケット取得部３０３、解像度・レイヤ算出部３０４、ネットワークパケット選択部３０５、および、ネットワークパケット送信部３０６を有する。
【０２２３】
選択対象解像度・レイヤ決定部３０１は、各種情報に基づいて、配信する画像の（選択対象とする）解像度およびレイヤ（画像特徴量）を決定する。
【０２２４】
例えば、選択対象解像度・レイヤ決定部３０１が配信する画像が、配信先となる端末装置１０４の性能や状況に対して不要に高解像度・高画質な場合、データ伝送や画像表示において不具合が発生する恐れがある。逆に、選択対象解像度・レイヤ決定部３０１が配信する画像が、配信先となる端末装置１０４の性能に対して不要に低解像度・低画質な場合、端末装置の性能を十分に生かした画像表示を行うことができない（不要に低解像度・低画質な画像表示しか行うことができない）。
【０２２５】
同様に、ネットワークパケットの伝送路となるネットワークの使用可能な帯域幅に対して、データ伝送量が多すぎても少なすぎても好ましくない。また、配信サーバ１０３自身の能力や状況に対しても、データ伝送量は適切であることが望ましい。さらに、コンテンツの配信に対して課金処理を行う場合、配信を要求する端末装置による代金の支払額に応じて、配信する画像の解像度や画質（レイヤ）を制御することも考えられる。
【０２２６】
このように、選択対象解像度・レイヤ決定部３０１は、例えば、受信処理能力、画像処理能力、バッファ容量、若しくはモニタの解像度等の、配信先の装置の性能や状態、ネットワークパケットの伝送路となるネットワークの使用可能帯域幅、配信サーバ１０３自身の性能や状態、配信に対する代金支払額、若しくはユーザの指示等、任意の条件に基づいて選択対象とする解像度およびレイヤ（画像特徴量）を決定する。
【０２２７】
選択対象解像度・レイヤ決定部３０１は、決定した解像度やレイヤの情報を、ネットワークパケット選択部３０５に通知する（矢印３３１）。
【０２２８】
プログレッションオーダ情報取得部３０２は、コンテンツサーバ１０２から取得するネットワークパケットに対応する符号化コードストリームのプログレッションオーダ情報を取得する。プログレッションオーダ情報取得部３０２は、取得したプログレッションオーダ情報を解像度・レイヤ算出部３０４に供給する（矢印３３２）。
【０２２９】
ネットワークパケット取得部３０３は、配信するコンテンツのネットワークパケットをコンテンツサーバ１０２から取得し、それを解像度・レイヤ算出部３０４に供給する（矢印３３３）。
【０２３０】
解像度・レイヤ算出部３０４は、ネットワークパケット取得部３０３から供給された各ネットワークパケットのNORMヘッダを参照し、アトリビュート番号の先頭値および末端値から、各ネットワークパケットの先頭および末端の解像度番号およびレイヤ番号（画像特徴量）を求める。
【０２３１】
解像度・レイヤ算出部３０４は、タイプ判定部３１１、L-R用算出部３１２、およびR-L用算出部３１３を有する。
【０２３２】
タイプ判定部３１１は、プログレッションオーダ情報取得部３０２から供給されたプログレッションオーダ情報（矢印３３２）に基づいて、ネットワークパケット取得部３０３から供給されるネットワークパケット（矢印３３３）に対応する符号化コードストリームのタイプを判定する。
【０２３３】
タイプ判定部３１１は、符号化コードストリームのタイプがL-Rタイプである場合、ネットワークパケット取得部３０３から供給される各ネットワークパケットをL-R用算出部３１２に供給する（矢印３４１）。
【０２３４】
L-R用算出部３１２は、上述した式（１）に示されるようなL-R用の算出式を用いて、各分割コードストリームについて、アトリビュート番号の先頭値と末端値から、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）をそれぞれ求める。
【０２３５】
なお、１つの値から２つの変数（R_fとL_f、若しくは、R_tとL_t）の値を求めることになるが、これらの変数はいずれも自然数であり、かつ、解像度番号（R_fおよびR_t）は、Resolution level数Ｒ（Res-R）以下である。したがって、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）はアトリビュート番号の先頭値と末端値によって一意に定まる。
【０２３６】
より具体的に説明すると、例えば分割コードストリームの末端の場合、L-R用算出部３１２は、アトリビュート番号の値から１を減算した値をResolution level数Ｒ（Res-R）で除算し、その商をレイヤ番号L_tとし、その余を解像度番号R_tとする。ただし、余は０以外の値でなければならない。つまりこの場合、L-R用算出部３１２は、商から１を減算した値をレイヤ番号L_tとし、その場合の余を解像度番号R_tとする。つまりこの場合、解像度番号R_tの値はＲとなる。
【０２３７】
なお、先頭については、１番目のネットワークパケット（Network Packet 1）の解像度番号R_fとレイヤ番号L_fはともに０である。２番目以降のネットワークパケットの場合、その先頭の解像度番号R_fとレイヤ番号L_fは、上述した末端の解像度番号R_tとレイヤ番号L_tの場合と同様に求めることができる。
【０２３８】
L-R用算出部３１２は、算出した解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）を、そのネットワークパケットとともにネットワークパケット選択部３０５に供給する（矢印３３４）
【０２３９】
また、タイプ判定部３１１は、符号化コードストリームのタイプがR-Lタイプである場合、ネットワークパケット取得部３０３から供給される各ネットワークパケットをR-L用算出部３１３に供給する（矢印３４２）。
【０２４０】
R-L用算出部３１３は、上述した式（２）に示されるようなR-L用の算出式を用いて、各分割コードストリームについて、アトリビュート番号の先頭値と末端値から、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）をそれぞれ求める。
【０２４１】
この場合も、L-Rタイプの場合と同様に、解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）は、アトリビュート番号の先頭値と末端値によって一意に定まる。
【０２４２】
より具体的に説明すると、例えば分割コードストリームの末端の場合、R-L用算出部３１３は、アトリビュート番号の値から１を減算した値を全Layer数Ｌで除算し、その商を解像度番号R_tとし、その余をレイヤ番号L_tとする。ただし、余は０以外の値でなければならない。つまりこの場合、R-L用算出部３１３は、商から１を減算した値を解像度番号R_tとし、その場合の余をレイヤ番号L_tとする。つまりこの場合、レイヤ番号L_tの値はＬとなる。
【０２４３】
なお、先頭については、１番目のネットワークパケット（Network Packet 1）の解像度番号R_fとレイヤ番号L_fはともに０である。２番目以降のネットワークパケットの場合、その先頭の解像度番号R_fとレイヤ番号L_fは、上述した末端の解像度番号R_tとレイヤ番号L_tの場合と同様に求めることができる。
【０２４４】
R-L用算出部３１３は、算出した解像度番号の先頭値と末端値（R_f,R_t）、並びに、レイヤ番号の先頭値と末端値（L_f,L_t）を、そのネットワークパケットとともに、ネットワークパケット選択部３０５に供給する（矢印３３４）
【０２４５】
ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１から供給された解像度およびレイヤ（画像特徴量）の指定に基づいてネットワークパケットの取捨選択を行い、指定された解像度およびレイヤの画像を得るのに必要なネットワークパケットを選択する。
【０２４６】
選択対象解像度・レイヤ決定部３０１によって指定された解像度の画像を得るためには、その解像度より低い解像度番号の符号化データ（パケット）が全て必要である。同様に、選択対象解像度・レイヤ決定部３０１によって指定されたレイヤ（画質）の画像を得るためには、そのレイヤより低いレイヤ番号の符号化データ（パケット）が全て必要である。
【０２４７】
つまり、選択対象解像度・レイヤ決定部３０１によって指定された解像度およびレイヤ（画質）の画像を得るためには、指定された解像度より低い解像度番号の符号化データ（パケット）と、指定されたレイヤより低いレイヤ番号の符号化データ（パケット）とが全て必要である。
【０２４８】
したがって、ネットワークパケット選択部３０５は、これらの符号化データ（パケット）を含むネットワークパケットを全て選択する。つまり、ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１によって指定された解像度およびレイヤの画像に対応する画像データ（符号化データ）を含むネットワークパケットを選択する。
【０２４９】
図１６および図１８に示されるように、符号化コードストリームにおいて符号化データは、その画像の解像度およびレイヤ毎にパケット化されて所定順に整列されている。したがって、ネットワークパケット選択部３０５は、選択対象解像度・レイヤ決定部３０１による指定に該当する解像度およびレイヤのパケットを含む分割コードストリームをBodyとするネットワークパケットを選択すればよい。
【０２５０】
ネットワークパケットが該当する解像度およびレイヤのパケットを含むか否かは、分割コードストリームの先頭と末端の解像度番号およびレイヤ番号から判別することができる。
【０２５１】
ただし、図１６および図１８を参照して説明したように、符号化コードストリームの構造（パケットの並び）は、そのタイプによって異なる。
【０２５２】
したがって、ネットワークパケット選択部３０５は、符号化コードストリームのタイプに応じた判定式を用いてネットワークパケットの選択を行う。
【０２５３】
ネットワークパケット選択部３０５は、タイプ判定部３２１、L-R用選択部３２２、およびR-L用選択部３２３を有する。
【０２５４】
タイプ判定部３２１は、プログレッションオーダ情報に基づいて、ネットワークパケットに対応する符号化コードストリームのタイプを判定する。
【０２５５】
タイプ判定部３２１は、符号化コードストリームのタイプがL-Rタイプである場合、解像度・レイヤ算出部３０４から供給される各ネットワークパケットをL-R用選択部３２２に供給する（矢印３５１）。
【０２５６】
L-R用選択部３２２は、L-Rタイプ用に用意されたL-R用判定式を用いて各ネットワークパケットの取捨選択を行う。このL-R用判定式は、L-Rタイプの構造に対応している。つまり、L-R用選択部３２２は、このL-R用判定式を用いることにより、L-Rタイプの符号化コードストリームから作成されたネットワークパケットの先頭および末端の解像度番号およびレイヤ番号から、そのネットワークパケットが選択対象解像度・レイヤ決定部３０１において決定された解像度およびレイヤの画像を得るのに必要な符号化データ（パケット）を含むか否かを正しく特定することができる。
【０２５７】
L-R用選択部３２２は、このように、条件を満たすネットワークパケットを選択し、抽出する。L-R用選択部３２２は、抽出したネットワークパケットをネットワークパケット送信部３０６に供給する（矢印３３５）。
【０２５８】
また、タイプ判定部３２１は、符号化コードストリームのタイプがR-Lタイプである場合、解像度・レイヤ算出部３０４から供給される各ネットワークパケットをR-L用選択部３２３に供給する（矢印３５２）。
【０２５９】
R-L用選択部３２３は、R-Lタイプ用に用意されたR-L用判定式を用いて各ネットワークパケットの取捨選択を行う。このR-L用判定式は、R-Lタイプの構造に対応している。つまり、R-L用選択部３２３は、このR-L用判定式を用いることにより、R-Lタイプの符号化コードストリームから作成されたネットワークパケットの先頭および末端の解像度番号およびレイヤ番号から、そのネットワークパケットが選択対象解像度・レイヤ決定部３０１において決定された解像度およびレイヤの画像を得るのに必要な符号化データ（パケット）を含むか否かを正しく特定することができる。
【０２６０】
R-L用選択部３２３は、このように、条件を満たすネットワークパケットを選択し、抽出する。R-L用選択部３２３は、抽出したネットワークパケットをネットワークパケット送信部３０６に供給する（矢印３３５）。
【０２６１】
ネットワークパケット送信部３０６は、ネットワークパケット選択部３０５において選択されたネットワークパケットを、配信先となる端末装置１０４若しくは端末装置１０５に送信する。
【０２６２】
［処理の流れ］
以上のような各処理の流れの例を説明する。最初に、図２４のフローチャートを参照して、配信サーバ１０３により実行されるネットワークパケット配信処理の流れの例を説明する。
【０２６３】
例えば、端末装置１０４や端末装置１０５からの要求やユーザの指示等に基づいて、ネットワークパケットの配信が決定すると、配信サーバ１０３は、ネットワークパケット配信処理を開始する。
【０２６４】
ネットワークパケット配信処理が開始されると、選択対象解像度・レイヤ決定部３０１は、ステップＳ３０１において、選択対象の解像度およびレイヤを決定する。
【０２６５】
ステップＳ３０２において、プログレッションオーダ情報取得部３０２は、所望のコンテンツのプログレッションオーダ情報をコンテンツサーバ１０２から取得する。
【０２６６】
ステップＳ３０３において、ネットワークパケット取得部３０３は、コンテンツサーバ１０２から、所望のコンテンツのネットワークパケットを取得する。
【０２６７】
ステップＳ３０４において、解像度・レイヤ算出部３０４は、分割コードストリームの先頭および末端の解像度およびレイヤを算出する。
【０２６８】
ステップＳ３０５において、ネットワークパケット選択部３０５は、選択対象の解像度およびレイヤに基づいて、ネットワークパケットを選択する。
【０２６９】
ステップＳ３０６において、ネットワークパケット送信部３０６は、選択されたネットワークパケットを送信する。
【０２７０】
ステップＳ３０７において、ネットワークパケット取得部３０３は、全てのネットワークパケットを処理したか否かを判定する。所望のコンテンツに、未処理のネットワークパケットが存在すると判定された場合、ステップＳ３０３に戻り、それ以降の処理が繰り返される。
【０２７１】
また、ステップＳ３０７において、所望のコンテンツのネットワークパケットが全て処理されたと判定された場合、ネットワークパケット配信処理が終了される。
【０２７２】
次に、図２４のステップＳ３０４において実行される解像度レイヤ算出処理の詳細な流れの例を図２５のフローチャートを参照して説明する。
【０２７３】
解像度レイヤ算出処理が開始されると、ステップＳ３２１において、タイプ判定部３１１は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定する。
【０２７４】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部３１１は、ステップＳ３２２において処理をステップＳ３２３に進める。ステップＳ３２３において、L-R用算出部３１２は、L-R用算出式を用いて、アトリビュート番号から解像度番号およびレイヤ番号を求める。
【０２７５】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部３１１は、ステップＳ３２２において処理をステップＳ３２４に進める。ステップＳ３２４において、R-L用算出部３１３は、R-L用算出式を用いて、アトリビュート番号から解像度番号およびレイヤ番号を求める。
【０２７６】
解像度番号およびレイヤ番号が求められると、解像度レイヤ算出処理が終了され、図２４のステップＳ３０４に戻り、ステップＳ３０５以降の処理が実行される。
【０２７７】
次に、図２４のステップＳ３０５において実行される選択処理の詳細な流れの例を図２６のフローチャートを参照して説明する。
【０２７８】
選択処理が開始されると、ステップＳ３４１において、タイプ判定部３２１は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定する。
【０２７９】
符号化コードストリームのタイプがL-Rタイプであると判定された場合、タイプ判定部３２１は、ステップＳ３４２において処理をステップＳ３４３に進める。ステップＳ３４３において、L-R用選択部３２２は、L-R用判定式を用いて、パケットの選択を行う。
【０２８０】
また、符号化コードストリームのタイプがR-Lタイプであると判定された場合、タイプ判定部３２１は、ステップＳ３４２において処理をステップＳ３４４に進める。ステップＳ３４４において、R-L用選択部３２３は、R-L用判定式を用いて、パケットの選択を行う。
【０２８１】
パケットが選択されると、選択処理が終了され、図２４のステップＳ３０５に戻り、ステップＳ３０６以降の処理が実行される。
【０２８２】
以上のように、解像度・レイヤ算出部３０４が、各ネットワークパケットのNORMヘッダの拡張パラメータ領域に記述されたアトリビュート番号の先頭値および末端値から、そのネットワークパケットに含まれる分割コードストリームの先頭および末端の解像度番号およびレイヤ番号を求める。
【０２８３】
そして、ネットワークパケット選択部３０５は、その解像度番号およびレイヤ番号に基づいて、所望の解像度およびレイヤ（画質）の画像を得るのに必要なネットワークパケットを選択し、抽出する。
【０２８４】
このようにすることにより、配信サーバ１０３は、NORMヘッダに記述されたアトリビュート番号等の情報に基づいてネットワークパケットを取捨選択するだけで、所望の画像特徴量に応じて必要なデータをより容易に得ることができる。
【０２８５】
なお、このアトリビュート番号に関する情報（画像特徴量に関する情報）は、各ネットワークパケットのNORMヘッダに記述されているので、配信サーバ１０３は、従来と同様の方法でネットワークパケットを処理することができる。すなわち、配信サーバ１０３は、容易に、そのアトリビュート番号に関する情報を参照して処理することができる。
【０２８６】
また、解像度・レイヤ算出部３０４は、プログレッションオーダ情報に基づいて符号化コードストリームのタイプを判定し、そのタイプに応じた算出式を用いてアトリビュート番号から解像度番号やレイヤ番号を求めるので、符号化コードストリームのタイプに依らず、解像度番号やレイヤ番号を正しく求めることができる。
【０２８７】
さらに、ネットワークパケット選択部３０５は、符号化コードストリームのタイプに応じた判定式を用いてネットワークパケットの選択を行うので、符号化コードストリームのタイプに依らず、所望の解像度や画質に応じて必要なデータを正しく得ることができる。
【０２８８】
つまり、配信サーバ１０３は、符号化コードストリームのタイプを判別し、そのタイプに応じて適切な処理方法を選択することができるので、複数のタイプに対応することができる。
【０２８９】
もちろん、配信サーバ１０３は、上述したL-RタイプおよびR-Lタイプ以外のタイプにも対応することができる。例えば、符号化コードストリームは、解像度とレイヤ以外の画像特徴量をプログレッションに関する変数として適用するようにしてもよい。さらに、適用されるタイプの数は任意であり、例えば３つ以上であってもよいし、１つであってもよい。
【０２９０】
どのようなタイプが設定されるとしても、プログレッションオーダ情報には、適用される全てのタイプについて、符号化コードストリームの構造が示されている。したがって、解像度・レイヤ算出部３０４およびネットワークパケット選択部３０５は、適用される全てのタイプの符号化コードストリームの構造を、プログレッションオーダ情報を参照することにより把握することができる。
【０２９１】
なお、解像度・およびレイヤ以外の特徴量をプログレッションに関する変数として適用する場合、解像度・レイヤ算出部３０４は、解像度番号やレイヤ番号の場合と同様に、その特徴量についての識別番号を求める。選択対象解像度・レイヤ決定部３０１は、その特徴量について選択対象とする値を決定し、ネットワークパケット選択部３０５は、解像度やレイヤの場合と同様に、その特徴量の値を条件として、ネットワークパケットの選択を行う。
【０２９２】
また、解像度・レイヤ算出部３０４は、適用される全てのタイプについて、各タイプ専用の算出式を用いて解像度番号やレイヤ番号等の画像特徴量を算出する算出部を有している。タイプ判定部３１１は、判定したタイプの算出部に、各分割コードストリームのアトリビュート番号等の情報を供給する。
【０２９３】
同様に、ネットワークパケット選択部３０５は、適用される全てのタイプについて、各タイプ専用の判定式を用いてネットワークパケットの選択を行う選択部を有している。タイプ判定部３２１は、判定したタイプの選択部に、各ネットワークパケットを供給する。
【０２９４】
以上のように、コンテンツ配信システム１００は、例えば解像度や画質等、所望の特徴量に応じて、必要なデータをより容易に得ることができる。
【０２９５】
なお、図１においてコンテンツ配信システム１００の構成例を示したが、このコンテンツ配信システム１００を構成する各装置の数は任意である。また、コンテンツサーバ１０２を省略し、配信用データ生成装置１０１が生成したネットワークパケットを配信サーバ１０３に供給するようにしてもよい。
【０２９６】
また、この各装置が、図１で矢印により示される接続先以外の装置にさらに接続されているようにしても良い。例えば、配信用データ生成装置１０１が、コンテンツサーバ１０２だけでなく、さらに配信サーバ１０３や端末装置１０４および端末装置１０５と接続されるようにしても良い。その他の各装置についても同様である。
【０２９７】
さらに、以上においては、アトリビュート番号が付加されたネットワークパケットの利用方法としてそのネットワークパケットを送信（配信）する例について説明したが、ネットワークパケットの利用方法は任意である。
【０２９８】
また、以上においては、配信用データ生成装置１０１が、画像データをJPEG2000方式で符号化するように説明したが、符号化コードストリームがプログレッション順の構造を有するようにすればよく、画像データの符号化方式はJPEG2000方式に限定されない。
【０２９９】
＜２．第２の実施の形態＞
［パーソナルコンピュータ］
上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。この場合、例えば、図２７に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０３００】
図２７において、パーソナルコンピュータ４００のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０３０１】
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
【０３０２】
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）ディスプレイやLCD（Liquid Crystal Display）等のディスプレイ、並びにスピーカなどよりなる出力部４１２、フラッシュメモリ等SSD（Solid State Drive）やハードディスクなどよりなる記憶部４１３、有線LAN（Local Area Network）や無線LANのインタフェースやモデムなどよりなる通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０３０３】
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
【０３０４】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０３０５】
この記録媒体は、例えば、図２７に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、若しくは半導体メモリなどよりなるリムーバブルメディア４２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM４０２や、記憶部４１３に含まれるハードディスクなどにより構成される。
【０３０６】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０３０７】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３０８】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
【０３０９】
また、以上において、１つの装置（または処理部）として説明した構成が、複数の装置（または処理部）として構成されるようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成が、まとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成が付加されるようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部が他の装置（または他の処理部）の構成に含まれるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【０３１０】
本発明は、例えば、デジタルシネマ用編集装置、アーカイブシステム、放送局の画像伝送装置、画像データベース、医用画像の記録システム、ネットワークサーバ、インターネット上の画像伝送装置、無線伝送装置、映画館からの２次映像配信装置、ノンリニア編集装置、ゲーム機、テレビ受像機システム、HDDレコーダ、PC上のオーサリング・ツールまたはそのソフトウェア・モジュール等に適用することができる。
【符号の説明】
【０３１１】
１００ コンテンツ配信システム， １０１ 配信用データ生成装置， １０２ コンテンツサーバ， １０３ 配信サーバ， １０４および１０５ 端末装置， １２１ JPEG2000エンコーダ， １２２ コードストリーム分割部， １２３ NORMヘッダ生成部， １２４ ネットワークパケット生成部， １９１ アドレス抽出部， １９２ 解像度・レイヤ算出部， １９３ アトリビュート番号算出部， １９４ ヘッダ記述部， ２０１ タイプ判定部， ２０２ L-R用算出部， ２０３ R-L用算出部， ３０１ 選択対象解像度・レイヤ決定部， ３０２ プログレッションオーダ情報取得部， ３０３ ネットワークパケット取得部， ３０４ 解像度・レイヤ算出部， ３０５ ネットワークパケット選択部， ３０６ ネットワークパケット送信部， ３１１ タイプ判定部， ３１２ L-R用算出部， ３１３ R-L用算出部， ３２１ タイプ判定部， ３２２ L-R用選択部， ３２３ R-L用選択部
【特許請求の範囲】
【請求項１】
画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成するヘッダ情報生成手段と、
前記ヘッダ情報生成手段により生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化するバケット生成手段と
を備える画像処理装置。
【請求項２】
前記画像データを符号化し、前記プログレッション順の構造を有する前記コードストリームを生成する符号化手段をさらに備え、
前記ヘッダ情報生成手段は、前記符号化手段により前記画像データが符号化されて生成された前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成する
請求項１に記載の画像処理装置。
【請求項３】
前記符号化手段により前記画像データが符号化されて生成された前記コードストリームを所定のデータ長毎に分割する分割手段をさらに備え、
前記ヘッダ情報生成手段は、前記分割手段により前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成する
請求項２に記載の画像処理装置。
【請求項４】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものである
請求項１に記載の画像処理装置。
【請求項５】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含む
請求項４に記載の画像処理装置。
【請求項６】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度である
請求項５に記載の画像処理装置。
【請求項７】
前記ヘッダ情報生成手段は。
各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する抽出手段と、
前記アドレス抽出手段により抽出された前記先頭アドレスおよび前記末端アドレス、並びに、前記プログレッション順に基づいて、各分割コードストリームの先頭および末端の特徴量を算出する特徴量算出手段と、
前記特徴量算出手段により算出された、各分割コードストリームの先頭および末端の前記特徴量から、前記特徴量を他と識別する識別番号であるアトリビュート番号を算出するアトリビュート番号算出手段と、
前記ヘッダ情報を生成し、前記ヘッダ情報に、前記アトリビュート番号算出手段により算出された前記アトリビュート番号を記述する記述手段と
を備える請求項１に記載の画像処理装置。
【請求項８】
前記アトリビュート番号算出手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号を算出する算出処理手段と
を備える請求項７に記載の画像処理装置。
【請求項９】
画像処理装置の画像処理方法であって、
前記画像処理装置のヘッダ情報生成手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成し、
前記画像処理装置のパケット生成手段が、生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化する
画像処理方法。
【請求項１０】
画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定する特徴量特定手段と、
前記特徴量特定手段により特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行うパケット選択手段と
を備える画像処理装置。
【請求項１１】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものである
請求項１０に記載の画像処理装置。
【請求項１２】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含む
請求項１１に記載の画像処理装置。
【請求項１３】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度である
請求項１２に記載の画像処理装置。
【請求項１４】
前記パケットは、前記パケットに含まれる前記分割コードストリームの先頭および末端の、前記特徴量を他と識別する識別番号であるアトリビュート番号を含み、
前記特徴量特定手段は、前記アトリビュート番号から前記特徴量を求める
請求項１０に記載の画像処理装置。
【請求項１５】
前記特徴量特定手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号から前記特徴量を算出する算出処理手段と
を備える請求項１４に記載の画像処理装置。
【請求項１６】
前記パケット選択手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の判定式を用いて、前記パケットの選択を行う選択処理手段と
を備える請求項１０に記載の画像処理装置。
【請求項１７】
画像処理装置の画像処理方法であって、
前記画像処理装置の特徴量特定手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定し、
前記画像処理装置のパケット選択手段が、特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行う
画像処理方法。
【請求項１】
画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成するヘッダ情報生成手段と、
前記ヘッダ情報生成手段により生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化するバケット生成手段と
を備える画像処理装置。
【請求項２】
前記画像データを符号化し、前記プログレッション順の構造を有する前記コードストリームを生成する符号化手段をさらに備え、
前記ヘッダ情報生成手段は、前記符号化手段により前記画像データが符号化されて生成された前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成する
請求項１に記載の画像処理装置。
【請求項３】
前記符号化手段により前記画像データが符号化されて生成された前記コードストリームを所定のデータ長毎に分割する分割手段をさらに備え、
前記ヘッダ情報生成手段は、前記分割手段により前記コードストリームが分割されて得られる各分割コードストリームについて、前記ヘッダ情報を生成する
請求項２に記載の画像処理装置。
【請求項４】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものである
請求項１に記載の画像処理装置。
【請求項５】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含む
請求項４に記載の画像処理装置。
【請求項６】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度である
請求項５に記載の画像処理装置。
【請求項７】
前記ヘッダ情報生成手段は。
各分割コードストリームの先頭アドレスおよび末端アドレスを抽出する抽出手段と、
前記アドレス抽出手段により抽出された前記先頭アドレスおよび前記末端アドレス、並びに、前記プログレッション順に基づいて、各分割コードストリームの先頭および末端の特徴量を算出する特徴量算出手段と、
前記特徴量算出手段により算出された、各分割コードストリームの先頭および末端の前記特徴量から、前記特徴量を他と識別する識別番号であるアトリビュート番号を算出するアトリビュート番号算出手段と、
前記ヘッダ情報を生成し、前記ヘッダ情報に、前記アトリビュート番号算出手段により算出された前記アトリビュート番号を記述する記述手段と
を備える請求項１に記載の画像処理装置。
【請求項８】
前記アトリビュート番号算出手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号を算出する算出処理手段と
を備える請求項７に記載の画像処理装置。
【請求項９】
画像処理装置の画像処理方法であって、
前記画像処理装置のヘッダ情報生成手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる各分割コードストリームについて、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量を含むヘッダ情報を生成し、
前記画像処理装置のパケット生成手段が、生成された前記ヘッダ情報を用いて、各分割コードストリームをパケット化する
画像処理方法。
【請求項１０】
画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定する特徴量特定手段と、
前記特徴量特定手段により特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行うパケット選択手段と
を備える画像処理装置。
【請求項１１】
前記コードストリームは、前記画像データがJPEG2000方式により符号化されたものである
請求項１０に記載の画像処理装置。
【請求項１２】
前記特徴量は、前記JPEG2000方式における解像度およびレイヤを含む
請求項１１に記載の画像処理装置。
【請求項１３】
前記プログレッション順は、少なくとも２階層の階層構造を有し、上位階層の変数が前記解像度であり、かつ、下位階層の変数が前記レイヤであるか、若しくは、前記上位階層の変数が前記レイヤであり、かつ、前記下位階層の変数が前記解像度である
請求項１２に記載の画像処理装置。
【請求項１４】
前記パケットは、前記パケットに含まれる前記分割コードストリームの先頭および末端の、前記特徴量を他と識別する識別番号であるアトリビュート番号を含み、
前記特徴量特定手段は、前記アトリビュート番号から前記特徴量を求める
請求項１０に記載の画像処理装置。
【請求項１５】
前記特徴量特定手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の算出式を用いて、前記アトリビュート番号から前記特徴量を算出する算出処理手段と
を備える請求項１４に記載の画像処理装置。
【請求項１６】
前記パケット選択手段は、
前記プログレッション順を判定する判定手段と、
前記判定手段により判定された前記プログレッション順専用の判定式を用いて、前記パケットの選択を行う選択処理手段と
を備える請求項１０に記載の画像処理装置。
【請求項１７】
画像処理装置の画像処理方法であって、
前記画像処理装置の特徴量特定手段が、画像データが符号化されて生成されるプログレッション順の構造を有するコードストリームが分割されて得られる分割コードストリームを含むパケットに含まれる、前記分割コードストリームの先頭および末端の、前記画像データの画像の特徴量に関する情報に基づいて、前記分割コードストリームの先頭および末端の前記特徴量を特定し、
前記画像処理装置のパケット選択手段が、特定された前記分割コードストリームの先頭および末端の前記特徴量に基づいて、所望の特徴量に応じた前記パケットの選択を行う
画像処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２０１１−１４７０５１（Ｐ２０１１−１４７０５１Ａ）
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願番号】特願２０１０−７８０８（Ｐ２０１０−７８０８）
【出願日】平成２２年１月１８日（２０１０．１．１８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願日】平成２２年１月１８日（２０１０．１．１８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]