JP3529130B2

JP3529130B2 - 非常に大きな微細解像度画像のために、調整された印刷パラメータとともに、予備圧縮されたデータを無損失で送る方法および装置

Info

Publication number: JP3529130B2
Application number: JP2001229645A
Authority: JP
Inventors: ルカ・キャラビニ; ガロ・ギメネズ; ジョーディ・ヴィラー
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 2000-08-01
Filing date: 2001-07-30
Publication date: 2004-05-24
Anticipated expiration: 2021-07-30
Also published as: JP2002202869A; EP1178669A1

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は全般に紙などの印刷
媒体上に写真などの画像を順次印刷するための機器およ
び方法に関し、特に、（３．１より後の）Windows（登
録商標）環境で実行されるアプリケーション・プログラ
ムから、Postscript（登録商標）印刷装置（たとえば、
プリンタ、コピー機またはファクシミリ機器）へ、画像
データを高速且つ高い忠実度で伝送するための方法およ
び装置に関する。本発明は、非常に大きな、高解像度の
画像を作成するために、非常に大きな画像データファイ
ルから印刷する場合に特に有利である。

【０００２】

【従来の技術】（ａ）商業的な環境本質的にあらゆる芸術的品質の画像に対して、以下に説
明する技術的な環境と問題は、印刷画像品質の点から、
重要であり厄介である。しかしながら、印刷される画像
が非常に大きなときに、品質についての懸念は、速度す
なわち、処理量についての問題によってさらに重大なも
のとなる。

【０００３】たとえば、ポスターサイズ、たとえば５０
００ｃｍ^２以上の美術複製は、大変な仕事である。美術
館およびその他の画像所有者によって所有された著作権
で保護された画像を安全に配布するための最新のシステ
ムの詳細は、継続中の米国特許出願に示されている。

【０００４】上記のシステムにおいて、所有者は、画像
情報を印刷サービス・プロバイダ（printing service p
rovider）すなわちＰＳＰへ伝送する。ＰＳＰは、画像
データを受け取り、当該データをローカル印刷装置へ伝
送することができる電子サービス・システムを保持す
る。

【０００５】（ｂ）技術的な環境上記の処理の特に難しい側面は、ポスターサイズの美術
複製が画素レベルの莫大な量のデータに対応することで
ある。正確な量は、もちろん、正確な寸法と他の要因に
依存する。本明細書における説明の目的のために、一般
的に典型的なデータファイルは、百メガバイトのオーダ
である。

【０００６】興味深いことに、当該ファイルにおける主
要な困難性は、ゲートウェイからＰＳＰへのインターネ
ット伝送にはない。伝送されるデータの量は、Joint Ph
otographic Experts Group （ＪＰＥＧまたはＪＰＧ）
規格などの規格手続きを使用して、画像データファイル
圧縮によって扱いやすいレベルまで減少されるからであ
る。同様に、ＰＳＰのe-サーバからそれ自身のローカル
印刷装置への実際の伝送は、いくつかのプリンタ言語の
いずれでも、また、いまや比較的標準化された、たとえ
ば、よく知られたPostscript（登録商標）言語でも利用
可能な同様な圧縮によって、適当な時間内で行なうこと
ができる。

【０００７】むしろ、奇妙なことに、長距離（インター
ネット）伝送とローカル（サーバからプリンタ）伝送と
の間のインターフェースに、より大きな難題がある。以
下のように、データフォーマットの不適合の雑多なも
の、処理量についての高い需要、画像忠実度についての
非常に高い要請、種々のオペレーティング・システムお
よびアプリケーション・プログラム、および画像のトリ
ミング、サイズ変更、回転についての普通の事象の重な
りによって、ここでのボトルネックが形成される。

【０００８】このように、ハードコピー産業では、画像
圧縮は永続的な問題であり、容認できる出力品質を得る
ために、高解像度の画像を伝送し、処理し、印刷する必
要がある分野の大きなフォーマットの区分において特に
重要である。

【０００９】（ｃ）技術的な問題：開発されていない
「圧縮一致」このような問題は、「ＬＺＷ」（無損失）や直接コサイ
ン変換「ＤＣＴ」（有損失）のような、新しく、比較的
高い圧縮アルゴリズムの発明によって部分的にだけ解決
されている。「有損失」および「無損失」という用語
は、データ圧縮手続きにおいて生じる画像詳細情報の不
可逆的な損失を意味する。

【００１０】この分野において知られているように、デ
ータ圧縮が適切に且つ１回だけ行なわれるときは、この
ような損失は重要ではなく、データは後で、直接使用さ
れるために抽出される、すなわち「圧縮解除される」。
しかしながら,圧縮解除されたデータが再圧縮される
と、正確に同じアルゴリズムを使用し、名目上同じ圧縮
パラメータを使用しても、２回の圧縮の間の相互作用ま
たは干渉が通常起こる。

【００１１】このような干渉は、入力画像のブロックま
たはタイルについて行われる、一般にフーリエ変換に似
通った数学的に精巧な手続きである、ＤＣＴのような有
損失アルゴリズムの基本的な性質から生じる。

【００１２】ＤＣＴブロックによって表現される空間周
波数の内容は、画像を圧縮解除（すなわち、再構成）
し、それから再圧縮する試みによってひずみを受ける。

【００１３】圧縮の２回目における、ブロックへの画像
の分割が１回目における分割と少しだけ異なっている場
合には、特にそのことが当てはまる。色のシフトがしば
しば結果として生じ、より明らかな機械的なアーテファ
クト（artifact）も時々起きる。

【００１４】正確にはこのような状況は、長距離伝送と
ローカル伝送との間の、上記のインターフェースにおい
て存在する。根本的な問題は、全体データパスの両方の
区間で同じ圧縮アルゴリズムが使用されたとしても、長
距離伝送で使用されるファイルフォーマットが、ローカ
ル伝送で使用される印刷言語と正確に同じではないこと
である。

【００１５】したがって、印刷言語変換の部分として再
圧縮するのに先だって、長距離伝送されたファイルから
原画像情報を回復する作業において、データを圧縮解除
する必要がある。このような再圧縮の品質へのインパク
トを避けるために、研究者のあるものは、たとえば、全
ての非圧縮画像を印刷装置へ伝送するというような、非
常に好ましからざる解決策を考案している。

【００１６】この特別な解決策は、多分５０から１００
メガバイトの非圧縮データを伝送することを要求するの
で、時間の点から特に不都合である。視覚的にはほとん
ど同じ、圧縮された情報を表す典型的な数字は、２から
５メガバイトに過ぎないオーダである。

【００１７】より具体的には、上記の高圧縮アルゴリズ
ムは、たとえば、以下のようなファイルフォーマットと
印刷言語という、二つの調整されていない群に見えるい
くつかの産業規格に別々に組み込まれる。

【００１８】ファイルフォーマット印刷言語ＪＰＥＧＰＣＬＴＩＦＦＨＰＧＬ２ＧＩＦＰＳ（ここで「ＰＳ」は、"postscript" 言語を表す。）本
明細書では、この重要な事実を「圧縮一致」と呼ぶ。

【００１９】ファイルフォーマットと印刷言語は、この
ように、正確に同じ圧縮アルゴリズムを使用しているか
もしれないが、しかし、互換性はない。このことは、フ
ァイルフォーマットを考案した研究者と印刷言語を考案
した研究者が彼らの努力の結果を調整しなかったためで
あり、したがって、圧縮されたデータは、ファイルおよ
び印刷言語に非常に異なったやり方で組み込まれる。

【００２０】このように、ＪＰＥＧ、ＴＩＦＦまたはＧ
ＩＦのラスター画像を直接にPostscript装置へ送ること
は、Postscript装置が、印刷言語として、これらのフォ
ーマットをはっきりとサポートしない限り、従来可能で
はなかった。このようなはっきりしたサポートの努力の
いくつか（および、参考のために、ＪＰＥＧ規格の詳細
についても）簡単に説明する。

【００２１】ＪＰＥＧ画像をカプセル化するために一般
的なPostscriptファイルを使用することは、可能ではあ
るが、普通ではない。その理由は、アプリケーションや
画像ビュワーが、サポートされたフォーマットとしてＰ
Ｓファイルを適切に認識する能力を一般的に欠いている
からである。Postscriptファイルをプレヴューし操作す
るのは複雑な仕事である。

【００２２】結局のところ、産業の慣行と習慣の問題で
ある。Postscriptは、ＪＰＥＧ、ＴＩＦＦまたはＧＩＦ
のような、「移植性のあるラスター・ファイル」ではな
く、「印刷言語」と一般的に考えられ、一般的な事項と
して、産業界はこの不一致に、有意義な仕方で注意を向
けなかった。

【００２３】（ｄ）ＪＰＥＧプロセスの詳細ＪＰＥＧファイルとして入力画像を記憶する従来のプロ
セスは、スキャナ、デジタル・カメラまたはスクリーン
上のオリジナル・アートのような何らかのソース１１
（図１）からの情報で始まる。この情報は、通常は、Ｒ
ＧＢビットマップとして表現されてもよいが、必ずしも
その形式でファイルとしてセーブする必要はない。

【００２４】ビットマップ１２は、その後、放送ビデオ
分野ではよく知られている、輝度クロミナンス「ＹＵ
Ｖ」空間における等価な表現１４を得るように、変換プ
ロセス１３を通過する。この時点まで、データは、それ
ぞれ、画像画素と関連した個々の色空間値として表現さ
れ続ける。

