JP3285941B2

JP3285941B2 - 色処理方法、色処理装置、及びカラー画像処理システム

Info

Publication number: JP3285941B2
Application number: JP20524692A
Authority: JP
Inventors: 良和横溝
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1992-07-31
Filing date: 1992-07-31
Publication date: 2002-05-27
Anticipated expiration: 2017-05-27
Also published as: EP0581590B1; US5699489A; DE69323809T2; EP0581590A3; JPH0654176A; DE69323809D1; US5923824A; EP0581590A2

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、カラー画像を入出力す
るデバイスの色空間の違いを補正する色処理方法、色処
理装置、及びカラー画像処理システムに関するものであ
る。

【０００２】

【従来の技術】例えば、コンピュータ，スキャナ，電子
カメラ及びプリンタ等の各種デバイスにおいて同じＲＧ
Ｂの色成分を表現できても、各色成分毎の感度は各デバ
イス毎に微妙に違っており、ユーザの意図したプリント
結果が得られない場合が多い。また、例えば１台のコン
ピュータが複数のプリンタを切り換えて使う場合には、
プリンタ毎の色再現が異なる場合が多く、印刷結果がま
ったく同じにはならない場合が多い。

【０００３】この様な場合、通常、演算処理能力の高い
コンピュータにおいて、各デバイス毎に適切な色補正を
行っている。この時、アプリケーションソフトの対応方
法としては、何らかのメニューを表示させ、そのメニュ
ーから必要なプリンタ或いはスキャナ等の固有の色空間
を選択させる方法が一般的に行われている。

【０００４】

【発明が解決しようとする課題】しかしながら、上記従
来例では、本質的に以下のような欠点があった。（１）プリンタやスキャナの種類が増えてくると、アプ
リケーションソフト側での対応が取れなくなる。（２）色補正が、アプリケーションを操作する者の責任
になる。つまり、ユーザが色補正しなければならない。

【０００５】上述の問題は、特にネットワークを介して
複数のスキャナやプリンタを複数のコンピュータで共同
利用する際に深刻な問題であった。本発明は、上記課題
を解決するためになされたもので、外部装置から受信し
た第１の色空間をデバイスインディペンデントな色空間
に変換する第１の色処理データと、デバイスインディペ
ンデントな色空間を第２の色空間に変換する第２の色処
理データとを合成して生成したパラメータを用いて入力
カラー画像データを色空間変換し、第２の色空間のカラ
ー画像データを出力する色処理方法、色処理装置、及び
カラー画像処理システムを提供することを目的とする。

【０００６】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、第１のデバイスに依存する第１の色空間
の入力カラー画像データを第２のデバイスに依存する第
２の色空間の出力カラー画像データに変換する色処理方
法であって、前記第１の色空間をデバイスインディペン
デントな色空間に変換する第１の色処理データを外部装
置から通信回線を介して受信し、前記第１の色処理デー
タと前記デバイスインディペンデントな色空間のカラー
画像データを第２の色空間のカラー画像データに変換す
る第２の色処理データとを合成することによりパラメー
タを生成し、前記パラメータを用いて入力カラー画像デ
ータの色空間変換を行い、第２の色空間のカラー画像デ
ータを出力することを特徴とする。

【０００７】

【実施例】以下、添付図面を参照して本発明に係る好適
な一実施例を詳細に説明する。通常、コンピュータとプ
リンタとの接続は、例えばセントロニクスを代表とする
ケーブルによって物理的に行うが、ローカルエリアネッ
トワーク（ＬＡＮ）に接続されたネットワークプリンタ
を考えても分かるように、物理的にも論理的にもケーブ
ルが接続点であると考えるのは誤りである。ケーブルは
物理的接続点であるが、もし、ケーブルが論理接続点で
もあるなら、アプリケーションは個々のプリンタやスキ
ャナの物理的仕様の違いまでも切り替えなければならな
い事になってしまう。

【０００８】この問題を避けるため、入出力デバイスメ
ーカーにより供給される入出力デバイスをコンピュータ
に接続する時に、コンピュータのオペレーティングシス
テム（ＯＳ）にデバイスドライバをインストールしてい
る。実施例では、プリンタやスキャナ等の入出力デバイ
スとのインターフェースを以下の４項目について仮想化
することにより、実現するものである。（１）論理接続点（２）標準色空間（３）仮想色補正（仮想色空間変換）（４）仮想色空間変換プロトコル＜論理接続点＞図１は、本発明のシステムブロック図で
ある。同図において、１はスキャナ、２は接続ケーブ
ル、３はスキャナのデバイスドライバ、５は例えばカラ
ーＤＴＰソフトの様な画像処理アプリケーション、６は
プリンタのデバイスドライバ、７は接続ケーブル、８は
プリンタである。デバイスドライバ３，６はコンピュー
タ４の中に存在し、互いにソフト的な結合パス９及び１
０で接続されている。

【０００９】従来、カラー画像データのインターフェー
スは入出力デバイス１，８との物理的な接続点（２，
７）で規定されているが、実施例では、論理的な接続点
（９，１０）で規定する。つまり、デバイスドライバ３
は物理的にはコンピュータ４の中に存在するが、論理的
にはスキャナ１の一部と考えられ、また、プリンタドラ
イバ６は物理的にはコンピュータ４の中に存在するが、
論理的にはプリンタ８の一部と考えられる。

