(57)【特許請求の範囲】
【請求項１】
画像データを選択的に転送する方法において、
ウェーブレット分解により１つの画像から分解された複数のデータセットのうちの１つのセットに対応し且つ所望のビューポートでの表示に適する１つの画像分解能の画像を予め用意された複数の画像分解能の画像から選択する段階であって、
設定可能なスケーリング閾値に基づいて、複数の異なる画像分解能のうちの一つの画像分解能のスケーリングが、所望のビューポートの分解能以下のスケーリングされた画像分解能となるか否かを決定することを含む対話的なプロセスにより、前記１つの画像分解能の画像が決定され、
前記対話的なプロセスは、前記ビューポートを拡張又は縮小して、該ビューポートに表示された画像をズームイン又はズームアウトすることにより行われる、
前記選択する段階と、
その画像分解能の画像を再合成するために複数のデータセットの一部分を選択的に要求する段階と、
を含み、
画像分解能の画像を選択する前記段階は、拡張又は縮小する前記ビューポートでの表示のために設定可能な前記スケーリング閾値を越えるスケーリングアップを要求しない、複数の徐々に高くなる分解能レベルのうちの最低の適切な１つの分解能レベルを識別する段階を含み、
最低の適切な１つの分解能レベルを識別する前記段階は、複数の徐々に高くなる分解能レベルのうちの最高のローカル分解能レベルを評価する段階を含む、方法。
【請求項２】
前記複数のデータセットは、画像データファイルの一部を形成し、該画像データファイルがウェーブレット分解され、サーバ上で圧縮形式で格納されている、請求項１記載の方法。
【請求項３】
前記画像データファイルが可逆ウェーブレット分解され、前記サーバ上で可逆的な圧縮形式で格納されている、請求項２記載の方法。
【請求項４】
前記複数のデータセットの一部分は、複数のデータセットより小さく、前記選択的に要求する段階が、可逆ウェーブレット分解に基づいて所望の順序に順次配列された複数のデータセットを含むデータ・ストリームを要求する段階を含む請求項１記載の方法。
【請求項５】
画像データを選択的に転送する方法において、
クライアントビューポートのビューポート分解能を判定する段階と、
１つの画像からウェーブレット分解により生成される複数の分解画像セットのうちの１つのローカルセットに対応する最高のローカル分解能レベルを識別する段階と、
ビューポート分解能を複数の分解画像セットに対応する徐々に高くなる分解能レベルと比較することにより、クライアントビューポートでの表示のために許容画像分解能の画像を予め用意された複数の画像分解能の画像から選択する段階であって、
設定可能なスケーリング閾値に基づいて、複数の徐々に高くなる分解能レベルのうちの一つの分解能レベルのスケーリングが、所望のビューポートの分解能以下のスケーリングされた画像分解能となるか否かを決定することを含む対話的なプロセスにより、前記許容画像分解能の画像が決定され、
前記対話的なプロセスは、前記ビューポートを拡張又は縮小して、該ビューポートに表示された画像をズームイン又はズームアウトすることにより行われる、
前記選択する段階と、
許容画像分解能で画像を再合成するために、複数の分解画像セットのうちの所望の画像セットを遠隔検索する段階を含み、
画像分解能の画像を選択する前記段階は、拡張又は縮小する前記ビューポートでの表示のために設定可能な前記スケーリング閾値を越えるスケーリングアップを要求しない、複数の徐々に高くなる分解能レベルのうちの最低の適切な１つの分解能レベルを識別する段階を含み、
最低の適切な１つの分解能レベルを識別する前記段階は、複数の徐々に高くなる分解能レベルのうちの最高のローカル分解能レベルを評価する段階を含む、
方法。
【請求項６】
許容画像分解能を選択する段階は、最高のローカル分解能レベルが許容し得ないスケーリングをビューポート分解能と等しくすることを要求しない場合に、最高のローカル分解能レベルを許容画像分解能として選択する段階を含む請求項５記載の方法。
【請求項７】
所望のセットを遠隔検索する段階は、分解能が高くなる順に順次配列された複数の分解画像セットのうちの所望のセットを含むデータストリームを要求する段階を含み、
ビューポート分解能を判定する動作と、最高のローカル分解能レベルを識別する動作と、許容画像分解能を選択する動作と、所望のセットを遠隔検索する動作とはユーザがクライアントビューポートと対話する間に自動的に実行される請求項５記載の方法。
【請求項８】
クライアントビューポートのビューポート分解能を判定するように構成されたビューポート解析モジュールと、
データ選択モジュールであって、１つの画像からウェーブレット分解により生成される複数の分解画像セットのうちの１つのローカルセットに対応する最高のローカル分解能レベルを識別するローカルデータ識別器と、
設定可能なスケーリング閾値に基づいて、前記複数の分解画像セットのうちの１つの分解画像セットに対応するスケーリングが、前記ビューポートの分解能以下のスケーリングされた画像分解能となるか否かを決定することを含む対話的なプロセスにより、クライアントビューポートでの表示のために許容画像分解能の画像を予め用意された複数の画像分解能の画像から選択するように構成された所望データ識別器とを具備するデータ選択モジュールと、
画像を許容画像分解能で再合成するために、複数の分解画像セットのうちの所望のセットを遠隔検索するように構成されたデータ検索モジュールとを具備し、
前記対話的なプロセスは、前記ビューポートを拡張又は縮小して、該ビューポートに表示された画像をズームイン又はズームアウトすることにより行われ、
所望データ識別器は、ビューポート分解能を複数の分解画像セットに対応する徐々に高くなる分解能レベルと比較するように構成された分解能比較器を具備し、
分解能比較器は、拡張又は縮小する前記ビューポートでの表示のために設定可能な前記スケーリング閾値を越えるスケーリングアップを要求しない、徐々に高くなる分解能レベルのうちの最低の適切な１つの分解能レベルを識別するように構成された最低許容分解能識別器を具備するシステム。
【請求項９】
機械読み取り可能な媒体であって、前記機械読み取り可能な媒体に格納されたコンピュータプログラムを具備し、
前記コンピュータプログラムが、
クライアントビューポートのビューポート分解能を判定するように構成されたビューポート解析モジュールと、データ選択モジュールを備え、
前記データ選択モジュールが、
１つの画像からウェーブレット分解により生成される複数の分解画像セットのうちの１つのローカルセットに対応する最高のローカル分解能レベルを識別するように構成されたローカルデータ識別器と、
設定可能なスケーリング閾値に基づいて、前記複数の分解画像セットのうちの１つの分解画像セットに対応するスケーリングが、前記ビューポートの分解能以下のスケーリングされた画像分解能となるか否かを決定することを含む対話的なプロセスにより、クライアントビューポートでの表示のために許容画像分解能の画像を予め用意された複数の画像分解能の画像から選択するように構成された所望データ識別器とを具備するデータ選択モジュールとを具備し、
前記対話的なプロセスは、前記ビューポートを拡張又は縮小して、該ビューポートに表示された画像をズームイン又はズームアウトすることにより行われ、
画像分解能の画像の選択は、拡張又は縮小する前記ビューポートでの表示のために設定可能な前記スケーリング閾値を越えるスケーリングアップを要求しない、複数の徐々に高くなる分解能レベルのうちの最低の適切な１つの分解能レベルを識別することにより行われ、
最低の適切な１つの分解能レベルの識別は、複数の徐々に高くなる分解能レベルのうちの最高のローカル分解能レベルを評価することを含む、
機械読み取り可能な媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般に、画像データ圧縮の分野に関する。特に、本発明は、画像データを所望のビューポートへ高速に送信し且つ適応させるために画像データを処理する技術に関する。
【０００２】
【従来の技術】
画像データの圧縮には広範囲にわたるアプリケーションが存在している。デジタル化画像は、相対的に単純なデジタル化機器及びデジタルカメラを経て作成する、並びに医学診断の分野で使用されているような複雑な撮影システムを使用するなどの多様な方法で作成できる。画像データが作成される環境とは無関係に、後の再構成及び表示に備えて画像を記述するデジタルデータが格納され、データはインターネットなどのネットワークにより様々な場所へ送信される。デジタル画像管理の目標は、画像データを格納するために割り当てられるメモリを効率良く使用すること、並びに再構成のために画像データを効率良く且つ高速に送信することである。第２の目標は、帯域幅が比較的限られているネットワークを介して大型の画像又は複雑な画像を処理しなければならない場合には特に重要である。例えば、医学診断撮影の分野においては、欠けるところのない詳細な画像を高速に送信するために必要とされる非常に広い帯域幅に対するアクセスが制限されているユーザを含めてある範囲のユーザによる送信及び観察のために非常に大きな画像データセットを利用できるであろう。
【０００３】
医用画像情報システム、略してＰＡＣＳは、特に医学撮影の分野において、デジタル化画像データの管理で極めて重要な要素となっている。このようなシステムは、多くの場合、医学撮影システムなどの様々な供給源からデータを受信して、画像データの中央レポジトリとして機能する。画像データは格納され、ネットワークリンクを介して放射線技師、診断及び言及を行う医師、並びにその他の専門家に対して利用可能な状態とされる。ＰＡＣＳの改善は利用可能な画像データ量を大幅に増加させ、且つ施設内部、並びに中央格納場所と遠隔クライアントとの間の双方において大きなデータファイルの読み込みと転送を容易にした。
【０００４】
単純なインターネットブラウザから医学診断に適用されるＰＡＣＳに至るまであらゆる画像処理システムを更に改善しようとする試みの主な問題点は、画像を定義する大型データファイルの処理である。医学診断の分野では、撮影の態様に応じて、デジタル化データは１回の検査で相当な数の画像について収集され、処理されることになり、各々の画像が再構成画像のそれぞれ別個のピクチャエレメント、すなわち、画素を定義する大きなデータセットを表現している。例えば、コンピュータ断層撮影（ＣＴ）撮影システムは非常に短い検査時間フレームの中で関心人体構造に沿って多数の別個の画像を生成することができる。そのような画像の全てをＰＡＣＳに集中して格納し、検討及び診断の際に放射線技師が利用できる状態にするのが理想的である。
【０００５】
医学画像データファイルなどの大型データファイルを解析し且つ圧縮するために様々な技術がこれまで提案されており、現在も使用されている。画像データファイルは、通常、画像特性、典型的には再構成画像における個々の画素の強さ又はその他の特性を記述するデータのストリームを含む。医学診断の分野では、これらの画像ファイルは、通常、Ｘ線システム、磁気共鳴撮影システム、コンピュータ断層撮影システムなどにおけるように画像収集又は符号化のシーケンスの間に作成される。その後、画像データは格納、送信及び表示に備えて、ダイナミックレンジを調整するか又は画像中に示されているいくつかの特徴を強調するなどの目的のために処理される。
【０００６】
画像ファイルは生フォーマット及び処理済フォーマットで格納されるが、多くの画像ファイルは極めて大きく、ディスク又は記憶装置の相当に広いスペースを占めるであろう。撮影システムは複雑さを増しており、それに伴って、通常は撮影システムの有効ダイナミックレンジ、画像画素の行列の大きさ及び検査ごとに収集される画像の数の関係でより多くのデータを含む非常に大きな画像ファイルが作成されることになった。
【０００７】
利用可能なメモリのセグメントのうちの多数を占めるのに加えて、大型画像ファイルは１つの場所から別の場所へ送信するのが困難であるか、あるいはそのために長い時間を要する。典型的な医学撮影の用途においては、例えば、スキャナ又は他の撮影装置は通常は生データを作成し、その少なくとも一部はスキャナで処理されても良い。その後、データは通常はプログラム済みコンピュータを含む他の画像処理回路へ送信され、そこで更に処理され、画質が向上される。最終的には、画像データはシステムにローカルに格納されるか、又は後の検索及び解析に備えてＰＡＣＳに格納されるかのいずれかである。これらのデータ送信過程の全てにおいて、大型画像データファイルをアクセスし、１つの装置から別の装置へ送信しなければならない。
【０００８】
現在の画像処理技術は、格納要求を軽減し且つ送信時間を短縮するために、ＰＡＣＳ環境内部での画像データの圧縮を含む。しかし、そのような圧縮技術は、検討のために画像をアクセスする又は相関する際に有用であると思われる記述ヘッダ情報を含めてファイル全体を圧縮する。更に、現在の技術は、システムスループット速度及びアクセス時間の更なる向上を求める要求を十分に満足させるほどに高速な画像ファイルの圧縮と伸長を提供しない。最後に、そのような技術に代わる圧縮技術や伸長技術も、クライアント−サーバ環境における高速な圧縮及び伸長と組み合わせて、所望の圧縮比を提供しない。
【０００９】
既存の圧縮技術のもう１つの欠点は、ユーザが再構成画像を利用可能な全てのディテールまで見ることができない場合又はそれを望まない場合でも大型データファイルが格納、アクセス、送信されてしまうことである。例えば、医学撮影の場合、極めて詳細な画像が収集され、格納されるが、それらの画像を見ることを望む放射線技師は画像を格納されたときの分解能で表示することが可能であるビューポートを有していないかもしれない。従って、画像の全てを遠隔観測ステーションへ相対的に時間のかかる作業によって送信したとしても、現実にはメリットはなく、画像の読み取り又はその他の利用を遅らせてしまうであろう。
【００１０】
【発明が解決しようとする課題】
従って、画像ファイルの高速な送信及び所望のビューポートの分解能特性に基づく選択的処理を実行する改良された画像データ処理技術が必要とされている。
【００１１】
【課題を解決するための手段】
本発明の技術は、複数の分解能レベルに分解された画像データを選択的に処理する。画像データは、分解能レベルのうちの所望の１つの分解能より高い又は低いビューポート分解能を有するビューポートでの表示のために、分解能が徐々に高くなる順に検索される。当初、画像データはビューポートにおいて複数の分解能レベルのうちの相対的に低い分解能レベルで表示される。ユーザが画像の全体又は一部をより高い分解能で表示することを望む場合、１つ以上の徐々に高くなる分解能レベルが検索され、それがビューポートに適合するようにスケーリングされる。従って、本発明の技術は、画像データの全体をそのままアクセスするのではなく、複数の分解能レベルに対応する複数のブロックとして画像データをアクセスすることにより、データをより効率良く処理する。複数の分解能レベルのうちの次に高いレベルが必要であることを報知するために、スケーリング閾値を使用することも可能である。
【００１２】
本発明の上記の利点及び特徴、並びにその他の利点及び特徴は、以下の詳細な説明を読み且つ図面を参照することにより明白になるであろう。
【００１３】
【発明の実施の形態】
図１は、画像データを受信し、圧縮し、伸長する医用画像情報システム（ＰＡＣＳ）１０の形態をとる画像データ管理システムの一例を示す。図示されている実施例では、ＰＡＣＳ１０は図中符号１２、１４及び１６により指示されるいくつかの別個の撮影システムから画像データを受信する。当業者には理解されるであろうが、画像システムは磁気共鳴撮影（ＭＲＩ）システム、コンピュータ断層撮影（ＣＴ）システム、ポジトロン放出断層撮影（ＰＥＴ）、放射線透視撮影（ＲＦ）システム、コンピュータＸ線撮影（ＣＲ）システム、超音波システムなどの様々な種類と態様のシステムであって良い。更に、システムは既存のフィルム又はハードコピー画像に基づいてデジタル化画像データを提供するように設計された機器などの処理ステーション又はデジタル化ステーションを含んでいても良い。また、画像データをＰＡＣＳに供給するシステムを同じ施設又は設備のようにＰＡＣＳに関してローカルに配置しても良いし、あるいは外部の診療所又は付属施設などのようにＰＡＣＳから完全に離れた場所に配置しても良いことに注意すべきである。後者の場合、画像データはオープンネットワーク、専有ネットワーク、仮想専用ネットワークなどを含む何らかの適切なネットワークリンクを介して送信されれば良い。
【００１４】
ＰＡＣＳ１０は、画像データを受信し且つ処理すると共に、画像データを伸長及び検討のために利用可能な状態にするように設計された１つ以上のファイルサーバ１８を含む。サーバ１８は入出力インタフェース１９を介して画像データを受信する。画像データは圧縮／伸長インタフェース２０を介してアクセスされるルーチンで圧縮される。以下に更に詳細に説明するが、インタフェース２０は、記述画像データをサーバ１８及びＰＡＣＳの他の構成要素が参照するために利用可能な状態に維持しつつ、入力する画像データを高速且つ最適に圧縮するように機能する。希望に応じて、インタフェース２０はサーバを介してアクセスされる画像データを伸長するように機能しても良い。サーバは図中符号２２により指示される内部クライアントにも結合しており、各クライアントは、通常、放射線技師、医師又は臨床医がサーバから画像データをアクセスし、画像データを伸長し、画像データを希望に応じて観察又は出力することができるワークステーションを含む。クライアント２２は、検査シーケンスを検討した後の放射線技師の口述内容などの情報を更に入力しても良い。同様に、サーバ１８は、画像データをアクセスし且つ伸長すると共に、プリンタ２６又は他の周辺装置を介してハードコピー画像を出力するように設計されたプリンタインタフェース２４などの１つ以上のインタフェースにも結合している。
【００１５】
サーバ２８は１つ以上のファイルサーバ１８を参照することにより画像データ、及びＰＡＣＳ内部の他の作業流れ情報を関連付ける。ここで意図されている実施例においては、データベースサーバ２８は特定の画像シーケンス、言及又は診断した医師の情報、患者情報、背景情報、作業リスト相互参照などに関する相互参照情報を含む。データベースサーバ２８内部の情報は画像データファイルの格納及び相互の関連付けを容易にすると共に、要求を発しているクライアントがシステム内に格納されている画像データファイルを高速且つ正確にアクセスできるようにする働きをする。同様に、サーバ１８は、バックアップ及びアーカイビングを目的として大量の画像データのレポジトリとして機能する光記憶システムなどの１つ以上のアーカイブ３０に結合している。サーバ１８と、短期間格納システムを形成し且つサーバ１８と関連する何らかのメモリと、アーカイブ３０との間で画像データを転送する技術は、放射線技師による検討及び所見口述に続いて、あるいは画像データファイルの受信又は検討から十分な時間が経過した後に画像データをアーカイビングするなどの何らかの適切なデータ管理方式に従っていれば良い。
【００１６】
図示されている実施例では、ＰＡＣＳシステム又は施設の他の構成要素を上述の構成要素と一体に組み合わせて、システムの機能性を更に拡張しても良い。例えば、図１に示すように、圧縮／伸長ライブラリ３２はインタフェース２０に結合し、圧縮ルーチン及び伸長ルーチンの実行時にインタフェース２０（又は他のシステム構成要素）によりアクセスされるべき圧縮ルーチン、アルゴリズム、ルックアップテーブルなどを格納する（すなわち、様々なルーチン、ソフトウェアバージョン、コードテーブルなどを格納する）ように機能する。実際には、インタフェース２０はライブラリ３２の一部であっても良い。ライブラリ３２は、同様に圧縮ルーチン、伸長ルーチン及びアルゴリズムのライブラリ又はストアとして機能する、クライアントステーション２２又はプリンタインタフェース２４などの、システムの他の構成要素に結合していても良い。図１には別個の構成要素として示されているが、ライブラリ３２がサーバ１８内部を含めて何らかの適切なサーバ又はメモリ装置に含まれていても良いことを理解すべきである。更に、以下に説明する圧縮プロセス及び伸長プロセスを定義するコードはインタフェース２０及び／又はライブラリ３２に直接にロードされても良いが、ワイドエリアネットワーク、オープンネットワークなどを含むネットワークリンクを介してロード又は更新されても良い。
【００１７】
追加のシステムをサーバ２８に直接にリンクするか、又はインタフェース１９などのインタフェースを介してリンクするなどの方法によりＰＡＣＳにリンクしても良い。図１に示す実施例では、データ、通常はデータベースサーバ２８内部の相互参照データと、中央情報システム又はデータベース、あるいは放射線科情報システム又はデータベースとの交換を容易にするために、放射線科情報システム（ＲＩＳ）３４がサーバ１８にリンクしている。同様に、データベース情報、作業流れ情報などを交換するために、病院情報システム（ＨＩＳ）３６もサーバ２８に結合している。希望に応じて、そのようなシステムはデータ交換ソフトウェアを介してインタフェースされても良いし、あるいはＰＡＣＳデータベースと放射線科データベース又は病院データベースとの間におけるデータのアクセスを可能にするため、又は単一の相互参照データベースを提供するためにＰＡＣＳシステムと部分的に又は完全に一体化されていても良い。同様に、図中符号３８により指示されるような外部クライアントをＰＡＣＳとインタフェースして、遠隔場所で画像を見られるようにしても良い。そのような外部クライアントは伸長ソフトウェアを採用するか、既にインタフェース２０により伸長された画像ファイルを受信する。同様に、そのような外部クライアントに至るリンクもワイドエリアネットワーク、仮想専用ネットワークなどの何らかの適切な接続を介して行われれば良い。
【００１８】
図２は、データベースサーバ２８を介してクライアント２０、２２、２４及び３０に対して利用可能とされる相互参照データの型を幾分詳細に示す。図２に全体を図中符号４０により指示されるデータベースエントリは、患者データ４２、特定の研究又は検査に対する参照４３、実施された特定の手順に対する参照４４、撮影された人体構造に対する参照４５、及び研究又は検査の中における特定の画像シリーズに対する更に別の参照４６を含む相互参照情報を含む。当業者には理解されるであろうが、そのような相互参照情報は検査及びシリーズの時間及び日付、診断、言及又はその他の行為を行った医師の名前、画像が作成された病院又は科などに関する更に別の情報を含むことがある。データベースは、図中符号４８により指示されるように特定の画像、ファイル名及び画像の場所を識別するアドレス情報を更に含む。ＰＡＣＳが様々な関連メモリ装置又は短期間格納システムを含む場合、それらの記憶場所はデータベース内部で相互参照され、本質的にはユーザからは隠蔽されているので、画像ファイルは単にデータベース中の相互参照情報に基づいてシステムにより特定の記憶場所からアクセスされるだけであり、ユーザはそれを見ることになる。
【００１９】
以下に更に詳細に説明するが、本発明の技術のいくつかの面によれば、画像データを圧縮するために使用される好ましい又は最適の圧縮ルーチンを識別するために記述情報が使用される。そのような記述情報は、通常、以下に詳細に説明するように、画像データストリングのヘッダ部分から利用できる。しかし、データベースサーバ２８から利用可能である情報が圧縮技術で採用されるアルゴリズムを選択する上での基礎として利用されても良い。すなわち、撮影シーケンスで実施された手順、データに基づく再構成画像で見ることができる特定の人体構造又はその他の特徴などの記述情報を識別する際に、データベース参照に依存しても良い。そのような情報はＲＩＳ３４及びＨＩＳ３６からも利用できる。
【００２０】
図２は、データベースエントリにより相互参照される画像ファイルの一例を更に示す。図２に示すように、画像ファイル５０は複数の画像データセット５２、５４及び５６を含む。典型的な画像ファイルでは、多数のそのような画像セットが連続するデータストリームにより定義される。各データセットは、以下に説明する圧縮アルゴリズムを含む特定の圧縮アルゴリズムに従って圧縮される。
【００２１】
各画像データセットの中には、圧縮ヘッダ６０と共に記述ヘッダ５８が規定されている。ヘッダ５８及び６０の後に圧縮画像データ６２が続く。各データセットの記述ヘッダ５８はＤＩＣＯＭ準拠記述データなどの工業規格又は認識可能記述情報を含むのが好ましい。当業者には理解されるであろうが、そのような記述情報は、通常、患者のＩＤ、画像、研究又は撮影シリーズの日付、画像データを作成するシステムの態様、並びに再構成画像で見ることができる特定の人体構造又は特徴に関する追加情報を含む。以下に更に詳細に説明するが、このような記述ヘッダデータは、本発明の技術においては、圧縮画像データ部分６２の中のデータを圧縮するために使用される最適の圧縮アルゴリズム又はルーチンを識別するために採用されるのが好ましい。画像データを圧縮するために使用される特定のアルゴリズム又はルーチンを参照するデータは、後に画像データを伸長する際に参照されるのに備えて、圧縮ヘッダ６０に格納される。以下に説明する通り、画像データを伸長するときに使用するために圧縮ヘッダ６０で識別されているアルゴリズムを相互参照する追加データが圧縮画像データ中に格納されている。すなわち、現時点で好ましい実施例においては、圧縮ヘッダ６０は圧縮画像データの部分領域の長さの識別情報と、特定の最適アルゴリズムに対する参照とを部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態で含む。
【００２２】
図３は、本発明の技術により圧縮、伸長される連続データストリームとしてアセンブルされたデジタル化データのパケットにより符号化されている典型的な画像を示す。全体を図中符号１００により指示される画像は、通常、特定の人体構造特徴などの関心特徴１０２を含む。医学診断アプリケーションにおいては、そのような特徴は、ＭＲＩシステム画像における軟組織、Ｘ線画像における骨などのように、画像収集の態様の物理学的特性によって目に見える患者の特定の人体構造又は領域を含む。各々の画像は、個別の画素１０８の数と分布により定義される幅１０４と高さ１０６を有する行列から構成されている。画像行列の画素は行１１０と、列１１２とを成して配列されており、再構成画像で見ると関心特徴を定義する様々に変化する特性を有する。典型的な医学診断アプリケーションでは、それらの特性はグレイレベル強さ又は色を含む。デジタル化データストリームにおいて、各画素は２進コードにより表現され、画像の識別及び画像と研究対象である他の画像との関連付けを補助するために、２進コードは記述ヘッダに追加される。先に述べた通り、そのような記述情報はＤＩＣＯＭ準拠データなどの工業規格情報を含む。
【００２３】
図４は、画像行列の一対の行に沿って画像を定義する画素データの強さを表すグラフである。画像行列の各行は一連の画素を含み、各画素は画素特性、通常は強さを記述する２進コードにより符号化されている。従って、再構成画像のより明るい領域はより高い強さレベルを有する画素に対応し、暗い領域はより低い強さレベルを有する。グラフにより表すと、画像に沿った画素の強さレベルは図４に示すような輪郭又はトレースを形成する。詳細には、図４に示すように、第１の行１１４は第２の行１１６に隣接して位置し、各行はトレース１１８及び１２０によりそれぞれ指示するような様々な強さを有する一連の画素を含む。当業者には理解されるであろうが、実際には、画素強さのグラフは位置軸１２２に沿って段階的関数を形成し、強さ軸１２４に沿って変化する振幅を有する。
【００２４】
実際の画像においては、行に沿った強さの変動、及び隣接する行を通って上下に動く、対応して位置する強さにより表される列に沿った強さの変動は再構成画像で表現される特徴に従って変化することが図４からわかるであろう。図４に示すように、行１１４は、強さの低い領域と、強さの高い領域の双方を含めて、強さが増して行く領域及び強さが低下して行く領域を含む。行１１６はそれに類似する強さの領域を含むが、画像で表現される特徴によって変動している。本発明の技術によれば、画像データストリームは図４に図中符号１２６により指示されるように複数の部分領域に縮小される。部分領域の長さ（すなわち、画素の数）は異なっていて良いが、現時点で好ましい実施例においては、各部分領域は等しい数の画素を符号化するデータを含む。しかし、圧縮後、部分領域のコードの実際の長さがその部分領域の内部の画素の強さと、画素強さを符号化するデジタルデータのダイナミックレンジとに応じて変化することは当業者には容易に認識されるであろう。また、画像行列の行長さが部分領域幅の整数倍である場合、個々の部分領域は図４に示すように画像行列に沿って下降しながら互いに整列することに注意すべきである。しかし、一般には本発明の技術はそのような整数倍の行幅に限定されない。
【００２５】
画像データストリームの各部分領域は、圧縮を目的として画像データのエントロピーレベルを識別するために解析される。一般に、画像データのエントロピーは各部分領域の内部における画素強さの相対的変動を表す。従って、特定の１つの部分領域が高い強さ又は低い強さの画素を含むことはあるが、強さレベルがその部分領域の中で相対的に安定している又は一定であれば、エントロピーは低いと考えられる。そのような領域は、図４では、例えば、トレース１１４及び１１６の、図中符号１２８及び１３２によりそれぞれ指示される部分に示されている。これに対し、部分領域データにより画素強さの相当に大きな変動が符号化されている場合には、エントロピーレベルは高いと考えられる。そのような領域は図４に図中符号１３０及び１３４で示されている。画像データストリームを画像特性に応じて様々な長さを有する部分領域に分割し、且つ各部分領域の相対的エントロピーレベルを解析することにより、いくつかの候補圧縮アルゴリズムの１つに従って部分領域を最適に圧縮できることがわかっている。具体的には、本発明の技術は、部分領域ごとに画素予測誤差を圧縮コードに翻訳する働きをする一連の事前定義済み圧縮コードテーブルを採用する。部分領域ごとに選択される特定の圧縮コードテーブルは、圧縮ルーチンにおいてその部分領域について識別されるエントロピーの関数である。
【００２６】
以下に更に詳細に説明するが、本発明の技術は画素値予測子を採用し、個々の画素の予測値（すなわち、画素強さ又はその他の特性を表す２進コード）と、それぞれの画素の実際値との差を識別するのが好ましい。実際には、いくつかの予測子アルゴリズムを採用でき、特定の予測子は、画像データストリームの記述ヘッダで符号化されている特性などの画像特性に基づいて識別される。予測子は目標画素、すなわち、関心画素と近傍画素との比較に基づいている。図５は、予測子アルゴリズムで行われる参照の基礎として利用される画素近傍を表す。図５で図中符号１３８により指示される画素近傍は、p(i,j)として指示されている関心画素１３６を含む。近傍画素は、p(i-1,j-1)として指示されている「北西」画素１４０と、p(i,j-1) として指示されている「北」画素１４２と、p(i+1,j-1)として指示されている「北東」画素１４４と、p(i-1,j)として指示されている「西」画素１４６とを含む。これらの画素の一部又は全てが予測子アルゴリズムで採用されるか、あるいはより大きな近傍で他の追加画素を規定しても良い。
【００２７】
先に説明したシステムにおいて混成圧縮画像データファイルを作成するために画像データストリームを圧縮するための好ましい技術を図６に要約した。制御論理は、最適の圧縮アルゴリズム、テーブル、予測子選好、ブロック又は部分領域の長さ選好などが確定される構成セグメント２５０を含む一連の論理ブロック又はセグメントに分割されている。データアクセス検索セグメント２５２では、圧縮すべき画像データと、データベースサーバ２８からの記述情報（使用する場合）とを受信する。評価セグメント２５４では、構成セグメント２５０で確定されたアルゴリズム及び選好に基づいて画像を評価する。圧縮セグメント２５６では、圧縮ルーチンのためにいくつかの値を計算、選択し、画像データを圧縮して圧縮ファイルを作成する。最終セグメント２５８では、圧縮データにファイルコードを追加する。次に、ファイルはステップ２６０で完成し、ステップ２６２で格納される。その後、圧縮伸長論理はステップ２６４で圧縮画像ファイルが最終的にアクセスされ、ステップ２６６で伸長アルゴリズムが検索され、ステップ２６８で観察及び出力のために伸長が実行されることによって完了する。以上の論理セグメント及びプロセスについては後に更に詳細に説明する。
【００２８】
制御論理の構成セグメント２５０は、ルーチンで採用される特定の圧縮アルゴリズム、予測子アルゴリズム及びブロック又は部分領域アルゴリズムを構成するステップを含む。すなわち、ステップ２７０では、予測誤差により指示される通りの相対エントロピーレベルに基づいて画像データの部分領域を最適に圧縮するために一連の圧縮コードテーブルを生成する。当業者には理解されるであろうが、そのような圧縮コードテーブルは、一般に元の値の予測分布又は発生頻度に従って、元の値を圧縮値と相互参照するために利用される。現時点で好ましい実施例においては、ルーチンにより圧縮されるべき典型的な画像の解析に基づいて、一連の圧縮コードテーブルを確定する。圧縮コードテーブルで実現される特定の符号化及び範囲は様々に異なり、一般に特定のアプリケーションにおいて経験的に判定されるが、いくつかのそのような圧縮コードテーブルの例を図７から図１２に示す。
【００２９】
図７から図１２を参照すると、図７のテーブル１７０のような各々の圧縮コードテーブルは、原画像パラメータ１７４に対して相互参照される一連の圧縮データ値１７２を含む。図示されている例では、解析は図中符号１７６により指示されるようなビット単位の結果コードリンクの表示と、図中符号１７８により指示されるような各テーブルエントリにより翻訳されるコードのスパンとを含む。図示されている実施例においては、コラム１７２の圧縮データコードは圧縮ルーチンにおける予測子の適用により識別されるコラム１７４の差値を翻訳し、その後に、予測値と実際値との差の判定が続いている。従って、一例として、以下に説明するように予測子アルゴリズムに基づいて１の差値が識別された場合、テーブル１７０は圧縮データコード１００を規定している。この場合も、差値は一般に符号化画素それ自体の値を表現しているのではなく、予測値と実際値との差を表現していることに注意すべきである。すなわち、テーブル１７０のコラム１７６に要約されている通り、コード長が３ビットであるとき、予測値と１個となる関心画素は圧縮データ値１００を獲得するが、画素値自体はそれより相当に長くなる。同様に図７からわかるように、コラム１７２に規定されている圧縮データコードはテーブル内のレベルを指定する第１の部分１８０と、それに続く、レベル間棚範囲内における位置を指示する第２の部分１８２とを含むと要約できるであろう。従って、例えば、図７のテーブルの場合、−２から−３の差範囲は１１０１と符号化され、その後に、差が−２であるか又は−３であるかに応じて追加ビットが０又は１の値に設定されることになるであろう。以下に図１３を参照して説明するように、範囲の上限で、圧縮データコードは個々の画素の実際値をとる。
【００３０】
図面からわかるように、予測誤差又は差を圧縮コードに翻訳するための圧縮コードテーブルは、データストリームの部分領域ごとに差の値のレベル又は変化に対して適切な符号化の範囲を規定するために確定される。特定して言えば、図７のテーブル１７０はテーブル中の最短コードにより対応される小さな差の変化（０）及び差レベル間の相対的に細かいステップにより指示されるように最低エントロピーレベルに適合されている。図８は、テーブルにより対応される相対的に広い最大レベル及び図７のテーブル１７０と比較して相対的に高い差の範囲により指示されるように相対的に高いエントロピーを規定する第２の圧縮コードテーブル１８４を表す。図９、図１０、図１１及び図１２は、それぞれ、様々な部分領域の内部における予測誤差又は差により指示されるように順に高くなるエントロピーレベルを符号化するための更に別の圧縮コードテーブル１８６、1８８、１９０及び１９２の例を示す。図示されているこの実施例では、コードテーブルはハフマンコードに基づくプレフィクスと、マルチビット拡張子とを使用して構成されている。
【００３１】
一連のテーブルの中で各々の圧縮コードテーブルにより規定される圧縮比は対応すべき相対エントロピーレベルに応じて異なることに注意すべきである。すなわち、図７のテーブル１７０は１６：１という相対的に高い最大圧縮比を規定し、一方、図１２のテーブル１９２は２.２９：１という低い最大圧縮比を規定している。しかし、データストリーム部分領域の様々に異なるエントロピーに対応するために複数の異なる圧縮コードテーブルを使用することにより、その結果、部分領域の予測誤差の変動に対応するために最適に選択された圧縮データコード長を使用できるために優れた圧縮が実行されることがわかっている。
【００３２】
特定の種類の画像に対して、又は特定の典型的特性を有する画像に対して、様々なエントロピーレベルを予想できることがわかっている。例えば、医学診断撮影の場合、ＣＴデータ及びＭＲＩデータなどの特定の態様に対しては相対的に高いエントロピーレベルが期待される。他の撮影態様は、それより低いエントロピー値及びそれに相応して低い予測差により反映されて、画像強さレベルの変動が相対的に小さい画像を提供するであろう。更に、特定の画像型はより高い又は低い特性エントロピー値を提供することもわかっている。医療診断の分野では、そのような画像の型は胸部、頭部、四肢などの特定の人体構造を含み、その変動は部位によって大きくも、小さくもなり、また、エッジラインやコントラストも強くもなり、弱くもなるであろう。そこで、ストリームにより圧縮すべき典型的な画像に基づいて、特定の一連の圧縮コードテーブルを確定するのが好ましい。
【００３３】
図６に戻る。一連の圧縮コードテーブルをステップ２７０で生成し、格納したならば、構成セグメント２５０は、その後、ステップ２７２で指示するように予測子選好を生成する。先に説明した通り、本発明の圧縮技術では符号化に際して実際の画素強さ値を採用するのではなく、予測子アルゴリズムに基づいて差の値を採用する。一般に、予測子アルゴリズムは画像の低エントロピー領域では相対的に低い値を生成し、高エントロピー領域では相対的に高い値を生成する。しかし、データ圧縮に予測誤差を使用すると、一般に、画像に沿って強さの変動が相対的に漸進的に進行して行くために最適データストリームコード値より低い（すなわち、長さが短い）値の圧縮を引き起こす。
【００３４】
現時点で好ましい実施例においては、いくつかの予測子アルゴリズムのうちの１つ以上を採用する。再び図５に戻ると、単純明解なアルゴリズムでは、各画素p(i,j)の値をそのすぐ前の画素p(i-1,j)の値であるとして予測する。この予測子アルゴリズムは、各画素値を予測するための計算に関して極めて効率の良いツールであり、画像中の第１の画素を０の値であると推定する。そして、関心画素について予測値と実際値との差の絶対値を求めることにより、差値を生成する。その結果得られる差値は原画像行列と等しい大きさの行列を形成する。
【００３５】
現時点で、これに代わるいくつかの予測子アルゴリズムが考えられており、他のアルゴリズムを採用しても良い。現時点で好ましい実施例では、それらの予測子アルゴリズムを次のように要約できるであろう。
Ip(i,j)=Ip(i-1,j)(P1);
Ip(i,j)=Ip(i-1,j)+(Ip(i,j-1)-Ip(i-1,j-1)(P2);
Ip(i,j)=((3*(Ip(i-1,j))+Ip(i-1,j-1)+Ip(i,j-1)+Ip(i+1,j-1))/6(P3);
Ip(i,j)=((-2*I(i-1,j-1))+(3*Ip(i,j-1))+(3*Ip(i-1,j)))/4(P4);
Ip(i,j)=((-5*I(i-1,j-1))+(7*Ip(i,j-1))+Ip(i+1,j-1)+
(9*Ip(i-1,j)))/12(P5);
Ip(i,j)=Ip(i,j-1)+Ip(i-1,j))/2(P6)
アルゴリズム中、表記「Ｉ」は画像強さを表し、個々の画像の指定は図５に従ってマッピングされている。
【００３６】
更に、様々な態様、及び再構成画像中に見ることができる様々な特徴又は人体構造から得られる様々な種類の画像に対して、様々な予測子が特に有用であることがわかっている。例えば、予測子アルゴリズムＰ１は各々の現在画素値の「最終値」を極めて単純且つ高速に推定する。予測子Ｐ２は多少のエッジ検出能力を示すが、画像中の雑音の影響を際立たせてしまうおそれがある。第３の予測子値Ｐ３はある種の画像には有用であることが示されている線形予測子であり、より多くの周囲画素の値を採用して、最終値をより大きく重み付けする。実際には、図６のステップ２７２で生成される予測子選好は様々な画像の種類及び態様に関わる実験の結果に従う。
【００３７】
図６の制御論理のセグメント２５０に示されている最終ステップは、画像データストリームを複数の部分領域に分割するための部分領域選好の生成である。先に指示した通り、画像データストリームの部分領域の長さはエントロピーレベルなどの要因に応じて異なる又は変動することもあるが、現時点で好ましい構成においては、部分領域の長さは互いに等しくなるように設定されている。しかし、画像データを当初生成させた態様、画像の種類、再構成画像で示される人体構造などの要因に応じて変わることもある。例えば、現時点では３２画素の部分領域長さをデフォルトと設定しているが、それに代わる８画素、１６画素、２４画素又は３２画素を越える部分領域長さも考えられる。一般に、この実施例のステップ２７４で設定される選好は画像行列における行の数によって決まり、６４行以下の行列の場合は部分領域長さ８を使用し、１２８行以下の行列の場合は部分領域長さ１６を使用し、それ以上の行を有する行列についても同様である。計算の複雑さを軽減し且つ速度を改善するため、現時点で好ましい実施例では、データが格納される方向に従って、画像行列の主方向、すなわち、軸（すなわち、列又は行）に沿って部分領域をとる。また、部分領域は１次元のみであるのが好ましい。
【００３８】
圧縮アルゴリズム、テーブル、予測子選好及び部分領域サイズ選好を設定したならば、図６に示す制御論理はセグメント２５２へ進む。論理のそのセグメントでは、ステップ２７６に指示するように画像データを受信する。先に述べた通り、画像データは外部供給源から直接に受信されても良いし、あるいはＰＡＣＳ自体の内部にあるメモリからアクセスされても良い。ステップ２７８で、圧縮ルーチンのアルゴリズム又はパラメータを選択するために使用される記述情報をデータベースサーバから検索する。先に述べた通り、そのような記述情報はデータベースに格納されており、画像データストリームの記述ヘッダに含まれる情報を捕捉する。
【００３９】
セグメント２５２に続いて、制御は評価セグメント２５４へ進む。このセグメントの中で、ステップ２８０に指示するように記述情報を求めて画像データを検討する。先に説明したように、画像データストリームの記述ヘッダ部分にあるＤＩＣＯＭ準拠データ又はデータベースからの記述データなど、記述情報を利用可能である場合、ステップ２８０でこのデータの一部又は全てを検討する。構成セグメント２７２で設定した選好に基づいて、ステップ２８２では、ステップ２８０で識別された画像特性に応じて予測子を選択する。予測子は当初画像を作成した撮影システムの態様、研究の種類又は画像で特徴となっている人体構造、画像中の行の数、列の数などを含む。更に、ステップ２８２で予測子を選択するに際しては、希望される計算効率、システムの処理能力などの他の要因も考慮され、プロセッサの能力が限られている場合、又はスピードアップが望まれる場合には計算の上で効率の良い予測子を選択する。ステップ２８４では、ステップ２７４で確定された選好に従って、画像データストリームを部分領域に分割するための部分領域サイズを選択する。同様に、ステップ２８４もデフォルト選択から構成されており、予測子の選択に際して考慮される特性又は要因の一部又は全てに応じてデフォルト選択は変更されることがある。
【００４０】
評価セグメント２５４は、ステップ２８６に指示する通り、圧縮テーブルのサブセットの適宜の選択へと続く。すなわち、いくつかの画像特性に基づいて、いくつかの圧縮テーブルをデフォルトとしてあらかじめ選択することが有用であると考えられる。例えば、ＣＴ画像又はＭＲ画像のように特定の態様で生成された特定の種類の画像はステップ２８６で選択される特定の候補テーブルによって圧縮されても良い。ステップ２８８では、圧縮ヘッダを画像データに追加する。以下に説明するように、この圧縮ヘッダは圧縮ルーチンのバージョンを識別するコード、ステップ２８２で選択された識別子、ステップ２８４で選択された部分領域サイズなどを含む。
【００４１】
制御論理の圧縮セグメント２５６では、ステップ２９０で一組の予測誤差又は差値を計算する。先に述べた通り、これらの値はステップ２８２において選択された予測子アルゴリズムの１つ以上の適用に基づいており、画素ごとに予測値を実際値と比較することにより予測誤差又は差を判定する。その結果得られる予測誤差は、第１の画素にその実際値が割り当てられ、その後、部分領域の画素ごとの差値が続くようなデータストリームを形成する。
【００４２】
本発明の技術は、ステップ２７０で確定される一連の圧縮コードテーブルからテーブルを適切に選択することに基づいて、各々の部分領域の最適の圧縮を実行する。どのテーブルが最良の圧縮を提供するかを判定するために、図６の制御論理のステップ２９０では、各々の候補圧縮コードテーブルを予測子アルゴリズムの適用の結果得られたデータに適用することにより、圧縮データの候補長さを計算する。ケース（すなわち、各々の圧縮コードテーブルの適用）ごとに、各部分領域の総データストリーム長さを加算する。各部分領域の完了に続いて、求められた和を比較して、どの圧縮コードテーブルがその部分領域について最短のデータストリームを提供するかを識別する。次に、ステップ２９２でこれに対応する圧縮コードテーブルを選択する。ステップ２９４で、以下に更に詳細に説明するように、部分領域ごとの選択されたテーブルを識別するコードを圧縮データ及びそのヘッダに挿入する。
【００４３】
先に述べた通り、評価セグメント２５４又は圧縮セグメント２５６は最適コードテーブルの選択に関してデフォルト及び制約を含んでいても良い。例えば、符号化すべき画像データのビット深さなどの要因に応じて、８以下のビット深さの場合には初めの４つのテーブルを選択するなど、圧縮コードテーブルの間でいくつかのデフォルト選択を行っても良い。更に、この選択プロセスにおいては、画像データを当初に生成した態様などの要因に応じて、指定圧縮コードテーブルに対していくつかの選好を行っても良い。一例として、ＣＴデータやＭＲＩデータはエントロピーの高い領域に対応して、画素強さのより高い遷移を符号化する傾向にある。従って、そのような態様で当初生成された画像に対して１つ以上のエントロピーの高いテーブルを優先するなど、ステップ２８０で検討された記述データに応じて、圧縮コードテーブルの選択に選好を含めても良い。最後に、現時点で好ましい実施例においては、個々の部分領域を圧縮するときに選択されたテーブルのうちのどれが採用されるかを指示するために、圧縮データストリームにコードが直接挿入される。圧縮を最適化するためには、制御論理の前処理セグメントで選択されるテーブルの数をデータ２ビット分などの限られた数のビットで都合よく符号化できる数に限定することが望ましいであろう。従って、テーブル識別コードを２ビットで提供すべき場合には、圧縮に候補テーブルのうちの４つのみを選択できるような制約が前処理セグメントに課されるであろう。テーブルに識別に追加ビットを利用できる場合には、８つの候補テーブルを選択し、符号化することもできるであろう。
【００４４】
ステップ２９４では、部分領域圧縮のキーコードを圧縮コードストリームの、圧縮部分領域データの直前に挿入する。先に述べた通り、圧縮に４つの候補テーブルが採用される場合、ステップ２９４で挿入されるコードは一対の指定ビットを含む。ステップ２８８で作成された圧縮ヘッダは選択された圧縮テーブルに対してこのキーコードを相互参照する。ステップ２９６で、選択され圧縮コードテーブルを適用することにより部分領域の画像データを圧縮する。画像全体が圧縮されるまで、セグメント２５６の一連のステップを画像の部分領域ごとに繰り返す。
【００４５】
最終セグメント２５８では、画像ごとの圧縮データを完成する。詳細に言えば、ステップ２９８で、圧縮終了ブロックを圧縮データに追加する。ステップ３００では、圧縮終了ブロックに続いてパディングビットを挿入する。最後に、ステップ３０２で、圧縮プロセスを通して計算されたチェックサム値を圧縮データに追加して、適正な伸長を検査するための手段を形成する。セグメント２５８の間に圧縮データに追加されるコードの位置と型については、以下に図１３を参照して更に詳細に説明する。
【００４６】
原画像データについて記述ヘッダが規定されている場合、ステップ２６０に指示するように画像ファイルを完成するために、記述ヘッダは圧縮ヘッダに隣接して置き換えられるのが好ましい。これにより得られるデータファイルは、画像の管理、アクセス、送信及びそれに類似する目的のために記述ヘッダデータを読み取ることは可能であるが、画像データの大部分は先に説明したように最適に圧縮されている混成圧縮データファイルである。ステップ２６２で、得られたファイルを典型的には短期間格納システム又はアーカイブにセーブする。ステップ２６４で、検討、解析、ハードコピー作成などのために画像をアクセスする。画像がアクセスされると、ステップ２６６に指示するように、混成圧縮データファイルの中で識別される伸長アルゴリズムが伸長のために検索され、圧縮画像データが伸長される。この伸長は圧縮ヘッダ情報に続いており、データを伸長するときには、部分領域ごとにデータを圧縮するために採用されたのと同じ圧縮コードテーブルが採用される。このように圧縮コードテーブルを適用することによって、圧縮の基礎となっていた予測誤差又は差が識別され、それらの差を生成するために採用された特定の予測子アルゴリズムを使用して、可逆に原画像データを再生することになる。
【００４７】
図１３は、上述の技術に従って圧縮された画像データセットを表す。全体を図中符号１９４で指示される画像データセットは、ステップ１９２で追加された圧縮ヘッダ１９８と共にステップ１６０で追加された記述ヘッダ１９６を含む。圧縮ヘッダ１９８に続いて、圧縮画像部分領域２０２、２０４等を含む圧縮画像データ２００がある。各圧縮データ部分領域はその部分領域を符号化するために使用されたアルゴリズム（例えば、圧縮コードテーブル）のＩＤと、それに続く実際の圧縮データとを含む。
【００４８】
図１３は、圧縮ヘッダ１９８の現時点で意図されているフォーマットを更に示す。図１３に示すように、圧縮ヘッダは圧縮ルーチンバージョンのＩＤ２０６と、それに続く、圧縮プロセスで使用された予測子のＩＤ２０７と、図中符号２０８で示す部分領域長さのＩＤとを含む。圧縮ヘッダには、圧縮時にどの圧縮アルゴリズム（例えば、圧縮コードテーブル）が選択されたか、及び各テーブルが部分領域ごとのデータストリームでどのようにして符号化されているかを識別するために、圧縮アルゴリズム識別セグメント２１０が挿入されている。例えば、図１３の例の場合、図中符号２１２で指示するようにテーブル０、３、４及び５が選択されており、各テーブルは部分領域ごとの圧縮データの最初の２ビットの中に見出すべき２ビット２進コードにより識別される。
【００４９】
図１３は、画像部分領域２０２、２０４等の各々に関して圧縮データコードの現時点で好ましい実施例におけるフォーマットを更に示す。図示されている実施例では、各部分領域の第１の部分は、部分領域２０２については図中符号２１４、部分領域２０４については図中符号２１８により指示するように、その部分領域のデータを圧縮するために使用された圧縮テーブルのＩＤを含む。このキーコードに続いて、図中符号２１６及び２２０によりそれぞれ指示するように圧縮コードがある。最後に、図１３は各圧縮画像ファイル、又はファイルの一部の終わりに挿入されるコードを示している。すなわち、画像の最後の部分領域ＢＮに続いて、ブロック終了コード部分２２２が追加されている。先に述べた通り、このブロック終了コードは画像の終わりを報知するが、画像データエントロピーの変動が大きいなどの理由により１つの画像の中でデータ圧縮ルーチンが変更されるような場合には、画像の一部の終わりを報知するために使用されても良い。図中符号２２４により指示するように、パディングコードが挿入されている。このコードは、１語分の長さで圧縮データファイルを完成するために必要に応じて可変サイズのコードである。最後に、圧縮データを完成するために３２ビットチェックサム部分２２６が追加されている。
【００５０】
本発明の技術の上述の面は圧縮すべき画像の種類に応じて様々な方法により適応されて良い。例えば、本発明の技術は様々に変化するグレイレベルから成る画像と、カラー画像の双方に使用できる。当業者には理解されるであろうが、カラー画像は、通常、各々の強さによって色変化の見かけを生み出す様々な色成分から構成されている。上述の技術はそれらの色成分を互いに分離することを伴って使用されても良いが、そのような分離を伴わずに使用されても良い。しかし、色成分を分離し、成分を複数のグループとして処理（すなわち、圧縮）することにより適用されるのが好ましい。同様に、マルチフレーム画像にも本発明の技術で対応できる。当業者には理解されるであろうが、マルチフレーム画像は、通常、行と列により符号化されたいくつかの別個の画像から構成され、それぞれの画像の間に別個の記述ヘッダ（例えば、ＤＩＣＯＭ準拠ヘッダ）は存在していない。そのような場合、それぞれ異なる画像フレームの場所に対応する圧縮データ中のオフセットを識別するコードが混成圧縮データファイルの記述ヘッダに挿入されるのが好ましい。
【００５１】
データ転送及び伸長の速度を更に向上させるように多重分解能（又はマルチサイズ）画像データ圧縮を実現するために、上述の画像データ圧縮伸長技術を更に改善できることがわかっている。ユーザが最大分解能で画像全体を見ることを望まない場合、又はユーザのビューポートが限定されている場合、そのような多重分解能画像圧縮はユーザに対して優れた画質を有する縮小サイズの画像を観察のために容易に転送できる。更に、以下に説明する通り、本発明の技術の多重分解能画像圧縮の面によれば、ユーザは縮小サイズ又は低分解能の画像を相対的に高速に見ることができると共に、まだ転送されていないより大型の画像のいくつかの要素に対応する圧縮データの一部分のみを転送することにより、後に画像を「ズーム」することができる。その後、追加データを処理し、縮小サイズ画像データを組み合わせて、より大型の画像を獲得することになる。
【００５２】
本発明の多重分解能実現形態は、先に説明した最適化ハフマンコード圧縮と組み合わされた可逆整数ウェーブレット分解と、ウェーブレット分解からの高周波数データセットの性質の認識に基づくハフマンコード圧縮の変形とに基づいている。詳細に言えば、当業者には了承されるであろうが、ウェーブレット分解は２項フィルタリングと、サブサンプリングプロセスとを含む。これは、図１４に示すような複数のサブバンドからなる階層セットを作成する。図１４に示すように、画像データセット３００は低周波数成分３０２と、雑音又は低周波数成分からの変動と考えることができる高周波数成分３０４とを含む。単一レベルウェーブレット分解の結果、図１４には図中符号３０８により指示される１つの低周波数サブバンドＬＬと、それぞれ図中符号３１０、３１２及び３１４により指示される３つの高周波数サブバンドＬＨ、ＨＬ及びＨＨとを含む分解データセット３０６が得られる。その後の分解は更に別のデータセット３１６を生成すると考えられ、このデータセットにおいては低周波数サブバンドが低周波数サブバンド３２０と、３つの付加的な高周波数サブバンド３２２、３２４及び３２６とを含むサブバンドのセット３１８へと更に分解されている。
【００５３】
通常、ウェーブレット変換は実（浮動小数点）フィルタであり、その結果も実数値である。最近になるまで、Ｓ変換（変形ハールウェーブレット）のみが整数に基づく変換と再構成を提供する方法であった。変換の性質から明白であるように、浮動小数点演算によって精度を維持することは非常に困難である。しかし、「リフティング」と呼ばれる技術により、どのウェーブレット変換も完全な可逆性を伴う整数に基づく変換として実現できる。
【００５４】
この「リフティング」技術を使用して、Ｓ変換（リフティングを伴うハールウェーブレット）、（２＋２,２）変換及び（４,２）変換を含めて様々なウェーブレット変換を解析し、比較した。更に、得られたサブバンドの情報理論エントロピー値に基づいて解析を実施した。ベース２のエントロピー値はクラフトの不等式によって可変長コード（ＶＬＣ）の平均長さに対してより低い限界を規定する。エントロピー値に加えて、４つのサブバンドの各々における１つのエントリの値を表現するために要求される演算を判定した。解析の成果は、変換に使用すべき最適のウェーブレットはＳ変換であることを示唆していた。その他の変換も採用できるであろうが、この実施例ではＳ変換が好ましく、得られる圧縮比よりも変換の速度及び複雑さの程度がより重要視される。
【００５５】
画像データセットの分解に際して、１次元の順方向１ステップウェーブレット変換は次の等式に基づいている。
【００５６】
【数１】
0004187514.tif 000002
【００５７】
式中、i∈[0,N-1]のときのC(i)は入力データを表し、Ｌ及びＨは分解された低周波数成分と高周波数成分であり、Ｃは入力データである。記号
【００５８】
【外１】
0004187514.tif 000003
【００５９】
により表される演算はオペランドより小さい最大の整数を生成し、「Ｎ」は入力データのサイズである。
【００６０】
この変換の逆である１ステップ逆ウェーブレット変換は次の等式により記述される。
【００６１】
【数２】
0004187514.tif 000004
【００６２】
上記の等式における暗黙の前提は、データサイズ「Ｎ」が偶数であるということである。理論上の解析及び記述には有効であるが、この仮定は本発明の技術で圧縮すべきいくつかのデータセットに対しては有効でない場合がある。しかし、本発明の技術は、以下に要約する通り、奇数、偶数を問わず入力データのサイズに対応し、且つ１次元変換を２次元変換に拡張するように適応されている。
【００６３】
先に説明した順方向ウェーブレット変換及び逆方向ウェーブレット変換の等式は１次元１ステップ変換である。２次元の再帰的１ステップウェーブレット分解は図１４に示すような画像のテセレーションを実行する。本発明の技術においては、全てのレベルで低周波数成分、すなわち、「ＬＬ」成分に対して１ステップウェーブレット変換を繰り返し実行する。変換のレベルの数は、最低分解能の行及び／又は列のサイズを固定することにより判定される。このレベル値は所望の最低分解能サイズまで原画像の最大限の行又は列のサイズを分解するために必要なステップにより判定される。このレベル変数を「ｎ」とすると、下記の等式が使用される。
n=log2(max(rows,cols))-log2(dsize)
式中、nは分解のレベルの数であり、「rows」及び「cols」は原画像の次元であり、log2は底が２のlogであり、dsizeは最低分解能画像の構成可能サイズである。
【００６４】
各レベルにおける奇数の行又は列の特殊な処理を実行する。本発明の実現形態では、ウェーブレット変換のアルゴリズムがシームレスユニットであるように、奇数行又は奇数列を強制的に偶数にするという目的を持って奇数行又は奇数列を複製する。この追加は画像の格納に必要とされるメモリスペースを幾分か増加させるが、それらの行又は列においては高周波数サブバンドが全て０を有するため、圧縮を実行するときの追加はないに等しい。
【００６５】
先に採用された用語に関して言えば、カッドo入力画像データ（a,b,c,d）をｌｌ、ｈｌ、ｌｈ、ｈｈに分解するための２次元１ステップ順方向変換は下記の等式により決定される。
【００６６】
【数３】
0004187514.tif 000005
【００６７】
変換の全てのレベルで奇数行及び奇数列を処理するのに加えて、本発明の技術は符号付き１６ビットアレイ又は符号なし１６ビットアレイを使用するときのオーバフローの可能性に対応するように適応されている。全ての値を３２ビット値として扱うことは可能であろうが、所望の変換を実行するときの速度の損失と、画像を処理するために要求されるメモリの著しい増加が発生すると考えられる。ＰＡＣＳ向けに設計された本発明の実現形態においては、アルゴリズムの速度を維持し且つできる限り小さなメモリマップを作成するために、データ値のほとんどの部分は符号なしデータ及び符号付きデータに対して１４ビット以内であるので、１６ビット符号付きルーチン及び１６ビット符号なしルーチンをデフォルトとして採用する一方で、以下に説明するようにオーバフロー状態を検査する。オーバフロー状態が現れた場合、１６ビットに基づく変換ルーチンから適切なオーバフロールーチンへ移行する。
【００６８】
図１５は、格納、アクセス及び送信のためにデータストリームを生成するためのウェーブレット分解及びハフマンコード圧縮による画像データの漸進的処理を概略的に示す。図１５に図中符号３２８により指示される全体的なプロセスの流れは、何らかの適切な方法により収集され、ダイナミックレンジ調整、画像エンハンスメントなどのために前処理された画像データセット３３０によって始まる。この例ではレベル０として指定されているこの画像は、次に、先に説明したような順方向ウェーブレット変換により分解されて、ＬＬ、ＬＨ、ＨＬ及びＨＨの各データセットを含むデータセット３３２を生成する。次に、同様の順方向ウェーブレット変換により低周波数データセットが分解されて、次のレベルのデータセット３３４を生成する。それに続く各レベルで低周波数データセットに対して更にウェーブレット変換を実行することにより、最終データセット３３６に到達するまで類似のデータセットが生成される。最終データセット３３６は、この例では「ｎ」と示される所望の最低分解能のデータセットであると考えられる。
【００６９】
連続ウェーブレット分解により獲得されたデータセットは次のようにして圧縮される。各レベルで、図中符号３３８により指示するように、変形圧縮ルーチンに従って高周波数データセットを圧縮する。この変形ルーチンにおいては、全ての処理は、予測誤差値ではなく、データセットの実際値を使用するという点を除いて先に説明した処理とほぼ同一である。すなわち、図６に示すステップ２８０〜２９０を実行せず、部分領域解析、最適コードテーブル選択などの他のステップをほぼ同様にして実行するのである。高周波数ウェーブレット変換データセットに対して実行される変形圧縮ルーチンは、誤差値を予測又は計算する必要なく本発明の技術を直接に適用することを可能にするようにウェーブレット変換データは既に相関解除されているという認識に基づいている。
【００７０】
最低レベルより高いレベルごとの低周波数データセットを更に分解するため、それらのデータセットを記述する情報は、最も低いレベルの低周波数データセット（すなわち、ｎ番目のレベルの低周波数データセット）を除いて低レベルに維持される。この実現形態では、このデータセットは、図１５に図中符号３４０により指示するように、先に説明した予測誤差圧縮技術に従って圧縮される。
【００７１】
図１５に要約した伸長及び圧縮に関していくつかのポイントを指摘しておくべきである。第１に、当業者には理解されるであろうが、解析されるデータの大きさと型に応じて、先に説明したハフマンコードテーブルの値、部分領域長さ及びその他の特定のパラメータは所望の圧縮比及び圧縮速度を提供するように適応される。更に、低周波数データセットの連続分解の結果、データセットは徐々に小さくなる（両方向に半減する）ため、それらのデータセットは本発明の技術の多重分解能圧縮及び伸長の面に関して利用可能なレベルのいずれにおいてもアクセス、送信及び再構成が可能になる。
【００７２】
図１５に要約したような高周波数データセット及び低周波数データセットの圧縮に続いて、図中符号３４２により指示するように、得られたデータをデータストリーム又はファイルとしてコンパイルする。この実施例では、データストリームは記述ヘッダ３４４と、それに続き、最低分解能のデータ（低周波数圧縮データ及び高周波数圧縮データを含む）の第１のセット３４６と、各々が対応するレベルの高周波数圧縮データを含む後続データセット３４８とを含む一連のデータセットとを含む。この実現形態においては、データストリーム又はファイルは、多重分解能方式のバージョン、順方向変換の種類（符号付き／符号なし、オーバフローを伴う／伴わない、以下の説明を参照）、ウェーブレット分解のレベルの数、各サブバンドレベル（分解能）の行及び列の値、並びに最小から最大までの全てのサブバンドの圧縮サイズを記述するヘッダを含む。また、最低レベルの低周波数データセットは先に説明した予測圧縮を使用して圧縮されるが、各レベルの高周波数データセットは適切な非予測又は変形圧縮方式を使用して圧縮される。圧縮ストリームの最上位置にデータ格納ヘッダを格納するのに加えて、医療診断に関連して、その他の要素をＤＩＣＯＭヘッダに格納しても良い。本発明の一実現形態においては、それらの要素はレベルの数「ｎ」、行（rr）値（rr(n),rr(n-1),...,rr(0)）、列（cc）値（cc(n),cc(n-1),...,cc(0)）、及び各レベルの圧縮データサイズ（cxebyte）（cxebyte(n),cxebyte(n-1),...,cxebyte(0)）を含む。
【００７３】
先に述べた通り、処理及び格納の観点から効率の良い実現形態を提供するために、本発明の一実施例は１６ビット処理を実行し、３２ビット処理は入力データに要求される場合に限り実行される。図１６を参照すると、図中符号３５０により指示されるように、この方式に従ったウェーブレット変換の論理が要約されている。この実現形態では、符号付き１６ビットデータと符号なし１６ビットデータに対して１つずつ、符号付きオーバフロー状態と符号なしオーバフロー状態を処理するために１つずつの４つの順方向変換ルーチンが符号化した（オーバフロールーチンは１６ビットルーチンの３２ビットバージョンであった）。従って、ステップ３５２で、符号付きデータ及び符号なしデータに対して順方向変換を実行する。ステップ３５４では、オーバフロー処理が必要であるか否かを判定するためにデータを解析する。必要でなければ、ステップ３５６に示すように変換係数を戻し、処理は先に説明したように継続する。しかし、３２ビット処理が必要である場合には、論理はステップ３５８へ進み、オーバフローを伴って処理を再開し、ステップ３６０に示すようにそのような処理からの変換係数を戻す。８ビット型データ及びカラー型データの処理にも類似の技術を適用できる。
【００７４】
ウェーブレット分解データセットの最低レベル、すなわち、ｎ番目のレベルで使用された圧縮と組み合わせると、上述の方式を図１７に示すように要約できる。全体を図中符号３６２により指示される論理は、順方向変換のために画像データが入力されるステップ３６４で始まる。この実現形態では、４つの順方向ルーチンに対応して４つのルーチンが符号化されている。以下に説明する再構成段階においては、符号化型フラグが使用すべき適切な逆変換ルーチンを報知する。これにより再構成段階は簡略化される。図１７に要約したプロセス流れは、非予測又は変形圧縮方式と共に、それぞれのオーバフロー順方向変換ルーチンにより生成された３２ビット符号付きデータ及び３２ビット符号なしデータを処理するように処理が適応されているような実現形態を反映している。すなわち、ステップ３６６では、３２ビット処理を要求するオーバフローが起こったか否かを判定する。起こっていなければ、ステップ３６８で後続レベルのサブバンド又はデータセットを生成し、ステップ３７０で指示するように、サブバンドの全ての高周波数データセットに対して変形圧縮技術を実行する。先に述べた通り、最低レベル、すなわち、ｎ番目のレベルの低周波数データセットは予測圧縮技術に従って圧縮される。ステップ３６６でオーバフロー処理が必要であると判定された場合には、ステップ３７４でサブバンド又はデータセットを生成し、ステップ３７６に示すように、高周波数データセットを３２ビット処理を経て圧縮する。この場合も、ｎ番目のレベルの低周波数データセットはステップ３７２で予測圧縮方式に従って圧縮される。先に述べた通り、圧縮に使用される圧縮ハフマンコードテーブルは、得られる１８ビット符号付きデータ及び１８ビット符号なしデータを処理するなど、データの緊急事態に従って適応されても良い。本発明の一実現形態では、入力が１６ビットの格納容量を越える場合に符号化及び復号を実行するために追加のコードテーブルを採用している。オーバフロー状態は１８ビット符号付きの最大ビット深さを有する。
【００７５】
上述の技術の一実現形態は、先に挙げた全ての値をアクセスするためにファンクションコールを実行する。これらの要素は圧縮ストリームのヘッダに存在しているため、伸長ルーチン及び逆変換ルーチンには不要である。しかし、ユーザが異なる分解能レベルで画像を表示することを望む場合にはそれらの要素が望まれる。再構成データをバッファすることを別にして、あらゆるユーザについてインタフェースの変更が不要であるように伸長ルーチン及び再構成ルーチンを構成できるであろう。様々な分解能レベルで表示するという特定の要求をもつユーザに対しては、特定ユーザ向けルーチンを開発できるであろう。
【００７６】
上述の技術により作成されるデータストリーム又はファイルマップを図１８に幾分詳細に示す。先に述べた通り、データストリーム又はファイル３４２はヘッダ３４４と、それに続く、ｎ番目のデータセットから始まる圧縮サブバンド又はデータセットのコード値とを含む。これらのデータセグメントの中で、セクション３７８は低周波数及び高周波数のサブバンド又はデータセットを符号化する。続くデータセグメント３４８では、セクション３８０はより高いレベルの高周波数サブバンド又はデータセットを符号化する。また、先に述べた通り、データストリームの中には、圧縮に使用されたハフマンコードテーブル、部分領域長さなどに関する前述の情報を表す追加のコード値が含まれていることに注意すべきである。
【００７７】
図１９は、圧縮データファイルから伸長して、画像を再構成するプロセスを概略的に要約している。全体を図中符号３８２により指示されるプロセスは、最低レベルのデータセット及びその他のデータセットを求めてユーザに提供すべきサイズ又は分解能を通してデータをアクセスすることを含む。すなわち、図１９に要約したように、ヘッダに格納されている情報に従ってファイルからデータをアクセスし、伸長するが、図中符号３８４で指示するように最低レベルの低周波数データセットは先に説明した予測誤差技術に従って伸長される。高周波数サブバンド又はデータセットは、図中符号３８６で指示するように、変形圧縮技術に従って伸長される。すなわち、伸長データを予測誤差として扱うのではなく、結果データを直接にウェーブレット変換係数として扱うのである。
【００７８】
データを所望のレベルまで伸長した後、伸長データに対して逆ウェーブレット変換を実行するが、低レベル画像データセットは次に高い画像レベルの低周波数サブバンドとして利用される。すなわち、逆変換ルーチンは。最低分解能の「ＬＬ」バンドを処理し、それを関連する「ＨＬ」、「ＬＨ」及び「ＨＨ」バンドと組み合わせて、次に高い分解能の「ＬＬ」バンドを生成することにより動作する。画像の全分解能が実現されるまで、又は指定の分解能レベルに達するまで、このプロセスを繰り返す。１ステップ逆変換はｌｌ値、ｈｌ値、ｌｈ値及びｈｈ値、すなわち、最低レベルの値を取り出し、次のレベルのｌｌバンドに関してカッド画素を生成する（最終逆変換で、画像の全分解能画素データを生成する）。
【００７９】
同様に、先に採用して用語に関連させて言うと、１ステップ２次元逆変換は次の一連の等式により決定される。
【００８０】
【数４】
0004187514.tif 000006
【００８１】
本発明の一実現形態では、逆変換の設計は可能な１レベル再構成に関してモジュール方式でなされた。これにより、ユーザは再構成に際して最低分解能から全分解能まで所望のレベルを指定できる。更に、圧縮データストリームにおける順方向変換の型の符号化によって、正しい逆変換ルーチンを使用した再構成が可能になる。
【００８２】
上述の技術により、格納されているサイズ及び分解能のいずれにおいても画像のアクセス、送信及び再構成が可能になることに注意すべきである。更に、ユーザが既にアクセスした画像からのズーミング又は分解能の向上を望む場合、より高い分解能レベルの追加の高周波数バンドをアクセスし、既に提供されているデータと組み合わせて処理し、新たな画像を再構成するだけで良い。
【００８３】
従って、この技術の多重分解能という側面は０から「ｎ」までの特定レベルの画像に関して目標を定めた伸長と再構成を可能にする。ユーザは、医学診断アプリケーションにおけるＤＩＣＯＭヘッダのようなヘッダに存在する情報から圧縮ストリームの適切なサブセットを所望の再構成レベルをレベル選択ルーチンに指示すると共に提供する。その後、画素バッファによりユーザは拡張再構成画像を格納することができる。
【００８４】
上述の新奇な機能性により、ユーザは利用可能な送信帯域幅を効率良く使用できる。医学診断の分野で生成された画像について圧縮結果の例を図２０のテーブル３８８に要約した。この例では、画像行サイズ２０４８、列サイズ２５００の典型的な胸部ＣＲを５レベルに変換している。レベルごとの行サイズ及び列サイズの関連情報と、関連する圧縮バイトとを示す。１０ＭＢ画像は３９０９８４８バイト（テーブルの画像レベルごとに挙げられているバイトの数の和）のサイズに多重分解能圧縮されている。従って、全分解能２０４８ｘ２５００画像を再構成するためには、約３.９ＭＢのデータの送信が必要になるであろう。
【００８５】
しかし、ユーザははるかに少ない量のデータを次のようにしてアクセスしても良い。一例として、典型的なウェブ−クライアントアプリケーションにおいて、ユーザモニタの分解能サイズが１ｋｘ１ｋであると仮定する。テーブル３８８に記載されているデータセットを検討すると、このサイズ制限はほぼレベル１への再構成を可能にすると考えられる。従って、サーバからの送信に要求されるデータは９７９９８８バイト（レベル１までの画像を構成するバイトの和）に等しい。しかし、多くの場合、画像表示要素には全モニタ分解能のサブセットが割り当てられている。そこで、この例では、第１の画像を特に最高の分解能の画像の送信及び再構成と比較して非常に高速なプロセスでレベル２まで再構成でき、送信しなければならないバイト数はわずか２５５４２８バイトにすぎない。多重分解能方式によれば、この後により高いレベルへのズーミングが可能であり、残りの７２４５６０バイトによりレベル１からレベル２画像へ再構成し、その後に残りの２９２９８６０バイトによりレベル１再構成画像から全分解能画像を再構成することができる。
【００８６】
上述の技術を使用して、複数の分解レベルのうちの、クライアントの所望の表示分解能に必要であるレベルのみを選択的に転送することにより、画像データを更に効率良く転送することもできるであろう。まず、クライアントはクライアントの表示装置で画像を表示するために、最低分解レベルＮなどの低い分解能レベルを１つ以上検索する。分解レベルＮ−１から分解レベル１までの間にあるような残りのより高い分解能レベルは、後にクライアントの要求に従って検索されるのに備えてサーバにとどまる。従って、ユーザがクライアントで画像をより高い分解能で表示することを希望した場合、クライアントはその高い分解能を支援するためにサーバから１つ以上のより高い分解能レベルを検索する。残る分解能レベルは、ユーザがそれらのレベルを要求するローカル分解能表示を指令するまで、サーバのみに常駐している。
【００８７】
図２１は、サーバ４２０と、サーバ４０２から離れたクライアント４０４とを具備する画像送信システム４００の一例を示す。サーバ４０２には複数の画像データ４０５があり、クライアント４０４はそのビューポート４０６で所望の分解能で画像を表示するのに必要とされる所望の画像分解能を検索するためにサーバ４０２をアクセスできる。画像データ４０５はヘッダ４０８と、ウェーブレット分解により生成され且つ上述の圧縮技術のうちのいずれかにより圧縮された、画像分解能レベルに対応するデータブロックなどの複数の画像データブロックとを含む。例えば、画像データ４０５は、レベルＮからレベル１まで徐々に高くなる分解能レベル（例えば、図１５及び図１８を参照）に対応する画像分解能レベル４１０、４１２、４１４及び４１６などの画像データブロックを含んでいても良い。矢印４１８により指示するように、ビューポート４０６での表示のためにクライアント４０４が要求する特定の画像分解能に基づいて、これらの画像分解能レベル４１０、４１２、４１４及び４１６のうちの１つ以上が送信される。例えば、クライアント４０４が画像レベル４１０及び４１２を要求する相対的に低い画像分解能の表示を希望したとする。これらの画像レベル４１０及び４１２がクライアント４０４でローカルに利用不可能である場合、クライアント４０４は、以下に詳細に説明するように、自動要求手続き又は手操作要求手続きによりサーバ４０２から必要な画像レベル４１０及び４１２を要求することになる。クライアント４０４がサーバ４０２から画像データを検索する間、画像データ（すなわち、画像レベル４１０及び４１２の画像データ）はクライアント４０４により記憶装置４２０に格納／キャッシュされても良い。その後、クライアント４０４が相対的に高い画像分解能（すなわち、画像レベル４１０及び４１２より高い分解能）を希望した場合には、クライアント４０４はサーバ４０２から必要な画像レベルを要求し、それらの画像レベルを記憶装置４２０に格納する。以下に詳細に説明するが、画像送信システム４００は、画像レベル４１０から４１６の画像分解能をビューポート４０６の所望の分解能と比較することにより、ビューポート４０６の所望の分解能に必要な画像分解能レベルの数を判定する。システム４００は、サーバ４０２からの画像データの最初の検索又はその後の検索においてヘッダ４０８を読み取ることにより、画像レベル４１０から４１６の分解能特性を獲得しても良い。
【００８８】
図２２及び図２３に示すように、サーバ４０２にある画像レベル４１０から４１６がビューポート４０６と一致する分解能を有しているとは限らない。例えば、ビューポート４０６は大きさ４２４及び４２６（例えば、２５６ｘ２５６画素）を有するビューポート分解能４２２を有する。先に詳細に説明した通り、本発明の技術は画像レベル４１０から４１６を徐々に何度か組み合わせて、画像４２８の連続して分解能が高くなるような表示を生成する。この再構成プロセスのいずれかの時点で、画像レベル４１０から４１６のうちの１つ以上を組み合わせて、大きさ４３２及び４３４を有する画像分解能４３０を提供する。以下に更に詳細に説明するが、ビューポート４０６における所望の表示分解能に要求される画像レベルは、主に、画像４２８をクライアントビューポート４０６に適応させるために要求される分解能スケーリングの両によって決まる。例えば、画像レベル４１０及び４１２は、それぞれ、１４０Ｘ１４０画素と、２８０Ｘ２８０画素の画像分解能を提供するであろう。
【００８９】
システム４００は、画像４２８の分解能をビューポート４０６と比較し、画像４２８をビューポート４０６に適応するために必要はスケーリングを判定し、必要なスケーリングをスケーリング閾値係数（ＳＴ）と比較することにより、必要画像レベルを識別する。これらの比較には何らかの適切なスケーリング閾値係数（ＳＴ）を使用すれば良いのであるが、所望のアプリケーションに対して許容しうる画質を維持するためにＳＴ係数を使用すると有利であろう。従って、画質を維持するためには約５０％から７０％（例えば、１.６、すなわち、６０％のスケーリング）という経験上のスケーリング閾値係数（ＳＴ）が特に適していると思われる。動作中、システム４００はこの係数ＳＴを使用して、ビューポート４０６での表示には相対的に低い画像分解能（すなわち、画像レベル４１０）が適切であると判定する。従って、クライアント４０４は次のステップでサーバ４０２から画像レベル４１０を獲得する。次に、クライアント４０４は画像４２８を再構成し、ビューポート４０６に適合するように再構成画像４２８をスケーリングアップする。システム４００が係数ＳＴを使用して、ビューポート４０６で許容しうる表示を行うためには相対的に高い画像分解能（すなわち、画像レベル４１２）が必要であると判定した場合には、クライアント４０４は次のステップで画像レベル４１２を獲得する。次に、クライアント４０４は検索した画像レベル４１２と、先に格納され、クライアント４０４で表示されていた画像レベル４１０を使用して画像４２８を再構成する。その後、ビューポート４０６に適合するように再構成画像４２８をスケーリングダウンする。このスケーリング閾値係数（ＳＴ）については以下に図２４、図２５及び図２７を参照して更に詳細に説明する。
【００９０】
図２２に示すように、画像４２８は、画像分解能４３０を画像４２８の鮮明度を維持するスケーリング閾値係数（ＳＴ）より小さい係数だけビューポート分解能４２２にスケーリングアップすることにより、ビューポート４０６に適合されている。従って、画像送信システム４００はクライアント４０４に、ビューポート分解能４２２より相対的に低い分解能を有する画像レベルのみを獲得するように指示する。例えば、画像分解能４３０が画像レベル４１２に対応している場合、クライアント４０４は画像レベル４１２以下の画像レベルのみを獲得する。
【００９１】
これに対し、図２３に示すように、画像４２８は、画像分解能４３０を小数スケーリング係数によってビューポート分解能４２２へスケーリングダウンすることによりビューポート４０６に適合されている。この方式では、相対的に低い画像レベルはスケーリング閾値係数（ＳＴ）に基づく過剰スケーリングを必要としたため、システム４００は画像レベル４１０から４１６のうちの相対的に高い画像レベルを選択していた。例えば、画像レベル４１０は画像４２８をビューポート４０６に適合させるために１.７のスケーリング係数を要求するが、画像レベル４１２は画像４２８をビューポート４０６に適合させるために０.９のスケーリング係数を要求する。経験に基づき、スケーリング閾値係数（ＳＴ）を１.６に設定した場合、システム４００はビューポート４０６においてビューポート分解能４２２で画像４２８を再構成するに際して許容画像分解能レベルとして画像レベル４１２を識別するであろう。従って、画像送信システム４００はビューポート４０６内で許容画像鮮明度を確保するために相対的に高い画像分解能レベルを獲得する。
【００９２】
図２４は、画像送信システム４００の初期画像検索表示プロセス４３８を示すフローチャートである。図示されているように、プロセス４３８は、サーバから画像を要求する（ブロック４４０）ことにより進行し、その後、サーバからクライアントへ画像データストリームが送信される（ブロック４４２）。クライアントへ送信される画像データストリームは図１８及び図２１に最も明確に示されている。その後、クライアント４０４は画像データストリームのヘッダ４０８を読み取り（ブロック４４４）、画像レベルの画像分解能特性などの画像特性をヘッダ４０８から取り出す（ブロック４４６）。
【００９３】
先に述べ、また、以下に詳細に説明するように、プロセス４３８は次にクライアントビューポートでの表示のための画像分解能レベル（ＩＲＬ）を選択する（ブロック４４８）。プロセス４３８は、クライアント４０４がサーバ４０２から画像データストリーム４０７を検索すると同時に、又はオンザフライ方式で画像分解能レベルＩＲＬを選択する。従って、クライアント４０４は、まず、画像データ４０５のセット全体を検索するのであるが、このデータセットは画像を再構成するための画像分解能レベルが徐々に高くなる順序で検索される。クライアント４０４は、クライアントビューポート４０６で画像を見るのに適する選択画像分解能レベルＩＲＬに至るまで画像データストリーム４０７を検索し続ける（ブロック４５０）。画像データ４０５の十分な部分が選択分解能レベルＩＲＬに対して検索されたとプロセス４３８が判定すれば（ブロック４５２）、プロセス４３８は画像データストリーム４０７の検索を停止する（ブロック４５４）。しかし、選択分解能レベルＩＲＬに対して検索された画像データ４０５の部分が不十分である場合には（ブロック４５２）、プロセス４３８は、選択分解能レベルＩＲＬでの表示のために十分な画像分解能レベルが検索され終わるまで画像データストリーム４０７を検索し続ける（ブロック４５６）。
【００９４】
次に、画像４２８のローカル表示のために、検索した画像データストリームをクライアント４０４の記憶装置４２０に格納／キャッシュする（ブロック４５８）。画像データストリーム４０７から画像データを伸長し（ブロック４６０）、検索した分解能レベルＩＲＬに至るまでの画像レベルから画像４２８を再構成し、画像４２８をクライアントビューポート４０６に適合するようにスケーリングする（ブロック４６２）ことにより、ビューポート４０６で表示すべく画像４２８を調整する。図１９は画像分解技術の一例を示し、図２２、図２３及び図２６は画像スケーリング技術の一例を示す。次に、クライアントビューポート４０６に選択分解能レベルＩＲＬで画像４２８を表示させる（ブロック４６４）。先に説明した通り、初期表示のために選択される画像分解能レベル（ＩＲＬ）は、ビューポート４０６での表示に際して画像をスケーリング閾値係数（ＳＴ）を越えてスケーリングすることを要求しない最低の画像分解能レベルである。
【００９５】
先に説明した通り、本発明の技術は、画像４２８をクライアントビューポート４０６で表示するために必要に応じて画像データの選択部分のみを転送することによりデータ転送効率を改善する。従って、サーバ４０２からクライアント４０４へ転送されている画像データストリーム４０７は、クライアントビューポート４０６で所望のビューポート分解能４２２で表示するのに十分な画像データが検索され終わった時点で中断される。図２５は、画像分解能レベル（ＩＲＬ）の選択プロセス４６６の一例を示すフローチャートである。図示されているように、プロセス４６６は、サーバ４０２に格納されている利用可能な分解能レベルの各々で画像分解能（ＩＲ）を判定し（ブロック４６８）、且つクライアントビューポート４０６のビューポート分解能４２２を判定する（ブロック４７０）ことにより進行する。先に述べた通り、プロセス４６６は画像データストリーム４０７のヘッダ４０８から画像分解能を取り出すことができる。その後、プロセス４６６は、ビューポート分解能４２２を徐々に高くなる画像分解能と比較することにより、分解能レベルを選択する（ブロック４７２）。
【００９６】
この分解能選択ブロック４７２は、デフォルトスケーリング閾値係数を使用することにより（ブロック４７４）又は所望のスケーリング閾値係数を使用することにより（ブロック４７６）実行されれば良い。先に説明したように、プロセス４６６は許容画像鮮明度及びその他の画像特性を維持するために適切などのようなスケーリング閾値係数（ＳＴ）を利用しても良い。スケーリング閾値係数（ＳＴ）を使用して、分解能選択ブロック４７２はビューポート分解能（ＶＲ）に照らして画像分解能（ＩＲ）を評価する。プロセス４６６は、許容分解能レベルが識別されるまで、サーバ４０２に格納されている画像分解能レベル（ＩＲＬ）の各々を解析する（ブロック４７８）。
【００９７】
従って、分解能評価はステップＩ＝０で最低の画像分解能（レベルＮのＩＲＬ）を解析することにより始まる（ブロック４８０）。画像分解能は、ビューポート分解能（ＶＲ）がスケーリング閾値（ＳＴ）によりＩＲ（Ｎ−ｉ）ＸＳＴにスケーリングされた画像分解能（すなわち、レベルＮのＩＲ）より大きいか否かを判定する（ブロック４８２）ことにより解析される。ビューポート分解能（ＶＲ）がスケーリング済み画像分解能ＩＲ（Ｎ−ｉ）ＸＳＴ以下であれば、画像分解能レベルＮはビューポート４０６における表示に適している。従って、分解能選択ブロック４７２は画像分解能ＩＲ（Ｎ−ｉ）に対応する画像分解能レベルＩＲＬを選択する（ブロック４８４）。しかし、ビューポート分解能（ＶＲ）がスケーリング済み画像分解能ＩＲ（Ｎ−ｉ）ＸＳＴを越えている場合には、分解能選択ブロック４７２はサーバ４０２で他のより高い画像分解能レベルがまだ利用可能であるか否かを判定する（ブロック４８６）。より高い画像分解能レベルを利用できなければ（ブロック４８６）、ビューポート４０６での表示のために現在分解能レベルを選択する（ブロック４８４）。より高い分解能レベルを利用できる場合には（ブロック４８６）、分解能選択ブロック４７２はステップＩ＝Ｉ＋１で先に評価した分解能レベル（すなわち、レベルＮ）に続く次に低い分解能レベル（すなわち、Ｎ−１）を評価する（ブロック４８８）。
【００９８】
分解能選択ブロック４７２は、プロセス４６６がスケーリング閾値係数（ＳＴ）を満たすほど十分に高いか又は最大画像分解能（ＩＲ）レベル１を具現化する画像分解能レベル（ＩＲＬ）を識別するまで、ブロック４８０、４８２、４８６及び４８８をループし続ける。プロセスが適切な高さの画像分解能レベル（ＩＲＬ）を識別し、選択したならば、プロセス４６６は選択分解能レベル（ＩＲＬ）を使用して、サーバ４０２からの選択分解能レベル（ＩＲＬ）以下の画像レベルの選択的検索を実行する。この実施例では、画像送信システム４００はビューポート４０６における所望の画像の初期検索及び表示と、その後の検索及び表示の双方に選択分解能レベルを使用する。
【００９９】
図２４を参照して先に述べたように、プロセス４６６は画像データストリーム４０７中の画像データ４０５を検索し、格納し、選択分解能レベル（ＩＲＬ）に至るまで伸長する。ビューポート４０６で画像４２８を最適に表示するために、画像４２８をビューポート４０６に合わせて拡張又は縮小するように適切な係数により画像４２８をスケーリングする。図２６は、適切なスケーリングアップ又はスケーリングダウンの係数を判定するために画像分解能（すなわち、選択画像分解能レベル）をビューポート分解能（ＶＲ）と比較する（ブロック４９２）スケーリングプロセス４９０の一例を示すフローチャートである。画像分解能がビューポート分解能より大きければ（ブロック４９４）、スケーリングプロセス４９０はビューポート分解能に適合させるために画像分解能４３０をスケーリングダウンする（ブロック４９６）。例えば、スケーリングプロセス４９０は、ビューポート４０６に画像４２８を適合させるために、画像分解能４３０を０.８０又は０.９０の係数によりスケーリングする。画像分解能がビューポート分解能より小さい場合には（ブロック４９４）、スケーリングプロセス４９０はビューポート分解能に適合させるために画像分解能４３０をスケーリングアップする（ブロック４９８）。例えば、スケーリングプロセス４９０は画像分解能４３０を１.０から１.６の係数によりスケーリングする。先に述べた通り、スケーリング閾値係数（ＳＴ）はスケーリングの上限を形成する。しかし、画像４２８が相対的に小さいか、又はビューポート４０６が相対的に大きいなど場合によっては、画像データ４０５をビューポート４０６へ許容しうる程度に再構成するために全画像データセット４０５が必要になることもある。このような状況では、スケーリングはスケーリング閾値（ＳＴ）に限定されない。上述のスケーリングプロセス４９０は双三次補間又は双一次補間などの何らかの適切なスケーリング技術を利用できるであろう。
【０１００】
先に述べた通り、画像送信システム４００はクライアント４０４における画像４２８の表示に際して必要に応じて画像データの連続自動検索に利用できる。図２７は、クライアント４０４が様々な表示機能及び指令に従ってトリガできる連続データ検索表示プロセス５００の一例を示すフローチャートである。例えば、プロセス５００は、クライアント４０４側の記憶装置４２０にローカルに格納されているより高い分解能の画像データを要求するズーミング指令に応答して、自動的に又はユーザとの対話によって追加画像データを検索することができる。この実施例では、プロセス５００はビューポート４０６での表示のために必要に応じて自動的に追加画像データを検索する。
【０１０１】
例えば、プロセス５００は、ユーザがマウスを使用して（例えば、マウスの左側のボタンを押し下げたままで、ビューポート４０６を拡張又は縮小することにより）画像４２８をズームイン又はズームアウトした後に追加画像データを収集しても良い。マウスボタンを放すと、プロセス５００は新たなビューポート分解能で表示するために追加画像データが必要であるか否かの判定を実行する。また、ユーザは画像４２８の対話型ズーミングの間にコントロールキー（すなわち、「Ｃｔｒｌ」キー）を押し下げたままにしておくことにより、追加画像データ（すなわち、徐々に高くなる画像分解能レベル）の自動検索を阻止することも可能である。このコントロールキー機能は、画質を維持するために追加画像データを検索するか、又は単にローカルに格納されている画像データによって処理を進めるかのいずれかをユーザに選択させる。上述の対話型ズーミング操作の間、プロセス５００は、対話型ズームの性能を向上させるために、双一次補間などの相対的に単純な補間技術により画像４２８をビューポート４０６に対してスケーリングしても良い。しかし、プロセス５００は、対話型ズーミングが完了した後（すなわち、ユーザがマウスボタンを放した後）に画像４２８をスケーリングするために、双三次補間などのより複雑な又はより正確な補間技術を使用しても良い。
【０１０２】
その他の様々なユーザ指令も本発明の技術の範囲内に含まれる。例えば、プロセス５００は１Ｘ、２Ｘ、３Ｘ、...１０Ｘ又はそれより高い分解能のズーム指令、全分解能表示指令、フィットトゥビュー指令、ズームイン又はズームアウトのためのマウスのダブルクリック、関心領域（ＡＯＩ）のマウス選択、画像分解能レベルアップ又はレベルダウン指令（例えば、１からＮの画像レベルのうちのいずれか１つへの指令）、手操作シネ動作（例えば、１からＮの画像レベルなどの画像のスタックのローミング）、又は他の何らかのそのようなズーミング指令によりトリガされても良い。手操作シネ動作においては、本発明の技術は相対的に単純な補間技術を採用し、動作中、ユーザが画像のスタックを（例えば、マウスボタンを押し下げたままにしておくことにより）対話形式でブラウジングしている間により高い性能を提供するために相対的に低い画像分解能レベルで画像４２８を表示する。しかし、スタック中の所望の画像が選択されると（例えば、マウスボタンを放すと）、上述のシネ動作は相対的により複雑又は正確な補間プロセスに戻り、選択された画像を表示するのに必要とされる追加画像データを検索する。
【０１０３】
図２７に示すように、クライアント４０４は所望のビューポート分解能へのズームを開始することにより連続検索表示プロセス５００をトリガする（ブロック５０２）。ユーザが「ズームアウト」操作を開始した場合（ブロック５０４）、プロセス５００はクライアント記憶装置／キャッシュの最高格納分解能レベル（ＨＳＲＬ）を使用する（ブロック５０６）。追加の画像分解能レベルは不要であり、最高格納分解能レベル（ＨＳＲＬ）はビューポート４０６でのローカル表示に際して最適の画像分解能であるので、最適の画像表示を実行するために最高格納分解能レベルが使用される。しかし、性能を向上させるために、プロセス５００はこれより低い分解能レベルを利用しても良い。その場合、プロセス５００は最高格納分解能レベル（ＨＳＲＬ）を所望のビューポート分解能にスケーリングする（ブロック５０８）。この実施例では、プロセス５００は、画像４２８のスケーリングアップ又はスケーリングダウンに関わらず、デフォルトとして最高の検索格納画像分解能レベル（ＨＳＲＬ）を使用し続ける。例えば、ユーザが画像４２８の全分解能表示を得るために画像４２８をダブルクリックした場合、ユーザが画像を元のサイズに戻すためにダブルクリックした後でも、全分解能表示のために収集された追加画像データはそのまま使用される。
【０１０４】
ユーザが「ズームイン」操作を開始した場合には（ブロック５０４）、連続検索表示プロセス５００はクライアントの記憶装置／キャッシュの最高格納分解能レベル（ＨＳＲＬ）の画像分解能（ＩＲ）を判定する（ブロック５１０）。先に述べた通り、ユーザはデフォルトスケーリング閾値（ＳＴ）によって処理を進める（ブロック５１２）か、又は所望のスケーリング閾値を設定する（ブロック５１４）かのいずれかを選択できる。いずれの場合にも、プロセス５００は画像４２８の許容しうる鮮明度及び特性を維持するためにスケーリング閾値及び係数（ＳＴ）を利用する。選択されたスケーリング閾値（ＳＴ）を使用して、プロセス５００はビューポート分解能（ＶＲ）に対して適切な画像分解能（ＩＲ）を選択する。従って、プロセス５００は、スケーリング閾値係数（ＳＴ）を満足させるまで、クライアント４０４における最高格納分解能レベル（ＨＳＲＬ）と、サーバにおける徐々に高くなる画像分解能レベル（ＩＲＬ）とを評価する（ブロック５１６）。
【０１０５】
ステップＩ＝０で、プロセス５００は最高格納分解能レベル（ＨＳＲＬ）を評価する（ブロック５１８）。画像分解能は、ビューポート分解能（ＶＲ）がスケーリング閾値（ＳＴ）によりＩＲ（ＨＳＲＬ）ＸＳＴの値にスケーリングされた画像分解能（すなわち、レベルＨＳＲＬにおけるＩＲ）より大きいか否かを判定することにより解析される（ブロック５２０）。ビューポート分解能（ＶＲ）がスケーリング済み画像分解能ＩＲ（ＨＳＲＬ）ＸＳＴ以下である場合、画像分解能レベルＨＳＲＬはビューポート４０６での表示に適している。従って、プロセス５００はＩＲ（ＨＳＲＬ）の画像分解能に対応する画像分解能レベル（ＩＲＬ）を選択する（ブロック５２２）。しかし、ビューポート分解能（ＶＲ）がスケーリング済み画像分解能ＩＲ（ＨＳＲＬ）ＸＳＴを越えている場合には、プロセス５００はサーバ４０２で更に別のより高い画像分解能レベルがまだ利用可能であるか否かを判定する（ブロック５２４）。より高い画像分解能レベルが利用不可能である場合（ブロック５２４）、ビューポート４０６での表示のために現在分解能レベル（すなわち、ＨＳＲＬ）を選択する（ブロック５２２）。より高い画像分解能レベルを利用可能である場合には（ブロック５２４）、プロセス５００はサーバ４０２から次に高い画像分解能レベル（すなわち、ＩＲＬ＝ＨＳＲＬ−１）を検索する（ブロック５２６）。次に、検索された高い画像分解能レベル（ＩＲＬ）をクライアント４０４で格納／キャッシュし（ブロック５２８）、そこで検索されたＩＲＬをクライアント４０４に格納／キャッシュされた既存の画像データと統合する（ブロック５３０）。例えば、図１８に示すように、サーバ４０２から検索された高い画像分解能レベル（ＩＲＬ）を圧縮画像データストリーム４０７に追加する。
【０１０６】
次に、プロセス５００は、この第２の評価ループＩ＝Ｉ＋１ではＩＲＬ＝ＨＳＲＬ−１として定義される次に高い画像分解能レベルを評価する（ブロック５３２）。先に述べた通り、プロセス５００はビューポート分解能（ＶＲ）を、画像レベルＨＳＲＬ−１では分解能レベル１つ分だけ高くなっている画像分解能（ＩＲ）と比較する（ブロック５２０）。スケーリング済み画像分解能ＩＲ（ＨＳＲＬ−１）ＸＳＴがビューポート分解能（ＶＲ）を越えている場合、プロセス５００はビューポート４０６における表示のために画像分解能レベルＨＳＲＬ−１を選択する（ブロック５２２）。ビューポート分解能（ＶＲ）がスケーリング済み画像分解能ＩＲ（ＨＳＲＬ−１）ＸＳＴを越えている場合、プロセス５００はサーバ４０２で更に別のより高い画像分解能レベルがまだ利用可能であるか否かを判定する（ブロック５２４）。より高い画像分解能レベルが利用不可能である場合（ブロック５２４）、プロセス５００はビューポート４０６での表示のために現在分解能レベル（すなわち、最高格納分解能レベル）を選択する（ブロック５２２）。そうでない場合には、プロセス５００はサーバ４０２から次に高い画像分解能レベル（すなわち、ＩＲＬ＝ＨＳＲＬ−２）を検索する（ブロック５２６）。次に、プロセス５００は検索したＩＲＬをクライアント４０４で格納／キャッシュし（ブロック５２８）、検索／格納されたＩＲＬをクライアント４０４で格納・キャッシュされている既存の画像データと統合する（ブロック５３０）。
【０１０７】
プロセス５００は、スケーリング閾値（ＳＴ）を満足させるほど十分に高いか又は最大画像分解能レベル（ＩＲＬ＝０）を具現化する画像分解能レベル（ＩＲＬ）を識別するまで、ブロック５１８、５２０、５２４、５２６、５２８、５３０及び５３２をループする。プロセス５００が適切な高さの画像分解能レベルを識別し且つ選択したならば（ブロック５２２）、選択された分解能レベル（ＩＲＬ）を伸長し（ブロック５３４）、クライアントビューポート４０６に適合するようにスケーリングし（ブロック５３６）、クライアントビューポート４０６において選択され且つスケーリングされた分解能レベルで表示する（ブロック５３８）。
【０１０８】
本発明の技術は画像４２８の多様な画像分解能レベル特性及び伸長レベル特性を表示することもできるであろう。例えば、システムは現在画像分解能又は分解能レベルと、最大画像分解能又は総分解能レベルとの関係を指示するテキストブロックを提供しても良い。例えば、このテキストブロックは、現在分解能レベルをＩＲとし、画像４２８の総分解能レベルをＮとして、ＩＲ／Ｎとフォーマッティングされても良い。システムがビューポート４０６で画像４２８の最大分解能を表示する場合、テキストブロックは、ビューポート４０６で表示中の画像４２８について全ての利用可能な画像データが収集されており且つ現在使用されていることを指示するために、「ＦＵＬＬ」又は「ＦＵＬＬＲＥＳ」と表現されるであろう。「ＦＵＬＬ」分解能標識は、画像データが上述の画像伸長処理技術を受けた場合に画像４２８の全分解能を指示するために使用される。これに対し、「ＦＵＬＬＲＥＳ」分解能標識は、画像データが上述の分解技術及び伸長技術を受けなかった場合に、画像４２８の全分解能を指示するために使用される。
【０１０９】
更に、テキストブロックは画像４２８のスケーリング／ズーミング特性を指示できるであろう。例えば、テキストブロックは、現時点で表示されている画像４２８のズーム率をｘ.ｘとするときに「ＺＦ：ｘ.ｘ」のフォーマットでスケーリング／ズーミング特性を表示する。ズーム率は、ビューポート４０６に適合させるために様々な度合でスケーリングアップ又はスケーリングダウンされた画像４２８の現在スケーリング状態をユーザに報知する。従って、ユーザは、画像がその実際の分解能を越えてどの程度まで拡張されているかによって表示画像の相対精度を仮定できるであろう。また、テキストブロックは、画像４２８をスケーリングするために使用される、双一次補間又は双三次補間などの補間の種類も表示できるであろう。
【０１１０】
ヘッダ４０８からの情報を表示するために画像情報ウィンドウを規定しても良いであろう。ヘッダ情報は分解能レベルの総数（すなわち、１からＮ）、各分解能レベルの行と列、及び各圧縮分解能レベルのメモリサイズ（例えば、バイト）を含む。ヘッダ情報は様々な患者情報、医学撮影システムデータ、又は画像データストリーム４０７の１つ以上のヘッダ４０８からの他の何らかの所望の情報を更に含んでいても良い。
【０１１１】
本発明の技術は、サーバ４０２から画像データセット全体を収集し且つ収集した画像４２８をビューポート４０６において全分解能で（すなわち、１Ｘズーム）表示するためにショートカットを実行しても良い。これは、ユーザが画像画素とビューポート画素との１対１の関係をもって全データセットを有することを保証する。先に説明した通り、画像検索、スケーリング及びビューポート４０６での表示を高速に処理するために他にも様々なズーミング／スケーリングのショートカットを規定して良い。
【０１１２】
本発明は様々な変形及び代替形態が可能であるが、例として図面に特定の実施例を示し、それを詳細に説明した。しかし、本発明はここで開示した特定の形態に限定されないことを理解すべきである。本発明は特許請求の範囲により定義される本発明の趣旨の範囲内に入るあらゆる変形、等価の構成及び代替構成を含む。
【図面の簡単な説明】
【図１】  本発明の技術のいくつかの面に従って画像データを受信し且つ格納するための画像管理システムの一例、図示されている例においては医用画像情報システム、略してＰＡＣＳの概略図。
【図２】  複数の画像データセット、圧縮データ及び記述情報を含むファイルにおいて格納されている画像データを参照するためのデータベースのコンテンツの概略図。
【図３】  図１のシステムで受信され、圧縮され且つ格納される型の典型的な画像を表す図。
【図４】  部分領域の特性に基づく部分領域の最適の圧縮のために、複数の部分領域に細分された１つの画像に沿った画素化データの強さを表すグラフ。
【図５】  圧縮を目的とする画像データの解析において使用される画素近傍の概略図。
【図６】  本発明の技術の面に従って画像データを圧縮し且つ伸長するための制御論理の例を示すフローチャート。
【図７】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図８】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図９】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図１０】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図１１】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図１２】  図６に示すプロセスの間に本発明の技術に従って画像データの部分領域を最適に圧縮するために使用される圧縮コードテーブルの形態をとるルックアップテーブルの例を示す図。
【図１３】  記述ヘッダと、圧縮ヘッダと、部分領域ごとの圧縮データのブロックとを含む画像データセットの一例の概略図。
【図１４】  多重分解能圧縮画像データセットの生成を可能にする、本発明の技術の別の面に従った画像データの漸進的ウェーブレット分解を示すプロセスマップ。
【図１５】  多重分解能圧縮画像データセットの生成の圧縮のための結果データの圧縮と関連させて図１４の漸進的ウェーブレット分解を示すプロセスマップ。
【図１６】  本発明の一実施例に従って順方向ウェーブレット変換を実行する際の論理の一例を示すフローチャート。
【図１７】  多重分解能画像データ圧縮のために順方向ウェーブレット分解を実行するための論理の一例を示すフローチャート。
【図１８】  多重分解能圧縮におけるヘッダ及び圧縮データのブロックを含む画像データセットの一例を示す概略図。
【図１９】  所望の分解能の画像を得るための画像データ伸長及び逆方向ウェーブレット変換を示すプロセスマップ。
【図２０】  本発明の技術を経て得られる圧縮レベルの例を示すテーブル。
【図２１】  サーバと、画像データを表示するためのビューポートを有するクライアントとの間の画像送信システムの一例を示す図。
【図２２】  画像分解能をビューポートに適合するように適応させるためのスケーリングアップ方式の一例を示す図。
【図２３】  画像分解能をビューポートに適合するように適応させるためのスケーリングダウン方式の一例を示す図。
【図２４】  図２１に示す画像送信システムの初期画像検索表示プロセスを示すフローチャート。
【図２５】  ビューポートでの表示のために適切な画像分解能レベルを選択する選択プロセスの一例を示すフローチャート。
【図２６】  図２２及び図２３に示すような、画像分解能をビューポートに適応させるためのスケーリングプロセスの例を示すフローチャート。
【図２７】  図２１に示す画像送信システムの連続データ検索表示プロセスの一例を示すフローチャート。
【符号の説明】
１０…医用画像情報システム（ＰＡＣＳ）、１２、１４、１６…撮影システム、１８…ファイルサーバ、２０…圧縮／伸長インタフェース、１９…入出力インタフェース、２２…内部クライアント、２４…プリンタインタフェース、２６…プリンタ、２８…データベースサーバ、３０…アーカイブ、３２…圧縮／伸長ライブラリ、３４…放射線科情報システム（ＲＩＳ）、３６…病院情報システム（ＨＩＳ）、３８…外部クライアント
【図１】
0004187514.tif 000007
【図２】
0004187514.tif 000008
【図３】
0004187514.tif 000009
【図４】
0004187514.tif 000010
【図５】
0004187514.tif 000011
【図６】
0004187514.tif 000012
【図７】
0004187514.tif 000013
【図８】
0004187514.tif 000014
【図９】
0004187514.tif 000015
【図１０】
0004187514.tif 000016
【図１１】
0004187514.tif 000017
【図１２】
0004187514.tif 000018
【図１３】
0004187514.tif 000019
【図１４】
0004187514.tif 000020
【図１５】
0004187514.tif 000021
【図１６】
0004187514.tif 000022
【図１７】
0004187514.tif 000023
【図１８】
0004187514.tif 000024
【図１９】
0004187514.tif 000025
【図２０】
0004187514.tif 000026
【図２１】
0004187514.tif 000027
【図２２】
0004187514.tif 000028
【図２３】
0004187514.tif 000029
【図２４】
0004187514.tif 000030
【図２５】
0004187514.tif 000031
【図２６】
0004187514.tif 000032
【図２７】
0004187514.tif 000033