(57)【特許請求の範囲】
【請求項１】
サーバクライアント環境における方法であって、
クライアントが画像サイズおよび解像度の最大数を判定できるようにするための情報を、ＨＴＭＬ書類又はＸＭＬ書類として提供し、
圧縮されたデータのコードストリームの１つ以上のタイルに関する要求を受信し、および
圧縮されたデータの前記コードストリームを分析して前記要求に関連するパケットを、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対するパケットも含めて見出すステップを有し、
前記分析の結果として見出されるパケットは、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対する総てのパケットを含み、
前記コードストリームのタイル部分ヘッダは、ＣＯＤ又はＣＯＣマーカーを含んでいない、ことを特徴とする方法。
【請求項２】
クライアントと、
ネットワークを通じて前記クライアントに接続されるサーバと
を有するシステムであって、前記サーバは、
クライアントが画像サイズおよび解像度の最大数を判定できるようにするための情報を、ＨＴＭＬ書類又はＸＭＬ書類として提供し、
圧縮されたデータのコードストリームの１つ以上のタイルに関する要求を受信し、および
圧縮されたデータの前記コードストリームを分析して前記要求に関連するパケットを、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対するパケットも含めて見出す処理を行い、
前記分析の結果として見出されるパケットは、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対する総てのパケットを含み、
前記コードストリームのタイル部分ヘッダは、ＣＯＤ又はＣＯＣマーカーを含んでいない、ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、クライアント／サーバ・システムの技術分野に関し；特に、ＪＰＥＧ２０００コードストリームの画像処理を行うクライアント／サーバ・システムに関する。
【背景技術】
【０００２】
ディジタル画像処理は１９９０年代に２つの重要な技術革新を経験した。第１に、ディジタル画像が一般的に高解像度および高品質になっていることである。例えば、消費者は、写真に近い３メガ画素のディジタル・カメラを利用可能である。６００ｄｐｉまたはそれ以上のスキャナおよびプリンタは、ありふれている。第２に、市民権を得た(populist)インターネットおよび無線技術の出現により、今日の高速ネットワーク化は様々な異質の形式の表示装置を接続する。
【０００３】
画像サイズが大きくなると、画像圧縮は非常に重要である。しかしながら、同一形式の画像に関し、多くの異なる形式の表示装置を取り扱う必要性に起因して、新しい画像圧縮手法が望まれており−その画像圧縮はエンコードだけでなく、伝送およびデコードにおいて柔軟性のあるものである。ＪＰＥＧ２０００画像符号化規格，ITU-T  Rec.T.800/ISO/IEC  154441:2000  JPEG  2000  画像符号化システムは、あるエンコードされた画像を、必要最小量のデータより多くのデコードをすることなしに、異なる解像度、ビット・レートでおよび異なる領域でデコードすることを可能にする。
【０００４】
ＪＰＥＧ２０００規格は、画像をタイル（四角形領域）、小波変換分解(wavelet  transform  decomposition)（異なる解像度）、レイヤと呼ばれるコード係数ビット・プレーン（進行ビット・レート）、成分（例えば、Ｒ，Ｇ，Ｂ）および区画(precinct)（小波係数の領域）に分割する。これらのタイル−解像度−階層‐成分−区画装置は、独立してＪＰＥＧ２０００パケットに符号化される。これらのパケットはデコードすることなしにコードストリームから識別され抽出され得る。これは所与のディスプレイに必要なデータのみが抽出され伝送されることを可能にする。例えば、モニタが高品質で７５ｄｐｉデータしか必要としない一方、プリンタは低品質でも６００ｄｐｉデータを必要とし得る。両者は１つのコードストリームに収容され得る。
【０００５】
クルー（ＣＲＥＷ）画像圧縮システムは、ＪＰＥＧ２０００規格に含まれる特徴に関する原型を提供した。更なる情報については、例えば、非特許文献１を参照されたい。ＪＰＥＧ２０００コードストリーム“分解または分析(parsing)”に関する先行技術論文は、ＪＰＥＧ２０００コードストリームのデータに対するアクセス、抽出および再配列をどのように行うかを示す。これについての更なる情報は、例えば、非特許文献２に記載されている。ＪＰＥＧ２０００コードストリーム構文(syntax)に関する他の論文は、特定のユーザ関与の進行送信(progressive  transmission)に対してコードストリームがどのように配置されるかを示す。更なる情報については、例えば、非特許文献３を参照されたい。
【０００６】
ＪＰＥＧ２０００は、ファイル・フォーマットおよび圧縮アルゴリズムである。これは、例えば、クライアント／サーバ構造における特徴を考慮するのに必要なプロトコル又はアルゴリズムを特定しない。この規格は、ディジタル画像グループと呼ばれる企業組合によって規格されたフラッシュピックス(Flashpix)ファイル・フォーマットと同様である。これに関する更なる情報は、例えば、Digital  Imaging  Group,“The  Flashpix  image  format”,ワールド・ワイド・ウェブ・サイト(world  wide  web  site)のdigitalimaging.org.を参照されたい。しかしながら、ＪＰＥＧ２０００とは異なり、フラッシュピックスは、インターネットを通じて画像を取り扱うために、インターネット画像プロトコル（ＩＩＰ）と呼ばれるプロトコルと一組になっている。これについての更なる情報は、例えば、Digital  Imaging  Group,“The  Internet  Imaging  Protocol”を参照されたい。
【非特許文献１】M.  Boliek,M.J.Gormish,E.L.Schwartz,A.Keith,“Decoding  compression  with  reversible  embedded  wavelets  (CREW)  codestreams”,Electronic  Imaging,Vol.7,No.3,July  1998
【非特許文献２】G.K.Wu,M.J.Gormish,M.Boliek,“New  Compression  Paradigms  in  JPEG  2000”,SPIE  San  Diego,July  2000
【非特許文献３】M.Boliek,J.S.Houchin,G.Wu,“JPEG  2000  Next  Generation  Image  Compression  System  Features  and  Syntax”,Int.Conf.On  Image  Processing  2000,Vancouver,Canada,12  September  2000
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、サーバおよびクライアントより成る新規なシステムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
一実施例にあっては、システムはサーバおよびクライアントより成る。サーバは画像データに対応する圧縮されたコードストリームを格納する。クライアントはネットワーク環境を通じてサーバに結合される。クライアントは、アプリケーションを有するメモリを含み、そこに格納されたデータ構造を有する。このデータ構造は、サーバにおける圧縮されたコードストリームのパケット位置を示し、既にクライアントにバッファされている圧縮コードストリームのデータを示す。
【０００９】
一実施例にあっては、クライアントは、サーバからの圧縮コードストリームのバイトを要求し、それはメモリに格納されていないものであり、クライアントは、ユーザにより要求された、サーバから要求された圧縮コードストリームのバイトからのデコード画像を生成し、その画像データを生成するために必要なメモリに以前格納された圧縮コードストリームの任意の部分を生成する。
一実施例にあっては、サーバクライアント環境における方法は、
クライアントが画像サイズおよび解像度の最大数を判定できるようにするための情報を、ＨＴＭＬ書類又はＸＭＬ書類として提供し、
圧縮されたデータのコードストリームの１つ以上のタイルに関する要求を受信し、および
圧縮されたデータの前記コードストリームを分析して前記要求に関連するパケットを、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対するパケットも含めて見出すステップを有し、
前記分析の結果として見出されるパケットは、要求された解像度以下の解像度における要求されたタイルおよび総ての階層に対する総てのパケットを含み、
前記コードストリームのタイル部分ヘッダは、ＣＯＤ又はＣＯＣマーカーを含んでいない、ことを特徴とする方法である。
【発明を実施するための最良の形態】
【００１０】
本発明の実施例に関する以下の詳細な説明および添付図面により、本発明は充分に理解されるであろうが、本発明はこれら特定の実施例に限定されず、以下の説明は本発明を理解するためのものである。
【００１１】
以下に説明する新規かつ有益なシステムは、ＪＰＥＧ２０００を取り扱う多数の技術およびクライアント／サーバ・システムにおける同様なコードストリームを含む。これらが包含するデータ構造は、サーバおよびクライアント両者により受信されるコードストリームにおける全パケットの長さおよび位置を追跡する。一実施例にあっては、ＪＰＥＧ２０００ＴＬＭおよびＰＬＭマーカー・セグメント(maker segment)が利用される。更に包含されるものは、ＪＰＥＧ２０００に関するバイト要求、およびインターネット画像プロトコル（ＩＩＰは、ディジタル画像グループ企業組合によって管理される。）の修正を行うクライアントに関する相互クライアント／サーバ・プロトコルである。
【００１２】
ＪＰＥＧ２０００画像圧縮システムは、インターネットを介する画像を改善する重要な機会を提供する。ＪＰＥＧ２０００規格は、ウェブのクライアント／サーバ・アーキテクチャに理想的に適している。１つの圧縮された形式のもののみが格納されている場合に、サーバは、各自のクライアントにより特定される解像度、品質、サイズおよび顧客領域を有する画像送信することが可能である。また、相互的なズームおよびパン(pan)クライアント・アプリケーションを提供することも可能である。これらの総ては、減少した潜在的に最小のサーバ演算、格納および帯域を利用しつつ、サーバにおけるデコードなしに達成することが可能である。
【００１３】
以下の説明は、ＪＰＥＧ２０００に関するインターネット画像処理に含まれるシステム事項のいくつかを説明する。クライアントの選択、制御情報の伝送およびサーバがクライアントの要求に対応するのに使用可能な方法を説明する。これらの事項は、ＪＰＥＧ２０００エンコードおよびデコード・オプションで使用する規格を含む。
【００１４】
以下の説明において詳細な事項が説明され、本発明をいっそう理解することに寄与する。しかしながら、当業者にとって、本発明がこれらの具体的な詳細説明なしに実現され得ることは明らかであろう。また、本発明を簡明に説明するために、周知の構造および装置は詳細な形式ではなくブロック図で示されている。
【００１５】
以下の詳細な説明の一部は、アルゴリズム、およびコンピュータ・メモリ内のデータ・ビットに関する動作の象徴的な表現で与えられている。これらのアルゴリズムの記述および表現は、データ処理技術分野の者が利用する手法であり、他の技術者に彼らの仕事内容の本質を最も効果的に伝達するためのものである。ここで一般に、アルゴリズムは、所望の結果を導出する自己矛盾のない一連のステップとして思考される。これらのステップは物理量の物理的な操作を要求するものである。通常は、必須ではないが、これらの量は、格納、転送、結合、比較その他の操作を可能にする電気的または磁気的信号の形態をとる。この場合において、基本的には一般的な使用の観点から、ビット、値、要素、シンボル、キャラクタ、用語、数等のようにこれらの信号を言及することが有利である。
【００１６】
しかしながら、これらおよび類似の用語の総ては、適切な物理量に付随し、それらの量に適用される便利なラベルに過ぎない点に留意すべきである。以下の説明において特に明示されない場合は、本願説明を通じて、「処理」、「演算」、「計算」、「判定」、「表示」等のような用語を使用する説明は、コンピュータ・システムまたは同様な電子演算装置または送信若しくは表示装置の動作および処理に言及するものであり、コンピュータ・システムのレジスタおよびメモリ内の物理的な（電気的な）量として表現されるデータを操作し、およびコンピュータ・システムのメモリ又はレジスタまたはそのような情報格納部内の物理量として表現される他のデータに変換する。
【００１７】
本発明は、本願で説明する動作を実行する装置にも関連する。その装置は、要求される目的に対して特に構築され、または汎用コンピュータを形成し、コンピュータに格納されるコンピュータ・プログラムによって選択的に起動され又は再構成される。このようなコンピュータ・プログラムはコンピュータ読み取り可能な記憶媒体に格納され、それは、コンピュータ・システム・バスに各々が結合される、フロッピー（登録商標）ディスク、光学ディスク、ＣＤ−ＲＯＭ、磁気光学ディスク、読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カードその他の伝記的命令を格納するのに適した媒体  を含む任意のディスク形式のようなものであるが、これらに限定されない。
【００１８】
本願で説明されるアルゴリズムおよびディスプレイは、特定のコンピュータ又は他の装置に固有に関連するものではない。本願の教示するものに従うプログラムを利用して、様々な汎用システムが利用され得る。また、必要な方法手順を実行する更に特殊な装置を構築することも可能である。これら様々なシステムに必要な構造は、以下の説明で明らかになるであろう。さらに、本発明は任意の特定のコンピュータ・プログラミング言語を参照して説明されるものではない。様々なプログラミング言語を利用して、ここに説明する本願の教示するものを実現することが可能である。
【００１９】
機械的に読み取り可能な媒体は、機械（例えば、コンピュータ）によって読み取り可能な形式で情報を格納または送信する任意の機構を包含する。例えば、機械的に読み取り可能な媒体は、読み取り専用メモリ（ＲＯＭ）；ランダム・アクセス・メモリ（ＲＡＭ）；磁気ディスク格納媒体；光学格納媒体；フラッシュ・メモリ装置；電気的、光学的、音響的その他の信号伝搬形態（例えば、搬送波、赤外線信号、ディジタル信号等）；等である。
【００２０】
概要
以下の説明は、ＪＰＥＧ２０００または同様なコードストリームを処理するクライアント／サーバ・ネットワークを通じて相互作用するプロトコルおよびアルゴリズムを説明する。ネットワーク化された環境が説明され、異なる環境の説明が続き、そこでは計算労力がクライアントおよびサーバ機構の間で別々に分散される。第１実施例では（スマート・クライアント，試行(Challenged)サーバと言及する）、演算労力がクライアントに対して重み付けされる。これは、クライアントがパーソナル・コンピュータ（ＰＣ）またはラップトップのような高い処理能力を有する機器であるところのネットワークにとって好ましい。第２実施例（スマート・サーバ，試行クライアントと言及する）は、クライアントからサーバへ更なる演算労力を与える。これは、セルラ電話、ＰＤＡ等のような処理能力の低い機器にとって有益である。サーバは、クライアントの能力に依存していずれの形態の機能も実行可能に設計され得る。したがって異種のクライアント装置がネットワークを共有し、適切な程度のサーバ支援を行うことが可能である。
【００２１】
ＪＰＥＧ２０００画像の分割
ＪＰＥＧ２０００では、典型的な画像は１つ又はそれ以上の成分より成る（例えば、赤、緑、青）。成分は四角形のサンプル配列である。これらの配列は更に正規の四角タイル(regular  rectangular  tile)に分割される。色彩空間変換を利用して、成分はタイル毎に分解され得る。色彩空間変換の後、全タイル成分は独立に圧縮される。
【００２２】
その後、各タイル成分は小波変換(wavelet  transformation)によって変換される。小波変換の複数のスケール属性は、異なる解像度でタイル成分を再構築することが可能な係数データ（ＬＬサブバンドおよびＨＬ，ＬＨ，ＨＨサブバンド）のグループを提供する。
【００２３】
係数サブバンドは更に符号ブロック（各サブバンドを被覆する正規の四角領域）にグループ化される。符号ブロックにおける各係数の最上位ビットから始まるビット・プレーンは、コンテキスト・モデル(context  model)および算術符号器を利用して符号化される。この符号化は、最上位から最下位に起因していくつかの符号化経路（ビット・プレーン当たり３つまで）を形成する。
【００２４】
総ての係数データが符号化された後に、符号化経路はパケット内に配置される。各パケットは、そのタイル成分の所与の解像度および区画における符号化ブロックの全部又は一部からの符号化経路の集合を表現する。言い換えれば、１パケットは、タイル成分内の所与の解像度に関する繊細さの１単位である。タイル成分における各解像度に関し、そのパケットの厳格な順序が存在する。しかしながら、異なる解像度およびタイル成分によるパケットは、様々な手法でインターリーブすることが可能である。パケットは、コードストリームにおいて容易にアクセス可能な符号化データの最小単位である。
【００２５】
図１はパケットの順序の２つの例を示す。左側におけるパケット順序は、画素忠実(pixel  fidelity)順序（３解像度、３階層、１区画、１タイル成分）におけるものである。右側におけるパケット順序は、解像度順序である（Ａ，Ｄ，Ｇ，Ｂ，Ｅ，Ｈ，Ｃ，Ｆ，Ｉ）。
【００２６】
コードストリームの構文は画像の分割に従う。コードストリームの開始時に主ヘッダが存在する。このヘッダが包含するマーカーは、画像特性、符号化形式および画像全体または個々の成分に適用する他のパラメータを記述する。各タイル部はヘッダを有する。これらのタイル部は順序を示すための指標が付される。タイルの第１タイル部ヘッダの包含する情報は、タイル全体又は個々のタイル成分に適用するものである。残りのタイル部ヘッダは、そのタイル部および／または連続するタイル部に関する順序および長さ情報のみを包含する。
【００２７】
ネットワーク例
図２は、ここに説明される技術を利用することの可能なネットワーク環境２０１の一実施例のブロック図である。一実施例において、サーバ・コンピュータ・システム２００は広域ネットワーク２１０に結合される。広域ネットワーク２１０は、インターネットまたは他のネットワークを含み、他のネットワークは、アメリカ・オン・ライン（商標）、コンピュサーブ（商標）、マイクロソフト・ネットワーク（商標）およびプロディジィ（商標）等を含むがこれらに限定されない。広域ネットワーク２１０は、従来のネットワーク技術、長距離電話回線、インターネットおよび／またはイントラネット・サービス・プロバイダ、様々なレベルのネットワーク・ルータ、およびコンピュータ間のデータを配信する他の既存の機構を包含する。ネットワーク・プロトコルを利用して、サーバ２００は広域ネットワーク２１０を通じてクライアント・コンピュータ・システム２２０，２３０，２４０と通信することが可能であり、これらは、広域ネットワーク２１０を通じて、様々な形式で又は直接的にサーバ２００に結合される。例えば、クライアント２４０は、直通若しくはダイヤル・アップ電話または他のネットワーク伝送回線を通じて、広域ネットワーク２１０に直接的に結合される。クライアント２４０は無線接続を介して広域ネットワーク２１０に結合することも可能である。
【００２８】
また、クライアント２３０は、モデム・プール２１４を利用して広域ネットワーク２１０に結合され得る。モデム・プール２１４は複数のクライアント・システムが、モデム・プール２１４内のモデムの小集合に接続可能にし、広域ネットワーク２１０に接続する。クライアント２３１はサーバ２００に直接的に結合可能であり、またはモデム２１５を介してサーバに結合され得る。更なる他のネットワーク形態にあっては、広域ネットワーク２１０はゲートウエイ・コンピュータ２１２に結合される。ゲートウエイ・コンピュータ２１２は、ローカル・エリア・ネットワーク２１６を通じて、クライアントにデータを配信するために使用される。このようにして、クライアント２２０はローカル・エリア・ネットワーク（ＬＡＮ）２１６を通じて互いに、又はゲートウエイ２１２および広域ネットワーク２１０を通じてサーバ２００と通信することが可能である。また、ＬＡＮ２１７はサーバ２００に直接的に結合し、クライアント２２１はＬＡＮ２１７を通じて接続される。
【００２９】
様々なネットワーク接続機構の１つを利用して、サーバ・コンピュータ２００はクライアント・コンピュータ２５０と通信することが可能である。一実施例にあっては、インターネットのワールド・ワイド・ウェブ（ｗｗｗ）の部分が広域ネットワーク２１０に利用されるならば、サーバ・コンピュータ２００はウェブ・サーバとして動作する。ＨＴＴＰプロトコルおよびＨＴＭＬ符号化言語またはＸＭＬを利用して、そのようなウェブ・サーバは、ワールド・ワイド・ウェブを通じて、クライアントと通信することが可能である。この形態において、クライアントは、ネットスケープ（商標）ナビゲータ（商標）、インターネット・エクスプローラ（商標）、アメリカ・オン・ライン（商標）のユーザ・インターフェースその他の荷煮の既存のサプライヤによるウェブ・ブラウザまたはＨＴＭＬ変換として知られるクライアント・アプリケーション・プログラムを利用する。このようなブラウザおよびワールド・ワイド・ウェブを利用して、クライアント２５０は、ウェブ・サーバ２００により提供される、グラフィックスおよびテキスト・データ又は映像的、音響的、または触覚的データにアクセスし得る。
【００３０】
スマート・クライアント，“試行”サーバ
一実施例において、クライアントはパーソナル・コンピュータのような（処理能力の高い）スマート端末であり、これはサーバに対して、画像に対応するいくらかの量のデータを取得することを要求する。要求されるデータは、サーバにおいてファイルとして格納されるＪＰＥＧ２０００コードストリームのようなコードストリームの一部である。サーバは特定のファイルに関するバイトの要求を受信し、それらをクライアントに送信する。
【００３１】
図３は、ユーザにより要求された画像を表示するためのクライアントの論理処理（例えば、クライアント側のアプリケーション）を実行することにより行われるプロセスの一実施例である。このプロセスに関し、クライアント側のアプリケーションは、必要とされるデータが何であるかを判定すること、サーバからのデータを求めることの取り扱いを担う。処理論理は、ハードウエア（例えば、回路、専用論理回路等）、ソフトウエア（汎用コンピュータ・システムまたは専用の機器において実行されるようなもの）またはそれらの組み合わせより成る。
【００３２】
図３を参照するに、処理論理は、ユーザが要求する画像の特徴を判定する（処理ブロック３０１）。これらは、領域、解像度、区画および／または品質を包含し得る。
【００３３】
次に、処理論理は、これらの画像特性に対応するＪＰＥＧ２０００コードストリームのデータを選択し（処理ブロック３０２）、クライアントに既にバッファされているものに基づいて、そのデータを受信するために何バイトが必要であるかを判定する（処理ブロック３０３）。クライアントは、どのパケットを必要とするか及びどのパケットを既に有しているかを判定し、パケットが依然として必要な要求を発する。クライアントは、最初にパケットのない状態から始まり、その後多くの要求がなされ、以下に説明するように、クライアントはコードストリームのパケットを保持し、それらを格納し、以前に要求した又は取得したパケットにクライアントが容易にアクセスできるようにする。一実施例にあっては、クライアントは、相後セッション形式の１つに関するパケットのみを保持する。一実施例にあっては、これは以下に説明するデータ構造を利用して実行される。しかしながら、これは多数の手法で実行可能である。
【００３４】
この情報を利用して、処理論理はサーバに対してバイト範囲要求を発行する（処理ブロック３０４）。一実施例にあっては、クライアントは、メモリ・ロケーションの開始位置を送信するのに必要とされるＪＰＥＧ２０００コードストリームのデータを特定し、その場所では、データが格納され、データ量の範囲が要求される。他の実施例にあっては、所望のデータを格納するメモリ・ロケーションの開始および終了位置が、その要求の中で送信される。
【００３５】
一実施例にあっては、ユーザはＨＴＴＰ又は同様な機構を利用して、所望のコードストリームの部分を取得する。例えば、クライアントは、ポスト（ＰＯＳＴ）または取得（ＧＥＴ）動作を利用して、サーバから情報を要求する。他の実施例にあっては、クライアントは、ユニバーサル資源ロケータ(URL:  universal  resource  locator)における、開始位置（例えば、バイト）および長さ、または開始位置（例えば、バイト）および終了位置（例えば、バイト）（又はこれらの複数のシーケンス）を特定し得る。
【００３６】
処理論理は受信データを統合し、これは以前にバッファされたデータと共にエンコードされた形式で送信され、適切なＪＰＥＧ２０００コードストリームを作成する（処理ブロック３０５）。一実施例にあっては、当初のコードストリームで生じる順序でパケットが設けられる。
【００３７】
ＪＰＥＧ２０００コードストリームにおけるマーカー・セグメントを変更して、ＪＰＥＧ２０００対応デコータが取り扱うことの可能な正規のＪＰＥＧ２０００コードストリームを作成することが可能である。より具体的には、サーバに格納された当初のＪＰＥＧコードストリームに付随するマーカーは、所定数のタイルおよびタイル部分等を示す。これらのマーカーは、コードストリームの要求されるバイトと共に転送される。（サーバは、ＪＰＥＧ２０００ファイルを提供しつつあることを知る必要はなく；単に要求を受信してバイトを送信する。）しかしながら、コードストリームの一部分のみが要求されるので、クライアントはそのマーカーを修正し、マーカーが、統合化のプロセスの結果として生成されたコードストリームに対して適切であるようにする。したがって、クライアントは、適切な、又は正規のコードストリームを作成する。例えば、コードストリームの小型バージョン（低解像度）が要求される場合に、サーバは要求されたデータを提供する。しかしながら、主ヘッダに提供されるＰＬＭ値は、もはや正しいものではない。より高い解像度に属するいくつかのパケットは新規のコードストリームに包含されていないので、ＰＬＭ値は更新される必要がある。同様に、ＴＬＭマーカーのＴｔｌｍおよびＰｔｌｍ値に加えて、ＳＯＴマーカーのＰｓｏｔ値（タイル部分のＳＯＴ（タイル部分の開始）マーカー・セグメントの第１バイトの始まりから、そのタイル部分のデータの終了までの長さ）マーカーは、その修正を反映するよう更新される必要がある。
【００３８】
処理論理は、ＪＰＥＧ２０００対応デコーダを利用して新たに生成されたＪＰＥＧ２０００コードストリームをデコードし（処理ブロック３０６）、モニタにその画像を描く（処理ブロック３０７）。
【００３９】
サーバは要求を取り扱う；しかしながら、サーバはＪＰＥＧ２０００ファイルを取り扱うためのいかなる特殊なソフトウエアも要しない。しかしながら、サーバの制御（例えば、ＨＴＭＬまたは他の制御言語）は、ファイルの取り扱いだけでなく、主ヘッダの長さをも包含する。要求に応答して、サーバは、要求されたバイトを含む情報をクライアントに提供する。一実施例にあっては、サーバはバイト長の要求を取り扱うことが可能である。これは、多数の方法を利用して達成することが可能である。一実施例にあっては、共通ゲートウエイ・インターフェース（ＣＧＩ）スクリプトを利用して、ファイルの連続的な部分を抽出し、それをクライアントに送信する。ＣＧＩスクリプトは、送信するバイトを決定し、ＴＣＩ／ＩＰパケットを作成し、作成したパケットを送信する。
【００４０】
クライアントは、送信したデータ・パケットから正規のＪＰＥＧ２０００コードストリームを作成し、汎用デコーダでそれらをデコードする。これを行うため、クライアントは、受信したコードストリームの部分を、デコード用の完全な正規のＪＰＥＧ２０００コードストリームに組み立てる。デコーダは汎用ソフトウエア・デコーダより成る。汎用デコーダは、コードストリーム全体（すなわち、正規のコードストリーム）を利用することを期待する。他の実施例にあっては、デコーダは、メモリ内でスキップすることによってコードストリームの異なる部分を処理することが可能である。ストリーム・フィルタを設けて、デコーダでデコードされる前にそのストリームをフィルタ処理することも可能である。
【００４１】
他の実施例にあっては、デコーダは機能強化されたデコーダであり、順序どおりでなく、格納部に分散されたコードストリームを取り扱うことが可能である。このような場合におけるヘッダは、メモリを通じて、好ましくはポインタを利用して、拡散した必要部分の各々の位置を示す。
【００４２】
更なる他の実施例にあっては、ＪＰＥＧ２０００進行順序のもののみを理解することの可能なデコーダのような、機能の制限されたデコーダが利用される。このような場合において、要求されおよびサーバから受信されるデータは、デコーダに送られる前に並べ替えられる必要がある。
【００４３】
ＪＰＥＧ２０００に関し、ＪＰＥＧ２０００ファイルは、充分に特定されたＴＬＭおよびＰＬＭマーカー・セグメントを有し得る。これらのマーカー・セグメントに関し、主ヘッダがクライアントにより受信された後は、コードストリームにおける各パケットの長さおよび開始点は既知である。他の実施例において、この情報は、各タイル部分ヘッダひいては全パケットヘッダを読み取ることにより−効率的な手法ではない−これらのマーカー・セグメントなしに識別される。
【００４４】
一実施例にあっては、画像およびＪＰＥＧ２０００コードストリームは、以下の特徴を含む。画像サイズ、タイル・サイズ、多数の解像度および階層化パターンが適切である。すなわち、画像は、相互作用が画像全体の送信に対して意味をなす程度に充分大きい。例えば、一実施例において、１０２４×１０２４ピクセル色彩画像またはそれ以上のものが利用される。タイル・サイズは、画像品質を保持するのに充分大きいが、例えば、２５６×２５６のファイルの小さな部分を選択することが可能な程度に小さいことが有利である。過度に多くのタイル部分が存在しないのは、過度に多くのタイル部分は、ＴＬＭマーカー・セグメントのサイズを増加させるからである。ＴＬＭが画像サイズより５％多く付加するならば、おそらく能率的でないであろう。（過度に多くのタイル部分が生じると、信号データを伝送するよりも画像全体をダウンロードすることが容易である）解像度数は、画像を抽出可能にする程度に充分小さい。例えば、４ないし６の分解レベルは有効であり、画像を抽出可能にする程度に充分小さい。また、階層化パターンは、その画像に対して予想可能な比較的同等なひずみを含む。過度に多くの小パケットを生成するほど繊細であるように、そのレートでの制御レベルを良好にする程度に充分に繊細であることが好ましい。小パケットはサーバにアクセスするのに最も能率的なものではなく、そのパケット数はＰＬＭマーカー・セグメントのサイズを増加させる。
【００４５】
以下の１つ又はそれ以上の提案事項に従ってＪＰＥＧ２０００ファイルが当初エンコードされるならば、クライアント／サーバ相互作用はより効率的になる。一実施例にあっては、ファイルは、１つの進行順序（例えば、レベル−階層−成分−位置），１つの仕切り(partition)，および主ヘッダのみにおけるＣＯＤ，ＱＣＤおよびＱＣＣマーカー・セグメントのみを包含する。タイル部分ヘッダは、ＳＯＴおよびＳＯＳマーカー・セグメントのみを包含する。画像の成分は、ここに述べた例について総て同様に取り扱われる。理論的には、コードストリームの適切な部分を抽出するのにこれらの条件は必要ない。しかしながら、実際には、これらは効率化の観点から有益である。ＪＰＥＧ２０００コードストリームのこの構造は非常に一般的であることに留意されたい。また、ＪＰＥＧ２０００コードストリームのファイル・フォーマット属性の特殊な用法をここで述べているわけではなく、当業者によく知られているものである。
【００４６】
コードストリームの主ヘッダにおける情報の抽出
数値例に関し、３成分、４タイル（１タイルにつき１タイル部分）、３解像度レベルおよび２階層を有する周知のレナ(Lena)画像を利用する。７２パケットが存在する（３×４×３×２＝７２）。ブラウザ・アプリケーションは、ＨＴＭＬソース（例えば、組み込まれた画像を有するウェブ・ページ、または画像へのリンクを有するページ）からファイル名および長さを受信する。ＸＭＬソースを利用することも可能である。例えば、一実施例にあっては、フォーマットは以下のようになる：
<img src=”lena.jp2”headerlength=”309”>
ここで、（この例では３０９である）ヘッダ長(headerlength)は、コードストリームの前にあるファイル・フォーマット・ボックスおよびコードストリームの構文主ヘッダにおけるデータに対応する。図４は、このファイルおよびヘッダ長を示す。図４を参照するに、ＪＰ２ファイル４００は、ファイル・フォーマット・ボックス４０１およびコードストリーム・ボックス４０２を含む。コードストリーム・ボックス４０２は主ヘッダ４０３およびタイル部分ヘッダおよびデータ４０４を含む。ヘッダ長４０５は、ファイル・フォーマット・ボックス４０１および主ヘッダ４０３に等しい。図４は寸法を示すものでない点に留意すべきである。
【００４７】
クライアントはサーバに対してヘッダ長に対応するデータの要求を行う。一実施例では、その要求は、サーバがそのサーバにおけるＣＧＩスクリプトを呼び出すようにするものであり、要求される範囲内のバイトのみを伝送するようにする。例えば、この要求の構文は以下のようにすることができる：
cgiByteRequest:lena.jp2:0:309。
【００４８】
クライアントは、ファイル・フォーマット・ボックスにおける情報を読み出し、必要に応じてそれを使用する。ＪＰＥＧ２０００コードストリームの場合には、コードストリーム・ボックスの主ヘッダは、更なる相互作用に有用な２つのキー・マーカー・セグメント、ＴＬＭおよびＰＬＭマーカー・セグメント、更には符号化および量子化マーカー・セグメントを包含する。これら２つのマーカー・セグメントを利用して総てのパケットのビット・マップを提供する。パケットは、タイル、成分、解像度、および階層によって区別される。
【００４９】
例えば、画像が３成分を有し、４タイルに分割され（１タイルにつき１タイル部分）、３つの解像度を有し（２つの小波分解(wavelet  decomposition)）、２階層を有し、および１タイルにつき唯１つの仕切りを有するならば、その画像は７２パケットを有し、１パケットは、１タイル成分の１解像度の１階層の１つの仕切りを表現する。この場合、ＴＬＭは以下の値を有する：
【００５０】
【数１】
0004538430.tif 000002
ＰＬＭマーカー・セグメントは以下のような７２パケットの長さを記述する：
【００５１】
【数２】
0004538430.tif 000003
各パケットの開始位置は、クライアントで目下利用可能な情報を利用して識別することが可能である。第１タイルの開始位置は、画像を呼び出すスクリプトにおけるヘッダ長の値から把握される。これにより、総てのタイル部分の位置がわかる。図５は２つのタイル部分およびタイル部分につき２つのパケットを有する例を示す。図５を参照するに、パケット５０１はタイル部ヘッダ５０２に付随するパケットであり、パケット５０３はタイル部ヘッダ５０４に付随するパケットである。
【００５２】
一実施例にあっては、タイル部分ヘッダはＳＯＴおよびＳＯＳマーカー・セグメントのみを有する。したがって、第１パケットの開始は、タイル部分の開始後１２バイトである（タイル部ヘッダの長さが未知であるならば、タイル部分の長さからタイル部分内のパケット長の合計を減算することにより、それを導出することが可能である）。
【００５３】
この情報により、パケットの既知の順序、正確な位置および各パケットの長さがわかる。クライアントが作成することの可能なデータ構造は、サーバ側における総てのパケットの位置をリストし、それをクライアント側で受信したデータに関連付けるものである。上記の例については、データ構造は表１におけるデータを包含し得る。この情報は、所与のタイルに関するタイル部分数またはコードストリームにおける順序によらず収集されることが可能である。
【００５４】
表１  サーバおよびクライアントの両者におけるパケット位置を判定するためのデータ構造
【００５５】
【表１】
0004538430.tif 000004
一実施例にあっては、サーバからデータを要求する複数のクライアント・アプリケーションがテーブル（表）を利用し、画像データはテーブルで指定されるように格納される。このような場合に、クライアントは、ＪＰＥＧ２０００画像を管理するキャッシュ管理部を含み、そのような画像に関するウェブ・ブラウザによる要求は、それがテーブル内に存在するか否かを見出すために最初に検査される。したがって、テーブルは、多数のアプリケーションで供給される共通資源でもある。
【００５６】
要求するデータの判定
一実施例にあっては、ユーザが制御可能な３つの主な画像要求は、領域（どのタイルか）、サイズ（解像度）、および品質またはスピード（階層）である。ユーザは、クライアントに対して、ユーザ・インターフェースを通じて見ることを希望する特定の画像位置を指示する。この指示に応答して、クライアントは、サーバに対して、要求される画像データに対応し、保持していないコードストリームの部分を取得するよう要求する。ユーザ・インターフェースは、画像が特定のサイズ、ビット・レート又は選択される領域で選択されることを可能にする。
【００５７】
一実施例にあっては、ユーザ・インターフェースは、一連のサムネイルを有するウェブ・サイトより成り、そこからユーザはカーソル制御装置を利用して選択することが可能である。このような場合に、ユーザは、サーバに対して、１つ又はそれ以上の画像を選択することによって（例えば、１つ又はそれ以上の画像をクリックすることによって）、より大きなサイズの画像を取得する要求を生じさせる。この選択は、要求を生成するクライアント側のブラウザ・アプリケーションによって受信される。
【００５８】
他の実施例では、クライアントはダブル・クリックしてその要求を特定する。更なる他の実施例では、スクリーンに、垂直及び水平寸法を要求するボックス、またはユーザが見ることを希望する画像の部分を指示し得るＤＰＩが現れる。更なる他の実施例では、スクリーンにスライド・バーが現れる。スライド・バーは品質スライド・バーとすることが可能であり、これは表示される画像の品質をユーザが特定することを可能にする。更なる他の実施例では、一群のボタンを利用してその要求を作成する。更なる他の実施例では、ユーザがスクリーンに四角形を描き、異なる解像度で見ることを希望する画像領域を特定する。更なる他の実施例では、アルゴリズムを利用して、例えば、画像に生じる特定のテキストまたはグラフィックスを探索することによって、ページにおける特定の位置を見出す。更なる他の実施例では、単に画像の部分の上でマウスを転がしてハイライトし、クライアントが、ハイライトとされた領域に付随する要求を生成可能にする。
【００５９】
一実施例にあっては、ユーザ・インターフェースが全く利用されない。例えば、ＨＴＭＬページ内で、ユーザに提供される画像の大きさを設計者が予め決定しているような場合である。したがって、ユーザが画像を含むページをロードする場合に、画像のサイズは、指定され又は予め設定されたレートにおけるものである。
【００６０】
データ要求，受信および併合
一実施例にあっては、ＣＧＩスクリプトを利用して要求を処理する。先ず、適切なパケットが要求される。次に、クライアントはパケットを受信し、ストリームを併合する(merge)。すなわち、クライアントは、クライアント側に以前格納されたものを有する要求に応答して、サーバから受信したパケットを結合する。これは、表１のクライアント開始オフセット列を利用して実行される。
【００６１】
新たなデータが受信されるにつれて又はその後の近辺において、処理はデータ構造を徐々に変化させる。こうして、データ構造は、クライアントによってバッファされたＪＰＥＧ２０００コードストリームの部分の正確な指標を提供する。その後、第２の要求が生じると、新たなデータが併合される。
【００６２】
スマート・サーバ，“試行”クライアント
インターネット画像プロトコル（ＩＩＰ）は、画像データの交換に関するクライアント・サーバ通信の規則を提供する。これは、主に、ネットワーク化された環境におけるフラッシュピックス・ファイル・フォーマットを考慮して設計されたものである。フラッシュピックスは、圧縮された６４×６４タイルを利用して複数の画像解像度を格納するために設計されたので、ＪＰＥＧ２０００コードストリームと共に利用することに応用可能である。
【００６３】
つまり、サーバが総ての要求されたタイルを、それらが要求されるようなＪＰＥＧ  ＤＣＴ圧縮方式に変換するならば、プロトコルまたはクライアントにいかなる変更も加えることなしに、ＩＩＰを利用してＪＰＥＧ２０００画像を取り扱うことが可能である。このことは、サーバが圧縮支援を実現可能にし、その支援は、１つのファイルに複数の解像度を格納するＪＰＥＧ２０００の機能により提供されるものである。しかしながら、これは変換時間を節約するものではなく、処理時間に影響を及ぼし、画像の部分を再圧縮し、ＪＰＥＧ圧縮に起因する品質劣化の影響を受ける。このような場合は、クライアントは、ＪＰＥＧ  ＤＣＴ圧縮をデコードする機能を有する。
【００６４】
より有効な手法は、ＩＩＰ仕様を修正し、当初の圧縮形式としてのＪＰＥＧ２０００を許容するようにするものである。これは、プロトコルを考慮する限りは簡明な修正である。しかしながら、フラッシュピックスは、解像度レベル毎に同一のサイズである固定サイズのタイル（６４毎）を利用し、ＪＰＥＧ２０００は各解像度レベルで変化する可変サイズのタイルを利用する（そして各解像度レベルで同一のタイル数を維持する）ので、新たな圧縮形式を実現するには、クライアントおよびサーバ両者の実質的な変更が必要である。
【００６５】
ＩＩＰ交換の例は、仕様書のバージョン１．０．５の付属書類１によれば以下のとおりである：
クライアントは以下のものを提供する：
【００６６】
【数３】
0004538430.tif 000005
上述したように、クライアントからの第１要求は、フラッシュピックス・ファイルに関するいくつかの基本情報を求める。サーバは、“フィルタ値”，“カラー・ツイスト(Color-twist)”および“コントラスト調整”が利用可能でないことの指標を含むいくつかの事項と共に応答する。クライアントは画像サイズおよび解像度の最大数を学ぶということが重要である。そして、クライアントは、解像度２において１つのタイルを、解像度３において２つのタイル（０および１）を要求する。一実施例にあっては、サーバは初期ＨＴＭＬ，ＸＭＬまたは同様なファイルを提供し、ＩＩＰプロセスを開始する。このファイルから、クライアントは、画像サイズおよび解像度の最大数を突きとめることが可能である。こうして、サーバおよびクライアント間の１往復の通信を回避することが可能になる。
【００６７】
フラッシュピックスは解像度を独立して格納するので、画像の低解像度の部分の伝送を追跡することを要しない。一実施例にあっては、表１に類似するサーバにおいて使用されるデータ構造において、サーバは、ＪＰＥＧ２０００コードストリームのどの部分がクライアントに格納されるかの指標を格納する。
【００６８】
一実施例にあっては、ＪＰＥＧ２０００に関して、非常に類似する相互作用が行われる。まず、クライアントは基本情報を求める。その情報がＪＰＥＧ２０００主ヘッダ（または、更にちょうどＳＩＺタグ）に含まれるならば、クライアントは要求するタイルがどれであるかを判別する。フラッシュピックスとは異なり、解像度によらず、画像の同一部分について同一のタイルが要求される。いくつかのＪＰＥＧ２０００ファイルに関し、最大解像度が決定されないのは、多数の解像度がタイル毎に変化し得るためである；しかしながら、一実施例にあっては、その目的のために、システムは、いくつかのアプリケーションに対して“プロファイル(profile)”として定めれられるように、タイル部分ヘッダにＣＯＤまたはＣＯＣマーカーを包含しないコードストリームを使用するよう制限される。
【００６９】
タイル０，解像度２の所与の要求に関し、サーバはＪＰＥＧ２０００コードストリームを分解し、全パケットをその要求に適切に位置付ける。これらは、要求された解像度より小さいまたはそれに等しい解像度および総ての階層における、要求されたタイルに関する総てのパケットである。ＪＰＥＧ２０００を利用する際にＩＩＰサーバにより返送されたタイル・オブジェクトの定めは、指定された解像度(named  resolution)に至るまでおよびそれを含む総ての解像度、または指定された解像度のみであり得る。第２の場合において、以下の交換が行われ得る：
クライアントから：
FIF=Moon.fpx&OBJ=IIP,1.0&TIL=2,4
サーバから：
IIP:1.0CRLF
Tile,0,4,0/597:dataCRLF
Tile,1,4,0/2296:dataCRLF
Tile,2,4,0/6296:dataCRLF
当然ながら、このようにＩＩＰを利用することは、ビットストリームの選択部分を、解像度および空間領域にのみ限定する。一実施例にあっては、タイル要求構文は次のようになる：
TIL=res,tile[,sub]
ＪＰＥＧ２０００の完全に利用することに関し、その構文は次のように修正され得る。
【００７０】
TIL=res,comp,lay,prec,tile
ここで、ｒｅｓは目下定められている解像度であり、ｃｏｍｐは成分であり、ｌａｙはＪＰＥＧ２０００階層であり、ｐｒｅｃはＪＰＥＧ２０００区画である。例示的範囲は（０−２）を含み、またはワイルドカード“*,”を任意のパラメータとして利用することも可能である。
【００７１】
クライアント要求は以下のようにすることが可能である：
=>
TIL=0-2,*,0-1,*,5
これは、総ての成分、第５タイルの最初の３解像度に関する総ての区画を取得するためのものであるが、要求されるビットレートを実質的に減少させることが可能な最初の２階層のみを取得する。
【００７２】
コンピュータ・システム例
図６は、コンピュータ・システム例のブロック図であり、ここに説明した動作の１つ又はそれ以上を実行するものである。図６を参照するに、コンピュータ・システム６００は、一般的なクライアント６５０またはサーバ６００コンピュータ・システムより成る。コンピュータ・システム６００は、情報を通信する通信機構又はバス６１１と、バス６１１に結合され情報を処理するプロセッサ６１２より成る。プロセッサ６１２はマイクロプロセッサを含むが、例えば、ペンティアム（登録商標）、パワーＰＣ（商標）、アルファ（商標）等のようなマイクロプロセッサに限定されない。
【００７３】
システム６００は、更に、バス６１１に結合され、情報およびプロセッサ６１２により実行されるべき命令を格納するランダム・アクセス・メモリ（ＲＡＭ）または他のダイナミック格納装置６０４より成る。そのような命令は、プロセッサ６１２により実行される場合に、クライアントおよび／またはサーバが実行すべき動作を引き起こすものである。主メモリ６０４は、プロセッサ６１２による命令実行中に、一次的な変数または中間情報を格納するためにも使用される。
【００７４】
コンピュータ・システム６００は、バス６１１に結合され、プロセッサ６１２のための静的情報および命令を格納する読出専用メモリ（ＲＯＭ）、およびディスク・ドライブに関連する磁気ディスクまたは光学ディスクのようなデータ格納装置をも有する。
【００７５】
コンピュータ・システム６００は、更に、バス６１１に結合され、コンピュータのユーザに情報を表示する陰極線管（ＣＲＴ）または液晶表示装置（ＬＣＤ）のような表示装置６２１を含み得る。英数字及び他のキーを含む英数字入力装置６２２も、バス６１１に結合され、プロセッサ６１２に対する情報および命令の選択を通信する。付加的な入力装置は、マウス、トラックボール、トラックパッド、スタイラス(stylus)またはカーソル方向キーのようなカーソル制御装置６２３であり、これもバス６１１に結合され、プロセッサ６１２に対する方向情報および命令選択を通信し、およびディスプレイ６２１におけるカーソルの動きを制御する。
【００７６】
バス６１１に結合される他の装置はハード・コピー装置６２４であり、これは、紙やフィルムのような媒体その他の同様な媒体に命令、データまたは他の情報を印刷するために使用される。さらに、スピーカおよび／またはマイクロフォンのような音響読み取りおよび再生装置が、バス６１１に選択的に結合され、コンピュータ・システム６００に対する音響インターフェースを提供する。バス６１１に結合され得る他の装置は、電話機または携帯機器と通信を行うための有線／無線通信部６２５である。
【００７７】
本発明では、システム６００の任意の又は総ての要素および付随するハードウエアを利用することが可能である。さらに、これらの装置の全部又は一部を包含するコンピュータ・システムの他の配置構成を採用することも可能である。
【００７８】
以上の説明により、本発明に関する多くの代替例および修正例が、当業者に明らかになるであろうが、図面を利用して説明した特定の実施例は、本発明が限定されることを意図しない点に留意すべきである。したがって、様々な実施例の詳細に関連するものは、本発明の本質的特徴を記載する特許請求の範囲を限定することを意図するものではない。
【図面の簡単な説明】
【００７９】
【図１】ＪＰＥＧ２０００コードストリームに配列されたパケットを示す図（左側は画素複製順、右側は解像度順）である。
【図２】模式的なネットワーク環境を示す図である。
【図３】ＪＰＥＧ２０００コードストリームを処理するプロセスのフローチャートを示す。
【図４】先行するコードストリーム・ボックス長および主ヘッダ長を有するＪＰ２ファイルを示す図である。
【図５】ＪＰＥＧ２０００コードストリームにおけるパケット位置を示す図である。
【図６】コンピュータ・システムの一例のブロック図である。
【符号の説明】
【００８０】
２００  サーバ
２１０  広域ネットワーク
２１２  ゲートウエイ
２１４  モデム・プール
２１５  モデム
２１６  ローカル・エリア・ネットワーク
２１７  ラン
２２０，２２１，２３０，２３１，２４０  クライアント
４００  ＪＰ２ファイル
４０１  ファイル・フォーマット・ボックス
４０２  コード・ストリーム・ボックス
４０３  主ヘッダ
４０４  タイル部分ヘッダおよびデータ
４０５  ヘッダ長
５０１  パケット
５０２  タイル部分ヘッダ
５０３  パケット
５０４  タイル部分ヘッダ
６００  コンピュータ・システム
６０４  主メモリ
６０６  スタティック・メモリ
６０７  マス格納メモリ
６１１  バス
６１２  プロセッサ
６２１  ディスプレイ
６２２  キーボード
６２３  カーソル制御装置
６２４  ハード・コピー装置
６２５  無線／電話インターフェース
【図１】
0004538430.tif 000006
【図２】
0004538430.tif 000007
【図３】
0004538430.tif 000008
【図４】
0004538430.tif 000009
【図５】
0004538430.tif 000010
【図６】
0004538430.tif 000011