【００１０】従って、コンピュータ４とスキャナ１又は
プリンタ８との色空間特性の違いについては、デバイス
ドライバ３，６とのインターフェース９，１０を論理接
続点として、そこで色補正をするとやりやすい。以下こ
れらの点を論理接続点９及び１０と呼ぶ事にする。実施
例では、これら論理接続点の左右に標準色空間を設定す
る。例えば、コンピュータ４がＲＧＢの色空間を用い、
プリンタ８がＹＭＣの色空間を用いている場合には、デ
バイスドライバ６がＲＧＢからＹＭＣへの変換を行う。

【００１１】＜論理接続点における色補正＞この方式
は、ＲＧＢやＹＭＣの様に、明確に異なる色空間同士の
間の変換だけに適用するものではなく、例えばＲＧＢと
ＲＧＢ同士の間にも適用できることは言うまでもない。
例えば、スキャナ１は通常ＲＧＢ信号を出力することが
多く、コンピュータ４もＲＧＢを標準にすることが多
い。しかし、両者の白バランスは微妙に違っている事が
多く、従来、最終的にはユーザが手動で微調整をしてい
たか、何もせずに諦めていた。しかるに、スキャナ１の
色空間が仮にＲ′Ｇ′Ｂ′だったとすると、コンピュー
タ４の色空間ＲＧＢに合わせるための補正をどの部分が
やらなければならないかと言うと、やはりデバイスドラ
イバ３が行うのが理想的である。つまり、論理接続点に
おいて色補正を実施するという形態が最も望ましい。

【００１２】＜標準色空間の導入＞上述の如く、スキャ
ナ１の色空間をＲ′Ｇ′Ｂ′とし、コンピュータ４の色
空間をＲＧＢとしたのは適切でない。なぜなら、良く設
計されたスタンドアロンのスキャナは、通常その内部で
色補正をして出力するから、自分自身は標準のＲＧＢで
ある、と信じて出力しているので、もしかするとコンピ
ュータ４の色空間の方が狂っているかも知れないのであ
る。通常、コンピュータは正しい色空間に則っていると
錯覚するのは、コンピュータの内部で扱われる者はデジ
タルの数値であり、スキャナは光源、撮像素子を含むア
ナログ装置であるからどうしても分が悪い。ところが、
コンピュータ上である値をセットすると、それが何色に
なるかという事は、実際には分からないのである。なぜ
なら、コンピュータのデータはＣＲＴディスプレイ上に
表示されて初めて人間の目に触れる訳だから、ＣＲＴデ
ィスプレイが正確に校正されたものでない限りコンピュ
ータの数値が正しいとは言えないのである。通常、諸々
の色補正を行う時に、コンピュータではなく各デバイス
を調整するのは、コンピュータが全てのデバイスを制御
しているため、コンピュータで色補正を行う訳には行か
ず、仮にコンピュータは正しいと仮定して使っているに
過ぎないのである。

【００１３】＜色補正をコンピュータで行う矛盾＞実際
のシステムの構成として、最終的な色補正をコンピュー
タで行うのは便利だから、しばしばそうした構成になり
がちである。しかし、これは上述した論理に照らし合わ
せるとはなはだ問題である。具体的な例で説明すると、
あるアプリケーションでは、コマンドのメニューの中か
らスキャナを駆動できる様になっている。つまり、アプ
リケーションが直接スキャナを駆動できるのだからさぞ
かし便利なはずであるが、実際にはメニューの中におび
ただしいスキャナ製品のリストが表示され、その中から
自分のスキャナを選択してから原稿のスキャンとなる。
このスキャナの選択は一回やっておけば良いので、何等
問題はなさそうにも思えるが問題も生じる。

【００１４】このように、アプリケーションから諸々の
スキャナが選択できるという事は、裏を返せば各種スキ
ャナの諸々のセッティングもアプリケーションの責任で
やらなければならないと言う事を意味する。色補正もし
かりである。世の中に、白黒２値のスキャナが数種類し
かなかった頃ならこれでも良いが、白黒の中間調あり、
カラーありという時代になって来るとこのやり方では不
充分である。やはり、デバイスドライバの所で責任の分
界点を明確にし、スキャナの色補正はスキャナ側の責任
で行わなければならない。即ち、ユーザに取ってたった
１台のスキャナであっても、システムとしてはどんなス
キャナを持って来ても無調整でつながるような構成にな
っていなければならない。

【００１５】＜標準色空間の設定＞上述の問題点や矛盾
点を解決する為に、実施例では論理接続点において標準
色空間を設定している。式１は、色［Ｒ′Ｇ′Ｂ′］を
色［ＲＧＢ］に変換するための式である。［ｆ₁₁，
ｆ₁₂，…，ｆ₃₃］は変換係数マトリックスである。また
式２は、色［ＲＧＢ］を色［ｒｇｂ］に変換するための
式である。［ｇ₁₁，ｇ₁₂，…，ｇ₃₃］は変換係数マトリ
クスである。

