JPH02142275A - 画像通信方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 ［産業上の利用分野］ 本発明は、画像データを半二重の伝送回線を用いて伝送
する際の画像通信方式に関する。

［従来の技術］ 従来、画像データを電話回線などを用いて半二重の通信
で伝送する際には、以下のような手順が知られている。

すなわち、第９図に示すように、 ０画像データを１ラインごとにＣＲＣなとの誤り検出コ
ードを付加して伝送フレーム化し、数フレームを１ブロ
ツクとして伝送する。

■１ブロックの伝送が終了すると、送信側は伝送したブ
ロックの誤り検出結果を要求し、■受信側はこの要求に
対して誤りのあったフレームを送信側に応答し、■送信
側はこの応答に基づき誤りのあったフレームを再送する
。

以上の手順を繰返して１つのブロックのついて誤りがな
くなるまで再送を繰返す。このブロックの伝送を何回か
行うことにより、１枚の画像の伝送が行われる。

この従来の伝送方式について、具体例を用いてさらに説
明を行う、いま、画像データは横６４０゜縦４８０の画
素からなり、１画素は８ビツトの階調を持つ画像とする
。１ライン分の画像データを予測符号化などの圧縮手法
を用いて圧縮し、圧縮データに）ＩＤＬＣ（）Ｉｉｇｈ
　１ｅｖｅｌ　Ｄａｔａ　Ｌｉｎｋ　Ｃｏｎｔｏｒｏｌ
）のフレーミングを施す。ここで、一般にＨＤＬＣのフ
レーミングとは第７図（Ａ）　　に示すように、初めと
終りにフラグパターン０１１１１１１０を付加して内部
に１バイトのアドレスフィールド、１バイトのコントロ
ールフィールド、不定ビット長の情報フィールドそして
２バイトのＣＲＣ（Ｃｙｃｌｉｅ　Ｒｅｄｕｎｄａｎｃ
ｙｃｈｅｃｋ　Ｃｏｄｅ）を含んでいる。このＣＲＣは
予め定められた多項式で、前のフラグパターンの次のビ
ット（つまりアドレスフィールドの先頭ビット）からＣ
ＲＣの直前のビット（つまり情報フィールドの最終ビッ
ト）までを、モデュロ２の演算で除算した余りである。

）ＩＤＬｃではアドレスフィールド、コントロールフィ
ールドの情報を用いて通信の制御を行うが、特にこれら
のフィールドは活用せずに第７図（Ｂ）のごとく情報フ
ィールドに２バイトのフィールドを設けることもできる
。このフィールドのＭＳＢ　（ＭｏｓｔＳｉｇｎｉｆｉ
ｃａｎｔ　ｂｉｔ：最上位ビット）が制御情報と画像圧
縮データ情報との識別に用いられる。画像データ情報の
場合は、第７図（Ｃ）のどと＜　ＭＳＢを「０」として
、残りの１５ビツトをフレーム番号とし、その後に画像
圧縮データを付ける。制御情報の場合は、第７図（Ｄ）
のどと＜　ＭＳＢを「１」として、残りの１５ビツトに
は予め定められた制御を表わす制御コードを割り当てる
。

画像は４８０ラインから成るので、４８０の画像圧縮デ
ータフレームによって伝送される。この４８０フレーム
を第８図に示すように１２０フレームずつ４つのブロッ
クに分けて伝送する。この伝送の様子を再び第９図を用
いて説明する。

第９図では既に回線が接続された状態からの伝送制御手
順を示しである。

送信側はブロック「０」から送信を始める。■の伝送に
よって１２０の画像圧縮データのフレームが伝送される
。受信側は■のデータを受信しながら、ＣＲＣチエツク
によって誤り検出を行い、誤りがない場合は１フレーム
ごとに圧縮コードを画像に復元する。

送信側は■の伝送の後、第７図（Ｅ）に示すごとく情報
フィールドに誤りチエツク要求を表わすコードと画像ブ
ロック番号を含んだ制御フレームを、■の送信で受信側
に送信する。

受信側は■の誤りチエツク要求を受信した時点で、■の
情報フィールドのブロック番号よりそのブロックのフレ
ームの誤り検出結果を調べ、■の応答で送信側に誤りの
情報を知らせる。

