(57)【特許請求の範囲】
【請求項１】
自然画像に対して空間的相関及び時間的相関が相対的に高い動画像を、伝送路を介して画像再生装置側へ供給する画像データ供給装置であって、
前記画像再生装置において画像のスクロール再生をする場合には、フレーム間圧縮はせずにフレーム内圧縮を施した動画像を供給し、
前記画像再生装置において前記画像のスクロール再生をしない場合には、前記フレーム内圧縮はせずに、供給するフレームを間引きし、その間引きによる空き時間を利用して、前記非圧縮のフレームを分割して供給すること、
を特徴とする画像データ供給装置。
【請求項２】
請求項１記載の画像データ供給装置において、
前記フレーム内圧縮は、フレームを構成する画素を間引きすることによって実現すること、
を特徴とする画像データ供給装置。
【請求項３】
請求項２記載の画像データ供給装置において、
前記フレーム内圧縮は、フレームを構成する垂直方向及び水平方向のライン単位の画素を、所定ラインおきに間引きすることによって実現すること、
を特徴とする画像データ供給装置。
【請求項４】
請求項１〜３のいずれか記載の画像データ供給装置において、
前記自然画像に対して空間的相関及び時間的相関が相対的に高い動画像は、地図画像であること、
を特徴とする画像データ供給装置。
【請求項５】
自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して圧縮を施す圧縮手段を備え、その圧縮手段にて圧縮されたデータを、伝送路を介して所定のビットレートで画像再生装置側へ供給する画像データ供給装置であって、
前記圧縮手段は、
前記入力される原画像のフレームの内、一定間隔のフレーム毎に圧縮率の試算を行い、その試算値に基づいて前記所定のビットレートにするための圧縮率となるように調整し、前記試算のために用いたフレーム以降のフレームについては、前記調整された圧縮率にて圧縮を施して前記圧縮データとすると共に、前記試算のために用いたフレームについては圧縮は施さず、代わりに、直前のフレームについての圧縮データを援用すること、
を特徴とする画像データ供給装置。
【請求項６】
請求項５記載の画像データ供給装置において、
前記原画像はデジタル画像データであり、
前記圧縮手段は、
前記デジタル画像データに対して直交変換を施す直交変換手段と、
該直交変換手段から出力される直交変換データを所定の量子化ステップ値で割って変換符号化データとして出力する量子化手段と、
該量子化手段から出力された変換符号化データを可変長のコードに変換して出力する可変長符号化手段とを備えており、
前記圧縮率の調整は、前記量子化手段における量子化ステップ値を調整して行うこと、
を特徴とする画像データ供給装置。
【請求項７】
請求項１又は２記載の画像データ供給装置において、
前記自然画像に対して時間的相関が相対的に高い動画像は、地図画像であること、
を特徴とする画像データ供給装置。
【請求項８】
自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して圧縮を施す画像圧縮装置であって、
当該画像圧縮装置にて圧縮されたデータは、伝送路を介して所定のビットレートで画像再生装置側へ供給されることを前提とし、
前記入力される原画像のフレームの内、一定間隔のフレーム毎に圧縮率の試算を行い、その試算値に基づいて前記所定のビットレートにするための圧縮率となるように調整し、前記試算のために用いたフレーム以降のフレームについては、前記調整された圧縮率にて圧縮を施して前記圧縮データとすると共に、前記試算のために用いたフレームについては圧縮は施さず、代わりに、直前のフレームについての圧縮データを援用すること、
を特徴とする画像圧縮装置。
【請求項９】
自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して圧縮を施す圧縮手段を備え、その圧縮手段にて圧縮されたデータを、伝送路を介して所定のビットレートで画像再生装置側へ供給する画像データ供給装置であって、
前記圧縮手段は、
自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して一時的に蓄積しておく入力側フレームメモリと、
該入力側フレームメモリから取り出したフレーム単位の原画像に対して圧縮を施す圧縮部と、
該圧縮部にて圧縮されたデータをフレーム単位で入力して一時的に蓄積しておく出力側フレームメモリと、
前記入力側フレームメモリから前記圧縮手段へのフレーム入力タイミングまでに前記圧縮手段での圧縮処理が終了しないタイムオーバー状態が発生した場合には、前記入力側フレームメモリからのフレーム入力を一時的に中止させると共に、前記圧縮手段から前記出力側フレームメモリへの圧縮データの出力が再開されるまで、前記出力側フレームメモリに蓄積された直前の圧縮データを取り出して前記画像再生装置側へ供給させるフェールセーフ制御を実行する制御手段と、を備えたこと、
を特徴とする画像データ供給装置。
【請求項１０】
請求項９記載の画像データ供給装置において、
前記制御手段は、
前記入力側フレームメモリからのフレーム入力を一時的に中止させたフレーム数分だけ、前記出力側フレームメモリに蓄積された直前の圧縮データを取り出して前記画像再生装置側へ供給させること、
を特徴とする画像データ供給装置。
【請求項１１】
請求項９又は１０記載の画像データ供給装置において、
前記自然画像に対して時間的相関が相対的に高い動画像は、地図画像であること、
を特徴とする画像データ供給装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばナビゲーション用の地図画像などを、伝送路を介して画像再生装置側へ供給する画像データ供給装置に関し、特に、リアルタイム通信を行う際の技術に関する。
【０００２】
【従来の技術】
従来、例えば自動車等に搭載されて、ＧＰＳ（Global Positioning System ）等により検出された現在位置周辺の地図を自動的に表示したり、設定した目的地までの経路をガイドするカーナビゲーションシステムが知られている。このようなナビゲーションシステムにおいては、ナビゲーション装置が例えばＣＤ−ＲＯＭやＤＶＤなどの地図データ記録媒体から読み出した地図を表示装置側へ送り、表示装置にてその送られた地図を表示するのであるが、マルチメディア化に伴って、複数の画像ソース（画像データ供給装置）をデジタル通信路を介して複数のディスプレイと接続し、リアルタイムで動画像通信を行って画像表示するシステムへの移行が考えられる。
【０００３】
このような状況の中、デジタル通信路を用いてナビゲーション用の画像（特に地図画像、以下「ナピ画像」と略記する。）の圧縮データを伝送した例は無く、仮に実現するとしても、テレビ画像などの自然画像を圧縮するための方式であるＭｏｔｉｏｎ−ＪＰＥＧ，ＭＰＥＧなどを用いることになると推定される。
【０００４】
【発明が解決しようとする課題】
しかしながら、このナビ画像などの、自然画とは異なる性質を持つ画像に対しても、自然画像に対する汎用の圧縮方式を用いた場合には、以下に示すような種々の問題が生じる。
【０００５】
（１）一般的なナビ画像の特徴としては、道路、川や建物などの線情報及び地名などを示す文宇情報が多く、ほとんど静止画像に近い画像であることが挙げられる。それにもかかわらず、自然画像を対象とする汎用的な圧縮方式（上述のＭＰＥＧなど）を採用すると、その方式中に用いられるＤＣＴ（離散コサイン変換）の特徴から、圧縮率を上げていった場合に輪郭などの高周波成分が削られて線及び文字が見づらくなってしまう。また、これらの圧縮方式では、ナビの動作状態（通常走行時、スクロール時）に合わせて圧縮率を調整することが難しく、最も視認性を要する通常走行時においてもスクロール時と同等の画像劣化が生じる。さらには、画像データ供給側における圧縮回路及び画像再生装置側における伸張回路の大規模化や高コスト化につながるという問題もある。
（２）また、汎用的な圧縮方式を用いてビットレートを一定に制御する場合には、通常、フレーム単位で圧縮を行うのであるが、圧縮率を試算する前処理とその結果を基に実際に圧縮・符号化を行う後処理の２つの処理が必要になる。従って、一般的には、定ビットレート制御を行うためには同じ画像データ（フレーム）を２回入力する必要があり、１フレームを圧縮するのに２倍の時間がかかり、１フレーム分の遅れが生じていた。そして、そのような前提においてリアルタイム性を維持するためには秒間のフレーム数を２分の１に間引く必要があるため、圧縮手段の前段には入力された原画像のフレームを一時的に蓄積しておくフレームバッファが必要になるなど、回路の大規模化や高コスト化につながっていた。
【０００６】
なお、例えば特開平７−６６７８９号公報には、予め圧縮率の異なる複数の画像データを蓄積手段に蓄えておき、必要に応じて圧縮データを使い分けることで通信帯域を確保しているが、この手法では、圧縮手段及び蓄積手段などの大幅なコストアップにつながってしまう。
【０００７】
（３）また、画像を圧縮する場合には、復元画像の画質及び通信帯域の制約から１フレーム当たりの圧縮目標値及び圧縮手法を決定している。一般的にナビ画像は、道路、川や建物などの線情報と文字情報から成る単純な画像が多いが、例えば、交差点をより現実に近い状態で示すために、写真表示などが使用されることも考えられる。しかし、時間的な相関関係は高いままである。このような特徴を持つナピ画像に対して、画像の絵柄（単純か複雑か）に応じて圧縮アルゴリズムが変わらない場合、複雑な画像を圧縮する際には１フレームに要する処理時間が多くかかりタイムオーバ一が発生する。その結果、画像データの伝送遅れが生じ、絵柄の複雑な画像が連続すると遅れ時間が積み重なり、リアルタイム性が損なわれていた。
【０００８】
このように、自然画とは異なる性質を持つ画像に対しても自然画像に対する汎用の圧縮方式を用いた場合には種々の問題が生じるため、本発明は、そのような問題を解決し、自然画像に対して少なくとも時間的相関が相対的に高い動画像を伝送路を介して画像再生装置側へ供給する場合に、適切なデータ供給を実現できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
請求項１に記載の画像データ供給装置は、自然画像に対して空間的相関及び時間的相関が相対的に高い動画像を、伝送路を介して画像再生装置側へ供給することを前提とする。なお、この「自然画像に対して空間的相関及び時間的相関が相対的に高い動画像」としては、例えば請求項４に示すように、ナビゲーション装置などにおいて用いられる地図画像であることが考えられる。
【００１０】
そして、本画像データ供給装置は、画像再生装置において画像のスクロール再生をする場合には、フレーム間圧縮はせずにフレーム内圧縮を施した動画像を供給する。なお、画像のスクロール再生をする場合に行う「フレーム内圧縮」としては、例えば請求項２に示すように、フレームを構成する画素を間引きすることによって実現することが考えられる。この場合、請求項３に示すように、フレームを構成する垂直方向及び水平方向のライン単位の画素を、所定ラインおきに間引きすることが簡便に実現できて好ましい。例えば垂直方向及び水平方向の画像データをそれぞれ１ラインおきに間引きすれば、それだけで１フレーム当たりのデータ量が元の４分の１となる。
【００１１】
もちろん、画素の間引きによってフレーム内圧縮をする以外にも、フレーム内圧縮として汎用的な方法（ＤＣＴ、ランレングス、ハフマン符号化等）を用いても構わない。
一方、画像再生装置において前記画像のスクロール再生をしない場合には、フレーム内圧縮はせずに、供給するフレームを間引きし、その間引きによる空き時間を利用して、非圧縮のフレームを分割して供給する。例えば供給するフレームを４枚に１枚ずつ残し３枚を間引きすれば、全体として供給データ量を４分の１にできる。
【００１２】
このように、スクロール再生をしない場合には、画像劣化を防止する観点からフレーム内圧縮は行わない。その代わりに、供給するフレームを間引きし、その間引きによる空き時間を利用して、非圧縮のフレームを分割して供給するという一種のフレーム間圧縮を行っている。本画像データ供給装置が供給する動画像は、自然画像に対して時間的相関が相対的に高いものである。例えば上述したナビゲーション用に用いる地図画像を考えてみると、隣接するフレームはほとんど同一データであることが多い。したがって、間引きしても、人間の視覚特性（残像効果）のおかげで違和感が生じにくい。そのため、画像劣化を防止しながら伝送データ量を低減でき、結果として所定の通信帯域内での適切な伝送を実現できるのである。
【００１３】
一方、スクロール時にはフレーム間圧縮は行わないで本来のフレームレートを維持することにより、スムーズ感を確保している。そして、所定の通信帯域内での適切な伝送実現のための圧縮として、フレーム内圧縮を行う。上述したライン単位の画素の間引きなどを行うと多少の画像劣化は否めないが、本画像データ供給装置が供給する動画像は、自然画像に対して空間的相関が相対的に高いものである。また、スクロール再生しているため、人間の視覚特性（分解能）を鑑みれば違和感は少ない。
【００１４】
このように、本発明の画像データ供給装置によれば、スクロール再生の場合とそうでない場合とでは、再生画像の認識主体である利用者の視覚特性を考慮した場合の優先すべき点が異なることに着目し、スクロール再生時にはフレーム内圧縮、非スクロール再生時にはフレーム間圧縮によって伝送データ量を低減して、いずれの場合にも所定の通信帯域内での適切な伝送を実現している。これも、自然画像に対して空間的相関及び時間的相関が相対的に高い動画像を扱うことを前提としたためであり、上記着目点に基づく効果を発揮できるような動画像の種類を適切に認識したことにも本願発明のポイントがある。
【００１５】
また、請求項５に記載の画像データ供給装置は、自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して圧縮を施す圧縮手段を備え、その圧縮手段にて圧縮されたデータを、伝送路を介して所定のビットレートで画像再生装置側へ供給することを前提とする。なお、この「自然画像に対して時間的相関が相対的に高い動画像」としては、例えば請求項７に示すように、ナビゲーション装置などにおいて用いられる地図画像であることが考えられる。
【００１６】
ここで上述の圧縮手段は、入力される原画像のフレームの内、一定間隔のフレーム毎に圧縮率の試算を行い、その試算値に基づいて前記所定のビットレートにするための圧縮率となるように調整する。そして、試算のために用いたフレーム以降のフレームについては、調整された圧縮率にて圧縮を施して圧縮データとすると共に、試算のために用いたフレームについては圧縮は施さず、代わりに、直前のフレームについての圧縮データを援用することによって、所定のビットレートでの画像再生装置側への供給を実現する。
【００１７】
上述したように、従来は、定ビットレート制御を行うためには同じ画像データ（フレーム）を２回入力する必要があり、１フレームを圧縮するのに２倍の時間がかかり、１フレーム分の遅れが生じていた。そして、そのような前提においてリアルタイム性を維持するためには秒間のフレーム数を２分の１に間引く必要があるため、圧縮手段の前段には入力された原画像のフレームを一時的に蓄積しておくフレームバッファが必要になるなど、回路の大規模化や高コスト化につながっていた。
【００１８】
それに対して、本願発明の画像データ供給装置によれば、自然画像に比べて時間的（フレーム間）相関関係が高く、例えば静止画像に近いような画像を扱うことを前提とし、フレーム毎に圧縮率を計算するのではなく、ある一定間隔に圧縮率の試算を行い、その試算に用いたフレームは出力せず前フレームの圧縮データを出力するようにした。これにより、リアルタイム性を維持しながら、原画像のフレームを一時的に蓄積しておくフレームバッファは不要であり、回路の大規模化や高コスト化を防止できる。
【００１９】
なお、圧縮率の調整は種々の方法によって実現できるが、例えば請求項６に示すように、原画像がデジタル画像データであり、圧縮手段が、デジタル画像データに対して直交変換を施す直交変換手段と、その直交変換手段から出力される直交変換データを所定の量子化ステップ値で割って変換符号化データとして出力する量子化手段と、その量子化手段から出力された変換符号化データを可変長のコードに変換して出力する可変長符号化手段とを備える構成を前提とした場合においては、量子化手段における量子化ステップ値を調整して圧縮率の調整を行うことができる。
【００２０】
また、直交変換には、アダマール変換、フーリエ変換、ハール変換、ＫＬ変換など多くのものがあるが、動画圧縮の分野においては、直交変換のうちで最も効率のよいＫＬ変換に近い性能を持ち、しかもハード化しやすいＤＣＴ（離散コサイン変換）を用いることが一般的である。可変長符号化手段としては、変換符号化データをランレングス符号化によって圧縮し、さらに可変長コードに変換するものや、ハフマン符号化を用いたものなどが考えられる。
【００２１】
ところで、これまでは画像データ供給装置として実現した場合を説明したが、請求項８に示すように画像圧縮装置として単位で捉えることもできる。つまり、自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して圧縮を施す画像圧縮装置であり、その画像圧縮装置にて圧縮されたデータは、伝送路を介して所定のビットレートで画像再生装置側へ供給されることを前提とする。そして、入力される原画像のフレームの内、一定間隔のフレーム毎に圧縮率の試算を行い、その試算値に基づいて所定のビットレートにするための圧縮率となるように調整し、試算のために用いたフレーム以降のフレームについては、調整された圧縮率にて圧縮を施して圧縮データとすると共に、試算のために用いたフレームについては圧縮は施さず、代わりに、直前のフレームについての圧縮データを援用することを特徴とするものである。
【００２２】
この画像圧縮装置における作用・効果については上述した画像データ供給装置についての説明にて行っているので繰り返さない。
また、請求項９に記載の画像データ供給装置は、自然画像に対して時間的相関が相対的に高い動画像の原画像をフレーム単位で入力して一時的に蓄積しておく入力側フレームメモリと、入力側フレームメモリから取り出したフレーム単位の原画像に対して圧縮を施す圧縮手段と、圧縮手段にて圧縮されたデータをフレーム単位で入力して一時的に蓄積しておく出力側フレームメモリとを備え、出力側フレームメモリから取り出したフレーム単位の圧縮データを、伝送路を介して画像再生装置側へ供給することを前提とする。なお、この「自然画像に対して時間的相関が相対的に高い動画像」としては、例えば請求項１１に示すように、ナビゲーション装置などにおいて用いられる地図画像であることが考えられる。
【００２３】
そして、さらに、制御手段が次に示すフェールセーフ制御を実行する。すなわち、入力側フレームメモリから圧縮手段へのフレーム入力タイミングまでに圧縮手段での圧縮処理が終了しないタイムオーバー状態が発生した場合には、入力側フレームメモリからのフレーム入力を一時的に中止させると共に、圧縮手段から出力側フレームメモリへの圧縮データの出力が再開されるまで、出力側フレームメモリに蓄積された直前の圧縮データを取り出して画像再生装置側へ供給させるのである。
【００２４】
このフェールセーフ制御としては、例えば請求項１０に示すように、入力側フレームメモリからのフレーム入力を一時的に中止させたフレーム数分だけ、出力側フレームメモリに蓄積された直前の圧縮データを取り出して画像再生装置側へ供給させることが考えられる。
【００２５】
上述したように、従来の汎用的な圧縮方式を用いた場合、画像の絵柄（単純か複雑か）に応じては圧縮のアルゴリズムが変わらないため、複雑な画像を圧縮する場合には１フレームに要する処理時間が多くかかりタイムオーバ一が発生する。その結果、画像データの伝送遅れが生じ、絵柄の複雑な画像が連続すると遅れ時間が積み重なり、リアルタイム性が損なわれていた。
【００２６】
それに対して本発明の画像データ供給装置は、時間的（フレーム間）相関関係が高く、例えば静止画像に近いような画像を扱うことを前提としている。このような画像は、前後のフレームで画像がほとんど変わらないことに着目し、絵柄が複雑で圧縮処理に時間を要する場合には、一時的に画像入力を止め、その時間で圧縮処理を行い圧縮データを分割して出力する（フロー制御出力する）こととした。これにより、絵柄が複雑で圧縮処理に時間を要する場合にでも通信帯域を確保し、リアルタイムの動画像通信が可能になる。
【００２７】
なお、以上の説明において、自然画像に対して少なくとも時間的相関が相対的に高い動画像の具体例としてナビゲーション装置などで用いる地図画像を挙げているが、他の画像でも、同様の性質（つまり時間的相関が相対的に高い、あるいはさらに空間的相関も相対的に高いという性質）を持つ画像であれば、ナビ画像の場合と同様に採用できる。
【００２８】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り、種々の形態を採り得ることは言うまでもない。
【００２９】
図１は以下に示す各実施例が適用される画像データ伝送システムの概略構成を示すブロック図である。本システムは、車両に搭載されることを前提として構成されており、図１に示すように、ナビゲーション用電子制御装置（以下「ナビＥＣＵ」と称す。）、ＣＣＤカメラ、ＴＶチューナをそれぞれソースコンテンツとし、圧縮手段及び通信手段を備える複数の画像データ供給装置１０，２０，３０と、通信手段、伸張手段及び画像表示手段をそれぞれ備える複数の画像再生装置５０，６０とが、多重通信可能な通信バス４０を介して接続されている。
【００３０】
ナビＥＣＵは、図示しない位置検出器、地図データ入力器などが接続され、これらからのデータを入力する。位置検出器は、いずれも周知のジャイロスコープ、距離センサ、及び衛星からの電波に基づいて車両の位置を検出するＧＰＳ（Global Positioning System ）のためのＧＰＳ受信機を有している。これらのセンサ等は各々が性質の異なる誤差を持っているため、複数のセンサにより、各々補間しながら使用するように構成されている。なお、精度によっては上述した内の一部で構成してもよく、更に、ステアリングの回転センサ、各転動輪の車輪センサ等を用いてもよい。地図データ入力器は、位置検出の精度向上のためのいわゆるマップマッチング用データ、地図データ及び目印データを含む各種データを入力するための装置である。媒体としては、そのデータ量からＣＤ−ＲＯＭやＤＶＤを用いるのが一般的である。
【００３１】
ＣＣＤカメラは、車両後方の監視用に設けてあり、車両後進時に後方の映像を取り込み、車室内の画像表示手段に映し出す。
ＴＶチューナは、図示しない受信アンテナを介してＴＶ放送を選択受信する。画像表示手段は、制御を司るディスプレイＥＣＵとＬＣＤモニタとを備えている。ＬＣＤモニタはカラー表示が可能であり、その画面には、ナビＥＣＵをソースコンテンツとする画像データ供給装置１０から供給された画像データによるナビ画面や、ＣＣＤカメラをソースコンテンツとする画像データ供給装置２０から供給された画像データによる撮像画面、あるいはＴＶチューナをソースコンテンツとする画像データ供給装置３０から供給された画像データによるＴＶ画面などを表示できる。この場合、これらインターネット画面、ナビ画面、ＴＶ画面などの複数の画像ソースからの画像データによる画面の内の、利用者が選択したいずれか１つの画面を切り替え表示することもできるし、複数画面を同時に表示（マルチウインドウ表示）することもできる。
【００３２】
なお、表示させる画面の選択は、例えばメニュー画面を表示させた状態で、その画面上の所望の入力項目を利用者がタッチすればタッチスイッチによってそれが検知され、ディスプレイＥＣＵにて所定の対応処理が実行される。また、図示しないリモコンを操作することによって選択できるように構成してもよい。ナビＥＣＵをソースコンテンツとする画像データ供給装置１０から供給されたナビゲーション用の画像（主に地図画像）については、利用者からのスクロール指示がなされるとスクロール再生がなされるようになっている。
【００３３】
以下、このようなシステムに用いられることを前提とした画像データ供給装置の実施例について説明する。なお、本発明の適用されるのは、このシステムではナビＥＣＵをソースコンテンツとする画像データ供給装置１０である。
［第１実施例］
ナビＥＣＵをソースコンテンツとする画像データ供給装置１０は、基本的には秒間６０フレームでナビ画像を画像再生装置５０，６０側へ供給する。このナビ画像は、主に地図画像であり、フレーム間（時間的）相関が高いため、隣接するフレームはほとんど同一データである。また、１秒間のデータ数はフレームサイズによっても異なるが、仮に画像再生装置５０，６０側の画像表示手段が６４０ドット×４８０ドットのＶＧＡモニタであり、ＲＧＢデータが各８ビットの出力であるとすると、４４２Ｍビット／秒にも及ぶ。この膨大なデー夕は最近のＩＥＥＥ１３９４（帯域が約２００Ｍビット／秒）などの高速通信バスを用いても帯域不足が生じ、何らかの圧縮処理が必要不可欠となる。
【００３４】
そこで、本第１実施例の場合の画像データ供給装置１０においては、以下に示すような圧縮処理を実行する。なお、ここでは、原画像データを４分の１に圧縮する場合を例にとって説明している。図２は本第１実施例の特徴を示す概念図であり、図４は制御概要を表したフローチャートである。
【００３５】
図２（ａ）は、通常走行時における画像データの処理方法を示している。ここでいう「通常走行時」においては、地図を表示したナビ画像は静止している状態が多い。つまり、車両の走行に応じて地図上の自車位置は移動して行くが、その移動は急激でないため、一定時間毎に地図をスクロールすれば足りる。したがって、その地図を見る人間にとっては静止状態のナビ画像を認識する機会が多いため、それに応じた圧縮を行う。
【００３６】
まず、人間の視覚特性（残像効果）を利用して、連続するフレームを３枚置きに間引き、秒間フレーム数を１５フレームにすることで全データ量を単純に４分の１に減らす。次に、間引いた３フレーム分の空き時間を利用して、６０分の４秒間で１フレーム分のデータを分割してそのまま無処理（フロー制御）で伝送する。これにより、平滑化された約１００Ｍビット／秒のデータ量に抑えることができ、画像再生装置５０，６０の伸張手段においては、非圧縮（可逆性）データであるため鮮明に原面像が復元できる。なお、フレームを間引く目安としては、間引いた後が１５フレーム／秒以上となる程度が、違和感の少ない範囲であると考える。
【００３７】
次に、図２（ｂ）にスクロール時における画像データの処理方法を示す。ここでいう「スクロール時」とは、利用者が地図を表示させたい場所を任意に移動させるために所定のスクロール操作を行った場合を指す。このスクロール速度としては約４００ドット／秒程度を想定している。もちろん、画像データ供給装置１０側の処理能力にも関係するが、一般的に、実際の車両が移動する速度よりははるかに速い。そのため、スクロール時は画像のスムーズ感を損なわないように本来のフレームレート（６０フレーム／秒）の画像伝送を行う。その上で、通信帯域を確保するために、人間の視覚特性（分解能）を利用し、水平方向のデータ及び垂直方向のデータをそれぞれ１ラインおきに間引く。
【００３８】
これによって１フレーム当たりのデータ量が４分の１になり、約１００Ｍビット／秒のデータ量に抑えることができる。但し、図２（ａ）の場合の通常走行時と比べると多少の画像劣化は否めないが、スクロール速度（約４００ドット／秒）を考慮すると可逆性は必要ない。つまり、人間の視覚による分解能では、この約４００ドット／秒のスクロール速度で画像を再生させた場合、画像自体の劣化を細部まで認識することはできないため、あまり気にならなくなるからである。
【００３９】
なお、ライン間引きの目安としては水平方向、垂直方向のデータ共に、２分の１までが違和感の少ない範囲と考える。また、ここではライン間引き処理以外にも汎用的な圧縮方法（ＤＣＴ、ランレングス、ハフマン符号化等）を用いても構わない。
【００４０】
この場合の圧縮処理について、図４のフローチャートを参照して説明する。
本処理が開始されると、まず各種初期設定をし（Ｓ１１０）、その後、スクロール信号がＯＮされたか否かを判断する（Ｓ１２０）。これは、上述したように例えば図示しないリモコンが利用者によって操作され、スクロール指示がなされたか否かで判断する。
【００４１】
そして、スクロール信号がＯＮであれば（Ｓ１２０：ＹＥＳ）、フレーム間圧縮はせずに、本来のフレームレート（６０フレーム／秒）で画像伝送を行う設定にし（Ｓ１３０）、その上で、上述した水平方向のデータ及び垂直方向のデータをそれぞれ１ラインおきに間引いたフレームデータを出力する「簡易圧縮出力処理」を行う。
【００４２】
一方、スクロール信号がＯＮでなければ（Ｓ１２０：ＮＯ）、連続するフレームを３枚置きに間引き、秒間フレーム数を１５フレームにするフレーム内圧縮を施す（Ｓ１４０）。そして、間引いた３フレーム分の空き時間を利用して、６０分の４秒間で１フレーム分のデータを分割してそのまま無処理（フロー制御）で出力する（Ｓ１６０）。
【００４３】
Ｓ１４０あるいはＳ１６０の処理後はＳ１７０へ移行して、画像データの供給自体が終了したか否か判断し、終了していなければ（Ｓ１７０：ＮＯ）、Ｓ１２０へ戻る。
このように、本第１実施例の画像データ供給装置１０によれば、画像再生装置５０，６０において画像のスクロール再生をする場合には（Ｓ１２０：ＹＥＳ）、フレーム間圧縮はせずに（Ｓ１３０）、フレーム内圧縮（Ｓ１４０）を施した動画像を供給する。これにより、スクロール時には本来のフレームレートを維持することでスムーズ感を確保できる。
【００４４】
一方、スクロール再生をしない場合には（Ｓ１２０：ＮＯ）、フレーム内圧縮はせずに、供給するフレームを間引きし（Ｓ１５０）、その間引きによる空き時間を利用して、非圧縮のフレームを分割して供給する（Ｓ１６０）。供給する対象であるナビ画像は自然画像に対して時間的相関が相対的に高く、間引きしても、人間の視覚特性（残像効果）のおかげで違和感が生じにくい。そのため、画像劣化を防止しながら伝送データ量を低減でき、結果として所定の通信帯域内での適切な伝送を実現できる。
【００４５】
このように、本発明の画像データ供給装置によれば、スクロール再生の場合とそうでない場合とでは、再生画像の認識主体である利用者の視覚特性を考慮した場合の優先すべき点が異なることに着目し、スクロール再生時にはフレーム内圧縮、非スクロール再生時にはフレーム間圧縮によって伝送データ量を低減して、いずれの場合にも元の４分の１のデータ量にて画像データの供給を行うことができる。
【００４６】
なお、比較のため、テレビなどの自然画像を圧縮するためのＭｏｔｌｏｎ−ＪＰＥＧ、ＭＰＥＧなど汎用的な圧縮方法を採用した場合について図３に示した。この場合、通常走行時及びスクロール時共に安定して４分の１の圧縮が可能にはなるが、伝送するデータが全て非可逆圧縮となるため、圧縮率を上げていくと輪郭などの高周波成分が削られ、通常走行時に文字や線が見づらくなる。これに対して本実施例の場合には、図２（ａ）に示すようにフレームデータ自体は非圧縮の状態で伝送されるため、画像劣化がなく、文字や線が見づらくなることも生じない。
【００４７】
［第２実施例］
ナビＥＣＵをソースコンテンツとする画像データ供給装置１０は、基本的には秒間６０フレームでナビ画像を画像再生装置５０，６０側へ供給する。画像を圧縮する場合には、復元画像の画質及び通信帯域の制約から１フレーム当たりの圧縮目標値及び圧縮手法を決定する。しかし、最近のナビ画像は、主に線と文字だけで構成される比較的単純な画像だけでなく、例えば交差点拡大図などにおいては、３次元立体表示且つバックカラーにグラデーションがつくなど一部複雑な画像がある。そのため、通信帯域を一定にするためには圧縮率を調整してビットレートを制御（ＢＲＣ）する必要がある。
【００４８】
そこで、本第２実施例の場合の画像データ供給装置１０においては、以下に示すような圧縮手段を備えることを特徴とする。
図５（ａ）は、本第２実施例の圧縮手段のシステムブロック図であり、圧縮符号化部１１と、圧縮強度調整・メモリコントロール部１２と、フレームメモリ１３とを備えている。
【００４９】
圧縮符号化部１１は、取り込んだ画像データ（デジタルＲＧＢデータ）を圧縮し、さらに符号化するものであり、ここではＤＣＴ（離散コサイン変換）とハフマン符号化を組み合わせた圧縮アルゴリズムを持つ汎用ＩＣを想定している。そして、圧縮強度を調整可能とされている。本実施例では、デジタル画像データに対してＤＣＴを施し、そのＤＣＴ後のデータを所定の量子化ステップ値で割って変換符号化データとし、その変換符号化データをハフマン符号化によって可変長コードに変換して出力する構成となっている。そのため、量子化ステップ値（Ｑ値）を調整することにより、圧縮率の調整、すなわち圧縮強度の調整を行うことができる。
【００５０】
なお、ＤＣＴの代わりに、アダマール変換、フーリエ変換、ハール変換、ＫＬ変換などの直交変換を採用しても良いが、ここでは、動画圧縮の分野においては、直交変換のうちで最も効率のよいＫＬ変換に近い性能を持ち、しかもハード化しやすいＤＣＴを用いることとした。
【００５１】
また、フレームメモリ１３は、圧縮符号化部１１からのデータ出力速度と通信手段へのデータ入力速度の差を吸収するためのバッファメモリであり、ＦＩＦ０（First In First Out）構造になっていて数フレーム分の容量がある。以下の説明では、圧縮データの書き込みと圧縮データの読み出し（伝送データの出力）の間には１フレーム分の遅れがあるものとする。
【００５２】
そして、圧縮強度調整・メモリコントロール部１２は、圧縮符号化部１１から得た圧縮試算値を基に圧縮強度を調整し、上述したビットレートの制御を行う。またフレームメモリ１３の入出力タイミングも制御する。
図５（ｂ）には、このような構成の本第２実施例の圧縮手段によって実行されるビットレート制御（ＢＲＣ）の概念を示した。
【００５３】
基本的にはナビＥＣＵからの画像データ（ＲＧＢ）をフレーム毎に圧縮・符号化し、通信手段へ出力するが、ある一定間隔（この例では４フレーム毎）に圧縮後のデータ量を試算して圧縮率の適否をチェックする。このチェック間隔は最短の場合で１フレームおきに行うが、一般的なナビ画像を考えた場合には、数十フレームに１回程度行えば十分である。
【００５４】
このチェックの結果、試算した圧縮後のデータ量が目標データ量から外れている場合には、圧縮強度調整（Ｑ値調整）を行う。上述したように、量子化ステップ値（Ｑ値）は、ＤＣＴを施したデータを量子化する際のレベルを決めるパラメータであり、Ｑ値を大きくすると高圧縮になり、逆に小さくすると低圧縮になる。但し、この圧縮率チェックと圧縮・符号化は同時にできないため、チェック中の出力（データ伝送）は、フレームメモリ１３内に格納されている前フレームの圧縮データを出力することで対応する。
【００５５】
この場合のＢＲＣ処理について、図７のフローチャートを参照して説明する。本処理が開始されると、まず各種初期設定をする（Ｓ２１０）。この初期設定において、圧縮符号化部１１における圧縮率も初期設定される。具体的には、量子化ステップ値（Ｑ値）のデフォルト値が設定される。
【００５６】
その後、目標データ量を設定する（Ｓ２２０）。この目標データ量とは、フレームを圧縮した後のデータ量として目標とすべき値をいう。同じ圧縮率であれば、画像の内容によって圧縮後のデータ量が異なり、ビットレートを一定に保つことができない。したがって、圧縮後のデータ量が大きくなりすぎないように、例えば複雑な画像の場合には圧縮率を上げ、ビットレートを一定にしようとするのである。
【００５７】
Ｓ２３０では、ナビＥＣＵの方から画像データ（ＲＧＢ）を入力する。そして、その入力された画像が４ｎ（ｎ＝０，１，２…）フレーム目であるか否かを判断する（Ｓ２４０）、画像データが４ｎフレーム目でなければ（Ｓ２４０：ＮＯ）、圧縮符号化部１１にてフレームデータを圧縮してフレームメモリ１３へ出力し（Ｓ２５０）、フレームメモリ１３から伝送データを通信手段へ出力する（Ｓ２６０）。１フレーム分のデータについてＳ２５０，Ｓ２６０の処理が終了したら（Ｓ２７０：ＹＥＳ）、Ｓ３２０へ移行する。Ｓ３２０では、画像データの供給処理自体が終了か否かを判断し、終了していなければ（Ｓ３２０：ＮＯ）、Ｓ２３０へ戻る。
【００５８】
一方、入力した画像データが４ｎフレーム目であれば（Ｓ２４０：ＹＥＳ）、圧縮符号化部１１にてそのフレームデータを圧縮し、圧縮後のデータ量を計算する（Ｓ２８０）。このデータ量の計算は、１フレームを例えば８画素×８画素といったブロック単位で実行されるため、１フレーム分の計算が完了したら（Ｓ２９０）、Ｓ３００へ移行して圧縮強度を調整する。つまり、１フレームを圧縮した場合のデータ量（圧縮試算値）と、Ｓ２２０にて設定した目標データ量と比較し、圧縮試算値が目標データ量と一致しない場合には、現在の圧縮率では圧縮強度が適切ではないので、目標データ量になるような圧縮強度を実現できる量子化ステップ値（Ｑ値）に調整する。もちろん、圧縮試算値が目標データ量と完全一致することを期待するのではなく、誤差が所定範囲内であれば十分である。
【００５９】
そして、Ｓ３００での圧縮強度の調整が済んだ後は、Ｓ３１０へ移行し、前フレームの伝送データを、フレームメモリ１３から通信手段へ再度出力する。これは、上述したように、Ｓ２８０〜Ｓ３００での圧縮率チェックに係る一連の処理と、Ｓ２５０に示すような圧縮・符号化処理は同時にできないため、フレームメモリ１３内に格納されている前フレームの圧縮データを出力することで対応するためである。Ｓ３１０の処理後はＳ３２０へ移行する。
したがって、例えば４フレーム目で圧縮強度を調整した場合には、５，６，７フレームはその調整された圧縮強度での圧縮が施される。同様に、８フレーム目で圧縮強度を調整した場合には、９，１０，１１フレームはその調整された圧縮強度での圧縮が施される。ナビ画像は自然画像に比べて時間的（フレーム間）相関関係が高いため、同じような画像が連続する可能性が高い。そのため圧縮強度の調整が４フレーム毎であっても、全てのフレームについてほぼ適切な圧縮が実現される。
【００６０】
なお、必ず４ｎフレーム毎に圧縮強度の調整機会が与えられているが、実質的な調整が毎回なされるとは限らない。つまり、Ｓ２８０での試算値がＳ２２０での目標データ量と一致（所定範囲内の誤差という場合も含む）している場合には、実質的な調整は実行されない。また、本実施例では圧縮後のデータ量の試算を４ｎフレーム毎に行うこととしたが、これに限定されず、それよりも長い（あるいは短い）間隔で行っても良い。
【００６１】
このように、本第２実施例の場合の圧縮手段は、入力される原画像のフレームの内、一定間隔のフレーム毎に圧縮率の試算を行い、その試算値に基づき、圧縮後のデータ量が目標データ量になるような圧縮率に調整することによって所定のビットレートでのデータ伝送が可能となる。そして、試算のために用いたフレーム以降のフレームについては、その調整された圧縮率にて圧縮を施して圧縮データとすると共に、試算のために用いたフレームについては圧縮は施さず、代わりに、直前のフレームについての圧縮データを援用することによって、所定のビットレートでの画像再生装置側への供給を実現する。
【００６２】
ここで、比較のため従来構成の場合のシステムブロック図を図６（ａ）に、その構成の場合のビットレート制御の概念図を図６（ｂ）に示す。この場合は、圧縮符号化部１１１の前段にフレームメモリＡ１１３を持ち、そのフレームメモリＡ１１３に貯えた画像データから圧縮符号化部１１１が同じフレームデータを２回入力することで、圧縮率の計算とその結果を基に圧縮データを生成するようにしていた。そのため、１フレームを圧縮するのに２倍の時間がかかる。また、リアルタイム性を維持するためには、フレームメモリに１フレームおきのデータを入力する必要である。そのため、さらにフレームメモリＡ１１３において、フレームを間引くための構成が必要になってくる。
【００６３】
すなわち、図６（ｂ）に示すように、ナビＥＣＵから取り込んだ画像データ１に対して、まず１フレームおきに間引く。そして、同じフレームについて圧縮データ量の計算と、その計算に基づいて調整された圧縮率による実際の圧縮符号化を行う。また、圧縮符号化部１１１から後段のフレームメモリＢ１１４へは１フレームおきにしか圧縮データが出力されないので、毎回、同じ圧縮データを２度続けて伝送データとすることとなる。このように、従来構成においてはリアルタイム性を維持するためには、圧縮符号化部１１１の前段に、入力された原画像のフレームを間引き且つ一時的に蓄積するフレームメモリＡ１１３が必要になるなど、回路の大規模化や高コスト化につながっていた。
【００６４】
それに対して、本第２実施例の画像データ供給装置によれば、自然画像に比べて時間的（フレーム間）相関関係が高く、例えば静止画像に近いようなナビ画像を扱うことを前提とし、フレーム毎に圧縮率を計算するのではなく、ある一定間隔に圧縮率の試算を行い、その試算に用いたフレームは出力せず前フレームの圧縮データを出力するようにした。これにより、リアルタイム性を維持しながら、原画像のフレームを一時的に蓄積しておくフレームバッファは不要であり、回路の大規模化や高コスト化を防止できることとなった。
【００６５】
［第３実施例］
ナビＥＣＵをソースコンテンツとする画像データ供給装置１０は、基本的には秒間６０フレームでナビ画像を画像再生装置５０，６０側へ供給する。画像を圧縮する場合には、復元画像の画質及び通信帯域の制約から１フレーム当たりの圧縮目標値及び圧縮手法を決定している。一般的にナビ画像は、道路、川や建物などの線情報と文字情報から成る単純な画像が多いが、例えば、交差点をより現実に近い状態で示すために、写真表示などが使用されることも考えられる。しかし、時間的な相関関係は高いままである。このような特徴を持つナピ画像に対して、画像の絵柄（単純か複雑か）に応じて圧縮アルゴリズムが変わらない場合、複雑な画像を圧縮する際には１フレームに要する処理時間が多くかかり、タイムオーバ一が発生する。その結果、画像データの伝送遅れが生じ、絵柄の複雑な画像が連続すると遅れ時間が積み重なり、リアルタイム性が損なわれてしまう。
【００６６】
そこで、本第３実施例の画像データ供給装置は、このようなタイムオーバーが生じた場合にリアルタイム性が損なわれることを防止するため、フェールセーフ機能を持つ圧縮手段を採用した。
図８（ａ）は、本第３実施例の圧縮手段のシステムブロック図であり、圧縮符号化部２１と、タイムオーバー判断・メモリコントロール部２２と、フレームメモリＡ２３と、フレームメモリＢ２４とを備えている。
【００６７】
フレームメモリＡ２３は、ナビＥＣＵが画像データを出力する速度と圧縮符号化部２１が画像データを入力する速度の差を吸収するためのメモリであり、「入力側フレームメモリ」に相当する。
圧縮符号化部２１は、取り込んだ画像データ（デジタルＲＧＢデータ）を圧縮し、さらに符号化するものであり、上述したダイ２実施例と同様に、ＤＣＴとハフマン符号化を組み合わせた圧縮アルゴリズムを持つ汎用ＩＣを想定している。
【００６８】
また、フレームメモリＢ２４は、圧縮符号化部２１からのデータ出力速度と通信手段へのデータ入力速度の差を吸収するためのバッファメモリであり、「出力側フレームメモリ」に相当する。
なお、フレームメモリＡ２３及びフレームメモリＢ２４は、それぞれＦＩＦ０（First In First Out）構造になっていて数フレーム分の容量がある。以下の説明では、データの書き込みとデータの読み出しの間には１フレーム分の遅れがあるものとする。
【００６９】
そして、タイムオーバー判断・メモリコントロール部２２は、圧縮符号化部２１から１フレーム毎の圧縮完了信号であるＥＮＤ信号を得ると共に、ナビＥＣＵ側より垂直同期信号Ｖsync及び水平同期信号Ｈsyncを取得する。そしてタイムオーバーを判断すると共に、フレームメモリＡ２３及びフレームメモリＢ２４のデータ入出力タイミングを制御する。
【００７０】
図８（ｂ）には、このような構成の本第３実施例の圧縮手段が発揮するフェールセーフ機能の概念を示した。
図８（ｂ）中の「画像データ」とは、フレームメモリＡ２３へ入力されるデータを指し、「非圧縮データ」とは、フレームメモリＡ２３から圧縮符号化部２１へ出力されるデータを指す。これらのデータ間には上述したように１フレーム分のディレイ（遅れ）が生じている。また、「圧縮データ」とは、圧縮符号化部２１からフレームメモリＢ２４へ出力されるデータを指し、「伝送データ」とは、フレームメモリＢ２４から通信手段へ出力されるデータを指す。これらのデータ間にも上述したように１フレーム分のディレイ（遅れ）が生じている。
【００７１】
このような前提において、現在圧縮中のフレームが（ｎ−５）であったとする。この（ｎ−５）のデータに対する圧縮処理が完了しない内（つまり非圧縮データ（ｎ−５）として残っている内）に、画像データとして次のフレーム（ｎ−４）が入力される、タイムオーバーとなる。このタイムオーバーの判断は、タイムオーバー判断・メモリコントロール部２２に圧縮符号化部２１から入力されるＥＮＤ信号がアクティブになる前に、垂直同期信号Ｖsyncが入力されることで判断できる。
【００７２】
そして、タイムオーバ−となった場合、タイムオーバー判断・メモリコントロール部２２は、フレームメモリＡ２３への（ナビＥＣＵからの）画像データ入力をフレーム単位で止め、現在処理中のフレーム（ｎ−５）の圧縮処理が全て完了した時点で新しい画像データ（ｎ−１）入力を再開する。つまり、この場合は、画像データ（ｎ−３），（ｎ−２）の２フレームの入力が停止される。この入力停止に対処するため、フレームメモリＢ２４からの出力としては、前回と同じデータ（ｎ−６’）を、入力停止分の２フレームだけ出力する。なお、このように間引きすることで入力を停止するフレーム数は、人間の視覚特性（残像効果）を考慮して数フレーム（フレーム間隔としては数十ミリ秒程度）までとすることが好ましい。
【００７３】
この場合のフェールセーフに係る処理について、図１０のフローチャートを参照して説明する。
本処理が開始されると、まず各種初期設定をする（Ｓ４１０）。そして、ナビＥＣＵの方から画像データ（ＲＧＢ）をフレームメモリＡ２３へ入力し（Ｓ４２０）、続けて、フレームメモリＡ２３から圧縮符号化部２１へフレーム非圧縮データを入力する（４３０）。上述したようにこの「画像データ」と「非圧縮データ」との間には、通常１フレーム分のディレイ（遅れ）が生じている。
【００７４】
次に、圧縮符号化部２１においてフレームデータの圧縮及びフレームメモリＢ２４への出力を行う（Ｓ４４０）。このフレームデータの圧縮及び出力処理を実行している最中に、タイムオーバーが発生したか否かを判断する（Ｓ４５０）。上述したように、１フレーム分の圧縮が完了すると、圧縮符号化部２１からＥＮＮＤ信号がタイムオーバー判断・メモリコントロール部２２へ出力される。したがって、垂直同期信号Ｖsyncが入力される前にＥＮＤ信号がアクティブになっていればタイムオーバーは発生しておらず（Ｓ４５０：ＮＯ）、フレームメモリＢ２４から伝送データを出力する（Ｓ４６０）。
【００７５】
一方、ＥＮＤ信号がアクティブになる前に、垂直同期信号Ｖsyncが入力された場合には、タイムオーバーが発生しているので（Ｓ４５０：ＹＥＳ）、この場合は、フレームメモリＢ２４から前フレームの伝送データを再度出力する（Ｓ４７０）。
【００７６】
Ｓ４６０あるいはＳ４７０の処理後に移行するＳ４８０では圧縮が完了したかどうかを判断し、圧縮が完了しない間は（Ｓ４８０：ＮＯ）、Ｓ４３０へ戻ってフレームメモリＡ２３から圧縮符号化部２１へフレーム非圧縮データを入力し、Ｓ４４０以降の処理を繰り返す。そして、圧縮が完了すると（４８０：ＹＥＳ）、Ｓ４９０へ移行し、画像データの供給処理自体が終了か否かを判断し、終了していなければ（Ｓ４９０：ＮＯ）、Ｓ４２０へ戻る。
【００７７】
このように、本第３実施例の場合の圧縮手段は、フレームメモリＡ２３から圧縮符号化部２１へのフレーム入力タイミングまでに圧縮符号化部２１での圧縮処理が終了しないタイムオーバー状態が発生した場合には、フレームメモリＡ２３からのフレーム入力を一時的に中止させると共に、圧縮符号化部２１からフレームメモリＢ２４への圧縮データの出力が再開されるまで、フレームメモリＢ２４に蓄積された直前の圧縮データを取り出して、伝送データとして出力する。
【００７８】
ここで、比較のため、従来のフェールセーフ機能がない場合の制御概念図を図９に示す。
この場合は、画像の絵柄（単純か複雑か）に合わせて圧縮アルゴリズムが変わらないため、画像データ（ｎ−４）を入力した時点で前の圧縮処理が終了していないタイムオーバーが発生すると、その後に入力される画像データ（ｎ−３）及び（ｎ−２）がフレームメモリＡ２３にたまってしまう。それと共に、フレームメモリ２４から出力する圧縮データが無くなるため、伝送データは通常の場合に比べて２フレーム分だけ「出力データ無し」状態となる。よって、画像データの伝送遅れが生じ、このような絵柄の複雑な画像が連続すると遅れ時間が積み重なって、リアルタイム性が損なわれてしまう。
【００７９】
それに対して本第３実施例の画像データ供給装置によれば、自然画像に比べて時間的（フレーム間）相関関係が高く、例えば静止画像に近いようなナビ画像を扱うことを前提としている。このような画像では、前後のフレームで画像がほとんど変わらないことに着目し、絵柄が複雑で圧縮処理に時間を要する場合には、一時的に画像入力を止め、その時間で圧縮処理を行い圧縮データを分割して出力する（フロー制御出力する）こととした。これにより、絵柄が複雑で圧縮処理に時間を要する場合にでも通信帯域を確保し、リアルタイムの動画像通信が可能になる。
【００８０】
［その他］
上記各実施例では、車載用のシステムとして実現したが、例えば街頭やパーキングエリアなどに設置されて道案内などをするための情報端末装置などにも同様に適用できる。同様に上記各実施例では、扱う画像をナビ画像とした例を説明したが、ナビ画像は、自然画像に対して時間的相関が相対的に高い画像、あるいはさらに空間的相関も高い画像としての一具体例であり、同様の性質を持つ画像であれば適用可能である。
【００８１】
また、上記実施例の前提として、図１において複数の画像データ供給装置１０，２０，３０と、複数の画像再生装置５０，６０とが、多重通信可能な通信バス４０を介して接続されているシステムを例示した。これは、多重通信にてデータ伝送する際に通信帯域の確保（調整）が重要な問題となるため、本発明の効果がより顕著になると考えられる。但し、多重通信でなくても、データ伝送の際に通信帯域の確保（調整）を考える必要はあるため、必ずしも図１のようなシステムにて適用しなければならないわけではないことを言及しておく。
【図面の簡単な説明】
【図１】  本発明の各実施例の前提となる画像データ伝送システムの概略構成を示すブロック図である。
【図２】  第１実施例の特徴を示す概念図である。
【図３】  従来の制御概要を表した概念図である。
【図４】  画像データ供給装置側にて実行される処理を示すフローチャートである。
【図５】  （ａ）は第２実施例の圧縮手段のシステムブロック図であり、（ｂ）はこの圧縮手段にて実行されるビットレート制御の概念図である。
【図６】  （ａ）は従来の圧縮手段のシステムブロック図であり、（ｂ）は従来の圧縮手段にて実行されるビットレート制御の概念図である。
【図７】  第２実施例の圧縮手段にて実行されるビットレート制御に係る処理を示すフローチャートである。
【図８】  （ａ）は第３実施例の圧縮手段のシステムブロック図であり、（ｂ）はこの圧縮手段にて実行されるフェールセーフの概念図である。
【図９】  従来のフェールセーフ無しの場合の概念図である。
【図１０】  第３実施例の圧縮手段にて実行されるフェールセーフに係る処理を示すフローチャートである。
【符号の説明】
１０，２０，３０…画像データ供給装置
１１，２１，１１１…圧縮符号化部
１２，１１２…圧縮強度調整・メモリコントロール部
１３…フレームメモリ
２２…タイムオーバー判断・メモリコントロール部
２３，１１３…フレームメモリＡ
２４，１１４…フレームメモリＢ
４０…通信バス
５０，６０…画像再生装置
【図１】
0004086994.tif 000002
【図２】
0004086994.tif 000003
【図３】
0004086994.tif 000004
【図４】
0004086994.tif 000005
【図５】
0004086994.tif 000006
【図６】
0004086994.tif 000007
【図７】
0004086994.tif 000008
【図８】
0004086994.tif 000009
【図９】
0004086994.tif 000010
【図１０】
0004086994.tif 000011