【００１６】式１の［ＲＧＢ］を式２に代入すると、式
３が得られる。ここで、式３の変換係数マトリクスを式
４の様に置き換えると、式３は式５の様に表される。即
ち、変換係数マトリクス同士の計算を１回やっておけ
ば、２回やるべき色変換のための計算を１回で済ますこ
とができる事が解る。変換係数マトリクス［ｆ₁₁，
ｆ₁₂，…，ｆ₃₃］と［ｇ₁₁，ｇ₁₂，…，ｇ₃₃］は簡単の
ため、それぞれ式６，式７の様に［Ｆ］，［Ｇ］と表現
する。

【００１７】

【数１】

【００１８】

【数２】

【００１９】

【数３】

【００２０】

【数４】

【００２１】

【数５】

【００２２】

【数６】

【００２３】

【数７】

【００２４】

【数８】

【００２５】図２は、コンピュータ４内の色空間特性を
示す模式図であり、図１と同じ構成要素には同じ番号を
付与してある。同図において、１１はスキャナ固有の色
空間特性、１２は標準空間特性、１３はコンピュータ固
有の色空間特性であり、便宜上それぞれ［Ｒ′Ｇ′
Ｂ′］、［ＮＴＳＣＲＧＢ］、［ｒ′ｇ′ｂ′］とす
る。また、［Ｇ］は［Ｒ′Ｇ′Ｂ′］を［ＮＴＳＣＲ
ＧＢ］に変換する為の変換手段（マトリクス）、［Ｆ］
は［ＮＴＳＣＲＧＢ］を［ｒ′ｇ′ｂ′］に変換する
為の変換手段（マトリクス）である。

【００２６】上述の標準色空間は色彩工学上妥当なもの
であれば何であってもよいが、画像データの送り側（ス
キャナ３）も受けて側（コンピュータ５）も共に［ＲＧ
Ｂ］の場合には、［ＮＴＳＣＲＧＢ］が望ましい。送
り側では、変換手段［Ｇ］によってデバイス固有の色空
間特性［Ｒ′Ｇ′Ｂ′］を、標準色空間［ＮＴＳＣＲＧ
Ｂ］に変換する。そして、受け側では、変換手段［Ｆ］
によって標準色空間［ＮＴＳＣＲＧＢ］からデバイス
固有の色空間［ｒ′ｇ′ｂ′］に変換する。このよう
に、標準色空間への／から変換義務は、スキャナ１もコ
ンピュータ４も対等に負っている。

【００２７】＜仮想色補正（仮想色空間変換）＞前項の
目的を実行する為には、［Ｇ］と［Ｆ］という２回の変
換手段が必要になる。しかし、これは以下の様な問題が
ある。（１）システム全体の価格がアップしてしまう。（２）スループットが悪くなる。

【００２８】（３）変換する度に、演算誤差が累積す
る。（４）変換する度に、色表現のダイナミックレンジが狭
くなる。このような問題を避けるため、実施例では、仮想色補正
（仮想色空間変換）の概念を導入している。仮想色補正
／仮想色空間変換（以下「仮想変換」）とは、目的とす
る標準色空間への変換式と、元のデータをセットで送る
だけで、実際には何も演算を施さず、最終的な演算はデ
ータを受け取った側に委ねてしまう方法である。変換手
段［Ｇ］［Ｆ］同士の計算をやってから、それに元の画
像データを掛算すれば、計算の手間が１回で済み、しか
も丸め等による演算誤差の累積もない。但し、データを
受け取った側に演算を委ねられるのは、受け側にその様
な機能がある場合のみであり、その様な機能がなけれ
ば、送り側で変換して出さなければならない。

【００２９】＜仮想色変換空間プロトコル＞図３は、実
施例における仮想色空間変換プロトコルの概要を示すも
のである。送り側と受け側では、デバイスドライバを介
して通信を行うので、プロトコルはパケットのやり取り
により実現される。例えば、パーソナルコンピュータの
場合にはパケットのポインタのみを渡し、実際にパケッ
トを伝送しなくても良い。

【００３０】図４〜図７は、伝送される各パケットの構
造を示す図である。尚、その構造は同様であり、ここで
は図４に示す色空間要求（Color_Space_Request)パケッ
トを例に説明する。各要素は１バイトを基本とし、先頭
からパケットID（Packet_ID)４１、コマンドID（Comman
d_ID）４２、長さ（Length）４３、内容（Content)４４
の順番にデータが構築される。パケットID４１は、その
パケットの種類を表すコードが入る。コマンドID４２
は、以下に続く内容の意味を表すコードが入る。長さ４
３は、内容４４のバイト単位の長さを示す。コマンドID
４２、長さ４３及び内容４４は、必要に応じて繰り返し
ても良い。パケットの最後には、終了コード（Terminat
or）４５が入る。終了コード４５はコマンドIDの一種
で、［０］を書く。そして、内容４４は可変長で、その
長さは、長さ４３がバイト単位に規定する。尚、内容を
可変長にしたのは、拡張性を持たせるためで、固定長で
あっても良い。