■の応答は、誤り検出結果を示すコード、ブロック番号
、誤りフレームの個数および誤りフレームの番号を情報
フィールドに含む制御フレームを送信することにより行
われる。誤りが無かった場合のフレームおよび誤りが有
った場合のフレームは、例えばそれぞれ第７図（Ｆ）お
よび（Ｇ）のようになる。

誤りフレームがない場合は、送信側は次のブロックを伝
°送を■に戻って始める。誤りがあった場合は、■の応
答より誤りの有ったフレームのみを■の伝送で再送し、
再度■と同じ誤り検出要求を■の送信で受信側に要求す
る。

受信側は■の要求を受は取り、再度誤り検出結果を調べ
、■と同様の制御フレームによって誤り検出結果を送信
側に応答する。

以上の■〜■の繰返しで１つのブロックに誤りがなくな
るまで通信を行い、誤りがなくなった時点で、送信側は
次のブロックの伝送を■に戻って始める。

以上の通信手順に従い、４つのブロックの伝送を行うこ
とにより、受信側で１枚の画像が復元される。

ここで、以上述べた通信方式に関し、受信側の圧縮復号
において特に１つのフレームの復号が他のフレームの復
号結果を用いる場合について説明する。例えば、２次元
の予測を行う予測符号化などでは予測の際に前のライン
の復号結果を用いるので、前のラインが正しく復号され
ていなければそのラインは複合できない。

このように、あるフレームに伝送誤りが生じた場合に、
誤りなく受信されていても復号できないフレームが生じ
てしまう。このような場合、受信装置は誤りのあったフ
レームが正しく誤りなく再送されてから前に影響を受け
たフレームを復号できる。このような場合、再送がなさ
れるまで受信装置は誤りの影響を受けて復号できないフ
レームを保持する必要があるので、１ブロツクの符号量
以上のバッファ容量を持つ必要がある。

このバッファの容量は、画像の圧縮率に依存する。画像
の圧縮率は画像の内容によって大きく異なる場合があり
、画像によっては通常の６倍程の符号量にもなり得る。

例えば、通常の画像では平均２ビット／ビクセルの圧縮
率である場合に、画像によっては１２ビツト／ビクセル
の圧縮率になる場合も有り得る。

［発明が解決しようとする課題］ 従って、上記従来例では、バッファのオーバーフローを
防ぐために最悪の場合を想定して１２（ｂｉｔ／ｐｉｘ
ｅｌ）　Ｘ６４０（ｐｉｘｅｌ）Ｘ１２Ｇ（ｌｉｎｅ）
＝　９２１６００ビット＝１１２．５キロバイトのバッ
ファ容量を必要とする。

一方、通常の画像で２ビツト／ビクセルの圧縮率が得ら
れるならば、 ２　ｘ　６４０　ｘ　１２０ビツト＝　１５３６００ビ
ツト＝　１８．７５キロバイト 程度のバッファ容量で済む、従って、最悪の場合を想定
して１１２．５キロバイトのバッファ容量を設定するの
はコストの面で不利である。

よって本発明の目的は、上述の点に鑑み、受信側におい
てコストに見合った適切な容量のバッファを設定できる
ようにした画像通信方式を提供することにある。

［課題を解決するための手段］ かかる目的を達成するために、本発明に係る画像通信方
式は、ディジタル画像データを圧縮して伝送する画像通
信方式において、送信局から受信局に対して受信バッフ
ァ容量の情報を要求し、受信局は該要求に応じて自局の
バッファ容量を送信局に応答し、送信局は受信局から応
答された前記受信バッファ容量に応じて画像圧縮データ
を受信局に伝送するものである。

［作　用］ 本発明によれば、送信側は画像データの通信を行う前に
受信側のバッファ容量を受信側と通信して調べておき、
この受信側のバッファ容量に応じて１ブロツクのフレー
ム数を可変して送信する。

つまり、実際にデータを送信する際に、総送信データ量
を計数し、受信側のバッファがほぼ満たされたところで
画像データブロックの伝送を終了し、受信側に対しその
伝送したフレームについてエラー検出の命令を送信でき
る０以上の通信プロトコルによって、受信側はコストに
見合った適当な容量のバッファを設定することができる
。

［実施例］ 以下に、本発明の実施例を具体的に説明する。

