JP2001526853A - データ符号化ネットワーク - Google Patents

Abstract

(57)【要約】 好ましい符号化ネットワークは、ベース−フィルタ−リソース(Base-Filter-Resource(BFR))システムと呼ばれるアーキテクチャを使用する。この手法は、フォーマット仕様圧縮の有利な点を、広範囲なデータフォーマットを提供する汎用圧縮ツールに統合する。ソースデータは共通データのブロックに分解され、各分解されたブロックは、それぞれ選択された圧縮アルゴリズムを用いて圧縮される。アルゴリズムは静的モデルから選ばれるか、または、分解されたブロックのデータに適応されうる。分解されたブロックは、エンコードデータファイルに結合される。デコードでは、上記処理とは逆の処理がなされる。

Description

【発明の詳細な説明】 データ符号化ネットワーク 発明の背景 高性能データ圧縮システムは、値を予測する能力を高めるデータのモデルを使 用し、これにより圧縮度が逆に高められることになる。最良のモデルは、特定の データフォーマットをサポートするための圧縮システムを構築することにより実 現する。特定のファイルの中のデータから粗モデルを誘導することを試みる代わ りに、フォーマットに固有の圧縮システムは、精密な予め定められたモデルを提 供することができる。モデルは、ファイルフォーマット構造そのものに限らず、 サンプルデータベースから集められた統計データをも利用することができる。 従来のフォーマットに固有の圧縮における試みは、多くのフォーマットに適合 する汎用法の開発よりも、僅かな固有のフォーマットに対する解を見出すことに 集中していた。作り出されたモデルは、通常極めて僅かな数のコンポーネントを 含むに過ぎない。大抵は赤、青および緑のピクセル値を持つイメージファイルの ようなデータの大部分が僅かなコンポーネントの中に含まれる時には、前記のモ デルで充分間に合う。しかし、多くのフォーマットは、多量のコンポーネントを 用いなければ最良のモデル化は不可能であり、従来のシステムは、このようなモ デルを構築またはエンコードするようには設計されていない。 発明の概要 本発明による好ましい符号化システムは、公知の技術のこれらの２つの問題を 解決する。システムは、広汎なフォーマットを扱うのに適合した汎用解法を提供 し、多数のコンポーネントを使用するモデルを効果的に扱う。システムは、多く のレベルで、すなわち、最高（インタフェース）レベルから最低（コア−エンコ ードアルゴリズム）レベルまでにおいて、新しいアプローチを使用する。符号化 ネットワークは、データを エンコードするための圧縮ネットワークと、データをデコードするための伸張ネ ットワークとを含む。 最高レベルでは、本発明による好ましい圧縮システムは、Ｂａｓｅ−Ｆｉｌｔ ｅｒ−Ｒｅｓｏｕｒｃｅ（ＢＦＲ）システムと呼ばれるアーキテクチャーを使用 する。このアプローチは、フォーマットに固有の圧縮の利点を、広汎のデータフ ォーマットに用いられる汎用圧縮ツールに統合する。前記システムは、そのそれ ぞれが例えばＥｘｃｅｌ ＸＬＳワークシート、またはＷｏｒｄ ＤＯＣファイ ルのためのような特定のデータフォーマットをサポートするフィルタを含む。ベ ースは、システムコントロールモジュールおよびすべてのフィルタにより用いら れるライブラリを含む。リソースは、一つ以上のフィルタにより使用されるが、 ベースの一部ではないルーチンを含む。エンコードされるべきデータのフォーマ ットに合致するフィルタが設けられる時には、フォーマットに固有の圧縮の利点 は、このデータに対して実現することができる。しかし、前記以外では、他の固 有でないデータ圧縮システム（ＰＫＺｉｐ、Ｓｔａｃｋｅｒ等のような）に類似 の性能を達成する“汎用的な”フィルタが用いられる。 次のレベルでは、システムは、ソースデータを個々のコンポーネント（要素） に分解するための方法を含むのが好ましい。“ストラクチャーフリッピング”と 呼ばれる基本アプローチは、フォーマット情報を圧縮モデルに変換するための鍵 を提供する。ストラクチャーフリッピングは、通常分離される類似のコンポーネ ントが同じグループに入れられるように、情報をファイルに再構築する。 この基礎の上に、下記のような多くのツールが設けられている。 ―分解ルーチンの作成を簡単にするための言語。 ―この方法を用いてソースデータを別個のコンポーネントに分解するためのツ ール。 ―サンプルデータベースの自動的な解析による個々のコンポーネント に対するモデルの作成のためのツール。 これらのツールは、広汎なファイルおよびデータタイプに対するフィルタに適 用することができる。 圧縮システムは、特定のフィルタおよびあるタイプのフィルタのためのカスタ マイズされたアレー（配列）変形器と呼ばれるツールを含むのが望ましい。これ らの技術は、特定のファイルタイプまたは幾つかのファイルタイプにより用いら れるあるデータ構造を、多くのデータベースフォーマットに見られるデータの２ 次元配列をエンコードするように、取り扱う。 システムの低レベルでは、下記を含むデータ配列をエンコードするための多く のメカニズムが存在するのが望ましい。 ―新しい低レベルエンコードアルゴリズム。 ―多数のトランスフォームとエンコードアルゴリズムを統合するための方法。 ―小さいデータブロックが効果的に符号化できるようにオーバーヘッドを除去 するための方法。 ―静的モデル（サンプルデータベースの統計的解析から求められた）および動 的モデル（特定のアレーの中でのデータに適用される）を各コンポーネントのエ ンコードに統合するための新しい方法。 ソースデータのエンコードの好ましい方法は、ソースデータの多数のブロック への分解を含む。分解されたブロックは、通常ソースデータフォーマット以外の フォーマットを持つ。特に、ソースデータからの類似のデータが集められ、それ ぞれのブロックにグループ分けされる。 各ブロックに対し、圧縮アルゴリズムは、多数の候補圧縮アルゴリズムから選 ばれ、ブロックに適用される。圧縮アルゴリズムは、該当ブロック中のデータの 量に基づいて決めることができる。さらに圧縮アルゴリズムは、カスタマイズさ れた変形の使用を含め、該当ブロックに適用することができる。アルゴリズムの 選択は、ソースデータのフォーマッ トから誘導される圧縮モデルにも基づくことができる。多数のブロックからの圧 縮されたデータは、次にエンコードデータに結合される。 符号化ネットワークは、また符号化されたデータをソースデータに戻すための 圧縮解除ネットワークをも含む。最初にデータが解読され、次に分解が反転され る。ロスのないシステムでは、得られたデータはソースデータと同じである。 本発明の実施形態は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードディスク、 またはその他の機械での読取りの可能な配付媒体上に、機械で読取りの可能なフ ォーマットで書き込まれた、機械で実行できる命令の形態を持つことが望ましい 。これらの命令は、圧縮および伸張ネットワークを実行するための一以上のプロ セスユニットにより実行される。 図面の簡単な説明 本発明の前述のおよびその他の目的、特徴ならびに長所は、本発明の下記の好 ましい実施形態の詳細な記述から、添付の図面に図示されるように、明らかであ り、図面においては、共通の部分には共通の記号が付されている。図面は、必ず しも厳密な縮尺を用いておらず、むしろ本発明の原理を示すために誇張されてい る。 図１は、代表的なデータ圧縮システムの高レベルブロック図である。 図２は、本発明によるＢＦＲシステムを用いた好ましいエンコーダのブロック 図である。 図３は、アレー符号器のフローチャートである。 図４は、図３の文字列符号器４０のブロック図である。 図５は、図３の浮動小数点符号器５０のブロック図である。 図６は、好ましい自動化された解析システムのフローチャートである。 図７は、整数符号器の高レベル状態を概観するフローチャートである。 図８は、整数符号器の中レベル状態を概観するフローチャートである。 好適な実施形態の説明 図１は、代表的なデータ圧縮システムの高レベルブロック図である。システム の主要な構成要素は、送信アプリケーション１、エンコーダ３、デコーダ５およ び受信アプリケーション７である。 送信アプリケーション１は、エンコーダ３によりエンコードされるソースデー タ２を提供する。送信アプリケーションは、ファイル保管、通信システム、又は 元のフォーマットよりも少ないバイトを使用するデータ表現することを必要とす る他のアプリケーションとなりうる。 エンコーダ３は、ソースデータ２を受信し、少ないバイトを用いてデータを表 現する為のデータ圧縮アルゴリズムを使用する。エンコーダ３の代表的な実現は 、汎用コンピュータ上で動作するソフトウエアとしてであるが、記載されるアル ゴリズムは特殊化されたハードウエア上でも実現できる。 エンコーダの出力は、エンコードされたデータ４であり、これはメモリに格納 されることができるか（この場合には、エンコードにより同じハードウエア中に より多くのソースデータを格納することができる）、又はデコーダ５に送られる （この場合には、転送チャネル帯域幅が限られている時には、高速に転送にされ るソースデータをエンコードする）。 デコーダ５は、エンコードデータ４を検索、又は受信し、データをエンコード する為に用いられたアルゴリズムを逆にしてソースデータをデコードデータ６と して再構築する。ロスのないシステムにおいては、デコードデータ６はソースデ ータと同一である。しかし、アプリケーションによっては、或る程度のデータの ロスは容認することができる。エンコーダ３を用いる場合のように、デコーダ５ は、汎用コンピュータにお いて動作するソフトウエアとして通常実現されるが、特殊化されたハードウエア において実現することができる。 受信アプリケーション７は、デコードデータ６を処理の為に受信する。 好ましい圧縮エンジンは、フィルタを基礎とするエンコーダとデコーダを有し 、これらは多数の送信アプリケーション１と受信アプリケーション７により利用 することができる。エンコードされたデータを格納／検索、又は送信／受信する アプリケーション１，７は、圧縮システムの一部ではないが、これらアプリケー ションは、利用可能な転送チャネルの帯域幅のようなシステムの状態によってエ ンコードおよびデコード動作を調整することができる。 次の記載は主としてエンコーダを対象とする。デコーダは、エンコーダの動作 の逆の動作を行うに過ぎず、従ってエンコーダの記述は、エンコード／デコード システム全体を記載するのに十分である。用語“ファイル”は、ソースデータの ブロックを記載するために用いられ、これは従来の用法に適合するが、クライア ントサーバーアプリケーションのデータ交換のようなデータブロックの他の多く のタイプに適用することもできる。 エンコーダ 図２は、本発明によるＢａｓｅ−Ｆｉｌｔｅｒ−Ｒｅｓｏｕｒｃｅ（ＢＦＲ） ネットワークを用いる好ましいエンコーダのブロック図である。エンコーダ３' は、特定のファイルフォーマットを提供する複数のフィルタ１０ａ，…，１０ｘ ，…，１０ｚの使用を基礎としている。例えば、一つのフィルタ１０ａは、ＤＢ Ｆデータベースフォーマットの幾つかのバージョン（変形）をサポートすること が考えられるのに対し、別のフィルタ１０ｚは、マイクロソフトのワードソフト ウエアプログラムにより用いられるＤＯＣフォーマットの幾つかのバージョンを サポートすることができる。個々のフィルタは、フィルタ選択システム２２にそ れぞれの選択規則１２を提供する。 フィルタ選択システム２２は、ソースデータ２を受信し、システムにインスト ールされたべてのフィルタ１０ａ，…，１０ｘ，…，１０ｚの選択規則１２ａ， …，１２ｘ，…，１２ｚをチェックして、ソースデータのフォーマットをその規 則の何れかがサポートするか否かを認める。フォーマットがサポートされない場 合には“汎用”システムが用いられ、Ｌｅｍｐｅｌ−Ｚｉｖ（ＬＺ）エンジンの ような他の汎用圧縮システムと同様の圧縮性能を提供する。本発明の特定の好ま しい実施形態では、汎用的な圧縮システムは、その教示が本明細書に参照として すべて取り入れられている１９９７年１１月１４日に出願された米国特許出願第 ０８／９７０，２２０号においてシンドラー（Ｍｒ．Ｓｃｈｉｎｄｌｅｒ）によ り記載されたＳＺＩＰエンジンを使用している。ネットワークの記述は、主とし てデータフォーマットをサポートするフィルタが首尾よく見出される状況を包含 する。 簡単に説明すれば、分解システム２４は、ソースデータ２を多数の分解された アレー２５に分解し、上記のアレーの各々は、ソースファイルの中の特定のコン ポーネントのすべてのインスタンスを含む。以下に更に詳述されている用語「ア レー(Array)」は、用語「配列(array)」の通常の用法と異なり、ネットワークに 特定の構造体のタイプを指すことを示す為にカタカナ（大文字）にされている。 ソースデータ２を分解する為に用いられるアルゴリズムは、以下に更に詳述され る「ストラクチャ（構造体）フリッピング」と呼ばれるネットワークの重要な構 成である。 ＢＦＲシステムは、アレー２５が配列符号器２８で符号化される時に用いられ る各アレー２５用モデルを確立する為に、自動化された解析システム（以下に詳 述されている）を使用する。場合によっては、カスタマイズされた配列変形器２ ６が最初に用いられると、更に良好な圧縮が得られる。自動化された解析システ ムにより生成されたモデルは、各コ ンポーネントアレー２５を個別に処理するが、カスタマイズされたルーチンは、 コンポーネント間の関係を利用することができる。 配列符号器２８は、静的モデル（すべてのデータベースに対して一定）と各特 定のアレー２５に対する動的調整の混合体を含む、数に依存するモデリングシス テムを用いるアレー２５をエンコードする。 フィルタ１０ｘは、エンコーダ３'の４つのセクションの各々をサポートする 為の構成要素を有する。ファイルフォーマット仕様により決まる選択規則１２ｘ は、ファイル、又はファイルタイトルサフィスの先頭のバイト値のようなフィル タ１０ｘにより提供されたファイルを認識するのに必要な情報を含む。ファイル フォーマット仕様によって、さらに決まる分解命令１４は、ソースファイル中の 特定のコンポーネントのすべてのインスタンスを持つ、分解アレー２５にソース ファイルを分解するのに必要な情報を含む。カスタムコンポーネントモデル１６ は、ファイルフォーマット仕様およびサンプルデータベースの両者を参照するこ とにより構築される。それらは、コンポーネントアレー２５のいくつかを更に圧 縮し得るものにするように変形させる為に、コンポーネント間の関係を利用する ことができる。エンコード用パラメータ１８は、多数のサンプルデータベースか ら分解されたコンポーネントアレー２５を検査する自動化された解析システムに より生成される。エンコード用パラメータ１８は、配列符号器２８中の数に依存 するモデリングシステムをサポートする為に必要なデータを提供する。 フィルタ選択システム 好ましい圧縮システムは、フィルタ１０を追加、又は入れ替えることにより、 ユーザーが新しい、又は更新されたフォーマットをサポートすることのできる拡 張可能なアーキテクチャを使用する。上述のように、フィルタ１０は、一つ以上 のフォーマットをサポートすることができる。例えば「ロータス１２３バージョ ン４（ＬＯＴＵＳ １２３ｖ４」と 呼ばれるフィルタは、現行のＷＫ４フォーマットおよび以前のＷＫ３おょびＦＭ ３フォーマットのようなロータス１２３プログラムに関連するすべてのファイル フォーマットをサポートする。フィルタが新しいロータスＷＫ５フォーマットに 対して後に開発された時には、ユーザーは古ぃフィルタを、新しいフォーマット をサポートするフィルタに取り替え、また、このフィルタは古いフォーマットに 関する以前のフィルタに、後退的に適合できる。 マイクロソフトウィンドウズ（Ｗｉｎｄｏｗｓ）環境では、各フィルタは別個 の動的リンクライブラリ（ＤＬＬ）ファイルである。データテーブルのほかに、 フィルタは実行可能な符号を含む。あるファイルに対するフィルタが見出される と、動的にリンクされ、次にファイルをエンコードする為に呼び出される。エン コードされたデータのストリームは、何れのフィルタがデータをエンコードする のに用いられたかを示す識別子（ＩＤ）符号を含み、デコーダは対応するデコー ドフィルタを有する。 フィルタ選択システム２２を実施する為に、ベースモジュールは、現在インス トールされているファイルの登録を保持し、このファイルは、ＤＬＬのパスのほ かに、ソースファイルタイプを識別するのに必要なデータを含む。この登録は、 フィルタが追加されるか、又は取替えられるたびに更新される。識別データは、 ファイルタイトルサフィスのリスト、およびファイルの先頭近くのバイト値によ ってファイルを識別する方法を含むことができる。識別手順は、多くのフィルタ がインストールされた時にリストをチェックする時間を短縮するサーチツリー法 を用いる。この登録から、適切なフィルタ１０がフィルタタイプに対して呼び出 される。 マイクロソフトのＯＬＥ２のような混合ファイルフォーマットを扱う為に、一 つのフィルタが、混合ファイル中のサブファイル、又はストリームをエンコード する為に別のフィルタを呼び出す。例えばウィンワー ド（Ｗｉｎｗｏｒｄ）フィルタは、混合ドキュメントファイルの中に埋め込まれ ていたエクセル（Ｅｘｃｅｌ）データをエンコードする為のエクセル（Ｅｘｃｅ ｌ）フィルタを呼ぶことができる。 分解システム 上述のように、分解システム２４は、多数の分解されたアレー２５を作り出す 。各分解されたアレー２５は、ファイル中の特定のコンポーネントのすべてのイ ンスタンスを含む。各決められたされた構造体タイプの各メンバに対して、別個 のコンポーネントが作り出される。 実施例１ 例えば、ファイルフォーマット記述において決められたレコードの下記の記述 を考える。 セル値： フォーマットは、メモリとディスクスペースを節約する為に、ＲＫ番号と 呼ばれる内部番号タイプにおける番号を符号化する特別な方法を使用する。 レコーダデータ： オフセット ネーム サイズ 内容 ４ ｒｗ ２ 列番号 ６ ｃｏｌ ２ 行番号 ８ ｆｍｔ ２ セルフォーマットを含むレコードに対する インデックス １０ ｎｕｍ ４ 符号化された番号 分解システム２４は、このレコードの４つのコンポーネントの各々に対する分 解されたアレー２５を作り出す。ＲＫレコードが見出される度に、エントリが各 アレーに加えられる。分解されたアレー２５は、５つのレコードからのデータに よって示されるように、未処理ソースデータよりもさらに圧縮が可能である。 レコード 列 行 インデックス 数値 １ 0x0001 0x0002 0x0055 0x3ff1e100 ２ 0x0001 0x0003 0x005f 0x3ff1a300 ３ 0x0001 0x0004 0x0053 0x3ff1d000 ４ 0x0001 0x0006 0x005f 0x3ff1c400 ５ 0x0001 0x0007 0x005f 0x3ff1d300 ソースデータは、バイト合致アルゴリズムに対してほぼランダムに現れる（１ ６進法で示された）。 01 00 02 00 55 00 00 el fl 3f 01 00 03 00 5f 00 00 a3 fl 3f 01 00 04 00 53 00 00 d0 fl 3f 01 00 06 00 5f 00 00 c4 el fl 3f 01 00 07 00 5f 00 00 d3 fl 3f 各コンポーネントに対して最適化されたアルゴリズムを用いて４つの別個のア レー２５（列、行、インデックスおよび数値）として扱われる時には、データは 十分に圧縮されることができる。この手法は、本明細書中では、データを再配置 する方法のために、「構造体フリッピング」と称される。 データベース中の同一のコンポーネントのインスタンスを共にエンコードする ことは、一般的な圧縮技術であり、ファイルフォーマットは、しばしばこのよう なコンポーネントを識別するのに用いられる。しかし、従来技術では、この手法 は特定のファイルフォーマットの少しの主要なコンポーネントを分離することに 制限されており、又ファイルフォ−マット記述は、これらの主要なコンポーネン トを見つける為の技術としてのみ使用されてきた。本発明の好ましい実施形態に よれば、ファイルフォーマットは、実際に、圧縮モデルに変換され、次に、デー タを解析して各コンポーネントの符号化性能を最適化するために、この圧縮モデ ルが自動化されたシステムにインターフェースされる。この圧縮モデル は、カスタマイズされた配列変形器２６によって、通常、圧縮度を高められるが 、それは、システム全体の一構成に過ぎない。 好ましい手法が従来のシステムと異なる度合いは、それを実施する為に構築さ れた新しいツールに反映されている。この手法は、多数のアレ-２５を作り出す 。各アレー２５は、異なった圧縮モデルを必要とし、各々のエントリ数は、ファ イル毎に大輻に相違する。このような場合に効果的に動作するには、本発明の好 ましい実施形態は、オーバーヘッドの除去、数に依存する処理、および固定され た符号化アルゴリズムに代わる処理ネットワークの使用のような低レベル符号化 の取扱いに関する新しい手法を用いる。上記のこれらの技術は、分解システム２ ４の出力を取扱う為に好んで用いられる。 これらの実施上の特徴のすべては、高いレベルで統合されて、これにより、高 レベルの呼び出しは、システムを初期化し、データを分解し、アレーをエンコー ドするのに必要な動作のすべてを取扱うことができる。 本発明の特定の好ましい実施形態によれば、ファイル分解システム２４は、３ つのサブシステムを用いる。 FILE＿BUFFER 入力／出力インターフェース ARRAYS 単一コンポーネント用データを格納する PVSTRUCT 入力をアレーに分解し、又はデコードされたアレー を出力ストリームに書き込む 複数のFILE＿BUFFERルーチンは、FILE＿BUFFER構造体を用いるフレキシブルな 入力／出力インターフェースを提供し、したがって、入力／出力フォーマットに は無関係に同一の分解ルーチンのセットを用いることができる。これにより、圧 縮システムは、入力／出力フォーマットには無関係となる。ファイル分解システ ムは、好ましくは次の２つのファイルフォーマット、ＤＯＳおよびＯＬＥ２をサ ポートするが、通信ポートおよび他の入力／出力オプションに対するインターフ ェースのほかに、 他のファイルフォーマットに拡大できる。ＤＯＳファイルに対しては、論理スト リーム位置は、通常、未処理ファイル位置と同じである。ＯＬＥ２フォーマット は、コンテナファイル中のＯＬＥ２ストリームに追随する為に、広範な符号の層 を必要とする。 複数のARRAYルーチンが、初期化、データの追加、符号化およびデータのアレ ーを解放する処理を管理するシステムを提供する。各ARRAY構造体は、アレー２ ５へのエントリの数、アレーに現在割当てられているバッファのサイズ、および アレーをエンコードするのに役立つ情報のような、これらの処理を管理するのに 必要なデータおよび情報の一つのアレーを含む。 特にARRAY＿XX構造体は、コンポーネントからのすべてのデータを格納し、高 速で連続するデータへの読み／書きアクセス、データ用拡張可能バッファおよび モデルデータの格納をサポートするメカニズムを含む。この構造体によれば、ま た、単純なセットのツールによって、すべての割当て、分解および符号化機能を 取扱うことができる。＿XXの表現は、異なった整数ワードサイズ、文字列、およ び浮動小数点タイプのような異なったデータタイプに対してわずかに異なったAR RAY構造体が決められることを示すが、処理ルーチンの多くは、全てのバリエー ションに関して機能する。 複数のPVSTRUCTルーチンは、ファイルデータを分解する自動化されたシステム を編成する。エンコードの間、ルーチンは、FILE＿BUFFER構造体からデータを読 み出し、データをアレー２５に書込む。デコードの間、PVSTRUCTルーチンは、ア レー２５からデータを取り出し、FILE＿BUFFER構造体に書き込む。これらのルー チンは、ファイルフォーマットの高レベル記述を取り出し、分解されたデータの エンコードのほかに、分解の管理に関連するすべてのタスクを取扱う。また、フ ィルタ１０の多くは、FILE＿BUFFERを呼び出すカスタマイズされた分解ルーチン およびPVSTRUCTルーチンの使用に直接代わるARRAYルーチンを含む。しかし、分 解システム２４の一構成は、PVSTRUCTルーチンであり、この考察は主としてそれ らの動作に関するものである。 PVSTRUCT構造体は、ファイルフォーマットで決められたデータ構造体を分解し 符号化するのに必要なすべての情報を含む。このPVSTRUCT構造体は、通常、複数 のコンポーネントを含み、これにより、各コンポーネントに対する個別のアレー ２５を提供し取扱う。用語“PVSTRUCT”は、予測可変構造（Ｐｒｅｄｉｃｔｏｒ Ｖａｒｉａｂｌｅ Ｓｔｒｕｃｔｕｒｅ）から来ており、予測（Ｐｒｅｄｉｃ ｔｏｒ）は、データのエンコードを助ける為に多数のサンプルファイルを解析す ることから得られる統計データの使用を指す。また、可変（Ｖａｒｉａｂｌｅ） は、構造体（あるテキストブックでは「動的構造体（ｄｙｎａｍｉｃ ｓｔｒｕ ｃｔｕｒｅｓ）」と呼ばれている）をサポートすることを示し、コンポーネント の数が各インスタンスに対する実行時間で変化できる。 分解言語は、決められた命令セットであり、PVSTRUCT構造体の分解を特定する 簡潔な方法を提供する。命令セットは、広範な動的バリエーションのサポートを 含み、コンポーネントの数が、外部因子のほかに、他のコンポーネントのファイ ル数に左右される場合も含む。決められた値、又は範囲の制約のような、他のフ ァイルフォーマットデータが取り込まれる。命令セットは、また、分解器とフィ ルタとの間のデータ交換手段を提供する。 圧縮システムは、類似のアイテムをまとめる為に、ファイルを分解することに 基づいている。圧縮システムの以下の記述において、実施例は、代表的なスプレ ッドシートファイルフォーマットに見られる構造体を示す。 実施例２ スプレッドシートファイルは、通常、多数のレコードを含む。各レコードは、 レコードのタイプを示す１６ビットワードで始まり、続く１６ビットワードは、 レコードの本文のバイト数を示す。次に、ファイル仕 様は、レコードの内容を記述する。TABLE SIZEレコードの仕様は次のようなもの である。 RecType＝0x402 Rec Body Sixe＝12 レコードデータ： オフセット ネーム サイズ 内容 ４ MinRow ２ シート上の最初に画定された列 ６ MaxRow ２ シート上の最後に画定された列＋１ ８ MinCol ２ シート上の最初に画定された行 １０ MaxCol ２ シート上の最後に画定された行＋１ １２ （Reseved） ４ 予備 データには、複数のこのようなレコードが存在できる。複数のレコードが存在 する場合には、各レコード中の同一のコンポーネントの値は互いに類似したもの になって行く。これにより、圧縮システムは、圧縮比を高める為に、類似性を利 用することができる。 圧縮システムは、好ましくは、以下のARRAY＿XX構造体に基づく。 ARRAY＿U8：±符号なしとしてエンコードシステムによって扱われる８ビッ トデータアイテム用 ARRAY＿16：±符号ありとしてエンコードシステムによって扱われる16ビッ トデータアイテム用 ARRAY＿32：±符号ありとしてエンコードシステムによって扱われる32ビッ トデータアイテム用 ARRAY＿F32：32ビット浮動少数点用 ARRAY＿F64：64ビット浮動少数点用（「ダブル」） ARRAY＿F80：８０ビット浮動少数点用（「ロングダブル」） ARRAY＿STR：各エントリは、その数がサイズ（文字列サイズ）によって与え られる数バイトを含む。 TABLE SIZEレコードに対しては、５つのアレーが作り出される（レコ ード仕様を参照して）。レコードが分解される度に、エントリは５つのアレーの 各々に加えられる。 すべてのレコードが分解された時には、各アレー中のアイテムをエンコードす る関数が呼び出される。この関数は、圧縮を最大にする為の多種類の関係を解明 する(exploit)ことのできる多数のアルゴリズムを含む。オーバーヘッドが事実 上要求されない点で、この実現は極めて効果的である。一つのエントリしか持た ないアレーでさえも、効果的に圧縮することができる。分解システムがファイル を膨大な数のこれらの小さいアレーに変形することがあるので、この事は必要で ある。エンコード関数は、また、データのエンコードが終わった後にデータを解 放することができる。 デコード処理は、上記シーケンスを逆にする。最初に、各コンポーネントアレ ーはデコードされる。次に、分解が逆になされる。 このタイプの分解は、広範囲に行わなければならないが、処理を簡素化するた めに、多数のツールが用いられる。それらのツールは、vstruct＿defsと呼ばれ る命令の使用に基づいている。TABLESIZE実施例で続けるには、このようなレコ ードを分解する命令セットは、下記の通りとなる。 //最初の３つの命令は、常に、レコードに関する一般情報を提供する。 ８， //このセットの命令の数 12， //12バイトの固定サイズであるレコード本文のサイズ ５， //作りだす配列数 //残りの命令は、レコードの分解方法を示す。 INT16， //第１コンポーネント用１６ビット整数を分解する（“MinR ow”） INT16， INT16， INT16， INT32｝： //最後のコンポーネント用３２ビット整数を分解する（“予 備”） vstruct＿def命令は、１６ビット整数である。最初の３つのワードは、必ずレ コードに関する一般情報を含む。残りのワードは、このようなレコードが現れた 時の処置を自動化された分解システムに教示する命令を含む。この場合には、命 令は可能な限り簡単であり、レコードの各コンポーネントに対するデータタイプ のリストに過ぎない。分解器は、各コンポーネントに対して一つの配列を作り出 し、そのタイプの一つのエントリを、そのタイプのレコードを分解する度に、配 列にロードする。 次に、これらの命令に基づいてレコードを分解しエンコードする関数が提供さ れる。さらに、デコード処理が、エンコーダの動作を逆になす。 vstruct＿def命令は、前の実施例よりもさらに複雑な状況を処理することがで きる。便宜上、これらの命令の構造の概要が次に要約される。１６ビット命令の 上位バイトは、下位バイトにより要求されるアーギュメント(argument)である。 下位バイトは２つの４ビット符号に分割される。最下位の４ビットは、命令のタ イプを記述し、次の４ビットの意味を決める。このビットフィールド構造は、符 号の下記の記述の中で使用される１６進法で命令を極めて読み易くする。文字‘ ｘ’は、記述される符号ワードに影響を及ぼすことのない１６進値をあらわす。 Bits ０＝３は命令タイプ（opcode）を設定する。 opcode＜＝bの場合には、この値はコンポーネントのデータタイプを示す。上 位フィールドは、下記のように使用される。 Bits 8-15は、使用される時には、アーギュメント（ARG）である。 Bits 4-7は、下記のように使用される。 xx0x：単純なエントリ。このタイプの一つのデータアイテムを読む xx1x：そのタイプのARGエントリを単一アレーに加える xx2x：複数のアイテムも同じアレーに加えるが、数はDataBuf[ARG]で与 えられる xx8x：値のアイテムは、仕様で限定される。値は、読み出され、チェッ クされるが、格納される必要はない。 xxfx：値の範囲はデータタイプによって許可される範囲よりも小さく制 約される。 ARGは決められた範囲、又は決められたリストを選択する。 opcode＝xxxdの場合：サブ構造体をスタートする opcode＝xxxeの場合：サブーサブ構造体をスタートする opcode＝xxxfの場合：ビット4-7によって決まる特別な命令、タイプである。 xx0x：サブ構造体を終わる xx1x：サブーサブ構造体を終わる xx2x：DataBufに値を加える（位置はARGにより与えられる） xx5x：外部から与えられたレコード長に残るサイズARGのワード数を格 納する opcodeにより選ばれたデータタイプは、下記のように決められる。 #define CHAR ０ #define UCHAR ０ #define INT16 １ #define UINT16 １ #define INT32 ２ #define UINT32 ２ #define FLOAT32 ３ #define FLOAT64 ４ #define FLOAT80 ５ #define STRING ６ #define STRINGZ ７ #define SYS＿S1 ８ #define SYS＿SZ1 ９ #define SYS＿S2 Oxa #define SYS＿SZ2 Oxb エンコーダにおいて、±符号あり整数と±符号なし整数の間の区別はされない 。８ビット値は、常に±符号なしとして処理される。１６ビットおよび３２ビッ ト値は、±符号ありとして処理される。この取り決めは、分岐(switch)ステート メントにおけるチェックの為の「場合(case)」の数を少なくするように、ルーチ ンを簡単化し高速化する為に用いられる。これは、圧縮性能には余り影響を及ぼ すことはないが、ファイルデータが分解にも用いられる時（エレメント数がファ イルデータの一部である時のように）には注意が必要である。 STRINGZは、ゼロで終る文字列を指す。それらは正規の文字列と同様にARRAY＿ STRに格納されるが、分解中の取扱いは異なる。例えば、正規の文字列を分解す る時には、文字列の長さが与えられなければならないが、STRINGZは、その長さ を見つけることができる。STRINGZは、ゼロで終わるchar（キャラクタ）を格納 する必要はない。 SYS＿Sxxタイプは、システム文字列を指す。通常、各pvstructの各コンポーネ ントは、各々が個別の配列に入れられ、個別に符号化されている点で独立してい る。小さいが極めて相関度の高い配列を持つことは、エンコードルーチンを用い る時に、数値データに対して極めて有効で ある。しかし、文字列に対しては、圧縮は複数のレコードからのテキストデータ を組合わせるように多くのコンポーネント文字列を単一配列に入れることによっ て、しばしば改善することができる。システムは、２つの“System”文字列に対 して、これらの組合わせコンポーネントを保持することを許容する。これらのシ ステムデータに加えられた文字列は、正規のタイプまたはSTRINGZタイプの何れ も可能である。 説明の為に、２つの簡単な実施例を以下に示す。 実施例３ この実施例においては、特定の位置(location)の水深(depth)が８回にわたり 測定され、データベースに格納される。 レコードコンポーネント int16 locationX （位置X）； int16 locationY （位置Y）； int16 depth[8] （深さ[8]）； 深さの測定は、極めて類似するため：それらを単一のアレーに入れ様とするも のである。命令セットは、次の通りとなる。 vstruct＿def VD ex2[8] ＝｛ ６， //6命令ワード 20， //レコード毎に２０バイト ３， //作りだす配列数 INT16， INT16， 0x811)； //単一配列への８ int16エントリ 但し、0x811は、 xxx1：データタイプはINT16である xx1x：各レコードにおけるこのコンポーネントに対するインスタンス数 はAGRによって与えられる 08xx：ARG＝８実施例４ この実施例では、レコードは、ある人の友達(friend)の年令(age)を格納する 。 レコードコンポーネント int16 num＿friends （友人番号）； uchar ages[num＿friends] （年令[友人番号]）； この場合のような、サイズの可変な配列は、‘Ｃ’プログラミング言語の構造 体内で宣言できないが、しばしばファイルフォーマットにおいて起こる。このタ イプの構造体は、動的構造体と呼ばれる。これは、命令セットにより分解するこ とができる。 vstruct def VD ex3[]＝｛ ６， //６命令ワード INTERN＿SZ， //内部データによって決まるレコードのサイズ ２， //作りだす配列数 INT16， //num＿friends(友人番号)のエントリ 0x12f， //以前の値(val)をレジスタ１に格納する 0x120)； //U8値(val)：数（ct）はレジスタ１から 但し、0x12fは次の通りである。 xxxf：特別な命令 xx2x：ARGによって特定されたレジスタの中の以前の命令によって分解 されたデータ値を格納する 01xx：ARG＝１の時は、レジスタ１を使用する および0x120は次の通りである。 xxx0：データタイプはucharである xx2x：複数エントリ、レジスタ内に見つけられる数はARGで与えられる 01xx：ARG＝１の時レジスタ１を使用する レジスタは、PVSTRUCT構造体の一部として割当てられ、レコードを処理してい る間に、データを一時的に格納するのに使用される。レジスタ0は、特別な目的 で使用される（次の実施例を参照）。フィルタを設計するプログラマーは、エン トリの残りを任意に使用することができる。レジスタは、また、pvstructおよび 残りのプログラム間のデータの交換に用いることもできる。例えば、大きいレコ ードの中に埋まった一つのアイテムが制御に必要な場合には、データアイテムを 読む命令に続くxx2f命令を持つレジスタ内に、レコードをダンプできる。データ アイテムは、次にファィルを読み書きする為の呼び出しの後に、レジスタの中で 利用可能となる。 実施例５ COLUMUN TYPESと呼ばれるレコードに対するファイル仕様は次のとおりである 。 RecType ＝0x413 RecBodySize ＝可変 レコードデータは次の通りである。 オフセット ネーム サイズ 内容 ４ AlignCode １ アラインメント符号 ５ Style １ コラムスタイル符号 ６ Font ２ コラムに用いられるデフォルト フォント ８ Offsets var(可変) コラムオフセット オフセットは１バイト値である。オフセットの数は、レコードサイズによって 決まる。 このレコードに対する命令セットは次の通りとなる。 vstruct＿def VD＿413[]＝｛ ８， //８命令 EXTERN＿SZ， //レコード本文のサイズは外部でセットされ る ４， //作りだす配列数 UCHAR,UCHAR， INT16 0x15f， //ファイルに残された１バイトワードの数をロード する。この為に、デフォルトによってレジスタ０が用いられる //ENDTO数 0x020｝： //U8値(val)：数（ct）はレジスタ１から レコードの最後のコンポーネントは、１バイトコラムオフセットのリストであ る。これらは、互いに類似しており、すべてが単一の配列内に入れられる。この 場合に、この様なエントリの数は、内部的には決定することはできず、以前に分 解されたレコードサイズを使用しなければならない。0x15f命令は、レコード中 に残る１バイトワードの数を決定することを分解器に命令し、この数は、常にレ ジスタ０に格納される。0x020は、複数の１バイトアイテムを単一配列に加えな ければならず、このようなアイテムの数はレジスタ０で見つけられることを、分 解器に教示する。 実施例６ 文字列を含むRANGEDE FINITIONと呼ばれるレコードの実施例である。 RecType ＝0x215 RecBodySize ＝24 レコードデータ： オフセット ネーム サイズ 内容 ４ Name 16 レンジの名称 20 StarRow ２ レンジ内の最初の列 22 EndRow ２ レンジ内の最後の列 24 StartCol ２ レンジ内の最初の行 26 EndCol ２ レンジ内の最後の行 このレコードに対する命令セットは下記の通りである。 vstruct def VD215[]＝｛ ８， //８命令 24， //固定サイズ＝２４バイト ５， //作りだす配列数 0x1018， //８＝SYS＿STR1；サイズ(sz)16(0x10) INT16， INT16， INT16， INT16}； 但し、0x1018： xxx8：文字列がSYS＿STRI配列に格納されることを 示す xx1x：長さはARGにより与えられる 10xx：ARG＝16（0×10） フィルタを書く人物による主観的な決定がここでは、行われる。文字列として 扱われたコンポーネントは、また、上述のように、複数のエントリとして扱うこ とができる。その命令は次の通りである。 0x1010 但し xxx0＝UCHARタイプ xx1x＝アーギュメントで与えられた固定数 10xx＝ARG＝16（0x10 16進法） 文字列アレーを使用する解決は、エントリの性質に基づいていた。レコードは テキスト文字列を含む。配列エンコードシステムは、文字列を取扱うのに、多数 の特別な性質を提供する。例えば、システムは完全な文字列合致をチェックし、 極めて効果的にエンコードされうる（一つの エントリのすべての１６charは他方の１６charと合致する）。したがって、テキ スト文字列は、文字列として格納される時には、必ずより効果的に圧縮される。 これとは逆に、前段落では、文字列サイズを使用しない数値コンプレッサ内で、 オフセットがよりよく扱われる。 実施例７ 文字列を含むEXTERNAL REFERENCESと呼ばれる別のレコードに対するファイル 仕様は次のようなものである。 RecType ＝0x17A RecBodySize ＝var（可変） レコードデータ： オフセット ネーム サイズ 内容 ４ StartRow ２ レンジの中の最初の列 ６ EndRow ２ レンジの中の最後の列 ８ StartCo1 ２ レンジの中の最初の行 10 EndCo1 ２ レンジの中の最後の行 12 Name var レンジ参照を含むゼロで終る文字列 このレコードに対する命令セットは次の通りである。 vstruct＿defVD＿17a[] ＝｛ ８， //８命令 INTERN＿SZ， //rec body sizeは固定されず内部データにより設 定される ５， //作りだす配列数 INT16， INT16， INT16， INT16， SYS SZ2｝； レコードの最後のコンポーネントは、ゼロで終る文字列である。文字列の長さ は、終りの文字を探すことによって見出すことができる。文字列配列は、文字列 サイズを格納しエンコードするので、終端の文字はセーブしておく必要はない。 INTERN＿SZはレコードサイズを示し、これは、予め判明していないが、内部的に 決定されるので、レコードサイズは実施例５のColumn Typeレコードに対しては 必要とされたように、エンコードされる必要はない。実施例８ 構造体、は別の構造体内に収める、つまり入れ子にすることができる。親構造 体は、入れ子にされた構造体の複数のインスタンスを含むことができる。このよ うなCOLUMN STATUSレコードの記述は、次のようなものである。 Rec Type ＝0X7 RecBodySize ＝var（可変） レコードデータ： オフセット ネーム サイズ 内容 ４ Default Status １ コラムに対するデフォルトの状態 ５ Col Data var 以下に決められたようなコラムデー タエントリのリスト コラムデータエントリは、その状態がデフォルトに等しくない各コラムに対す るオフセット、およびそのコラムの状態を示す。各エントリは２バイトである。 オフセット １バイト ステータス １バイト このレコードに対する命令は次の通りである： vstruct＿def VD＿7[]＝{ ８， //８命令 EXTERN＿SZ， //外部入力を必要とする可変サイズ ３， //作りだす配列数 UCHAR， //「デフォルト状態」が親構造体の一部である //サブ構造体をスタートする準備が整う。数は、外部的に供給されたレ コードボディサイズで、残りのスペースに適合できる数である 0x25f， //ファイルに残っている２バイトワードの数をレジ スタｏの決められた位置にロードする //ENDTOデータに対して 0x02d， //サブ構造体（sub）をスタートし、レジスタ０か らの数（ct） UCHAR， //「オフセット（Offset）」は、サブ構造体の最初 のコンポーネントである UCHAR}； //「状態（status）」は、サブ構造体の第２コンポ ーネントである レコードの最後のコンポーネントは、多数のオフセット／状態の対である。別 個の配列を、オフセットコンポーネントおよび幅コンポーネントに対して作り出 す必要がある。分解器は、対のシーケンスを調べ、アイテムをそれらの適切な配 列に入れる。この一般的な手順は、サブ構造体により取扱われる。この場合には 、サブ構造体は２つのuchar（±符号なしキャラクタ）コンポーネントを持つ。 ２つの命令が、サブ構造体を組み立てるのに呼び出された。 0x25f：この場合に数を設定するのに用いられる xxxf：ｆは特別な命令を示す xx5x：レコードの中に残ったARG長ユニットの数を決定し、これをレジ スタ０に格納する 02xx：ユニットサイズは2(サブ構造体当たり２バイト） 0x02d：サブ構造体をスタートする実際の指令 xxxd：サブ構造体をスタートする xx2x：レコード中のサブ構造体のインスタンス数は、register［ARG］ 内で、見つけられる 00xx：ARG＝０（従って、数はレジスタ０にある） 後に続くすべてのコンポーネントは、End＿SubStructure命令（0x000f）が現 れるまで、サブ構造体のエレメントとして扱われる。命令リストが終るまでに、 何も現れなければ、すべての残りのコンポーネントはサブ構造体の一部である。 End＿SubStructure指令が見つけられると、その後の命令は、メイン構造体の一 部として含まれるコンポーネントを参照する。 分解システムも、また、サブ−サブ構造体（サブ構造体中のサブ構造体）をサ ポートするが、好ましくは、より高レベルの入れ子構造は許されない。なぜなら ば、これ程複雑になったファイルスペックは、未だ識別されたことがないからで ある。多くのサブ構造体、又はサブ−サブ構造体は、好ましくは、入れ子が一度 に２レベル以上深まることのない限り、pvstructの中で必要に応じて限定するこ とができる。即ち、End＿SubStructure命令を介して親ネスティングレベルに戻 る。 実施例９ 場合によっては、アレーに書きこむデータのレンジは、ワードサイズによって 許容される全数値レンジよりも小さいとして、ファイルフォーマットにより決め られる。例えば、ファイル仕様は、０又は１の１バイトエントリを特定する。こ の情報は、分解システムによる正常チェック、およびエンコードシステムによる 圧縮度の向上に使用できる。説明的なCOLUMN OPENレコードの記述は次の通りで ある。 Rec Type ＝0x11 RecBodySize ＝１ レコードデータ： オフセット ネーム サイズ 内容 ４ Co10pen １ ０（コラム閉）又は１（コラム開） このレコードに対する命令セットは下記の通りである。 vstruct＿def VD＿11[]＝｛ ４， //４命令 １， //固定サイズ(sz)＝１バイト １， //作りだす配列数 D8＿１｝； //後述する決められた定数 UCHARエントリの代わりに、D8＿１がエントリとなり、８ビットワードサイズ および１ビットの値の範囲を示す決められた符号が実際に用いられる。これらの レンジの制約は、ファイルの分解に影響を及ぼすことはない。レンジ制約エント リは、そのワードサイズにしたがって分解される。レンジ制約は、PREDICTOR構 造体が自動生成を助ける為に用いられ、この構造体はコンポーネントの静的モデ ルを含み、アレーのエンコードを制御する。現在、決められた符号ワードは、次 のフォーマットを用いる。 min＿val＝０： max＿val＝（1＜＜nbits）−１である、決められたレンジ。 DX＿Y： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32） Y＝nbits(nビッド) min＿val＝１：max＿val＝（1＜＜nbits）であって、１で始まる決められたレ ンジ。 DX＿Ys1 ： X＝ワードサイズ（8＝uchar；16＝int16：32＝in t32） Y＝nbits(nビッド) 特別に決められたレンジ DX＿rY： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32） Y＝PREDICTOR＿CONTROLにおけるRANGEエントリのインデック ス-＞spec＿range[] 特別に決められた値のリスト： DX＿vY： X＝ワードサイズ（8＝uchar：16=int16；32=int32） Y＝PREDICTOR＿CONTROLにおける値リストエントリのインデ ックス-＞spec＿dlist[] 分解システム２４（図２）は、好ましくは、Ｃプログラミング言語で書かれた 関数ライブラリとして実現される。ライブラリのこの記述は、FILE I/Oルーチン 、ARRAYルーチン、およびPVSTRUCTルーチンの３つのセクションに分割される。 分解システム２４は、フレキシブルな入力／出力インターフェースを有するの で、同一セットの分解ルーチンを、入力／出力フォーマットには関係なく使用で きる。ＤＯＳ、およびＯＬＥ２の２つのファイルフォーマットがサポートされる 。しかし、通信ポートおよび他のＩ／Ｏオプションのほかに、他のファイルフォ ーマットにまで拡大できる。ＤＯＳフォーマットは、論理ストリーム位置が、通 常、未処理のファイル位置と同一であるため、平易である。ＯＬＥ２フォーマッ は、内部割当てテーブルを用いるＯＬＥ２ストリームを再構築する為に、広範な 符号の層を要求する。 カスタマイズされた配列変形器 分解システム２４は、ソースファイル中の各コンポーネントに対してアレー２ ５を作り出し、自動化された解析システムにより生成されたエンコード用パラメ ータ１８によって援助された配列符号器２８は、利用可能なアルゴリズムを用い て各アレー２５をエンコードする最良の方法を見つける。場合によっては、これ らの自動化されたデフォルトメカニズムは、カスタムルーチンを用いることによ って改善できる。カスタムルーチンは、変形器と呼ばれる。なぜならば、カスタ ムルーチンは分解されたアレー２５で始まり、結果は、配列符号器２８に送られ るアレー２５の異なるセットだからである。 カスタマイズされた配列変形器２６の主な役割は、コンポーネント間のモデル の実施である。一つのコンポーネントからのデータが、別のコンポーネントの符 号化を援助できる。自動化されたデフォルトメカニズムは、各コンポーネントを 個別に処理し、圧縮性能はコンポーネント間の関係を解明することにより、時に は、改善できる。このようなシステムは、アレー２５中のすべての値を正確に予 測でき、これより、アレー２５に符号は必要ない。カスタマイズされた配列変形 器２６は、シミュレータになり、ソースデータファイルを生成するプログラムの 機能性を複写する。各カスタムルーチンは、単一フィルタ１０に関連する特定の 問題を解決する別個の創造物である。これらのルーチンの多くは、特定の問題に 対する解決手段として独立して適用される。 カスタムルーチンは、実行可能なサイズを構築して拡大するために、多くの労 力を要求するので、カスタムルーチンの使用は、好ましくは、総合的な性能が大 幅に急増すると考えられる場合に制限する。多くのファイルフォーマットにおい て、少数のコンポーネントがデータの大部分を編成する。カスタマイズされた配 列変形器２６は、通常、これらの頻度の高いコンポーネントの圧縮度を改善でき 、自動化されたデフォルトメカニズムは、残りのコンポーネントの十分な圧縮を 達成する。 システムの他の部分は、カスタマイズされた配列変形器２６が書かれ るコンポーネントに関しても、十分な役割を果たす。分解システム２４は、コン ポーネントの隔離と、カスタム作業を必要とするコンポーネントの識別および解 析を簡易化する。配列符号器２８および自動化された解析ルーチンは、カスタマ イズされた配列変形器２６によって生成されたアレーをさらに処理する。配列符 号器２８の能力によって、カスタムモデリングに対する革新的なアプローチが可 能である。このようなアプローチの一つは、サブディビジョンによる圧縮であり 、アレー２５を複数のアレー２５に変形し、その各々を、配列符号器２８によっ て解明された方法で内部的に相関させる。 この一例として、上記実施例１における符号化された数字を考える。これらの 値は、３２ビットの整数の単一アレー２５に分解される。しかし、これらの値は 整数ではなく、むしろ、エントリは４つの異なるタイプの一つであることを２つ のビットが示し、残りビットが各タイプに対して異なる意味を持つ、符号である 。新しいアレー２５が、２ビットフラグに対して作り出され、次に、分離した配 列が各４つのタイプに対して作り出される。自動化された分解システムおよび配 列符号器２８は、これらの各５つのアレーに対して異なった最適モデルを見つけ ることができ、エントリの少ないアレーの取扱いにおけるシステムの効率は、複 数のアレーの使用から、オーバーヘッドを除去する。この結果として、これら５ つの高度に相関化されたアレーを符号化して得られる全符号サイズは、単一オリ ジナルアレーの符号化によって得られるサイズよりも十分に小さい。 カスタマイズされた配列変形器が、複数のフィルタ１０によって使用される場 合、リソースにすることができる。リソースは、複数のフィルタによって使用さ れる個別のモジュール（Ｗｉｎｄｏｗｓ環境におけるＤＬＬ）である。リソース を用いることの主たる理由は、冗長符号を減らすことにある。 配列符号器 大抵の圧縮アルゴリズムは、データブロックを変形し、その結果を少ないビッ トで頻度の最も高い値をあらわす方法を用いてエンコードするプロセスを含む。 前記の変形は、数回継続することが可能であり、変形ごとに複数の出力ブロック を作り出すことができる。例えば代表的なＬＺ７７符号器において、ソースデー タは、４つの異なる配列（array）に変形される。すなわち、合致シーケンスが 見出されたか否かを示す１ビットフラグのブロック、以前のシーケンスと合致し なかったバイトの配列、および一つのシーケンスが見出された時の合致シーケン スの長さと位置、である。最初の３つの配列は、しばしば単一の配列に結合され てからハフマン符号化されるのに対し、合致位置は、レンジ変形されてからハフ マン符号化される。 このタイプの圧縮システムは、ソースアレー（Array）が変形されて一つ以上 のアレーになり、これらがまた他の変形を行うようなプロセスネットワークとみ なすことができる。各パスの終わりには、確率的なモデルをエンコードされた出 力に変形するハフマン符号器、または算術符号器のような低レベル符号器がある 。データ圧縮のための従来のアプローチは、僅かな数の変形を持ち、それらへの 固定化されたパスを定義する“圧縮アルゴリズム”に基づいている。これらの固 定されたシステムは、僅かな数のコンポーネントを作り出す従来の分解システム に必要とされるエンコードを扱う。 本発明による好ましい分解システム２４は、異なるフィルタ１０の異なるコン ポーネントをあらわす多数のアレー２５を作り出す。データ夕イプ（文字列、浮 動小数点（フローティングポイント）値および各種のワードサイズの整数）は、 コンポーネントごとに異なっていることが考えられる。これらのコンポーネント アレーのそれぞれの中のデータは、多様な方法で内部的に相関化できる。最適の 圧縮を実現するためには、これらのパターンを利用する圧縮アルゴリズムを用い ることが必要とな る。また、最適アルゴリズムは、その時利用可能なメモリおよび速度と圧縮能力 との兼合いの必要性に影響を受ける。各アレーにおけるエントリの数もまた大幅 に変化し、異なる符号化アプローチが、異なるアレーカウントにおいて、より効 率的に作動できる。 好ましい符号器システムは、各コンポーネントの静的モデルを利用することが できる。このモデルは、フィルタが使用されているタイプの多数のソースファイ ルにおけるこのコンポーネントのインスタンスを解析することにより、得ること ができる。このシステムは、“静的”でもなく“適合的”でもなく、むしろ役に 立ちさえすれば静的モデルからの情報を使用する一方、各アレーに見出される個 々のデータに完全に応答できる。静的モデルは、変形アルゴリズムの選択を導く こと、および各種のアルゴリズムに対する予め算出されたエンコードテーブルを 提供することができる。 従って、好ましい符号器システムは、各アレーをエンコードするための何千種 の方法をサポートせねばならない。プロセスシステムは、固定されたアルゴリズ ムではなく、むしろ動的ネットワークであり、このネットワークを通る各パスは 、各種のエンコードアルゴリズムを作り出す。ネットワークを通るデータのパス は、静的モデルならびにアレーへのエントリ数、速度およびメモリ上の制約のよ うな動的な考慮により導かれる。 好ましい符号器システムの持つ一面は、ネットワークを制御するためのアレー カウント（アレーへのエントリ数）の広汎な使用にある。低いカウントでは、シ ステムは、サンプルデータベースの解析から作り出される静的モデルに全面的に 依存する。カウントが増大するにつれて、システムは、特定のアレーの特性に対 する適合度の高いアプローチを使用する。なぜならば、適合モデルの使用から得 られる利点が、適合モデルのエンコードのオーバーヘッドよりも重要になり始め るからである。カウントの低い時のオーバーヘッドは、ほとんど完全に除去され るから、 エントリが一つしかないアレーでも、効果的にエンコードできる。オーバーヘッ ドが無くなることにより、サブディビジョンによる圧縮と呼ばれる新しいタイプ のアプローチを使用することが可能となり、この場合には、ソースアレーは、多 数の高度に相関化された小さいアレーに変形される。 また、好ましい符号器システムは、出現したコンポーネントの多くに対して圧 縮能力を高める多数のオリジナルアルゴリズムを含む。浮動小数点および文字列 アレー変形のようなルーチンは、これらのコンポーネントをエンコードするため の以前の方法を十分に上回る利点を提供する。 図３は、配列符号器のフローチャートである。他のルーチンとの間のインタフ ェースを簡単にするために、配列符号器の好ましい導入は、すべてのアレータイ プ（各種のワードサイズ、文字列等の整数および浮動小数点）を扱う単一エンコ ードルーチンを含む。次に、マスタールーチンが、各アレーを図示されたデータ タイプに対する特殊なエンコードルーチンに導く。 特にステップ３２において、アレー２５タイプは、文字列配列としてチェック される。アレーが文字列配列の場合には、文字列符号器４０が呼び出される。配 列が文字列配列でない時には、アレー２５タイプは浮動小数点（フロート）タイ プとしてステップ３４においてチェックされる。アレーが浮動小数点タイプであ れば浮動小数点符号器５０が呼び出される。アレーが文字列タイプでも浮動小数 点タイプでもなければ、整数タイプであり整数符号器７０が呼び出される。 図４は、図３の文字列符号器４０のブロック図である。ここでは、用語“文字 列（String）”は、文字のマルチバイトシーケンスを記載するために用いられる 。文字列アレーは、一つ以上の文字列を含むことが可能であり、そのそれぞれは 異なる文字列サイズ（そのシーケンスでのバイトの数）を持つことができる。文 字列符号器は、まず、文字列合致判 断器４１を用いて、受取った文字列データにおける文字列合致をチェックできる （文字列全体がアレーの中の他のすべての文字列に合致する場合）。文字列合致 判断器４１は、配列符号器２８からの文字列データ、または静的モデル４３によ り供給され予測された文字列のリストについて作動できる。その後にアレーは、 いくつかのメカニズムによりエンコードされ得る。合致していない文字列のよう な小さいアレーは、テキスト符号器４７により処理され、この符号器４７は、Ｌ Ｚ変形の一種を用い、文字列位置を利用し、静的モデルを用いて辞書を準備（Pr ime（プライム））し、または符号化テーブルを提示できる。合致符号の大きな アレーは、ブロック分類アルゴリズムおよび他の公知の技術のような配列符号器 ２８により提供される標準テキスト圧縮ルーチンにより扱われ得る。テキスト符 号器４７が静的モデル４３により使用される時には、符号器は静的モデル４３に より準備される。 図５は、図３の浮動小数点符号器５０のブロック図である。浮動小数点アレー は、３２、６４、または８０ビットのフォーマットのいずれをもとることができ る。浮動小数点符号器は、配列符号器２８から浮動小数点データを受取り、フル ワード（２倍精度浮動小数点値のすべての８バイトのような）のみの合致を調べ て合致していない値を持つアレーを戻すＬＺ符号器５１を用いて、まず、以前の 値との合致の有無をチェックする。次に、合致していない値は、ベース１０変換 器５３の中でベース１０記号に変形される、なぜならば、多くのデータベースは 、ベース１０値として当初エントリされた浮動小数点値を含み、またアレー符号 器２８を通った値をそれらのネイティブフォーマットでエンコードすることが、 より有効であるからである。ベース１０仮数、指数および変換エラーは、配列符 号器２８により個別に処理される。ロスのない符号化のために、オフセットは変 形時の僅かな丸め誤差を修正するように格納されねばならないことがある。ベー ス１０に効果的に変換されなかった値は、次に、文字列符号器４０（図４）を用 いてエンコードされる。 自動化された解析システム 分解システムは、ソースファイルを多数のコンポーネントに分解する。多数の サンプルファイルの中の同じコンポーネントを調べることにょり、静的モデルは 、アレー符号器の中のコンポーネントのアレーの圧縮を高めることのできるコン ポーネントで構成できる。自動化された解析システムは、最良のこのようなモデ ルを見出す。 図６は、好ましい自動化された解析システムのフローチャートである。ステッ プ６２においては、動作は、まず、全ソースファイルの中の特定のコンポーネン トのすべてのインスタンスを持つファイルに、ソースデータファイルのすべてを 分解することにより簡単化される。次に、これらの分解されたファイルは、ステ ップ６４において解析される。この解析は、高速である必要はない、なぜならば 、その作業はオフラインで行なわれるからである。次に、フィルタに対するすべ てのコンポーネントに対する結果は、多数コンポーネントモデルの中で冗長デー タを消去する単一の“Ｐｒｅｄｉｃｔｏｒ Ｄａｔａ”ファイルにステップ６６ で統合される。整数データ用の符号器 整数データに対する符号器は、３レベルシステムに基づくのが望ましい。高レ ベル操作は、合致値のシーケンスに対する距離をエンコードするＬＺアルゴリズ ム、又はある値を以前の値からのオフセットに変換する差変形のようなデータブ ロックの中のデータアイテムと特定の以前のデータアイテムとの間の関係を解明 するモデルに基づく。中レベル操作は、ソースデータブロックにおけるデータ値 の位置とは無関係なモデルをベースとする。操作により、特定値がブロック全体 の中で生じる頻度のようなデータ、又はデータ値が各種の数値範囲の中にある頻 度のようなデータの特性を解明する。データ値を１ブロックの符号に変形する操 作が行われる。低レベル符号器は、これらの符号を確率的なモデルに基づいて圧 縮する。２つの公知の低レベル符号器は、ハフマン符号および算術符号を用いた ものであり、そのいずれもが本発明のシステムに使用することができる。下記の 考察は、中および高レベルシステムに限定することとする。 高レベル符号器は、単一の解法ではなく、むしろその各々が特定のタイプのデ ータセットに関して有効な方法とモデルの集合体である。問題のこの部分につい ては、単一の解法は存在しない。何故ならば多くの他の方法は同じ汎用の目的に 用いられ、あるいはこの中で考察されているものとは別の性格を持つデータセッ トに対する解法を提供するためである。記載される方法のあるものは、標準的な 技術であり、又他のものは標準技術の独自の改変である。これらの方法を記載す ることの外に一般的なフレームワークがこれらの高レベルモデルを統合するため に、又それらの変形から得られるデータが中レベル符号器により如何に効果的に 処理されるかを示すために記載される。 中レベル符号器は、アルファベットのサイズを低レベル符号器により有効に処 理することのできるものに減らさねばならない。通常の数値ワードサイズは、し ばしばハフマン符号、又は算術符号を用いた従来の手段により処理することので きる以上のシンボルを必要とする。例えばこれらの符号器の処理容量をはるかに 上回る３２ビット整数のアルファベットをあらわすのに４，０００，０００，０ ００以上のシンボルが必要である。中レベル符号器は、数値データブロックにお いて公知の２つの特性を利用する。 第１に特定データ値は、しばしばデータブロックの中で高い頻度で現れる。各 データブロックは、これらのマジック値の独自のセットを持つことが可能であり 、これらの値は、数値範囲の中の何れかのポイントに生じることがある。 第２にデータ値は、数値範囲に関して不均一に分布することがある。 例えばあるデータブロックにおいては小さい値は大きな値よりも更に頻度の高い 傾向がある。 図７は、整数符号器の高レベルの動作を示すフローチャートである。整数符号 器７０は、ステップ７１においていずれの変換が用いられるか、又これらの変形 を実施するのに必要な他のパラメータを決める高レベルモデルを構築することに より始まる。このデータは、ステップ７３においてエンコードモジュールデータ 構造の中に格納され、図示されたようにプロセス中、各種のステップで使用され る。 最初のオプションは、ステップ７５における初期の分割器であり、これは値が 低いバイトが高いバイトとは無関係に高度に相関化される時に用いられる。これ に対する通常例は、ランダムデータセットの場合に予測される１０％よりはるか に高い頻度でベース１０値の低い桁の中にゼロが出現することである。高レベル モデラ（符号器）がこのような状態を検出した時には、ステップ７７においてソ ースアレーをソース値の上と下の桁をあらわす別個のアレーに分離させる。分割 器によって戻された複数のアレーは、別個に処理される。 アレーデータは、次にステップ７９において合致アルゴリズムがデータに用い られるべきか否かを決めるためにテストされる。ステップ８１における合致アル ゴリズムは、冗長データアイテム（即ち、配列の中の以前の入力に完全に合致す るもの）を取り去る。合致アルゴリズムは、ステップ８３においてデータを合致 したデータをもつアレーを格納する。合致しない値は、ステップ８５においてサ イズオーバアレー処理器により処理される。 システムは、整数アレーのサイズを効率の改善とデザイン上の問題のいくつか の簡単化に役立つ固定された最大値に限定するのが望ましい。アレーカウントが この最大値を越えると、オーバーサイズアレー処理器（ステップ８５）は、配列 を一連の小さいアレーに分割する。次にこれらのアレーは、ステップ８７におい て、残りのルーチンが通常データタ イプに関して操作することができるように、int32に変換される。これらの変形 は、合致アルゴリズム（ステップ８１）の後に行なわれる、何故ならば合致アル ゴリズムは、大きなブロックに関して、より効率的に機能するからである。 次にint32データがステップ８９において数値変形が次に行なわれるか否かを 決定するためにチェックされる。ステップ９１において数値アルゴリズムは、以 前の値を用いてアレーを予測された値からのオフセットに変形する。これらのモ デルからのオフセットは、次にステップ９３において分割器決定ブロックに渡さ れる。 上述のように分割器機能が必要な時には、分割器操作がステップ９５において 実施される。分割器機能は、別個に処理される複数のアレーを戻す。 ステップ９７において、繰り返し変形（ステップ９９）を用いるべきか否かの 決定が行なわれる。ステップ９９の繰り返し変形は、合致変形の１タイプである が、すべての他の変形の後に行なうことができる。何れの場合にもプロセス動作 は中レベル符号器１００に渡される。 分割器がフローチャート中の２箇所（ステップ７７および９５）で示されてい ることに留意する必要がある。これは、分割化が、下記の変形の一つが用いられ る時に、数値変形の前に、又は合致変形の後に定常的に行なわれるためである。 合致、数値変形および繰り返し変形は、データアイテムとエンコードブロックの 中の前のデータとの間の関係を解明する。 “高レベル”の用語は、この符号器の構造に関係することに注意すべきである が、この符号器と総合的な圧縮システムとの間の関係には無関係であることにも 注意すべきである。データブロックをこの符号器に送る前に総合的なシステムは 圧縮を高めるために、例えば類似の成分の配列を生成するためにソースデータを 分析し、各種の成分の間の相互関係を利用するような多くの事を行なうことがで きる。ここに記載の操作は 、システムレベルで取り扱うべきものを除外する。この記載は、又総合システム がバイレベルデータ、テキスト、ビットマップイメージ、等のような特殊化され た符号器の使用がより適切なデータタイプを選び出すことを前提としている。 高レベル符号器の目的は、データブロックの中の異なったデータアィテムの間 の関係を解明することにある。現在では上記の関係は、次の２つのタイプ、数値 変形および合致変形が対象となる。数値変形は、ブロックの前のデータ値に関し て行なわれた算術符号操作の関数としてのデータ値Ｄ〔ｉ〕を予測する。この時 、Ｄ〔ｉ〕は、変形方程式により予測された値からのオフセットとしてあらわさ れる。変形は、変形された値をエンコードするのに必要なビットの数がオリジナ ルの値をエンコードするのに必要な数よりも少ない時には有効である。合致アル ゴリズムエンコードは、Ｄ〔ｉ〕とデータブロックの中の前の値との間を合致さ せる。アルゴリズムは、合致値の位置をエンコードするのに必要なビットの数が 〔ｉ〕をエンコードするために必要な数よりも少ない時には有効である。両タイ プの操作は、同じブロックにおいて行うことができる。例えばＤ〔ｉ〕をＤ〔ｉ −１〕からのオフセットとしてあらわす差変形の次には、これらのオフセットの マッチを見出す合致アルゴリズムが続くことができる。 データブロックに関して何れの操作を行なうべきかに関する決定はモデラ（符 号器）により行なわれる。アルゴリズムに考えられる各組合せを用いてフルデー タブロックをエンコードすることにより最大の圧縮を実施することができるが、 これには最も現実的な用法が箇約できるよりも多くの処理時間を必要とする。エ ンコードされるべきデータブロックのサブセットに関する代案をテストするとと もに、変形されたデータブロックを完全にエンコードすることなしにそのエンコ ードコストを推定するモデルを作ることにより、スピードアップすることができ ることの決定がなされる。符号器は、圧縮性能に対して次のような兼合い（トレ ードオフ）方式のプロセスサイクルの能力を提供する。つまり、アプリケーショ ン環境が圧力時間のより少ない状態に在る時には、圧縮性能を改善するための代 案の決定に、より多くの時間を費やすことができる。各アルゴリズム考察は、そ のァルゴリズムが用いられる時にエンコードコストを推定するために用いられる モデルの記載を含む。 高レベル符号器に於ける第１のステップは、変形が使用されぬ時にはデータブ ロックをエンコードするコストを決めることである、何故ならばバイパス符号化 テーブルは、他の代案の有効性を決定するために後で用いられるからである。バ イパスモードは、サンプルデータブロックを生成し、それを中レベルシミュレー タに送ることによりテストすることができる。後述の中レベルシミュレータは、 中レベル符号器に送られるブロックのエンコードのコストを推定するための高速 メカニズムを提供する。サンプルデータブロックのサイズは、時定数によって調 整される。中レベルエンコードは、データ値の位置には無関係であるために、サ ンプルは一連のアルゴリズムを決定するために必要なサンプルブロックを選ぶ代 わりにデータブロック中にランダムに分散することができる。他の高レベルモー ドを決定する時に、モデラはソースデータブロックの中の各アイテムをエンコー ドするためのコストを推定するために中レベル符号器により生成されたエンコー ドテーブルを使用することができる。 最も簡単な関係は、ある値を前の値からのオフセットとしてエンコードするこ とである。これは、ほぼＤ〔ｉ〕＝Ｄ〔ｉ−１〕であることを予測し、Ｄ〔ｉ〕 を前の値からのオフセットに変形する。 Ｄ'[i]＝Ｄ[i]-Ｄ[i-1] （１） 上記のシステムは、又ノイズの影響を受けにくい値に関してある値がＮ回の以 前の入力に関する平均値に等しいことを予測する点で、変化に対応する。 式（１）は、式（２）においてＮ＝１である場合と見なすことができる。しか し式は、更に簡単な式（１）を処理する時に高い速度を利用するための別個のル ーチンを用いて実行することができる。 あるデータタイプ（音響、画像、等）は、更に複雑な関係を利用することがで きるかも知れないが、他の式が汎用整数符号器に統合されることのないために、 このようなデータタイプは特殊なルーチンを用いてエンコードされることが望ま しい。 モデラは２段階で操作される。第１段階は最良の数値モデルを選ぶが、これは 我々のこの場合の設定では式（２）のＮの最適値の選択である。Ｎ＝１、２およ び４のような幾つかの値をチェックし、次に生じるオフセットが最小になるＮの 値を選ぶことで充分である。符号化コストのもっとも正確な表現は、オフセット のベース２対数を比較することであるが、オフセットの絶対値（ａｂｓ）を判定 することで充分である。 但し、ｃｔ＝データブロックへの入力の数 このルーチンは、エンコードコストを推定するために必要な、より詳細なルー チンが一つの代わりの数値で実行されるだけでよいように、最適の数値関係を迅 速に見出すことができる。実際の符号化コストを推定するための現行のルーチン は、バイパス決定のために行なわれていたように中レベル符号器を用いたサンプ ルデータセットのエンコードに基づく。 ３つの合致アルゴリズムの実施されていることが望ましい。つまり、整数を用 いて使用するのに多くの改善の行なわれたＬＺアルゴリズムのバージョン、繰り 返し変形、およびＭＴＦ（ムーブ−トゥ−フロント） アルゴリズムである。 基本的なＬＺアルゴリズムは、ワードサイズを定めないが、大抵の手段は、１ バイトワードを用いることを基本としている。好ましいシステムは、現行では１ 、２および４バイト整数を含むフレキシブルワードサイズを可能にする。ルーチ ンは、３つの出力アレーを生成する。 （合致しない値について） これらは合致シーケンスの一部ではないデータブロックの中の整数である。デ ータタイプは変化しない。つまり、ソースアレーがint32であった時には合致し ない値も又int32であろう。このコンパクトにされたアレーは圧縮のために整数 符号器の低いレベルに送られる。 （長さについて） 合致シーケンスにおいて、長さはそのシーケンスにおいて合致していたワード の数を示す。上記以外であれば長さは次の合致の前の合致しない値の数を与える 。 （位置について） 位置は合致シーケンスのスタートに対するオフセット（ワードの数であって、 バイトではない）を与える。 アルゴリズムの手段における別の工夫は、合致の判定のための動的システムで ある。従来のＬＺ手段は、合致しないデータアイテムをエンコードするための固 定コストを前提とするが、バイパス判定の結果が利用可能であり、この判定は各 々の異なった合致しないデータ値をエンコードするコストの優れた推定値を与え る。例えば値１０１９が２５％の頻度で出現する時には、その合致しないアイテ ムとしてのエンコードコストは２ビットであり、この事は合致シーケンスとして このような２つの値の合致をユーンコードすることは有効でないことを意味する 、なぜならば合致をエンコードするコストは、合致しない入力としての値をエン コードするコストを上回るからである。動的判定のこのシステムが実施される度 合いは、各リアルタイム状況下での速度／圧縮の兼合いに従って 調節することができる。 繰り返し変形は、繰り返し符号を持つ繰り返された値に置き換えるものである 。好ましいシステムは、標準手段に対する幾つかの改善点を提供する。第１に繰 り返し符号は動的に調節される。即ち各データブロックのために用いられた繰り 返し符号は、データブロックの次の２っの特性、つまり、データブロックのサイ ズとブロック中の繰り返し値の数に従って調節される。第２に特殊なＲＴＥ（ラ ン−トゥ−エンド）符号は、繰り返しシーケンスがブロックの終りに迄続くこと を意味する。最後に大きな値をあらわすために特殊なコードも存在する。繰り返 し符号のためのスペースを設けるために合致しない正の値は、上方に繰り返し符 号の数だけシフトされる。我々の、数値レンジの増えることを避けるために正の レンジの終りの値は、特殊符号を用いてエンコードされる。 従来のＭＴＦ符号器は、小さいワードサイズを前提とするので、すべての考え られるシンボルを合致距離としてあらわすことができる．大きいワードサイズは 、限定されたサイズのバッファを用い、合致しない値の出力配列を生成すること により考慮され、上記の出力配列は、エンコードのために整数符号器のすぐ次の レベルに送ることができる。あるデータ値がこのバッファの中の値に合致する時 には、バッファの中の合致値インデックスを用いてあらわされる。別に、次のバ ッファ合致の前の合致しない値の数が記録される。バッファのサイズは、バイパ ステスト結果に従って調節される。時間が許す場合、あるアイテムを合致しない 値としてエンコードするためのコストは、バッファ合致としてそれをエンコード するコストとの間で兼合いを求められるが、低いオーバーヘッドのためにこの事 は、ＭＴＦアルゴリズムにとってはＬＺに対する場合に対する程には重要な問題 ではない。 このＭＴＦアルゴリズムは、個別のアイテムが合致するが、多ワード合致シー ケンスが少ない時には、整数ＬＺよりも能力が優れている。合致の冗長化された 探索を避けるために両アルゴリズムは、単一の変形ル ーチンに統合されて別個の出力配列を形成し、その後により性能の良かった方を 選ぶことが望ましい。 小さいサンプルセットを用いて合致アルゴリズムを判定するよりは、変形は完 全なデータブロックにおいて実行され、次にそれらを中レベルシミュレータに送 るために結果を判定することができる。アプリケーション環境が時間的に極めて 制約される場合に、この判定はブロックの一部のみが変形された後に行なわれる 。 多くの現実のデータセットの中では、値の表現におけるベース１０の個々の桁 は圧縮を高めるために解明することのできる特性を持つ。これらの特性は“分割 化(splitting)”と呼ばれるテクニックを用いて解明される。整数の配列は、２ つ以上の整数の個別の配列に分割され、ここでは各配列は、ソースアレーの中の 桁のサブセットから生成される。分割された配列のエンコードのための全コスト が、入力ソースアレーをエンコードするためのコストよりも小さい時に分割化は 有効である。分割化を用いて有効に処理される配列の一つの例は次のようなもの である。 ソースアレー アレー１ アレー２ アレー３ 10795484 107 95 484 11995460 119 95 460 13195399 131 95 399 12295501 122 95 501 11195453 111 95 453 11895469 118 95 469 分割の前のソースアレーは、２１ビットレンジ（１０７９５４８４−１３１９ ５３９９）の中でランダムに変化する様に見える。然し、分割の後には第１行は ４ビット／入力においてエンコードすることが可能であり、第２行は消減し、第 ３行は７ビットレンジ（３９９−５０１）に所属する。符号化のための全コスト は、ソースアレーを符号化するコス トの約半分である。更に各配列はしばしば幾つかの方法で分割することができる 。 分割化は、それが数を判定する他の方法にとって見出せない桁分野の間で時と して起きる相関性を見出すために有用である。この事は特にここでは重要である 、何故ならばレンジ再マップのために記載すべき変形のあるものがランダム数の ような低いビットを処理するからである。分割化を用いなければ多くのゼロの存 在のような低い桁における相関性は失われることになる。 高レベルモデラは、分割化に関する幾つかの決定を行なわねばならない。第１ にモデラは、使用すべき最良のモデルおよび分割化が他のエンコードのための代 わりの方法よりも有効であるか否かを決定する。第２にモデラは、合致アルゴリ ズムが分割化の行なわれる前に実行すべきか否かを決定する。最後にモデラは、 例えば数値変形、又は合致アルゴリズムの一つのような何れの高レベルアルゴリ ズムが分割化の後に分割アレーの各々に実行すべきかを決める。 分割化に従うべき関係は、通常ベース１０の表現においてしか可視的でないた めに、分割器の第１の動作は、データをベース１０の表現に変換することである 。場合によっては、ソースデータは当初は英数字表現であることも考えられ、こ のような場合の変形時間は、整数符号器に対する可視的アーギュメントとしてデ ータブロックの文字列表現を用いることにより、節約される。 分割器アルゴリズムを判定するためにヒストグラムが各桁に対して作られ、そ の桁分野の中の１０の可能な値の出現の頻度を示す。これらのヒストグラムは、 次に個別の配列に分割すべき桁分野を特定しグループ化するのに用いられる。配 列は、次に繰り返し変形が有効であるか否かをチェックされ、次にエンコードの ためのコストは中レベルシミュレータを用いて推定することができる。 図８は、整数符号器の中レベルの動作を示すフローチャートである。 アレーデータは、ステップ１０において入力され、先ずステップ１０３において レンジマップにより処理される。パックすべきエキストラビットは、ステップ１ ０５において格納される。得られたレンジ符号からステップ１０７においてＭＴ Ｆ符号器を用いるべきか否かの決定が行なわれる。この決定が肯定的であればＭ ＴＦ符号器がステップ１０９において実行される。最終レンジ符号は、ステップ １１０における低レベル符号器に対して与えられる。 この中レベル符号器は、低レベル符号器により効果的に処理することのできる サイズにアルファベットのサイズを減らし、又圧縮を最大にする方法で実施せね ばならない。この符号器は、レンジ再マップ（ステップ１０３）およびオプショ ンの変形後のＭＴＦ（ムーブ−トゥ−フロント）変形（ステップ１０９）を含む 。レンジ符号化は、位置成分をデータセットに再投入し、このレンジ符号の中で 当初の値が合致していなかった場合にも近くのレンジ符号に合致する傾向を示す ことがある。この現象が生じた場合、ＭＴＦ変形はこれらのシンボルをエンコー ドされたデータの流れに変換する低レベル符号器に送る前に実行される。中レベ ル符号器の出力は、低レベル符号器に送られる。中レベルシュミレータは、又エ ンコードコストを推定するための高レベルルーチンにより用いることもできる。 レンジ再マップは、整数をコードワードに変換する。各入力値は、単純なコー ドワードにより表現される。コードワードの数は、通常考えられるデータ値の数 以下であるから、コードワードのあるものは考えられる一つのソース値以上のも のを表現することができる。これらの場合においては、コードワードはある範囲 の値を示し、レンジ再マップはオフセットをこの範囲内にビットパックする。こ れは標準的な圧縮技術である。 標準アプローチは、予め限定されたレンジテーブルを使用し、低レベル符号器 がそのデータブロックにおいて最も通常のレンジに対するレン ジ符号に対して少ししかビットを使用せぬことを可能にする傾向を持つ。好まし いシステムは、各データブロックに対して最適化されるレンジテーブルを作り出 し、そのレンジ内のオフセットをパックするために用いられるビットの数を有意 義に減少させる。例えば固定されたレンジテーブルは、そのレンジにおける各入 力に対するオフセットをパックするために１６ビットを必要とする0x10000で始 まり0x20000で終るレンジを限定することがある。然しこのレンジ内の入力のす べては、値0x18000を持つことができる。好ましいシステムは、これを見出し、 エキストラビットを必要とせぬこの値に対するエキストラレンジを作り出す。 システムは、データブロックに高い頻度で出現する特定値を記載するために“ マジック値”の用語を使用する。これらの値は、特殊な処理を施される。なぜな らばデータレンジの中で出現する場所とは無関係にそれらはエキストラビットを 用いることなしにパックすべきであるからである。残りの“非マジック”に対し ては、データブロックの中の値の分布に適合する最適化レンジが生成される。 第１ステップは、ターゲットテーブルサイズを決定することである。テーブル 入力の各々は、レンジ再マップおよび低レベル符号器の両者に固定されたオーバ ーヘッドを必要とする。データブロックが小さければ使用されるテーブルも小さ くすべきである。しかし大きな数値レンジを持つデータブロックは、より優れた テーブルを用いて、より多くのビットを節約することができるために、テーブル のサイズは、又データレンジに対しても調節すべきである。各テーブル入力に対 する入力の目標数は、ｍｉｎ頻度と呼ばれ下記の式により計算される。 ｍｉｎ頻度＝入力のターゲット数／ターゲットテーブルサイズ （４） 最終テーブルサイズは、目標からかなり異なったものであるが、これによりテ ーブルの構成に用いるための値が得られる。データブロックの中の各値の頻度を 示す分類されたヒストグラムが次に生成される。この テーブルは、正の値のためのセクションと負の値のためのセクションの２つのセ クションを持つ。追随型レンジテーブルを生成するための一般的な手順が正のテ ーブルに対して記載される。 頻度＞０を持つ最小値から始め、これを我々の最初のレンジの“ベース”と呼 ぶ。その頻度がｍｉｎ頻度よりも小さい時には、レンジの中に含まれる値の全頻 度＞ｍｉｎ頻度となるまで、別の値を加えてレンジを拡大する。この時点でレン ジは次のサイズを持つ。 レンジサイズ＝ベースの最終値 （５） レンジの中の考えられるすべての値を表現するために必要なビットの数、ｎビ ットを求める。レンジをサイズ１＜＜ｎビットまで拡大する。 次のレンジは下記から始まる： ベース〔ｉ＋１〕＝ベース〔ｉ〕＋（１＜＜ｎビット〔ｉ〕） （６） 次の値＞＝ベース〔ｉ＋１〕に達するまでヒスト値を飛び越し、次に続くレン ジを生成する。負のテーブルは同じ方法であるが、−１から始まり、大きな負の 値に移行する。 実施例１０ この実施例は、一般的なアプローチを紹介するが、同時にマジック値を扱うこ とのできるように改変される。その頻度＞ｍｉｎ頻度である値はマジック値であ り、エキストラビット（Ｅビット）を必要とせぬ別個のテーブル入力に到達すべ きである。テーブルを作るプロセス中に一つが出現すると、マジック値を保持す る特別リストに加えられる。データレンジは、レンジからマジック値を除去する ためにコンパクト化される。 ｍｉｎ頻度＝１０の場合には、 値 頻度 マジック値の ベース オフセット Ｅビット 除去後の頻度 100 ４ ４ 100 ０ ２ 101 ３ ３ 100 １ ２ 102 12 ０ （マジック） （０） 103 ３ ３ 100 ２ ２ 104 ２ ２ 100 ３ ２ この実施例においてｍｉｎ頻度が１０であり、新たなレンジが値１００におい てスタートすべきであれば、‘１０２’の値はマジック値であり、そのベースが １００に在るレンジから削除される。このレンジに残る４つのすべての値（１０ ０、１０１、１０３、１０４）は、次に２ビットオフセットを用いて表現するこ とができる。 レンジテーブルは、各レンジに対するマジック値とＥビット（オフセットをエ ンコードするためのエキストラビットの数）を用いて再構成することができる。 Ｅビットをエンコードするためにその値が前のＥビット入力からのオフセットを あらわす２ビットコードが各入力に対して生成される。 ０：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕−１ １：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕 ２：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕＋１ ３：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕＋オフセット 但し、オフセットは、多数のＥビットを用いるサインされた値としてパックさ れる。 これらのコードの４つは、パックされて１バイト値にされ、次に低レベル符号 器が１バイトコードワードをエンコードするために予め限定された静的テーブル と共に使用される。サンプリング間隔が限定され、各サンプルグループに対して エキストラビット値（オフセットに対して必要なビットの最大値）が調節される 。いくつかのセットの低レベルエンコードテーブルも又生成され、コードテーブ ルはサンプルグループの中の動作の量（変更された全ビット）により選ばれる。 マジック値のリストをエンコードするために、リストは格納され、前 の値からのオフセットに変換される。これらのオフセットは次に２ビットコード を用いてエンコードされる。 ０：オフセット＝１ １：オフセット＝2-5、２つのＥビットをパックして何れかを選ぶ ２：オフセット＞＝6、オーバーサイズオフセットに対し特殊エンコード手順 を使用すること ３：前のオフセットをｒｐｔ ｃｔ（データブロックへの入力の数）回繰り返 すこと。ｒｐｔ ｃｔを見出すために用いられる２ビット符号は次の通りである ： ０：ｒｐｔ ｃｔ＝１ １：ｒｐｔ ｃｔ＝2、3、選択のためにＥビットをパックすること ２：ｒｐｔ ｃｔ＝4-6、選択のためにＥビットをパックすること、オフセ ット＝３を持つ符号２が特殊な最大ｒｐｔ値を示すために用いられる ３：ｒｐｔ ｃｔ＝7-22、選択のために４つのＥビットをパックすること これらの２ビット符号の４つが１バイトワードにパックされ、次にこのワード が前のワードにおける最後の２ビット符号に従って予め限定された静的テーブル を用いてエンコードされる。オーバーサイズオフセットは、静的に限定されたベ ース＋オフセットレンジテーブルを用いてエンコードされる。レンジ符号は、前 のレンジ符号に従って選ばれるテーブルを持つ低レベルエン符号器を用いてエン コードされる。オフセットはビットパックされる。 レンジコードは、しばしば位置的に相関化される。つまり、類似のコードは、 互いに近くに集まることができる。このような場合には、標準ＭＴＦ変換の中で 符号化を実行することにより、低レベル符号器における符号化を改善することが できる。その時にそれを用いている変形は有 効である。 高レベルモデラは、競合する高レベルアルゴリズムの中から選ぶために、しば しば１ブロックのエンコードコストの推定値を必要とする。シミュレータは、サ ンプル値のブロック並びにフルデータブロックのサイズを受け取る。シミュレー タは、フルデータブロックのエンコードのためのコストの推定値を生成するため にサンプルを使用する。この推定値を生成する時に、以下のように、いくつかの 改変が中レベル符号器の操作に施される。 （ａ）入力の数並びに入力テーブルに対して変更されたビットの全数に基づくモ デルを用いたテーブルのエンコードのコストの推定。 （ｂ）下記の標準式の高速近似化を用いる各符号の頻度から、レンジ符号をエン コードするコストの推定。 但し：頻度〔ｉ〕 ＝符号〔ｉ〕の頻度 全頻度 ＝すべての符号の全頻度 log2 ＝ベース２の対数 コスト ＝ブロックをエンコードするために必要とされるビッ ト数 （ｃ）レンジ内のオフセットをエンコードするために必要なエクストラビットを 計算すること。 （ｄ）中レベルＭＴＦを削除すること。 なお、本発明は、その好ましい実施形態に関して特定的に図示記載されている が、この分野の当業者によっては形態および詳細に於ける各種の変更を随意に請 求項により限定された発明の原理と範囲から逸脱せずに行なうことができるもの と理解される。この分野の当業者は、日常的な実験以上の手段を用いることなく この中に具体的に記載された発明の 特定の実施形態に対する多くの同等の事項を認識し、又は確認することができる であろう。このような同等の事項を請求項の範囲内に包含することが意図される 。