【００３１】ここで、図３に示す仮想色空間変換プロト
コルについて説明する。まず送り側に対して色空間要求
パケットを送り、自分が送りたい画像の色空間を指定す
ると共に、相手の色空間が何であるかを問い合わせる。
同時に、色変換機能の有無も知らせる。この時、送り側
は、例えば図４の例に示す様に、［ＲＧＢ］の色空間に
則って送信し、且つ自分には色変換機能が無い［Ｎｏ］
事を知らせる。一方、受け側は、要求パケットに対して
色空間リスト（Color_Space_List）パケットを返し、自
分の受けられる色空間のリストを知らせる。この時、受
け側は、例えば図５の例に示す様に、［ＲＧＢ］の色空
間に則って受信し、且つ、そこに色変換機能がある［Ｙ
ｅｓ］事を知らせる。

【００３２】これに対し、送り側は、改めて図６に示す
色空間選択（Color_Space_Select）パケットを送り、使
用する色空間とデータ形式を確定する。例えば、［ＲＧ
Ｂ］の色空間データを仮想色補正パラメータ付で送る事
を確定する。このパケットには、色空間補正用のフィル
タ係数 (Filter_Coefficients)が含まれている。受け側
は、図７に示す色空間選択確認（Color_Space_Select_A
ck）パケットによって使用する色空間とデータ形式を確
認する。色空間選択確認パケットはオプションであって
も良く、必ずしも確認はしなくても伝送は可能である。

【００３３】次に、スキャナやプリンタがネットワーク
を介してコンピュータに接続されている場合を説明す
る。送り側に、例えばアップルコンピュータ（以下アッ
プル）社のマッキントッシュ（以下「SP Client 」と略
す）、受け側にスタンドアロンのネットワーク・スキャ
ナプリンタサーバ（以下「SP Server 」と略す）を用い
てシステムを構築する場合、通信プロトコルを介して両
者を接続することになる。マッキントッシュでは、ロー
カルトークを用いるのが一般的だが、例えばＳＵＮを代
表とするＵＮＩＸ環境と共存させるためには、TCP/IPプ
ロトコルの方が便利である。そのため、マッキントッシ
ュ用のTCP/IPプロトコルであるMacTCPを用いて本実施例
を実現する方法を述べる。

【００３４】ここで述べる機能要素は、PrintTCP，SP C
lient ，SP Server ，MacTCPの４つである。マッキント
ッシュにインストールするのは、PrintTCPとSP Client
及びアップルのMacTCPである。PrintTCPは、マッキント
ッシュのアプリケーションからTCP/IPを介してイーサネ
ット（Etherenet ）上のスキャナプリンタサーバに印刷
する為のスキャナプリンタドライバである。PrintTCPの
基本機能は以下の通りである。（１）プリント時にQuickDraw 描画サブルーチンがコー
ルされた時、それと等価なCaPSL (Canon Printing Syst
em Language)コードを生成する。ここで、CaPSLはキヤ
ノン（株）が海外市場向けに開発したプリンタ言語であ
る。（２）BitMapの中間調画像データ（カラー／白黒）は、
オプションとしてＪＰＥＧ規格に準拠したＡＤＣＴ方式
によるデータ圧縮を掛けたものを、CaPSL コードとして
生成する。（３）生成したCaPSL コードを、S/P Clientドライバを
通じてS/P Serverに伝送する。

【００３５】S/P Clientは、S/P Serverに接続されてい
るプリンタにCaPSL コードを伝送するための通信制御プ
ログラムであり、TCP/IP及びEthernetを介して通信を行
う。S/P Clientの基本機能は以下の通りである。（１）TCP/IPを介してS/P ServerとEnd-to-Endのリンク
を張る。（２）PrintTCPから受け取ったCaPSL データを、S/P Se
rverに送る。（３）S/P Serverに原稿のスキャンをさせ、それを受信
し、アプリケーションに送る。

【００３６】S/P Serverは、ＳＰサーバ上でデーモンと
して常に走っており、クライアントからの受信を待って
いる。S/P Clientの基本機能は以下の通りである。（１）S/P Clientから受け取ったCaPSL データをCaPSL
インタープリタに渡す。（２）原稿をスキャンするプログラムを起動し、受け取
ったデータをS/P Clientに送る。

【００３７】これらのプログラムの関係を図８の太い四
角で囲んだ部分に示す。各プログラムユニットのリソー
スの形式及び機能を次に示す。（イ）Printing Manager:System に標準でインストール
されている次のプリンタドライバをコールする。type=D
RVR 、iPrDrvRef=-3 （ロ）PrintTCP：このプリンタドライバは、初めはSyst
emにインストールせず、Chooser Documentの形でコード
リソースで提供し、Laser WriterやImage Writerと共
に、Chooser DAから選択可能にする。（ハ）S/P Client：S/P Clientドライバは、INIT−31メ
カニズムによって電源の立ち上げ時に自動的に自分自身
をSystemにインストールする。（ニ）MacTCP：このドライバは、[Control Panel Docum
ent]のリソースも有し、Control DAからIPアドレス等の
初期値をセットできる。（ホ）S/P Server：ＦＳＸサーバ側のプログラムであ
り、例えばＵＮＩＸのデーモンの形で常駐している。