【００２５】つぎに、ＹＵＶデータは、画素のブロック
のための変換値１６を作成するように、離散コサイン変
換（ＤＣＴ）を受ける（１５）。それでも、この時点ま
では、両方向矢印１７で示されるように、プロセスは可
逆的であると明確に考えられる。

【００２６】変換値１６は、原データのコサイン展開に
おける係数である。ほとんど損失なく変換値１６から原
情報を再構成することができるように、最初に、すなわ
ち、この段階で、全ての係数は最大限の精度で表現され
る。

【００２７】このため、これらの最初のステップ１２か
ら１６は、「無損失」と呼ばれる。しかしながら、次の
処理ステップ２１において、二つの重要な変化が起き
る。

【００２８】ＤＣＴ係数は、種々の係数の相対的な重要
度を判定するように解析される。

【００２９】この判定に基いて、ＤＣＴ情報の非常に大
きな部分が通常捨てられる。

【００３０】「捨てる」という語は、この文脈におい
て、本質的に、選択されたデータの切捨て(truncation)
の巧妙なプロセス、相対的に重要でないとして選択され
た値の選択された数の下位の桁を効果的に落とすことを
指す。

【００３１】物理的には、係数の解析は、画像における
種々の空間周波数の相対的な重要性を判定することに対
応する。この解析によって、表現される画像の視覚的な
忠実度をほとんど損なわないようにしながら、それぞ
れ、種々の周波数の相応して変化する部分を、適切に保
持し、（実際には、切捨てにより）捨てることが可能と
なる。

【００３２】換言すれば、データを捨てる機能は、種々
の係数が記憶される精度の程度を相応して調整すること
によって行なわれる。必ずしも、全データ値ではなく、
より一般的には、各値の変化する部分が、このように、
選択的に保たれるかあるいは放棄される。

【００３３】相対的な重要性の判定は、いわゆる「量子
化テーブル」に記録される。これらのテーブルによっ
て、後で、係数を正確に解釈することができ、したがっ
て、保持されたＤＣＴ係数から、後で、物理的に意味の
あるように、画像を再構成することができる。

【００３４】重要性の解析と精度の切捨てを含むステッ
プ２１の後、結果としてのデータ２２は、量子化テーブ
ルとＤＣＴ係数１６の保持された部分だけとからなる。
情報１６のかなり大きな部分が捨てられ、すなわち失わ
れたので、解析し捨てるステップ２１は、「有損失」と
呼ばれる。

【００３５】したがって、このステップは、完全に可逆
的ではない。この不可逆性は、下部の破線の両矢印の隣
に示されている。

【００３６】このプロセスによって得られる圧縮の量
は、非常に重要であり、通常１０パーセントより大き
く、しばしば、９０パーセント以上である。それにもか
かわらず、精巧な選択プロセスのために、残ったデータ
２２によって表現される画像は、通常、視覚的には原画
像と区別することができない。

【００３７】この重要な前提には、重要な制限がある。
本発明を十分に評価するには、データの空間周波数の特
徴が、特に、後で試みられる圧縮解除および再圧縮を含
む、後続の全てのプロセスにおいて、十分に考慮されな
いと、この前提は成り立たないことを認識するのがきわ
めて重大である。

【００３８】量子化テーブル、保持されたＤＣＴデータ
およびクリティカル・パラメータは、その次に、「ハフ
マン符号化」と呼ばれる更なる圧縮段階２３へ移る。こ
の段階で、通常、１０パーセントより小さい、追加的な
少量のデータ圧縮が適用される。このように、ハフマン
符号化は、ＤＣＴデータおよびテーブルからなるファイ
ルをジップするのに似通ったものである。

【００３９】保持されたＤＣＴ係数および対応する量子
化テーブルをハフマン符号化する（２３）ことによっ
て、最終的なＪＰＥＧファイル２４が作成される。この
ステップ２３も、解析し捨てるステップ２１に先行する
ステップ１１から１６と同様に、両方向矢印２７で示さ
れるように無損失である。

【００４０】ＪＰＥＧファイル２４の付加的な要素は、
通常白黒画像で１かカラー画像で３である、色平面の数
と、各平面の高さと幅とともに単位距離あたりの解像度
と平面ごとの全体解像度とを含む、（図１には示されて
いない）クリティカル・パラメータブロックである。後
で分かるように、これらのデータは、画像情報と幾分か
分離して最もうまく処理される。

【００４１】ＪＰＥＧシステムは、優れて効果的で有用
であるが、アート品質の複製作業を試みる場合には、上
記の制限は非常に重要である。既に説明したようにデー
タの完全性の重大な問題を呈する、上述の環境において
は、特にこのことが当てはまる。

【００４２】（ｅ）ＤＯＳおよびＵｎｉｘ(登録商標)の
旧来のアプリケーションこれらの問題を緩和するのに適切なコア概念は、長年知
られていた。ＵｎｉｘおよびＤＯＳは、まだ広く使用さ
れている最も古いオペレーティング・システムであり、
これらのシステムにおいては、プリンタととともに機能
する場合には、アプリケーションは、それ自身のプリン
ト言語を生成できるばかりか生成する必要がある。

【００４３】このようなアーキテクチャにおいては、印
刷言語出力に、圧縮したラスター・データを直接組み込
んで画像ファイルを利用するのは簡単である。Ｕｎｉｘ
およびＤＯＳは、旧来のオペレーティング・システムで
あるから、また、多分ある場合には、理解不足から、本
発明者が知る限り、プリンタへ画像ファイルを送る場合
に、ラスター・データ予備圧縮を活用しているＤＯＳま
たはＵｎｉｘアプリケーションは非常に少ない。

【００４４】いずれにしろ、現在のパーソナル・コンピ
ュータ産業において支配的なオペレーティング・システ
ムは、Windowsである。プリンタ伝送において予備圧縮
画像を含んでいたＤＯＳまたはＵｎｉｘアプリケーショ
ンであっても、Windowsの下で、あるいはWindowsと連携
して機能し、ＰＳ印刷装置へ画像データを送ることを求
められる多くのアプリケーションのニーズに対する実行
可能な解決策を示しているとはみなすことはできない。

【００４５】（ｆ）主要なオペレーティング・システム MacintoshとWindowsのオペレーティング・システムは、
印刷言語またはプリンタについてほとんど知識がなくと
も、アプリケーションに印刷する資格を与え、印刷でき
るようにする印刷ドライバ・アーキテクチャを提供す
る。これらのシステムにおいて、画像を印刷するのに、
アプリケーションは、オペレーティング・システムに図
形要素(graphics primitives)を送り、オペレーティン
グ・システムは、印刷ドライバにドライバ要素(driver
primitives)を送ることによって応答する。

【００４６】ドライバは、つぎに、最後に印刷装置に送
られる印刷言語を生成する。このようなアーキテクチャ
は、汎用性を促進し、それによって多岐にわたる装置の
使用を容易にする点で有益である。

【００４７】しかしながら、このアーキテクチャは、
（１）オペレーティン・グシステムによって、特にサポ
ートされ、（２）アプリケーションによって、特に使用
され、（３）ドライバによって、特にサポートされない
限り、予備圧縮した画像データに基いて、画像を効果的
且つ忠実に複製するのを妨げる。Macintoshのオペレー
ティング・システムもWindowsのオペレーティング・シ
ステムも、従来より、予備圧縮した非テキストのラスタ
ー・データの管理を効率的に使用することをサポートし
ていなかった。いくつかのアプリケーションは、ＪＰＥ
Ｇ、ＴＩＦＦまたはＧＩＦファイルを印刷することがで
きるが、これらの全てのアプリケーションは、システム
・メモリにおいてデータを圧縮解除し、オペレーティン
グ・システム・コールによってそのデータを転送し、印
刷ドライバが、データを印刷装置へ送る前にラスター・
データを再圧縮するのをあてにする。

【００４８】インターフェースにおいて、速度と忠実度
の上述した障害を引き起こすのは、まさにこのようなオ
ペレーティング・システムである。欠点には以下のもの
がある。

【００４９】この標準的なアプローチは、全体として不
必要な、複雑な圧縮解除および再圧縮アルゴリズムをホ
スト・コンピュータにおいて機能させる必要があるの
で、非常に高い性能ペナルティをこうむる。

【００５０】これらのステップの間、データは非圧縮で
あり,その状態で管理される必要があるので、なお、メ
モリと処理時間の更なる投入が要求される。

【００５１】非圧縮のデータを大量に操作するためのメ
モリの要請は、通常、ホスト自身に悪い影響を与え、ホ
ストはしばしば、スワッピング・モ−ドにはいり、挿入
ジョブ（episodes）の大部分において、完全に失敗（ク
ラッシュ）するかまたはユーザへ警告することなくデー
タを改悪する。

【００５２】ある場合には、よりとらえにくい障害であ
り、ホストは、有損失再圧縮を防止し、結果として、時
間に多大な犠牲を払って、本質的にフルサイズのファイ
ルを印刷装置へ伝送する。これは、ユーザにとっては受
け入れることができない。

【００５３】汎用印刷ドライバは、原ラスター・データ
の性質について情報を持たないので、（写真のような画
像にだけ適する）有損失圧縮方式を安全に使用してもよ
いか、（チャート、グラフおよびテキストによい）無損
失方式を使用すべきかについて合理的に工夫することが
できない。

