JPH0955858A

JPH0955858A - 画像データ処理装置

Info

Publication number: JPH0955858A
Application number: JP20861195A
Authority: JP
Inventors: Hiromichi Ogasawara; 弘道小笠原
Original assignee: NEC Engineering Ltd
Current assignee: NEC Engineering Ltd
Priority date: 1995-08-16
Filing date: 1995-08-16
Publication date: 1997-02-25

Abstract

(57)【要約】【課題】特別なハードウェアや非常に高速な処理能力
を持つＣＰＵを使用することなく、簡単なソフトウェア
で高速な画像データ圧縮伸張処理を実現する。【解決手段】ＣＰＵ１の処理に従い、画像入力装置４
で取得された画像データを符号化部５で圧縮符号データ
に変換し、符号蓄積部６を介して符号入出力装置７から
外部へ出力し、当該装置７により外部から入力される圧
縮符号データを復号蓄積部６を介して復号部８に入力
し、前記符号化部と逆の処理を行って元の画像データに
復元し、画像出力装置９より画像再生出力する。符号化
部５では、入力画像データをブロック（ライン）毎に区
切って１バイト単位で圧縮符号化処理を行い、１バイト
の符号化処理毎に入力画像バイト数と出力符号バイト数
を比較して、出力符号バイト数が入力画像バイト数を越
える場合に、それ以降、そのブロックのエンドまで圧縮
符号化を止めるようにしたことを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えばファクシミ
リ装置等に用いられ、白黒の２値のイメージデータを符
号化、復号化してデータ圧縮・伸張処理を行う画像デー
タ処理装置に係り、特に画像データの編集や表示等、そ
の装置内でローカルにデータ転送やデータ加工が必要と
なる部位における符号化・復号化処理技術に関する。

【０００２】

【従来の技術】周知のように、ファクシミリ装置では、
原稿を白と黒の２値データに変換して読み取り、そのイ
メージデータをさまざまなデータ圧縮技術を使って符号
化して、その圧縮符号データを記憶装置に蓄積する。そ
して、モデム等の通信機能を使い、電話回線を通して遠
隔地の装置へ送信する。また逆に、電話回線を通して遠
隔地の装置から受信し、受信した圧縮符号データを記憶
装置に蓄積する。そして、同種のデータ圧縮技術を使っ
て、蓄積した圧縮符号データを復号化し、白・黒のイメ
ージデータに復元してプリンタに印字する、あるいは表
示装置に出力する。

【０００３】この種のファクシミリ装置では、ＩＴＵ−
Ｔ国際勧告にあるＭＨ／ＭＲ／ＭＭＲ符号化方式を使用
するのが一般的である。

【０００４】しかしながら、これらの符号化方式を高速
に実現しようとした場合、その複雑なアルゴリズムゆえ
に特別なハードウェアを組み込む必要があり、装置コス
トが高価になる問題があった。仮に、ソフトウェアでＭ
Ｈ／ＭＲ／ＭＭＲ符号化を実現した場合、ビット単位の
複雑な処理が必要であるため、高速化できないという問
題があった。その上、画像パターンによっては元画像デ
ータ量に対して符号量が最悪４．５倍以上に伸長してし
まい、データ転送や蓄積メモリ量を悪化させるという問
題もあった。

【０００５】これらの問題を改善する有力な方法とし
て、従来、この種のファクシミリ装置に用いられる画像
データ処理装置が特開平１−１８３２７５号公報に開示
されている。

【０００６】ここに示される画像データ処理装置は、入
力画像をブロックに分割して、白画素のみからなるブロ
ックが連続する白モードデータ群と、黒画素のみからな
るブロックが連続する黒モードデータ群と、白画素と黒
画素が混在するブロックが連続する混在モードデータ群
に分類する手段を持つ。また、各モードを区別するモー
ドフィールドと、連続するブロック数を示すカウンタフ
ィールドと、圧縮しないデータを付加するローデータフ
ィールドで構成される符号データに変換する手段を持
つ。