【００３８】図８において、２０は市販のＤＴＰアプリ
ケーション、２１はOSに常駐しているPrintingManager
、２２はPrintTCP、２３はSP Client 、２４はMacTC
P、２５はイーサネットボード、２６はＡＤＣＴボード
の制御関数、２７はＡＤＣＴ圧縮ボード、２８はイーサ
ネットケーブル、２９はイーサネットボード、３０はＵ
ＮＩＸに常駐するTCP/IPプロトコル、３１はSP Server
、３２はCaPSL インタープリタ、３３はＡＤＣＴボー
ドの制御関数、３４はＡＤＣＴ圧縮ボード、３５はプリ
ンタである。２０から２５までがマッキントッシュ、２
９から３４までがＮＷＳＰである。２５と２９はケーブ
ル２８を介して通信機能を提供するハードウェアであ
る。実際の論理的通信路は、MacTCP２４とTCP/IP３０に
よって確保される。SP Client ２３とSP Server ３１
は、TCP/IPの提供する汎用の論理通信路上にEnd-to-End
で構築されるプリンタサーバクライアントプロトコルで
ある。このプロトコルの目的は、アプリケーション２０
にネットワーク（この場合はイーサネット）を意識させ
ずに、プリンタ３５があたかもローカルなコンピュータ
に接続されているかの様に見せる為のドライバである。
言い換えると、プリンタ３５はアプリケーション２０か
ら見ると、あたかもPrintingManager ２１の下に直接接
続されているかの様に見える。

【００３９】図９は、図８のコンピュータ側について、
OS３６との関わりをより詳細に説明した図である。図示
する様に、PrintingManager ２１はOS３６の一部を構成
している。２２と２３，２３と２４，２２と２６はDevi
ceManager ３７に媒介されて互いに通信する。PrintTCP
２２は、QuickDraw - CaPSL 変換部２２−１とPrinterD
river 部２２−２とに分かれ、２２−１はQuickDraw の
描画ルーチンをCaPSLコードに置き換えている所であ
る。これによってQuickDraw の代わりにCaPSL インター
プリタを有するSP SeverがQuickDraw をエミュレートで
きる。各ドライバをアプリケーションとしてではなく、
ドライバとして構成する最大のメリットは、インターフ
ェースがOS３６を介してつながるので、スペックが標準
化しやすいことである。また、マルチファインダーとは
言っても、事実上シングルタスクのOSの場合、ドライバ
化する事によって、その部分をマルチタスク化する事が
できる。例えばＵＮＩＸの場合には、文字どおり物理デ
バイスとのインターフェースのみをドライバ化し、あと
はデーモンとして簡単にバックグラウンドで走らせる事
ができる。＜SP Client ドライバの形式＞SP Client ドライバは、
INIT-31 メカニズムによって電源の立ち上げ時に自動的
に自分自身をシステム内にインストールする。ドライバ
のメモリ占有サイズが大きくなる時は、大部分のコード
はコードリソースの形で持ち、オープンされた時にリソ
ースをシステムヒープにロードする形式が望ましい。そ
の場合、Close時にメモリを開放する。ドライバ名はピ
リオド［．］で始まる。

【００４０】また、SP Client は［コントロールパネル
ドキュメント］のリソースも有し、コントロールパネル
から、ＩＰアドレス等の各種パラメータを設定できる。
そのため少なくとも以下に示す様なリソースを持ってい
る。ＤＩＴＬＩＤ＝−４０６４ｍａｃｈＩＤ＝−４０６４ｎｒｃｔＩＤ＝−４０６４ＩＣＮ＃ＩＤ＝−４０６４ＢＮＤＬＩＤ＝−４０６４ＦＲＥＦＩＤ＝−４０６４ｃｄｅｖＩＤ＝−４０６４＜SP Client ドライバのインターフェース＞SP Client
は、次のハイレベルデバイスマネジャールーチンを提供
する。

【００４１】DriverOpen DriverClose Control FSRead FSWite Status KillIO 上記標準ドライバインターフェースに無いSP Client の
サービスは、Controlルーチンが提供する。Control コ
ールのパラメータブロックの持つcs Code を所定の値に
設定する事によって、次の様な各種コマンドが利用でき
る。

【００４２】SPSetInit SPListen SPCapability Color_Space_Request Color_Space_List Color_Space_Select Color_Space_Select_Ack ＜コマンドの説明＞各種コマンドは、表１に示す通りで
ある。

【００４３】

【表１】

【００４４】＜パケットの形状＞ＳＰサーバ／クライア
ントプロトコルの一般的なパケットの形状は、図１０に
示す通りであり、図において左側の数字はバイト数であ
る。＜各パケットの機能＞そして、ＳＣＣＬパケットとＤＶ
ＣＬパケットの機能は、表２乃至表４に示す通りであ
る。

【００４５】

【表２】

【００４６】

【表３】

【００４７】

【表４】

【００４８】図１１〜図１２は、これらのパケット及び
コマンドのシーケンスを示す図である。図１１はクライ
アントとサーバ間でやり取りするフローに着目して書い
たものであり、図１２はクライアント側で、MacTCPとSP
Client の間のフローに着目して書いたものである。ア
プリケーションからは標準のファイルアクセスと同じ、
Open，Read，Write，Close のコマンドでアクセス出来
る様に設計している。まずアプリケーションからPrOpen
の関数を呼ぶと、SP Client にSPOpenコマンドが届く。
これにより、SP Client はConnect コマンドによってTC
PActivateOpen 関数を発行し、TCP/IPを接続する。SP C
lient は、関数の戻り値がnoErr であればTCP/IPの呼が
正常に確立したことを示す。SP Client は確立したＴＣ
Ｐリンクの上でSP Client ／SPServer 間のリンクを貼
るために、引き続きOpenConnパケットをSP Server に送
る。SP Server は、プリンタに問題がなければOpenConn
Reply を返してセッションリンクの成立を確認する。そ
の後、サーバ側に固有のパラメータを初期化するために
InitパケットとControl パケットを送り、次に色空間制
御のためにColor_Space_Request パケットを発行する。
その後のやり取りは、先に説明した通りである。これら
のSP Server ／SP Client パケットは、すべてTCP/IPプ
ロトコルのTCPSend またはTCPRv パケットによって伝送
される。

【００４９】＜応用例＞図１３及び図１４に本発明の応
用例を示す。図１３はＣＲＴモニタに画像情報を表示し
ているところを示している。同図において、５０はＣＲ
Ｔモニタ、５１は管面に正しいＮＴＳＣＲＧＢカラー
を表示するための補正された色信号、［Ｄ］は補正係数
マトリクス、５２は接続ケーブルである。この例の様
に、人間の目に正しくＲＧＢ信号を見せるためには、ガ
ンマ（γ）補正等の色補正を行う事が必要となる。図１
３では、この補正をコンピュータ側で行っている例であ
る。この様な補正をＣＰＵで行うのは時間がかかるの
で、通常はモニタ５０側で行うことになる。その様子を
図１４に示す。補正係数マトリクス［Ｄ］はモニタ側で
掛けられる。通常、モニタの色補正回路は、ハードウェ
アで構成するか、ＤＳＰ(Digital Signal Prosessor)の
様な特殊な高速なプロセッサで行うので、極めて高速な
処理が可能である。何れの場合でも、コンピュータ側か
ら見たＣＲＴは、従来はパッシブな受動デバイスであっ
て、与えたＲＧＢの信号を忠実に再現する努力を原って
いるだけであった。言い換えると、補正係数マトリクス
［Ｄ］は、ＣＲＴモニタ５０に含まれる専用の色処理系
であり、これをコンピュータが（設置調整の時は例外と
して）日常の使用時に頻繁にダイナミックに利用すると
いう概念はなかった。

【００５０】本発明に係るデバイスインディペンデント
な色処理方法を用いれば、インターフェースはあくまで
も仮想の標準色空間で渡しながら、実際には、式４や図
２で説明した様なスキャナ等の入力側の色補正係数を
も、画像信号とは別々にプロトコルで送る事により、コ
ンピュータの本体のＣＰＵでは画像処理のための演算を
一度もやらずにＣＲＴモニタに渡すことされ可能とな
る。その様子を式８に示す。［Ｆ］はスキャナ固有の色
特性を標準に合わせる補正係数、［Ｇ］はコンピュータ
内部での補正係数、［Ｄ］はモニタ固有の色特性を標準
に合わせるための補正係数である。ＣＲＴモニタが本発
明の様にアクティブなデバイスならば、式８の様に色補
正演算を最終デバイス内で一気に演算させることさえ出
来る。

【００５１】これによって、デバイスインディペンデン
トな概念を守りつつ、且つハードウェア資源を有効に利
用し、しかも高速で演算の累積誤差の少ない色処理系が
実現できる。このように、フィルタ演算をカスケードに
つなげて行って、最後に一気に演算するというアルゴリ
ズムが成り立つのは、［ＲＧＢ］，［ＸＹＺ］，［ＣＭ
Ｙ］，［ＹＩＱ］の様に、三原色（混色系）の色空間表
現の相互間の時に容易であり、［Ｌ^* ａ^* ｂ^* ］の様
に、ＸＹＺから計算によって求められた色空間表現（顕
色系）との間の変換では、やや困難であり、一旦その色
空間に変換した方が速い場合もある。

【００５２】＜色校正＞コンピュータ上で処理したカラ
ー画像を印刷する場合、ＣＲＴモニタ上の画像の色と、
印刷結果が正しく一致しているかどうかと言うことは、
印刷の専門家にとっては深刻な問題である。このため、
コンピュータでカラー画像を扱うシステムでは、次の方
法により、モニタとプリンタを校正している。