【００５４】ドライバが、写真のような画像を他のタイ
プのラスター画像から安全に区別できるとしても、以前
に有損失圧縮され（圧縮解除された）画像に有損失圧縮
を適用することは、画像品質にたびたび悪い影響を与え
る。すなわち、以前に言及したように、一度圧縮解除さ
れたデータの有損失再圧縮によって、画像欠陥が導入さ
れる。圧縮比を当初のものの近くに設定すると、受け入
れることのできないアーテファクト（artifact）と色の
シフトが通常生じる。

【００５５】全体として、通常の結果は、当初高圧縮さ
れた内容はいずれも、再圧縮を達成するために、ホスト
上の多量の処理を要求することである。さらに、この圧
縮はしばしば不完全に行なわれ、性能に悪影響を与え
る。

【００５６】（ｇ）予備圧縮されたファイル・フォーマ
ットのための直接のプリンタ・サポート上述の状況に応じて、ＪＰＥＧやＴＩＦＦなどの最も普
通のファイル・フォーマットに対する直接のサポート
が、競争の激しい市場の最高級のプリンタのファームウ
ェアにごく最近追加された。このようなプリンタは、Ｔ
ＩＦＦファイルやＪＰＥＧファイルを直接受け取り、印
刷することができる。このような構成は、長距離伝送と
印刷のためのローカル伝送との間にインターフェースが
ある場合に、上述の効率と品質の問題を理論的に解決す
る。しかしながら、実際問題として、これらの解決策に
は、非常に小さな有用性しかない。その理由は、上記の
構成は、印刷媒体に現れる画像のサイズ、方向および位
置に対して、ほとんど何も制御を行なわないからであ
る。ほとんどのユーザは、画像をトリミングしたりスケ
ール決めし、媒体に対して回転したり、移動したりする
ことができることを期待する。

【００５７】（ｈ）ベクトル・グラフィクスとテキスト正しくない方向に行ってしまったと思われる特に奇妙な
試みは、WindowsのためのAdobe Photoshop（登録商標）
およびCornel Draw（登録商標）と表される。これらの
アプリケーションは、非常に強力な基礎から出発し、印
刷ドライバをバイパスし、高圧縮された印刷言語を直接
生成することによって、部分的に問題を解決する。

【００５８】さらに、これらのアプリケーションは、圧
縮されたＰＳデータを直接生成する特別なモードを提供
する。さらに、Windowsにおいて機能するこれらのアプ
リケーションは、プリンタと通信する特別のコンジット
を活用する。

【００５９】「Postscript パススルー(Postscript pas
sthrough)」として知られるこのコンジットは、マイク
ロソフト（登録商標）によって何年も前に実施された標
準の機構であり、したがって、Windowファミリの全ての
オペレーティング・システムの下でサポートされ、さら
に、全てのPostscriptドライバによって従来からサポー
トされている。この機構は、実際、Postscriptドライバ
をバイパスして、Postscriptファイルを直接生成できる
ように、同じアプリケーション・ベンダによって要求さ
れた。

【００６０】Postscriptパススルーを開発するための特
に大きな動機は、ベクトル・グラフィクス（Cornel Dra
wの基本特性）およびテキストをプリンタに送るのを容
易にすることであったが、個々の色修正を適用するの
に、（特にPhotoshopによって）このパススルーは有効
に使用されてきた。

【００６１】これらのアプリケーションは、このよう
に、すばらしい出発である。しかしながら、残念なこと
に、これらのアプリケーションは、予備圧縮された非テ
キスト・ラスター・データを処理するときにいくつかの
優れた、組み込まれた利点を結局活用していない。

【００６２】より具体的には、これらのアプリケーショ
ンは、当初に予備圧縮されたデータを利用していないの
で、印刷プロセス中に不必要に品質低下を生じる。たと
えば、PhotoShopは、当初のＤＣＴ圧縮ファイルから読
み込んだ後、メモリにロードされた圧縮解除されたデー
タにそれ自身のＤＣＴ圧縮アルゴリズムを適用する。Co
rnel Drawは、組み込んだ予備圧縮ビット・マップを含
むベクトル・グラフィクス・ファイルを印刷するとき
に、このように含まれた、圧縮されていないビット・マ
ップを記憶し、伝送してもよい。

【００６３】（ｉ）最近のＯＳの革新これらの問題点を克服するために、有力なオペレーティ
ング・システムの最新版（MacOS8.6およびWindouws200
0）は、オペレーティング・システムによってＤＣＴ圧
縮画像を送る際に、アプリケーションによって使用され
る機構を導入した。しかし、これらの新しい特性を使用
するアプリケーションまたはドライバは非常に少ない。

【００６４】Macintosh 用のPageMakerは、新しいPosts
criptドライバによって、ＤＣＴ圧縮画像を効率的に印
刷することができる。PageMakerは、２００メガバイト
ではなく、２メガバイトだけを処理し伝送するために、
他のシステムが５０分かかるものを多分１０分で完成さ
せるので、ＰＳＰで非常に評判がよくなった。

【００６５】Macintoshのオペレーティング・システム
の改定は、およそ２年前にこのタイプのオペレーション
を許容した。しかしながら、PageMakerの最新版であっ
ても、Windouwsにおけるこのような機能をまだ提供して
いない。

【００６６】Windouws2000で提供される新しい機構は、
ＪＰＥＧファイルをサポートするだけである。すなわ
ち、ＴＩＦＦおよびＧＩＦデータは、なお、以前と同じ
問題を呈している。

【００６７】さらに、これらの開発は、対応するオペレ
ーティング・システムと印刷ドライバの最新版の下での
み、効率的な予備圧縮データ印刷を提供する。すなわ
ち、旧来の製品には、対応できる機構が提供されない。

【００６８】

【発明が解決しようとする課題】（ｊ）結論予備圧縮された非テキスト・ラスター・データを処理す
る際の、新しいシステムの困難は、特に非常に大きな画
像だけではなく、高速、且つ一様に優秀な順次印刷を達
成することを妨げつづけている。このように、本発明の
分野において使用される技術の重要な態様は、有効に改
良できる。

【００６９】

【課題を解決するための手段】本発明は、そのような改
良を導入する。好ましい実施形態において、利点を最適
化するために一緒に採用するのが好ましいが、独立に採
用できるいくつかの態様または側面を有する。

【００７０】側面または態様の最初のものの好ましい実
施形態において、本発明は、印刷装置を制御するWindou
wsオペレーティング・システムを使用する、画像を印刷
するための方法である。印刷は、有損失予備圧縮非テキ
スト・ラスター画像データに基いている。

【００７１】本方法は、有損失予備圧縮非テキスト・ラ
スター画像データを受け取るステップを含む。本方法
は、また、印刷装置によって期待されるファイル仕様フ
ォーマットに合わせるように当該データを調整するステ
ップを含む。

【００７２】調整は、有損失再圧縮なしで行なわれる。
更なるステップは、またも、有損失再圧縮なしで、Wind
ouwsオペレーティング・システムを経由して印刷装置
に、調整したデータを渡すことである。

【００７３】以上は、本発明の第１の態様または側面の
記述または定義を、最も広く、すなわち最も一般的な形
で表現する。しかしながら、このような広い用語で表さ
れていても、本発明のこの側面は、従来技術を重大に進
めることが分かる。特に、有損失手続きなしにデータ調
整を挿入することによって、本発明は、ファイル・フォ
ーマットと印刷装置言語との間の圧縮フォーマットの一
致を最大限に利用することができる。より具体的には、
本発明は、入力データのフォーマットを印刷装置が要求
するものに調和させる機会を捕らえる。

【００７４】同時に、圧縮解除／再圧縮のいくつかの欠
点、すなわち、品質退化、多量のデータ処理の要請およ
び遅延を避けるために、本発明は最適化することができ
る。特に、品質に関して、ドキュメント全体を無差別に
ＪＰＥＧ再符号化する所定のアプリケーションよりも、
本発明はかなりよく機能することができる。

【００７５】本発明の第１の主要な態様は、このよう
に、従来技術からかなり進んだものであるが、利点を最
適に享受するためには、本発明は、更なる特性または特
徴とともに実施されるのが好ましい。特に、本発明の方
法は、受け取るステップの後に、受け取った画像データ
が圧縮された非テキストデータであるかどうかを判定す
るステップを含むのが好ましい。

【００７６】画像データが圧縮された非テキストデータ
であれば、本方法は、調整するステップおよび渡すステ
ップへ進む。そうでなければ、これらの２ステップは省
かれ、画像データは代わりに、アプリケーション・プロ
グラムで確立された手続きにしたがって、印刷装置へ送
るために準備される。それぞれ、渡されるか、または準
備された画像データは、印刷装置へ中継され、その後、
画像が印刷装置で印刷される。

【００７７】さらに、基本的に好ましいことは、調整す
るステップが、望ましい印刷パラメータを処理すること
である。この場合に、副次的に好ましいことの一つは、
パラメータが画像回転、トリミングまたはサイズ変更の
ためのものであることであり、他の副次的に好ましいこ
とは、パラメータが色平面の数、色平面別の、画像高さ
および幅、または、色平面別の、単位距離あたりの解像
度であることである。

