(57)【要約】【課題】  画像データを処理するデバイスが、それぞれで画像データの操作を行うソフトモジュール、ハードデバイスを呼び出し、設定を行って処理を依頼するシステム構成となっていたため、画像データの操作を行うソフトモジュールやハードデバイスに変更や入れ替えがあった場合、それに伴って画像データを処理するプリンタやスキャナなどの依頼元のデバイスがそれぞれに変更点のあったソフトモジュール、ハードデバイスに関する変更を行わなければならなかった。【解決手段】  プリンタ部や、スキャナ部など、画像処理を依頼するデバイスが、画像符号データに対する符号化、復号化、拡大、縮小、回転等の画像処理ソフトモジュール、ハードデバイスを併用して処理する際に、インターフェイスモジュールを必ず通過させる。【選択図】  図１
2005217683.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークとのデータの送受信を行うことのできるネットワーク通信制御部と、
電話回線を用いてファクシミリ通信によって画像の送受信を行うファクシミリ通信制御部と、
原稿を読み取り、画像データに変換できる、読み取り部と、
画像データを出力できる記録部と、
機器本体から取り外し、持ち運びが可能な外部記憶装置にアクセスする手段と、
機器本体内に画像データを保存できるメモリ部を持ち、
さらに、画像データに対して、符号化、復号化、拡大、回転、縮小などのデータ変換を行うハードウエア画像変換デバイスと、ソフトウエア画像変換モジュールを持つ画像通信装置において、上記の画像処理を依頼するデバイスが、画像符号データに対して画像変換を行う場合、ハードウエア画像変換デバイスに画像処理を依頼する場合は、それぞれのハードウエア変換デバイスへのインターフェイスモジュールを通して処理を依頼し、ソフトウエア画像変換モジュールに画像処理を依頼する場合は、ソフトウエア画像変換モジュール全てのインターフェイスを行う、１つのインターフェイスモジュールを通して処理を依頼することを特徴とする画像通信装置。
【請求項２】
それぞれのハードウエア画像変換デバイスに対応する、複数のインターフェイスモジュールと、
それぞれのソフトウエア画像変換モジュールをまとめる、１つのインターフェイスモジュールに対して、さらにそれらを取りまとめる上位インターフェイスモジュールを持ち、スキャナ、プリンタなどの画像処理を依頼するデバイスは、上位インターフェイスモジュールに対してのみ処理の依頼を行い、その依頼内容に対して、ハードウエア画像変換デバイスを使用するか、ソフトウエア画像変換モジュールを使用するかは、上位インターフェイスモジュールが決定して、下位のインターフェイスモジュールに作業を振り分けることを特徴とした請求項１の画像通信装置。
【請求項３】
スキャナ、プリンタなどの画像処理を依頼するデバイスが、上位インターフェイスに処理を依頼する際に、その処理をハードウエア画像変換デバイスを使用するか、ソフトウエア画像変換モジュールを使用できるかを、依頼時に指定することのできることを特徴とする、請求項２の画像通信装置。
【請求項４】
上位インターフェイスモジュールは、ハードウエア画像変換デバイスの競合制御機能を持ち、スキャナ、プリンタなどの画像処理を依頼するデバイスが、依頼した処理に必要なハードウエアデバイスが使用中の場合、同機能を持つソフトウエア画像処理モジュールに処理を依頼することを特徴とする、請求項２の画像通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像通信装置のソフトウエア構成に関するものである。
【背景技術】
【０００２】
マルチパス機において、画像データの入力経路は、スキャナ、ネットワークからの受信、ファクシミリからの受信、メモリカード等外部記憶装置からのファイルの読み込みなどがある。また、逆に、画像データの出力経路としては、用紙へのプリント、ネットワークへの送信、ファクシミリへの受信、外部記憶装置へのファイルの書き込みなどが挙げられる。
【０００３】
画像データは、これらの入力経路を通じて、機器本体内のメモリに格納され、またこれらの出力経路を通じて機器本体内のメモリからデータを放出する。
通常、本体機器内のメモリの内部で、画像データを保持する時には、あらかじめその画像データの符号形式、ファイル形式が決められている。従って、画像データの入力の際には、外部から入ってきたデータを、本体機器で保持する画像データ形式に変換する必要があり、また、出力の際には本体機器内のデータ形式から、出力の対象となるデータ形式に変換する必要がある。
【０００４】
従って、スキャナ、プリンタ、ネットワーク通信部等、画像データのやり取りを担うデバイスは、符号形式やファイル形式の変換を行う必要がある。
【０００５】
一方で、実際に画像データの符号化、復号化、回転、拡大縮小を行う、画像処理デバイスが存在する。スキャナ、プリンタ、ネットワーク通信部等が必要とする、画像変換処理は、機能的に重複しているので、これらの画像変換デバイスは、独立したデバイスとして動作している。また、画像処理に必要な処理要素は、ハードウエアで実現しているものと、ソフトウエアで実現しているものがある。ハードウエアによる処理は高速であるが、チャンネルが有限個しかないため、それ以上の多重動作を行うことができない。ソフトウエアによる処理は、比較的低速であるが、多重動作に関しての制限が無く、CPUの処理容量を越えない限り、いくつでも並行動作が可能となる。
【０００６】
スキャナ、プリンタ、ネットワーク通信部等は、これらの画像処理デバイスに、画像処理を依頼することになる。従来では、この依頼作業はそれぞれ、プリンタ部はプリンタ部で設定し、スキャナ部はスキャナ部で設定していた。そしてそれぞれの依頼元で、どの画像処理デバイスをどのように使用するか判断し、詳細な設定を行い、実行開始、中止、終了などの指令を直に行っていた（特許文献１参照）。
【０００７】
図２は、従来の画像処理デバイスの使用例を示したものである。画像データの符号化、復号化、拡大縮小、回転等の処理をスキャナはスキャナの制御ソフト部で設定を行い、プリンタはプリンタの制御ソフト部で設定し、それぞれ画像操作デバイスを使用している。また、ハードウエア画像処理デバイスか、ソフトウエア画像処理デバイスかどちらを使用するかということも、プリンタ部やスキャナ部で決定していた。
【０００８】
図３は、例として、スキャナ部が、画像データ操作ソフトモジュールの使用する場合についてのフローを示したものである。読み取りを開始すると、まず始めに、スキャナは原稿の主走査長を調べる（３−１）。次に、CCDカメラより、画像の読み取りを開始し、獲得した生画像データを一旦メモリに格納する（３−２）。その後、符号化を依頼するデバイスを、ソフトモジュールか、ハードデバイスかを決定する。まず、ハードウエアデバイスの競合制御部に、そのハードデバイスが使用中でないかどうかのチェックを行う。そして、使用中でない場合は、主走査長や、副走査長、画像データのメモリアドレス等の画像処理に必要とするパラメータを、そのハードデバイスが理解できるようにパラメータ群を作成する（３−３）。また、使用中の場合は、同じ機能を持つソフトウエアモジュールに対して、主走査長や、副走査長、画像データのメモリアドレス等のパラメータ群を、ソフトモジュールの理解できるパラメータ群として作成する。そして、それぞれの場合において、そのパラメータを渡すとともに、画像データ操作ソフトモジュールに処理を依頼する（３−４）。そのあいだ、スキャナ部は、レスポンス待ちのため待ち状態に入る（３−５）。パラメータを受け取った画像処理ソフトモジュール、または画像処理ハードデバイスは、スキャナ部の指示する画像データを、指示された変換する（３−６）。そして、出来上がった符号をメモリに格納し、スキャナ部に修理終了の通知を行う（３−７）。通知を受け取ったスキャナ部は待ち状態から抜け、処理終了を確認し、読み取り動作の後処理を行い終了する（３−８）。
【特許文献１】特開２００２−３０５６２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来の手法では、画像データを処理するデバイスが、それぞれで画像データの操作を行うソフトモジュール、ハードデバイスを呼び出し、設定を行い処理を依頼している形となっていた。また、同じ機能を、ソフトモジュールとハードデバイスの両方で設定できる場合、（例えば、JBIG符号への符号化はハードデバイスでも可であり、ソフトでも同機能の処理が可能）そのどちらを使用するかという選定も依頼側で指定していた。しかし、この手法では、将来的に画像データの操作を行うソフトモジュールやハードデバイスに変更や入れ替えがあった場合、それに伴って画像データを処理するプリンタやスキャナなどの依頼元のデバイスがそれぞれに変更点のあったソフトモジュール、ハードデバイスに関する変更を行わなければならない。また、ハードとソフトの両方で実現できる機能としては、その選定する部分にも変更が必要であり、それぞれの依頼元タスクにその変更が必要となってしまっていた。
【課題を解決するための手段】
【００１０】
本発明によれば、ネットワークとのデータの送受信を行うことのできるネットワーク通信制御部と、原稿を読み取り、画像データに変換できる、読み取り部と、画像データを出力できる記録部と、機器本体から取り外し、持ち運びが可能な外部記憶装置と、機器本体内に画像データを保存できるメモリ部を持つ画像通信装置において、上記の画像処理を依頼するデバイスが、画像符号データに対する符号化、復号化、拡大、縮小、回転等の画像処理ソフトモジュール、ハードデバイスを併用して処理する際に、インターフェイスモジュールを必ず通過させることで、画像操作ソフトモジュール、ハードデバイスに対しての変更についての影響はすべて、インターフェイスモジュールまでで吸収できることになり、変更に強く、流用性の高いシステムを実現できる。
【００１１】
そのために、まず、それぞれの画像処理ソフトモジュールに関しては、その依頼方法について、ある程度一般化させることが比較的容易であるため、画像処理ソフトモジュール群に関しては、唯一つのインターフェイスモジュールを設定し、画像処理依頼元のデバイスは、画像処理ソフトモジュールを使用する時は、必ず、このインターフェイスモジュールに依頼して処理を行う。
【００１２】
一方で、それぞれの画像処理ハードウエアデバイスに関しては、その処理依頼方法はさまざまであり、また、その依頼方法を変更することが極めて困難であるので、それぞれの画像処理ハードデバイスに対して１対１にインターフェイスモジュールを設定する。
【００１３】
これにより、画像操作ソフトモジュール、ハードデバイスに対しての変更についての影響はすべて、インターフェイスモジュールまでで吸収できる。また、ソフトモジュールの依頼方法についての一元化をも実現できる。
【００１４】
さらに、それぞれの画像操作ソフトモジュール、ハードデバイスのインターフェイスモジュール（下位インターフェイスモジュール）の上にそれらの下位インターフェイスモジュールを統括する上位インターフェイスモジュールを設定し、画像処理依頼元のデバイスは、必ずこの上位インターフェイスモジュールを通して処理依頼を行うことにより、処理依頼側としては、ソフトとハードの意識をしない処理要求の手法が可能となり、さらに柔軟性、流用性を高めることが可能となる。
【００１５】
そして、その上位インターフェイスモジュールに、競合制御機能を持たせ、同機能の要求に対するハード、ソフトの切り替えを自動的に行うようにすることにより、処理依頼側は、処理方法だけでなく、ソフトとハードの意識を全く無いままで、処理依頼を行うことも可能となる。
【００１６】
しかし、処理内容としては、是非ハードウエアで行いたい処理であると言うものも存在するため、処理依頼側に選択機能をつけることも可能である。
【発明の効果】
【００１７】
以上説明したように、プリンタ部や、スキャナ部など、画像処理を依頼するデバイスが、画像符号データに対する符号化、復号化、拡大、縮小、回転等の画像処理ソフトモジュール、ハードデバイスを併用して処理する際に、インターフェイスモジュールを必ず通過させることで、画像操作ソフトモジュール、ハードデバイスに対しての変更についての影響はすべて、インターフェイスモジュールまでで吸収できることになり、変更に強く、流用性の高いシステムを実現できる。さらに、処理依頼側としては、ソフトとハードの意識をしない処理要求の手法が可能となり、さらに柔軟性、流用性を高めることが可能となる。
【発明を実施するための最良の形態】
【００１８】
本発明の手順をネットワーク画像通信装置にインターネットFAXを例にあげて説明する。
【００１９】
図１は、本発明における通信装置のハードウエア構成の概略図である。
【００２０】
図２は、本発明におけるハード及びソフトデバイスのインターフェイスモジュールの説明図である。
【００２１】
図３は、符号化ソフトモジュールを、例としてスキャナ部が使用した場合の従来例である。
【００２２】
図４は、ハード及びソフトデバイスにインターフェイスモジュールを配置した際の実施例である。
【００２３】
図５は、JPEGハードデバイスを、例としてスキャナ部が使用した場合の図４での実施例である。
【００２４】
図６は、上位インターフェイスを配置した際の実施例である。
【００２５】
図７は、JPEGハードデバイスを、例としてスキャナ部が使用した場合の図６での実施例である。
【００２６】
図１において、
（１−１）：CPUはシステムの制御部であり、装置全体を制御する。
【００２７】
（１−２）：ROMはCPUの制御プログラムを格納するためのものである。
【００２８】
（１−３）：SRAMはオペレータが登録した設定値や装置の管理データ等や各種ワーク用バッファ等を格納するものである。
【００２９】
（１−４）：DRAMはプログラム制御変数等を格納するためのものである。また画像データ、テキストデータを蓄積するためのものである。
【００３０】
（１−５）：読み取り部は画像データを読み取り、バイナリデータに変換する装置である。
【００３１】
（１−６）：記録部は画像データを、記録紙に出力する装置である。
【００３２】
（１−７）：ネットワーク通信制御部はネットワークとの通信インターフェイスである。
【００３３】
（１−８）：ファクシミリ通信制御部は電話回線との通信インターフェイスである。
【００３４】
（１−９）：操作部はオペレータによる登録を行う装置である。
【００３５】
（１−１０）：CODECは通信制御装置で扱う画像データの符号化復号化処理を行う。また画像の縮小拡大処理もここで行われる。
【００３６】
図２は、従来の画像処理デバイスの使用例を示したものである。画像データの符号化、復号化、拡大縮小、回転等の処理をスキャナはスキャナの制御ソフト部で設定を行い、プリンタはプリンタの制御ソフト部で設定し、それぞれ画像操作デバイスを使用している。また、ハードウエア画像処理デバイスか、ソフトウエア画像処理デバイスかどちらを使用するかということも、プリンタ部やスキャナ部で決定していた。
【００３７】
図３は画像データ操作モジュールとして、符号化ソフトモジュールを、例としてスキャナ部が使用した際の従来の動作例を示したフローである。
【００３８】
図３に従って動作を説明する。
【００３９】
読み取りを開始すると、まず始めに、スキャナは原稿の主走査長を調べる（３−１）。次に、CCDカメラより、画像の読み取りを開始し、獲得した生画像データを一旦メモリに格納する（３−２）。その後、主走査長や、副走査長、画像データのメモリアドレス等の画像データ操作ソフトモジュールの必要とするパラメータを、そのソフトモジュールが理解できるパラメータ群を作成する（３−３）。そして、そのパラメータを渡すとともに、画像データ操作ソフトモジュールに処理を依頼する（３−４）。そのあいだ、スキャナ部は、レスポンス待ちのため待ち状態に入る（３−５）。パラメータを受け取った画像データ操作ソフトモジュールは、スキャナ部の指示する画像データを、指示された符号に変換する（３−６）。そして、出来上がった符号をメモリに格納し、スキャナ部に処理終了の通知を行う（３−７）。通知を受け取ったスキャナ部は待ち状態から抜け、処理終了を確認し、読み取り動作の後処理を行い終了する（３−８）。
【００４０】
図４は画像処理の各ソフトモジュールおよびハードデバイスのインターフェイスを配置した例を示している。画像処理のソフトモジュールはそれぞれのインターフェイスをある程度変更し、まとめることは可能であるので、ソフトモジュールの上位には「ソフト統括I/F」として１つのインターフェイスのみで管理するようにしている。一方で、ハードデバイスの方は、それぞれのデバイスのインターフェイスを容易に変更することが不可能であるため、１つのデバイスに１つのインターフェイスモジュールを置くことにより、それより上位の依頼元タスクからの要求に柔軟に対応できる作りになっている。
【００４１】
図５は画像データ操作デバイスとして、JPEG符号化ハードデバイスを、例としてスキャナ部が使用した際の本発明における動作例を示したフローである。
【００４２】
大まかな動作は図３と同様であるので、異なる点において説明する。スキャナ部が画像を読み取り、生画像データを獲得し、符号化を依頼するために必要なパラメータ群を作成する場合において、そのパラメータ群は、ハードJPEGインターフェイスタスクが理解できるパラメータ群を作成する（５−３）。そして、ハードJPEGインターフェイスタスクに向けて、符号化の依頼を行う（５−４）。その後、スキャナ部は待ち状態に入る（５−５）。
【００４３】
パラメータを受け取ったハードJPEGインターフェイスタスクは、JPEGハードデバイスの必要としているパラメータ群に変換し（５−６）、JPEGハードデバイスに符号化の依頼を行う（５−７）。そして、ハードJPEGインターフェイスタスクは待ち状態に入る（５−８）。パラメータを受け取ったハードJPEGデバイスは、ハードJPEGインターフェイスタスクの指示する画像データを、指示された符号に変換する（５−９）。そして、出来上がった符号をメモリに格納し、ハードJPEGインターフェイスタスクに処理終了の通知を行う（５−１０）。処理終了の通知を受け取ったハードJPEGインターフェイスタスクは、依頼元であるスキャナ部に処理終了の通知を行う（５−１１）。通知を受け取ったスキャナ部は待ち状態から抜け、処理終了を確認し、読み取り動作の後処理を行い終了する（５−１２）。
【００４４】
図６は、図４において配置した、画像処理の各ソフトモジュールおよびハードデバイスのインターフェイスを下位インターフェイスとし、これらを統括するさらに上位のインターフェイスタスクを配置し、スキャナ、プリンタ等の画像処理依頼元は必ず、この上位インターフェイスを通して依頼することにより、より変更に柔軟なシステムを構築した際の例を示している。またこの上位インターフェイスタスクに処理を依頼する際に、「強制的にハードデバイスを使う」といった、デバイス指定を行えるようにすることにより、さらに柔軟な処理の振り分けが可能となる。さらにこの上位インターフェイスに競合制御機能を持たせることにより、画像処理依頼元が、「JPEGデータを符号化して欲しい」という依頼を行うだけで、ハードJPEGデバイスのチャネルが空いているかどうか調べ、使用中であれば、ソフトJPEGモジュールに依頼するといった振り分けを上位インターフェイスで決定することが可能となり、画像処理依頼元は、処理の依頼先に対して、ソフトかハードかといった意識を全く行わなくても良いようになる。
【００４５】
図７は、図６で示した上位インターフェイスを配置した際の実施例を示している。この例では、図５と同じくJPEG符号化ハードデバイスを、スキャナ部が使用した際の本発明における動作例を示したフローである。
【００４６】
大まかな動作は図５と同様であるので、異なる点において説明する。スキャナ部が画像を読み取り、生画像データを獲得し、符号化を依頼するために必要なパラメータ群を作成する場合において、そのパラメータ群は、上位インターフェイスタスクが理解できるパラメータ群を作成する（７−３）。そして、上位インターフェイスタスクに向けて、符号化の依頼を行う（７−４）。その後、スキャナ部は待ち状態に入る（７−５）。
【００４７】
パラメータを受け取った上位インターフェイスタスクは、JPEG符号変換を必要としていることを知り、JPEG符号化能力を持つ下位モジュールの中から、ハードJBIGデバイスを選択する。そして、ハードJBIGデバイスインターフェイスの必要としているパラメータ群に変換し（７−６）、JPEGハードデバイスインターフェイスに符号化の依頼を行う（７−７）。そして、上位インターフェイスタスクは待ち状態に入る（７−８）。
【００４８】
パラメータを受け取ったハードJPEGインターフェイスタスクは、JPEGハードデバイスの必要としているパラメータ群に変換し（７−９）、JPEGハードデバイスに符号化の依頼を行う（７−１０）。そして、ハードJPEGインターフェイスタスクは待ち状態に入る（７−１１）。パラメータを受け取ったハードJPEGデバイスは、ハードJPEGインターフェイスタスクの指示する画像データを、指示された符号に変換する（７−１２）。そして、出来上がった符号をメモリに格納し、ハードJPEGインターフェイスタスクに処理終了の通知を行う（７−１３）。処理終了の通知を受け取ったハードJPEGインターフェイスタスクは、上位インターフェイスに処理終了の通知を行う（７−１４）。さらに上位インターフェイスは終了通知を依頼もとのスキャナ部に送る（７−１５）。通知を受け取ったスキャナ部は待ち状態から抜け、処理終了を確認し、読み取り動作の後処理を行い終了する（５−１６）。
【図面の簡単な説明】
【００４９】
【図１】本発明実施時の通信装置のハードウエア構成を示した図である。
【図２】本発明におけるハード及びソフトデバイスのインターフェイスモジュールの説明図である。
【図３】符号化ソフトモジュールを、例としてスキャナ部が使用した場合の従来例である。
【図４】ハード及びソフトデバイスにインターフェイスモジュールを配置した際の実施例である。
【図５】JPEGハードデバイスを、例としてスキャナ部が使用した場合の図４での実施例である。
【図６】上位インターフェイスを配置した際の実施例である。
【図７】JPEGハードデバイスを、例としてスキャナ部が使用した場合の図６での実施例である。
【図１】
2005217683.tif 000003
【図２】
2005217683.tif 000004
【図３】
2005217683.tif 000005
【図４】
2005217683.tif 000006
【図５】
2005217683.tif 000007
【図６】
2005217683.tif 000008
【図７】
2005217683.tif 000009