第１図は本発明に従った通信プロトコルの一例を、第２
図は本通信プロトコルを行う画像通信装置の一構成例を
示す。

第２図において、１は本装置の制御を行うＣＰｔ１　、
４はビデオ信号をＡ／Ｄ変換するＡ／Ｄ変換器、５は＾
／Ｄ変換されたビデオ信号を蓄積しＤ／＾変換器７を用
いて表示させる画像メモリアある。

６はＣＰ旧から与えられたパラレル８ビツトのデータを
シリアルのデジタルデータに変換してモデム８に渡すパ
ラレル／シリアル変換器であり（モデム→ＣＰｕのとき
は、シリアル−パラレル、デフレーミングの機能をもつ
）、またＨＤＬＣのフレーミングやＣＲＣの検査などを
行う機能をもつ（以下の説明においては、シリアルＩ１
０と呼ぶ）。８はモデムであり、パラレル／シリアル変
換器６から渡されるシリアルのデータを変調しＮＣｕ　
１０を介して伝送路に送出し、あるいは伝送器からＮＣ
ＵＩＯを介して受信した信号を復調してシリアル■１０
６にシリアルデータとして伝送する機能を果す。ｌＯは
伝送路を制御して回線を接続するＮＣＩＪ　（Ｎｅｔｗ
ｏｒｋ　Ｃｏｎｔｒｏｌｌ　Ｕｎｉｔ）、９は使用者と
の通信を行うためのマンマシンインターフェースである
。２は本装置の制御手順を記憶させであるＲＯＭであり
、（ｉ）マンマシンインターフェース９との通信を行う
ルーチン（ｉｉ）画像メモリ５の制御、シリアルＩ１０
６　、モデム８．ＮＣＵＩＯを制御してデータの送受信
を行うルーチン（ｉｆｆ）画像メモリに蓄積された画像
データを圧縮／伸張するルーチンを記憶させである。

第２図に示した装置が伝送路へＨＤＬＣフレームを送出
する際には、フレームのデータ長をシリアルｌ１０６に
プログラムし、シリアルｌ１０６はそのバイ゛ト長に対
して）ＩＤＬＣのフレーミングを施してシリアルのデー
タ列としてモデム８にデータを渡す。

シリアルＩ１０６は１バイトのシリアルデータをモデム
８に渡すたびに割込みを発生し、ホストＣＰＵに送信デ
ータ（１バイト）を要求することができる。この割込み
で割込みルーチンはＲＡＭ上に設けられたデータバッフ
ァから順次データを１バイトずつシリアルｌ１０６に渡
してゆくことにより、連続的にデータがモデム８．ＮＣ
ｌ１１０を介して伝送路へ送出される。

第２図の装置がＨＤＬＣフレームを受信する際に、シリ
アルＩ１０６は１（ＤＬＣの先頭フラグを検出した後に
１バイト分のシリアルデータをモデム８から受は取る度
に割込みを発生し、ホストＣＰＵにデータの引き取りを
要求する。割込みルーチンでは、シリアルＩ１０６から
データ（１バイト）を受は取り、ＲＡＭ上に設けられた
データバッファに順次蓄えてゆく、また、ＨＤＬＣの終
結フラグを受信した時点で、シリアルｌ１０６は割込み
を発生させ、この割込みによりホストＣＰｔ１はシリア
ル■１０６のＣＲＣ演算結果を調べることにより、受信
したフレームにエラーがあったか否かを判定する。

以上のように割込みによりデータの送受信を行えば、画
像を圧縮符号化しながらデータを送信する、あるいはデ
ータを受信しながら画像を伸長復号することが可能とな
る。

第２図の装置が本通信プロトコルを行う送信機・受信機
として機能するためには、それぞれ第３図および第４図
に示す領域を各ＲＡＭ上に設ける必要がある。それぞれ
の領域の使用法については、以下に詳しく述べる。

送信局は圧縮データフレームを送信する前に、第１図（
ａ）の通信で受信局のバッファ容量（バイト単位）を要
求する。これは第５図（Ｂ）に示すような予め定められ
たバッファ容量を要求するコードを情報フィールドに含
む制御フレームを送信することによってなされる。

