JP4884438B2 - 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 - Google Patents
階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 Download PDFInfo
- Publication number
- JP4884438B2 JP4884438B2 JP2008215480A JP2008215480A JP4884438B2 JP 4884438 B2 JP4884438 B2 JP 4884438B2 JP 2008215480 A JP2008215480 A JP 2008215480A JP 2008215480 A JP2008215480 A JP 2008215480A JP 4884438 B2 JP4884438 B2 JP 4884438B2
- Authority
- JP
- Japan
- Prior art keywords
- subtree
- context
- compression
- compression coding
- content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
- H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/40—Tree coding, e.g. quadtree, octree
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
Description
本発明の技術分野は、データを圧縮する分野である。より正確には、本発明はＸＭＬベースの文書（「拡張マークアップ言語規約（eXtended Markup Language）」）に関する。
本発明には、特に下記の分野のアプリケーションがあるが、それらに限定されない。
−マルチメディア用アプリケーション
−インデクセーションツール（indexation tool）
−メタデータ（meta-data）取扱いツール
−ＭＰＥＧ−７規格
−ＳＭＩＬ
−常設ＴＶ（TV Anytime）
−第三世代の無線通信（３ＧＰＰ）
−マルチメディア用アプリケーション
−インデクセーションツール（indexation tool）
−メタデータ（meta-data）取扱いツール
−ＭＰＥＧ−７規格
−ＳＭＩＬ
−常設ＴＶ（TV Anytime）
−第三世代の無線通信（３ＧＰＰ）
ＸＭＬに対する従来の圧縮技術には、幾つかの欠点がある。特に、それらの技術はデータへの高速アクセス、高い圧縮率及び文書のプログレッシブ構造に同時に対応していない。言い換えると、大抵の場合、上記の特徴の１つに対応すると、他の全ての特徴が失われてしまう。
従来の圧縮技術の１つは、ＢｉＭ（２進ＭＰＥＧ）として周知である。そのような技術は、文書の構造、すなわちＸＭＬ文書に関連したツリー構造のノードを２進化することによって、ＸＭＬ文書を圧縮する方法を提供する。このため、ＢｉＭ技術はデータへの高速アクセス、文書のプログレッシブ構造及びスキップ能力を可能にするが、ＢｉＭ技術を実行することによって得られる圧縮率は極めて小さい。
本発明の目的は、従来技術の欠点を補償することである。より正確には、本発明は、ＸＭＬベースの文書に対する効率的な圧縮技術を提供することを目的とする。本発明は、文書のスキップ能力、高い圧縮率、及びプログレッシブ構造を提供する、ＸＭＬ文書に対する圧縮技術を提供することも目的とする。本発明は、ＭＰＥＧ−７記述子を効率的に圧縮することも目的とする。本発明の別の目的はＸＭＬ文書を圧縮するための方法を実現することであり、この方法は、ＢｉＭ形の技術によって与えられた圧縮率を大いに向上させるが、ＢｉＭにより与えられる機能性と同じ機能性を提供する。
後に出てくる本発明の別の目的と同様に本発明の上記の目的は、本発明に基づいて、マルチメディア信号を記述する階層化ツリーを圧縮する方法によって実現される。このツリーは、少なくとも２つの明確なタイプの内容に結び付けることができるノード及びリーフを含むものである。この場合には、この方法は、それぞれが少なくとも１つのコンテントタイプに選択的に関連付けられた少なくとも２つの圧縮コード化技術によって、少なくとも幾つかのリーフに対してコンテント圧縮（content compression）を実現する。
本発明の好ましい実施形態によれば、そのような方法は少なくとも１つのサブツリー（sub-tree）を識別するステップと、圧縮コード化技術の１つをこのサブツリーに割り当てるステップとを含む。
有利には、そのような方法は、サブツリーのリーフのコンテンツ（又は、内容）が圧縮コード化技術に関連したタイプであり、サブツリーの他のリーフがいかなる圧縮コード化処理も受けないようなサブツリーのみに割り当てられた圧縮コード化技術を実行するステップを含む。
本発明の好ましい特徴によれば、そのような方法は、圧縮コード化技術のパラメータ記述を実行する。
そのような方法は、このツリーの構造を選択的に圧縮するステップも含む。
有利には、このツリーは、ＭＰＥＧ７規格によるＢｉＭ（２進ＭＰＥＧ）形である。
この圧縮コード化技術の１つは、線形の量子化を選択的に実行する。
有利には、この圧縮コード化技術の１つは統計的な圧縮アルゴリズムを実行する。
選択的には、このアルゴリズムはＧＺｉｐ形である。
有利には、このアルゴリズムは、少なくとも２つのリーフの内容に対応するデータの集合に対して同時に実行される。
このツリーは、ＸＭＬ（Extended markup language：拡張マークアップ言語規約）形の文書の構造を選択的に示す。
本発明は、階層化ツリーを圧縮するための上記の方法に基づいて圧縮されたマルチメディア信号をデコードする方法にも関係する。
そのような方法は、このツリーの構造を選択的に圧縮するステップも含む。
有利には、このツリーは、ＭＰＥＧ７規格によるＢｉＭ（２進ＭＰＥＧ）形である。
この圧縮コード化技術の１つは、線形の量子化を選択的に実行する。
有利には、この圧縮コード化技術の１つは統計的な圧縮アルゴリズムを実行する。
選択的には、このアルゴリズムはＧＺｉｐ形である。
有利には、このアルゴリズムは、少なくとも２つのリーフの内容に対応するデータの集合に対して同時に実行される。
このツリーは、ＸＭＬ（Extended markup language：拡張マークアップ言語規約）形の文書の構造を選択的に示す。
本発明は、階層化ツリーを圧縮するための上記の方法に基づいて圧縮されたマルチメディア信号をデコードする方法にも関係する。
有利には、そのような方法は、信号によって伝達されたコンテキスト情報（context information）のコード化に基づいて、現在のデコーディングコンテキスト（decoding context）をリフレッシュするステップを実行する。
この現在のコンテキストは、少なくとも１つのコンテントタイプを選択的に定義し、この方法は、リーフがこのコンテントタイプの内容を有するようなこのコンテントタイプに関連した圧縮デコーディング技術を実行するステップを含む。
この現在のコンテキストは、少なくとも１つのコンテントタイプを選択的に定義し、この方法は、リーフがこのコンテントタイプの内容を有するようなこのコンテントタイプに関連した圧縮デコーディング技術を実行するステップを含む。
本発明は、階層化ツリーを圧縮する前述した方法が発生する信号にも関係する。
本発明の他の特徴及び利点は、下記の説明及び以下の図面に照らしてより明確になるであろう。下記の説明は、単に説明するために示すものであり、実施例に限定するものではない。
本発明を実行する方法を詳細に説明する前に、ＢｉＭ技術としてよく知られた従来の圧縮技術の主な特徴を最初に思い出してみる。
文書を容易に理解するために、幾つかの引例をＡｎｎｅｘ９（表１６）の中に集めて、本明細書全体にわたって参照する。本明細書に含まれる全てのＡｎｎｅｘ（補遺）は、本発明の説明の一部をなすものである。
１．従来技術
（はじめに）
図１に示したコーディングコンテキストは、ビットストリームをデコーディングする間に必要なデコーディング情報の集合である。コーディングコンテキストは、定義されるノードのサブツリー全体に適用できる。ツリーの全てのノードにおいて、コーディングコンテキストを修正して、新しいコーディングコンテキストを作成し、対応するサブツリーに適用するようにできる。
（はじめに）
図１に示したコーディングコンテキストは、ビットストリームをデコーディングする間に必要なデコーディング情報の集合である。コーディングコンテキストは、定義されるノードのサブツリー全体に適用できる。ツリーの全てのノードにおいて、コーディングコンテキストを修正して、新しいコーディングコンテキストを作成し、対応するサブツリーに適用するようにできる。
コンテキストは、命令が関係するサブツリーに適用できることを特徴とする幾つかの情報を保持できる。現在のところ、ＢｉＭのサブツリーのコーディングフォーマット［１］では、これらの特徴は、（後方及び前方の互換性の特徴を提供するため、）サブツリーまたはコンテキストのスキップ能力及びサブツリーまたはコンテキストに対する複数のスキーマ（schema）のコード化である。最後に、このコンテキスト方法は、帯域幅をセーブするために全てのサブツリー内で無効にすることができる。これはコンテキスト凍結モードである。
このコーディングコンテキスト方法は、文書ツリーの全てのサブツリーの中で最大の柔軟性を提供し、ＢｉＭのコード化方法にプラグ接続されるという拡張可能な特徴を可能にする。
発明者らは、次に、ＢｉＭ内で使用されるコンテキスト方法を説明する。
[現在のコーディングコンテキスト方法]
（定義）
（コーディングコンテキスト（codingContext））
「コーディングコンテキスト」とは、デコーダがビットストリームをデコードするために必要とする情報の集合、すなわちコンテキスト情報である。コーディングコンテキストは、それが定義されているノード及びこのノードに対応するサブツリー全体に適用できる。
現在のコーディングコンテキスト（つまり、ある記述の指定されたノードにおいて適用可能なコンテキスト）は、文書内で修正することができる（換言すれば、その下にある情報の集合の修正）。コーディングコンテキストが修正されるたびに、修正された情報の集合を保持する新しいコーディングコンテキストが作成される。全てのコーディングコンテキストは、デコーダがコンテキストに対応するサブツリーのデコーディングを終了したとき、それらを元に戻すためにスタックされるべきものである。
（定義）
（コーディングコンテキスト（codingContext））
「コーディングコンテキスト」とは、デコーダがビットストリームをデコードするために必要とする情報の集合、すなわちコンテキスト情報である。コーディングコンテキストは、それが定義されているノード及びこのノードに対応するサブツリー全体に適用できる。
現在のコーディングコンテキスト（つまり、ある記述の指定されたノードにおいて適用可能なコンテキスト）は、文書内で修正することができる（換言すれば、その下にある情報の集合の修正）。コーディングコンテキストが修正されるたびに、修正された情報の集合を保持する新しいコーディングコンテキストが作成される。全てのコーディングコンテキストは、デコーダがコンテキストに対応するサブツリーのデコーディングを終了したとき、それらを元に戻すためにスタックされるべきものである。
（デコーダ）
ＢｉＭのデコーダは、下記の２つのデコーダからなる、すなわち、
−コンテキストデコーダ（context decoder）。このデコーダは、コンテキスト情報のデコーディング専用である。前述したように、コンテキスト情報は記述の一部ではない。これは幾つかの外部形状、後方及び前方の互換性、高速スキッピング（fast skipping）などを保持する情報の集合である。
−要素デコーダ（element decoder）。このデコーダはＢｉＭ正規デコーダ［１］（BiM regular one）であり、要素情報のデコーディング専用である。
ＢｉＭのデコーダは、下記の２つのデコーダからなる、すなわち、
−コンテキストデコーダ（context decoder）。このデコーダは、コンテキスト情報のデコーディング専用である。前述したように、コンテキスト情報は記述の一部ではない。これは幾つかの外部形状、後方及び前方の互換性、高速スキッピング（fast skipping）などを保持する情報の集合である。
−要素デコーダ（element decoder）。このデコーダはＢｉＭ正規デコーダ［１］（BiM regular one）であり、要素情報のデコーディング専用である。
（チャンク）
記述の各要素は、図２に示した３つの部分にコード化される。この場合、ヘッダ部は大きさをゼロにできる２つのチャンクから構成される。
−ＭＣはメタコンテキストのチャンク（metacontext chunk）である。
−Ｃはコンテキストチャンクである。
−エレメント（Element）は要素チャンクであり、これは正規の要素コーディングチャンクである（［１］を参照のこと）
このＭＣメタコンテキストチャンクは、デコーダが次のＣコンテキストチャンクをデコードするために必要とする情報を含む。すなわち、ＭＣチャンクは、Ｃコンテキストチャンクのコンテキストチャンクである。
このＣコンテキストチャンクは、デコーダが次の要素チャンクをデコードするために必要な、現在のコーディングコンテキストの情報の集合を変更できる情報を含む。言い換えると、このＣチャンクは、要素チャンクのコンテキストチャンクである。
記述の各要素は、図２に示した３つの部分にコード化される。この場合、ヘッダ部は大きさをゼロにできる２つのチャンクから構成される。
−ＭＣはメタコンテキストのチャンク（metacontext chunk）である。
−Ｃはコンテキストチャンクである。
−エレメント（Element）は要素チャンクであり、これは正規の要素コーディングチャンクである（［１］を参照のこと）
このＭＣメタコンテキストチャンクは、デコーダが次のＣコンテキストチャンクをデコードするために必要とする情報を含む。すなわち、ＭＣチャンクは、Ｃコンテキストチャンクのコンテキストチャンクである。
このＣコンテキストチャンクは、デコーダが次の要素チャンクをデコードするために必要な、現在のコーディングコンテキストの情報の集合を変更できる情報を含む。言い換えると、このＣチャンクは、要素チャンクのコンテキストチャンクである。
（情報の集合）
現在のＢｉＭコーディングコンテキストは、情報の集合、すなわち、次の２つの主な部類に分割できるコンテキスト情報を保持する。
−（この節に含まれた情報がコンテキストデコーディング工程のみに影響する場合の）メタコンテキスト部。
−（この節に含まれた情報が要素デコーディング工程のみに影響する場合の）コンテキスト部。
現在のＢｉＭコーディングコンテキストは、情報の集合、すなわち、次の２つの主な部類に分割できるコンテキスト情報を保持する。
−（この節に含まれた情報がコンテキストデコーディング工程のみに影響する場合の）メタコンテキスト部。
−（この節に含まれた情報が要素デコーディング工程のみに影響する場合の）コンテキスト部。
現在の情報の集合は、下記の変数の集合である。
定義されたクラスは、（ＭＣメタコンテキストチャンク及びＣコンテキストチャンク等の）前述したチャンクを正確にコーディングする。
[メタコンテキストチャンク]
（定義）
ＭＣメタコンテキストチャンクは、その大きさをゼロにすることができ、デコーダが以下の節で説明されるような次のＣコンテキストチャンクを読み取る必要があるかどうかを知るための情報を含む。
（定義）
ＭＣメタコンテキストチャンクは、その大きさをゼロにすることができ、デコーダが以下の節で説明されるような次のＣコンテキストチャンクを読み取る必要があるかどうかを知るための情報を含む。
（関係する変数）
（デフォルト値）
freezing_stateのデフォルト値は偽である。すなわち、デフォルトでは、根本的なコンテキストを動的に変更できるようになっている。
freezing_stateのデフォルト値は偽である。すなわち、デフォルトでは、根本的なコンテキストを動的に変更できるようになっている。
（伝搬規則）
新しいコンテキストが作成されるときには、
−freezing_state値は、その父親のコンテキスト（father's context）のfreezing_state値に設定される。
新しいコンテキストが作成されるときには、
−freezing_state値は、その父親のコンテキスト（father's context）のfreezing_state値に設定される。
（動的修正規則）
新しいコンテキストを作成するために、記述の各ノードにおいて、
−freezing_state値を偽の値から真の値に切り換えることができる。
新しいコンテキストを作成するために、記述の各ノードにおいて、
−freezing_state値を偽の値から真の値に切り換えることができる。
（デコーディング規則）
freezing_state値が真の場合には、ＭＣメタコンテキストチャンク（及び次のＣコンテキストチャンク）はビットストリームにコード化されない。真でない場合には、ヘッダ部分のＭＣメタコンテキストチャンクは下記のようにコード化される。
context_chunkは偽で初期化されたローカル変数である。
freezing_state値が真の場合には、ＭＣメタコンテキストチャンク（及び次のＣコンテキストチャンク）はビットストリームにコード化されない。真でない場合には、ヘッダ部分のＭＣメタコンテキストチャンクは下記のようにコード化される。
（コンテキストデコーディング工程に対する影響）
context_chunk値が真の場合には、デコーダは次のＣコンテキストチャンクを読み込む必要がある。
context_chunk値が真の場合には、デコーダは次のＣコンテキストチャンクを読み込む必要がある。
コンテキストチャンク
（定義）
Ｃコンテキストチャンクは、大きさをゼロにすることができ、現在のコンテキスト変数を動的に変更できる情報の集合を含む。これらの変数は、ＢｉＭ要素のデコーディング工程に影響を与えるため、コーディング特性（codingProperties）と呼ばれる。
（関係するコーディング特性）
（定義）
Ｃコンテキストチャンクは、大きさをゼロにすることができ、現在のコンテキスト変数を動的に変更できる情報の集合を含む。これらの変数は、ＢｉＭ要素のデコーディング工程に影響を与えるため、コーディング特性（codingProperties）と呼ばれる。
（関係するコーディング特性）
（デフォルト値）
allows_skip変数は、ＦＤＣシステム文書［１］の中で定義されているように、特別な４ビットのビットフィールド（bitfield）の最初の２ビットによって、ビットストリームの始めで初期化される。
allows_partial_instantiation変数は、特別な４ビットのビットフィールドの第３の２ビットによって、ビットストリームの始めで初期化される。
allows_subtyping変数は、特別な４ビットのビットフィールドの第４の２ビットによって、ビットストリームの始めで初期化される。
schema_modeのデフォルト値は、モノラル（mono）である。すなわち、デフォルトでは、ルートのサブツリー／コンテキストは１つのスキーマを用いてコード化される。
allows_skip変数は、ＦＤＣシステム文書［１］の中で定義されているように、特別な４ビットのビットフィールド（bitfield）の最初の２ビットによって、ビットストリームの始めで初期化される。
allows_partial_instantiation変数は、特別な４ビットのビットフィールドの第３の２ビットによって、ビットストリームの始めで初期化される。
allows_subtyping変数は、特別な４ビットのビットフィールドの第４の２ビットによって、ビットストリームの始めで初期化される。
schema_modeのデフォルト値は、モノラル（mono）である。すなわち、デフォルトでは、ルートのサブツリー／コンテキストは１つのスキーマを用いてコード化される。
（伝搬規則）
新しいコンテキストの作成時に、
−allows_skip値は、その父親のコンテキストのallows_skip値に設定される。
−allows_partial_instantiation値は、その父親のコンテキストの値に設定される。
−allows_subtyping値は、その父親のコンテキストの値に設定される。
−schema_mode値は、そのデフォルト値に設定される。
新しいコンテキストの作成時に、
−allows_skip値は、その父親のコンテキストのallows_skip値に設定される。
−allows_partial_instantiation値は、その父親のコンテキストの値に設定される。
−allows_subtyping値は、その父親のコンテキストの値に設定される。
−schema_mode値は、そのデフォルト値に設定される。
（動的修正規則）
新しいコンテキストを作成するために、記述の各ノードにおいて、
−allows_skipは動的に修正できる。
−allows_partial_instantiationは動的に修正できない。
−allows_subtypingは動的に修正できない。
−schema_modeは動的に修正できる。
新しいコンテキストを作成するために、記述の各ノードにおいて、
−allows_skipは動的に修正できる。
−allows_partial_instantiationは動的に修正できない。
−allows_subtypingは動的に修正できない。
−schema_modeは動的に修正できる。
（デコーディング規則）
Ｃコンテキストチャンクは、ＭＣメタコンテキストチャンクが既に存在し、その以前のローカル変数context_chunkが真の場合にのみ存在する。
現在のコンテキストの動的な修正は、ＢｉＭの正規のコード化方式を用いてコード化されるＸＭＬ要素を用いて記述される。ＢｉＭスキーマからの汎用要素modifyContextが使用される。http://www.mpeg7.org/2001/BiMCodingのコーディングスキーマは、補遺１に記載されている。
Ｃコンテキストチャンクは、上記のスキーマによるＢｉＭの正規の方式を用いて記述する必要がある。
前述したように、コンテキスト内の現在のコーディング特性の修正は、新しいコンテキストの作成を意味する。このため、Ｃコンテキストチャンクが存在することは、修正されたコーディング特性を保持する新しいコンテキストが作られたことを意味する。
allowsSkip要素がmodifyContext要素の中で例示される場合には、allows_skipの値は新しいコンテキストの中で更新される。
schema_mode要素がmodifyContext要素の中で例示される場合には、schema_modeの値は新しいコンテキストの中で更新される。
Ｃコンテキストチャンクは、ＭＣメタコンテキストチャンクが既に存在し、その以前のローカル変数context_chunkが真の場合にのみ存在する。
現在のコンテキストの動的な修正は、ＢｉＭの正規のコード化方式を用いてコード化されるＸＭＬ要素を用いて記述される。ＢｉＭスキーマからの汎用要素modifyContextが使用される。http://www.mpeg7.org/2001/BiMCodingのコーディングスキーマは、補遺１に記載されている。
Ｃコンテキストチャンクは、上記のスキーマによるＢｉＭの正規の方式を用いて記述する必要がある。
前述したように、コンテキスト内の現在のコーディング特性の修正は、新しいコンテキストの作成を意味する。このため、Ｃコンテキストチャンクが存在することは、修正されたコーディング特性を保持する新しいコンテキストが作られたことを意味する。
allowsSkip要素がmodifyContext要素の中で例示される場合には、allows_skipの値は新しいコンテキストの中で更新される。
schema_mode要素がmodifyContext要素の中で例示される場合には、schema_modeの値は新しいコンテキストの中で更新される。
（要素デコーディング工程に対する影響）
allows_skip値及びschema_mode値は、スキッピング特性を処理する場合に要素デコーディング工程に影響を与える。この動作は［１］に記載されている。
schema_mode値は、要素が１つのスキーマだけにより又は幾つかのスキーマによりコード化されるのかどうかを知るために要素デコーディング工程に影響する。この仕組みは［１］に記載されている。
allows_partial_instantiation値は、１つの特殊なタイプのpartiallylnstantiatedタイプを要素の可能なサブタイプに加えることによって、要素デコーディング工程に影響を与える。［１］を参照のこと。
allows_subtyping値は、要素デコーディング工程に影響し、要素が多形性（polymorphism）（xsi:typeの属性を有する）又はユニオンの場合には、要素又は属性が異なる可能なタイプを持つことができるようにする。［１］を参照のこと。
allows_skip値及びschema_mode値は、スキッピング特性を処理する場合に要素デコーディング工程に影響を与える。この動作は［１］に記載されている。
schema_mode値は、要素が１つのスキーマだけにより又は幾つかのスキーマによりコード化されるのかどうかを知るために要素デコーディング工程に影響する。この仕組みは［１］に記載されている。
allows_partial_instantiation値は、１つの特殊なタイプのpartiallylnstantiatedタイプを要素の可能なサブタイプに加えることによって、要素デコーディング工程に影響を与える。［１］を参照のこと。
allows_subtyping値は、要素デコーディング工程に影響し、要素が多形性（polymorphism）（xsi:typeの属性を有する）又はユニオンの場合には、要素又は属性が異なる可能なタイプを持つことができるようにする。［１］を参照のこと。
２．本発明の説明
２．１ リーフを圧縮するためのフレームワークを提供するコンテキスト方法の拡張
本発明は、新規で興味ある特徴、すなわち、結果として生ずるビットストリームの大きさを減らすために、ある文書のリーフを圧縮する局部圧縮機（local compressor）を使用して、現在のＢｉＭコンテキスト方法を拡張することを提案する。
２．１ リーフを圧縮するためのフレームワークを提供するコンテキスト方法の拡張
本発明は、新規で興味ある特徴、すなわち、結果として生ずるビットストリームの大きさを減らすために、ある文書のリーフを圧縮する局部圧縮機（local compressor）を使用して、現在のＢｉＭコンテキスト方法を拡張することを提案する。
この節では、局部圧縮機を使用できるように現在のＢｉＭコンテキスト方法を拡張する方法を説明する。これは、典型的な例では、特定の意味論規則、伝搬規則及びコーディング規則とリンクした新しい変数の集合のcodingPropertiesである。従って、この新たなcodingPropertiesの集合によって、現在のコンテキストチャンクが拡張される。
（はじめに）
サブツリーでは、１つ又は数個の指定された単純なタイプのインスタンスがあると、それらは全て１つ又は数個の指定された圧縮機を用いて圧縮することができる。これは基本的には、圧縮機と１つ又は数個の単純なタイプとの間のマッピングを定義する。
さらに、
−場合によっては、圧縮機は幾つかの外部パラメータを必要とすることができる。
−幾つかのサブツリー内で圧縮機を使用し、別のサブツリーでは使用しないようにするために、マッピングを起動又は停止することができる。
最後に、起動または停止するために、マッピングは参照可能でなければならず、このためコンテキストの中で固有の識別子を持つ必要がある。
その結果、各コンテキストは、ゼロ、１つ又は数個のcodecTypeMapperを保持できる。ここで、codecTypeMapperは、識別子、１つ又は数個の単純なタイプ、コーデック、選択可能な外部のコーデックパラメータ及び活性化状態から成る４プレット（4-plet）である。
サブツリーでは、１つ又は数個の指定された単純なタイプのインスタンスがあると、それらは全て１つ又は数個の指定された圧縮機を用いて圧縮することができる。これは基本的には、圧縮機と１つ又は数個の単純なタイプとの間のマッピングを定義する。
さらに、
−場合によっては、圧縮機は幾つかの外部パラメータを必要とすることができる。
−幾つかのサブツリー内で圧縮機を使用し、別のサブツリーでは使用しないようにするために、マッピングを起動又は停止することができる。
最後に、起動または停止するために、マッピングは参照可能でなければならず、このためコンテキストの中で固有の識別子を持つ必要がある。
その結果、各コンテキストは、ゼロ、１つ又は数個のcodecTypeMapperを保持できる。ここで、codecTypeMapperは、識別子、１つ又は数個の単純なタイプ、コーデック、選択可能な外部のコーデックパラメータ及び活性化状態から成る４プレット（4-plet）である。
（定義）
（CodecTypeMapper）
codecTypeMapperは、４プレットであり、
−サブツリーまたはコンテキストの中で固有の参照キーとして使用される識別子と、
−マッピングが適用できる１つ又は数個の単純なタイプと、
−コーデックと、
−任意選択的な外部コーデックパラメータ（コーデックに依存する）と、
−活性化状態と
を備えている。
（CodecTypeMapper）
codecTypeMapperは、４プレットであり、
−サブツリーまたはコンテキストの中で固有の参照キーとして使用される識別子と、
−マッピングが適用できる１つ又は数個の単純なタイプと、
−コーデックと、
−任意選択的な外部コーデックパラメータ（コーデックに依存する）と、
−活性化状態と
を備えている。
（識別子）
識別子は、固有の番号であり、明白な方法でコンテキスト内のマッピングを識別する。ＢｉＭのコーディングスキーマは、コンテキスト内のcodecTypeMappersの最大数を３２に制限する。
識別子は、固有の番号であり、明白な方法でコンテキスト内のマッピングを識別する。ＢｉＭのコーディングスキーマは、コンテキスト内のcodecTypeMappersの最大数を３２に制限する。
（単純なタイプ）
あるスキーマにおいて定義された全ての単純なタイプ（simple type）は、全てのコーデックによって先験的に（a priori）コード化することができるが、各コーデックはこの選択を制限できる。例えば、以後文書の中で定義するような線形の量子化器（linear quantizer）は、数値的な単純なタイプと共にのみ使用できる。
あるスキーマにおいて定義された全ての単純なタイプ（simple type）は、全てのコーデックによって先験的に（a priori）コード化することができるが、各コーデックはこの選択を制限できる。例えば、以後文書の中で定義するような線形の量子化器（linear quantizer）は、数値的な単純なタイプと共にのみ使用できる。
単純なタイプは、その名前及びそれが属するスキーマのＵＲＬによって識別される。正しいスキーマを指し示すために、ＸＭＬスキーマのプレフィックス（prefix）を用いるべきである。ＢｉＭコーディングスキーマは、この対をコード化するためにある特殊なタイプを定義する、すなわち、このタイプは整数の対としてコード化されなければならない、第１の整数はわかっているスキーマの現在の数に制限され（この情報の部分は、DecoderConfig部［１］の中でフェッチすることができる）、第２の整数は対応するスキーマの中に存在するグローバルな単純なタイプの数に制限される。
（コーデック）
圧縮機または解凍機（compressor/decompressor）の役目をするコーデック（codec）は、入力ビットを取り入れて出力ビットを書き込むモジュールである。それは幾つかの選択可能な外部パラメータを必要とすることがある。
コーデックは、ＢｉＭのコーディングスキーマの中で定義された非抽象的なコーデックの名前の中の名前によって識別される。上記の節の中で定義された現在のＢｉＭのコーディングスキーマは、どの非抽象的なコーデックも定義しないが、本明細書の２．２節（段落番号[００６１]以下）では定義している。
圧縮機または解凍機（compressor/decompressor）の役目をするコーデック（codec）は、入力ビットを取り入れて出力ビットを書き込むモジュールである。それは幾つかの選択可能な外部パラメータを必要とすることがある。
コーデックは、ＢｉＭのコーディングスキーマの中で定義された非抽象的なコーデックの名前の中の名前によって識別される。上記の節の中で定義された現在のＢｉＭのコーディングスキーマは、どの非抽象的なコーデックも定義しないが、本明細書の２．２節（段落番号[００６１]以下）では定義している。
（活性化状態）
活性化状態はブーリアンフラグである。
活性化状態はブーリアンフラグである。
（意味論規則）
（CodecTypeMapper）
各コンテキストは、
−ゼロ、１つ又は数個のcodecTypeMapperを保持できる。
−１つ又は数個のcodecTypeMapperを定義できる。
−１つ又は数個の現行のcodecTypeMapperを起動又は停止できる。
あるcodecTypeMapperがコンテキストの中で定義されると、それは全てのそのサブコンテキストの中に残る。
コンテキスト内に存在するcodecTypeMapperを削除又は修正することはできない（活性化状態は除く）。
（CodecTypeMapper）
各コンテキストは、
−ゼロ、１つ又は数個のcodecTypeMapperを保持できる。
−１つ又は数個のcodecTypeMapperを定義できる。
−１つ又は数個の現行のcodecTypeMapperを起動又は停止できる。
あるcodecTypeMapperがコンテキストの中で定義されると、それは全てのそのサブコンテキストの中に残る。
コンテキスト内に存在するcodecTypeMapperを削除又は修正することはできない（活性化状態は除く）。
（識別子）
マッピングの識別子は、コンテキストの全てのcodecTypeMapperの中で一意的でなければならない。
マッピングの識別子は、コンテキストの全てのcodecTypeMapperの中で一意的でなければならない。
（単純なタイプ）
codecTypeMapperを１つ又は数個の単純なタイプ及びコーデックと結び付ける場合、このコーデックは単純なタイプ自体及びそれらから生じた全ての単純なタイプをコード化／デコードする。
コンテキストには、コーデックの場合とは異なり、たかだか１つの単純なタイプが存在する必要がある。
codecTypeMapperを１つ又は数個の単純なタイプ及びコーデックと結び付ける場合、このコーデックは単純なタイプ自体及びそれらから生じた全ての単純なタイプをコード化／デコードする。
コンテキストには、コーデックの場合とは異なり、たかだか１つの単純なタイプが存在する必要がある。
（コーデック）
２種類のコーデック、すなわち、メモリ無しのコーデックとコンテキスト式コーデックとがある。
メモリ無しのコーデックは、常に同じ入力バイトを同じバイト出力にコード化するモジュールであり、コーデックの履歴に無関係である。典型的なメモリ無しのコーデックは、線形の限定子である。ＢｉＭのリーフ圧縮（本明細書の２．２節を参照のこと）は、そのようなコーデックを説明している。
コンテキスト式コーデックは、送られた以前のバイトを使用する（このため、コーデックのコンテキストは変更される）モジュールである。そのようなコーデックは、受け取った同じ入力バイトに対して同じ出力バイトを発生しない。典型的なコンテキスト式コーデックは、Ｚｉｐのようなローカルコーデックであり、本明細書の２．２節に説明されている。
メモリ無しのコーデックは、現在のコンテキストのアーキテクチャでは何ら問題を引き起こさないが、コンテキスト式コーデックはスキップ可能なサブツリーの場合には問題を発生する。そのような場合には、この前者がサブツリーをスキップした場合にデコーダを混乱させないように、コンテキスト式コーデックはリセットされる。
２種類のコーデック、すなわち、メモリ無しのコーデックとコンテキスト式コーデックとがある。
メモリ無しのコーデックは、常に同じ入力バイトを同じバイト出力にコード化するモジュールであり、コーデックの履歴に無関係である。典型的なメモリ無しのコーデックは、線形の限定子である。ＢｉＭのリーフ圧縮（本明細書の２．２節を参照のこと）は、そのようなコーデックを説明している。
コンテキスト式コーデックは、送られた以前のバイトを使用する（このため、コーデックのコンテキストは変更される）モジュールである。そのようなコーデックは、受け取った同じ入力バイトに対して同じ出力バイトを発生しない。典型的なコンテキスト式コーデックは、Ｚｉｐのようなローカルコーデックであり、本明細書の２．２節に説明されている。
メモリ無しのコーデックは、現在のコンテキストのアーキテクチャでは何ら問題を引き起こさないが、コンテキスト式コーデックはスキップ可能なサブツリーの場合には問題を発生する。そのような場合には、この前者がサブツリーをスキップした場合にデコーダを混乱させないように、コンテキスト式コーデックはリセットされる。
（活性化状態）
全てのサブツリー又はコンテキストにおいて、codecTypeMapperを起動又は停止することができる。
この仕組みにより、codecTypeMapperを文書ツリーのより高いレベルで定義し、使用されているサブツリーの中でのみcodecTypeMapperを再定義せずに起動することができる。
全てのサブツリー又はコンテキストにおいて、codecTypeMapperを起動又は停止することができる。
この仕組みにより、codecTypeMapperを文書ツリーのより高いレベルで定義し、使用されているサブツリーの中でのみcodecTypeMapperを再定義せずに起動することができる。
（新しいcodingProperty：codecTypeMapper）
この部分では、新しいcodingPropertyを、前述したコンテキスト部の以前の変数の集合に加える。この新しいcodingPropertyはcodecTypeMapperと名付けられ、前の節の中で説明された以前のcodecTypeMapperのリストである。
この部分では、新しいcodingPropertyを、前述したコンテキスト部の以前の変数の集合に加える。この新しいcodingPropertyはcodecTypeMapperと名付けられ、前の節の中で説明された以前のcodecTypeMapperのリストである。
（関係する新しいcodingProperty）
コンテキストはcodecTypeMapperのリストを保持する。
コンテキストはcodecTypeMapperのリストを保持する。
（新しいデフォルト値）
デフォルトにより、サブツリー又はコンテキスト内にはcodecTypeMapperはない。
codecTypeMapperをコンテキスト内で定義する場合には、その識別子、コーデック及びsimple_type値を定義する必要がある。指定されない場合は、新しく定義されたcodecTypeMapperの活性化状態はデフォルトにより真に設定される。すなわち、新しく定義されたcodecTypeMapperはデフォルトにより起動される。
デフォルトにより、サブツリー又はコンテキスト内にはcodecTypeMapperはない。
codecTypeMapperをコンテキスト内で定義する場合には、その識別子、コーデック及びsimple_type値を定義する必要がある。指定されない場合は、新しく定義されたcodecTypeMapperの活性化状態はデフォルトにより真に設定される。すなわち、新しく定義されたcodecTypeMapperはデフォルトにより起動される。
（新しい伝搬規則）
（規則１）
新しいコンテキストの作成時には、codecTypeMapperのリストはその父親のコンテキストのコピーである。
−識別子の値がコピーされる。
−simple_typeの値がコピーされる。
−コーデックの値が規則２に従ってコピーされる。
−codec_parameterの値がコピーされる。
−activation_stateの値がコピーされる。
（規則２）
コーデックの値がコピーされ、下記が成立する場合、つまり、
−父親のコーデックのcodingProperty[i].codecがコンテキスト式コーデックであり、
−現在のコンテキストがスキップ可能である場合には、
デコーダは、父親のコーデックの事例（その値だけでなく）をコピーし、それをリセットすることによって、コーデックの新しい事例を作成することが期待される。
例えば、ZLibコーデックがコピーされ、スキップ可能なノードに入るときに再度初期化される。
（規則１）
新しいコンテキストの作成時には、codecTypeMapperのリストはその父親のコンテキストのコピーである。
−識別子の値がコピーされる。
−simple_typeの値がコピーされる。
−コーデックの値が規則２に従ってコピーされる。
−codec_parameterの値がコピーされる。
−activation_stateの値がコピーされる。
（規則２）
コーデックの値がコピーされ、下記が成立する場合、つまり、
−父親のコーデックのcodingProperty[i].codecがコンテキスト式コーデックであり、
−現在のコンテキストがスキップ可能である場合には、
デコーダは、父親のコーデックの事例（その値だけでなく）をコピーし、それをリセットすることによって、コーデックの新しい事例を作成することが期待される。
例えば、ZLibコーデックがコピーされ、スキップ可能なノードに入るときに再度初期化される。
（新しい動的な修正規則）
codecTypeMapperのリストを記述の中で下記のように動的に修正できる。
−新しいcodecTypeMapperを定義できる。
−現在の（次に参照可能な）activation_stateのcodecTypeMapperを動的に修正できる。
（そのactivation_stateを除き、）現在のcodecTypeMapperを削除することはできず、そのメンバを動的に修正することもできない。
codecTypeMapperのリストを記述の中で下記のように動的に修正できる。
−新しいcodecTypeMapperを定義できる。
−現在の（次に参照可能な）activation_stateのcodecTypeMapperを動的に修正できる。
（そのactivation_stateを除き、）現在のcodecTypeMapperを削除することはできず、そのメンバを動的に修正することもできない。
（新しいデコーディング規則）
同じ前の規則はＣコンテキストチャンクのデコーディングに適用するが、補遺２で説明される新しいスキーマが、新しいcodecTypeMapperの動的な修正機能を加えるために使用される。
同じ前の規則はＣコンテキストチャンクのデコーディングに適用するが、補遺２で説明される新しいスキーマが、新しいcodecTypeMapperの動的な修正機能を加えるために使用される。
（情報提供部）
（実施例）
補遺３に示した実施例は、記述する場合の１つの活性化された線形の限定子（本明細書の２．２節を参照のこと）の定義を示す。
（実施例）
補遺３に示した実施例は、記述する場合の１つの活性化された線形の限定子（本明細書の２．２節を参照のこと）の定義を示す。
補遺４に示した実施例は、記述する場合の１つの非活性化された線形の限定子（本明細書の２．２節を参照のこと）の定義を示す。
２．２ ＢｉＭのリーフ圧縮
異なるコーデックを用いてデータをコード化するために、本発明によって実現された仕組みをここで示す。より正確に言うと、ここで２つの実施例を示す、すなわち、１つは線形の量子化コーデックを使用して例えば浮動小数点の値を圧縮する実施例、及びもう１つはgzipのコーデックを使用して例えばストリング値を圧縮する実施例である。
異なるコーデックを用いてデータをコード化するために、本発明によって実現された仕組みをここで示す。より正確に言うと、ここで２つの実施例を示す、すなわち、１つは線形の量子化コーデックを使用して例えば浮動小数点の値を圧縮する実施例、及びもう１つはgzipのコーデックを使用して例えばストリング値を圧縮する実施例である。
そのような仕組みはコーディングコンテキストに密接に関連しており、幾つかの他の種類のコーデックを使用できるようにする。さらに、この仕組みは、例えば、ストリップ可能なサブツリーなどのコーディングコンテキストの機能を適切に処理できる。最後に、この仕組みは、別のコーディングコンテキスト内のコーデックを再度使用することができる。
（はじめに）
ＢｉＭのサブツリーのコーディング［１］は、記述のデータリーフを圧縮しない。現在は、リーフ値は、（ＩＥＥＥ７５４のフロート及びダブル（floats and doubles）、ＵＴＦストリングなどの）その種類に関連してコード化される。
ＢｉＭのサブツリーのコーディング［１］は、記述のデータリーフを圧縮しない。現在は、リーフ値は、（ＩＥＥＥ７５４のフロート及びダブル（floats and doubles）、ＵＴＦストリングなどの）その種類に関連してコード化される。
多くの場合には、ＢｉＭの圧縮比をその主な機能を失わずに向上させるために、（流線型の構文解析（streamline parsing）、高速スキッピング機能、タイプドデコーディング（typed decoding）などの）線形の量子化又は統計的な圧縮のような幾つかの伝統的な圧縮技術を使用することが有用である。
次に、より優れた圧縮比を実現するために、２．１節で説明されたコンテキストコーディングの方法の中で、ある文書のデータリーフの圧縮を行うことができる方法を示す。
２．２．１ 線形量子化
（定義）
線形量子化は、情報源が既知であり、このため損失を制御できる場合に、ビットストリーム内のコード化された数の大きさを減らすための通常の損失の多い方法である。
一例として、サンプリングされたオーディオ信号の包絡線は正確なビットサイズの量子化を有するとして良く知られており、この技術は、ＭＰＥＧ−７のオーディオ記述をコーディングするために効果的に使用することができる。
νが実数の場合には、νはnbitsビットのνqにより下記のようにコード化することができる。
ここで、
−νqは、νの量子化及びコード化された値である。
−nbitsは、ビットに必要な精度である。
−νminは、νが到達できる最小の包含的値である。
−νmaxは、νが到達できる最大の包含的値である。
（定義）
線形量子化は、情報源が既知であり、このため損失を制御できる場合に、ビットストリーム内のコード化された数の大きさを減らすための通常の損失の多い方法である。
一例として、サンプリングされたオーディオ信号の包絡線は正確なビットサイズの量子化を有するとして良く知られており、この技術は、ＭＰＥＧ−７のオーディオ記述をコーディングするために効果的に使用することができる。
νが実数の場合には、νはnbitsビットのνqにより下記のようにコード化することができる。
−νqは、νの量子化及びコード化された値である。
−nbitsは、ビットに必要な精度である。
−νminは、νが到達できる最小の包含的値である。
−νmaxは、νが到達できる最大の包含的値である。
νからのデコード値は、
であり、次式で与えられる。
ここで、
は、νのデコードされた近似値である。
（コンテキスト方法との統合：LinearQuantizerCodec）
線形の量子化は、本明細書の２．１節の中で説明されたコーディングコンテキスト方法で定義されたように、コーデックとして使用できる。この方法を用いて、線形の量子化を記述のどのようなサブツリーの中でも、望ましい単純なタイプの数値データのリーフに対して適用できる。
線形の量子化は、本明細書の２．１節の中で説明されたコーディングコンテキスト方法で定義されたように、コーデックとして使用できる。この方法を用いて、線形の量子化を記述のどのようなサブツリーの中でも、望ましい単純なタイプの数値データのリーフに対して適用できる。
このように使用することにより、線形の量子化コーデックに関連するコーディングコンテキスト方法は、ＭＰＥＧ−４のＢＩＦＳ［３］の中で使用されるQuantizationParameterノードとして動作する。
（適用可能な単純なタイプに対する制約）
本明細書の２．１節のコーデックに対する定義によれば、このコーデックはメモリ無しのコーデックであり、これは全ての極小の数値及び極小でない数値の単純なタイプに適用できる。そのＸＭＬスキーマの基本タイプは、フロート、ダブル又はデシマルである。
本明細書の２．１節のコーデックに対する定義によれば、このコーデックはメモリ無しのコーデックであり、これは全ての極小の数値及び極小でない数値の単純なタイプに適用できる。そのＸＭＬスキーマの基本タイプは、フロート、ダブル又はデシマルである。
（コーデックの外部パラメータ）
線形量子化器のコーデックは、下記の３つの必須のパラメータである
−上記のnbits変数であるbitSizeと、
−上記のνmin変数であるminInclusiveと、
−上記のνmax変数であるmaxInclusiveと
を必要とする。
線形量子化器のコーデックは、下記の３つの必須のパラメータである
−上記のnbits変数であるbitSizeと、
−上記のνmin変数であるminInclusiveと、
−上記のνmax変数であるmaxInclusiveと
を必要とする。
（コーデックのスキーマの定義）
線形量子化のコーデックは、抽象的なCodecTypeタイプ（２．１節を参照のこと）に基づいて、コーディングコンテキストのnamespaceのＵＲＬ xmlns:cc=http://www.mpeg7.org/2001/BiMCodingにおける補遺５の中で与えられたスキーマで定義されたタイプLinearQuantizerCodecTypeの新しいコーデックである。
線形量子化のコーデックは、抽象的なCodecTypeタイプ（２．１節を参照のこと）に基づいて、コーディングコンテキストのnamespaceのＵＲＬ xmlns:cc=http://www.mpeg7.org/2001/BiMCodingにおける補遺５の中で与えられたスキーマで定義されたタイプLinearQuantizerCodecTypeの新しいコーデックである。
（コード化（情報提供））
値νの数値データのリーフは、nbitsビットの符号のない整数νqにより下記の式のよう
にコード化される。
値νの数値データのリーフは、nbitsビットの符号のない整数νqにより下記の式のよう
にコード化される。
（デコーディング）
nbitsビットでコード化された符号のない整数νqは、下記の式のように、
としてデコードされるべきである。
nbitsビットでコード化された符号のない整数νqは、下記の式のように、
（実施例（情報提供））
補遺６で示された実施例は、記述における線形量子化器の定義を示す。
補遺６で示された実施例は、記述における線形量子化器の定義を示す。
２．２．２ 統計的な圧縮
伝統的な損失のない統計的な圧縮アルゴリズムは、コーディングコンテキスト方法（２．１節を参照）の中で定義されたようなコーデックとして使用できる。この方法を用いて、どの記述のサブツリーの中でも、望ましい単純なタイプのデータリーフを効率的に圧縮できる。
このコーデックは、特に記述が多くの反復的な又は同様のストリングを含む場合には、ビットストリームの大きさを著しく減少させるために有用である。
伝統的な損失のない統計的な圧縮アルゴリズムは、コーディングコンテキスト方法（２．１節を参照）の中で定義されたようなコーデックとして使用できる。この方法を用いて、どの記述のサブツリーの中でも、望ましい単純なタイプのデータリーフを効率的に圧縮できる。
このコーデックは、特に記述が多くの反復的な又は同様のストリングを含む場合には、ビットストリームの大きさを著しく減少させるために有用である。
（定義）
（Zip又はGZipなどの）伝統的な損失のない統計的な圧縮アルゴリズムをＢｉＭの中で用いて、記述の任意のリーフを圧縮することができる。
しかし、大抵の場合、データリーフが１０文字よりも少ない短いストリングの場合には、通常の統計的な圧縮アルゴリズムは大きなルックアヘッドバッファ（lookahead buffer）を必要とするため、このアルゴリズムの性能は良くない。
最適な圧縮比を実現するために、文書のリーフは圧縮する前に、小さいバッファにバッファする必要がある。次の節は、根本的な損失のない統計的な圧縮アルゴリズムに依存するそのようなバッファ付き統計的コーダ（a buffered statistical coder）を定義する。
（Zip又はGZipなどの）伝統的な損失のない統計的な圧縮アルゴリズムをＢｉＭの中で用いて、記述の任意のリーフを圧縮することができる。
しかし、大抵の場合、データリーフが１０文字よりも少ない短いストリングの場合には、通常の統計的な圧縮アルゴリズムは大きなルックアヘッドバッファ（lookahead buffer）を必要とするため、このアルゴリズムの性能は良くない。
最適な圧縮比を実現するために、文書のリーフは圧縮する前に、小さいバッファにバッファする必要がある。次の節は、根本的な損失のない統計的な圧縮アルゴリズムに依存するそのようなバッファ付き統計的コーダ（a buffered statistical coder）を定義する。
（バッファ付き統計的コーダの定義）
バッファ付き統計的コーダは、一般的な下記の基本的な方法である、
−ストリームの圧縮又は解凍動作を初期化するinitialize_stream()と、
−コーダの現在の統計的なモデルをリセットするreset_model()と、
−入力の解凍されたバイトを取り、圧縮ストリームの中に入れるfeed_input_bytes()と、
−既に処理された入力バイトを圧縮し、対応する圧縮された出力バイトを出すことによって、圧縮ストリームをフラッシュするflush_output_bytes()と、
−指定された量の圧縮された入力バイトを取り、対応する解凍された出力バイトを出すことによってそれらをデコードするdecompress_input_bytes()と
を必ず含む根本的な統計的コーダに依存する。
バッファ付きコーデックは、bufferSizeのバイト長、すなわちバイトアレイバッファ（byte array buffer）のＦＩＦＯ構造を有する。
エンコーダ側から見ると、bufferSize値はフラッシングの前にエンコーダがどの位の入力バイトを処理できるかを示す。デコーダ側からすると、これは根本的な統計的コーダのＡＰＩを通してビットストリームをデコードするために必要な最小のバッファ寸法である。
このバッファはfillingLevel変数も有する。この変数は、バッファのバイトにおける実際の充填レベルを含む。
バッファ付き統計的コーダは、一般的な下記の基本的な方法である、
−ストリームの圧縮又は解凍動作を初期化するinitialize_stream()と、
−コーダの現在の統計的なモデルをリセットするreset_model()と、
−入力の解凍されたバイトを取り、圧縮ストリームの中に入れるfeed_input_bytes()と、
−既に処理された入力バイトを圧縮し、対応する圧縮された出力バイトを出すことによって、圧縮ストリームをフラッシュするflush_output_bytes()と、
−指定された量の圧縮された入力バイトを取り、対応する解凍された出力バイトを出すことによってそれらをデコードするdecompress_input_bytes()と
を必ず含む根本的な統計的コーダに依存する。
バッファ付きコーデックは、bufferSizeのバイト長、すなわちバイトアレイバッファ（byte array buffer）のＦＩＦＯ構造を有する。
エンコーダ側から見ると、bufferSize値はフラッシングの前にエンコーダがどの位の入力バイトを処理できるかを示す。デコーダ側からすると、これは根本的な統計的コーダのＡＰＩを通してビットストリームをデコードするために必要な最小のバッファ寸法である。
このバッファはfillingLevel変数も有する。この変数は、バッファのバイトにおける実際の充填レベルを含む。
（統計的なコーダとしてのZLib ＡＰＩの使用）
GZip圧縮方式の中で使用されるZLibの公開ライブラリのＡＰＩ［４］は、文書リーフに対して統計的圧縮を行うための効率的で有用なＡＰＩを提供する。
GZip圧縮方式の中で使用されるZLibの公開ライブラリのＡＰＩ［４］は、文書リーフに対して統計的圧縮を行うための効率的で有用なＡＰＩを提供する。
ZLib ＡＰＩは、下記のマッピングを用いて前の一般的な方法を実行する。
−initialize_stream()は、Z_DEFAULT_COMPRESSIONの効率値のパラメータを用いて、ZLibのinflateInit()又はdeflateInit()機能によってマッピングすることができる。
−reset_model()は、ZLibのinflateEnd()又はdeflateEnd()コール及び次のinitialize_stream()コールを用いてマッピングすることができる。
−feed_input_bytes()は、Z_NO_FLUSHパラメータを用いてZLibのdeflate()方法によりマッピングすることができる。
−flush_output_bytes()は、Z_SYNC_FLUSHパラメータを用いてZLibのdeflate()方法によりマッピングすることができる。
−decompress_input_bytes()は、ZLibのdeflate()方法によりマッピングすることができる。
−initialize_stream()は、Z_DEFAULT_COMPRESSIONの効率値のパラメータを用いて、ZLibのinflateInit()又はdeflateInit()機能によってマッピングすることができる。
−reset_model()は、ZLibのinflateEnd()又はdeflateEnd()コール及び次のinitialize_stream()コールを用いてマッピングすることができる。
−feed_input_bytes()は、Z_NO_FLUSHパラメータを用いてZLibのdeflate()方法によりマッピングすることができる。
−flush_output_bytes()は、Z_SYNC_FLUSHパラメータを用いてZLibのdeflate()方法によりマッピングすることができる。
−decompress_input_bytes()は、ZLibのdeflate()方法によりマッピングすることができる。
ZLibのバッファ付きコーデックは、［４］で定義されたように、Z_DEFAULT_COMPRESSIONの効率値を用いて初期化されるべきである。このことは、メモリのフットプリント（footprint）についての要求事項と圧縮効率との間の良いトレードオフになる。
（コンテキスト方法との統合：ZlibCodec）
この節では、コーディングコンテキスト方法の中で定義された、ZLib ＡＰＩに依存する、上記のバッファ付き統計的コーダの統合について説明する。
この節では、コーディングコンテキスト方法の中で定義された、ZLib ＡＰＩに依存する、上記のバッファ付き統計的コーダの統合について説明する。
（適用可能な単純なタイプに対する制約）
２．１節のコーデックに対する定義によれば、このコーデックはコンテキスト式コーデックであり、これは全ての極小のストリングタイプ及び極小でないストリングタイプに適用できる。ZLibCodecは、［１］の中で説明したように、文書のリーフの根本をなす基本的なコード化に依存している。例えば、intリーフは３２ビットの符号のない整数によりコード化され、stringリーフはＵＴＦ−８のコード化により、float及びdoubleリーフはＩＥＥＥ７５４形式でコード化される。このため、ZLibCodecは、コード化されたリーフを圧縮できる。
２．１節のコーデックに対する定義によれば、このコーデックはコンテキスト式コーデックであり、これは全ての極小のストリングタイプ及び極小でないストリングタイプに適用できる。ZLibCodecは、［１］の中で説明したように、文書のリーフの根本をなす基本的なコード化に依存している。例えば、intリーフは３２ビットの符号のない整数によりコード化され、stringリーフはＵＴＦ−８のコード化により、float及びdoubleリーフはＩＥＥＥ７５４形式でコード化される。このため、ZLibCodecは、コード化されたリーフを圧縮できる。
（コーデックの外部パラメータ）
バッファ付きのZLibコーデックは、根本的なZLibの効率がZ_DEFAULT_COMPRESSIONに設定され、bufferSizeパラメータがデコーダ側からは必要とはされないため、どのような外部のパラメータも必要としない。
バッファ付きのZLibコーデックは、根本的なZLibの効率がZ_DEFAULT_COMPRESSIONに設定され、bufferSizeパラメータがデコーダ側からは必要とはされないため、どのような外部のパラメータも必要としない。
（コーデックのスキーマの定義）
このZLibコーデックは、抽象的なCodecTypeタイプ（２．１節を参照のこと）に基づいて、補遺７のコーディングコンテキストのnamespaceの中で説明されたスキーマによって定義されたZLibCodecTypeタイプの新しいコーデックである。
このZLibコーデックは、抽象的なCodecTypeタイプ（２．１節を参照のこと）に基づいて、補遺７のコーディングコンテキストのnamespaceの中で説明されたスキーマによって定義されたZLibCodecTypeタイプの新しいコーデックである。
（コード化（情報提供））
コーデックの活性化又はインスタンシエーションにおいては、
−ＦＩＦＯのバッファ構造はクリアであると想定され、そのfillingLevelは０に設定される。
−グローバル変数referencable_chunkは０に初期化される。
このreferencable_chunkは、エンコーダが保持しなければならない参照可能なビットのチャンクを含むべきである。その理由は、その値がコード化工程の間に後で知られるからである。通信関数signal_reference_chunk_known()は、このチャンクが知られた場合には呼び出すことができる。
全てのゼロでないチャンクのバイトの大きさは、［１］で定義されたように、標準的な符号無しの無限の整数４＋１コーディング（infinite integer 4+1 coding）を用いて、flush_output_bytes()呼出しの間にチャンク自身の前に書き込まれるべきである。
入力リーフ（input leaf）は、その基本のタイプに関連したテキストのリーフのコード化された値である。このリーフのバイトの長さは、フィールドleaf.lengthによって与えられる。一例［１］を挙げれば、stringリーフは、ストリングのバイトの大きさが前に来る（無限整数のコーディング［１］を用いてコード化された）ＵＴＦ−８のコードであり、doubleリーフは、対応するＩＥＥＥ７５４規格の６４ビット値である。
コーデックの活性化又はインスタンシエーションにおいては、
−ＦＩＦＯのバッファ構造はクリアであると想定され、そのfillingLevelは０に設定される。
−グローバル変数referencable_chunkは０に初期化される。
このreferencable_chunkは、エンコーダが保持しなければならない参照可能なビットのチャンクを含むべきである。その理由は、その値がコード化工程の間に後で知られるからである。通信関数signal_reference_chunk_known()は、このチャンクが知られた場合には呼び出すことができる。
全てのゼロでないチャンクのバイトの大きさは、［１］で定義されたように、標準的な符号無しの無限の整数４＋１コーディング（infinite integer 4+1 coding）を用いて、flush_output_bytes()呼出しの間にチャンク自身の前に書き込まれるべきである。
入力リーフ（input leaf）は、その基本のタイプに関連したテキストのリーフのコード化された値である。このリーフのバイトの長さは、フィールドleaf.lengthによって与えられる。一例［１］を挙げれば、stringリーフは、ストリングのバイトの大きさが前に来る（無限整数のコーディング［１］を用いてコード化された）ＵＴＦ−８のコードであり、doubleリーフは、対応するＩＥＥＥ７５４規格の６４ビット値である。
下記のencode_leaf関数は、出力バイトのチャンク内のリーフをコード化することができる。
chunk encode_leaf(chunk leaf) [
while (leaf is not empty) [
if (fillingLevel + leaf.length < bufferSize) [
feed_input_bytes(leaf,leaf.length)
fillingLevel = fillingLevel + leaf.length
if (referencable_chunk is null) [
referencable_chunk = new chunk
return referencable_chunk
] else [
return nil_size_chunk
]
] else [
remaining_bytes = bufferSize - fillingLevel - leaf.length
feed_input_bytes(leaf,remaining_bytes)
referencable_chunk = flush_output_bytes()
signal_reference_chunk_known()
fillingLevel = 0
leaf = leaf.remove_beginning_bytes(remaining_bytes)
referencable_chunk = null
]
]
]
chunk encode_leaf(chunk leaf) [
while (leaf is not empty) [
if (fillingLevel + leaf.length < bufferSize) [
feed_input_bytes(leaf,leaf.length)
fillingLevel = fillingLevel + leaf.length
if (referencable_chunk is null) [
referencable_chunk = new chunk
return referencable_chunk
] else [
return nil_size_chunk
]
] else [
remaining_bytes = bufferSize - fillingLevel - leaf.length
feed_input_bytes(leaf,remaining_bytes)
referencable_chunk = flush_output_bytes()
signal_reference_chunk_known()
fillingLevel = 0
leaf = leaf.remove_beginning_bytes(remaining_bytes)
referencable_chunk = null
]
]
]
（デコーディング）
string_fifoをストリングＦＩＦＯとする。
下記の方法get()及びput()は、それぞれ、ＦＩＦＯから要素を取り出し、ＦＩＦＯに要素を置く。
ＦＩＦＯが空かどうかを知る方法はEmpty()信号である。
subをサブストリングを取り出す関数とする。
concatを連結関数とする。
getData()を、リーフからのde-gzipデータを保持するchar[]を戻す関数とする。
split(char[] , char sep, Fifo, char[] remainder)を各セパレータ「sep」において文字のアレイを分割し、この分割されたストリング要素をＦＩＦＯに保管し残りを戻す方法とする。
[
if (data==null) return;
int BEGIN=0;
for (int I=0;I<data.length;I++)
[
if (data[I]==sep)
[
char[] str= concat(remainder, sub(data,BEGIN,I));
put(string_fifo, str);
BEGIN=I+1;
]
]
if(BEGIN!=data.length)
[
//there's a remainder.
remainder = sub(data,BEGIN,data.length);
]
]
String decode()
[
if (isEmpty(string_fifo)
[
data = getData();
split(data,0x00,string_fifo,remainder);
]
return get(string_fifo);
]
初期化されたとき、string_fifoは空である。
コーデックの活性化又はインスタンシエーションにおいては、
−ＦＩＦＯの構造はクリアであると想定され、そのnumberOfLeavesは０に設定される。
−変数first_chunkは真に設定される。
セパレータのバイトを0x00とする。
下記のdecode_leaf関数は、ビットストリームからの圧縮されたリーフをデコードすることができる。
string decode_leaf() [
if (numberOfLeaves == 0) [
read_and_decompressed_byte()
numberOfLeaves = count_number_of_leave_in_buffer()
] else [
]
]
string_fifoをストリングＦＩＦＯとする。
下記の方法get()及びput()は、それぞれ、ＦＩＦＯから要素を取り出し、ＦＩＦＯに要素を置く。
ＦＩＦＯが空かどうかを知る方法はEmpty()信号である。
subをサブストリングを取り出す関数とする。
concatを連結関数とする。
getData()を、リーフからのde-gzipデータを保持するchar[]を戻す関数とする。
split(char[] , char sep, Fifo, char[] remainder)を各セパレータ「sep」において文字のアレイを分割し、この分割されたストリング要素をＦＩＦＯに保管し残りを戻す方法とする。
[
if (data==null) return;
int BEGIN=0;
for (int I=0;I<data.length;I++)
[
if (data[I]==sep)
[
char[] str= concat(remainder, sub(data,BEGIN,I));
put(string_fifo, str);
BEGIN=I+1;
]
]
if(BEGIN!=data.length)
[
//there's a remainder.
remainder = sub(data,BEGIN,data.length);
]
]
String decode()
[
if (isEmpty(string_fifo)
[
data = getData();
split(data,0x00,string_fifo,remainder);
]
return get(string_fifo);
]
初期化されたとき、string_fifoは空である。
コーデックの活性化又はインスタンシエーションにおいては、
−ＦＩＦＯの構造はクリアであると想定され、そのnumberOfLeavesは０に設定される。
−変数first_chunkは真に設定される。
セパレータのバイトを0x00とする。
下記のdecode_leaf関数は、ビットストリームからの圧縮されたリーフをデコードすることができる。
string decode_leaf() [
if (numberOfLeaves == 0) [
read_and_decompressed_byte()
numberOfLeaves = count_number_of_leave_in_buffer()
] else [
]
]
デコーディングは、下記により定義される。
１．ＦＩＦＯが空の場合には、
ａ．コード化データをデコードする。
ｂ．0x00により分離された全ての要素をＦＩＦＯの中にスタックする。
ｃ．最後の文字が0x00でない場合は、未完成のストリングを一時的に保管する。
ｄ．「last_element」が空でない場合は、それをＦＩＦＯ内の第１の要素の先頭に挿入する。
ｅ．このラウンドの未完成のストリングをlast_elementの中に入れる。
ｆ．第１の要素を取り除き戻す。
１．ＦＩＦＯが空の場合には、
ａ．コード化データをデコードする。
ｂ．0x00により分離された全ての要素をＦＩＦＯの中にスタックする。
ｃ．最後の文字が0x00でない場合は、未完成のストリングを一時的に保管する。
ｄ．「last_element」が空でない場合は、それをＦＩＦＯ内の第１の要素の先頭に挿入する。
ｅ．このラウンドの未完成のストリングをlast_elementの中に入れる。
ｆ．第１の要素を取り除き戻す。
２．ＦＩＦＯが空でない場合には、第１の要素を取り除き戻す。
これは、「ＦＩＦＯは空ではない」及び「現在のリーフにはコード化されたデータはない」と言うのに等しい。
これは、「ＦＩＦＯは空ではない」及び「現在のリーフにはコード化されたデータはない」と言うのに等しい。
（実施例（情報提供））
補遺８で与えられた説明は、string及びanyURIタイプでマッピングされたZLibCodecTypeのコーデックを使用する場合の例である。
補遺８で与えられた説明は、string及びanyURIタイプでマッピングされたZLibCodecTypeのコーデックを使用する場合の例である。
（結果（情報提供））
下記の図面は、記述（string及びanyURIのＸＭＬスキーマの基本のタイプから得られた記述）のテキストのリーフを圧縮するためにZLibCodecを使用する場合の性能を示す。bufferSize＝２５６バイトのバッファは、コード化工程の間に使用された。使用されたファイルは、ＭＰＥＧ−７のＭＤＳサブグループにより提供された。
階層化ツリーのリーフの内容を圧縮するために、本発明に基づいて実行されたステップを、ここで手早く説明する。
下記の図面は、記述（string及びanyURIのＸＭＬスキーマの基本のタイプから得られた記述）のテキストのリーフを圧縮するためにZLibCodecを使用する場合の性能を示す。bufferSize＝２５６バイトのバッファは、コード化工程の間に使用された。使用されたファイルは、ＭＰＥＧ−７のＭＤＳサブグループにより提供された。
ステップ１は、圧縮コード化技術をあるコンテントタイプに対応付ける工程から成る。例えば、線形の量子化を、浮動小数点の値に対応付けることができる。
ステップ２では、あるサブツリーが検討されたＸＭＬ文書の構造に対応する階層化ツリーの中で識別される。
ステップ３は、圧縮コード化技術を識別されたサブツリーに割り当てる工程から成る。
そして、ステップ４は、圧縮コード化技術を実行しているコーデックが起動されているかどうかを検査する工程から成る。起動されていない場合には、サブツリーのリーフの圧縮（ステップ５）は行われない。
起動されている場合には、本発明は、その内容が（ステップ１において）圧縮コード化技術に対応付けられたコンテントタイプであるような、サブツリーのリーフの内容の圧縮を実行する（ステップ６）。
［補遺１］
［補遺２］
［補遺３］
［補遺４］
［補遺５］
［補遺６］
［補遺７］
［補遺８］
［補遺９］
Claims (15)
- マルチメディア信号を記述する階層化ツリーを圧縮する方法であって、
該ツリーが、コンテントタイプと呼ばれる少なくとも２つの明確な特徴を有するデータに対応付けることができる、ノードとリーフとを含み、コンピュータが、前記リーフの少なくともいくつかのコンテントタイプに対応したデータ圧縮を実行するものであり、
前記コンピュータが圧縮コード化技術をあるコンテントタイプに対応付けるステップと、
前記コンピュータが少なくとも１つのサブツリーを識別するステップと、
前記コンピュータが該サブツリーに対して圧縮コード化技術の１つを割り当てるステップと、
前記コンピュータが、前記圧縮コード化技術に対応した前記コンテントタイプをもつ前記サブツリーのリーフに対してのみ、該サブツリーに割り当てられた前記圧縮コード化技術を実行するステップであって、前記サブツリーの他のリーフはどのような圧縮コード化も受けることはないものである、実行するステップと
を含んでなる方法。 - 前記圧縮コード化技術は、あるコンテントタイプのパラメータ記述により指定されたものである請求項１に記載の方法。
- 前記サブツリーがＭＰＥＧ７規格によるＢｉＭ（２進ＭＰＥＧ）タイプである請求項１または２に記載の方法。
- 前記コンテントタイプが、フロート、ダブル又はデシマルであり、前記ＭＰＥＧ７規格に従うタイプである請求項３に記載の方法。
- 前記圧縮コード化技術の１つが線形の量子化コーデックを使用する請求項１から請求項４のいずれかに記載の方法。
- 前記圧縮コード化技術の１つが統計的圧縮コーデックを使用する請求項１から請求項５のいずれかに記載の方法。
- 前記アルゴリズムがGZipタイプである請求項６に記載の方法。
- 前記アルゴリズムが少なくとも２つのリーフのデータに対応するデータの集合に対して同時に実行されるものである請求項６及び請求項７のいずれかに記載の方法。
- 前記サブツリーがＸＭＬ（拡張マークアップ言語）タイプの文書の構造を示すものである請求項１から請求項８のいずれかに記載の方法。
- デコーダが前記サブツリーをスキップできるようにする幾つかの情報を含む少なくとも１つのコーディングコンテキストを、前記コンピュータによって前記サブツリーに関連付けるステップをさらに含む請求項１から請求項９のいずれかに記載の方法。
- 前記幾つかの情報が、
使用された圧縮コード化技術を示す１つの情報、及び／又は、
対応するサブツリーが圧縮されているかどうかを示す１つの情報、及び／又は、
対応するサブツリーがスキップ可能かどうかを示す１つの情報、及び／又は、
使用された圧縮コード化技術の少なくとも１つのパラメータが修正されているかどうかを示す１つの情報
を含むものである請求項１０に記載の方法。 - 請求項１から請求項１１のいずれかの方法に従って圧縮されたマルチメディア信号をデコーディングする方法であって、
コンピュータが、前記信号によって送られた少なくとも１つのコーディングコンテキストに従って、少なくとも１つのコンテントタイプを定義する現在のデコーディングコンテキストをリフレッシュするステップと、
前記コンピュータが、前記コンテントタイプのコンテントを含むリーフに対して、該コンテントタイプに対応した圧縮デコーディング技術を実行するステップと
を含む方法。 - 請求項１から請求項１２のいずれかの方法によって圧縮された階層化ツリーを表すデータ構造であって、前記ツリーが、コンテントタイプと呼ばれる少なくとも２つの明確な特徴を有するデータに対応付けることができる、ノードとリーフとを含み、前記ツリーが、少なくとも１つのコンテントタイプのためのある圧縮コード化技術に割り当てられる少なくとも１つのサブツリーも含むものであり、少なくとも１つのフィールドを含む前記データ構造は、
前記圧縮コード化技術に対応付けられる前記コンテントタイプのコンテントを有し、前記サブツリーの前記リーフが前記圧縮コード化を受けるものである、前記サブツリーの前記リーフと、
前記圧縮コード化技術に対応付けられる前記コンテントタイプのコンテントを有しておらず、どのような圧縮コード化を受けないものである、前記サブツリーの他のリーフと
を含んでなるデータ構造。 - 前記データ構造は、
前記少なくとも１つのコンテントタイプのために前記サブツリーに割り当てられる前記圧縮コード化技術を示す少なくとも１つのフィールドと、
前記サブツリーのために前記圧縮コード化技術に対応付けられる前記少なくとも１つのコンテントタイプを示す少なくとも１つのフィールドと
をさらに含むものである請求項１３に記載のデータ構造。 - 前記データ構造は、前記コンテントタイプの少なくとも１つのために前記サブツリーに割り当てられる前記圧縮コード化技術の少なくとも１つのパラメータを示す少なくとも１つのフィールドをさらに含むものである請求項１４に記載のデータ構造。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP01460047.2 | 2001-07-13 | ||
| EP01460047A EP1276324B1 (en) | 2001-07-13 | 2001-07-13 | Method for compressing a hierarchical tree, corresponding signal and method for decoding a signal |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003513248A Division JP2004535034A (ja) | 2001-07-13 | 2002-07-12 | 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009043267A JP2009043267A (ja) | 2009-02-26 |
| JP4884438B2 true JP4884438B2 (ja) | 2012-02-29 |
Family
ID=8183367
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003513248A Withdrawn JP2004535034A (ja) | 2001-07-13 | 2002-07-12 | 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 |
| JP2008215480A Expired - Fee Related JP4884438B2 (ja) | 2001-07-13 | 2008-08-25 | 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003513248A Withdrawn JP2004535034A (ja) | 2001-07-13 | 2002-07-12 | 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 |
Country Status (13)
| Country | Link |
|---|---|
| US (1) | US20040267710A1 (ja) |
| EP (1) | EP1276324B1 (ja) |
| JP (2) | JP2004535034A (ja) |
| KR (1) | KR20040036897A (ja) |
| CN (1) | CN100493187C (ja) |
| AT (1) | ATE341901T1 (ja) |
| AU (1) | AU2002330359A1 (ja) |
| BR (1) | BRPI0211106B8 (ja) |
| CA (1) | CA2452639C (ja) |
| DE (1) | DE60123596T2 (ja) |
| ES (1) | ES2272429T3 (ja) |
| MX (1) | MXPA04000219A (ja) |
| WO (1) | WO2003007614A2 (ja) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7126955B2 (en) | 2003-01-29 | 2006-10-24 | F5 Networks, Inc. | Architecture for efficient utilization and optimum performance of a network |
| US8159940B1 (en) | 2004-11-11 | 2012-04-17 | F5 Networks, Inc. | Obtaining high availability using TCP proxy devices |
| KR100660028B1 (ko) * | 2005-02-23 | 2006-12-20 | 인천대학교 산학협력단 | 데이터베이스 개념 구조에 기반한 ｘｍｌ 트리의 색인 및질의 방법 |
| US8111694B2 (en) | 2005-03-23 | 2012-02-07 | Nokia Corporation | Implicit signaling for split-toi for service guide |
| CN101223699A (zh) * | 2005-07-21 | 2008-07-16 | 易斯普维 | 压缩与解压缩结构化文档的方法和装置 |
| US7783781B1 (en) | 2005-08-05 | 2010-08-24 | F5 Networks, Inc. | Adaptive compression |
| US8275909B1 (en) | 2005-12-07 | 2012-09-25 | F5 Networks, Inc. | Adaptive compression |
| US7882084B1 (en) | 2005-12-30 | 2011-02-01 | F5 Networks, Inc. | Compression of data transmitted over a network |
| US8417833B1 (en) | 2006-11-29 | 2013-04-09 | F5 Networks, Inc. | Metacodec for optimizing network data compression based on comparison of write and read rates |
| CN101584120B (zh) * | 2007-01-19 | 2013-01-09 | 三菱电机株式会社 | 表装置、可变长度编码装置、可变长度解码装置 |
| JP4360428B2 (ja) | 2007-07-19 | 2009-11-11 | ソニー株式会社 | 記録装置、記録方法、コンピュータプログラムおよび記録媒体 |
| KR101323439B1 (ko) | 2008-11-12 | 2013-10-29 | 보드 오브 트러스티스 오브 더 리랜드 스탠포드 주니어 유니버시티 | 특징 디스크립터를 표현하고 식별하는 방법, 장치 및 컴퓨터 판독가능 저장 매체 |
| CN101741708B (zh) * | 2008-11-13 | 2012-11-21 | 华为技术有限公司 | 一种存储数据的方法和装置 |
| US8818024B2 (en) | 2009-03-12 | 2014-08-26 | Nokia Corporation | Method, apparatus, and computer program product for object tracking |
| CN101557399A (zh) * | 2009-05-20 | 2009-10-14 | 深圳市汇海科技开发有限公司 | 一种xmpp协议传输数据压缩与解压缩方法 |
| US8687891B2 (en) | 2009-11-19 | 2014-04-01 | Stanford University | Method and apparatus for tracking and recognition with rotation invariant feature descriptors |
| US9002859B1 (en) | 2010-12-17 | 2015-04-07 | Moonshadow Mobile, Inc. | Systems and methods for high-speed searching and filtering of large datasets |
| WO2012097009A2 (en) | 2011-01-10 | 2012-07-19 | Ward Roy W | Systems and methods for high-speed searching and filtering of large datasets |
| EP2557752B1 (de) | 2011-08-11 | 2017-09-27 | Siemens Aktiengesellschaft | Verfahren und vorrichtung zum herstellen einer end-zu-end-kommunikation zwischen zwei netzwerken |
| US9171054B1 (en) | 2012-01-04 | 2015-10-27 | Moonshadow Mobile, Inc. | Systems and methods for high-speed searching and filtering of large datasets |
| US8990204B1 (en) | 2012-01-17 | 2015-03-24 | Roy W. Ward | Processing and storage of spatial data |
| US10521411B2 (en) | 2016-08-10 | 2019-12-31 | Moonshadow Mobile, Inc. | Systems, methods, and data structures for high-speed searching or filtering of large datasets |
| CN107092656B (zh) * | 2017-03-23 | 2019-12-03 | 中国科学院计算技术研究所 | 一种树状结构数据处理方法及系统 |
| US11379420B2 (en) * | 2019-03-08 | 2022-07-05 | Nvidia Corporation | Decompression techniques for processing compressed data suitable for artificial neural networks |
| CN113282776B (zh) * | 2021-07-12 | 2021-10-01 | 北京蔚领时代科技有限公司 | 用于图形引擎资源文件压缩的数据处理系统 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1995001677A1 (en) * | 1993-06-30 | 1995-01-12 | Codex, Inc. | Method and apparatus for encoding and decoding compressed data in data communication |
| WO1997034240A1 (en) * | 1996-03-15 | 1997-09-18 | University Of Massachusetts | Compact tree for storage and retrieval of structured hypermedia documents |
| EP0928070A3 (en) * | 1997-12-29 | 2000-11-08 | Phone.Com Inc. | Compression of documents with markup language that preserves syntactical structure |
| JP2000067348A (ja) * | 1998-08-24 | 2000-03-03 | Matsushita Electric Ind Co Ltd | 携帯電話機及び携帯電話機による緊急通報システム |
| JP4003854B2 (ja) * | 1998-09-28 | 2007-11-07 | 富士通株式会社 | データ圧縮装置及び復元装置並びにその方法 |
| GB9911099D0 (en) * | 1999-05-13 | 1999-07-14 | Euronet Uk Ltd | Compression/decompression method |
| FR2813743B1 (fr) * | 2000-09-06 | 2003-01-03 | Claude Seyrat | Procede de compression/decompression de documents structures |
| EP1223759A1 (en) * | 2001-01-08 | 2002-07-17 | Robert Bosch Gmbh | Method for providing an extension code for a binary description for multimedia data |
| FR2820563B1 (fr) * | 2001-02-02 | 2003-05-16 | Expway | Procede de compression/decompression d'un document structure |
-
2001
- 2001-07-13 EP EP01460047A patent/EP1276324B1/en not_active Expired - Lifetime
- 2001-07-13 ES ES01460047T patent/ES2272429T3/es not_active Expired - Lifetime
- 2001-07-13 AT AT01460047T patent/ATE341901T1/de not_active IP Right Cessation
- 2001-07-13 DE DE60123596T patent/DE60123596T2/de not_active Expired - Lifetime
-
2002
- 2002-07-12 WO PCT/EP2002/008667 patent/WO2003007614A2/en active Application Filing
- 2002-07-12 MX MXPA04000219A patent/MXPA04000219A/es active IP Right Grant
- 2002-07-12 JP JP2003513248A patent/JP2004535034A/ja not_active Withdrawn
- 2002-07-12 CA CA2452639A patent/CA2452639C/en not_active Expired - Fee Related
- 2002-07-12 CN CNB028140419A patent/CN100493187C/zh not_active Expired - Fee Related
- 2002-07-12 US US10/483,576 patent/US20040267710A1/en not_active Abandoned
- 2002-07-12 AU AU2002330359A patent/AU2002330359A1/en not_active Abandoned
- 2002-07-12 KR KR10-2004-7000437A patent/KR20040036897A/ko not_active Application Discontinuation
- 2002-07-12 BR BRPI0211106A patent/BRPI0211106B8/pt not_active IP Right Cessation
-
2008
- 2008-08-25 JP JP2008215480A patent/JP4884438B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| ATE341901T1 (de) | 2006-10-15 |
| CN1528091A (zh) | 2004-09-08 |
| MXPA04000219A (es) | 2005-04-19 |
| JP2004535034A (ja) | 2004-11-18 |
| BR0211106A (pt) | 2004-06-22 |
| EP1276324B1 (en) | 2006-10-04 |
| CA2452639C (en) | 2012-10-23 |
| DE60123596T2 (de) | 2007-08-16 |
| US20040267710A1 (en) | 2004-12-30 |
| ES2272429T3 (es) | 2007-05-01 |
| CN100493187C (zh) | 2009-05-27 |
| CA2452639A1 (en) | 2003-01-23 |
| DE60123596D1 (de) | 2006-11-16 |
| JP2009043267A (ja) | 2009-02-26 |
| BRPI0211106B8 (pt) | 2017-04-11 |
| EP1276324A1 (en) | 2003-01-15 |
| WO2003007614A3 (en) | 2003-10-16 |
| KR20040036897A (ko) | 2004-05-03 |
| WO2003007614A2 (en) | 2003-01-23 |
| BRPI0211106B1 (pt) | 2016-10-18 |
| AU2002330359A1 (en) | 2003-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4884438B2 (ja) | 階層化ツリーを圧縮する方法及び圧縮されたマルチメディア信号をデコーディングする方法 | |
| Collet et al. | Zstandard Compression and the application/zstd Media Type | |
| US6633242B2 (en) | Entropy coding using adaptable prefix codes | |
| JP2022526098A (ja) | エントロピコーディングにおいて等確率シンボルをハンドリングするための方法およびデバイス | |
| US6309424B1 (en) | Content independent data compression method and system | |
| US7492290B1 (en) | Alternative encoding for LZSS output | |
| US20150009051A1 (en) | Data Compression Systems and Methods | |
| US20030218554A1 (en) | Method and system for compressing and decompressing multiple independent blocks | |
| US20070234192A1 (en) | Encoding and distribution of schema for multimedia content descriptions | |
| US6225922B1 (en) | System and method for compressing data using adaptive field encoding | |
| EP1158420A1 (en) | Method for a description of audio-visual data content in a multimedia environment | |
| JPH07123407A (ja) | Ｈｄｔｖ復号化器 | |
| Gupta et al. | A review on different types of lossless data compression techniques | |
| US7571152B2 (en) | Method for compressing and decompressing structured documents | |
| US7930435B2 (en) | Hub and spoke compression | |
| JP4727669B2 (ja) | ＬＡＳｅＲ二進表現のポイントシーケンス符号化／復号化方法及び装置 | |
| US20080001790A1 (en) | Method and system for enhancing data compression | |
| Timmerer et al. | An evaluation of existing metadata compression and encoding technologies for MPEG-21 applications | |
| Fang et al. | Automatic generation of entropy coding programs using flavor | |
| Huang et al. | Lossless compression algorithm for multi-source sensor data research | |
| US6522270B1 (en) | Method of coding frequently occurring values | |
| Tyagi et al. | Implementation of Data Compression Algorithms | |
| Garba et al. | Analysing Forward Difference Scheme on Huffman to Encode and Decode Data Losslessly | |
| Timmerer et al. | AND ENCODING TECHNOLOGIES FOR MPEG-21 APPLICATIONS | |
| JP2009543243A (ja) | 構造化文書の圧縮のための方法と装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110121 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110420 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110425 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110523 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110526 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110603 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111111 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111206 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141216 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4884438 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |