(57)【特許請求の範囲】
【請求項１】
少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮されて生成された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信する受信部と、
前記受信部により受信された前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号する復号化部と、
前記復号化部により復号された前記ユニットを蓄積する蓄積部と、
前記復号化部により復号化済みのライン数をカウントするカウント部と、
前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定する判定部と、
前記判定部により有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成する情報再圧縮部と、
前記第２の圧縮データを外部に出力する出力部と
を有することを特徴とする情報処理装置。
【請求項２】
少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮されて生成された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信するステップと、
前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号するステップと、
前記復号された前記ユニットを蓄積するステップと、
前記復号化部により復号化済みのライン数をカウントするステップと、
前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定するステップと、
有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに、前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成するステップと
を有することを特徴とする情報の再圧縮方法。
【請求項３】
第１の情報処理装置と、前記第１の情報処理装置に通信回線を介して接続された第２の情報処理装置とを備える情報処理システムであって、
前記第１の処理装置は、
少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮を圧縮して第１の圧縮データを生成する情報圧縮部と、
前記通信回線を介して前記第２の情報処理装置に前記第１の圧縮データを送信する送信部と、を備え、
前記第２の処理装置は、
前記通信回線を介して前記第１の情報処理装置により送信された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信する受信部と、
前記受信部により受信された前記第１の圧縮データから圧縮前のユニットを復号する復号化部と、
前記受信部により受信された前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号する復号化部と、
前記復号化部により復号された前記ユニットを蓄積する蓄積部と、
前記復号化部により復号化済みのライン数をカウントするカウント部と、
前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定する判定部と、
前記判定部により有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成する情報再圧縮部と
を備えたことを特徴とする情報処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は情報の再圧縮方法、情報処理装置及び情報処理システムに係り、とりわけＪＢＩＧ符号を採用するファクシミリ装置に関するものである。
【０００２】
【従来の技術】
近年、符号化方式としてＪＢＩＧ(Joint Bilevel Image coding experts Group)モードを有するファクシミリ装置が実用化されている。このＪＢＩＧ符号は国際電気通信連合（International Telecommunications Union : ＩＴＵ−Ｔ）がＴ．８２として勧告化したものであるがファクシミリ装置に使用する場合はＴ．８５勧告が適用される。
【０００３】
ＭＭＲ(Modified Modified Read)符号化等の従来の圧縮符号と比較し、ＪＢＩＧは圧縮率の高さに特徴がある。これは予測符号化による恩恵が大きい。ＪＢＩＧの予測符号化では、周辺画素から注目画素の状態を予測し、予測と異なる状態の場合にのみ符号データを生成する。よって予測が的中している間は全くデータが生成されないので高い圧縮率を得ることができる。
【０００４】
一方で、ＪＢＩＧ符号は、予測が一致している範囲では符号化側で全くデータが生成されないにもかかわらず、復号化側では全くデータの無い状態から復号データを生成するという特徴ももっている。これは、画像の後端ではそれ以上データが無いにも関わらず、余分なゴミデータを生成してしまう危険性を併せ持つことを意味する。
【０００５】
この様子を図８に示す。図８では、目的とする画像のサイズを超えてＪＢＩＧで符号化してしまった結果、復号時にゴミが生じたケースである。
【０００６】
その対策として、Ｔ．８２で勧告化された本来のＪＢＩＧ符号では画像の先頭でＹDというパラメータで画像のライン数を宣言し、復号時にはＹDの値を超えないに復号することにより、符号化側で作成した以上のデータが復号化側では表れないようにしている。
【０００７】
さらに、符号化開始時点では総ライン数が分からないアプリケーションのためには、開始時点ではＹDに十分に大きい値を設定した上で、画像を複数のストライプに分割して符号化を行い、最後のストライプの符号化以前にＮＥＷＬＥＮというパラメータで、正しいライン数を宣言するという方式が許容されている。なお、ＮＥＷＬＥＮは、画像の総ライン数を表すパラメータである。
【０００８】
このストライプというのは、一つの画像を複数の水平バンドに分割したもので、１ストライプを構成するライン数は予めＬ0として画像の先頭で宣言される。
【０００９】
このＬ0の値は可変なので、スキャナから読み取った画像をリアルタイムで符号化する様なアプリケーションでは、Ｌ0の値を十分に小さくすることにより最小限のバッファのみでＪＢＩＧ符号化を行うことが可能となる。
【００１０】
極端な例ではＬ0を１とすれば１ラインのバッファのみでスキャナから読み取った画像をリアルタイムでＪＢＩＧ符号化することが可能である。この場合は最後のラインを符号化する直前にＮＥＷＬＥＮでライン数を宣言すればよい。
【００１１】
もちろん、十分なメモリを有して画像を全て読み込んでしまってから符号化するアプリケーションでは、最初にＹDに総ライン数を設定すればよく、その場合はストライプに分割する必要は無いのでＬ0をＹDと同じ値にして、画像全体を一つのストライプとして扱うことも可能である。
【００１２】
前記の様にＴ．８２では可変ストライプと、最終ストライプ前のＮＥＷＬＥＮによりスキャナから読み取った画像のリアルタイムの符号化を可能としていたが、ＪＢＩＧ符号がファクシミリ装置に適用されるにあたり、Ｔ．８５では２つの重大な変更がなされた。
【００１３】
第一はストライプ長として１２８ラインが必須とされ、それ以外の値はオプションとされた点である。
【００１４】
これにより復号側では極端に大きなストライプに対応することが不要となったため、ハードウェア／ソフトウェアの設計が容易になり、また相互交信性の面でも有利となった。
【００１５】
しかし、一方ではＪＢＩＧ符号をサポートするファクシミリ装置は少なくとも１２８ラインのラインバッファを持つことが要求されることになった。
【００１６】
リアルタイムでの符号化時は、スキャナから読み取ったデータで１２８ラインのバッファがフルになるたびに１ストライプの符号化を行い、バッファがフルになる前に画像の後端を検出した場合には、その時点で総ライン数をＮＥＷＬＥＮで宣言してから最後のストライプを符号化することになる。
【００１７】
図３に例を示す。ここでＢＩＨはＪＢＩＧのヘッダーで各種のパラメータが宣言されるが、ここでは本発明に関係する３つのパラメータのみ示すが、他のパラメータは適切に設定されているものとする。ＹDは画像のライン数で、ここでは最大の０ｘffffffff（＝約４０億）が設定されている。Ｌ0はストライプ長で、ここでは標準の１２８が設定される。ＶＬＥＮＧＴＨ＝１は、この後にＮＥＷＬＥＮで総ライン数が訂正されることを示す。以下１２８ライン単位でストライプデータが作成され、この例では実際に送信されるライン数は５００ラインなので、最終の４番ストライプの前にＮＥＷＬＥＮが使われて、正しい総ライン数が宣言される。
【００１８】
第二は第一の変更によりラインバッファが最低でも１２８ライン必要になったことに対する代償として発案されたもので、ＮＵＬＬストライプという概念を導入することにより全ての画像を符号化した後にＮＥＷＬＥＮで総ライン数を宣言する方法が認められたことである。
【００１９】
この場合には全てのストライプが送られた後で、ＮＥＷＬＥＮが送られて総ライン数が示され、その後ろに全くデータを持たないＮＵＬＬストライプが送られて画像が閉じられる。
【００２０】
図７に例を示す。ここではＢＩＨは図６と同様で、以下ストライプデータが続くが、この例では最終の４番ストライプの後にＮＥＷＬＥＮが使われて総ライン数が宣言され、その後にＥＳＣ，ＳＤＮＯＲＭが続いてデータを伴わないストライプが存在することになっている。
【００２１】
【発明が解決しようとする課題】
この方法によりファクシミリ装置は１２８本のラインバッファを保有する必要がなくなり、いくばくかのコストダウンが可能となったが、新たに別の問題が発生した。
【００２２】
それは、画像のライン数は１２８の整数倍とは限らないので最終ストライプは殆どの場合に１２８ラインに満たないにも関わらず、最終ストライプの復号開始時点では総ライン数が不明のため、復号時に余分なゴミラインを生成してしまう危険性が発生したということことである。図８にゴミの発生の様子を示す。
【００２３】
図６に示す従来例では１ストライプ＝１２８ラインが宣言されていても、４番目のストライプの復号を開始する以前にＮＥＷＬＥＮで総ライン数＝５００ラインが宣言されているので、復号処理では５００ラインを超えるデータが出力されることはない。
【００２４】
しかし、図７に示すＴ．８５で新たに認められたＮＥＷＬＥＮの使用法の例では４番目のストライプの復号を開始する以前には総ライン数としては最初にＹDで与えられた０ｘfffffffが有効なままになっているので、復号処理では１ストライプ分の１２８ラインを復号してしまいトータルで５１２ラインまで復号してしまう危険性がある。このように過剰なストライプを復号すれば、図８に示すように情報として意味のないゴミが生じてしまう。
【００２５】
このゴミは、とりわけ、現行のファクシミリでは大きな問題となる。現行のファクシミリでは、ＪＢＩＧ符号の復号には時間がかかるという欠点を解決すべく、ＪＢＩＧの受信データを受信中にリアルタイムで復号し、別のより扱いやすい符号化方式、例えばＭＭＲ等で再度圧縮して装置内のメモリに蓄積して、そこから印字あるいは転送するといった処理が一般に行われている。このような場合に、後でＮＥＷＬＥＮにより総ライン数が５００であることが示されても、一般的なファクシミリ装置では既に別の符号化方式での再符号化が終了しており、発生してしまったゴミラインは消すことができない。
【００２６】
従って、上述の再符号化されたデータの後端に余分なゴミラインが付加されてしまうことが避けがたかった。
【００２７】
そこで、上記の問題を解決し、画像の後端にＮＥＷＬＥＮを付加してくる送信機から受信しても、再符号化後のデータにゴミラインが表れず、そのままＰＣ等にアップロード可能な情報処理装置を比較的安価に実現することが本発明の目的である。
【００２８】
【課題を解決するための手段】
上記目的を達成するため、本発明は、少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮されて生成された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信する受信部と、前記受信部により受信された前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号する復号化部と、前記復号化部により復号された前記ユニットを蓄積する蓄積部と、前記復号化部により復号化済みのライン数をカウントするカウント部と、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定する判定部と、前記判定部により有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成する情報再圧縮部と、前記第２の圧縮データを外部に出力する出力部とを有することを特徴とする。
【００３５】
さらに、上記目的を達成するため、本発明は、少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮されて生成された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信するステップと、前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号するステップと、前記復号された前記ユニットを蓄積するステップと、前記復号化部により復号化済みのライン数をカウントするステップと、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定するステップと、有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに、前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成するステップとを有することを特徴とする。
【００４３】
さらに、上記目的を達成するため、本発明の情報処理システムは、第１の情報処理装置と、前記第１の情報処理装置に通信回線を介して接続された第２の情報処理装置とを備える情報処理システムであって、前記第１の処理装置は、少なくとも一つのユニットからなる元データをＪＢＩＧ符号を用いて該ユニットごとに情報圧縮を圧縮して第１の圧縮データを生成する情報圧縮部と、前記通信回線を介して前記第２の情報処理装置に前記第１の圧縮データを送信する送信部と、を備え、前記第２の処理装置は、前記通信回線を介して前記第１の情報処理装置により送信された第１の圧縮データと前記元データの総ライン数を表したパラメータを受信する受信部と、前記受信部により受信された前記第１の圧縮データから圧縮前のユニットを復号する復号化部と、前記受信部により受信された前記第１の圧縮データから複数のラインで構成された圧縮前のユニットを復号する復号化部と、前記復号化部により復号された前記ユニットを蓄積する蓄積部と、前記復号化部により復号化済みのライン数をカウントするカウント部と、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数より大きければ、前記総ライン数までのラインを前記ユニット中の元データとして有効な部分と判定し、一方、前記パラメータによる前記総ライン数が、前記カウントされた復号化済みのライン数以下であれば、前記復号化済みのライン数を超える余剰ラインを除いた残りのラインを前記ユニット中の元データとして有効な部分と判定する判定部と、前記判定部により有効と判定された前記部分までを前記蓄積部から順次読み出し、読み出されたユニットごとに前記ＪＢＩＧ符号と異なる符号にて再度情報圧縮し第２の圧縮データを生成する情報再圧縮部とを備える。
【００４５】
【発明の実施の形態】
以下に本願発明の一実施形態を示す。もちろん以下の実施形態は、本願発明の当業者による実施を容易にするための開示を提供するものであり、特許請求の範囲によって確定される本願発明の技術的範囲のほんの一部の実施形態にすぎない。従って、本願明細書によって記載されていない実施形態であるからといって、直ちに本願発明の技術的範囲から外れるわけではない。
【００４６】
本実施形態では、画像圧縮を例に取り説明するが、本発明の技術思想はこれに限られるものではなく、音声、データファイル及び動画等の他の形式の情報圧縮にも適用可能である。
【００４７】
本実施形態ではＴ．８５で標準とされる１ストライプのライン数である１２８ライン以上のラインバッファを有し、１ストライプの復号終了時点で次のデータを調査し、そこに次のストライプデータが存在すればバッファリングされた１２８ラインのデータの再符号化を行い、そこにＮＥＷＬＥＮが存在すればＮＥＷＬＥＮで指定された総ライン数とそれまでに復号をしたライン数を比較して、ＮＥＷＬＥＮで指定されたライン数の方が復号済みライン数よりも大きい場合はまだ次のストライプが続くのでＹDで指定されたライン数をＮＥＷＬＥＮで指定されたライン数に変更した上でラインバッファ内のデータを再符号化して復号処理を続行し、ＮＥＷＬＥＮで指定されたライン数がそれまでに復号したライン数より以下の場合には、本来のデータにはない余剰な部分までも復号してしまったことになるので、余剰な部分を除いた本来有効な意味をもつ部分だけを再符号化すればよい。具体的には、ＮＥＷＬＥＮで指定されたライン数からそれまでに再符号化を終了したライン数を引いた残りのライン数の再符号化を行うことでゴミラインの発生を防ぐことが可能になる。
【００４８】
図１は本発明に係るファクシミリ装置の構成を示すブロック図である。なお、システム構成は図９に示す。同図において、中央演算処理装置(Central Processing Unit : ＣＰＵ)１０１は、システム制御部であり、装置全体を制御する。
【００４９】
リードオンリーメモリ(Read Only Memory : ＲＯＭ)１０７は、ＣＰＵ１０１の制御プログラムを格納するものである。ランダムアクセスムモリ(Random Access Memory : ＲＡＭ)１０８は、プログラム制御変数等を格納するためのもので、オペレータが登録した各種登録データや画像データもここに格納される。またＲＡＭ１０８の内部マッピングは図示しないが、請求項にいう１２８本以上のラインバッファもここに配置される。操作部１０２は、キーボード、タッチパネル等で構成され、オペレータが各種入力操作を行うためのものである。表示部１０３は、液晶表示装置(Liquid Crystal Display : ＬＣＤ)，発行ダイオード(Light Emitting Diode : ＬＥＤ)等でオペレータに表示通知するためのものである。モデム(Modulator-Demodulator : ＭＯＤＥＭ)１０４は、ファクシミリの送受信信号の変復調を行うものであり、ネットワーク接続装置(Network Control Unit : ＮＣＵ)１０５は、ＭＯＤＥＭ１０４を電話回線に接続するためのもので、他に選択信号（ダイヤルパルス）の送出や呼び出し信号を検出する機能も有する。なお、電話回線はアナログ回線、ＩＳＤＮだけでなく他の通信回線であってもよい。すなわちインターネット網などでもよい。また、有線に限らず無線により通信回線を実現してもよい。
【００５０】
記録部１０９は、プリンタのエンジン部であり、画像情報を受け取り、記録紙に印字する機能を持っている。なお、画像情報をファイルとして保存する場合は、この記録部は記憶媒体の読み書きドライブ等になろう。読取部１１０は原稿を読み取るスキャナあるいは原稿画像ファイルの記録された記憶媒体を読み取る読取装置等である。
【００５１】
ＰＣ−Ｉ／Ｆ部１０６は、ホストコンピュータ１１１に接続するためのもので、ホストコンピュータへの画像データのアップロードおよびホストコンピュータからの画像のダウンロードを行う。アップロードする画像はＭＯＤＥＭ１０４およびＮＣＵ１０５を通して受信したものでも良く、また読取部１１０で読み取ったものであっても差し支えない。またダウンロードされた画像は記録部１０９で印字しても良く、ＭＯＤＥＭ１０４およびＮＣＵ１０５を通して送信しても良い。本実施形態ではＰＣ−Ｉ／Ｆ部１０６は、ホストコンピュータ１１１とはＩＥＥＥ１２８４準拠の双方向パラレルＩ／Ｆで接続されることを想定しているが、これはＵＳＢ(Universal Serial Bus)、イーサネットまたはＩＥＥＥ１３９５等の他の通信規格で接続しても差し支えない。
【００５２】
以上の１０１〜１１０が本実施形態におけるファクシミリ装置の構成である。
【００５３】
そして、ホストコンピュータ１１１はファクシミリ装置と接続して画像のアップロード／ダウンロードを行うことで、ファクシミリ装置をスキャナ／プリンタ／ＰＣ−ＦＡＸの様に動作させるものである。
【００５４】
図９は、本実施形態のシステム概要を示すものである。第１の情報処理装置９００は、ＪＢＩＧで符号化された画像データを作成し、転送するファクシミリやパソコン等の装置である。第２の情報処理装置９００は、ＪＢＩＧデータを受信して復号し、ＭＲ等の他の符号化により再圧縮を行うファクシミリまたはＰＣ等である。第３の処理装置は、ＭＭＲ等のデータを第２の処理装置から受信し、画面に表示したりプリンタで印刷するパソコンなどである。各装置間は、無線または有線により接続されており、各装置とも通信に必要なＩＦを備えている。なお、処理の流れとしては、図示の逆の流れもあろう。すなわち、ＰＣで作成した文書や画像ファイル等を第２の情報処理装置にダウンロードし、そこでＪＢＩＧ符号化して第１の情報処理装置に転送し、第１の情報処理装置にて復元及び再圧縮してもよい。
【００５５】
図２は、図１をより機能的に記述したものである。受信部１５０は、ＮＣＵ１０５やＭＯＤＥＭ１０４に対応するものであり、通信回線と接続し、ＪＢＩＧにより圧縮されたデータ及びＮＥＷＬＥＮ等の制御データを受信する回路であり、ＮＣＵ１０５やＭＯＤＥＭ１０４が対応する。蓄積部１５２は、ＲＡＭ１０８などのデータを記憶する記憶装置であって、図３に詳細を示すように、受信部１５０で受信したＪＢＩＧデータ（第１の圧縮データ）や制御データ（付加情報）、後述する各種変数及びＭＭＲ等による再符号化後の圧縮データ（第２の圧縮データ）を蓄積する。判定部１５３では、ＮＥＷＬＥＮなどの付加情報及び蓄積部１５２に蓄積された各種変数とに基づいて、復号化された情報のうちゴミではない有効な部分を特定する。復号化部１５５は、蓄積部１５３に蓄積されたＪＢＩＧデータを復号し、復号された元データ（復号されたユニット）を再度蓄積部１５２に書き込む。再圧縮部１５４は、判定部１５３の命令に従って復号された元データのうちゴミを除いた有効な情報部分をＭＭＲ等の符号を用いた再度情報圧縮を施す。なお、判定部１５３、再圧縮部１５４及び復号化部１５５はそれぞれ専用の回路により実現してもよいが、図１、図２に示すようにＣＰＵ１０１、ＲＯＭ１０７またはＲＡＭ１０８等に記憶されたプログラムにより実現してもよい。出力部１５１は、ＰＣ等への接続インタフェースやディスプレイ等の画像表示装置または印字装置などである。
【００５６】
本実施形態では、ユニット単位で順次復号処理しながら、上記判定部１５３において意味のある情報の最終位置、すなわち元データの終端を監視し、再圧縮部１５４で不要な部分を除いた残りを再符号化する構成としたため、ゴミラインの発生を極力防止できる利点がある。
【００５７】
図３に、ＲＡＭ１０８の記憶例を示している。ラインバッファエリア１０８ａは、受信部１５０で受信した１ストライプ分のデータをバッファリングするための記憶領域である。変数格納エリア１０８ｂは、画像の総ライン数を表すｔｏｔａｌ＿ｌｉｎｅ、ＪＢＩＧ復号済みのライン数を表すｄｅｃ＿ｌｉｎｅ、ＭＭＲによる再符号化済みのライン数を示すｅｎｃ＿ｌｉｎｅ及び現在処理中のラインであるｓｔｒｉｐｅ＿ｌｉｎｅなどの各種変数を記憶する記憶領域である。
【００５８】
以上の前提を持って、本発明の具体的な実施形態を説明する。最初に図４に示したＪＢＩＧデータの構造図にしたがって、ＪＢＩＧ符号の構造を説明する。ＪＢＩＧデータは大きくはヘッダー部であるＢＩＨとデータの実体であるＢＩＤに分けられる。ＢＩＨには以後のＢＩＤの状態を示す情報が書き込まれている。例えば主走査長を示すＸD、副走査長を示すＹD、ストライプ長を示すＬ0等である。
【００５９】
そして、データの実体であるＢＩＤは図中でＳＤＥと表されている一つ以上のストライフから構成されている。ストライプは画像を固定のライン数で区切ったもので、１ストライプを構成するライン数はＢＩＨ内でＬ0として宣言される。ストライプ長はファクシミリ装置においては１２８ラインが必須であるが、送信側／受信側の双方がストライプ長を可変とすることが可能な場合には、別のライン数を使用しても良く、またＢＩＤ全体を１ストライプで構成しても良い。
【００６０】
ストライプデータはＥＳＣ，ＳＤＮＯＲＭ（０ｘｆｆ，０ｘ０２）あるいはＥＳＣ，ＳＤＲＳＴ（０ｘｆｆ，０ｘ０３）で終端が区切られる。ストライプとストライプの間にはフローティングマーカーセグメントという制御情報を挿入できる。フローティングマーカーセグメントにはいくつかの種類があるが、本発明に関係するのはＮＥＷＬＥＮマーカーセグメントで、これはＢＩＨ内でＹDにより宣言された副走査長を変更するためのものである。ＮＥＷＬＥＮを使用すると符号化開始時点ではライン数が不明な場合にも、ＹDには暫定的に大きな値を設定して符号化を開始し、正確なライン数が判明した時点でＮＥＷＬＥＮを使用して正しいライン数を宣言しなおすことができる。これはスキャナ等から読み取った画像をリアルタイムで符号化する時に有効な方法である。
【００６１】
Ｔ．８２ではＮＥＷＬＥＮは最後のストライプの前までに宣言しなくてはならなかったが、Ｔ．８５では最終ストライプを符号化した後にＮＥＷＬＥＮで正しいライン数を宣言し、その後ろにダミーのデータが存在しないストライプ（ＮＵＬＬストライプ）を付加してデータを終結することが許されている。
【００６２】
ここで本実施形態の前提となる動作を説明すると、本実施形態では受信時にはＪＢＩＧのベーシックモードのみサポートする。すなわちＩＴＵ−ＴのＴ．３０勧告で定義されるＤＩＳ／ＤＴＣのビット７８のみ宣言し、ビット７９のＬ0変更能力は宣言しない。これにより相手機は常に１ストライプ＝１２８ラインで送信を行う。
【００６３】
受信機は前述の様に受信したＪＢＩＧ画像を復号して、前記ＲＡＭ１０８内のラインバッファに生データの形式で蓄積する。このラインバッファは本実施形態では１２８本を有しているので１ストライプのデータは必ず蓄積可能である。
【００６４】
そして１ストライプの復号が終了するたびに、ラインバッファ内のデータを再度別の符号化方式で符号化し、これも前記ＲＡＭ１０８内に蓄積する。本実施形態ではこの再符号化に使用する符号化方式はＭＲとするが、これはＭＭＲ等、別の符号化方式を使用しても問題はない。蓄積された画像は主に記録部１０９を通して印字されるが、ＰＣＩ／Ｆ部１０６を通してホストコンピュータ１１１へアップロードしても良く、また他の装置へ送信しても良い。
【００６５】
以下、図５のフローチャートを使用して本実施形態における復号動作を説明する。受信動作および、復号後の記録／アップロード等の動作は公知の技術なので記述しないが、図５のフローを開始する前に、Ｔ．３０の手順は開始されて画像の受信は始まっており、記録／アップロード等の動作は図５のフローで１ページの復号が終了した後に行われるものとする。また、特に断りがない限り、各処理の主体はＣＰＵ１０１である。
【００６６】
最初に処理の概要を説明する。本発明では、少なくとも一つのユニットからなる元データを第１の情報圧縮符号を用いて該ユニットごとに情報圧縮が施されてなる第１の圧縮データを受信するステップと、前記第１の圧縮データから圧縮前のユニットを復号するステップと、前記復号されたユニットを蓄積するステップと、前記蓄積されたユニットのうち情報として意味のある位置までを順次読み出し、読み出されたユニットごとに順次第２の情報圧縮符号にて再度情報圧縮し第２の圧縮データを生成するステップと、前記第２の圧縮データを出力するステップとを含むものである。
【００６７】
このように本実施形態では、ユニット単位で順次復号処理しながら、意味のある情報の最終位置、すなわち元データの終端を監視し、不要な部分を除いた残りを再符号化する構成としたため、ゴミラインの発生を極力防止できるよう。以下に構成の詳細を示す。
【００６８】
まずＳ５０１で変数の初期化を行う。フロー中に記載される変数は全てＲＡＭ１０８内部に置かれる。変数ｔｏｔａｌ＿ｌｉｎｅは１ページのライン数で基本的にはＪＢＩＧ画像の先頭のＢＩＨ（ヘッダー部）内でパラメータＹDとして渡されるので、Ｓ５０１ではＹDの値をｔｏｔａｌ＿ｌｉｎｅに書き込む。変数ｄｅｃ＿ｌｉｎｅは復号化済みのライン数、変数ｅｎｃ＿ｌｉｎｅは再符号化済みのライン数でここではどちらも０に初期化する。次にＳ５０２で変数ｓｔｒｉｐｅ＿ｌｉｎｅを０に初期化する。これは現在注目しているストライプ内にあるライン数を表す。念のため、初期化とはＣＰＵ１０１が、変数に０等の値を代入してＲＡＭ１０８に書き込むことをいう。
【００６９】
そしてＳ５０３で１ラインのＪＢＩＧデコードを行う。デコード結果の生データは前記ＲＡＭ１０８内部のラインバッファに格納される。そしてＳ５０４で変数ｄｅｃ＿ｌｉｎｅとｓｔｒｉｐｅ＿ｌｉｎｅにそれぞれ１を加算する。
【００７０】
次にＳ５０５で１ストライプのデコードを終了したかどうかをチェックする。本実施形態では受信機は１ストライプ＝１２８ラインのモードでのみ動作するので、ストライプの終了は１２８ラインのデコードを終了した場合か、画像の最後で１２８ラインに満たないラインでストライプが終了した場合にＹＥＳとなる。ここでＮＯの場合にはＳ５０３に戻ってデコードを続行する。本実施形態ではラインバッファは１ストライプに相当する１２８本を有しているので、ストライプの途中でラインバッファがフルになることはない。なお、Ｓ５０５だけでなく、他の判断ルーチンＳ５０６、Ｓ５０７及びＳ５１３はいずれもＣＰＵ１０１の判定部１５３において判定がされる。
【００７１】
Ｓ５０５で１ストライプの終了を検出した場合、Ｓ５０６でまだデータがあるかどうかをチェックする。次データが存在しない場合にはこれで画像は終了なのでＳ５０９へ進む。Ｓ５０６でデータが残っている場合には、Ｓ５０７でそれがＮＥＷＬＥＮマーカーかどうかをチェックする。ＮＥＷＬＥＮでなかった場合にはＳ５０９へ進んで処理を続行する。尚、ストライプ間のフローティングマーカーセグメントとしてはＮＥＷＬＥＮ以外にも他のものが存在するが、本発明には関係しないのでそれらの処理は図示しない。
【００７２】
Ｓ５０７でＮＥＷＬＥＮを検出した場合には、Ｓ５０８へ進みＮＥＷＬＥＮに付属してきたライン数を持って、変数ｔｏｔａｌ＿ｌｉｎｅを書き換える。そしてＳ５１０でｔｏｔａｌ＿ｌｉｎｅとｄｅｃ＿ｌｉｎｅの比較を行う。ここで新たに指示されたｔｏｔａｌ＿ｌｉｎｅがこれまでにデコードが済んだライン数を示すｄｅｃ＿ｌｉｎｅよりも大きかった場合には、まだ画像が続くので、Ｓ５０９へ進んで処理を続行する。これはＴ．８２でも許されていた最終ストライプ前に宣言されるＮＥＷＬＥＮの場合の動作である。
【００７３】
Ｓ５０９ではそのストライプ内でデコードされたライン数であるｓｔｒｉｐｅ＿ｌｉｎｅに従って、ＭＲでの再符号化を行う。そして、Ｓ５１１では再符号化されたライン数を示すｅｎｃ−ｌｉｎｅにｓｔｒｉｐｅ＿ｌｉｎｅの値を加算する。
【００７４】
このように、本実施形態は１ストライプを単位として復号と再圧縮を繰り返すように構成したので、ＪＢＩＧで復号された圧縮データを受信しながらリアルタイムで復号を行うことが可能となり、ひいては、高いスループット得られよう。
【００７５】
そしてＳ５１３でｅｎｃ＿ｌｉｎｅとｔｏｔａｌ＿ｌｉｎｅを比較して、ｔｏｔａｌ＿ｌｉｎｅの方が大きければ、まだデータが残っているのでＳ５０２に戻って処理を続行する。さもなければ復号は終了である。これはＮＥＷＬＥＮを使用しない、またはＴ．８２で許されていた最終ストライプ前のＮＥＷＬＥＮを使用する場合の終了手順となる。
【００７６】
Ｓ５１０でｄｅｃ＿ｌｉｎｅがｔｏｔａｌ＿ｌｉｎｅと等しいか、あるいはより大きい場合は、送信側が符号化した以上のラインが復号されてしまっていることになる。これが本発明が解消しようとしているゴミラインであり、Ｔ．８５で認められた最終ストライプ後のＮＥＷＬＥＮの使用により発生する現象である。この場合はＳ５１２で新たに指示されたｔｏｔａｌ＿ｌｉｎｅから既に再符号化を行ったライン数であるｅｎｃ＿ｌｉｎｅを引いた値だけの再符号化を行う。これにより送信側で符号化された以上のラインが受信側に発生することはなくなり、最終ストライプ後のＮＥＷＬＥＮの使用により発生する課題も解決できよう。以上が本発明の実施形態におけるＪＢＩＧのデコード処理である。
【００７７】
本実施形態では、上述のようにＰＣにアップロードする前に、再圧縮を行いアップロードファイルの作成が終えているため、ファクシミリ装置の符号化性能がたとえ十分でなくとも、それが転送時のボトムネックとはならないという効果が生じる。
【他の実施形態】
・送受信時おけるラインバッファの共有
尚、本発明を実現する場合には１２８本以上のラインバッファを必要とするが、送信時にはそれをＪＢＩＧの符号化に使用する他の実施形態も可能である。この構成によれば、ストライプ単位のエンコードが可能となり、ひいては、Ｔ．８５で認められた最終ストライプ後のＮＥＷＬＥＮを使用せずに最終ストライプ前にＮＥＷＬＥＮを送ることができるので、不要なデータが付加されてしまうこともない。従って、本発明の様なゴミラインの削除処理機能を持たない従来の受信機であっても、送信側に本発明の他の実施形態を用いれば、その印刷時やアップロード時にゴミラインが極力生じないという利点がある。
・ラインバッファを削減したファクシミリ装置が画像の最後にＮＥＷＬＥＮを付加する場合の対策
ところで、Ｔ．８５勧告でも従来通り先頭のＹDで正しい総ライン数を宣言したり、最終ストライプの送信以前にＮＥＷＬＥＮで総ライン数を宣言したりすることも可能である。しかし、ラインバッファを削減したファクシミリ装置が画像の最後にＮＥＷＬＥＮを付加する方式で送信してくるケースも現実に存在する。
【００７８】
この問題を回避する実施形態としては、１ページ分のバッファを備えた受信側は、受信したＪＢＩＧデータをそのままの形式で保存して、最終的に受信したＮＥＷＬＥＮの値で画像先頭のＹDを書き換えてから復号を開始すればよい。
・１ページ分のバッファを持つことが困難な場合
コストや他の理由から、ＪＢＩＧで１ページ分のバッファを持つことが困難な場合もあろう。また、受信を完全に終了してから復号を開始するのでは、スループットが低下するおそれもある。この課題を解決するには、ページバッファとハードウェアのデコーダを備える構成にすればよい。
・印字またはアップロード時の制御により対応する場合
より簡単に対応するには、ＹDあるいはＮＥＷＬＥＮで指定された総ライン数を画像の有効ライン数として、画像とは別にＲＡＭに保持しておき、受信画像を印字する際に、ＣＰＵで印字制御することで、前記有効ライン数までを印字することできよう。これなら、画像の後端にゴミラインが付加されていても、それは印字されることはない。  なお、ファクシミリ装置をＰＣ（パーソナルコンピュータ）等の外部装置と接続して受信画像のアップロードを可能とする場合受信画像の後端にゴミが付加されていることはトラブルを招く恐れがある。
【００７９】
この場合は、ＰＣ上で表示あるいはＰＣからプリンタへ転送して印字を行った場合には画像の後端にゴミが表れてしまうので、最初に説明した本発明の実施形態を用いればよい。なお、先の実施形態に比べると複雑な処理となるが、ＰＣにアップロードしたファイルの特定のライン以降にゴミがある旨の情報を、ＰＣの印刷プログラムに渡すことで印刷制御をしてもよい。
【００８０】
もしくは、ＰＣへの転送時に画像の復号を行い、装置が保持している有効ライン数までで転送を終了させてもよい。ただし、装置とＰＣとのインタフェースは通常ＵＳＢ(Universal Serial Bus)やセントロニクス標準のＥＣＰ(Extended Capabilities Port)モードを使用していて数百ＫＢ／ｓから数ＭＢ／ｓの能力を持つのが一般的なのに対して、ファクシミリ装置の復号速度は通常通信回線の能力に合わせて３３．６〜６４Ｋｂｉｔ／ｓ程度に過ぎないので、この様な処理を行うことはアップロードの性能を大きく制約してしまうかもしれない。その点では、先の実施形態が有効である。
・その他
本発明は、複数の機器（例えばホストコンピュータ、インタフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００８１】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８２】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８３】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明した図５に示すフローチャートに対応するプログラムコードが格納されることになる。
【００８４】
【発明の効果】
以上説明したように、本発明によれば、受信しながらリアルタイムで復号を行うことで高いスループットでの動作を可能としつつ、装置内部に蓄積された再符号化データに余分なゴミラインが付加されることを防ぎ、そのままＰＣ等へ高速でアップロードを行うことが可能となる。
【図面の簡単な説明】
【図１】  本発明の実施形態に係るファクシミリ装置の構成を示すブロック図である。
【図２】  本発明の実施形態に係る機能ブロック図である。
【図３】  本発明の実施形態に係るＲＡＭに記憶されるデータを示した図である。
【図４】  ＪＢＩＧデータの構造図である。
【図５】  本発明の実施形態に係るファクシミリ装置の動作を示すフローチャートである。
【図６】  従来のＮＥＷＬＥＮの使用法の例を示す図である。
【図７】  Ｔ．８５勧告で認められたＮＥＷＬＥＮの使用法の例を示す図である。
【図８】  余剰なストライプを復号した場合の課題を示す図である。
【図９】  本発明の情報処理システムを示す図である。
【符号の説明】
１０１  ＣＰＵ
１０２  操作部
１０３  表示部
１０４  ＭＯＤＥＭ
１０５  ＮＣＵ
１０６  ＰＣ  Ｉ／Ｆ部
１０７  ＲＯＭ
１０８  ＲＡＭ
１０９  記録部
１１０  読取部
１１１  ホストコンピュータ
【図１】
0003715883.tif 000002
【図２】
0003715883.tif 000003
【図３】
0003715883.tif 000004
【図４】
0003715883.tif 000005
【図５】
0003715883.tif 000006
【図６】
0003715883.tif 000007
【図７】
0003715883.tif 000008
【図８】
0003715883.tif 000009
【図９】
0003715883.tif 000010