受信局はこの制御フレームを受信すると、自局に設定さ
れている受信バッファ容量を情報フィールドにおさめた
制御フレームを第１図（ｂ）の通信で送信局に返送する
。−例として、受信局かにバイトの受信バッファを持つ
場合は、第５図（Ｃ）のような制御フレームを返送する
。ただし、実際のバッファ容量は制御フレーム受信のた
めのデータ容量分の余裕を見であるものとする。

送信局は第１図（ｂ）の通信で得た受信局のバッファ容
量と自身のデータバッファ容量を比較し、小さい方の容
量をＲＡＭ上のＲｘ　Ｂｕｆｆ　Ｃａｐａｃｉｔｙに格
納する。送信局ではこのＲｘ　Ｂｕｆｆ　Ｃａｐａｃｉ
ｔｙを越えない範囲で、第１図（ｃ）に示す如く画像デ
ータフレームを送信する。

Ｏａｔ　Ｂｕｆｆに空領域があると、送信局の画像圧縮
ルーチンは画像メモリの画像データを圧縮符号化してＤ
ａｔ　Ｂｕｆｆに順次格納してゆく。この際Ｆｒａｍｅ
ＩｅｎｇｔｈＪｂｌにはそのフレーム番号のデータ長を
、Ｆｒａｍｅ　ａｄｄｒｅｓｓ　ＴＢＬにはフレームデ
ータの先頭アドレスを格納する。従って、画像データを
送信するルーチンはＦｒａｍｅ　ａｄｄｒｅｓｓ　ＴＢ
Ｌから圧縮データの格納されているＤａｔ　Ｂｕｆｆ領
域の先頭アドレスを得、Ｆｒａｍｅ　Ｌｅｎｇｔｈｊｂ
ｌからそのフレームのデータ長を知ることができる。

圧縮された画像データのフレームは以下のような手順で
受信局に送信される（第１図（ｃ）参照）。

Ｔｘ　　ＯＦｉｓｔ　Ｆｒａｍｅ、ＦｒａＩＩｌｅ　Ｃ
ｏｕｎｔｅｒを０にリセットする。

Ｔｘ　　Ｉ　　Ｔｘ　Ｄａｔ　Ｃｏｕｎｔｅｒを０にリ
セットする。

Ｔｘ　　ＩＩ　　（ｉ）　Ｆｒａｍｅ−Ｃｏｕｎｔｅｒ
のフレーム番号によりＦｒａｍｅＪｅｎｇｔｈ−Ｔｂｌ
を参照して、そのフレームのデータ長を得る。このデー
タ 長とＴｘ−Ｄａｔ　Ｃｏｕｎｔｅｒとの和がＲｘ　Ｂｕ
ｆｆ（：ａｐａｃｊｔｙよりも大きい場合は、第１図（
ｄ）の通信へ進む。そうでなければ、（ｉｆ）へ進む。

（ｉ　ｉ）　Ｔ３Ｄａｔ　Ｃｏｕｎｔｅｒに（ｉ）で求
めたデータ長を加える。

（ｉｉｉ）Ｆｒａｍｅ−ＣｏｕｎｔｅｒのＦｒａｍｅ番
号を用いてＦｒａｍ３ａｄｄｒｅｓｓ　ＴＢＬを参照し
、圧縮データフレームの先頭アドレスを得て、このアド
レスをＤａｊｇｅｔ　ＰＴＲに設定する。

（ｉｖ）変換器６を（ｉ）で求めたフレームのデータ長
を表わすデータをＨＤＬＣフレーミングするようにプロ
グラムする。

シリアルｌ１０６はＨＤＬＩＩ：の前置フラグを′ｘ Ｔｘ ■ ＩＶ 数バイト出力した後、１バイトのシリアルデータをモデ
ムに渡す度に割込みを発生し、ホストＣＰＵにデータを
要求する。

この割込みでＴｘ　　Ｉｌｌが割込みルーチンとして起
動される。

また、シリアルｌ１０６は（ｉｖ）で与えらえたデータ
長のデータをモデムに渡し終えると、ＨＤＬＣの終結フ
ラグを送出する。

フレームデータを全て送出した時点で、シリアルｌ１０
６は割込みを発生する。この割込みでＴｘ　　ＩＶが割
込みルーチンとして起動される。

