JP3839604B2 - データ処理方法 - Google Patents
データ処理方法 Download PDFInfo
- Publication number
- JP3839604B2 JP3839604B2 JP36370098A JP36370098A JP3839604B2 JP 3839604 B2 JP3839604 B2 JP 3839604B2 JP 36370098 A JP36370098 A JP 36370098A JP 36370098 A JP36370098 A JP 36370098A JP 3839604 B2 JP3839604 B2 JP 3839604B2
- Authority
- JP
- Japan
- Prior art keywords
- symbol
- offset
- data
- length
- encoding
- 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
Landscapes
- Compression Of Band Width Or Redundancy In Fax (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、データ処理方法に関するものであり、具体的には、ＬＺ７７およびＬＺ７８に代表される辞書ベース方式を基にしたデータ圧縮技術を用いて、画像データを効率的に圧縮するデータ処理方法に関する。
【０００２】
【従来の技術】
現在の辞書ベースによるデータ圧縮方法の起源は、Abraham Lempel氏とJacob Ziv 氏とが１９７７年にIEEE Transaction on Information Theoryに発表した論文｀AUniversal Algorithm for Sequential Data Compression´に見られる。これは、通称Lempel-Ziv符号化のスライド辞書法又はＬＺ７７法と言われている。
【０００３】
例えば、宗像清治：Ziv-Lempelのデ一タ圧縮法，情報処理，Ｖｏｌ．２６．Ｎｏ．１（１９８５）に、それが紹介されている。
【０００４】
ＬＺ７７のアルゴリズムは、符号化データを過去のデータ系列の任意の位置から一致する最大長の系列に区切り、過去の系列の複製として符号化する方法である。
【０００５】
具体的には、図２に示すように、符号化済みの入力データを格納する移動窓と、これから符号化するデータを格納する先読みバッファとを備え、先読みバッファのデータ系列と移動窓のデータ系列のすべての部分系列とを照合して、移動窓中で一致する最大長の部分系列を求める。
【０００６】
そして、移動窓中でこの最大長の部分系列を指定するために、「その最大長の部分系列の開始位置」と「一致する長さ」と「不一致をもたらした次のシンボル」との組を符号化する。
【０００７】
次に、先読みバッファ内の符号化したデータ系列を移動窓に移して、先読みバッファ内に符号化したデータ系列分の新たなデータ系列を入力する。
【０００８】
以下、同様の処理を繰り返していくことで、データを部分系列に分解して符号化を実行していくのである。
【０００９】
そして、このような基本的なデータ圧縮技術に対して、多くの改良型が提案されている。
【００１０】
例えば、符号化コードであるのか、生データであるのかを識別するフラグを設けて、符号化コードが生データよりも長くなってしまうときには生データを符号化するという方法をとるＬＺＳＳ符号方式(T.C.Bell,“Better OPM/L Text Compression",IEEE Transaction Commun.,Vol.COM-34,No.12,Dec.(1986)) がある。
【００１１】
また、他の文献としては、Ｍ．ネルソン：データ圧縮ハンドブック改訂第２版、トッパン(1996). ISBN4-8101-8605-9 がある。
【００１２】
ところで、近年、ＯＡシステム（スキャナ、プリンタ、ディジタル複写機など）が普及し、高速化・高解像度化の方向を目指している。
【００１３】
これらの装置では、大容量の画像データを高速で処理する必要があり、高速・高圧縮率のデータ圧縮を加えることで、処理するデータ量を滅らすことが必須となっている。
【００１４】
このようなデータ圧縮の従来技術としては、ＭＭＲ、ＪＢＩＧなど標準化された方式があるが、ＭＭＲは精細な画像で圧縮率が悪化する傾向にある。
【００１５】
また、圧縮率の点ではべストに近いＪＢＩＧは基本的に画素単位の処理であるため高速化に限界があり、高速システムでは採用できなかった。
【００１６】
しかるに、上述した辞書ベース圧縮方式は、基本的にバイト単位の処理であるためＪＢＩＧよりはるかに高速化が可能であり、また精細な画像に対してもＭＭＲほど圧縮率が悪化しないという特徴があり、高速・高解像度のＯＡシステムに適している。
【００１７】
【発明が解決しようとする課題】
しかしながら、従来のＬＺ７７ベースによるデータ圧縮装置では、符号化する際、移動窓中で一致する最大長の部分データ列を求めるためには、これから符号化するデータ列と移動窓の中のすべての位置の間でデータ列比較を行わなければならない。
【００１８】
すなわち、図２に示すように、これから符号化するデータ列を、移動窓中のオフセット１の位置から始まるデータ列、オフセット２の位置から始まるデータ列、…オフセットｎ（ｎは移動窓のサイズ）の位置から始まるデータ列と比較して、最大一致長が得られるオフセットを見つけることである。
【００１９】
上記のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致（たとえば２５６）が得られるので、１データの比較を１回とカウントすると、各オフセットあたり２５６回の比較を行うことになり、データ列の比較時間が飛躍的に伸びるという問題があった。
【００２０】
この発明の目的は、上記した事情に鑑みなされたものであって、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供することにある。
【００２１】
【課題を解決するための手段】
上記課題を解決し目的を達成するために、この発明のデータ圧縮方法は、下記に示す通りである。
【００２２】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【００２３】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較の対象として、前記オフセット１、Ｌ、Ｌ＋１、及びＬ−１のシンボルを優先的に選択する。
【００２４】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較対象優先順位を優先度の高いものから順に、前記オフセットＬ、１、Ｌ−１、Ｌ＋１、Ｌ−２、Ｌ＋２、…、Ｌ−ｎ、及びＬ＋ｎのシンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【００２５】
【発明の実施の形態】
以下、この発明の実施の形態について図面を参照して説明する。
【００２６】
まず、二次元的に近い位置から比較ポイントを選択する点を説明する。
【００２７】
従来例で述べたように、ＬＺ７７ベースの圧縮をソフトウェアで実現しようとすると、もっとも単純なインプリメントでは、符号か位置から始まるデータ列と、移動窓中のすべての位置から始まるデータ列とを比較し、最長の一致位置を検出することになる。この方式では、移動窓を大きくとったときに処理速度の低下が著しい。
【００２８】
そこで、第１の発明では、ＬＺ７７をベースとしながらも、これから符号化するデータ列を移動窓中のすべての位置から始まるデータ列と比較するのではなく、一致する可能性の高い位置から始まるデータ列だけを比較対象とすることで、処理速度向上を図っている。例えば、比較対象位置として１６あるいは３２程度で実現するものである。
【００２９】
しかしながら、単純に比較対象位置の数を減らしただけでは、一致する可能性が小さくなり圧縮率が低下すると考えられる。第１の発明では、画像データの周期性に着目して比較対照する位置を選択している。すなわち、移動窓中のすべての部分列を比較するのでなく、画像データ周期性に着目して、一致する可能性の高いデータ位置だけを比較する。
【００３０】
以下、図１を基に第１の発明の原理を説明する。ここでは圧縮対象のデータの単位をバイト単位としている。画像データの２次元的な局所性を考慮すると、あるバイトともっとも類似性が高いのはその上下左右の位置である。画像データの入力順として一般的な左上から右下へのラスタスキャンを考えると、あるバイトに対して、右と下の隣接バイトはこれから入力されるものであるため移動窓にはまだ入っていない。したがって右と下の隣接バイトを比較対象とすることはできない。左の隣接バイトは入力順で一つ前に入力したもっとも最近のデータであり、移動窓中でオフセット１の位置に入っている。上の隣接バイトは、入力画像データのライン長（横幅）がバイト数でＬとすると、移動窓中のオフセットＬの位置に入っている。ただし、移動窓のサイズがＬ以上であることが条件である。従来のＬＺ系コーデックは、入力が画像データであっても、その周期性を無視して左方向だけで一致するポイントを探していたことになる。ここでは、左方向に加えて上方向に隣接する位置とその周辺を比較ポイントに選んでいる。図１において、ひし形は、これから符号化するデータの先頭バイトを示し、イコールは、これから符号化するデータ系列を示し、黒塗り四角は、移動窓のうち比較ポイントとするバイト位置を示し、しろ抜きの四角は、移動窓のうち比較ポイントとしないバイト位置を示す。すなわち、ここでは、比較対象として、１６箇所のオフセット位置（１、Ｌ−７、Ｌ−６、Ｌ−５、Ｌ−４、Ｌ−３、Ｌ−２、Ｌ−１、Ｌ、Ｌ＋１、Ｌ＋２、Ｌ＋３、Ｌ＋４、Ｌ＋５、Ｌ＋６、Ｌ＋７）から始まるデータ列を選んでいる。Ｌは画像のライン長（主走査方法のサイズ）であり、あらかじめ外部から設定されている。
【００３１】
比較対象位置が少なくすることは、オフセット符号を短くできる点でも優れている。例えば、移動窓のサイズを２ｋＢとすると、従来例ではオフセットとして２ｋ通りの符号が必要になるが、図１の例ではオフセットとして１６通りしか必要ないので、単純な符号を選んだ場合、従来例では１１ビットのオフセット符号長になるのに対して、この発明では４ビットと短い。
【００３２】
さらに、この発明では、各オフセットにおける一致長を求める順番と最長一致探索打ち切り条件を組み合わせて圧縮処理の高速化を図っている。この発明の１６箇所の比較ポイントに対して、単純に最長一致を求めるやり方は次のようになる。
【００３３】
１６箇所の比較ポイントに対して単純に最長一致を求めるモジュール
｛符号化位置からのデータ列とオフセット１からのデータ列の一致長を求め、結果をｌｅｎ１とする
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
符号化位置からのデータ列とオフセットＬ−６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−６）とする
…
符号化位置からのデータ列とオフセットＬ＋６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋６）とする
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋７）の最大値とそのときのオフセットを返す｝
各オフセットで一致長を求める際には、一致長符号の構成で上限を決めて、長い一致が得られても上限で比較処理をうち切る。たとえば一致長符号の最大長が２５６となっている場合には、一致の検出が２５６に達したところでその後の比較をうち切り、２５６を一致長とする。
【００３４】
従来のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致（たとえば２５６）が得られるので、１データの比較を１回とカウントすると、各オフセットあたり２５６回、計２０９６回の比較を行うことになる。
【００３５】
この発明では、２５６が最大の一致長であることに着目して、２５６という一致長がえられた時点で残りのオフセットの比較をうち切ることで高速化を図る。ただし、通常はオフセット符号、一致長符号ともハフマン符号を用いるので、長い一致長が得られそうなオフセットに短いオフセット符号を割り当てている。たとえばこの発明のようにオフセットを選んだ場合は、これから符号化する位置に近い方が高い類似度を持つと考えられるので、Ｌに最短の符号を割り当て、以下、Ｌ−１、Ｌ＋１、Ｌ−１、Ｌ＋１、Ｌ−２、Ｌ＋２…、Ｌ−７、Ｌ＋７の順に短い符号を割り当てるのがよい。このとき、次のように単純に最大一致長で打ち切りを導入すると、最短でないオフセットが選ばれることがあり、最適とは言えない。
【００３６】
この発明の１６箇所の比較ポイントに対して単純に最長一致を求めるモジュールに打ち切りを導入
｛符号化位置からのデータ列とオフセット１からのデータ列の一致長を求め、結果をｌｅｎ１とする
ｌｅｎ１＝２５６なら、オフセット＝１、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
ｌｅｎ（Ｌ−７）＝２５６なら、オフセット＝Ｌ−７、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−６）とする
ｌｅｎ（Ｌ−６）＝２５６なら、オフセット＝Ｌ−６、一致長＝２５６としてモジュール終了
…
符号化位置からのデータ列とオフセットＬ＋６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋６）とする
ｌｅｎ（Ｌ＋６）＝２５６なら、オフセット＝Ｌ＋６、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ（Ｌ＋７）＝２５６なら、オフセット＝Ｌ＋７、一致長＝２５６としてモジュール終了
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋６）、ｌｅｎ（Ｌ＋７）の最大値とそのときのオフセットを返す｝
この順に探索すると、画像の白い部分ではオフセット１が選ばれることになるが、最短の符号を割り当てたのはオフセットＬなので、最適符号とはならない。この点を改善するためには、つぎのように探索順をオフセット符号の短い順（長くない順）にすればよい。
【００３７】
打ち切りを導入し探索位置を改善（この発明の方式）
｛符号化位置からのデータ列とオフセットＬからのデータ列の一致長を求め、結果をｌｅｎＬとする
ｌｅｎＬ＝２５６なら、オフセット＝Ｌ、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬからのデータ列の一致長を求め、結果をｌｅｎＬとする
ｌｅｎ＝１なら、オフセット＝１、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−１からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−１）とする
ｌｅｎ（Ｌ−１）＝２５６なら、オフセット＝Ｌ−１，一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋１からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋１）とする
ｌｅｎ（Ｌ＋１）＝２５６なら、オフセット＝Ｌ＋１，一致長＝２５６としてモジュール終了
…
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
ｌｅｎ（Ｌ−７）＝２５６なら、オフセット＝Ｌ−７、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ（Ｌ＋７）＝２５６なら、オフセット＝Ｌ＋７，一致長＝２５６としてモジュール終了
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋６）、ｌｅｎ（Ｌ＋７）の最大値とその時のオフセットを返す｝
この場合、２５６の一致が発生してそれ以降の一致長探索を中断したとしても必ずもっとも短いオフセット符号となるオフセットが選ばれるので、符号化効率の改善と処理高速化を両立できる。たとえば画像の白い部分に対しては、当初の方法では計４０９６回の比較が必要であったが、本発明の方式では２５６回の比較でよく、しかも発生する符号は同じになる。
【００３８】
符号化効率は多少落ちても高速化を実現しようとして、この発明の探索打ち切り条件を、一致長符号の最大値よりも小さく設定するようにしてもよい。例えば、一致長符号の最大値が２５６のとき、１２８を越える一致が得られたらそれ以降の探索を行わない、とすることで、多少符号化効率は落ちるものの、高速化を実現できる。
【００３９】
次に、第２の発明について説明する。
【００４０】
最長一致位置を求めるモジュールでは、符号化位置からのデータ列とそれぞれのオフセット位置から始まるデータ列とを比較して一致長を求める作業を行う、この発明では、計１６個所のオフセットに対して比較を行っている。符号化単位をバイトしたとき、単純にインプリメントすると、従来は、下記に示すように、１バイトづつ比較することになる。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
while(*offset==*cp) count++
return(count)
}
８ビットＣＰＵで圧縮処理を行う場合はこれでもよいが、最近のように３２ビットなどのＣＰＵへの実装を考えると次のように高速化できる。ＣＰＵの自然なデータ長を３２ビットとしたとき、この第２の発明では、下記に示すようにインプリメントする。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
（offsetとcpの差が４バイトの倍数でなければ従来例のように１バイト単位に比較し、そうでなければ以下の処理を行う）
（offsetとcpは４バイト境界に一致するまで１〜３バイト比較）
while(*(int)offset==*(int)cp) count+=4 //4バイト単位に比較
（最終不一致の４バイトないで１〜３バイト一致しているか、一致していればその分count追加）
return (count)
}
オフセットが４バイトの倍数でなければ、４バイト単位の比較ができないので従来のように１バイト単位で比較する。オフセットが４バイトの倍数の場合、４バイト境界に一致した部分は４バイト単位で比較できるので、まず４バイト境界まで一致しているかどうかを１バイト単位で１〜３バイト比較する。４バイト境界に一致した後は４バイト単位で高速に比較する。不一致が発生するか、一致長符号の上限に達するまで続ける。不一致が発生したときも最後の４バイト境界内で１〜３バイト一致している可能性があるので、１バイト単位で比較する。
【００４１】
一般的な３２ビットＣＰＵでは１バイト比較と４バイト比較は同じサイクルで処理される。したがってこの発明のように比較を行うことで最大４倍の高速化が実現できる。
【００４２】
次に、第３の発明について説明する。
【００４３】
伸長処理では、符号をデコードして一致オフセットと一致長を求め、データバッファの一致オフセットから一致長分だけデータをコピーし、新たなデコードデータとしてデータ出力に追加する作業を繰り返すことになる。このとき、単純にインプリメントすると、従来は、下記に示すように１バイトずつメモリコピーを行うことになる。
void matchl_copy( BYTE*offset, BY TE*cp, int length){
memcpy_in_BYTE(cp, offset, length)
}
第２の発明と同様に、最近のように３２ビットなどのＣＰＵへの実装を考えると次のように高速化できる。ＣＰＵの自然データ長を３２ビットとしたとき、この第３の発明では、下記に示すようにインプリメントする。
void matchl_copy( BYTE*offset, BY TE*cp, int length){ （offsetとcpの差が４バイトの倍数でなければ従来例のように１バイト単位にコピーし、そうでなければ以下の処理を行う）
（offsetとcpは４バイト境界に一致するまで１〜３バイトコピー）
memcpy_in_4BYTE(cp, offset, length) //4バイト単位にメモリコピー
（余りがあれば、１〜３バイト分コピー）
}オフセットが４バイトの倍数でなければ、４バイト単位のメモリコピーができないので従来例のように１バイト単位でメモリコピーを行う。オフセットが４バイトの倍数の場合、４バイト境界に一致した部分は４バイト単位でメモリコピーできるので、まず４バイト境界まで１バイト単位で１〜３バイトメモリコピーする。４バイト境界に一致した後は４バイト単位で一致長に達するまで高速にメモリコピーを行う。最後に４バイト境界ないであまりがある場合は、
１バイト単位でメモリコピーを行う。
【００４４】
一般的な３２ビットＣＰＵでは１バイトメモリコピーと４バイトメモリコピーは同じサイクルで処理される。したがって、この第３の発明のようにメモリコピーを行うことで最大４倍の高速化が実現できる。
【００４５】
次に、この発明のポイントの一覧をまとめる。
【００４６】
Lempel- Ziv方式（移動窓方式）の圧縮伸長をソフトウェアで表現するとき
＜圧縮＞
先に調べたオフセットで長い一致が得られれば他のオフセットは調査しない。
（従来）
for (from offset1 to offset N){
len 1 = search_matchlen( offset 1, current_pointer)
len 2 = search_matchlen( offset 2, current_pointer)
len 3 = search_matchlen( offset 3, current_pointer)
…
}
maxlen = max(len 1, len 2...)
（本発明）
for ( from offset 1 to offset N){
if ( len 1 = search_matchlen( offset 1, current_pointer)＞＝thresh_len) break
if ( len 2 = search_matchlen( offset 2, current_pointer)＞＝thresh_len) break
if ( len 3 = search_matchlen( offset 3, current_pointer)＞＝thresh_len) break
…
}
maxlen = max(len 1, len 2...)
search_matchlen関数をそのプロセッサのネイティブワード長（３２ビットプロセッサなら４バイト）で比較する。
＜伸長＞
一致符号から原画像を形成するとき、ワード境界が一致したら、memcpy動作を４バイトコピー命令で実行する。
【００４７】
上記したように、この発明は、ＬＺ７７ベースの圧縮装置をソフトウェアで実現する際に、画像データの周期性に着目して効率的に最長一致を与えるオフセットを探索し、最長一致を与えるオフセットが見つかった時点で、一致長の探索を終了する。これにより、余分な一致長探索処理を省略することができ、圧縮処理速度を向上させることができる。また、夫々のオフセットで一致長を調べる際に、例えば圧縮の単位（１バイト）と、圧縮ソフトウェアを実装するプロセッサのネイティブワード長（例えば３２ビットプロセッサの場合４バイト）とが異なるときに、プロセッサのネイティブワード長で一致の比較を行うことで処理効率を向上させることができる。さらに、伸張処理をソフトウェアで実装する際に、一致符号のデコードにおいて、プロセッサのネイティブワード長でメモリコピーを行うことで処理効率を向上させることもできる。
【００４８】
【発明の効果】
この発明によれば、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供できる。
【００４９】
（１）従来のＬＺ７７ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象とするすべてオフセット位置の間でデータ列比較を行うため、たとえば文書の周辺部などすべて白からなる部分で無駄な比較を行っていた。この発明では、画像データの周期性に注目し、２次元的に近いオフセット位置から比較し、一致符号で規定した最大一致長に達するオフセット位置が得られた時点でその他のオフセット位置との比較を取りやめることで、圧縮処理時間を短縮することができる。
【００５０】
また、一致符号で規定した最大一致長に達しなくとも、予め一致長のしきい値を設定しておき、それ以上の一致長が得られたらその後のオフセットとの比較を取りやめることで類似の効果が得られる。この場合最適の圧縮率が得られないことも有り得るが、しきい値を調整することで圧縮率の低下を押さえることもできる。
【００５１】
（２）従来のＬＺ７７ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象のオフセット位置からのデータ列を比較し、一致長を調べる必要がある。従来は、圧縮の処理単位が１バイトのときは、両データ列を１バイト単位で比較して一致長を求めていた。この発明では、圧縮の単位（たとえば１バイト）より、圧縮ソフトウェアを実装するプロセサのネイティブワード長（たとえば３２ビットプロセサの場合４バイト）が大である場合、プロセサのネイティブワード長でデータ列の比較を行うことで処理効率が向上する。
【００５２】
（３）従来のＬＺ７７ベースのデータ伸長装置をソフトウェアで実現する際には、一致符号のデコードにおいて、一致符号の示すオフセット位置から一致長分の原データをコピーする必要があり、従来は圧縮の処理単位（たとえば１バイト）でメモリコピーを行っていた。本発明では、圧縮の単位（たとえば１バイト）より、圧縮ソフトウェアを実装するプロセサのネイティブワード長（たとえば３２ビットプロセサの場合４バイト）が大である場合、プロセサのネイティブワード長でメモリコピーを行うことで処理効率が向上する。
【図面の簡単な説明】
【図１】この発明に係るデータ圧縮方法の概略を説明するための図。
【図２】従来のデータ圧縮方法の概略を説明するための図。
【発明の属する技術分野】
この発明は、データ処理方法に関するものであり、具体的には、ＬＺ７７およびＬＺ７８に代表される辞書ベース方式を基にしたデータ圧縮技術を用いて、画像データを効率的に圧縮するデータ処理方法に関する。
【０００２】
【従来の技術】
現在の辞書ベースによるデータ圧縮方法の起源は、Abraham Lempel氏とJacob Ziv 氏とが１９７７年にIEEE Transaction on Information Theoryに発表した論文｀AUniversal Algorithm for Sequential Data Compression´に見られる。これは、通称Lempel-Ziv符号化のスライド辞書法又はＬＺ７７法と言われている。
【０００３】
例えば、宗像清治：Ziv-Lempelのデ一タ圧縮法，情報処理，Ｖｏｌ．２６．Ｎｏ．１（１９８５）に、それが紹介されている。
【０００４】
ＬＺ７７のアルゴリズムは、符号化データを過去のデータ系列の任意の位置から一致する最大長の系列に区切り、過去の系列の複製として符号化する方法である。
【０００５】
具体的には、図２に示すように、符号化済みの入力データを格納する移動窓と、これから符号化するデータを格納する先読みバッファとを備え、先読みバッファのデータ系列と移動窓のデータ系列のすべての部分系列とを照合して、移動窓中で一致する最大長の部分系列を求める。
【０００６】
そして、移動窓中でこの最大長の部分系列を指定するために、「その最大長の部分系列の開始位置」と「一致する長さ」と「不一致をもたらした次のシンボル」との組を符号化する。
【０００７】
次に、先読みバッファ内の符号化したデータ系列を移動窓に移して、先読みバッファ内に符号化したデータ系列分の新たなデータ系列を入力する。
【０００８】
以下、同様の処理を繰り返していくことで、データを部分系列に分解して符号化を実行していくのである。
【０００９】
そして、このような基本的なデータ圧縮技術に対して、多くの改良型が提案されている。
【００１０】
例えば、符号化コードであるのか、生データであるのかを識別するフラグを設けて、符号化コードが生データよりも長くなってしまうときには生データを符号化するという方法をとるＬＺＳＳ符号方式(T.C.Bell,“Better OPM/L Text Compression",IEEE Transaction Commun.,Vol.COM-34,No.12,Dec.(1986)) がある。
【００１１】
また、他の文献としては、Ｍ．ネルソン：データ圧縮ハンドブック改訂第２版、トッパン(1996). ISBN4-8101-8605-9 がある。
【００１２】
ところで、近年、ＯＡシステム（スキャナ、プリンタ、ディジタル複写機など）が普及し、高速化・高解像度化の方向を目指している。
【００１３】
これらの装置では、大容量の画像データを高速で処理する必要があり、高速・高圧縮率のデータ圧縮を加えることで、処理するデータ量を滅らすことが必須となっている。
【００１４】
このようなデータ圧縮の従来技術としては、ＭＭＲ、ＪＢＩＧなど標準化された方式があるが、ＭＭＲは精細な画像で圧縮率が悪化する傾向にある。
【００１５】
また、圧縮率の点ではべストに近いＪＢＩＧは基本的に画素単位の処理であるため高速化に限界があり、高速システムでは採用できなかった。
【００１６】
しかるに、上述した辞書ベース圧縮方式は、基本的にバイト単位の処理であるためＪＢＩＧよりはるかに高速化が可能であり、また精細な画像に対してもＭＭＲほど圧縮率が悪化しないという特徴があり、高速・高解像度のＯＡシステムに適している。
【００１７】
【発明が解決しようとする課題】
しかしながら、従来のＬＺ７７ベースによるデータ圧縮装置では、符号化する際、移動窓中で一致する最大長の部分データ列を求めるためには、これから符号化するデータ列と移動窓の中のすべての位置の間でデータ列比較を行わなければならない。
【００１８】
すなわち、図２に示すように、これから符号化するデータ列を、移動窓中のオフセット１の位置から始まるデータ列、オフセット２の位置から始まるデータ列、…オフセットｎ（ｎは移動窓のサイズ）の位置から始まるデータ列と比較して、最大一致長が得られるオフセットを見つけることである。
【００１９】
上記のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致（たとえば２５６）が得られるので、１データの比較を１回とカウントすると、各オフセットあたり２５６回の比較を行うことになり、データ列の比較時間が飛躍的に伸びるという問題があった。
【００２０】
この発明の目的は、上記した事情に鑑みなされたものであって、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供することにある。
【００２１】
【課題を解決するための手段】
上記課題を解決し目的を達成するために、この発明のデータ圧縮方法は、下記に示す通りである。
【００２２】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【００２３】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較の対象として、前記オフセット１、Ｌ、Ｌ＋１、及びＬ−１のシンボルを優先的に選択する。
【００２４】
この発明は、画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較対象優先順位を優先度の高いものから順に、前記オフセットＬ、１、Ｌ−１、Ｌ＋１、Ｌ−２、Ｌ＋２、…、Ｌ−ｎ、及びＬ＋ｎのシンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【００２５】
【発明の実施の形態】
以下、この発明の実施の形態について図面を参照して説明する。
【００２６】
まず、二次元的に近い位置から比較ポイントを選択する点を説明する。
【００２７】
従来例で述べたように、ＬＺ７７ベースの圧縮をソフトウェアで実現しようとすると、もっとも単純なインプリメントでは、符号か位置から始まるデータ列と、移動窓中のすべての位置から始まるデータ列とを比較し、最長の一致位置を検出することになる。この方式では、移動窓を大きくとったときに処理速度の低下が著しい。
【００２８】
そこで、第１の発明では、ＬＺ７７をベースとしながらも、これから符号化するデータ列を移動窓中のすべての位置から始まるデータ列と比較するのではなく、一致する可能性の高い位置から始まるデータ列だけを比較対象とすることで、処理速度向上を図っている。例えば、比較対象位置として１６あるいは３２程度で実現するものである。
【００２９】
しかしながら、単純に比較対象位置の数を減らしただけでは、一致する可能性が小さくなり圧縮率が低下すると考えられる。第１の発明では、画像データの周期性に着目して比較対照する位置を選択している。すなわち、移動窓中のすべての部分列を比較するのでなく、画像データ周期性に着目して、一致する可能性の高いデータ位置だけを比較する。
【００３０】
以下、図１を基に第１の発明の原理を説明する。ここでは圧縮対象のデータの単位をバイト単位としている。画像データの２次元的な局所性を考慮すると、あるバイトともっとも類似性が高いのはその上下左右の位置である。画像データの入力順として一般的な左上から右下へのラスタスキャンを考えると、あるバイトに対して、右と下の隣接バイトはこれから入力されるものであるため移動窓にはまだ入っていない。したがって右と下の隣接バイトを比較対象とすることはできない。左の隣接バイトは入力順で一つ前に入力したもっとも最近のデータであり、移動窓中でオフセット１の位置に入っている。上の隣接バイトは、入力画像データのライン長（横幅）がバイト数でＬとすると、移動窓中のオフセットＬの位置に入っている。ただし、移動窓のサイズがＬ以上であることが条件である。従来のＬＺ系コーデックは、入力が画像データであっても、その周期性を無視して左方向だけで一致するポイントを探していたことになる。ここでは、左方向に加えて上方向に隣接する位置とその周辺を比較ポイントに選んでいる。図１において、ひし形は、これから符号化するデータの先頭バイトを示し、イコールは、これから符号化するデータ系列を示し、黒塗り四角は、移動窓のうち比較ポイントとするバイト位置を示し、しろ抜きの四角は、移動窓のうち比較ポイントとしないバイト位置を示す。すなわち、ここでは、比較対象として、１６箇所のオフセット位置（１、Ｌ−７、Ｌ−６、Ｌ−５、Ｌ−４、Ｌ−３、Ｌ−２、Ｌ−１、Ｌ、Ｌ＋１、Ｌ＋２、Ｌ＋３、Ｌ＋４、Ｌ＋５、Ｌ＋６、Ｌ＋７）から始まるデータ列を選んでいる。Ｌは画像のライン長（主走査方法のサイズ）であり、あらかじめ外部から設定されている。
【００３１】
比較対象位置が少なくすることは、オフセット符号を短くできる点でも優れている。例えば、移動窓のサイズを２ｋＢとすると、従来例ではオフセットとして２ｋ通りの符号が必要になるが、図１の例ではオフセットとして１６通りしか必要ないので、単純な符号を選んだ場合、従来例では１１ビットのオフセット符号長になるのに対して、この発明では４ビットと短い。
【００３２】
さらに、この発明では、各オフセットにおける一致長を求める順番と最長一致探索打ち切り条件を組み合わせて圧縮処理の高速化を図っている。この発明の１６箇所の比較ポイントに対して、単純に最長一致を求めるやり方は次のようになる。
【００３３】
１６箇所の比較ポイントに対して単純に最長一致を求めるモジュール
｛符号化位置からのデータ列とオフセット１からのデータ列の一致長を求め、結果をｌｅｎ１とする
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
符号化位置からのデータ列とオフセットＬ−６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−６）とする
…
符号化位置からのデータ列とオフセットＬ＋６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋６）とする
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋７）の最大値とそのときのオフセットを返す｝
各オフセットで一致長を求める際には、一致長符号の構成で上限を決めて、長い一致が得られても上限で比較処理をうち切る。たとえば一致長符号の最大長が２５６となっている場合には、一致の検出が２５６に達したところでその後の比較をうち切り、２５６を一致長とする。
【００３４】
従来のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致（たとえば２５６）が得られるので、１データの比較を１回とカウントすると、各オフセットあたり２５６回、計２０９６回の比較を行うことになる。
【００３５】
この発明では、２５６が最大の一致長であることに着目して、２５６という一致長がえられた時点で残りのオフセットの比較をうち切ることで高速化を図る。ただし、通常はオフセット符号、一致長符号ともハフマン符号を用いるので、長い一致長が得られそうなオフセットに短いオフセット符号を割り当てている。たとえばこの発明のようにオフセットを選んだ場合は、これから符号化する位置に近い方が高い類似度を持つと考えられるので、Ｌに最短の符号を割り当て、以下、Ｌ−１、Ｌ＋１、Ｌ−１、Ｌ＋１、Ｌ−２、Ｌ＋２…、Ｌ−７、Ｌ＋７の順に短い符号を割り当てるのがよい。このとき、次のように単純に最大一致長で打ち切りを導入すると、最短でないオフセットが選ばれることがあり、最適とは言えない。
【００３６】
この発明の１６箇所の比較ポイントに対して単純に最長一致を求めるモジュールに打ち切りを導入
｛符号化位置からのデータ列とオフセット１からのデータ列の一致長を求め、結果をｌｅｎ１とする
ｌｅｎ１＝２５６なら、オフセット＝１、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
ｌｅｎ（Ｌ−７）＝２５６なら、オフセット＝Ｌ−７、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−６）とする
ｌｅｎ（Ｌ−６）＝２５６なら、オフセット＝Ｌ−６、一致長＝２５６としてモジュール終了
…
符号化位置からのデータ列とオフセットＬ＋６からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋６）とする
ｌｅｎ（Ｌ＋６）＝２５６なら、オフセット＝Ｌ＋６、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ（Ｌ＋７）＝２５６なら、オフセット＝Ｌ＋７、一致長＝２５６としてモジュール終了
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋６）、ｌｅｎ（Ｌ＋７）の最大値とそのときのオフセットを返す｝
この順に探索すると、画像の白い部分ではオフセット１が選ばれることになるが、最短の符号を割り当てたのはオフセットＬなので、最適符号とはならない。この点を改善するためには、つぎのように探索順をオフセット符号の短い順（長くない順）にすればよい。
【００３７】
打ち切りを導入し探索位置を改善（この発明の方式）
｛符号化位置からのデータ列とオフセットＬからのデータ列の一致長を求め、結果をｌｅｎＬとする
ｌｅｎＬ＝２５６なら、オフセット＝Ｌ、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬからのデータ列の一致長を求め、結果をｌｅｎＬとする
ｌｅｎ＝１なら、オフセット＝１、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ−１からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−１）とする
ｌｅｎ（Ｌ−１）＝２５６なら、オフセット＝Ｌ−１，一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋１からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋１）とする
ｌｅｎ（Ｌ＋１）＝２５６なら、オフセット＝Ｌ＋１，一致長＝２５６としてモジュール終了
…
符号化位置からのデータ列とオフセットＬ−７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ−７）とする
ｌｅｎ（Ｌ−７）＝２５６なら、オフセット＝Ｌ−７、一致長＝２５６としてモジュール終了
符号化位置からのデータ列とオフセットＬ＋７からのデータ列の一致長を求め、結果をｌｅｎ（Ｌ＋７）とする
ｌｅｎ（Ｌ＋７）＝２５６なら、オフセット＝Ｌ＋７，一致長＝２５６としてモジュール終了
ｌｅｎ１、ｌｅｎ（Ｌ−７）、（Ｌ−６）…、ｌｅｎ（Ｌ＋６）、ｌｅｎ（Ｌ＋７）の最大値とその時のオフセットを返す｝
この場合、２５６の一致が発生してそれ以降の一致長探索を中断したとしても必ずもっとも短いオフセット符号となるオフセットが選ばれるので、符号化効率の改善と処理高速化を両立できる。たとえば画像の白い部分に対しては、当初の方法では計４０９６回の比較が必要であったが、本発明の方式では２５６回の比較でよく、しかも発生する符号は同じになる。
【００３８】
符号化効率は多少落ちても高速化を実現しようとして、この発明の探索打ち切り条件を、一致長符号の最大値よりも小さく設定するようにしてもよい。例えば、一致長符号の最大値が２５６のとき、１２８を越える一致が得られたらそれ以降の探索を行わない、とすることで、多少符号化効率は落ちるものの、高速化を実現できる。
【００３９】
次に、第２の発明について説明する。
【００４０】
最長一致位置を求めるモジュールでは、符号化位置からのデータ列とそれぞれのオフセット位置から始まるデータ列とを比較して一致長を求める作業を行う、この発明では、計１６個所のオフセットに対して比較を行っている。符号化単位をバイトしたとき、単純にインプリメントすると、従来は、下記に示すように、１バイトづつ比較することになる。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
while(*offset==*cp) count++
return(count)
}
８ビットＣＰＵで圧縮処理を行う場合はこれでもよいが、最近のように３２ビットなどのＣＰＵへの実装を考えると次のように高速化できる。ＣＰＵの自然なデータ長を３２ビットとしたとき、この第２の発明では、下記に示すようにインプリメントする。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
（offsetとcpの差が４バイトの倍数でなければ従来例のように１バイト単位に比較し、そうでなければ以下の処理を行う）
（offsetとcpは４バイト境界に一致するまで１〜３バイト比較）
while(*(int)offset==*(int)cp) count+=4 //4バイト単位に比較
（最終不一致の４バイトないで１〜３バイト一致しているか、一致していればその分count追加）
return (count)
}
オフセットが４バイトの倍数でなければ、４バイト単位の比較ができないので従来のように１バイト単位で比較する。オフセットが４バイトの倍数の場合、４バイト境界に一致した部分は４バイト単位で比較できるので、まず４バイト境界まで一致しているかどうかを１バイト単位で１〜３バイト比較する。４バイト境界に一致した後は４バイト単位で高速に比較する。不一致が発生するか、一致長符号の上限に達するまで続ける。不一致が発生したときも最後の４バイト境界内で１〜３バイト一致している可能性があるので、１バイト単位で比較する。
【００４１】
一般的な３２ビットＣＰＵでは１バイト比較と４バイト比較は同じサイクルで処理される。したがってこの発明のように比較を行うことで最大４倍の高速化が実現できる。
【００４２】
次に、第３の発明について説明する。
【００４３】
伸長処理では、符号をデコードして一致オフセットと一致長を求め、データバッファの一致オフセットから一致長分だけデータをコピーし、新たなデコードデータとしてデータ出力に追加する作業を繰り返すことになる。このとき、単純にインプリメントすると、従来は、下記に示すように１バイトずつメモリコピーを行うことになる。
void matchl_copy( BYTE*offset, BY TE*cp, int length){
memcpy_in_BYTE(cp, offset, length)
}
第２の発明と同様に、最近のように３２ビットなどのＣＰＵへの実装を考えると次のように高速化できる。ＣＰＵの自然データ長を３２ビットとしたとき、この第３の発明では、下記に示すようにインプリメントする。
void matchl_copy( BYTE*offset, BY TE*cp, int length){ （offsetとcpの差が４バイトの倍数でなければ従来例のように１バイト単位にコピーし、そうでなければ以下の処理を行う）
（offsetとcpは４バイト境界に一致するまで１〜３バイトコピー）
memcpy_in_4BYTE(cp, offset, length) //4バイト単位にメモリコピー
（余りがあれば、１〜３バイト分コピー）
}オフセットが４バイトの倍数でなければ、４バイト単位のメモリコピーができないので従来例のように１バイト単位でメモリコピーを行う。オフセットが４バイトの倍数の場合、４バイト境界に一致した部分は４バイト単位でメモリコピーできるので、まず４バイト境界まで１バイト単位で１〜３バイトメモリコピーする。４バイト境界に一致した後は４バイト単位で一致長に達するまで高速にメモリコピーを行う。最後に４バイト境界ないであまりがある場合は、
１バイト単位でメモリコピーを行う。
【００４４】
一般的な３２ビットＣＰＵでは１バイトメモリコピーと４バイトメモリコピーは同じサイクルで処理される。したがって、この第３の発明のようにメモリコピーを行うことで最大４倍の高速化が実現できる。
【００４５】
次に、この発明のポイントの一覧をまとめる。
【００４６】
Lempel- Ziv方式（移動窓方式）の圧縮伸長をソフトウェアで表現するとき
＜圧縮＞
先に調べたオフセットで長い一致が得られれば他のオフセットは調査しない。
（従来）
for (from offset1 to offset N){
len 1 = search_matchlen( offset 1, current_pointer)
len 2 = search_matchlen( offset 2, current_pointer)
len 3 = search_matchlen( offset 3, current_pointer)
…
}
maxlen = max(len 1, len 2...)
（本発明）
for ( from offset 1 to offset N){
if ( len 1 = search_matchlen( offset 1, current_pointer)＞＝thresh_len) break
if ( len 2 = search_matchlen( offset 2, current_pointer)＞＝thresh_len) break
if ( len 3 = search_matchlen( offset 3, current_pointer)＞＝thresh_len) break
…
}
maxlen = max(len 1, len 2...)
search_matchlen関数をそのプロセッサのネイティブワード長（３２ビットプロセッサなら４バイト）で比較する。
＜伸長＞
一致符号から原画像を形成するとき、ワード境界が一致したら、memcpy動作を４バイトコピー命令で実行する。
【００４７】
上記したように、この発明は、ＬＺ７７ベースの圧縮装置をソフトウェアで実現する際に、画像データの周期性に着目して効率的に最長一致を与えるオフセットを探索し、最長一致を与えるオフセットが見つかった時点で、一致長の探索を終了する。これにより、余分な一致長探索処理を省略することができ、圧縮処理速度を向上させることができる。また、夫々のオフセットで一致長を調べる際に、例えば圧縮の単位（１バイト）と、圧縮ソフトウェアを実装するプロセッサのネイティブワード長（例えば３２ビットプロセッサの場合４バイト）とが異なるときに、プロセッサのネイティブワード長で一致の比較を行うことで処理効率を向上させることができる。さらに、伸張処理をソフトウェアで実装する際に、一致符号のデコードにおいて、プロセッサのネイティブワード長でメモリコピーを行うことで処理効率を向上させることもできる。
【００４８】
【発明の効果】
この発明によれば、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供できる。
【００４９】
（１）従来のＬＺ７７ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象とするすべてオフセット位置の間でデータ列比較を行うため、たとえば文書の周辺部などすべて白からなる部分で無駄な比較を行っていた。この発明では、画像データの周期性に注目し、２次元的に近いオフセット位置から比較し、一致符号で規定した最大一致長に達するオフセット位置が得られた時点でその他のオフセット位置との比較を取りやめることで、圧縮処理時間を短縮することができる。
【００５０】
また、一致符号で規定した最大一致長に達しなくとも、予め一致長のしきい値を設定しておき、それ以上の一致長が得られたらその後のオフセットとの比較を取りやめることで類似の効果が得られる。この場合最適の圧縮率が得られないことも有り得るが、しきい値を調整することで圧縮率の低下を押さえることもできる。
【００５１】
（２）従来のＬＺ７７ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象のオフセット位置からのデータ列を比較し、一致長を調べる必要がある。従来は、圧縮の処理単位が１バイトのときは、両データ列を１バイト単位で比較して一致長を求めていた。この発明では、圧縮の単位（たとえば１バイト）より、圧縮ソフトウェアを実装するプロセサのネイティブワード長（たとえば３２ビットプロセサの場合４バイト）が大である場合、プロセサのネイティブワード長でデータ列の比較を行うことで処理効率が向上する。
【００５２】
（３）従来のＬＺ７７ベースのデータ伸長装置をソフトウェアで実現する際には、一致符号のデコードにおいて、一致符号の示すオフセット位置から一致長分の原データをコピーする必要があり、従来は圧縮の処理単位（たとえば１バイト）でメモリコピーを行っていた。本発明では、圧縮の単位（たとえば１バイト）より、圧縮ソフトウェアを実装するプロセサのネイティブワード長（たとえば３２ビットプロセサの場合４バイト）が大である場合、プロセサのネイティブワード長でメモリコピーを行うことで処理効率が向上する。
【図面の簡単な説明】
【図１】この発明に係るデータ圧縮方法の概略を説明するための図。
【図２】従来のデータ圧縮方法の概略を説明するための図。
Claims (8)
- 画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出し符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較の対象として、前記オフセット１、Ｌ、Ｌ＋１、及びＬ−１のシンボルを優先的に選択し、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較対象優先順位を優先度の高いものから順に、前記オフセットＬ、１、Ｌ−１、Ｌ＋１、Ｌ−２、Ｌ＋２、…、Ｌ−ｎ、及びＬ＋ｎのシンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 圧縮処理を担う演算処理部がｎビットの演算処理部の場合、ｎビットの単位でデータを圧縮することを特徴とする請求項１、請求項２、又は請求項３に記載のデータ処理方法。
- １シンボルが８ビットのデータであり、圧縮処理を担う演算処理部がｎビットの演算処理部の場合、（ｎ／８×シンボル）の単位でデータを圧縮することを特徴とする請求項１、請求項２、又は請求項３に記載のデータ処理方法。
- 符号化された符号化データストリームを伸張するために、符号化データストリームに含まれる一部のデータをコピーするとき、データのコピーを行う演算処理部がｎビットの演算処理部の場合、ｎビットの単位でデータをコピーすることを特徴とする請求項１、請求項２、請求項３、請求項４、又は請求項５に記載のデータ処理方法。
- 符号化された符号化データストリームを伸張するために、符号化データストリームに含まれる一部のデータをコピーするとき、１シンボルが８ビットのデータであり、データのコピーを行う演算処理部がｎビットの演算処理部の場合、（ｎ／８×シンボル）の単位でデータをコピーすることを特徴とする請求項１、請求項２、請求項３、請求項４、又は請求項５に記載のデータ処理方法。
- 画像の走査により得られるこの画像のライン長Ｌの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット１のシンボル、及び前記特定のシンボルから１ライン長離れたオフセットＬのシンボルを中心としたストリームの上流側及び下流側のオフセットＬ＋ｎ〜オフセットＬ−ｎの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、一致長符号の最大値の半分を超える一致が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36370098A JP3839604B2 (ja) | 1998-12-22 | 1998-12-22 | データ処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP36370098A JP3839604B2 (ja) | 1998-12-22 | 1998-12-22 | データ処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000188692A JP2000188692A (ja) | 2000-07-04 |
| JP3839604B2 true JP3839604B2 (ja) | 2006-11-01 |
Family
ID=18479975
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP36370098A Expired - Fee Related JP3839604B2 (ja) | 1998-12-22 | 1998-12-22 | データ処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3839604B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006295853A (ja) * | 2005-04-14 | 2006-10-26 | Sony Corp | 符号化装置、復号装置、および、符号化方法ならびに復号方法 |
| GB2469955B (en) * | 2008-01-31 | 2012-09-12 | Fujitsu Ltd | Data compression/decompression method,and compression/decompression program |
| JP5521501B2 (ja) * | 2009-11-09 | 2014-06-18 | セイコーエプソン株式会社 | 画像処理装置、および、画像処理方法 |
| JP5895545B2 (ja) * | 2012-01-17 | 2016-03-30 | 富士通株式会社 | プログラム、圧縮ファイル生成方法、圧縮符号伸張方法、情報処理装置、および記録媒体 |
| JP2013214832A (ja) * | 2012-03-30 | 2013-10-17 | Fujitsu Ltd | 圧縮及び伸長システム、圧縮装置、伸長装置、圧縮及び伸長方法、圧縮プログラム及び伸長プログラム |
| EP3041145B1 (en) * | 2013-08-30 | 2019-04-10 | Fujitsu Limited | Data compression device, method, and program |
-
1998
- 1998-12-22 JP JP36370098A patent/JP3839604B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000188692A (ja) | 2000-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100300789B1 (ko) | 적응형 데이터 압축기의 데이터 압축 효율을 개선하는 방법및 장치 | |
| US7492290B1 (en) | Alternative encoding for LZSS output | |
| US7403136B2 (en) | Block data compression system, comprising a compression device and a decompression device and method for rapid block data compression with multi-byte search | |
| CN108768403B (zh) | 基于lzw的无损数据压缩、解压方法及lzw编码器、解码器 | |
| JP3541930B2 (ja) | 符号化装置及び復号化装置 | |
| JP2581903B2 (ja) | バイト整列式データ圧縮方法及び装置 | |
| KR100950607B1 (ko) | 허프만 코딩 | |
| US7079051B2 (en) | In-place differential compression | |
| US6650261B2 (en) | Sliding window compression method utilizing defined match locations | |
| JP3634711B2 (ja) | 入力データストリームの圧縮方法とその装置 | |
| US10587285B1 (en) | Hardware friendly data compression | |
| KR100353171B1 (ko) | 적응형데이터압축을수행하는방법및장치 | |
| US5177622A (en) | Method and apparatus for detecting run length of two successive pixels and subjecting run length to universal coding | |
| EP2317476A2 (en) | Multimedia signature coding and decoding | |
| JP3730385B2 (ja) | デ−タ圧縮装置 | |
| JP3839604B2 (ja) | データ処理方法 | |
| KR100382649B1 (ko) | 하드 카피 장치용 데이타 압축 및 복원 방법들 및 장치들 | |
| US20140321765A1 (en) | Feature descriptor encoding apparatus, feature descriptor encoding method, and program | |
| JP4000266B2 (ja) | データ符号化装置、データ符号化方法、及びそのプログラム | |
| US20080001790A1 (en) | Method and system for enhancing data compression | |
| GB2360915A (en) | Run length compression encoding of selected bits of data words | |
| JP3083550B2 (ja) | データ圧縮及び復元方法 | |
| JP2612343B2 (ja) | データ圧縮方式 | |
| KR100462603B1 (ko) | 영상 데이타 압축 및 복원 방법 및 장치 | |
| GB2360916A (en) | Compression encoder which transmits difference between new data word and recent data word where this falls within a threshold |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051004 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20051004 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20051004 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060509 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060707 |
|
| 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: 20060801 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060803 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090811 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100811 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110811 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120811 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |