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
【発明の属する技術分野】
この発明は、データ処理方法に関するものであり、具体的には、LZ77およびLZ78に代表される辞書ベース方式を基にしたデータ圧縮技術を用いて、画像データを効率的に圧縮するデータ処理方法に関する。
【0002】
【従来の技術】
現在の辞書ベースによるデータ圧縮方法の起源は、Abraham Lempel氏とJacob Ziv 氏とが1977年にIEEE Transaction on Information Theoryに発表した論文`AUniversal Algorithm for Sequential Data Compression´に見られる。これは、通称Lempel-Ziv符号化のスライド辞書法又はLZ77法と言われている。
【0003】
例えば、宗像清治:Ziv-Lempelのデ一タ圧縮法,情報処理,Vol.26.No.1(1985)に、それが紹介されている。
【0004】
LZ77のアルゴリズムは、符号化データを過去のデータ系列の任意の位置から一致する最大長の系列に区切り、過去の系列の複製として符号化する方法である。
【0005】
具体的には、図2に示すように、符号化済みの入力データを格納する移動窓と、これから符号化するデータを格納する先読みバッファとを備え、先読みバッファのデータ系列と移動窓のデータ系列のすべての部分系列とを照合して、移動窓中で一致する最大長の部分系列を求める。
【0006】
そして、移動窓中でこの最大長の部分系列を指定するために、「その最大長の部分系列の開始位置」と「一致する長さ」と「不一致をもたらした次のシンボル」との組を符号化する。
【0007】
次に、先読みバッファ内の符号化したデータ系列を移動窓に移して、先読みバッファ内に符号化したデータ系列分の新たなデータ系列を入力する。
【0008】
以下、同様の処理を繰り返していくことで、データを部分系列に分解して符号化を実行していくのである。
【0009】
そして、このような基本的なデータ圧縮技術に対して、多くの改良型が提案されている。
【0010】
例えば、符号化コードであるのか、生データであるのかを識別するフラグを設けて、符号化コードが生データよりも長くなってしまうときには生データを符号化するという方法をとるLZSS符号方式(T.C.Bell,“Better OPM/L Text Compression",IEEE Transaction Commun.,Vol.COM-34,No.12,Dec.(1986)) がある。
【0011】
また、他の文献としては、M.ネルソン:データ圧縮ハンドブック改訂第2版、トッパン(1996). ISBN4-8101-8605-9 がある。
【0012】
ところで、近年、OAシステム(スキャナ、プリンタ、ディジタル複写機など)が普及し、高速化・高解像度化の方向を目指している。
【0013】
これらの装置では、大容量の画像データを高速で処理する必要があり、高速・高圧縮率のデータ圧縮を加えることで、処理するデータ量を滅らすことが必須となっている。
【0014】
このようなデータ圧縮の従来技術としては、MMR、JBIGなど標準化された方式があるが、MMRは精細な画像で圧縮率が悪化する傾向にある。
【0015】
また、圧縮率の点ではべストに近いJBIGは基本的に画素単位の処理であるため高速化に限界があり、高速システムでは採用できなかった。
【0016】
しかるに、上述した辞書ベース圧縮方式は、基本的にバイト単位の処理であるためJBIGよりはるかに高速化が可能であり、また精細な画像に対してもMMRほど圧縮率が悪化しないという特徴があり、高速・高解像度のOAシステムに適している。
【0017】
【発明が解決しようとする課題】
しかしながら、従来のLZ77ベースによるデータ圧縮装置では、符号化する際、移動窓中で一致する最大長の部分データ列を求めるためには、これから符号化するデータ列と移動窓の中のすべての位置の間でデータ列比較を行わなければならない。
【0018】
すなわち、図2に示すように、これから符号化するデータ列を、移動窓中のオフセット1の位置から始まるデータ列、オフセット2の位置から始まるデータ列、…オフセットn(nは移動窓のサイズ)の位置から始まるデータ列と比較して、最大一致長が得られるオフセットを見つけることである。
【0019】
上記のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致(たとえば256)が得られるので、1データの比較を1回とカウントすると、各オフセットあたり256回の比較を行うことになり、データ列の比較時間が飛躍的に伸びるという問題があった。
【0020】
この発明の目的は、上記した事情に鑑みなされたものであって、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供することにある。
【0021】
【課題を解決するための手段】
上記課題を解決し目的を達成するために、この発明のデータ圧縮方法は、下記に示す通りである。
【0022】
この発明は、画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【0023】
この発明は、画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較の対象として、前記オフセット1、L、L+1、及びL−1のシンボルを優先的に選択する。
【0024】
この発明は、画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較対象優先順位を優先度の高いものから順に、前記オフセットL、1、L−1、L+1、L−2、L+2、…、L−n、及びL+nのシンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で一致長の検出を終了し、この検出された一致長を基にして符号化を行う。
【0025】
【発明の実施の形態】
以下、この発明の実施の形態について図面を参照して説明する。
【0026】
まず、二次元的に近い位置から比較ポイントを選択する点を説明する。
【0027】
従来例で述べたように、LZ77ベースの圧縮をソフトウェアで実現しようとすると、もっとも単純なインプリメントでは、符号か位置から始まるデータ列と、移動窓中のすべての位置から始まるデータ列とを比較し、最長の一致位置を検出することになる。この方式では、移動窓を大きくとったときに処理速度の低下が著しい。
【0028】
そこで、第1の発明では、LZ77をベースとしながらも、これから符号化するデータ列を移動窓中のすべての位置から始まるデータ列と比較するのではなく、一致する可能性の高い位置から始まるデータ列だけを比較対象とすることで、処理速度向上を図っている。例えば、比較対象位置として16あるいは32程度で実現するものである。
【0029】
しかしながら、単純に比較対象位置の数を減らしただけでは、一致する可能性が小さくなり圧縮率が低下すると考えられる。第1の発明では、画像データの周期性に着目して比較対照する位置を選択している。すなわち、移動窓中のすべての部分列を比較するのでなく、画像データ周期性に着目して、一致する可能性の高いデータ位置だけを比較する。
【0030】
以下、図1を基に第1の発明の原理を説明する。ここでは圧縮対象のデータの単位をバイト単位としている。画像データの2次元的な局所性を考慮すると、あるバイトともっとも類似性が高いのはその上下左右の位置である。画像データの入力順として一般的な左上から右下へのラスタスキャンを考えると、あるバイトに対して、右と下の隣接バイトはこれから入力されるものであるため移動窓にはまだ入っていない。したがって右と下の隣接バイトを比較対象とすることはできない。左の隣接バイトは入力順で一つ前に入力したもっとも最近のデータであり、移動窓中でオフセット1の位置に入っている。上の隣接バイトは、入力画像データのライン長(横幅)がバイト数でLとすると、移動窓中のオフセットLの位置に入っている。ただし、移動窓のサイズがL以上であることが条件である。従来のLZ系コーデックは、入力が画像データであっても、その周期性を無視して左方向だけで一致するポイントを探していたことになる。ここでは、左方向に加えて上方向に隣接する位置とその周辺を比較ポイントに選んでいる。図1において、ひし形は、これから符号化するデータの先頭バイトを示し、イコールは、これから符号化するデータ系列を示し、黒塗り四角は、移動窓のうち比較ポイントとするバイト位置を示し、しろ抜きの四角は、移動窓のうち比較ポイントとしないバイト位置を示す。すなわち、ここでは、比較対象として、16箇所のオフセット位置(1、L−7、L−6、L−5、L−4、L−3、L−2、L−1、L、L+1、L+2、L+3、L+4、L+5、L+6、L+7)から始まるデータ列を選んでいる。Lは画像のライン長(主走査方法のサイズ)であり、あらかじめ外部から設定されている。
【0031】
比較対象位置が少なくすることは、オフセット符号を短くできる点でも優れている。例えば、移動窓のサイズを2kBとすると、従来例ではオフセットとして2k通りの符号が必要になるが、図1の例ではオフセットとして16通りしか必要ないので、単純な符号を選んだ場合、従来例では11ビットのオフセット符号長になるのに対して、この発明では4ビットと短い。
【0032】
さらに、この発明では、各オフセットにおける一致長を求める順番と最長一致探索打ち切り条件を組み合わせて圧縮処理の高速化を図っている。この発明の16箇所の比較ポイントに対して、単純に最長一致を求めるやり方は次のようになる。
【0033】
16箇所の比較ポイントに対して単純に最長一致を求めるモジュール
{符号化位置からのデータ列とオフセット1からのデータ列の一致長を求め、結果をlen1とする
符号化位置からのデータ列とオフセットL−7からのデータ列の一致長を求め、結果をlen(L−7)とする
符号化位置からのデータ列とオフセットL−6からのデータ列の一致長を求め、結果をlen(L−6)とする
…
符号化位置からのデータ列とオフセットL+6からのデータ列の一致長を求め、結果をlen(L+6)とする
符号化位置からのデータ列とオフセットL+7からのデータ列の一致長を求め、結果をlen(L+7)とする
len1、len(L−7)、(L−6)…、len(L+7)の最大値とそのときのオフセットを返す}
各オフセットで一致長を求める際には、一致長符号の構成で上限を決めて、長い一致が得られても上限で比較処理をうち切る。たとえば一致長符号の最大長が256となっている場合には、一致の検出が256に達したところでその後の比較をうち切り、256を一致長とする。
【0034】
従来のような最大一致長を求める方式では、それぞれのオフセットとも長い一致が得られる場合に処理速度が落ちるという欠点がある。たとえば画像の白い部分を符号化すると、すべてのオフセットとの比較で最長の一致(たとえば256)が得られるので、1データの比較を1回とカウントすると、各オフセットあたり256回、計2096回の比較を行うことになる。
【0035】
この発明では、256が最大の一致長であることに着目して、256という一致長がえられた時点で残りのオフセットの比較をうち切ることで高速化を図る。ただし、通常はオフセット符号、一致長符号ともハフマン符号を用いるので、長い一致長が得られそうなオフセットに短いオフセット符号を割り当てている。たとえばこの発明のようにオフセットを選んだ場合は、これから符号化する位置に近い方が高い類似度を持つと考えられるので、Lに最短の符号を割り当て、以下、L−1、L+1、L−1、L+1、L−2、L+2…、L−7、L+7の順に短い符号を割り当てるのがよい。このとき、次のように単純に最大一致長で打ち切りを導入すると、最短でないオフセットが選ばれることがあり、最適とは言えない。
【0036】
この発明の16箇所の比較ポイントに対して単純に最長一致を求めるモジュールに打ち切りを導入
{符号化位置からのデータ列とオフセット1からのデータ列の一致長を求め、結果をlen1とする
len1=256なら、オフセット=1、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL−7からのデータ列の一致長を求め、結果をlen(L−7)とする
len(L−7)=256なら、オフセット=L−7、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL−6からのデータ列の一致長を求め、結果をlen(L−6)とする
len(L−6)=256なら、オフセット=L−6、一致長=256としてモジュール終了
…
符号化位置からのデータ列とオフセットL+6からのデータ列の一致長を求め、結果をlen(L+6)とする
len(L+6)=256なら、オフセット=L+6、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL+7からのデータ列の一致長を求め、結果をlen(L+7)とする
len(L+7)=256なら、オフセット=L+7、一致長=256としてモジュール終了
len1、len(L−7)、(L−6)…、len(L+6)、len(L+7)の最大値とそのときのオフセットを返す}
この順に探索すると、画像の白い部分ではオフセット1が選ばれることになるが、最短の符号を割り当てたのはオフセットLなので、最適符号とはならない。この点を改善するためには、つぎのように探索順をオフセット符号の短い順(長くない順)にすればよい。
【0037】
打ち切りを導入し探索位置を改善(この発明の方式)
{符号化位置からのデータ列とオフセットLからのデータ列の一致長を求め、結果をlenLとする
lenL=256なら、オフセット=L、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットLからのデータ列の一致長を求め、結果をlenLとする
len=1なら、オフセット=1、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL−1からのデータ列の一致長を求め、結果をlen(L−1)とする
len(L−1)=256なら、オフセット=L−1,一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL+1からのデータ列の一致長を求め、結果をlen(L+1)とする
len(L+1)=256なら、オフセット=L+1,一致長=256としてモジュール終了
…
符号化位置からのデータ列とオフセットL−7からのデータ列の一致長を求め、結果をlen(L−7)とする
len(L−7)=256なら、オフセット=L−7、一致長=256としてモジュール終了
符号化位置からのデータ列とオフセットL+7からのデータ列の一致長を求め、結果をlen(L+7)とする
len(L+7)=256なら、オフセット=L+7,一致長=256としてモジュール終了
len1、len(L−7)、(L−6)…、len(L+6)、len(L+7)の最大値とその時のオフセットを返す}
この場合、256の一致が発生してそれ以降の一致長探索を中断したとしても必ずもっとも短いオフセット符号となるオフセットが選ばれるので、符号化効率の改善と処理高速化を両立できる。たとえば画像の白い部分に対しては、当初の方法では計4096回の比較が必要であったが、本発明の方式では256回の比較でよく、しかも発生する符号は同じになる。
【0038】
符号化効率は多少落ちても高速化を実現しようとして、この発明の探索打ち切り条件を、一致長符号の最大値よりも小さく設定するようにしてもよい。例えば、一致長符号の最大値が256のとき、128を越える一致が得られたらそれ以降の探索を行わない、とすることで、多少符号化効率は落ちるものの、高速化を実現できる。
【0039】
次に、第2の発明について説明する。
【0040】
最長一致位置を求めるモジュールでは、符号化位置からのデータ列とそれぞれのオフセット位置から始まるデータ列とを比較して一致長を求める作業を行う、この発明では、計16個所のオフセットに対して比較を行っている。符号化単位をバイトしたとき、単純にインプリメントすると、従来は、下記に示すように、1バイトづつ比較することになる。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
while(*offset==*cp) count++
return(count)
}
8ビットCPUで圧縮処理を行う場合はこれでもよいが、最近のように32ビットなどのCPUへの実装を考えると次のように高速化できる。CPUの自然なデータ長を32ビットとしたとき、この第2の発明では、下記に示すようにインプリメントする。
int search_maechlen(BYTE*offset, BYTE*cp){
count=0
(offsetとcpの差が4バイトの倍数でなければ従来例のように1バイト単位に比較し、そうでなければ以下の処理を行う)
(offsetとcpは4バイト境界に一致するまで1〜3バイト比較)
while(*(int)offset==*(int)cp) count+=4 //4バイト単位に比較
(最終不一致の4バイトないで1〜3バイト一致しているか、一致していればその分count追加)
return (count)
}
オフセットが4バイトの倍数でなければ、4バイト単位の比較ができないので従来のように1バイト単位で比較する。オフセットが4バイトの倍数の場合、4バイト境界に一致した部分は4バイト単位で比較できるので、まず4バイト境界まで一致しているかどうかを1バイト単位で1〜3バイト比較する。4バイト境界に一致した後は4バイト単位で高速に比較する。不一致が発生するか、一致長符号の上限に達するまで続ける。不一致が発生したときも最後の4バイト境界内で1〜3バイト一致している可能性があるので、1バイト単位で比較する。
【0041】
一般的な32ビットCPUでは1バイト比較と4バイト比較は同じサイクルで処理される。したがってこの発明のように比較を行うことで最大4倍の高速化が実現できる。
【0042】
次に、第3の発明について説明する。
【0043】
伸長処理では、符号をデコードして一致オフセットと一致長を求め、データバッファの一致オフセットから一致長分だけデータをコピーし、新たなデコードデータとしてデータ出力に追加する作業を繰り返すことになる。このとき、単純にインプリメントすると、従来は、下記に示すように1バイトずつメモリコピーを行うことになる。
void matchl_copy( BYTE*offset, BY TE*cp, int length){
memcpy_in_BYTE(cp, offset, length)
}
第2の発明と同様に、最近のように32ビットなどのCPUへの実装を考えると次のように高速化できる。CPUの自然データ長を32ビットとしたとき、この第3の発明では、下記に示すようにインプリメントする。
void matchl_copy( BYTE*offset, BY TE*cp, int length){ (offsetとcpの差が4バイトの倍数でなければ従来例のように1バイト単位にコピーし、そうでなければ以下の処理を行う)
(offsetとcpは4バイト境界に一致するまで1〜3バイトコピー)
memcpy_in_4BYTE(cp, offset, length) //4バイト単位にメモリコピー
(余りがあれば、1〜3バイト分コピー)
}オフセットが4バイトの倍数でなければ、4バイト単位のメモリコピーができないので従来例のように1バイト単位でメモリコピーを行う。オフセットが4バイトの倍数の場合、4バイト境界に一致した部分は4バイト単位でメモリコピーできるので、まず4バイト境界まで1バイト単位で1〜3バイトメモリコピーする。4バイト境界に一致した後は4バイト単位で一致長に達するまで高速にメモリコピーを行う。最後に4バイト境界ないであまりがある場合は、
1バイト単位でメモリコピーを行う。
【0044】
一般的な32ビットCPUでは1バイトメモリコピーと4バイトメモリコピーは同じサイクルで処理される。したがって、この第3の発明のようにメモリコピーを行うことで最大4倍の高速化が実現できる。
【0045】
次に、この発明のポイントの一覧をまとめる。
【0046】
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関数をそのプロセッサのネイティブワード長(32ビットプロセッサなら4バイト)で比較する。
<伸長>
一致符号から原画像を形成するとき、ワード境界が一致したら、memcpy動作を4バイトコピー命令で実行する。
【0047】
上記したように、この発明は、LZ77ベースの圧縮装置をソフトウェアで実現する際に、画像データの周期性に着目して効率的に最長一致を与えるオフセットを探索し、最長一致を与えるオフセットが見つかった時点で、一致長の探索を終了する。これにより、余分な一致長探索処理を省略することができ、圧縮処理速度を向上させることができる。また、夫々のオフセットで一致長を調べる際に、例えば圧縮の単位(1バイト)と、圧縮ソフトウェアを実装するプロセッサのネイティブワード長(例えば32ビットプロセッサの場合4バイト)とが異なるときに、プロセッサのネイティブワード長で一致の比較を行うことで処理効率を向上させることができる。さらに、伸張処理をソフトウェアで実装する際に、一致符号のデコードにおいて、プロセッサのネイティブワード長でメモリコピーを行うことで処理効率を向上させることもできる。
【0048】
【発明の効果】
この発明によれば、同一データが連続する圧縮対象データ、つまり比較的長い一致長が得られる圧縮対象データを高速に圧縮することが可能なデータ圧縮方法を提供できる。
【0049】
(1)従来のLZ77ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象とするすべてオフセット位置の間でデータ列比較を行うため、たとえば文書の周辺部などすべて白からなる部分で無駄な比較を行っていた。この発明では、画像データの周期性に注目し、2次元的に近いオフセット位置から比較し、一致符号で規定した最大一致長に達するオフセット位置が得られた時点でその他のオフセット位置との比較を取りやめることで、圧縮処理時間を短縮することができる。
【0050】
また、一致符号で規定した最大一致長に達しなくとも、予め一致長のしきい値を設定しておき、それ以上の一致長が得られたらその後のオフセットとの比較を取りやめることで類似の効果が得られる。この場合最適の圧縮率が得られないことも有り得るが、しきい値を調整することで圧縮率の低下を押さえることもできる。
【0051】
(2)従来のLZ77ベースのデータ圧縮装置をソフトウェアで実現する際には、これから符号化するデータ列と比較対象のオフセット位置からのデータ列を比較し、一致長を調べる必要がある。従来は、圧縮の処理単位が1バイトのときは、両データ列を1バイト単位で比較して一致長を求めていた。この発明では、圧縮の単位(たとえば1バイト)より、圧縮ソフトウェアを実装するプロセサのネイティブワード長(たとえば32ビットプロセサの場合4バイト)が大である場合、プロセサのネイティブワード長でデータ列の比較を行うことで処理効率が向上する。
【0052】
(3)従来のLZ77ベースのデータ伸長装置をソフトウェアで実現する際には、一致符号のデコードにおいて、一致符号の示すオフセット位置から一致長分の原データをコピーする必要があり、従来は圧縮の処理単位(たとえば1バイト)でメモリコピーを行っていた。本発明では、圧縮の単位(たとえば1バイト)より、圧縮ソフトウェアを実装するプロセサのネイティブワード長(たとえば32ビットプロセサの場合4バイト)が大である場合、プロセサのネイティブワード長でメモリコピーを行うことで処理効率が向上する。
【図面の簡単な説明】
【図1】この発明に係るデータ圧縮方法の概略を説明するための図。
【図2】従来のデータ圧縮方法の概略を説明するための図。
Claims (8)
- 画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出し符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較の対象として、前記オフセット1、L、L+1、及びL−1のシンボルを優先的に選択し、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して符号化するとき、前記符号化対象シンボルに含まれる前記特定のシンボルの比較対象優先順位を優先度の高いものから順に、前記オフセットL、1、L−1、L+1、L−2、L+2、…、L−n、及びL+nのシンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、予め規定された最大一致長が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。 - 圧縮処理を担う演算処理部がnビットの演算処理部の場合、nビットの単位でデータを圧縮することを特徴とする請求項1、請求項2、又は請求項3に記載のデータ処理方法。
- 1シンボルが8ビットのデータであり、圧縮処理を担う演算処理部がnビットの演算処理部の場合、(n/8×シンボル)の単位でデータを圧縮することを特徴とする請求項1、請求項2、又は請求項3に記載のデータ処理方法。
- 符号化された符号化データストリームを伸張するために、符号化データストリームに含まれる一部のデータをコピーするとき、データのコピーを行う演算処理部がnビットの演算処理部の場合、nビットの単位でデータをコピーすることを特徴とする請求項1、請求項2、請求項3、請求項4、又は請求項5に記載のデータ処理方法。
- 符号化された符号化データストリームを伸張するために、符号化データストリームに含まれる一部のデータをコピーするとき、1シンボルが8ビットのデータであり、データのコピーを行う演算処理部がnビットの演算処理部の場合、(n/8×シンボル)の単位でデータをコピーすることを特徴とする請求項1、請求項2、請求項3、請求項4、又は請求項5に記載のデータ処理方法。
- 画像の走査により得られるこの画像のライン長Lの複数ラインに相当する画像データストリームを符号化して、この画像データストリームを圧縮するデータ処理方法において、
前記画像データストリームに含まれる特定のシンボル、及びこの特定のシンボルを先頭とした複数のシンボルを符号化対象シンボルとし、前記特定のシンボルの上流側に隣接するオフセット1のシンボル、及び前記特定のシンボルから1ライン長離れたオフセットLのシンボルを中心としたストリームの上流側及び下流側のオフセットL+n〜オフセットL−nの複数のシンボルを比較対象シンボルとし、前記符号化対象シンボルと前記比較対象シンボルとを順次比較して一致長を検出するとき、一致長符号の最大値の半分を超える一致が得られた時点で残りの比較を打ち切り一致長の検出を終了し、この検出された一致長を基にして符号化を行うことを特徴とするデータ処理方法。
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 |