Claims (1)

1. 【特許請求の範囲】 １．データを符号化する方法であって、 ソースデータを複数のブロックに分解する分解工程と、 前記ブロックごとに、複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選 択する選択工程と、 前記ブロックごとに、前記選択された圧縮アルゴリズムを前記ソースデータに 適用する圧縮工程と、 前記複数のブロックから圧縮されたデータをエンコードデータに結合させる結 合工程とを備えた方法。 ２．請求項１において、 前記ソースデータが、第１データフォーマットで構成され、 前記分解工程が、前記ソースデータを第２データフォーマットへ変換する変換 工程を有する方法。 ３．請求項２において、 前記変換工程が、前記ソースデータからの類似のデータをそれぞれのブロック に集める工程を有する方法。 ４．請求項２において、 前記変換工程が、前記第１データフォーマットに基づく圧縮モデルを形成する 工程を有する方法。 ５．請求項１において、 前記圧縮アルゴリズムが、それぞれのブロック中のデータ量に基づいて決定さ れる方法。 ６．請求項１において、 前記圧縮アルゴリズムが、それぞれのブロックに適合している方法。 ７．請求項１において、 前記選択工程が、カスタマイズされた変形を形成する工程を有する方法。 ８．請求項１において、 前記エンコードデータから前記ソースデータを回復する工程を備えた方法。 ９．製造された物であって、 機械可読媒体と、 データ符号化ネットワークを実行するために前記機械可読媒体に記録された一 連の命令であって、ソースデータを複数のブロックに分解する分解工程と、前記 ブロックごとに複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選択する選 択工程と、前記ブロックごとに前記選択された圧縮アルゴリズムを前記ソースデ ータに適用する圧縮工程と、前記複数のブロックから圧縮されたデータをエンコ ードデータに結合させる結合工程とを有する一連の命令とを備えた製造物。 １０．請求項９において、 前記ソースデータが、第１データフォーマットで構成され、 前記分解工程が、前記ソースデータを第２データフォーマットへ変換する変換 工程を有する製造物。 １１．請求項１０において、 前記変換工程が、前記ソースデータからの類似のデータをそれぞれのブロック に集める工程を有する製造物。 １２．請求項１０において、 前記変換工程が、前記第１データフォーマットに基づく圧縮モデルを形成する 工程を有する製造物。 １３．請求項９において、 前記圧縮アルゴリズムが、それぞれのブロック中のデータ量に基づいて決定さ れる製造物。 １４．請求項９において、 前記圧縮アルゴリズムが、それぞれのブロックに適合している製造物。 １５．請求項９において、 前記選択工程が、カスタマイズされた変形を形成する工程を有する製造物。 １６．請求項９において、 前記一連の命令が、前記エンコードデータから前記ソースデータを回復する工 程を有する製造物。 １７．データを符号化する装置であって、 ソースデータを複数のブロックに分解する分解器と、 前記ブロックごとに、複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選 択する選択システムと、 前記ブロック中のデータを圧縮するために前記選択された圧縮アルゴリズムを 適用し、前記複数のブロックから圧縮されたデータをエンコードデータに結合さ せる符号器とを備えた装置。 １８．請求項１７において、 前記分解器が、前記ソースデータからの類似のデータをそれぞれのブロックに 集める装置。 １９．請求項１７において、 前記選択システムが、前記ブロック中のデータに適合可能な装置。 ２０．請求項１７において、 前記エンコードデータから前記ソースデータを回復する回復システムを備えた 装置。