【００７８】さらに、基本的に好ましいことは、渡すス
テップが、Windowdsオペレーティング・システムにおけ
るPostscriptパススルー・エスケープ(Postscript pass
through escape)を使用するサブ・ステップを含むこと
である。さらに、他のものは、渡すステップが、印刷の
ために、調整した圧縮画像データを直接印刷装置ドライ
バへ送り、また、当該印刷装置ドライバから印刷装置へ
画像データを伝送するサブ・ステップを含むことであ
る。他のものは、受け取るステップ、調整するステッ
プ、渡すステップが印刷制御アプリケーション・プログ
ラムによって行なわれることである。

【００７９】さらに、基本的に好ましいことは、受け取
るステップと調整するステップとの間に、受け取ったデ
ータに無損失圧縮解除を適用するステップと、調整する
ステップと渡すステップとの間に、調整したデータに無
損失再圧縮を適用するステップとを含むことである。こ
の場合に、本方法が、ＤＣＴ係数と量子化テーブルを有
するＪＰＥＧデータである画像データとともに使用され
る場合は、本方法は、二つの無損失の適用ステップの間
に、システム・スワップ・ファイルではない一時ファイ
ルにＤＣＴ係数と量子化テーブルとを記憶するステップ
を含むのも好ましい。

【００８０】一時ファイル記憶ステップが行なわれる場
合、印刷のために画像を回転することが望ましければ、
記憶するステップが、係数間の交換を実現するために、
データ構造において、対称性を活用することを含むこと
がさらに好ましい。このような交換は、特に、テーブル
における垂直次元と水平次元との間で係数をスワップす
るのに使用されると、印刷される画像を回転させる効果
を有することができる。

【００８１】通常、必ずではないが、これらは、本質的
に基本的なマトリクス回転プロセスであり、係数それ自
体の再計算を何らすることなく回転を達成する。回転さ
せた画像の縦横比を修正するように、再スケーリングす
るような、関連する少量の計算が要求されることがあ
る。

【００８２】第２の主要な独立した側面または態様の好
ましい実施形態において、本発明は、また、予備圧縮さ
れた非テキスト・ラスター画像データに基いて、画像を
印刷するための方法である。本方法は、印刷装置を制御
するWindowdsオペレーティング・システムを使用する。

【００８３】本方法は、予備圧縮された非テキスト・ラ
スター画像データを受け取るステップを含む。更なるス
テップは、Windowsオペレーティング・システムのPosts
criptパススルー・エスケープによって、受け取ったデ
ータを印刷装置へ渡すことである。

【００８４】以上は、本発明の第２の態様または側面の
記述または定義を、最も広く、すなわち最も一般的な形
で表現する。しかしながら、このような広い用語で表さ
れていても、本発明のこの側面は、従来技術を重大に進
めることが分かる。特に、Postscriptパススルーを使用
することによって、本発明は、旧来のコードを含む実際
上あらゆる種類の原アプリケーション・プログラムに適
する戦略を呼び出す。これは、上述のように、上記パス
スルーがほとんど全てのタイプのPostscript適合アプリ
ケーションからのデータを受け取るからである。

【００８５】本発明の第２の主要な態様は、このよう
に、従来技術からかなり進んだものであるが、利点を最
適に享受するためには、本発明は、更なる態様または特
徴とともに実施されるのが好ましい。特に、渡すステッ
プは、受け取ったデータの有損失再圧縮を含まないこと
が好ましい。

【００８６】本発明の第１の主態様に対して上記された
その他の好ましいことは、ここでも当てはまる。たとえ
ば、受け取ったデータが圧縮された非テキスト・ラスタ
ー・データであるかどうかを判定し、それにしたがって
進むことなどである。また、上述のように、本発明の本
主要な側面は、本明細書の本項に記述された他の主要な
態様と一緒に実施されるのが最もよい。

【００８７】第３の主要な独立した側面または態様の好
ましい実施形態において、本発明は、予備圧縮された非
テキスト・ラスター・データに基いて、印刷媒体上に画
像を印刷するための印刷装置である。印刷は、Windowds
オペレーティング・システムの制御下で行なわれる。

【００８８】印刷装置は、Postscript印刷言語インター
プリタを実行するプログラム化されたプロセッサを含
む。印刷装置は、また、予備圧縮された非テキスト・ラ
スター・データをプロセッサに受け取るためのデータ・
チャネルを含む。

【００８９】データ・チャネルは、Windowsオペレーテ
ィング・システムのPostscriptパススルー・エスケープ
によって、画像データを受け取るためのものである。印
刷装置は、また、プロセッサによって制御される、画像
を媒体上に記録するための印刷ハードウェアを含む。

【００９０】以上は、本発明の第３の態様または側面の
記述または定義を、最も広く、すなわち最も一般的な形
で表現する。しかしながら、このような広い用語で表さ
れていても、本発明のこの側面は、従来技術を重大に進
めることが分かる。

【００９１】特に、印刷装置プロセッサは、Postscript
言語の中にデータを受け取り、具体的には、標準のパス
スルー・エスケープによって受け取るので、印刷装置
は、非常に広い範囲のアプリケーションからだけではな
く、Windows95, 98, NTおよび2000を含む新しいWindows
オペレーティング・システムいずれの下でも、最大の速
度と忠実度で画像データを受け取ることができる。

【００９２】本発明の第３の主要な態様は、このよう
に、従来技術からかなり進んだものであるが、利点を最
適に享受するためには、本発明は、更なる態様または特
徴とともに実施される。特に、受け取りチャネルは、印
刷装置ドライバを含むのが好ましい。当該ドライバは、
Windowsオペレーティング・システムにおいて機能し、
予備圧縮された非テキスト・ラスター・データをPostsc
riptパススルー・エスケープによって受け取り、画像デ
ータを印刷装置へ伝送する。

【００９３】第４の主要な独立した側面または態様の好
ましい実施形態において、本発明は、Postscript印刷装
置ドライバである。当該ドライバは、コンピュータ・ホ
ストを管理するWindowsオペレーティング・システム内
で実行するためのものであり、印刷装置が画像を印刷す
るのを制御するためのものである。

【００９４】再び、印刷は、予備圧縮された非テキスト
・ラスター画像データに基く。当該ドライバは、コンピ
ュータ・ホストにおいてドライバを保持する不揮発性メ
モリを含む。

【００９５】また、Windowsオペレーティング・システ
ムにおいて、予備圧縮された非テキスト・ラスター・デ
ータをPostscriptパススルー・エスケープによって受け
取るための第１のデータ・チャネルが含まれる。さら
に、当該ドライバは、受け取ったデータを印刷装置へ送
るための第２のデータ・チャネルを含む。

【００９６】以上は、本発明の第４の態様または側面の
記述または定義を、最も広く、すなわち最も一般的な形
で表現する。このような広い用語で表されていても、本
発明のこの側面は、従来技術を重大に進めることが分か
る。

【００９７】特に、基本ドライバ、その特に汎用的なデ
ータ・チャネルおよび予備圧縮された非テキスト・ラス
ター画像データの流れの組合せは、非常に強固な（robu
st）情報管理機能を提供する。すなわち、この全体ドラ
イバ・アーキテクチャを使用するＰＳＰの能力は、上流
のアプリケーション・ソフトウェア、下流のハードウェ
アおよび画像データ・ソースの変化に対して格段に耐性
がある。

【００９８】本発明の第４の主要な態様は、このよう
に、従来技術からかなり進んだものであるが、利点を最
適に享受するためには、本発明は、更なる態様または特
徴とともに実施される。特に、本発明のこの第４の態様
は、上述した本発明の最初の三つの主要側面とともに実
施されるのが好ましい。

【００９９】本発明の上記の機能原理および利点の全て
は、添付の図面を参照しながら以下の詳細な説明を考慮
して、より完全に認識することができる。

【０１００】

【発明の実施の形態】１．概要本発明の好ましい実施形態は、本明細書の「従来の技
術」の項に記述された「圧縮一致」を利用して、非互換
性問題を克服し、高度に圧縮されたラスター画像を効率
的に印刷することを可能にする。この解決策によって、
ＪＰＥＧファイル、ＴＩＦＦファイルおよびＧＩＦファ
イルをうまく印刷することができるが、他のフォーマッ
トにも同様に使用できる。

【０１０１】特に大型フォーマット印刷の領域におい
て、本発明の好ましい実施形態は、Windowsアプリケー
ションによって使用される標準のアプローチに対して格
段の性能改善をもたらすことが判明した。これらの実施
形態は、大容量のデータを、当初の圧縮されたフォーマ
ットで印刷装置へ送ることによって、複雑な圧縮解除ア
ルゴリズムを実行すること、すなわち、複雑または有損
失の再圧縮を避ける。

【０１０２】ホスト（アプリケーションまたはドライ
バ）において高い処理能力は要求されず、データ転送に
対しては小さな帯域幅が要求される。したがって、本解
決策は、高容量、オンデマンド印刷生産に特によく適し
ており、本発明によって、ハードコピー装置の能力によ
ってのみ制限される最大処理量が提供される。

【０１０３】好ましい実施形態によって、ＪＰＥＧ、Ｔ
ＩＦＦおよびＧＩＦＦフォーマットにおけるプロ級の高
解像度のラスター・ファイルが、どんな現在のPostscri
ptレベル２ドライバによっても効率的に印刷される。こ
のことは、（Windows3.1より上の）Windowsオペレーテ
ィング・システムのどのバージョンの下でも当てはま
る。

【０１０４】標準のWindowsアプローチであっても、本
好ましい実施形態であっても、当初の予備圧縮された２
メガバイトＪＰＥＧラスター・ファイルを印刷するため
に、第１のステップは、アプリケーションにおいて当初
の予備圧縮されたファイルを開くことである。換言すれ
ば、当該当初の２メガバイトファイルは、メモリにロー
ドする必要がある。その後、これらのデータは、ハフマ
ン圧縮解除され（思い出されるとおり、これは可逆的な
無損失プロセスである。）、最後には、出力はハフマン
再圧縮される。

【０１０５】しかしながら、二つの比較的平凡なハフマ
ン段階の間において、二つのプロセスには重大な差異が
ある。標準のWindowsアプローチにおいて、そのファイ
ルを印刷するために間に起こるステップは、以下のとお
りである。ＪＰＥＧ圧縮解除する。恐らく１００メガバ
イトをメモリに置く。Postscript出力を生成する。有損
失再圧縮であり、２００から３００メガバイトをメモリ
またはディスクに置く間に、色のシフトや画像アーテフ
ァクトを導入する。印刷装置へ送る。入出力、５０から
１００メガバイトのデータ転送である。

【０１０６】他方、本発明においては、同じファイルを
印刷するために、間に起こるステップは、以下のとおり
である。Postscript出力を生成する。変換し、メモリま
たはディスクにおける当初のおよび変換された２から４
バイトだけを処理する。印刷装置へ送る。入出力、２メ
ガバイトのデータ転送である。時間がかかり、帯域幅を
要求する圧縮解除および再圧縮ステップが省かれ、メモ
リおよびディスク記憶の要請が１桁以上小さくなるばか
りでなく、それに加えて、有害な画像品質の影響が完全
に避けられる。

【０１０７】当初の高度に予備圧縮されたデータは、圧
縮解除されることも、有損失再圧縮を受けることもな
い。その代わりに、当該データは、変換だけされ、その
後、印刷ドライバ出力に直接組み込まれる。

【０１０８】当該変換は、（先の従来の技術の項で記述
した）ＤＣＴ係数または量子化テーブルの解釈または再
評価を含まない。むしろ、これらのデータ・ブロック
は、以下で説明するように、回転を要求され多場合に
は、せいぜい、配置転換される。

【０１０９】ホストにおける処理能力要請は、ＪＰＥＧ
圧縮解除および再圧縮を避けることによって、一般的に
減少される。入力および出力データ速度は、当初のラス
ター・データの有損失対無損失圧縮比率によって高めら
れる。

【０１１０】Postscript印刷装置は、ジョブを完全に受
け取った後でのみ印刷を開始するので、これらの改良点
は、全体の印刷時間を減少させる。さらに、いずれかの
有損失アルゴリズムのアプリケーションによって、当初
の画像をいじらないので、本発明の動作は、印刷品質に
退化させる影響をまったく与えない。

【０１１１】本好ましい実施形態は、全く、装置から独
立している。さらに、色調整、ハードコピー制限、ジョ
ブ設定などの全てのPostscriptドライバ設定は、保存さ
れる。

【０１１２】２．ＰＯＳＴＳＣＲＩＰＴデータ一致およ
びパススルー好ましい実施形態は、ＪＰＥＧ、ＴＩＦＦ、ＧＩＦなど
の、当初のＤＣＴまたはＬＺＷ圧縮ファイルを効率的に
印字する。本発明は、標準のPostscript印刷言語（レベ
ル２以上）と、基本的に同じ圧縮アルゴリズムが、これ
らのファイル・フォーマットにおいて使用されていると
いう事実を活用する。

【０１１３】本発明の好ましい実施形態によれば、アプ
リケーション３２（図２）は、データ、たとえば、図１
に示すように最初に準備された、ＪＰＥＧまたは類似の
予備圧縮ファイル２４を読み込む（３１）。このファイ
ルは、ＪＰＥＧファイルの場合には、図１の量子化テー
ブルおよび保持されたＤＣＴデータ２２に一般的に対応
する、画像データ４３を含む。

【０１１４】このようなファイルは、本発明の好ましい
実施形態によって解析されるマーカを含む。重要でない
マーカは除去される。

【０１１５】つぎに、システムは、Postscript言語仕様
に合う、単にフォーマットし直されたバージョン５３を
作成するように、画像データ４３を適切に調整する（４
４）。このプロセスは、当初の予備圧縮されたラスター
・データ２４,４３の完全な圧縮解除または再圧縮のい
ずれかよりもずっと効率的な、データ変換プロセスであ
る。

【０１１６】好ましい実施形態は、特別なWindowsのエ
スケープ（escape）５５,６７,７３を使用する。これ
は、符号化シンタックスで「Postscriptパススルー」と
呼ばれる特性であり、本明細書の従来技術の項で導入し
た。好ましい実施形態は、どのような一般的なPostscri
ptドライバ７４も受け取るように、変換された圧縮ラス
ター５３を直接送るように、パススルー・エスケープを
使用する。

【０１１７】パススルー・エスケープは、今日までのWi
ndowsの全ての新しい省略されていないバージョンで使
用することができる。これは、いわゆる「パーム（手の
ひら）」ユニットを含む小型製品のためのWindows CEの
ような現行の省略されたオペレーティング・システムを
除く、Windows 3.1より後の全てのバージョンを意味す
る。

【０１１８】ドライバ７４は、その後、最高品質のハー
ドコピー・カラー・プリントアウト８２を生成するのに
使用するように、変換された圧縮ラスター５３を印刷装
置８３へ中継する（８１）。関係するデータは、変換さ
れた圧縮ラスターとともに送られる。

【０１１９】本発明は、このように、当初にＤＣＴまた
はＬＺＷ予備圧縮されたデータ２４,４３,５３を効率的
に印刷するためにパススルー６５を活用しながら、標準
のWindowsおよびPostscriptドライバ・パス７４、８１
をバイパスしない。実際、標準の図形要素６３およびド
ライバ要素６４は、テキストまたはベクトル画像情報な
どのいずれかの非ラスター・データ６１を印刷するのに
使用される。同様に、標準の図形およびドライバ要素６
４,７２は、いずれかの非圧縮ラスター・データを印刷
するのに使用される。

【０１２０】この目的のために、図形要素６１,６４
は、６６,６８において、Windowsコア６５によって処理
され、ドライバ要素７１,７２２適切に変換され、結局
対応するドライバ７５,７６へ出力される。図形要素６
３,６４は、Windows 95および98に対してWindows NTと
基本的に同じである。しかしながら、ドライバ要素７
１,７２は、これらの二つの基本的なプラットフォーム
において全く異なる。

【０１２１】いずれの場合でも、Windows Postscriptド
ライバが、印刷装置８３への伝送（８１）のために、全
てのドライバ要素７１,７２を有効なPostscriptデータ
へ最終的に変換する。これらのデータ８１も、また、そ
こへ組み込まれたものとして、ＪＰＥＧ、ＴＩＦＦまた
はＧＩＦファイルから来た全ての予備圧縮データ７３,
７７を保持する。

【０１２２】色調整、クリッピング（トリミング）制
限、装置固有の特性などの、全てのＰＳドライバ制御設
定は、パススルーを使用しても、完全に保存される。し
かしながら、一般的な規則として、好ましい実施形態の
使用において、ドライバによって生成されたPostscript
コードは、重要ではない。というのは、必要とされる唯
一の特性は、パススルー６７、すなわち、アプリケーシ
ョン３２によって生成されたPostscriptコード５３,５
５を挿入するための方法だからである。

【０１２３】３．アプリケーション内の処理アプリケーション３２の手続き４４,６３,６４は、更な
る説明を有する。「従来の技術」の項で述べたように、
ＪＰＥＧファイル２４は、アプリケーションにロード
（３１）された場合に、画像データ２２（図１）だけで
はなく、画像の基本的なレイアウトにクリティカルない
くつかのパラメータを含む。このようにファイル２４
は、大容量のデータ３６の先頭に位置する小さなクリテ
ィカル・パラメータ・ブロック３５（図３）を有するも
のと大まかに概念化してもよい。

【０１２４】小さなヘッダ３５は、直接、変換プロセス
（４５）の中に読み込まれる。画像が、印刷用に、たと
えば９０度回転されたりトリムされる場合に、このプロ
セスは、寸法と解像度の値を単に修正する。

【０１２５】このような単純な回転は、画像の形をペー
ジの形に合わせるためにしばしば要求される。回転につ
いては、非常に簡単な数字の交換、言い方を変えれば、
数字の再識別だけが、通常の回転において高さと幅とを
交換するために必要である。

【０１２６】一般的に画像データ２２に対応する、当該
ファイルの残りは、量子化テーブル４２およびソースＤ
ＣＴ係数４３（図１の１６）を取り出すように、ハフマ
ン復号化（４１）される。ハフマン復号化は、ハフマン
符号化２３（図１）と同様に、無損失プロセスである。
当該係数は、しばしば、かなり大きなメモリを要求し、
そのような状況において、標準のＪＰＥＧプロトコル
は、オペレーティング・システムが許容する何らかの方
法で、ディスクへのスワップを要求する。

【０１２７】従来、このスワップ機能は、いわゆる「シ
ステム・スワップ・ファイル」を使用して実施された。
換言すれば、ホストにおける揮発性ワーキングメモリの
内容は、従来は、ハードドライブ・ファイルのような不
揮発性メモリへ記憶された、すなわち、プログラマの専
門用語では、「マップ・オーバ」された。通常、このよ
うなファイルは、いずれかのアプリケーションのこのよ
うなアシストに対する必要を検出して、オペレーティン
グ・システムによって自動的に作成される。

【０１２８】しかしながら、Windows NTにおいては、当
該システム・スワップ・ファイルは、非常に内容豊富な
データのために必要なものとして成長しない。したがっ
て、本発明の好ましい実施形態は、代わりに、一時的な
非システム・ファイル上に当該係数をマップする。

【０１２９】ＮＴの特別な要請を解決することに加え
て、本アプローチは、システム・スワップ・ファイルの
使用に対して異なった種類の障害を呈する、他のWindow
sバージョンのために、重要な利益を提供する。ＮＴ
は、スワップ・ファイルの十分な成長を提供しないが、
非同期のスワップ・ファイルアクセスを供給し、その結
果、アプリケーションがデータをファイルへまたはファ
イルから転送する間にシステム全体は待機する必要がな
い。

【０１３０】しかしながら、Windows 95および98におい
ては、スワップ・ファイル・アクセスは、もっぱら同期
式であり、このボトルネックは、ファイル・マッピング
におけるバグによって悪化される。この環境において、
バグを避けて行なうために、よりよいアプローチは、一
時的な非システム・ファイルへのスワップである。

【０１３１】現在好ましい環境において、この一時記憶
は、好ましくは、いわゆる「メモリ・マップされた」タ
イプのファイルにある。将来の実施においては、その代
わりに、メモリ・マップされたファイルではない一時フ
ァイルを使用する可能性もあり、その結果、一時記憶
は、オペレーティング・システムへの依存度がより低
く、より独立性があり移植性がある。

【０１３２】一時記憶がメモリ・マップされたファイル
である場合に、好ましい実施形態をしっかりと実施する
には、ファイル・マッピングの特化された管理が必要で
ある。これは、プログラミング技術の当業者に明らかな
簡単な方法ですぐに達成されるが、以下の第５項は、特
に初心者のオリエンテーションのためにさらに解説を提
供する。

【０１３３】つぎに、ＤＣＴ係数は、印刷準備において
要求されたならば、回転およびトリミングのために処理
される（４４）。たとえば９０度の簡単な画像回転は、
よく知られたマトリクス数学の対称性による、非常に簡
単なマトリクス回転に対応する。

【０１３４】これらの特別な対称性のおかげで、（たと
えば、画像の形をページの形へ合わせるために）回転が
要求されれば、係数を再計算するより、再配置するだけ
で、回転を達成することができる。換言すれば、本質的
に、これらの全ての変化は、係数の値ではなく順序であ
る。

【０１３５】マトリクス操作の分野の熟練したプログラ
マや数学者にとっては明らかなように、このことは、本
質的に、クリティカル・パラメータ・ブロックにおける
上述の高さと幅の交換のより手の込んだ類似物に過ぎな
い。しかしながら、さらに詳細を簡単に示す。

【０１３６】回転および同様な簡単な変更のために要求
される基本的な再配置または再識別とともに、量子化テ
ーブル４２におけるそれぞれの値の対応する再配置また
は再識別を行ない、修正した表４６を作表する必要があ
る。もちろん、そのような計算においてＤＣＴ圧縮解除
／再圧縮は必要なく、したがってこの手続きは無損失で
ある。

【０１３７】変換されたＤＣＴおよび量子化データ４
７,４６は、その後、ハフマン符号化される（５１）。
この結果は、新しい圧縮ＤＣＴ／量子化ストリーム５２
と、付随した変換されたクリティカル・パラメータ５
３’である。

【０１３８】特定の印刷プロジェクトにおいて、回転ま
たは他の変換が画像に適用されない場合、原則として、
ＤＣＴ係数のハフマン抽出および再符号化は、要求され
ない。それにもかかわらず、本発明の好ましい実施形態
は、あらゆる場合にこれらのステップを行なう。その理
由は、単に、独立ＪＰＥＧグループによって広められた
ＪＰＥＧライブラリにおける模範コードによって命じら
れているからである。以下の第４項において説明する。

【０１３９】これらのハフマンステップは、時間および
金額の点で、いくらか高価であり、したがって、揮発性
メモリが画像ファイル全体を保持するのに十分であれば
ディスクへのスワップを省くように、この特別な環境に
おいてはスキップしたほうがよい（図５）。これを達成
するためのアプリケーション・コードの修正は、比較的
簡単であるがまだ完成していない。

【０１４０】二重のＤＣＴ／パラメータストリーム５
２,５３’は、つぎにＡＳＣＩＩ８５符号化（５４）を
受ける。この符号化は、印刷装置によって認識されるフ
ォーマットであり、よりコンパクトである基本８５シス
テムにおけるデータを表す。しかしながら、この基本８
５符号化を使用する主な理由は、後続の段階７４,８１,
８３に知られたもっとも普通の種類のテキスト命令シン
タックスへの実際上全ての類似点を除去するからであ
る。

【０１４１】こうして、本符号化は、上記の段階でたび
たび起こり得る、誤った編集の試みに対して、データを
効果的に防護する。換言すれば、基本８５符号化は、テ
キストと思われるものを再フォーマット化する、誤っ
た、オペレーティング・システムまたはドライバの努力
によるファイル破損に対して、ガードする。

【０１４２】同時に、アプリケーション３２によってPo
stscriptヘッダ５６が準備される。これは、画像を見つ
けそれをページに挿入する機能を呼び出すためにPostsc
ript言語で書かれる。

【０１４３】ＡＳＣＩＩ８５符号化ストリーム５５は、
ヘッダ５６とともに、ページにおいて画像を適当な位置
とサイズで印刷する、Postscriptスクリプトに組み込ま
れる。このスクリプト５５,５６は、一般的に、上記の
第２項に記述したように、パススルー・エスケープ６７
（図２）によってどのような３２ビットWindows印刷ジ
ョブにも挿入することができる。

【０１４４】パススルーの間のWindowsＧＤＩ６５、ま
たはドライバ７４からの不適切な干渉は、二つの要因で
避けられる。第１に、ＡＳＣＩＩ８５符号化は、上記の
ように、データを図形保存フォームにカプセル化する。
第２に、使用される全てのシンボルは、Postscriptで
「辞書」と呼ばれる一時的な環境において隔離される。

【０１４５】この専用の辞書および全ての表示状態の保
存によって、多くのオブジェクトが、ＧＤＩパスまたは
パススルーを、衝突することなく送られる。したがっ
て、スクリプト５５,５６は、自由に且つ安全に、通常
の印刷動作と合わせることができる。

【０１４６】４．変換の典型的なシンタックスＪＰＥＧ（Joint Photographic Experts Group）特に独
立ＪＰＥＧグループ（ＩＪＧ）とＩＳＯ（Internationa
l Standards Organization）によって準備された、卓越
した公開資料のおかげで、本発明を実施するためのプロ
グラミングは、取るに足らないものではないが途方のな
いものではない。説明のための参照テキスト・ファイル
は、以下のものを含む。"IJG JPEG LIBRARY: SYSTEM AR
CHITECTURE"および付随した"README" ファイル、著作権
Thomas G. Lane； "JPEG FILE INTERCHANGE FORMAT", E
ric Hamilton, C-Cube Microsystems および"INFORMATI
ON TECHNOLOGY-DIGITAL COMPRESSION AND CODING OF CO
NTINUOUS-TONE STILL IMAGES-REQUIREMENTS AND GUIDEL
INES", International Telegraph and Telephone Consu
ltative Committee (CCITT) IJG資料は、"JPEGlib"として知られ、非公式規格ライブ
ラリの一種とみなしてもよいコード・ライブラリを含
む。特に、本発明のここでの好ましい実施形態は、ＩＪ
ＧＪＰＥＧライブラリ６ｂから引き出されるか、ま
たは適合された、いくつかのコード・モジュールを使用
する。このライブラリの付録は、マトリクス回転４４の
ような通常の変換のための、"JPEGTran"として知られた
独立型のユティリティである。

【０１４７】より具体的には、ページの方向と画像の方
向とが合わないときに、通常、画像の９０度の時計回り
回転が好ましい。これは、２７０度の反時計回りの回転
に相当し、角度は伝統的に、反時計回り方向を正として
測られる。

【０１４８】したがって、本発明の最近の好ましい実施
形態において、ページ方向合わせのためにJPEGTranから
選択されたシンタックスは、"do_rot_270" である。ク
リティカル・パラメータの対応する再配置のための関連
するシンタックスは、"transpose_critical_parameter
s"である。

【０１４９】しかしながら、本発明の最新の好ましい実
施形態は、印刷装置が回転を行なうように命令するため
に、コード・モジュールdo_rot_270を使用するよりも、
上述のように係数を交換するマトリクス計算を適用する
ことによって、アプリケーション３２に対して、内部的
に回転を行なう。これらの戦略のいずれも、機能しうる
ものであるが、アプリケーション３３の内で内部的に行
なうことは、現在では、本発明のきわめて好ましい形で
ある。