【００５３】モニタを校正する標準的な方法は、ＲＧＢ
の各色成分が“０”から“１００”まで変化するとし
て、まず［Ｒ，Ｇ，Ｂ］＝［１００，０，０］の信号を
入れて赤を表示し、それを分光光度計で測定する。測定
結果は［ＸＹＺ］で得られるので、これを計算で［ＲＧ
Ｂ］に変換し、［１００，０，０］になるように［Ｒ］
信号の利得を調整する。同様に［Ｒ，Ｇ，Ｂ］＝［１０
０，１００，１００］の信号を入力し、分光光度計の出
力が［１００，１００，１００］になる様に微調整をす
る。次に、［Ｒ，Ｇ，Ｂ］＝［７０，３０，３０］のご
とき中間色を入力して調整し、最後に白バランスとして
［Ｒ，Ｇ，Ｂ］＝［７０，７０，７０］を入力して調整
を完了する。プリンタについても、基本は同じである。
もちろん、これ以外にも色々なやり方がある。

【００５４】以上でモニタとプリンタが、それぞれ単独
に調整できたことになる。以後、この調整値はいじらな
い。ところが、これでもＣＲＴモニタとプリント結果が
異なることが普通である。印刷の専門家が深刻な問題で
あると感じるのは、ここからである。この問題を解決す
るための便法として、電子色見本が導入された。電子色
見本とは、印刷インキメーカーが、自社の代表的インキ
の印刷見本と同じ色がコンピュータ上でも得られる様
に、コンピュータ用の色見本（カラー画像データ）とセ
ットで供給しているものである。コンピュータ上でカラ
ー原稿を作成し、最終的にそれを印刷しなければならな
い時は、結局は電子色見本を参照しなければ正確な仕事
はできない。電子色見本は、アプリケーションの形で提
供されるか、市販の有名アプリケーションのドキュメン
トファイルとして本表とを一致させるために、アプリケ
ーションが持つ色相微調整機能を調整したくなる。しか
し、アプリケーションでこれを始めてしまうと、複数の
アプリケーションと複数のインキメーカー、複数の色見
本との組み合わせを考えると、すぐに収拾がつかなくな
る事が分かる。

【００５５】調整値の設定は、専用のユーティリティプ
ログラムで行っても、ＤＴＰアプリケーションを使って
行っても良い。ただし、調整結果はアプリケーションが
管理すべきではなく、デバイスドライバに引き渡してそ
れに管理させるべきである。さもなければ、アプリケー
ション毎、色見本毎に色調整を行わなければならなくな
る。実施例によれば、デバイスドライバに引き渡すカラ
ー画像信号は、仮想の標準カラーを渡す事ができるの
で、アプリケーション側で色合わせを行う必要はなく、
デバイスドライバ自身に行わせることができる。またデ
バイスドライバは色合わせの情報を、印刷メーカーのイ
ンキ毎にファイルにセーブして管理する。日本で入手可
能な電子色見本は３種類だから、これだけ切り替えられ
れば良い。そうすることによって、どんなアプリケーシ
ョンからでも同じ環境で色見本を参照可能になる。マッ
キントッシュの場合、デバイスドライバがｃｄｅｖリソ
ースを持つことができる。このメカニズムを用いれば、
アプリケーションを起動したままコントロールパネルか
ら色補正をかけることができ、しかも、いったん設定し
た設定値は全てのアプリケーションに共通となる。

【００５６】上述したデバイスインディペンデントな色
処理方法を用いれば、アプリケーションとデバイスドラ
イバが通信できるので、コントロールパネルを開くとい
う面倒な操作をしなくとも、アプリケーションから直接
デバイスドライバの設定値を制御できる。図１５にその
関係を示す。同図において、３はコンピュータ、６０は
プリンタ、６１はプリンタ６０を制御する為のデバイス
ドライバでコンピュータ３に常駐する。６２は特定の電
子色見本に対する校正データのファイル、６３は第２の
電子色見本に対する校正データのファイルである。各校
正データのファイルは、直接的にはデバイスドライバ６
１が管理、使用するが、間接的には図の様にアプリケー
ションが制御するものであっても良く、また例えばｃｄ
ｅｖから制御しても良い。

【００５７】以上述べたように、実施例におけるデバイ
スインディペンデントな色処理方法を用いれば、概念上
は仮想の標準色空間で渡すので、入力デバイスから受け
取った画像データを、常に標準色空間を基準に処理する
事ができ、実際にはそのような演算は行うことなく出力
デバイスに渡す事もできる。従って、演算の処理速度は
向上し、演算による丸め誤差の累積もなく、デバイスイ
ンディペンデントな概念を守りつつ、且つハードウェア
資源を有効に利用できる色処理系が実現できる。

【００５８】尚、本発明は、複数の機器から構成される
システムに適用しても、１つの機器から成る装置に適用
しても良い。また、本発明はシステム或いは装置にプロ
グラムを供給することによって達成される場合にも適用
できることは言うまでもない。

【００５９】

【発明の効果】以上説明したように、本発明によれば、
外部装置から受信した第１の色空間をデバイスインディ
ペンデントな色空間に変換する第１の色処理データと、
デバイスインディペンデントな色空間を第２の色空間に
変換する第２の色処理データとを合成して生成したパラ
メータを用いて入力カラー画像データを色空間変換し、
第２の色空間のカラー画像データを出力することによ
り、高精度な色処理を行うことができる。

【図面の簡単な説明】