Ｄａｊｇｅｔ−Ｐｔｒの指すＤａｔ−Ｂｕｆｆ上のアド
レスから１バイトのデータをシリアル ｌ１０６に渡し、Ｄａｊｇｅｔ−Ｐｔｒの内容を１だけ
インクリメントする。

Ｒｒａｍｅ　Ｃｏｕｎｔｅｒの内容を１だけインクリメ
ントする。全ての画像フレームの送信が終了したら、第
１図（ｄ）の通信を行う。そうでなければ、Ｔｘ　　Ｉ
Ｉへ進む。

以上の手順において、Ｔｘ　　ＩＩ　　（ｉ）で第１図
（ｄ）の通信へ進むまでに画像データフレームの伝送が
行われるが、この伝送では常にＲｘ−ＢｕｆｆＣａｐａ
ｃｉｔｙの内容よりも少ないデータ量が受信局へ送られ
る。この時点でＦｉｒｓｔＪｒａｍｅからＦｒａｍｅＣ
ｏｕｎｔｅｒ−１までのフレーム番号のフレームが送信
される。

受信側では、第１図（Ｃ）の画像データフレームを以下
の手順で受信する。

Ｒｘ　　ＯＤａｔ　Ｐｕｔ、ＰＴＲにＤａｔ　Ｂｕｆｆ
の先頭アドレスを格納する。

Ｒｘ　　Ｉ　　（ｉ）　ＦｒａｍｊＴＲＴ−ＰＴＲにＤ
ａｔ−Ｐｕｔ−Ｐｔｒの内容を格納する。

（ｉｆ）　シリアルＩ１０をＨＤＬＣのフレームを受信
するようにプログラムする。

シリアルＩ１０はＨＤＬＣの前置フラグを検出した後に
１バイトのデータを受信する度に割込みを発生し、ホス
トＣＰｕにデータの引き取りを要求する。この割込みで
Ｒｘ　　ＩＩの割込みルーチンが起動される。

また、シリアルＩ１０はＩ（ＤＬＣの終結フラグを受信
すると割込みを発生する。

この割込みで、Ｒｘ　　ＩＩＩの割込みルーチンが起動
される。

Ｒｘ　　ＩＩ　　ｍホストｃｐｏはシリアルＩ１０から
１バイトのブタを受は取り、Ｄａｔ　Ｐｕｔ　Ｐｔｒの
指すアドレスにこのデータを格納する。

（ｉ　ｆ）　Ｄａｔｊｕｔ　Ｐｔｒの内容を１だけイン
クリメントする。インクリメントされた値がＤａｔａＪ
ｕｆｆの終り（Ｏａｔ　Ｂｕｆｆ　ｅｎｄ）よりも大き
い場合は、Ｏａｔ　Ｐｕｔ　ＰｔｒにＯａｔ　Ｂｕｆｆ
の先頭アドレス（ＤａｊＢｕｆｆ　５ＴＲＴ）を格納す
る。

Ｒｘ　　ＩＩＩ　　ホストｃｐｕはシリアルＩ１０のＣ
ＲＣ検査結果を調べる。

（ｉ）エラーが検出された場合、受信したフレーム情報
は誤りが有ったことになるので、そのフレーム情報は消
去される。すなわち、次のフレームの受信のために、Ｆ
ｒａｍｅ　５ＴＲＴ　ＰＴＲの内容をＤａｔ　Ｐｕｔ　
Ｐｔｒに格納してＲｘ　　Ｉへ進む。

（ｉｆ）エラーがなかった場合は、受信したフレームに
ついて、画像デルタフレームであるかまたは制御フレー
ムであるかを解析する。これはＦｒａｍｅ　５ＴＲＴ　
ＰＴＲの指すアドレスから情報フィールドを参照するこ
とにより行われる。

（Ｏｉ）画像データフレームであった場合、受信された
フレームの情報フィールドにある画像データフレーム番
号を用いて、Ｆｒａｍｅ　ａｄｄｒｅｓｓ　ＴＢＬの受
信されたフレーム番号を示す場所にＦｒａｍｅ　５ＴＲ
Ｔ　ＰＴＲに格納されているアドレスを格納する。ま た、ＣＲＣｊＨＫ　Ｔｂｌの受信されたフレーム番号を
示す場所に、このフレームについてエラーが無かフたこ
とを示すコードを格納する。画像を復号するルーチンは
ＣＲＣ−Ｃ）Ｉに−Ｔｂｌの内容を見て正常に受信され
たフレーム番号を得、Ｆｒａｍｅ　ａｄｄｒｅｓｓＴＢ
Ｌからその圧縮コードの存在位置を知り、復号してゆく
ことができる。

