(57)【特許請求の範囲】
【請求項１】
クライアントにおいてサーバから画像を受信し、該画像は複数の独立に復号可能な符号化単位として記憶され、
クライアントが画像データの要求をサーバに送信する工程と、
サーバから伝送された要求された該画像データをクライアントが受信する工程とを有する方法において、
サーバから送信された該画像データの伝送中または伝送後に、クライアントが該画像の新しい部分の要求をサーバに送信し、該要求は、画像ヘッダから取得される、クライアントが関心ある画像の場所情報およびクライアントがすでにアクセスした画像情報を含み、
クライアントは、サーバから未送信の符号化単位だけを用いて伝送される該画像の要求された該新しい部分を受信することを特徴とする方法。
【請求項２】
画像が変換ドメインで記憶されていることを特徴とする請求項１記載の方法。
【請求項３】
クライアントからサーバへの個々の要求が要求番号を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
サーバにおいてクライアントへ画像を伝送し、該画像は複数の独立に復号可能な符号化単位として記憶され、
サーバが画像データの要求をクライアントから受信する工程と、
サーバが要求された該画像データのクライアントへの伝送を開始する工程とを有する方法において、
クライアントへの該画像データの伝送中または伝送後に、該画像の新しい部分の要求をサーバが受信し、該要求は、画像ヘッダから取得される、クライアントが関心ある画像の場所情報およびクライアントがすでにアクセスした画像情報を含み、サーバは、未送信の符号化単位だけを用いて該画像の要求された該新しい部分をクライアントへ伝送することを特徴とする方法。
【請求項５】
画像が変換ドメインで記憶されていることを特徴とする請求項４記載の方法。
【請求項６】
サーバが、要求された情報をクライアントに伝送した後にクライアントによって提供された全部の情報を直接破棄することを特徴とする請求項４または５に記載の方法。
【請求項７】
サーバが要求された符号化単位の伝送前にマーカ符号を送信することを特徴とする請求項４から６のいずれかに記載の方法。
【請求項８】
サーバが新しい画像部分のクライアントへの伝送前にトランスコーディングを実行することを特徴とする請求項４から７のいずれかに記載の方法。
【請求項９】
画像がサーバにおいて複数の符号化単位として記憶されている、サーバと関係したクライアントであって、
画像データの要求をサーバへ送信するための送信手段と、
サーバによって伝送された、要求された該画像データを受信する手段と、を有したクライアントにおいて、
サーバから伝送された該画像の受信中または受信後に、該画像の新しい部分の要求をサーバに送信する手段であって、該要求は、画像ヘッダから取得される、クライアントが関心ある画像の場所情報およびクライアントがすでにアクセスした画像情報を含み、サーバから未送信の符号化単位だけを用いて伝送される該画像の要求された該新しい部分を受信する手段を有するクライアント。
【請求項１０】
画像を変換ドメインで記憶するための手段を特徴とする請求項９記載のクライアント。
【請求項１１】
クライアントからの個々の要求が要求番号を含むことを特徴とする請求項９または１０に記載のクライアント。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアントとサーバとの間で画像を伝送するための方法およびシステムに関する。その方法およびシステムは、サーバに記憶された画像の一部の伝送に特に良好に適する。
【０００２】
【従来の技術】
デジタル画像は、サーバに記憶し、通信ネットワークによって配信することができる。画像はまた、例えばＣＤ−ＲＯＭなどによる物理的媒体に記憶することもできる。画像が大きい場合、画像を伝送するにはある程度の時間がかかるであろう。伝送を加速するために、クライアントは、より重要な画像の領域を選択し、その後その領域だけを受信することもできる。これは関心領域（ＲＯＩ）符号化として知られている。
【０００３】
今日のクライアントサーバシステムでは、クライアントがサーバに画像へのアクセスを望む場合、クライアント側のユーザプログラムとサーバとの間に接続が確立される。ユーザプログラムはその後、所望の画像を得るために要求を送信する。サーバは、ファイルをフェッチすることによって対応し、伝送を開始する。ユーザプログラムは、例えばファイルの一部の要求といった新しい要求をいつでもサーバに送信することができる。伝送が終了すると接続は閉じられる。そのようなシステムが、フィールディング（Fielding）らのハイパーテキスト転送プロトコル−ＨＴＴＰ／１．１ｒｅｖ０５、ＨＴＴＰ作業部会、ＩＮＴＥＲＮＥＴ−ＤＲＡＦＴ、１９９８年９月１１日（作業進行中）に記載されている。
【０００４】
しかし、例えばＪＰＥＧのようなほとんどの静止画像圧縮手法については、それらが分離不可能な符号化単位であるビットストリームを生成することから問題がある。従って、関心領域が選択された場合、独立に復号可能な単位を欠いていることにより、サーバは、完全な復号化を行った後にビットストリーム全体の新しい符号化を実行しなければならない。サーバソフトウェアに応じて、記憶媒体から画像を再ロードしなければならないことさえある。これに伴う欠点は、時間の消費および計算上の複雑な方式を必要とし、それはサーバの計算能力に高度な要求を負わせる。
【０００５】
さらに、新しく登場した静止画像規格ＪＰＥＧ２０００では、いわゆる符号化単位（ＣＵ）の独立エントロピー符号化が使用される。符号化単位は、例えば、変換ドメインにおけるサブバンド（すなわちウェーブレット変換の場合）、ある大きさ（例えば１６ｘ１６）のビットプレーンまたはブロックといったサブバンドの一部、または、サブバンド内の領域のビットプレーンとすることができる。
【０００６】
【発明が解決しようとする課題】
本発明の目的は上述の課題を克服すること、詳細には、クライアントがＲＯＩまたは画像の一部を要求した際にサーバにおける処理および符号化の量を低減することである。
【０００７】
【課題を解決するための手段】
上記および他の目的は、画像を独立に復号可能な単位（ＣＵ）の集合としてサーバに記憶することによって達成される。クライアントが画像のある一部を要求した場合、まだ伝送されていないＣＵにもとづく情報だけが再符号化され、それによりサーバにおいて多くの処理時間を節減する。
【０００８】
例えば、クライアントが画像情報の一連の要求を発しているとする。個々の要求は、要求番号、クライアントが次にどのような画像情報を見たがっているかの情報および、要求が発せられた時点でクライアントがどのような画像情報を受信していたかの情報を含む。サーバはいかなる状態情報（例えば、以前の要求）も記憶する必要がない。要求を受信すると、サーバは、リスタートマーカ、要求番号の確認および要求に対応した増分画像情報を送信する。
【０００９】
ここに記載する方法およびシステムの使用により、ビットストリーム全体のいかなる復号化もサーバにおいて必要とされないという結果をもたらす。これは、ストリームの完全な復号化を実行する必要がなくなるので、送信側（サーバ側）において多くの時間を節減する。
【００１０】
以下に、本発明を添付図面に関連して詳述する。
【００１１】
【発明の実施の形態】
図１に、クライアントとサーバとの間の基本的な対話を示す。このように、最初にクライアントはステップ１０１で画像を要求する。次にステップ１０３で、サーバはクライアントに画像を伝送し始める。その後ステップ１０５で、クライアントは、伝送中のある時点で現に伝送されている画像の一部を要求する。サーバは、ステップ１０５の要求に応答して、要求された部分をステップ１０７で伝送し始める。またクライアントは、ステップ１０９に示すように、画像の追加の部分をいつでも要求することができる。伝送は、ＴＣＰやＨＴＴＰといった下位プロトコルレベルにおいていつでも割り込むことができる。
【００１２】
以下の説明および対応する図面において、以下の定義、構文および表記法を使用する。
【００１３】
符号化単位（ＣＵ）は、独立に復号可能なビットストリームの一部である。従って、全体のストリームを復号化する必要なくビットストリームのある一部を復号化することが可能である。
【００１４】
タグまたは同期回復マーク(re-sync mark)は、エントロピーエンコーダから生成され得ないビットの組合せである。
【００１５】
クライアントサーバプロセスにおける構文要素
基本的なクライアントサーバプロセスにおけるいくつかの詳細な例を以下に説明する。それらは、クライアントサーバプロセスにおける構文要素の様々な特定のフォーマットに対応する。
＜画像データ要求＞は以下のフォーマットをとることができる。
−＜画像データ要求１＞は、第１の＜数＞のサブバンドを送信する
−＜画像データ要求２＞は、第１の＜数＞のビットプレーンを送信する
−＜画像データ要求３＞は、ＲＯＩ＜ＲＯＩ番号＞＜ＲＯＩ記述＞の第１の＜数＞のサブバンドを送信する
−＜画像データ要求４＞は、ＲＯＩ＜ＲＯＩ番号＞＜ＲＯＩ記述＞の第１の＜数＞のビットプレーンを送信する
−＜画像データ要求５＞は、＜ＣＵシーケンス＞（どのようなＣＵが要求されているかを記述する）を送信する
【００１６】
＜画像データ応答＞は以下のフォーマットをとることができる。
−＜画像データ応答１＞は、受信＜数＞の＜画像データ応答マーカ＞ビット／バイト／ＣＵ
−＜画像データ応答２＞は、受信＜数＞＜ＣＵ  ｎ１＞＜ＣＵ  ｎ２＞…＜ＣＵ  ｎｎ＞の＜画像データ応答マーカ＞（ここで、＜ＣＵ  ｎ＞は受信ＣＵに割り当てられた番号）
【００１７】
上記バージョン１は、ＴＣＰといった再送・パケット順序づけ伝送プロトコルにより使用される。上記バージョン２は、ＵＤＰといったコネクションレス・ベストエフォート型伝送プロトコルにより使用される。
【００１８】
＜画像データ＞は以下のフォーマットをとることができる。
−＜画像データ１＞は、第１の＜数＞の残りのサブバンドに対応する＜ＣＵストリーム＞
−＜画像データ２＞は、第１の＜数＞の残りのビットプレーンに対応する＜ＣＵストリーム＞
−＜画像データ３＞は、ＲＯＩ＜ＲＯＩ番号＞の第１の＜数＞の残りのサブバンドに対応する＜ＣＵストリーム＞
−＜画像データ４＞は、ＲＯＩ＜ＲＯＩ番号＞の第１の＜数＞の残りのビットプレーンに対応する＜ＣＵストリーム＞
−＜画像データ５＞は、＜画像データ要求５＞に指定されたＣＵに対応する＜ＣＵストリーム＞
【００１９】
いくつかの異なるフォーマットの＜ＣＵストリーム＞が可能である。
−＜ＣＵストリーム１＞は、＜ヘッダ＞＜長さＣＵ１＞＜長さＣＵ２＞…＜長さＣＵＮ＞＜ＣＵ１＞＜ＣＵ２＞…＜ＣＵＮ＞
−＜ＣＵストリーム２＞は、＜ヘッダ＞＜長さＣＵ１＞＜ＣＵ１＞＜長さＣＵ２＞＜ＣＵ２＞…＜長さＣＵＮ＞＜ＣＵＮ＞
−＜ＣＵストリーム３＞は、＜ヘッダ＞＜タグ１＞＜ＣＵ１＞＜タグ２＞＜ＣＵ２＞…＜タグＮ＞＜ＣＵＮ＞
−＜ＣＵストリーム４＞は、＜ヘッダ＞＜ＣＵ１＞＜タグｌ＞＜ＣＵ２＞＜タグ２＞…＜ＣＵＮ＞＜タグＮ＞
【００２０】
画像ヘッダは、クライアントによってすでに受信されている場合、必要ではない。
【００２１】
＜画像トランスコーディングヘッダ＞は、トランスコーディング画像を生成するために原画像に実行されたトランスコーディングオペレーションの記述を含んでいる。クライアンは、ＣＵを原画像からトランスコーディング画像にマップするために、またＣＵをトランスコーディング画像から原画像にマップするために、この情報を使用する。
【００２２】
＜画像ポスティング通知＞は、トランスコーディング画像がサーバに記憶されていることをクライアントに伝えるために使用される。それはトランスコーディング画像のＵＲＬを与える。タイムアウトは、画像が指定の時間だけ保存されるという指示をオプションで含むことができる。
【００２３】
図２に、本発明の第１の実施の形態を示す。この場合、クライアントは、記憶された画像の一部へのアクセスを望んでいる。それは、あるビットプレーン、サブバンドまたは事前に記憶された関心領域とすることができよう。この場合、サーバは、通信プロトコルにおいて使用されるもの（例えばＨＴＴＰ）を除き、その要求に応答するためにいかなる特別な機能も使用しない。このプロセスを図２に示す。
【００２４】
ステップ２０１で、クライアントは記憶された画像を要求し送信する。画像は、圧縮されたビットストリームとして、かつ独立に符号化された符号化単位（ＣＵ）よりなるフォーマットで記憶されている。
ステップ２０３で、サーバは応答し、伝送を始める。
ステップ２０５で、クライアントは画像の一部がより重要であると決定する。クライアントは、それが記憶されている場所の情報を画像ヘッダから取得し、その所望の部分の要求をサーバに送信する。その部分は、全体の画像の品質を向上させる、ＲＯＩまたは画像データとすることができる。
ステップ２０７で、サーバはここで、リスタートマークを送信することができ、要求されたＣＵの伝送を開始する。
【００２５】
リスタートマーカ機能は、ＴＣＰまたはＨＴＴＰなどの、スタックの下位プロトコルによっても付与できる。下位プロトコルレベルの情報から引き出すことが可能な場合、リスタートマーカは選択的に除外できる。
【００２６】
図３には、別の形式のクライアントサーバプロセスが示されている。図３に示すプロセスでは、サーバ側においていかなる高度な処理も実行されない。図３に関して説明する例において、クライアントは、画像を受信し始めてから、伝送の途中で、画像のいずれかの一部がより重要で、その一部だけを伝送してほしいと判断する。それは、複数のビットプレーン、サブバンドまたは関心領域とすることができよう。この場合、画像は関心領域（ＲＯＩ）とともに記憶できるであろうが、ユーザは別のＲＯＩを選択したいことに留意しなければならない。
【００２７】
そのような場合、サーバは、圧縮画像の要求された部分を見つけるためにいずれかの付加的な機能を使用しなければならない。クライアントとサーバとの間の対話および各側でのオペレーションは以下の通りとしてよいが、肯定応答メッセージおよび類似メッセージは明瞭さのために示さない。それらは、そうしたメッセージに例えば、ＩＰ、ＴＣＰ／ＵＤＰ、ＨＴＴＰまたは同様のプロトコルを使用することができる。
【００２８】
ステップ３０１で、クライアントは記憶された画像を要求し送信する。画像は、圧縮されたビットストリームとして、かつ独立に符号化された符号化単位（ＣＵ）を有するフォーマットで記憶されている。
ステップ３０３で、サーバは応答し、伝送を始める。
ステップ３０５で、クライアントは画像の一部がより重要であると決定し、関心領域を選択した場合、選択領域の形状および必要な他のいずれかの情報も送信する。それは例えば、要求の時間順番号、受信したＣＵまたはバイトの数とすることができ、図４において（＊）でマークされている。この時点で、クライアントは、例えばカリラオス・クリストポロス（Charilaos Christopoulos）（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の方法を用いて変換ドメインでのマスクを作成しており、これは、どのようなＣＵがサーバから求められているかを決定するためにサーバに必要な係数を選択する。
ステップ３０７で、サーバはその要求を取得する。サーバは、所望のＣＵを見つけるためにタグといったビットストリーム中の情報を使用する。この時点でサーバはリスタートマークおよび、必要に応じて残りのＣＵの長さを送信する。その後、要求されたＣＵの伝送を開始する。
【００２９】
以下では、クライアントが画像を受信し始めた後、伝送の途中で、画像のいずれかの一部がより重要で、その一部だけを伝送してほしいと判断した状況を扱う。それは関心領域の選択としても知られている。この場合、画像は関心領域（ＲＯＩ）とともに記憶できるであろうが、ユーザは別のＲＯＩを選択したいことに留意しなければならない。下記の例では、ＪＰＥＧ２０００のプログレッシブバイレゾリューション（ＰＢＲ：progressive-by-resolution）方式が使用される。しかし、例えばカリラオス・クリストポロス（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の通り、プログレッシブバイアキュラシー（ＰＢＡ：progressive-by-accuracy）方式といった同様の方法を適用することもできる。
【００３０】
図４に、ＪＰＥＧ２０００のプログレッシブバイレゾリューション方式を示す。ＪＰＥＧ２０００のＰＢＲモードでは、個々のサブバンドは、サブバンド全体が独立にエントロピー符号化されているので、符号化単位、ＣＵと簡略的にみなすことができる。いわゆる非適応モードが使用される場合も、その場合にサブバンドがシーケンスと同じものであるのでそれは当てはまる。これにより、クライアントがビットストリームのどこにそれがあるかを知っていれば、あらゆるサブバンドを独立にエントロピー復号化することが可能になる。ＪＰＥＧ２０００のまさにその基本モードにおいて、これは、ビット／バイト単位で各ＣＵの長さを含む、画像ヘッダに記憶されている配列によってサポートされている。従ってクライアントは、各エントロピー符号化サブバンドの長さがわかるので、ビットストリームを構文解析することができる。
【００３１】
クライアントは、要求をサーバに送信し、記憶された画像を要求する。画像は圧縮ビットストリームとして記憶されている。サーバは、ビットストリームを取得し、伝送を開始する。好適な実施の形態において、クライアントとサーバとの間の対話および各側でのオペレーションは以下の通りとしてよいが、肯定応答メッセージおよび類似メッセージは明瞭さのために除外する。
【００３２】
最初に、クライアントは、記憶された画像を要求し送信する。画像は、圧縮されたビットストリームとしてＣＵフォーマットで記憶されている。
その後サーバは応答し、伝送を始める
伝送の間のある時点で、クライアントは画像の一部がより重要であると決定し、選択領域の形状および必要な他のいずれかの情報も送信する。それは例えば、要求の時間順番号、受信したＣＵまたはバイトの数とすることができ、図４において（＊）でマークされている。
その後サーバは、そのＲＯＩの要求を取得し、送信していないＣＵについてエントロピー復号化を実行する。この場合、それは未送信のサブバンドである。エントロピー復号化により、量子化変換係数が得られる。サーバは変換ドメインのマスクを作成する。そしてサーバは、例えばカリラオス・クリストポロス（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の方法を用いて、関心領域に必要とされる係数を選択することができる。このようにして、マスクを使うことによって、サーバは、残りのサブバンドの各々においていずれの係数が必要であるかを選択する。関心領域に属する量子化係数はその後、サブバンド態様でエントロピー符号化される。従って同一のＣＵ構造が保持される。この時点でサーバは、リスタートマークおよび送信するＣＵの長さを送信し、そのＣＵの伝送を開始する。
クライアントは、使用されたトランスコーディングの形式を記述した応答をサーバから得る。その後クライアントは、例えばカリラオス・クリストポロス（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の方法を用いて変換ドメインでの所要のマスクを作成しており、これはサーバからの応答に必要な係数を選択する。
【００３３】
クライアントの観点からすれば、その結果は、関心領域は十分な解像度を有するのに対し、背景は低下した解像度を有するということになる（それはシフティングを用いる上述の方法を使用した場合、後の段階で改善できよう）。低減の量は当然、関心領域の要求がなされた時点に依存する。
【００３４】
最も起こり得る場合である、関心領域の要求がＣＵの途中になされた場合、２通りの処理方法がある。要求が行われた時点でＣＵを再送するか、または、そのＣＵの伝送が完了してから、再符号化が開始するかのいずれかである。
【００３５】
ＪＰＥＧ２０００のプログレッシブバイアキュラシーモードの場合、いかなる主要な変更も伴わずに前述の例と同じ考え方を使用することができる。この場合、ＣＵはビットプレーンである。従って、ビットストリームは精度により順序づけられる。最初に最上位ビットプレーンが伝送され、次に第２の上位ビットプレーン、以下同様となる。
【００３６】
クライアントとサーバとの間の対話および各側でのオペレーションは以下の通りであるが、肯定応答メッセージおよび類似メッセージは除外する。
【００３７】
最初に、クライアントは、記憶された画像を要求し送信する。画像は、圧縮されたビットストリームとしてＣＵフォーマットで記憶されている。
サーバが応答し、伝送を開始する。
クライアントは画像の一部がより重要であると決定し、選択領域の形状および必要な他のいずれかの情報を送信する。それは例えば、要求の時間順番号、受信したＣＵまたはバイトの数とすることができ、図４において（＊）でマークされている。この時点でクライアントは、例えばカリラオス・クリストポロス（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の方法を用いて変換ドメインでのマスクを作成しており、これはサーバからの応答に必要な係数を選択する。
サーバは、そのＲＯＩの要求を取得し、送信していないＣＵについてエントロピー復号化を実行する。この場合、それは未送信のビットプレーンである。エントロピー復号化により、量子化変換係数の残りの部分が得られる。サーバは変換ドメインでのマスクを作成する。そしてサーバは、例えばカリラオス・クリストポロス（編者）のＪＰＥＧ２０００検証モデルバージョン１．２（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１  Ｎ９８２、１９９８年８月１４日）に記載の方法を用いて、関心領域に必要とされる係数を選択することができる。このようにして、マスクを使うことによって、サーバは、ビットプレーンの各々においていずれの係数が必要であるかを選択する。関心領域に属する量子化係数の残りの部分はその後、ビットプレーン態様でエントロピー符号化される。従って同一のＣＵ構造が保持される。この時点でサーバは、リスタートマークおよび送信するＣＵの長さを送信し、そのＣＵの伝送を開始する。
【００３８】
前述の例のように背景の解像度の低減を伴う代わりに、関心領域に属さないピクセルの精度が低減される。これは単に、背景に属するビットプレーンについて残りのビットプレーンをスキップすることによって行われる。
【００３９】
要求を受信すると、サーバは原画像をトランスコーディングする。トランスコーディング画像は、後述のＣ１およびＣ２プロセスで出力バッファに送られるか、または後述のＣ３プロセスで新しい画像としてポストされるかのどちらかである。新しいクライアント要求は必ず、Ｃ１およびＣ２（以下参照）におけるように原画像かまたは、Ｃ３（以下参照）におけるようにポストされたトランスコーディング画像のいずれかのポストされた画像を参照する。クライアントは、原画像を参照している受信された画像情報がトランスコーディング画像のクライアントのコピーにおいて再使用できるように、画像フォーマット間の変換に責任を負う。成功した再使用は、＜画像データ肯定応答＞メッセージにおいてサーバに報告される。
【００４０】
クライアントサーバプロセスＣ１（ダウンロード速度について最適化される）
このプロセスは、画像情報のいかなる以前の転送も伴わずに開始することができよう。しかし、図２または３に関して上述した場合に従ったクライアントサーバプロセスが生起していることもある。原画像のＣＵの一部がこのプロセスの間にクライアントに転送されていることもあり得る。クライアントはこの以前のアクティビティを知っているが、サーバはそのようないかなる状態情報も記憶しない。
【００４１】
−クライアント要求１）＜要求番号＞＜画像データ肯定応答＞＜画像データ要求＞
−サーバ応答１）＜リスタートマーカ＞＜要求番号＞＜画像トランスコーディングヘッダ＞＜画像ヘッダ＞＜ＣＵストリーム＞（トランスコーディング画像のヘッダが送信される）
【００４２】
クライアントが新しいフォーマットを理解しない場合、それはＴＣＰレベルでストリームに割り込むことができる。クライアントサーバ交換の新しい組が継続できる。それらは、トランスコーディング画像が通常サーバによって保持されないので、必ず原画像を参照する。場合により新しい要求が生じた場合、サーバは通常トランスコーディングオペレーションを繰り返すことになる。サーバは、トランスコーディング画像のキャッシュコピーを保存すると決定することもできるが、それはクライアントによって前提とされ得ない。
【００４３】
クライアントサーバプロセスＣ２（低帯域幅について最適化）
このプロセスも、画像情報のいかなる以前の転送も伴わずに開始することができる。しかし、図２または３に関して上述した場合に従ったクライアントサーバプロセスが生起していることもある。原画像のＣＵの一部がこのプロセスの間にクライアントに転送されていることもあり得る。クライアントはこの以前のアクティビティを知っているが、サーバはそのようないかなる状態情報も記憶しない。
【００４４】
−クライアント要求１）＜要求番号＞＜画像データ肯定応答＞＜画像データ要求＞
−サーバ応答１）＜リスタートマーカ＞＜要求番号＞＜画像トランスコーディングヘッダ＞＜画像ヘッダ＞（サーバはトランスコーディング画像のヘッダを計算したにすぎない。完全なトランスコーディングは実行されていない）
−クライアント要求２）＜要求番号＞＜画像ヘッダ肯定応答＞＜画像データ肯定応答＞＜画像データ要求＞（クライアントは、自己がトランスコーディングフォーマットを取り扱えることを確認する。サーバが古い要求を保存しないので、要求は繰り返される）
−サーバ応答２）＜リスタートマーカ＞＜要求番号＞＜ＣＵストリーム＞（サーバは完全なトランスコーディングを実行し、画像ファイルの本体を出力バッファに送信する）
【００４５】
クライアントサーバプロセスＣ３（トランスコーディング画像がサーバによってポストされる）
このプロセスは、画像情報のいかなる以前の転送も伴わずに開始することができよう。しかし、図２または３に関して上述した場合に従ったクライアントサーバプロセスが生起していることもある。原画像のＣＵの一部がこのプロセスの間にクライアントに転送されていることもあり得る。クライアントはこの以前のアクティビティを知っているが、サーバはそのようないかなる状態情報も記憶しない。
【００４６】
−クライアント要求１）＜要求番号＞＜画像データ肯定応答＞＜画像データ要求＞
−サーバ応答１）＜リスタートマーカ＞＜要求番号＞＜画像トランスコーディングヘッダ＞＜画像ヘッダ＞＜画像ポスティング通知＞
−クライアント要求２）（クライアントはこの時ｈｔｔｐプロトコルレベルでポストされたトランスコーディング画像にアドレスしている）
＜要求番号＞＜画像ヘッダ肯定応答＞＜画像データ肯定応答＞＜画像データ要求＞
（クライアントは、ＣＵを原画像からトランスコーディング画像のフォーマットに変換することに責任を負う。それらのオペレーションの結果は＜画像データ肯定応答＞に入れられる）
−サーバ応答２）＜リスタートマーカ＞＜要求番号＞＜ＣＵストリーム＞
【００４７】
クライアントサーバ交換の新しい組が継続できる。それらは、クライアントによる決定に従って原画像またはトランスコーディング画像を参照することができる。
【００４８】
ある状況では受信したＣＵまたはビット／バイトの数が必要ではないことも指摘しておかなければならない。要求が送信された後にクライアントが画像データを受信し続ける場合にそれは当てはまる。サーバは、要求されたビットプレーン、サブバンドまたは関心領域が以後着信することをクライアントに知らせるために、リスタートマークおよび恐らく他の何らかの情報を送信する。
【００４９】
ストリームが要求された関心領域を含まない場合に伝送中におけるビットストリームからの関心領域の対話的選択の付加的な例を以下に説明する。これらの例は異なるビットストリームフォーマット＜ＣＵストリーム１＞から＜ＣＵストリーム４＞を例示している。
【００５０】
上述のように、図４に関して、ＪＰＥＧ２０００コーダのＰＢＲモードについて説明する。上述の方式の変更態様は、データとともにＣＵの長さを伝送することになろう。従って、サーバがＲＯＩの要求を取得し、未送信のＣＵについてエントロピー復号化を実行する場合がそうである。リスタートマークおよびＣＵの長さを送信しＣＵの伝送を開始する代わりに、サーバはこの時、リスタートマークおよび後続のＣＵの長さを送信し得る。
【００５１】
結果として生じるクライアントサーバプロセスは図５に示す。これは、図４に示すようにＣＵの長さの配列を再送する必要がまったくないという結果を生じる。
【００５２】
また、ビットストリームにタグまたは同期回復マークを使用することも可能である。従って、図４に関して上述したように個々のＣＵの長さを記述した配列を備える代わりに、ＣＵは、ビットストリームに、エントロピーコーダにより生成され得ないビットパターンによってマークすることができる。ビットストリームは、異なる符号化単位を見つけるために順次的に探索される。クライアントとサーバとの間の対話および各側でのオペレーションは、リスタートマークおよび送信されるＣＵの長さを送信しＣＵの伝送を開始する代わりに、サーバが対応するＣＵの前にリスタートマークおよびタグを伝送するように変更される。結果として生じるクライアントサーバプロセスは図６に示す。
【００５３】
代替方法は、図７に示すように、ＣＵの前ではなく、個々のＣＵまたはヘッダの後にタグを使用し送信することであることを指摘しておかなければならない。従って、クライアントとサーバとの間の対話および各側でのオペレーションは、リスタートマークおよび送信されるＣＵの長さを送信しＣＵの伝送を開始する代わりに、サーバが対応するＣＵの後にリスタートマークおよびタグを伝送するように変更される。
【００５４】
別の解決策は、サブバンドの残りに、ＪＰＥＧ２０００の「スケーリングベース方法（scaling based method）」を使用することとし得る。これは、残りのサブバンドのＲＯＩマスクがやはり生成されるが、ＲＯＩマスク係数のいかなる異なる符号化も実行されないはずであることを意味する。ＲＯＩマスク係数はある因子によりスケールアップされる。その後サブバンドの符号化は変更なく継続する。シフト値はビットストリームに記憶されるはずであるので、クライアントはシフトダウンできる。このようにして、クライアントとサーバとの間の対話および各側でのオペレーションは、リスタートマークおよび送信されるＣＵの長さを送信しＣＵの伝送を開始する代わりに、サーバが対応するＣＵの後にリスタートマークおよびタグを伝送するように変更される。
【００５５】
図４から７に関して上述した方式において、サーバは、量子化係数のエントロピー復号化の後にエントロピー符号化を実行する必要がある。これは、画像の異なる部分の真に高速なアクセスが要求される場合にあまり好ましくない。
【００５６】
この問題の解決策は、画像を独立に復号可能なブロックに分割することである。それらはＣＵとなるであろう。クライアントとサーバとの間の対話および各側でのオペレーションは、以下図８に示す。肯定応答メッセージおよび類似メッセージが除外されていることを指摘しておかなければならない。
【００５７】
−ステップ８０１で、クライアントは、記憶された画像を要求し送信する。画像は圧縮ビットストリームとして記憶されている。
−ステップ８０３で、サーバは応答し、伝送を開始する
−ステップ８０５で、クライアントは、画像の一部がより重要であると判断し、必要なＣＵを選択する変換ドメインのマスクを作成する（引用文献１参照）。所望のＣＵがサーバに送信される。
−ステップ８０７で、サーバはＣＵの要求を取得する。この時点でサーバは、その対応するＣＵの前にリスタートマークおよびタグを送信することができる。
【００５８】
ここに記載した方法およびシステムは、画像を検索するための従来のクライアントサーバシステムに比べて多くの利点を提供する。それにより、サーバは自己がどのような部分を送信したかに関する情報を記憶するためにいっさいメモリを必要としない。第１の実施の形態において、サーバは、ビットストリームの要求された所望の部分をクライアントに付与するためにいかなる処理も実行する必要はない。クライアントは、要求した部分が記憶されている場所の情報を画像ヘッダから得る。第１および第２の実施の形態では、サーバはいかなるエントロピー復号化も実行する必要はなく、要求されたＣＵを送信しさえすればよい。従って、伝送時間を劇的に減少させる。第３の実施の形態において、サーバはそのビットストリーム全体を復号化する必要がない。これは、ストリームの完全な復号化の必要がなくなるので、送信側（サーバ側）において多くの時間を節約させる。
【００５９】
また、ここに記載した方法およびシステムは、圧縮ビデオストリームに独立の復号可能な単位を有するビデオ圧縮アルゴリズムとともに使用されるように拡張することもできる。
【図面の簡単な説明】
【図１】  クライアントサーバプロセスにおいて実行される基本的なステップを示す。
【図２】  第１の実施の形態に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図３】  第２の実施の形態に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図４】  第３の実施の形態に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図５】  第３の実施の形態の第１代替例に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図６】  第３の実施の形態の第２代替例に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図７】  第３の実施の形態の第３代替例に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図８】  第４の実施の形態に従ってクライアントサーバプロセスにおいて実行されるステップを示す。
【図１】
0004764549.tif 000002
【図２】
0004764549.tif 000003
【図３】
0004764549.tif 000004
【図４】
0004764549.tif 000005
【図５】
0004764549.tif 000006
【図６】
0004764549.tif 000007
【図７】
0004764549.tif 000008
【図８】
0004764549.tif 000009