【０００７】すなわち、上記構成による画像データ処理
装置では、入力画像ブロックを８ｂｉｔとし、白画素を
２進数の“０”、黒画素を２進数“１”で表現する場
合、白モードデータ群とは“００００００００”＝００
Ｈ（末尾Ｈは１６進数を示す。）、黒モードデータ群と
は“１１１１１１１１”＝ＦＦＨ、それ以外を混在モー
ドとする。

【０００８】モードフィールドは２ｂｉｔで表現され、
“００”は白モード、“０１”は黒モード、“１０”は
混在モード、“１１”はエンドモードを示す。カウンタ
フィールドは、６ｂｉｔで表現され、１〜６４の値をと
り、同一モードのブロックが何個連続しているかを示
す。ローデータフィールドは前記モードフィールドとカ
ウンタフィールドの後に続き、混在するモードブロック
の圧縮されないデータ列を示す。

【０００９】したがって、連続する白モードブロックは
モードフィールド（２ｂｉｔ）とカウンタフィールド
（６ｂｉｔ）の８ｂｉｔ（１バイト）に圧縮される。同
様に、連続する黒モードブロックも８ｂｉｔ（１バイ
ト）に圧縮される。また、連続する混在モードブロック
は、モードフィールド（２ｂｉｔ）とカウンタフィール
ド（６ｂｉｔ）の８ｂｉｔ（１バイト）＋ローデータフ
ィールド（混在モードブロックデータ量）になり、元の
データに対して、１バイトデータ量が増える。

【００１０】本装置のデータフォーマットを図６に、デ
ータ処理例を図７に示す。図６において、（ａ）は白モ
ード、（ｂ）は混在モード、（ｃ）は黒モード、（ｄ）
はエンドモードを示している。また、図７において、
（ａ）は入力画像に対してデータ符号化処理後の出力符
号が短くなる場合、（ｂ）は入力画像に対してデータ符
号化処理後の出力符号が長くなる場合の様子を示してい
る。

【００１１】引用した公報の従来技術の処理はソフトウ
ェアでも高速に処理できるアルゴリズムになっている。
しかしながら、本方式でも、白モードブロックまたは黒
モードブロックと混在モードブロックが交互に発生する
ような画像データに対しては、混在モードのモードフィ
ールド及びカウンタフィールドの８ｂｉｔが混在モード
ブロック毎に付加されるため、元画像データ量に対し
て、最悪、１．５倍の符号データを生成してしまうとい
う問題が残る。これは、符号圧縮処理をしない場合に対
して、データ転送時間や蓄積メモリ量を１．５倍必要な
ことを意味し、高速化及び装置コストを圧迫することに
なる。

【００１２】尚、先行技術として、特開平１−１３６４
６９号公報に、白画素と黒画素とからなる画素データを
ｍビット単位毎に分割し、この単位データの構成及び単
位データ列における同一単位データの連続性を基に圧縮
符号を作成することで、安定した圧縮率の画像を得る
「画像の符号化圧縮方法」が開示されている。

【００１３】また、特開昭６１−１３３７７６号公報
に、部分画像に含まれる白画素と黒画素の比率に応じて
部分画像を分類し、各分類毎に画像データ圧縮を行うこ
とで、データ圧縮率を高める「画像データ圧縮装置」が
開示されている。

【００１４】いずれの先行技術も、白画素（黒画素）の
連続性を利用し、画像データの圧縮を行っている。しか
しながら、前述の問題を解決するための有効な手段につ
いては何等開示されていない。

【００１５】

【発明が解決しようとする課題】以上述べたように従来
の画像データ処理装置では、全白または全黒と白黒混在
が交互に発生する画像パターンで、最悪、１．５倍にデ
ータ伸張してしまうケースがあった。つまり、最悪ケー
スでは、符号蓄積メモリ量が増大し、コストアップする
問題があり、またデータ量増大により、データスループ
ットも低下するという問題があった。

【００１６】本発明の課題は、上記の問題を解決し、特
別なハードウェアや非常に高速な処理能力を持つＣＰＵ
を使用することなく、簡単なソフトウェアで高速な画像
データ圧縮伸張処理を実現する画像データ処理装置を提
供することにある。

【００１７】

【課題を解決するための手段】上記の課題を解決する本
発明の画像データ処理装置は、画像データを取得する画
像入力装置と、この前記画像入力装置で取得された画像
データを圧縮符号データに変換する符号化部と、外部へ
前記符号化部で処理された圧縮符号データを出力し、外
部から前記符号化部と同一形式で処理された圧縮符号デ
ータを入力する符号入出力装置と、この符号入出力装置
で入出力される圧縮符号データを蓄積する符号蓄積部
と、この符号蓄積部に蓄積された外部からの圧縮符号デ
ータを入力し、前記符号化部と逆の処理を行って元の画
像データに復元する復号化部と、この復号化部で得られ
た画像データを出力処理する画像出力装置とを具備し、
前記符号化部は、入力画像データを複数バイトからなる
ブロック毎に区切って１バイト単位で圧縮符号化処理を
行い、１バイトの符号化処理毎に入力画像バイト数と出
力符号バイト数を比較して、出力符号バイト数が入力画
像バイト数を越える場合に、それ以降、そのブロックの
エンドまで圧縮符号化を止めるようにしたことを特徴と
する。

【００１８】上記符号化部において、入力画像をバイト
単位（８ｂｉｔ単位）に分割して、全白（＝００Ｈ）が
何バイト連続するかを“００Ｈ”＋“ＸＸＨ”（ＸＸは
連続カウンタ数）の２バイトで表わし、同様に全黒（＝
ＦＦＨ）を“ＦＦＨ”＋“ＸＸＨ”の２バイトで表わ
す。それ以外の白画素と黒画素が混在するデータは、そ
のまま１バイトのデータで表わす。

【００１９】また、処理する単位をあるブロック（通常
は１走査ライン分）で区切り、入力画像バイト数と出力
符号バイト数を比較して、出力符号バイト数が入力画像
バイト数を越える場合は、“００Ｈ”または“ＦＦＨ”
の後の連続カウンタ数の“０１Ｈ”を“００Ｈ”に置き
換えて、以後ブロックエンドまで全て圧縮しないで、そ
のままのデータ列を出力する。

【００２０】尚、本方式では、連続しない全白及び全黒
の場合のみ入力１バイトが出力２バイトに伸長するた
め、出力符号バイト数が入力画像バイト数を越えるのは
これらの伸長するパターンの連続カウント数“０１Ｈ”
の時に限定される。

【００２１】したがって、本方式では、圧縮符号化処理
中、常に伸長しないかどうかをチェックして、画像パタ
ーンによって伸長する可能性が高くなると、それ以降そ
のブロックは圧縮符号化することを止めて、そのまま元
画像データを出力する。

【００２２】この場合、復号化部は、連続カウント数０
０Ｈの圧縮符号（００Ｈ＋００ＨまたはＦＦＨ＋００
Ｈ）を検出し、その検出時点から、１バイトの００Ｈ
（全白）またはＦＦＨ（全黒）を復元した後、ブロック
エンドまで非圧縮画像として再現する。

【００２３】つまり、“００Ｈ”＋“００Ｈ”及び“Ｆ
ＦＨ”＋“００Ｈ”が符号化中止コマンドになり、元画
像データ量に対して、最悪でも、１バイトしか増加する
ことはない。例えば、Ａ４サイズ８本／ｍｍの１ライン
は２１６バイトのデータ量があるが、最悪伸長時でも、
２１７バイトで０．５％以下の伸長率となる。

【００２４】

【発明の実施の形態】以下、図１乃至図５を参照して本
発明の一実施形態を詳細に説明する。

【００２５】図１は本実施形態の画像データ処理装置の
概略構成図である。図１において、１は本装置全体を制
御するＣＰＵで、このＣＰＵ１は制御プログラムを格納
したＲＯＭ２と、各種プログラムを実行するためのワー
ク用メモリのＲＡＭ３を備えている。

【００２６】上記ＣＰＵ１はシステムバスを通じて画像
入力装置４、符号化部５、符号蓄積部６、符号入出力装
置７、復号化部８、画像出力装置９と接続され、所定の
プログラムに基づいて各装置を順次アクセス制御する。

【００２７】画像入力装置４は、原稿イメージをラスタ
ースキャンして白画素／黒画素を電気信号“０”、
“１”に変換するもので、入力された画像データは破線
矢印に示すように符号化部５に入力される。

【００２８】この符号化部５は、後述する図４の符号化
処理フローチャートに従って、画像データを圧縮符号デ
ータに変換し、符号蓄積部６にストアさせる。この符号
蓄積部６に蓄積された圧縮符号データは、符号入出力装
置７から他のシステムまたは通信回路へ送出される。逆
に符号入出力装置７から受信した圧縮符号データは符号
蓄積部６にストアされる。

【００２９】また、符号蓄積部６に蓄積された圧縮符号
データは復号化部８へ渡され、後述する図５の復号化処
理フローチャートに従って画像データに復元され、プリ
ンタ装置やディスプレイ表示装置等の画像出力装置９へ
出力される。

【００３０】ところで、上述の構成では、符号化部５と
復号化部８を物理的なブロックの如く説明しているが、
後述する図４、図５の処理フローチャートに従って、Ｃ
ＰＵ１及びＲＯＭ２、ＲＡＭ３にて、ソフトウェアで実
現してもよい。

【００３１】次に、図２は本発明の圧縮符号データのフ
ォーマットを示すものである。データ圧縮処理はソフト
ウェアで容易に処理できるように１バイト、即ち８ビッ
ト単位で１つの画素データ群として扱い、圧縮符号デー
タもバイト単位に区切られる構造となっている。

【００３２】本例では、白画素を“０”で、黒画素を
“１”で表現し、８ビットの画素データ群が全て白画素
は００Ｈ（Ｈは１６進数を示す。）、全て黒はＦＦＨと
なる。

【００３３】図２に示すように、００Ｈの画素データ群
が連続する場合は、００Ｈ＋ＸＸＨの２バイトで表現す
る。ＸＸＨは００Ｈの画素データ群が連続する個数を１
６進数で表現したものである。例えば００Ｈが４個連続
すれば“００Ｈ＋０４Ｈ”で表現される。同様にＦＦＨ
の画素データ群が連続する場合はＦＦＨ＋ＸＸＨの２バ
イトで表現される。

【００３４】画素データ群に白画素と黒画素が混在して
いるデータ０１Ｈ〜ＦＥＨは圧縮しないでそのまま出力
する。

【００３５】ここで、以上の条件だけで符号化すると、
００ＨまたはＦＦＨが連続しないで１個のみ存在した場
合、例えば００Ｈ１バイトは００Ｈ＋０１Ｈの２バイト
の符号で表現されるため、最悪２倍にデータ量が増える
可能性がある。これは符号蓄積部６のメモリ容量を増大
させ、コストアップの原因となる上、符号入出力装置７
とのデータ転送においても、データバスのスループット
を悪化させる要因となる。

【００３６】そこで、本発明では、処理する大きな単位
として、ブロック（本実施形態では１ラインを１ブロッ
クとしている。）毎に区切り、１バイトの符号化処理毎
に入力画像バイト数と出力符号バイト数を比較して、出
力符号バイト数が入力画像バイト数を越える場合は、そ
れ以降、そのブロックのエンドまで圧縮符号化を止める
処理を追加する。

【００３７】ここで、符号化でデータが増加するのは前
述の通り、００ＨまたはＦＦＨが連続しないで１個のみ
存在する場合だけである。非圧縮符号として、出力符号
バイト数が入力画像バイト数を越えた時の００Ｈまたは
ＦＦＨの連続カウント数０１Ｈを００Ｈに置き替えたも
のを定義する。

【００３８】つまり、復号化する時、連続カウント数０
０Ｈの圧縮符号（００Ｈ＋００Ｈ、またはＦＦＨ＋００
Ｈ）を検出したら、１バイトの００Ｈ（全白）またはＦ
ＦＨ（全黒）を復元した後、ブロックエンドまで非圧縮
画像として再現する。

【００３９】図３は、以上説明した本発明のデータ圧縮
処理の例である。図３において、（ａ）では入力画像デ
ータ量を出力符号データ量が越えることはなく、ブロッ
ク内全てが圧縮符号の対象となっている。（ｂ）では、
１１バイト目の００Ｈを符号化する時に出力符号データ
量が入力画像データ量を越す（破線部）。

【００４０】したがって、本来１１バイト目の００Ｈは
００Ｈ＋０１Ｈに符号化されるべきであるが、本ブロッ
クは符号化することによってデータ量が増大する可能性
が高いので、００Ｈ＋００Ｈの非圧縮符号に置き換え
て、１２バイト目以降はブロックエンドまで圧縮せずに
元画像データのままとする。

【００４１】このように、入力画像データ量と出力符号
データ量を随時比較してダイナミックに圧縮符号化処理
を停止させることによって、最悪の場合でも、ブロック
当たり１バイトのデータ伸長に抑えることができる。

【００４２】ファクシミリ装置で一般によく使われるＡ
４サイズ８本／ｍｍの線密度では、１ライン（ブロッ
ク）＝２１６バイトであるが、本発明の符号化最悪伸長
時でも２１７バイト／２１６バイト≠１．００４６であ
り、０．５％以下の伸長率となる。

【００４３】次に具体的な符号化、復号化の実現方法と
して、図４に符号化処理のフローチャートを示し、図５
に復号化処理のフローチャートを示して、それぞれの処
理手順について説明する。

【００４４】図４の符号化処理において、ステップＳ１
ではライン（ブロック）毎に必要な入力画像データカウ
ンタや出力符号データカウンタ等の初期化を全て行な
う。次に、ステップＳ２で画像データ１バイトを入力
し、ステップＳ３で００Ｈ（全白）またはＦＦＨ（全
黒）かそれ以外（白黒混在）かを判定する。ここで、白
黒混在の場合は（Ｎｏ）、ステップＳ４で入力した画像
データをそのまま符号として出力する。

【００４５】続いて、ステップＳ５でライン（ブロッ
ク）エンドか判定し、ＮｏならばステップＳ２に戻る。
また、ＹｅｓならばステップＳ６でページエンドか判定
し、ＮｏならばステップＳ１に戻り、Ｙｅｓならば処理
を終了する。

【００４６】ステップＳ３で００Ｈ（全白）またはＦＦ
Ｈ（全黒）であれば（Ｙｅｓ）、ステップＳ７でさらに
００Ｈ（全白）かＦＦＨ（全黒）に分岐する。００Ｈ
（全白）ならば（Ｙｅｓ）、ステップＳ８で全白符号０
０Ｈを出力して、ステップＳ９で連続カウンタを０１Ｈ
（１個）に初期化する。

【００４７】続いて、ステップＳ１０でライン（ブロッ
ク）エンドかチェックする。Ｙｅｓの場合はカウント値
を出力して、ステップＳ１６で次ライン（ブロック）を
継続するかを判定する。ステップＳ１０でラインエンド
でなければ（Ｎｏ）、ステップＳ１１で次の画像データ
１バイトを入力して、ステップＳ１２で００Ｈが連続し
ているかを判定する。連続している場合は（Ｙｅｓ）、
ステップＳ１３で連続カウンタをインクリメント（＋
１）する。

【００４８】さらに、ステップＳ１４でカウンタの最大
値（＝ＦＦＨ）を越えたか判定し、Ｎｏならばステップ
Ｓ１０に戻って次の画像データ入力を続けるかを判定す
る。もし、カウンタの最大値を越えたら、ステップＳ１
５で連続カウント値としてＦＦＨを出力し、ステップＳ
８に戻って再び全白連続信号として００Ｈを出力し、ス
テップＳ９でカウンタを初期化し、前述と同様の連続数
をチェックする。