（ｉｖ）制御フレームであった場合、フレームの内容を
解析してそれに応じた処理を行う。Ｆｒａｍｅ　５ＴＲ
Ｔ　ＰＴＲの内容を０ａｔ−ＰｕｔＰｔｒへ格納する。

以上の処理により、送信側から送信された画像データフ
レームの受信が完了する（第１図（Ｃ）参照）。

送信側は次に、第１（ｄ）の通信において、受信側へ伝
送し終ったデータフレームのエラー検出結果を要求する
。第１図（Ｃ）の通信において、フレーム番号ｆＳから
ｆＬまでを送信した場合、第５図（Ｄ）のような制御フ
レームを受信側に送信する。

受信側ではこの制御フレームをＲｘ　　ＩＩＩ　（ｉｖ
）で解析し、誤り検出結果要求であることを認識し、フ
レーム番号ｔｓからｆＬまでのＣＲＣＣＨＫ　Ｔｂｌを
調査し、受信されていないフレームがあれば第７図（Ｇ
）のような制御フレームを、また全て正常に受信されて
いれば第７図（Ｆ）のような制御フレームを返送する。

そして、Ｒｘｌからフレームの受信を始める。

送信側は第７図（Ｆ）に示す返信を受は取った場合、第
１図（Ｃ）の伝送で使用していたデータバッファを圧縮
ルーチンに解放する。そして、手順Ｔｘ　　Ｉから次の
画像データフレームを伝送してゆく。

第７図（Ｇ）の返信を受は取った場合は、第７図（Ｇ）
のフレームからエラーの報告されたフレーム番号を用い
、Ｆｒａｍｅ　ｌｅｎｇｔｈ　Ｔｂ１．Ｆｒａｍｅ　ａ
ｄｄｒｅｓｓＴＢＬの情報を用いて第１図の送信により
受信側へ伝送する。エラーのあったフレームを全て送信
終了すると、第５図（Ｄ）　　と同じフレームフォーマ
ットで誤り検出結果を受信側に要求する（第１図（ｆ）
　、　（ｇ）参照）。

以上の手順によれば、Ｒｘ　　ＩＩＩ（ｉ）でエラーの
あったフレームは受信バッファーには残さないようにし
ているので、エラーフレームの再送が行われても受信側
の受信バッファをオーバーフローすることは有り得ない
。

しかし、次のような場合には１つの画像データブロック
の受信の直後に画像データフレームに受信障害が起こり
得る場合がある。つまり、あるフレームにエラーが生じ
て再送で受信された場合、そのフレームのエラーによっ
て影響を受けて復号できなかったデータフレームが存在
しているときには、これらのフレームを復号してしまわ
なければ次のデータを受信できないことがある。

端的な例として、第６図のような場合が考えられる。す
なわち、エラーのあったフレームが再送され、データバ
ッファの最後のあたりに格納されたとする。そして、こ
のフレームのエラーによって復号できなかったデータフ
レームがデータバッファの先頭に格納されているとする
。この場合、復号ルーチンは再送されたフレームＦ「を
復号してから影響を受けていたデータフレームＦｒ’　
を復号できる。一方、次の画像データを受信するには、
データバッファの先頭から受信してゆくことになるが、
このときにはＦｒ’　の復号はまだ終了していない可能
性がある。

そこでこの問題を解決するために、次の方式を採ること
ができる。すなわち、第１図（ｂ）の通信において受信
側から送信側へ伝える受信バッファの容量を実際の容量
よりも数フレーム分小さな値を伝える。このことにより
、１つの画像データブロックの送受信が終了しても、常
に次の画像データフレームを受信するデータバッファ領
域が存在するので、上記問題は解決される。