【０１５０】このように、アプリケーション３３内の回
転は、単に定型的な設計ではなく、Windowsのいくつか
のバージョンとの相互作用が円滑となり、さらに重要な
ことに、全体の処理量と効率の点からの、予想外の利点
を提供することが見出された後は、むしろ好ましいもの
である。同様に、transpose_critical_parametersを使
用することは、絶対的な要請というよりも、好ましいこ
とである。

【０１５１】このように、本発明の好ましい実施形態
は、非公式の標準プロトコルを使用するか、ある場合に
は、ＧＤＩ６５および特にパススルー６７との調和を最
適化するために、標準プロトコルを適合させる。ライブ
ラリの資料は、本質的に、本発明の好ましい実施におい
て使用したり適合したりしてもよい例に過ぎない。（JP
EGTranには、ミラーリングやグレースケールの説明も現
れるが、好ましい実施形態では使用する必要がない。）

【０１５２】JPEGlib９１（図４）は、標準メモリマッ
ピングの拡張９２をも含む。しかしながら、上述の理由
により、この標準モジュールは、従来のWindowsシステ
ム・スワップ・ファイルを非システム、非同期アクセス
型スワップ・ファイルに置き換える特化された拡張９３
に取り替えるのが好ましい。

【０１５３】ライブラリは、ソースファイルと目的ファ
イルとの間の自動交換、たとえば、単一のファイルをソ
ースおよび目的ファイルとして機能させるための規定を
含まない。しかしながら、このような動作は、画像デー
タの量が非常に多いときに、システムの不揮発性記憶資
源が使い尽くされる可能性を避けるために有用である。

【０１５４】９０度回転の場合には、またも、９０度回
転を実施するＤＣＴ係数交換の対称性によって導入され
る単純性によって、上記の自動交換は、非常にたやすく
達成される。特に、本好ましい実施形態は、いずれにし
ても、上述のように非同期アクセスを提供するように、
非システム・スワップを確立することを含むので、これ
は、大きな追加の努力を意味しない。更なる詳細を簡単
に示す。

【０１５５】さらに、AdobeのPostscript言語は、有用
な機能「ＤＣＴ符号化」および「ＤＣＴ復号化」を含
む、いわゆる「フィルタ」を含む。このフィルタの部分
は、上述のハフマンおよびＡＳＣＩＩ８５ステップ４
１,５１,５４のために、特に、最終のPostscriptスクリ
プト８１を復号化する際に印刷装置８３によって使用さ
れるために適合させることができる。

【０１５６】Windowsにおいて、本発明を実施するため
の作業において、種々のまずい環境と多少のバグに直面
し、克服した。特に、ページの形に合わせる回転を行な
わずに、しかし回転を行なうPostscriptドライバ７４へ
の命令とともに、Postscriptドライバ７４へファイルを
送ることを、最初は企画した。

【０１５７】全てのＪＰＥＧ処理が高性能印刷装置で行
なわれるので、概念的には、これは最善の技術である。
しかしながら、実際には、ＰＳ印刷装置のより古いバー
ジョンの性能は、この点に関し全く受け入れがたい。

【０１５８】したがって、上記の項で既に述べたよう
に、特化されたアプリケーション３２が、ＤＣＴ係数
（画像画素ではなく、ＪＰＥＧ係数）を交換し、その
後、この係数をパススルー６５によって、ドライバ７４
および印刷装置８３へ送る。この技術は、処理量を２か
ら１０倍増加させる。

【０１５９】他方、トリミングについて、以前の非常に
単純な戦略は、特化されたアプリケーション３２におい
て画像の端を切り落とすことを要求していたが、不明の
理由により、ＰＳドライバは、直接のテストによってフ
ァイルが有効であると確認されても、結果としてのトリ
ムされたファイルを拒絶する。したがって、本発明の好
ましい実施形態は、これに変わり、トリムされていない
ファイルをトリムのための命令とともにPostscriptへ送
り、このアプローチはうまく行くことが判明した。

【０１６０】本発明の好ましい実施形態を実施する際
に、ドライバと印刷装置がPostscriptであり、パススル
ーをサポートするか否かおよびどのようにコードを送る
かを検出する必要がある。マイクロソフト文書は、二つ
の方法を提供しており、両方ともドライバへのエスケー
プとしてコードを送る。

【０１６１】これらの作業の一方は、Windows 3.x （１
６ビットドライバ）のためのものであり、他方は、Wind
ows NT（３２ビットドライバ）のためのものである。Wi
ndows 95 および98は、１６ビットドライバを使用する
といわれるが、テストした際に、対応するドライバは、
ＮＴドライバと同じように機能した。Adobeからの全て
のドライバは、同じように機能すると暫定的に想定す
る。

【０１６２】上述のように、本発明の好ましい実施形態
を実施するためのコードは、主としてＩＪＧライブラリ
に基いている。異なったやり方で取り扱われる圧縮およ
び圧縮解除オブジェクトに基いており、ある場合には、
これはコストの大きなオーバーヘッドとなるので、この
ライブラリの構造は、ここでは完全に適切ではない。

【０１６３】コードにおける主な差異は、ＤＣＴの管理
にある。ライブラリにおいてＤＣＴは、汎用的且つ他の
システムで使用できる方法で取り扱われ、あるステップ
でＤＣＴのアレイ全体を仮想アレイと呼ばれるものに読
み込み、その後、変換を適用する。上述のように、アレ
イはハードディスクにあり、回転された画像においてＤ
ＣＴは異なった順序で記憶され、したがって、コードは
ディスクを「歩く」必要があるので、大画像に対して、
この変換は非常に時間がかかる。

【０１６４】ライブラリ（JPEGtran）で供給される変換
ツールは、最初にＤＣＴのアレイ全体を仮想アレイへ展
開し、その後変換し、最後にそのアレイを再圧縮する。
この手続きは、アレイの２個のコピーを必要とするので
非常にメモリを消費する。２個のコピーとは、（原画像
を維持し、圧縮解除オブジェクトによって使用され
る。）ソース・コピーと（変換された画像を蓄積し、圧
縮オブジェクトによって使用される）目標コピーであ
る。この手続きも、アレイ全体を３回横切る必要がある
ので、時間を消費する。

【０１６５】好ましい実施形態においては、その代わり
に、ＤＣＴは、全て、行ごとの単一ステップで、読み込
まれ、復号化され、圧縮解除され、変換され、メモリ・
マップ・ファイルにおいて、変換された位置に記憶され
る。最大の画像はこのように取り扱うことができ、ディ
スク・スペースによってのみ制限される。

【０１６６】画像全体がこのように処理されると、ディ
スクに記憶されるのは、変換された画像である。したが
って、次のステップは、単に、この一時的なメモリ・マ
ップ・ファイルを順次読み込み、ハフマン符号化するこ
とである。

【０１６７】アルゴリズムは、変換を行なうためにJPEG
tranで提供されるものと同じであるが、かしこい状況で
使用される（たとえば、圧縮解除中）。ＤＣＴ係数抽出
のためのルーチンは、ライブラリのものの機能拡張版で
あり、実行中（on the fly）に変換を行なう。

【０１６８】最後に、メモリ・マネージャは、ライブラ
リ組み込みメモリ・マネージャのインターフェースを保
存する、メモリ・マップ・ファイルをサポートするよう
に再生される。プログラミング技術の当業者は、このこ
とを単純明快であると理解する。しかしながら、役に立
つかもしれない更なるオリエンテーションが、以下の第
５項に示される。

【０１６９】最後に、上述のように、結果としてのファ
イルは、ＡＳＣＫＩＩ８５符号化されている。この時点
において、ドライバによって生成されるPostscriptスト
リームに組み込まれる、PostscriptＪＰＥＧのいわゆる
「デコーダ」コードが付加される。

【０１７０】このPostscriptデコーダ（復号手段）は、
印刷装置が画像を復号することができるように提供さ
れ、非常に簡単である。後で印刷装置によって呼び出さ
れたときに、デコーダは、以下の動作を行なう。

【０１７１】一時的な作業空間として辞書を作成する。
印刷装置のPostscriptエンジンの図形状態をセーブす
る。データを復号化するためにＡＳＣＩＩ８５フィルタ
およびＤＣＴ復号化フィルタを使用する。特定の座標上
に特定のサイズ、縦横比および向きで置かれた画像を描
写する。エンジンの（３ステップ前にセーブされた）図
形状態を回復する。辞書を残しておく。

【０１７２】（これらのステップにおいて、「向き」と
いうのは、いずれかの、任意の角度による回転を指す。
しかしながら、このような回転は、非常に時間を消費す
るので、薦められない。上述のように、９０度の倍数に
よる回転は、アプリケーション３２によって既に行なわ
れている。）

【０１７３】このPostscriptデコーダは、自立型であ
り、上述のPostscriptストリーム５５,５６のその他の
要素と同じように、ドライバー Postscriptコード７１
−７３,８１と自由に合わせることができる。したがっ
て、本好ましい実施形態の特性は、他の全ての動作に対
してＧＤＩ６５を使用するアプリケーションの能力を損
なわない。

【０１７４】５．プログラマ・ノート "MemoryMappedFiles" として知られるシステム・ツール
によって、ＣまたはＣ＋＋でプログラミングすること
は、Win32 プログラマの基本的な技能である。それは、
一般的に必要とされるWin32プログラミング知識であ
り、いくつかの例とともに、ＭＳＤＮにおいてよく説明
されている。