【図１】実施例でのシステム構成を示す概略ブロック図
である。

【図２】実施例でのデバイスドライバ部分を説明するた
めの図である。

【図３】実施例でのデバイスインディペンデントな色空
間制御プロトコルである。

【図４】実施例での色空間制御プロトコルに用いるパケ
ットの構造図である。

【図５】実施例での色空間制御プロトコルに用いるパケ
ットの構造図である。

【図６】実施例での色空間制御プロトコルに用いるパケ
ットの構造図である。

【図７】実施例での色空間制御プロトコルに用いるパケ
ットの構造図である。

【図８】サーバ／クライアントシステムに応用した例で
ある。

【図９】クライアント側の詳細な構成図である。

【図１０】色空間制御プロトコルに用いる一般的なパケ
ットの構造図である。

【図１１】サーバ／クライアント間のシーケンスの例で
ある。

【図１２】クライアント側のシーケンスの詳細な例であ
る。

【図１３】モニタにおける色補正の例である。

【図１４】モニタにおける色補正の例である。

【図１５】色校正データの管理方法を示す図面である。

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04N 1/60 G06T 1/00 510 H04N 1/46 H04N 9/64

Claims

(57)【特許請求の範囲】

【請求項１】第１のデバイスに依存する第１の色空間
の入力カラー画像データを第２のデバイスに依存する第
２の色空間の出力カラー画像データに変換する色処理方
法であって、前記第１の色空間をデバイスインディペンデントな色空
間に変換する第１の色処理データを外部装置から通信回
線を介して受信し、前記第１の色処理データと前記デバイスインディペンデ
ントな色空間のカラー画像データを第２の色空間のカラ
ー画像データに変換する第２の色処理データとを合成す
ることによりパラメータを生成し、前記パラメータを用いて入力カラー画像データの色空間
変換を行い、第２の色空間のカラー画像データを出力す
ることを特徴とする色処理方法。
【請求項２】前記色空間は、ＲＧＢ，ＸＹＺ，ＣＭ
Ｙ，ＹＩＱの様な混色系の三原色であることを特徴とす
る請求項１に記載の色処理方法。
【請求項３】前記デバイスインディペンデントな色空
間は、標準の色空間（ＮＴＳＣＲＧＢ）であることを特
徴とする請求項１に記載の色処理方法。
【請求項４】前記生成するステップは、前記第１の色
処理データと、前記第２の色処理データに加え、更に前
記第２のデバイスの階調特性に応じた色補正に関する色
処理データを合成することを特徴とする請求項１に記載
の色処理方法。
【請求項５】前記受信するステップは、パケットに格
納された前記第１の色処理データを送信デバイスとのプ
ロトコルに基づき、受信することを特徴とする請求項１
に記載の色処理方法。
【請求項６】前記色空間変換は、第２のデバイスで行
われることを特徴とする請求項１に記載の色処理方法。
【請求項７】前記生成するステップは、第２のデバイ
スで行われることを特徴とする請求項１に記載の色処理
方法。
【請求項８】前記入力カラー画像データは、前記外部
装置から通信回線を介して、送信側とのプロトコルに基
づき、前記第１の色処理データとは独立に受信されるこ
とを特徴とする請求項１に記載の色処理方法。
【請求項９】第１のデバイスに所属する送信ユニット
と第２のデバイスに所属する受信ユニットとを有するカ
ラー画像処理システムであって、前記送信ユニットは、前記第１のデバイスに依存する第１の色空間を基準の色
空間に変換する第１のパラメータ及びカラー画像データ
を通信回線を介して前記受信ユニットに転送する転送手
段を有し、前記受信ユニットは、前記第１のパラメータと前記受信ユニットの基準の色空
間を第２のデバイスに依存する第２の色空間に変換する
第２のパラメータとを合成することにより第３のパラメ
ータを生成する合成手段と、前記第３のパラメータを用いて前記カラー画像データを
色空間変換する色空間変換手段とを有することを特徴と
するカラー画像処理システム。
【請求項１０】前記第１のデバイスは、スキャナであ
ることを特徴とする請求項９に記載のカラー画像処理シ
ステム。
【請求項１１】前記第２のデバイスは、プリンタであ
ることを特徴とする請求項９に記載のカラー画像処理シ
ステム。
【請求項１２】前記受信ユニットは、物理的な接続点
を介して画像処理装置と接続されていることを特徴とす
る請求項９に記載のカラー画像処理システム。
【請求項１３】第１のデバイスに依存する第１の色空
間の入力カラー画像データを第２のデバイスに依存する
第２の色空間の出力カラー画像データに変換する色処理
装置であって、前記第１の色空間をデバイスインディペンデントな色空
間に変換する第１の色処理データを外部装置から通信回
線を介して受信する受信手段と、前記第１の色処理データと前記デバイスインディペンデ
ントな色空間のカラー画像データを第２の色空間のカラ
ー画像データに変換する第２の色処理データとを合成す
ることによりパラメータを生成する生成手段と、前記パラメータを用いて入力カラー画像データの色空間
変換を行い、第２の色空間のカラー画像データを出力す
る色空間変換手段とを有することを特徴とする色処理装
置。