なお、これまで述べた実施例による通信方式では、受信
側の受信バッファ容量を最初に送信側に知らせることに
しているが、これは装置規模が異なっても相互に通信で
きるようにするためである。従って、予め装置規模が定
められている場合には、バッファ容量を固定して第１図
（ａ）の通信を行わなくてもよい。このような場合にも
、受信バッファ能力を最大限に生かした効率のよいバッ
ファリングが可能である。

［発明の効果］ 以上述べたとおり、本発明によれば、送信側は画像デー
タの通信を行う前に受信側のバッファ容量を受信側と通
信して調べておき、この受信側のバッファ容量に応じて
１ブロツクのフレーム数を可変して送信する構成としで
あるので、受信装置あるいは送信装置の装置規模に応じ
て、最適な画像通信を行うことができる。すなわち、送
信機および受信機について何らバッファ容量の制約を受
けず、また画像データの圧縮率が変化してもオーバーフ
ロー等の問題は発生せず、バッファを適切に使用するこ
とができる。

【図面の簡単な説明】

第１図は本発明を適用した通信プロトコルを示す図、 第２図は第１図に示したプロトコルを実施するための画
像送受信装置の一例を示すブロック図、第３図は第、２
図に示した装置が送信機として機能するときにＲＡＭ上
に構成するバッファを示す図、第４図は第２図に示した
装置が受信機として機能するときにＲＡＭ上に構成する
バッファを示す図、第５図は本実施例に用いるフレーム
フォーマット（Ａ）に関して送信側が受信側に受信バッ
ファ容量を要求する制御情報フレームフォーマット（８
）と受信側が送信側に受信バッファ容量を返送するとき
の制御情報フレームフォーマット（Ｃ）　　と本通信プ
ロトコルにおいて送信側が受信側にエラーチエツクを要
求する際の制御情報フレームフォーマット（Ｄ）をそれ
ぞれ示す図、 第６図は受信バッファに生じる問題を説明するための図
、 第７図は）ＩＤＬｃフレームフォーマット（Ａ）　　と
本通信プロトコルで構成するＨＤＬＣフレームフォーマ
ット（Ｂ）　と画像データフレームフォーマット（Ｃ）
　　と制御情報フレームフォーマット（Ｄ）　　と送信
側が受信側にエラーチエツク結果を要求する制御情報フ
レームフォーマット（Ｅ）　　と受信側が送信側にエラ
ーチエツク結果を報告するときの制御情報フレームフォ
ーマットを示す図、 第８図は画像伝送を行う際のブロック番号とフレーム番
号の対応関係を示す図、 第９図は従来から知られている。画像通信プロトコルを
示す図である。 １・・・ホストＣＰＩＩ　。 ２・・・ＲＯＭ　　。 ３・・・ＲＡＭ　　。 ４・・・Ａ／Ｄ変換器、 ５・・・画像メモリ、 ６・・・シリアル１１０回路（パラレル／シリアル変換
を行うと共に、ＨＤＬＣのフレーミング／デフレーミン
グ機能をもつ）、 ７・・・Ｄ／＾変換器、 ８・・・モデム、 ９・・・マン・マシン・インターフェース回路、ｌＯ・
・・ＮＣＩＩ　。 送　イ官　局 受４局 第 図 第 図 第 図

Claims (1)

1. 【特許請求の範囲】 １）ディジタル画像データを圧縮して伝送する画像通信
   方式において、 送信局から受信局に対して受信バッファ容量の情報を要
   求し、 受信局は該要求に応じて自局のバッファ容量を送信局に
   応答し、 送信局は受信局から応答された前記受信バッファ容量に
   応じて画像圧縮データを受信局に伝送することを特徴と
   する画像通信方式。 ２）受信局側が自局の受信バッファ容量を送信局へ伝え
   る際に、実際のバッファ容量よりも小さなバッファ容量
   を送信局へ伝えることを特徴とした請求項第１項記載の
   画像通信方式。 ３）ディジタル画像データを圧縮して伝送する画像通信
   方式において、 送信局から受信局に対して受信バッファ容量の情報を要
   求し、 受信局は該要求に応じて自局のバッファ容量を送信局に
   応答し、 送信局は受信局から応答された前記受信バッファ容量に
   応じて画像圧縮データを受信局に伝送し、 受信局では受信した画像データのエラー検出を行い、必
   要に応じて画像データの再送要求を行うことを特徴とす
   る画像通信方式。