【０１７５】JPEGtranライブラリのメモリ・マネージャ
・インターフェースは、要求がマップ・ファイルのビュ
ーにマップすることができる大きなブロックによって行
なわれるので、メモリ・マップ・ファイルの使用によく
合う。上記に示したように、それは、単純明快である。

【０１７６】経験のあるほとんどのプログラマにとっ
て、ここでの説明は過剰であろう。しかし、このオリエ
ンテーションは、比較的初心者には役立つかもしれな
い。基本的な題目は、中間的なまたは一時的な画像管理
を行なう仕方である。

【０１７７】Windowsにおいて、オペレーティング・シ
ステムは、アプリケーション（クライアント）へメモリ
を提供（供給）する。このメモリは、システム・スワッ
プ・ファイルへマップされる。このようなファイルは、
一つしかないか、または物理的ディスクごとに一つであ
る。

【０１７８】このシステム・スワップ・ファイルは、ア
プリケーションによって直接アクセスすることはできな
い。システムだけがそれをアクセスすることができる。

【０１７９】間接的にそれを使用するために、アプリケ
ーションは、いわゆる"heap API"機能の内のあるものを
使用する必要がある。"heap API"機能は、標準Ｃライブ
ラリからの"malloc"および"free"機能およびWin 32 API
からの"Virtualxxxxx", "Localxxxxxx", "Globalxxxx
x", "Heapxxxx"などと呼ばれる機能を含む。

【０１８０】アプリケーションが大量のメモリを使用す
るとき、システムは、システム・スワップ・ファイルに
おいて、相応に大量のスペースを使用する。ライブラリ
は、たとえば、Ｃ標準ライブラリの"malloc"および"fre
e"機能を使用してメモリを割り当てながら、このように
してメモリを使用する。

【０１８１】ライブラリは、また、一時ファイルへマッ
プされたメモリを提供するが、ファイルシステムを使用
する。これは、少ない物理メモリと非同期ファイル・シ
ステムを備えたシステムに合っている。

【０１８２】しかしながら、これは、Windows 95または
98に対しては、ファイルシステムが同期的であるので、
最善の方法ではない。すなわち、アプリケーションがあ
るファイル・システム機能を呼び出すとき、この要求が
満たされるまでシステムはブロックする。したがって、
アプリケーションがディスクをアクセスするのに多くの
時間を費やすと、大きなファイルの場合、ＣＰＵ時間の
全てまたはほとんど全てはディスクを待つのに失われ
る。

【０１８３】本発明のこの好ましい実施形態において使
用されるアプローチは、これまでの技術のミックスであ
る。それは、メモリ・マップ非システム・ファイルを使
用する。これらのファイルは、システムが仮想メモリと
して取り扱うが、システム・スワップ・ファイルへマッ
プされていないメモリを表す。Windows NT, 2000, 98
および95において、これらのメモリ・マップ・ファイル
は、非同期でアクセスされる。しかしながら、このよう
なメモリ・アクセスは、上述の共通ＣＡＰＩルーチン
（malloc および free）によって提供される。

【０１８４】したがって、標準ライブラリによって提供
されるメモリ・マネージャは、特化作成メモリ・マネー
ジャによって置き換えられる必要がある。すなわち、ラ
イブラリ・モジュールは、標準マネージャの代わりに特
化されたマネージャを呼び出すように修正される。しか
し、もちろん、他のアプリケーションの使用のために、
標準マネージャは、本来の場所に残される。呼び出され
たときに、特化されたマネージャは、修正したライブラ
リ・モジュールから同じ要求を受け取るが、その要求を
Ｗｉｎ３２ＡＰＩの中のメモリ・マップ・ファイル機
能へ転送する。

【０１８５】上述のように、Windows 95 および98 の中
のバグを避けて作業する必要がある。問題および推薦さ
れる戦略は、"BUG: Creating File Mapping Objects U
singthe Same File Handle Will Cause a File to be I
naccessible, ID: Q230606."というタイトルで、KB "W
indows Development" の中で、マイクロソフトによって
詳しく説明されている。

【０１８６】ライブラリがより多くのメモリを要求する
たびに、ファイルは開かれ、成長され、以前のファイル
・マッピング・(FileMapping)オブジェクトは閉じられ
る。新しいファイル・マッピング・オブジェクトは作成
され、当該ファイルは再び閉じられる。当該ファイル
は、読み書き共用モードで開かれる。これは、多少危険
を伴う。この領域では、適切且つ通常の注意をすること
が推奨される。

【０１８７】上記の開示は、単に説明のためのものであ
り、発明の範囲を限定するものではない。発明の範囲
は、特許請求の範囲によって決められるべきである。

【図面の簡単な説明】

【図１】通常の画像データ・ビットマップ・ファイルか
ら、本発明または本明細書の「従来の技術」の項で説明
された、その他のシステムによって受け取られる代表的
な予備圧縮された画像データファイルを作成する従来の
手続きを示す図である。

【図２】本発明の全体像を示す、概略の装置および流れ
図である。

【図３】より詳細であり、図２の「アプリケーション」
ブロック３２に焦点を当てた同様の図である。

【図４】本発明の実施において好ましいＪＰＥＧ規格に
対する所定の変更の性質を示唆する非常に概念的な図で
ある。

【図５】回転または大きな画像スワップ・ファイルをそ
れぞれ必要としない場合の、望ましいプログラムバイパ
ス経路に焦点を当てたほぼ図３と同様の図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩＨ０４Ｎ 1/387 Ｈ０４Ｎ 1/387 1/46 1/46 Ｚ (72)発明者ジョーディ・ヴィラースペイン08130バルセロナ、サンタ・パーペツゥア、アヴェニダ・ドッズ 12 (56)参考文献特開平10−187368（ＪＰ，Ａ) 特開平11−110148（ＪＰ，Ａ) 米国特許6351317（ＵＳ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/12 B41J 5/00 H04N 1/00

Claims

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

【請求項１】印刷装置を制御する Windows （登録商
標）オペレーティング・システムを使用して、有損失予
備圧縮非テキスト・ラスター画像データに基いて、画像
を印刷するための方法であって、有損失予備圧縮非テキスト・ラスター画像データを受け
取るステップと、印刷装置によって期待されるファイル仕様フォーマット
に合わせるように、無損失再圧縮を使用して、当該デー
タを調整するために、当該データに言語変換を適用する
ステップと、無損失再圧縮を使用して、Windows （登録商標）オペレ
ーティング・システムによって、調整されたデータを印
刷装置へ渡すステップと、を含む方法。
【請求項２】言語変換を適用するステップが、また、
調整されたデータに追加されるべき望ましい印刷パラメ
ータの変換を処理するステップを含む請求項１に記載の
方法。
【請求項３】前記パラメータが、画像の回転、画像の
トリミング、画像のサイズ変更、色平面の数、色平面別
の画像高さおよび幅、色平面別の単位距離ごとの解像度
からなるグループから選択される請求項２に記載の方
法。
【請求項４】前記渡すステップが、Windows （登録商
標）オペレーティング・システムにおける Postscript
（登録商標）パススルー・エスケープを使用するサブス
テップを含む請求項１に記載の方法。
【請求項５】前記渡すステップが、調整された圧縮画
像データを直接印刷装置ドライバへ送るサブステップ
と、印刷のために、印刷装置ドライバから印刷装置へ画
像データを伝送するサブステップとを含む請求項１の方
法。
【請求項６】前記受け取るステップと調整するステッ
プとの間で、受け取ったデータに無損失圧縮解除を適用
するステップと、前記調整するステップと渡すステップ
との間で調整したデータに無損失再圧縮を適用するステ
ップとをさらに含む請求項１の方法。
【請求項７】ＤＣＴ係数および量子化テーブルを有す
るＪＰＥＧデータである画像データとともに使用し、上
記二つの無損失適用ステップの間で、システム・スワッ
プ・ファイルではない一時ファイルに当該ＤＣＴ係数お
よび量子化テーブルを記憶するステップをさらに含む請
求項６の方法。
【請求項８】前記記憶するステップが、印刷される際
に画像を回転させる、係数の交換を実現するデータ構造
における対称性を活用することを含む請求項７の方法。
【請求項９】前記受け取るステップ、調整するステッ
プおよび渡すステップが印刷制御アプリケーション・プ
ログラムによって行なわれる請求項１の方法。
【請求項１０】コンピュータ・ホストを管理する Wind
ows （登録商標）オペレーティング・システムで実行さ
れ、予備圧縮非テキスト・ラスター画像データに基いて
画像を印刷する印刷装置を制御するための Postscript
（登録商標）印刷装置ドライバであって、当該コンピュータ・ホストにおいて当該ドライバを維持
する不揮発性メモリと、当該 Windows （登録商標）オペレーティング・システム
における Postscript （登録商標）パススルー・エスケ
ープによって、当該予備圧縮非テキスト・ラスター画像
データを受け取るための第１のデータ・チャネルと、受け取ったデータを当該印刷装置へ送る第２のデータ・
チャネルと、を含み、当該印刷装置によって期待される第１のファイル仕様フ
ォーマットに合う当該予備圧縮非テキスト・ラスター画
像データは、当該印刷装置によって期待されない第２の
ファイル仕様フォーマットでフォーマットされた、対応
する画像データに、無損失再圧縮を使用して、言語変換
を適用することによって生成される Postscript （登録商
標）印刷装置ドライバ。