【００４９】ステップＳ１２で００Ｈ（全白）以外が発
生したら（Ｎｏ）、ステップＳ１７で入力画像データの
カウント値と出力符号データのカウント値＋１を比較す
る。ここで、入力画像データの方が大きければ（Ｎ
ｏ）、圧縮符号化を継続できると判断して、ステップＳ
１８で全白符号のカウンタの値を出力してステップＳ３
に戻り、ステップＳ１１で入力された画像データの属性
を判定して同様の処理を続ける。

【００５０】もし、ステップＳ１７で入力画像データの
カウント値が出力符号データのカウント値＋１以上にな
ったら（Ｙｅｓ）、符号化による伸張が発生したと判断
して、ステップＳ１９で全白符号の連続カウント値の代
わりに非圧縮符号として００Ｈを出力する。以後、ライ
ン（ブロック）エンドまでステップＳ２０〜Ｓ２２で画
像データをそのまま出力する。ライン（ブロック）エン
ドになったら（Ｙｅｓ）ステップＳ６に戻り、ページエ
ンドでなかったら（Ｎｏ）、ステップＳ１に戻って処理
を続ける。

【００５１】ステップＳ７で００Ｈ（全白）でない場合
（Ｎｏ）、つまりＦＦＨ（全黒）の場合はステップＳ２
３に進み、ステップＳ８〜Ｓ２２の全白処理と同様に、
ステップＳ２３〜Ｓ３０及びステップＳ１６〜Ｓ２２で
全黒処理を実行する。

【００５２】次に、図５の復号化処理において、ステッ
プＰ１ではライン（ブロック）毎に必要な出力画像デー
タカウンタ等を初期化する。ステップＰ２で符号データ
１バイトを入力し、ステップＰ３で００ＨまたはＦＦＨ
かそれ以外かを判定する。００ＨでもＦＦＨでもなけれ
ば（Ｎｏ）、白黒混在符号として入力されたデータをス
テップＰ４でそのまま出力画像データとして出力する。

【００５３】続いて、ステップＰ５でライン（ブロッ
ク）エンドか見て、ＮｏならばステップＰ２へ戻り、次
の符号データ入力を続ける。ラインエンドなら（Ｙｅ
ｓ）、ステップＰ６でページエンドか判定し、Ｎｏなら
ばステップＰ１へ戻り、次のライン処理を続け、ページ
エンドならば（Ｙｅｓ）復号化を終了する。

【００５４】ステップＰ３で００ＨまたはＦＦＨの場合
は（Ｙｅｓ）、ステップＰ７で００ＨかＦＦＨかを判定
して、００Ｈの場合は（Ｙｅｓ）ステップＰ８で次の符
号データを１バイト入力する。

【００５５】ステップＰ８で入力されたデータは連続カ
ウント値（０１Ｈ〜ＦＦＨ）または非圧縮符号（００
Ｈ）であるから、ステップＰ９で００Ｈかどうかをチェ
ックする。００Ｈでなければ（Ｎｏ）、連続カウント値
であるから、ステップＰ１０で００Ｈ（全白）を出力し
て、ステップＰ８で入力したデータ（つまり連続カウン
ト値）をステップＰ１１でデクリメント（−１）して、
ステップＰ１２で連続カウント値が００Ｈになるまでス
テップＰ１０〜Ｐ１２を繰り返し、これによって００Ｈ
（全白）を必要数出力する。

【００５６】もし、ステップＰ９で、ステップＰ８で入
力したデータが００Ｈならば（Ｙｅｓ）、非圧縮符号で
あるから、ステップＰ１３で直前の画像データ００Ｈ
（全白）を出力して、ステップＰ１４〜Ｐ１６でライン
（ブロック）エンドまで符号データを入力して、そのま
ま画像データとして出力する。

【００５７】ステップＰ７で、ステップＰ２で入力され
たデータがＦＦＨの場合は（Ｎｏ）、黒画素符号と判断
してステップＰ１７へ進む。ステップＰ１７〜Ｐ２５で
は、ステップＰ８〜Ｐ１６の全白処理と同様に全黒処理
が実行される。

【００５８】以上説明したように、図４及び図５のフロ
ーチャートに従って符号化、復号化処理を実現すれば、
非常に高速でかつほとんど伸張しない圧縮符号化がで
き、特別なハードウェアや不要な符号蓄積メモリを持た
ずに安価な画像データ処理装置を構成できる。

【００５９】

【発明の効果】以上のように本発明によれば、特別なハ
ードウェアや非常に高速な処理能力を持つＣＰＵを使用
することなく、簡単なソフトウェアで高速な画像データ
圧縮伸張処理を実現する画像データ処理装置を提供する
ことができる。

【図面の簡単な説明】

【図１】本発明に係る一実施形態による画像データ処理
装置の構成を示すブロック図である。

【図２】同実施形態の圧縮符号フォーマットを示す図で
ある。

【図３】同実施形態におけるデータ処理例を示す図であ
る。

【図４】同実施形態の符号化処理手順を示すフローチャ
ートである。

【図５】同実施形態の復号化処理手順を示すフローチャ
ートである。

【図６】従来の画像データ処理装置における圧縮符号フ
ォーマットを示す図である。

【図７】従来装置のデータ処理例を示す図である。

【符号の説明】

１ＣＰＵ２ＲＯＭ３ＲＡＭ４画像入力装置５符号化部６符号蓄積部７符号入出力装置８復号化部９画像出力装置

Claims

【特許請求の範囲】

【請求項１】画像データを取得する画像入力装置と、この前記画像入力装置で取得された画像データを圧縮符
号データに変換する符号化部と、外部へ前記符号化部で処理された圧縮符号データを出力
し、外部から前記符号化部と同一形式で処理された圧縮
符号データを入力する符号入出力装置と、この符号入出力装置で入出力される圧縮符号データを蓄
積する符号蓄積部と、この符号蓄積部に蓄積された外部からの圧縮符号データ
を入力し、前記符号化ｃ５部と逆の処理を行って元の画
像データに復元する復号化部と、この復号化部で復元された画像データを出力処理する画
像出力装置とを具備し、前記符号化部は、入力画像データを複数バイトからなる
ブロック毎に区切って１バイト単位で圧縮符号化処理を
行い、１バイトの符号化処理毎に入力画像バイト数と出
力符号バイト数を比較して、出力符号バイト数が入力画
像バイト数を越える場合に、それ以降、そのブロックの
エンドまで圧縮符号化を止めるようにしたことを特徴と
する画像データ処理装置。
【請求項２】前記符号化部は、入力画像データをバイ
ト単位に分割して、全白（＝００Ｈ）が何バイト連続す
るかを“００Ｈ”＋“ＸＸＨ”（ＸＸは連続カウント
数）の２バイトで表わし、同様に全黒（＝ＦＦＨ）を
“ＦＦＨ”＋“ＸＸＨ”の２バイトで表わし、それ以外
の白画素と黒画素が混在するデータはそのまま１バイト
のデータで表わすものとし、処理する単位をあるブロックで区切り、入力画像バイト
数と出力符号バイト数を比較して、出力符号バイト数が
入力画像バイト数を越える場合は、“００Ｈ”または
“ＦＦＨ”の後の連続カウンタ数の“０１Ｈ”を“００
Ｈ”に置き換えて、以後ブロックエンドまで全て圧縮し
ないで、そのままのデータ列を出力するようにしたこと
を特徴とする請求項１記載の画像データ処理装置。
【請求項３】前記復号化部は、連続カウント数００Ｈ
の圧縮符号（００Ｈ＋００ＨまたはＦＦＨ＋００Ｈ）を
検出し、その検出時点から、１バイトの００Ｈ（全白）
またはＦＦＨ（全黒）を復元した後、ブロックエンドま
で非圧縮画像として再現するようにしたことを特徴とす
る請求項２記載の画像データ処理装置。
【請求項４】前記ブロックは、前記画像入力装置の１
走査ライン分であることを特徴とする請求項１記載の画
像データ処理装置。