JP2004193752A - 画像処理方法 - Google Patents
画像処理方法 Download PDFInfo
- Publication number
- JP2004193752A JP2004193752A JP2002356736A JP2002356736A JP2004193752A JP 2004193752 A JP2004193752 A JP 2004193752A JP 2002356736 A JP2002356736 A JP 2002356736A JP 2002356736 A JP2002356736 A JP 2002356736A JP 2004193752 A JP2004193752 A JP 2004193752A
- Authority
- JP
- Japan
- Prior art keywords
- encoded data
- image
- data
- command
- image encoded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Compression Of Band Width Or Redundancy In Fax (AREA)
- Television Signal Processing For Recording (AREA)
Abstract
【解決手段】サーバ装置が保持するスケーラビリティを有する画像符号化データを受信する場合、端末装置で入力された入力の種別に応じて、指示した画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを1回の受信処理で受信するためにサーバ装置に送信する第1のコマンド、もしくは画像符号化データにおける部分画像符号化データを特定する情報を第1のコマンドよりも詳細に記述し、且つ部分画像符号化データをサーバ装置から所定の単位毎に受信するためにサーバ装置に送信する第2のコマンドの何れかを生成してサーバ装置に送信し、サーバ装置から送信される画像符号化データを受信してデコードして所定の出力装置に出力する。
【選択図】 図8
Description
【発明の属する技術分野】
本発明は、スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された画像符号化データを受信し、受信した画像符号化データを1つの画像ファイルに作成する技術に関するものである。
【0002】
【従来技術】
インターネット上では、WWWサーバにWeb(ウエブ)ブラウザを用いてアクセスして文書データや画像データ等を閲覧することが盛んに行われている。このシステムはインターネット上に情報を公開するWWWサーバと、その情報を閲覧するクライアント装置(端末装置)とを含み、各端末装置上ではウェブブウザが実行されており、各端末装置のユーザはこのウエブブラウザを用いてWWWサーバによって公開された情報を閲覧することができる。このWWWサーバには、ホームページと呼ばれる公開対象の情報をHTMLで記述したファイルが保存されており、上述の通り端末装置のユーザはウェブブウザを用いてこれにアクセスすることで端末装置の表示装置の表示画面上に上記ファイルによって表現される内容を表示することができる。
【0003】
また端末装置側のウエブブラウザを用いることで、表示装置の表示画面上に表示しているページ内のリンクを辿っていくことができ、これにより必要な情報を得ることができる。更に、WWWサーバが管理しているファイルを端末装置にダウンロードするためには、File Transfer Protocol(以下、FTPと略す)を用いるのが一般的である。このFTPとは、ネットワークを通してWWWサーバが管理するファイルを一度に端末装置に転送する技術である。
【0004】
また上記ファイルには画像ファイルも含まれており、端末装置からWWWサーバが管理する画像ファイルへ複数回に分けてアクセスし、アクセスした画像ファイルの内容(画像)を表示装置に表示するために使用するプロトコルとしてFlashpix/IIPがある。このIIPはFlashpixと呼称される画像データファイルのフォーマットに最適なプロトコルになっており、画像データへ複数回に分けてアクセスする際において1回のアクセス単位は、このFlashpixのタイル単位に行うものである。
【0005】
ここで、このIIPをそのままJPEG2000に適用した場合を考える。JPEG2000では、各スケイラビリティを有する符号化データにおいて、夫々の符号化データは、自身が有するスケーラビリティよりも1つ下のスケイラビリティのデータからの差分データで構成されている。WWWサーバがJPEG2000に従った符号化データを保持しており、端末装置からウェブブウザを用いてこの符号化データに対して複数回に分けてアクセスし、夫々のアクセスにおいて受信した各スケーラビリティの符号化データをデコードして表示装置にデコード結果を表示する場合、端末装置は受信した各スケーラビリティの符号化データをメモリにキャッシュしておき、全ての符号化データを受信するとこれらの全ての符号化データをデコーダに送り、デコードする方法や、各符号化データ毎にデコードし、新たに符号化データを受信すると、これを前回の続きからデコードする方法がある。
【0006】
このような状況に鑑みて、マルチ解像度を有する画像符号化データの中から必要な部分のデータのみを取り出して別の符号化データに変換する方法として従来から様々な方法が提案されている(例えば特許文献1を参照)。この種の技術として従来では、ソースとなる画像データは、ウェーブレット変換等のようなマルチ解像度のデータを管理するための符号化方式を用いて符号化されている。そして、このソースとなる符号化データ(オリジナル符号化データ)の中から、クライアントが選択した空間的な領域に対応する符号化データ(部分符号化データ)を取り出し、1つの独立した符号化データに変換するものである。この時、ソオリジナル符号化データから取り出される部分符号化データはJPEG2000のコードブロックに対応しており、部分符号化データの全ての階層で、かつ全てのサブバンドから部分符号化データに該当する、もしくは関係する全ての符号化データを含むものである。
【0007】
また他の従来技術としては、ソースとなる画像データは、マルチ解像度のデータを有する画像データであって、サーバと端末装置との間で画質とデータ量のトレードオフを決めるための調停を行う手段を有し、最終的にはサーバ側で転送するデータ量を決め、この調停で決められたデータ量で且つ論理的な符号データの単位まで、サーバが端末装置に対してデータを転送するものである(例えば特許文献2を参照)。
【0008】
【特許文献1】
米国特許第6041143号(「MULTIRESOLUTION COMPRESSED IMAGE MANAGEMENT SYSTEM AND METHOD」)
【特許文献2】
米国特許第5764235号(「COMPUTER IMPLEMENTED METHOD AND SYSTEMFOR TRANSMITTING GRAPHICAL IMAGES FROM SERVER TO CLIENT AT USER SELECTABLE RESOLUTION」)
【0009】
【発明が解決しようとする課題】
端末装置が受信した各スケーラビリティの符号化データをメモリにキャッシュしておき、全ての符号化データを受信するとこれらの全ての符号化データをデコーダに送り、デコードする場合、サーバ側から送られてくる各スケーラビリティの符号化データを、直接JPEG2000準拠の1つの符号化データファイルに作り直すことは可能である。
【0010】
しかし、サーバ側から送られてくる各符号化データは、端末装置側から要求する順に送られてくるため、端末装置が受信した符号化データをJPEG2000準拠の1本の符号化データに変換することは、端末装置側の処理が煩雑になり、コストがかかるという問題点がある。
【0011】
又、サーバから送られてきた各符号化データを独自形式のキャッシュファイルとして構成し、端末装置側のJPEG2000デコーダが直接このキャッシュファイルをリードすることも可能であるが、この場合、JPEG2000のデコーダは、この独自のキャッシュファイルをリードするための処理が必要となる。このため、処理が複雑になると共に、汎用のJPEG2000デコーダが使えないという問題点がある。
【0012】
そこで、JPEG2000の画像をパケット単位で受信し、それらパケットデータをキャッシュしておく。そして、デコーダへデータを渡す際に、まだ受信していないパケットデータ部分に、zero length packet(以下、ZLPと略す)データを挿入し、既に受信したパケットデータと合せて、一つのファイルを作成することで、メインヘッダの書き換えなど煩雑な処理を行わずに、一般的なJPEG2000デコーダで処理できるJPEG2000ファイルを作成する方法もある。
【0013】
また、端末装置からサーバに画像符号化データを送信する旨の要求を示すコマンドが、サーバが保持するファイルを構成する論理的な固まりの単位のみを示す場合には、サーバに対して要求を発行しなければ転送される画像符号化データのサイズを判断することはできない。それによって画像符号化データを端末装置に転送する時間が、端末装置側で予想される時間以上に要していまい、転送にリアルタイム性が要求される場合、例えば端末装置において画像サイズの大きい画像に対して高速にパンニングを行うなどの操作を行い、パンニングに応じた画像符号化データをサーバから受信する場合には不向きである。
【0014】
更に、上述の従来技術には以下の問題がある。すなわち端末装置がある画像符号化データのうち、既にいくつかの部分画像符号化データを受信している場合であっても、端末装置からサーバに要求を送信する度に、サーバから端末装置に対して全ての階層の全コードブロックの符号化データが送られる。すなわち、サーバは端末装置が既に受信済みの符号化データまでも送信することになる。更に、送信する符号化データのヘッダ部分は、今回要求した画像データの情報(画像サイズ、階層情報など)に書き換えられており、元々サーバで管理している符号化データの情報を取ることができない。
【0015】
また、上述の別の従来技術には以上の問題に加え、画質と量のトレードオフによって、ユーザが要求した画質を表示/印刷できない場合もある。また、サーバ、端末装置間での調停のため通信コストがかかる上、サーバの処理が多くなり、サーバの負荷が増大し、ひいてはユーザの要求から表示までの時間がかかるという問題点がある。
【0016】
本発明は以上の問題に鑑みてなされたものであり、複数の解像度の画像を有する符号化データの受信形態を、目的に応じて切り替える技術を提供することを目的とする。
【0017】
【課題を解決するための手段】
本発明の目的を達成するために、例えば本発明の画像処理方法は以下の構成を備える。
【0018】
すなわち、スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された当該画像符号化データを受信する画像処理方法であって、
ユーザからの各種の入力を受け付ける入力工程と、
当該入力工程で入力された入力の種別に応じて、当該入力工程で指示された画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを1回の受信処理で受信するために前記サーバ装置に対して送信する第1のコマンド、もしくは前記画像符号化データにおける前記部分画像符号化データを特定する情報を当該第1のコマンドよりも詳細に記述し、且つ前記部分画像符号化データを前記サーバ装置から所定の単位毎に受信するために前記サーバ装置に対して送信する第2のコマンドの何れかを生成し、前記サーバ装置に対して送信する送信工程と、
前記サーバ装置から送信される、当該送信工程で送信されたコマンドに応じた画像符号化データを受信してデコードし、デコード結果を所定の出力装置に出力する出力工程と
を備えることを特徴とする。
【0019】
【発明の実施形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。なお、本発明は、端末装置がサーバ装置からネットワークを介して受信した断片的な画像データを、一つの画像ファイルに作成し直す方法に関するものである。特に、ISO/IEC−15444に準拠したJPEG2000符号化データ(以下、単に画像符号化データと呼称する)をサーバ装置からインターネット・イメージング・プロトコル(IIP)などで画像符号化データの断片的な領域、或いは、断片的な画像符号化データを受信し、それらの断片化された画像符号化データを独自の方式でキャッシュするクライアントの端末装置(以下、単に端末装置と呼称する)において本発明は実施可能である。
【0020】
更には本発明は、端末装置において実行されるアプリケーションプログラムにより要求される表示要求に応じて、端末装置側で受信した断片化された画像符号化データのキャッシュデータから1つのJPEG2000準拠の符号化データファイルを生成するものである。
【0021】
[第1の実施形態]
図1は、インターネットやLANに代表されるネットワーク上に複数のコンピュータが接続されている本実施形態におけるシステムの概略構成を示す図である。
【0022】
図1において、100はインターネットやLANに代表されるネットワークである。101,103はサーバ装置であり、それぞれ画像データを送信するためのJPEG2000用のIIPサーバ機能、WWWサーバ機能に必要なソフトウェアを保持すると共に実行している。また、これらサーバ101,103はそれぞれ大容量のハードディスク101a,103aを接続しており、そのハードディスクに大量の画像データも格納している。102a,102bはクライアント側の端末装置であり、ウェブ(Web)ブラウザ、JPEG2000デコーダなどのソフトウェアを保持していと共に、必要に応じてこれを実行することが出来る。同図にはサーバ装置、端末装置は夫々2台ずつ示しているが、本実施形態におけるシステムを構成するサーバ装置、端末装置の数はこれに限定されるものではない。
【0023】
図2は、サーバ装置101,103、端末装置102a,102bの基本構成を示すブロック図である。なお、サーバ装置と端末装置とは基本的には同じ構成を備えるが、構成する各部が行う処理が異なる部分もある。
【0024】
図2において、201はCPUで、ROM204やRAM205が保持するプログラムやデータを用いて装置全体の制御を行うと共に、後述の画像符号化データの送受信に係る処理を行う。なお同図の構成がサーバ装置のものである場合にはCPU201は画像符号化データの送信に係る処理、同図の構成が端末装置のものである場合にはCPU201は画像符号化データの受信に係る処理を行うことになる。また、キーボード202,マウス202aから入力された指示に従った処理も行う。
【0025】
202、202aは夫々キーボード、マウスで、夫々ポインティングデバイスとして用いられ、各種の指示(各種のデータ、コマンド等)をCPU201に対して入力することが出来る。203は表示部で、CRTや液晶画面などにより構成されており、画像や文字などの各種の情報を表示することが出来る。なお同図の構成がサーバ装置のものである場合には、例えばサーバ装置のシステム情報や、画像符号化データの要求の受信状況などを表示する。また同図の構成が端末装置ものである場合には、例えば要求する画像符号化データを選択するためのGUIや受信した画像符号化データをデコードした結果などを表示する。
【0026】
204はROMで、装置を制御するためのプログラムやデータなどを保持する。205はRAMで、ハードディスク206や記憶媒体ドライブ207からロードされるプログラムやデータを一時的に保持するエリアを備えると共に、CPU201が各種の処理を行うために必要なワークエリアも備える。206はハードディスクで、OS(オペレーティングシステム)や、後述の画像符号化データの送受信に係る処理プログラムやデータ等を格納する。
【0027】
なおハードディスク206は、同図の構成がサーバ装置のものである場合には画像符号化データの送信に係る処理をCPU201が実行するためのプログラムやデータや、IIPサーバ機能、WWWサーバ機能をCPU201が実行するためのプログラムやデータ、例えば端末装置のユーザがウェブブウザを用いてアクセスすることにより閲覧できるホームページのデータ、閲覧する複数の画像の符号化データ等を保持する。なお、同図の構成がサーバ装置のものである場合にはハードディスク206は図1における101a、101bに対応するものである。
【0028】
またハードディスク206は、同図の構成が端末装置のものである場合には画像符号化データの受信に係る処理をCPU201が実行するためのプログラムやデータ、ウェブブラウザのプログラムやデータ、JPEG2000デコーダのプログラムやデータを保持する。
【0029】
207は記憶媒体ドライブで、CD−ROMやDVD−ROMなどの記憶媒体に記憶保持されているプログラムやデータを読み取り、RAM205やハードディスク206に読み出したプログラムやデータを出力する。なお、ハードディスク206が記憶保持する上述の各プログラムやデータの一部、もしくは全部を記憶媒体に記憶保持させておき、必要に応じて読み出しても良い。208はプリンタである。209はネットワークインターフェースで、図1に示したネットワーク100と本装置を接続するためのもので、ネットワークインターフェース209を介して各種のデータの送受信を行うことが出来る。
【0030】
なお同図の構成がサーバ装置のものである場合にはネットワークインターフェース209を介して、端末装置からの画像符号化データの送信要求を受信したり、要求に応じた画像符号化データの一部、もしくは全部を送信する。また同図の構成が端末装置のものである場合には、ネットワークインターフェース209を介して、サーバ装置に対して画像符号化データの送信要求を送信したり、サーバ装置から要求に応じた画像符号化データの一部、もしくは全部を受信する。
【0031】
本実施形態では、JPEG2000に従って圧縮符号化された画像データがサーバ装置のハードディスク206、もしくは不図示の(サーバ装置の記憶媒体ドライブ207が読み取り可能な)記憶媒体に複数記憶保持されており、端末装置から1つの画像符号化データを送信する要求を受けると、ハードディスク206から対象の画像符号化データが読み出され、端末装置に対して送信することが出来る。
【0032】
また端末装置は、画像表示/印刷アプリケーションを用いてサーバ装置に対してJPEG2000ファイル内の必要な部分のみをJPEG2000用のIIPを用いて要求することができ、要求に応じてサーバ装置から断片的に送信されてくる画像符号化データタ受信する。そしてこの受信した断片的な画像符号化データは端末装置のRAM205やハードディスク206に格納(キャッシュ)される。そして端末装置はハードディスク206にキャッシュされた断片的な画像符号化データから、JPEG2000のデコーダに渡すためのJPEG2000準拠の画像符号化データに変換する。
【0033】
次に、上記構成を備えるシステムにおいて、端末装置からサーバ装置に対して所望の画像符号化データを要求した場合に、サーバ装置、端末装置の夫々が行う処理について説明する。
【0034】
すなわち以下では、図1に示した端末装置102a,102bのユーザは、上述のウェブブウザを用いてサーバ装置101もしくは103の何れかにアクセスし、表示部203に画像を閲覧するためのホームページを表示させる。そしてユーザが画像を閲覧するためのホームページにおいて、1つの画像をキーボード202やマウス202を用いて指示することで、端末装置はサーバ装置から送信される指示された画像の符号化データ、すなわちJPEG2000に従って圧縮符号化された画像符号化データを断片的に(画像符号化データを複数回に分けて)RAM205にキャッシュする。そして、これらキャッシュデータから一本のビットストリームを作り出してデコードし、表示するという処理においてサーバ装置、端末装置の夫々が行う処理について説明する。
【0035】
次に図3を参照して一般的なJPEG2000ファイルについて説明する。図3は、Layer−resolution level−component−position progression(以下、SNR Progressionと記す)に従って生成されたJPEG2000ファイルの概略構成を示す図である。
【0036】
JPEG2000ファイルはメインヘッダ(Main Header)、タイルヘッダ(Tile Header)、データ(Data)が含まれており、このデータの部分に画像符号化データが記録されることになる。またタイルヘッダは、圧縮符号化元の画像を所定のサイズの矩形(タイル)毎に分割し、夫々のタイルの圧縮符号化データを生成した場合に、夫々のタイルの圧縮符号化データに対して作成されるものである。メインヘッダ、タイルヘッダについては公知の技術によるものであるのでここでの説明は省略する。
【0037】
このSNR Progressionに準じた場合、画像符号化データは、(レイヤ)Layer/(解像度)Resolution/(成分)Component/(位置)Positionの順に記録される。次に、解像度(画像サイズ)とResolution番号との関係を図4に示す。
【0038】
図4において、最も小さい解像度の画像の解像度(resolution)番号を「0」とし、resolution番号が一つ増加するごとに画像の幅と高さが共に倍になっていく。この解像度毎の符号データは、解像度番号の小さいものから順に、プログレッション・オーダに従って格納されている。
【0039】
一方、レイヤは、復元する画像の原画に対するS/N比に対応し、レイヤ番号が小さいほどS/N比が悪くなる。レイヤ毎の符号データも解像度毎の符号データと同様に、レイヤ番号の小さい順にプログレッション・オーダに従って格納されている。
【0040】
また各Resolutionには所定の順番で各色成分等のデータ(Componentデータ)が記録されており、各Componentデータには順番通りに番号(コンポーネント番号)が付けられている。また各Componentデータには圧縮符号化元の画像において空間的な各位置におけるコードブロック(符号化対象の最小単位)のデータ(Positionデータ)が順番に記録されており、各Positionデータにはコードブロックの空間的な順番通りに番号(ポジション番号)が付けられている(例えば画像の左上隅を0として画像の右方向に1つずつ番号が増加し、右端に達したら1つ下、且つ左端からまた画像右方向に番号が増加する)。
【0041】
一つのJPEG2000ファイル内でのResolution番号とレイヤ番号、コンポーネント番号の最大値は、エンコーダによって予め設定されており、圧縮符号化元の画像はそのパラメータに従ってエンコードされており、その情報はメインヘッダに記録されている。また各パケット(packet)は、そのパケットに格納されているコードブロック(code−block)の情報を管理しているパケットヘッダ(packet header)部と、各コードブロックの符号化データから構成されている。同図では1つのPositionデータがパケットに相当する。
【0042】
このような構造を有するJPEG2000ファイルがサーバ装置に保持されていれば、端末装置は必要な解像度等、要求する部分の画像のみをサーバ装置から受信することができる。受信するデータの単位としては、JPEG2000のパケット(packet)、或はパケットよりも更に小さい符号化単位であるコードブロック単位が考えられる。本実施形態では、端末装置がサーバ装置から受信するデータ単位としてパケット単位を想定する。このパケット単位でのリクエスト及びレスポンスの概念図を図5に示す。同図ではサーバ装置101、端末装置102a間のリクエスト、レスポンスについて示しているが、サーバ装置103、端末装置102bを適用しても良いことはいうまでもない。
【0043】
同図は、画像がタイル分割されており、各タイルの符号化データ(同図ではTile0〜TileNまでの各データ)がJPEG2000ファイル503としてサーバ装置101に接続されているハードディスク101aに格納されている状態で、端末装置102aから所望のタイル、所望の解像度、所望のレイヤ、所望のコンポーネント、そして所望の空間的な位置の符号化データを要求する場合に、サーバ装置101と端末装置102aとの間で行われる通信を示すものである。
【0044】
ここで例えば端末装置102aがタイル番号は「1」、解像度番号は「0」、レイヤ番号は「0」、コンポーネント番号は「0」、そしてポジション番号は「0」である符号化データをサーバ装置101に要求した場合、サーバ装置101はハードディスク101aに保存しているJPEG2000ファイル503を解析して、要求に相当する部分(要求されたタイル番号、解像度番号、レイヤ番号、コンポーネント番号、ポジション番号に相当する部分)をパケットデータとして抜き出し、パケット0として端末装置102aに返信する。
【0045】
図6は、本実施形態におけるサーバ装置101(もしくは103)に接続されたハードディスクに保持されているJPEG2000ファイルの構成の一例を示す図である。図3に示すとおりJPEG2000ファイルはメインヘッダ、タイルヘッダ、そしてデータ(画像符号化データ)に大別される。同図では画像符号化データは2つのレイヤデータ「0」、「1」に大別される。夫々のレイヤデータは「0」〜「5」の6種類の解像度データに大別される。またコンポーネントデータ、ポジションデータは夫々「0」の1種類である。ここで説明を簡単にするために、サーバ装置101で管理しているJPEG2000の画像符号化データの最大解像度の画像サイズを4096×4096画素とする。よって6種類の解像度があると、各解像度での画像サイズは、4096x4096,2048x2048,1024×1024,512×512,256×256,128×128画素となる。また夫々の符号化データに対して括弧書きで示している数値は各画像符号化データのバイト数を示す。
【0046】
図7は、端末装置102a(端末装置102bも同様)におけるウェブブウザが行う、サーバ装置101(サーバ装置103でも良い)に対してJPEG2000ファイルの送信を要求し、要求したJPEG2000ファイルをデコードして表示部203に表示する処理のフローチャートである。同処理はウェブブウザのプログラムをCPU201が実行することで行われるものである。なお同図のフローチャートでは、端末装置102aにおいてユーザがキーボード202やマウス202aを用いて予め送信を要求する画像を選択している。選択方法としては例えば、サーバ装置101が提供するホームページ上でサーバ装置101が保持する複数の画像のサムネイルが表示されており、ユーザはキーボード202やマウス202aを用いてこれらのうち1つのサムネイルを指示する。よって同図に示したフローチャートに従った処理では、選択した画像のJPEG2000ファイルの送信要求を行う。
【0047】
ステップS1では、ユーザからの操作入力を受け付ける。操作入力しては例えば選択している画像の拡大、縮小、パンニング等を行うための操作入力をキーボード202やマウス202aを用いて入力する。
【0048】
次にステップS2では、ステップS1で入力された操作入力から、必要なパケットを特定する。その後ステップS3において、ステップS1にてユーザが入力した操作の内容を判断し、予めウェブブウザが保持する複数のコマンドから判断した操作の内容に応じたコマンドを選択する。ステップS3における処理の詳細については後述する。次にステップS4では、ステップS3で選択されたコマンドをサーバ装置に対して送信する。ステップS4における処理の詳細については後述する。
【0049】
ステップS5では、ステップS4におけるサーバ装置への送信に対するレスポンス、即ち要求に応じた画像符号化データを受信し、RAM205にキャッシュする。ステップS6では、ステップS5でRAM205にキャッシュした画像符号化データからJPEG2000準拠のビットストリームを作成する。ステップS6における処理の詳細については後述する。その後ステップS7においてステップS6で作成したビットストリームを上記JPEG2000デコーダソフトによりデコードし、表示部203上に表示する。ステップS8では、本アプリケーションにより処理の終了が入力されたか否かを判断し、終了しない場合には処理をステップS1に戻す。
【0050】
次に、上記ステップS3における、処理の詳細について説明する。図8はステップS3における処理の詳細を示すフローチャートである。以下、同図のフローチャートを参照して、ステップS3における処理の詳細について説明する。
【0051】
まずステップS80は、ステップS1入力された操作の内容を解析する。具体的には、入力された操作に対して高速にレスポンスを返すべきであるか否かを判断する。例えば、連続的な拡大表示や、表示ウィンドウに画像全体を1度に表示できない場合の、画像のパンニングに対しては、高速にレスポンスを返すべきである。これらの操作は、ユーザが連続して行う可能性があり、各操作に対応した処理が高速に行われることが要求されるからである。
【0052】
よってステップS80では上記各操作が入力された場合には、高速にレスポンスを返すべきと判断て処理をステップS82に進め、上記各操作以外が入力された場合には、高速にレスポンスを返す必要がないと判断して処理をステップS81に進める。
【0053】
ステップS81では、ステップS2で特定したパケットの画像符号化データを全てサーバ装置から受信するためにサーバ装置に対して送信するコマンドを用意する。一方ステップS82では、ステップS2で特定したパケットの画像符号化データの内、一部分のみを物理的なバイト数で指定してサーバ装置から受信するために、サーバ装置に対して送信するコマンドを用意する。
【0054】
具体的にステップS82で用いるコマンドの仕様は以下の通りである。
【0055】
Tile/Reso/Layer/Compo番号 先頭オフセット 最大要求バイト数
このコマンドの中で「Tile/Layer/Compo番号」は、要求するパケットを特定するためのTile番号、Resolution番号, Layer番号, Component番号を示す。その次の「先頭オフセット」は、要求したパケットのJPEG2000ファイル内における記録位置の先頭からのオフセットであり、このパケットを最初に要求する場合は「0」である。最後の「最大要求バイト数」は今回の要求で転送するパケットデータの最大バイト数である。
【0056】
本実施形態ではステップS1で入力する操作内容として高速レスポンスを要求する操作を入力するものとし、またこの操作として画像の拡大表示を行う操作を例に取り以下、説明する。
【0057】
一般に、表示部203に表示された画像を拡大、縮小する手段として、マウスのホイールを使う場合がある。ホイールの場合、連続して上下に回転するため、短時間の間に、連続して拡大、縮小の倍率が入力され、これに応じて、連続して拡大画像や縮小画像をサーバ装置に対して要求することになる。
【0058】
例えば複数の画像がサムネイル表示されており、これら複数のサムネイル画像の中から1枚を選択してその画像の詳細な画像を表示、すなわち拡大表示する場合には、上述の通りホイールを回転させて表示画像を拡大させる。本実施形態ではホイールの回転により連続的に2回の拡大表示が要求された場合を説明する。
【0059】
この場合、サムネイル画像を指示すると、指示したサムネイル画像が所定の解像度の画像として表示部203に1枚表示される。この段階で表示される画像の解像度レベルを「0」とする。ここで、ホイールの回転により1回目の拡大操作が入力されたとすると、表示部203は1つ上の解像度レベル、即ち解像度レベル「1」の画像が表示されるよう、サーバ装置に対して解像度レベル「1」の画像を表示するための画像符号化データを送信する要求(コマンド)を送信する。更にホイールの回転により2回目の拡大操作が入力されたとすると、表示部203に更に1つ上の解像度レベル、即ち解像度レベル「2」の画像が表示されるよう、サーバ装置に対して解像度レベル「2」の画像を表示するための画像符号化データを送信する要求(コマンド)を送信する。
【0060】
図9は、この場合にサーバ装置と端末装置との間でのコマンド送信、レスポンス返信のシーケンスを示す図である。本実施形態では例として、1度に要求するパケットのバイト数を128バイトとする。
【0061】
図中900はサーバ装置、901は端末装置を示す。まず端末装置901において解像度レベル「1」の画像を表示するために必要な画像符号化データ(パケット)を要求するためのコマンド902をパケット要求1としてサーバ装置900に送信する。コマンド902の詳細を同図の下部に示す。
【0062】
コマンド902は端末装置901の表示部に現在表示している画像(サムネイル画像を指示することで表示される解像度レベル「0」の画像)の解像度レベルより1つ上の解像度レベルの画像の画像符号化データをサーバ装置に要求するためのコマンドで、図6に示した各符号化データにおいて、レイヤ番号0、解像度番号1、コンポーネント番号0、ポジション番号0の符号データの先頭から最大128バイトを要求するコマンドである。サーバ装置900は後者の画像符号化データをレスポンスとして端末装置901に返信する。このレスポンスが図9におけるレスポンス1として示されている。
【0063】
レスポンス1、即ちパケットの詳細を同図の下部に示す。レイヤ番号0、解像度番号1、コンポーネント番号0の画像符号化データのデータサイズは図6に示すとおり96バイトであり、最大で128バイトの要求であったため、今回の要求であるパケットデータは、最大バイト数よりも小さいため1回の要求で要求されたパケットデータを全て送信することができる。そのため、96(今回送信したデータサイズ)/0(後送信すべきデータサイズ)を示す情報もレスポンス1として端末装置901に送信する。
【0064】
端末装置901はこの画像符号化データを受信すると、CPU201による制御の下でRAM205にキャッシュすると共に、JPEG2000デコーダによりデコードし、デコード結果である解像度レベル1の画像を表示部203に表示する。また上記96/0の情報をも受信しているので、CPU201はこの情報を参照することで、今回受信したパケットは完全なパケット(要求に対する全てのパケット)であると判断することができ、解像度レベル「1」に画像を表示するための処理を終了することが出来る。
【0065】
次にCPU201は解像度レベル「2」の画像を表示するために必要な画像符号化データをサーバ装置900に要求するためのコマンド904をパケット要求2としてサーバ装置900に送信する。コマンド904の詳細を同図の下部に示す。
【0066】
コマンド904は端末装置901の表示部に現在表示している画像(解像度レベル「1」の画像)の解像度レベルより1つ上の解像度レベルの画像の画像符号化データをサーバ装置に要求するためのコマンドで、図6に示した各符号化データにおいて、レイヤ番号0、解像度番号2、コンポーネント番号0、ポジション番号0の符号データの先頭から最大128バイトを要求するコマンドである。
【0067】
サーバ装置900はこの要求に対応する画像符号化データをレスポンスとして端末装置901に返信する。このレスポンスが図9におけるレスポンス2として示されている。
【0068】
レスポンス2、即ちパケットの詳細を同図の下部に示す。レイヤ番号0、解像度番号2、コンポーネント番号0の画像符号化データのデータサイズは図6に示すとおり384バイトであり、あとサーバ装置900が端末装置901に送信すべき画像符号化データのサイズは256バイトとなる。そこでレスポンス2として128(今回送信したデータサイズ)/256(後送信すべきデータサイズ)を示す情報をもレスポンス2として端末装置901に送信する。よってこの情報を受信した端末装置901は、更に受信すべき画像符号化データがあると判断し、特に端末装置901のユーザからの入力がなければ、次の128バイトの画像符号化データを送信するよう、サーバ装置900に対してコマンドを送信する(パケット要求3)。
【0069】
また端末装置901は画像符号化データを受信すると、CPU201による制御の下でRAM205にキャッシュすると共に、JPEG2000デコーダによりデコードする。ここでまた受信していない部分のデータとしてはこの部分に相当するDWT(離散ウェーブレット変換)を0として公知のJPEG2000に従ったデコード処理を行い、デコード結果である解像度レベル2の画像を表示部203に表示する。
【0070】
なお、上述のステップS81で用いるコマンド仕様は以下の通りである。
【0071】
packet要求コマンド Tile/Reso/Layer/Compo番号
このコマンドの中で「Tile/Layer/Compo番号」は、要求するパケットを特定するためのTile番号、Resolution番号、Layer番号、Component番号を示す。このコマンドは、指定したパケットのデータを1回でサーバ装置から端末装置に転送させるためのコマンドである。
【0072】
なお、本実施形態ではレスポンスとしてサーバ装置から端末装置が受信する画像符号化データは指定されたもののみであったが、サーバ装置が端末装置に送信するパケットのデータサイズが、最大送信サイズ以下で事足りる場合には、その差分(最大送信データサイズ−送信したパケットのデータサイズ)として他のデータを送信しても良い。
【0073】
例えば図9に示した通信を例に取ると、解像度レベル1の画像符号化データのサイズは96バイトであるが、端末装置は最大128バイト受信可能であるので、この時点で後32バイト分のデータをサーバ装置は端末装置に対して送信可能である。そこでサーバ装置は96バイトの画像符号化データを端末装置に対して送信すると共に、残りの32バイト分を次の解像度レベル(解像度レベル2)の画像符号化データを送信しても良い。このようにすることで、毎回の通信に無駄が無くデータを送信することが出来る。
【0074】
また本実施形態では、パケットデータ要求コマンドは、通常のパケットデータ要求コマンドとは別の、「部分的なパケット要求コマンド」で説明したが、これに限るものではなく、コマンドとしては同一で、パラメータの数で判断することも可能である。
【0075】
また上記説明では1度に転送するパケットのバイト数を128バイトとしたが、これに限るものではない。
【0076】
次に、キャッシュ管理をするためのテーブルのデータ構造を図10を用いて説明する。同図のテーブルは端末装置のRAM205上に形成されるものである。同図のテーブルはタイル毎に存在するものであるが、本実施形態では画像はタイル分割されていないので、同図のテーブルは1つのみ存在することになる。
【0077】
同図に示すテーブルの中には、受信したパケットの数を格納する領域1001や、各パケットのデータを格納する領域1002が存在する。各パケットの個数(同図ではN)が領域1001に格納されている。更に領域1002において1つのパケット管理テーブルには領域1003乃至1005が存在する。領域1003はパケットの全バイト数を管理するフィールドであり、まだ1度もこのパケットを要求していない場合は「−1」、1度でも要求すると、そのパケットの全バイト数が入る。よって領域1003には「−1」(未要求)、「0」(元々Zero length packet)、「0以上の値」(パケットの全バイト数)の何れかの値が格納されていることになる。
【0078】
よって、キャッシュした夫々のパケットからJPEG2000の画像符号化データを作成する場合には、この領域1003には「−1」や、「0」の時、zerolength packetのコードを入れる。次に領域1004は、現在キャッシュしているパケットデータの実際のバイト数であり、通常のパケット要求コマンドで要求した場合は、領域1003に記録されたバイト数と領域1004に記録されたバイト数とは一致することになる。しかし部分的なパケット要求コマンドを発行した場合は、一致しないことがある。領域1005は実際のパケットデータのRAM205におけるアドレスを格納する。1006は対応するパケットデータである。
【0079】
このような管理テーブルを用いて、CPU201がユーザからの要求から必要なパケットを計算した時に、キャッシュ上にデータがあるか否かを判断し、コマンドを発行するかどうかを判断する処理のフローチャートを図11に示す。
【0080】
ステップS1100では、図10に示す領域1003に格納されている値が「0」未満であるか否かをチェックする。「0」未満の場合は処理をステップS1104に進め、ユーザの要求から判断に基づいて「部分的なパケット要求コマンド」、「通常のパケット要求コマンド」の何れかのコマンドを発行、送信する。一方ステップS1100で「0」以上である場合には処理をステップS1101に進め、領域1003に記録されたバイト数と、領域1004に記録されたバイト数とを比較し、同じであるか否かを判断する。同じである場合には、これ以上受信すべきパケットデータがないものと判断できるので(言い換えれば、必要なパケットデータは全てRAM205上に格納されているので)、コマンドを発行しないようにする。一方ステップS1101における判断処理において、同じでないと判断された場合には処理をステップS1103に進め、「部分的なパケット要求コマンド」をサーバ装置に対して送信する。
【0081】
以上の説明により、「通常のパケット要求」のためのコマンドと「部分的なパケット要求」のためのコマンドとをユーザからの要求に応じて切り替えることにより、各ユーザの要求に最適な画像表示を行うことができる。
【0082】
[第2の実施形態]
本実施形態では、端末装置において表示部203に表示された画像の拡大表示時に表示ウィンドウサイズより大きい画像をパンニングしながら表示する場合について説明する。この場合も第1の実施形態における拡大表示と同様に、ユーザは連続的に表示領域をパンニングし、希望する位置の画像を表示することになる。このときの動作の基本は、第1の実施形態と同じであるため、この説明は割愛する。
【0083】
そして、ユーザの操作の連続性を判断して、「部分的なパケット要求コマンド」において1度に転送するバイト数を動的に決定する方法を説明する。この処理のフローチャートを図12に示す。またこのフローチャートに従った処理はCPU201により行われるものとする。
【0084】
ステップS1201では、まず1つ目のユーザからの操作入力(操作入力1)を検知し、検知した操作に対するIIPのコマンドを決めると共に、そのときの時刻をCPU201内部の不図示のタイマにより求め、RAM205に保存する。次にステップS1202では、2つ目のユーザからの操作入力(操作入力2)を検知し、検知した操作に対するIIPのコマンドを決めると共に、そのときの時刻をCPU201内部の不図示のタイマにより求め、RAM205に保存する。そしてステップS1203では、ステップS1201,S1202で求めた夫々の時刻の差分を求め、求めた差分時間が所定の時間内を示すものであるか否かを求める。これは操作入力1と操作入力2とが連続してなされたものであるかを判断する処理である。なお、連続して操作が行われたか否かを判断するための処理は第1の実施形態で説明した方法を本実施形態に適用しても良いし、同図に示した処理方法を第1の実施形態に適用しても良い。
【0085】
そして所定の時間内に操作入力1と操作入力2とが連続してなされたものであると判断された場合には処理をステップS1204に進め、操作入力1と操作入力2とが同じ操作入力であるか否かを判断する。同じ操作入力である場合とは、例えばマウスのホイールを連続して回転させた場合であって、この場合には所定に時間内に同じ操作入力がなされる。よって同じ操作入力がなされた場合には処理をステップS1205に進め、ステップS1203で求めた差分時間に応じた、部分パケット要求コマンドを送信する際に要求するパケットのバイト数を決定する。これは例えば予め所定のバイト数を決めておき、差分時間が長ければ長いほど、そのバイト数を比例させて大きくするように決定しても良い。
【0086】
そしてステップS1206では、決定したバイト数と共に、要求する画像符号化データを指定するコマンドを部分パケット要求コマンドとしてサーバ装置に対して送信する。
【0087】
このような「部分的なパケット要求」は、画像のサムネイルを表示するときにも利用できる。例えば、1度に表示するサムネイル(すなわち画像)の枚数がいくら多くなろうとも、ある一定時間内で、全サムネイルを表示することを保証することが可能になる。これを実現する場合は、全サムネイル表示用に受信するバイト数を予め決めておき、このバイト数を枚数で割った値を各画像データを要求するコマンドの最大バイト数にすることで可能である。
【0088】
あるいは、サーバ装置に格納されているJPEG2000の画像符号化データに対して、画像符号化データが格納されている外部記憶装置内における位置と読み出すバイト数を部分パケット要求コマンドとして指定しても良い。
【0089】
また論理的な単位は、JPEG2000のパケットで説明したが、その他の単位、例えばタイル、プリシンクトあるいは、code−blockなどでも良いことは容易に推察できる。
【0090】
[第3の実施形態]
上記実施形態における端末装置からサーバ装置に対して要求する画像の解像度は例えばマウスのホイールを用いて表示部において拡大縮小などを行う場合に、マウスのホイールにより入力される指示に基づいたものであるが、他にも例えば、端末装置の外部記憶装置にプリンタ208のドライバをインストールしておき、ウェブブウザ上で表示される画像をプリンタ208を用いてプリントする場合、プリンタ208がプリント可能な解像度をプリンタドライバから取得し、取得した解像度の画像符号化データをサーバ装置に対して要求しても良い。
【0091】
またプリント可能な解像度が複数種存在する場合には、表示部にその一覧を表示し、ユーザにより選択しても良い。
【0092】
[第4の実施形態]
サーバ装置が保持する画像符号化データのうち端末装置から指示された画像符号化データにおいて、端末装置からの指示に応じた所望の解像度の画像を形成するために必要となるパケット群(部分画像符号化データ)を受信する場合、本実施形態では、指示された画像符号化データにおいて既に受信した部分画像符号化データのサイズ、受信対象外の部分画像符号化データのサイズ、そして今回受信する部分画像符号化データのサイズとを用いた比較結果に応じて、その受信形態を異ならせるよう制御するものである。以下、本実施形態における端末装置、サーバ装置が行う処理について説明する。
【0093】
なお本実施形態におけるサーバ装置、端末装置により構成されるシステムの形態、及びそれらの装置の構成については第1の実施形態と同じであるのでその説明を省略する。また本実施形態においてもサーバ装置が保持する画像符号化データはJPEG2000に従ってエンコードされたものであるので、その構成については第1の実施形態で説明したような、図3、4、6に示した内容に従ったものである。また本実施形態におけるサーバ装置と端末装置とのパケット単位でのリクエスト及びレスポンスについても第1の実施形態と同様に図5に示すとおりである。
【0094】
また本実施形態の端末装置102a(端末装置102bも同様)におけるウェブブウザは、第3の実施形態に様に、サーバ装置101(サーバ装置103でも良い)に対して要求したJPEG2000ファイルのデコード結果を表示部203だけでなく、プリンタ208にも出力する処理を行う。同処理はウェブブウザのプログラムをCPU201が実行することで行われるものである。よって本実施形態におけるCPU201が行うメインの処理のフローチャートは図7に示したものに加えて、デコード結果をプリンタ208に出力する指示をユーザが入力した場合には、第3の実施形態で説明したように、プリンタドライバからプリント可能な解像度を取得し、この解像度に従った画像符号化データの受信要求をサーバ装置に対して送信する。そして受信した画像符号化データをデコードし、デコード結果をプリンタ208に出力する。また本実施形態ではステップS4において部分画像符号化データを受信するので、ステップS5における処理は省く。
【0095】
上述の通り、本実施形態では受信形態を、端末装置から指示した画像符号化データのサイズと今回受信するデータのサイズとの比較結果に応じて異ならせるよう、制御を行う。よってこの比較結果に応じて当然発行するコマンドも異なる。以下ではこの比較結果に応じたコマンドの発行処理について、同処理のフローチャートを示す図13を用いて説明する。なお本実施形態では、端末装置が所望の解像度の画像を得るために、予め指示した画像符号化データにおいて、「Layer0/Reso0/Comp0/Pos0」のパケットと、「Layer0/Reso1/Comp0/Pos0」のパケットとによる部分画像符号化データをサーバ装置に対して要求する場合について説明する。
【0096】
まずステップS1310で、サーバ装置101に対して行う要求が最初(1回目)のものであるかあるか否かを判断する。1回目であれば処理をステップS1311に進める。そしてステップS1311では上記指示した画像符号化データのサイズを送信するよう、サーバ装置101に対して要求を送信する。例えば図6に示した画像符号化データの場合、取得するサイズは「Layer0/Reso0/Comp0/Pos0」から「Layer1/Reso5/Comp0/Pos0」までの各パケットのサイズの総和で、その総和は65536バイトとなる。
【0097】
この総和サイズを取得する、もしくはステップS1310においてサーバ装置101に対して要求するのが最初ではないと判断された場合には、次にステップS1312においてRAM205に既にキャッシュされている部分画像符号化データのサイズの総和を求める。
【0098】
次にステップS1313では、今回端末装置102aがサーバ装置101に対して要求する部分画像符号化データ(「Layer0/Reso0/Comp0/Pos0」のパケットと「Layer0/Reso1/Comp0/Pos0」のパケット)のサイズの総和を送信するよう、サーバ装置101に対して要求を送信する。本実施形態ではいずれのパケットのサイズも32バイトであるので、その総和は64バイトとなる。そしてこの総和をサーバ装置101から受信すると、次にステップS1314において、発行するコマンドを決定する。その決定方法について説明する。
【0099】
この決定方法としては本実施形態では、「既に受信した部分画像符号化データのサイズの総和+受信していない部分画像符号化データのサイズ」と「今回要求する部分画像符号化データのサイズの総和」との比較を行い、前者≧後者(等号はなくても良い)の場合には、サーバ装置からパケット単位で部分画像符号化データを受信するためにサーバ装置に対して送信するコマンドを発行する。一方、前者<後者(等号がついていても良い)の場合には、サーバ装置から1回で要求する全てのパケット(すなわち要求する部分画像符号化データ)を受信するためにサーバ装置に対して送信するコマンドを発行する(ステップS1316における処理)。
【0100】
例えば今回が初めてのサーバ装置に対しての部分画像符号化データの要求である場合、今回要求する部分画像符号化データのサイズの総和は64バイト、既に受信した部分画像符号化データのサイズの総和は0バイト、そして受信していない部分画像符号化データのサイズの総和は(指示した画像符号化データ全体のサイズ)−(既に受信した部分画像符号化データのサイズ+今回要求する部分画像符号化データのサイズ)であるので65536−(64+0)=65472となる。よって65472>64となるので、ステップS1315ではパケット単位で部分画像符号化データを受信するためにサーバ装置に対して送信するコマンドを発行する。
【0101】
そしてステップS1315,S1316のいずれの場合においても、夫々の受信形態に従って要求した部分画像符号化データを受信する。
【0102】
以上の処理により、所望の解像度の画像を得るための画像符号化データ(部分画像符号化データ)を受信することが出来るので、以降は第1の実施形態と同様の処理を行うことで、所望の画質の画像を表示部203に表示させることが出来る。
【0103】
次に、第1の実施形態と同様の操作により、表示部203に表示された画像に対する拡大指示が入力された場合について説明する。なお拡大された画像を形成するためには上記JPEG2000ファイルにおいて、「Reso2」までのレベルの部分画像符号化データが必要であるとする。すなわち、「Layer0/Reso1/Comp0/Pos0」、「Layer1/Reso1/Comp0/Pos0」、「Layer0/Reso2/Comp0/Pos0」、「Layer1/Reso2/Comp0/Pos0」の各パケットが必要となる。
【0104】
この場合も同様に図7に示すフローチャートに従った処理が行われるので、当然、図13に示すフローチャートに従った処理も行われる。この場合、ステップS1310では端末装置102aからサーバ装置101に対して部分画像符号化データの要求は1回目ではないので、処理は直接ステップS1312に進む。
【0105】
そしてステップS1312では上述の通り受信済みの部分画像符号化データの総和のサイズを取得するが、これは1回目に取得した部分画像符号化データの総和のサイズであるので、96バイトとなる。次に、ステップS1313では要求するパケットの総和のサイズを取得するが、上記4パケットのサイズは夫々96バイト,96バイト,384バイト,384バイトであるので、その総和は960バイトとなる。次に、ステップS1314では上記の説明の通りの計算を行う。すると、
(64+64512)>960となり、「既に受信した部分画像符号化データのサイズの総和+受信していない部分画像符号化データのサイズ」>「今回要求する部分画像符号化データのサイズの総和」となるので、端末装置は、パケット単位で部分画像符号化データを受信するためにサーバ装置に対して送信するコマンドを発行する。
【0106】
以上の処理により、第1の実施形態と同様の操作により、表示部203に表示された画像に対する拡大指示が入力された場合であっても、その拡大画像を形成するための画像符号化データをサーバ装置から受信することができるので、受信した画像符号化データをデコードすることで得られる画像を表示部203に表示させることができる。
【0107】
この状態で更にユーザから表示部203に表示されている画像を所定のサイズ、例として4096画素×4096画素の画像としてプリンタ208を用いてプリントする指示が入力された場合について説明する。4096画素×4096画素のサイズの画像を形成するために必要となる部分画像符号化データは「Layer0/Reso3/Comp0/Pos0」、「Layer1/Reso3/Comp0/Pos0」、「Layer0/Reso4/Comp0/Pos0」、「Layer1/Reso4/Comp0/Pos0」、「Layer0/Reso5/Comp0/Pos0」、「Layer1/Reso5/Comp0/Pos0」の各パケットが必要となる。
【0108】
この場合も同様に図7に示すフローチャートに従った処理が行われるので、当然、図13に示すフローチャートに従った処理も行われる。この場合、ステップS1310では端末装置102aからサーバ装置101に対して部分画像符号化データの要求は1回目ではないので、処理は直接ステップS1312に進む。
【0109】
そしてステップS1312では上述の通り受信済みの部分画像符号化データの総和のサイズを取得するが、これは1回目、そして2回目に取得した部分画像符号化データの総和のサイズであるので、1056バイトとなる。次に、ステップS1313では要求するパケットの総和のサイズを取得する。その総和は64512バイトとなる。次に、ステップS1314では上記の説明の通りの計算を行う。すると、
(1056+0)<64512となり、「既に受信した部分画像符号化データのサイズの総和+受信していない部分画像符号化データのサイズ」<「今回要求する部分画像符号化データのサイズの総和」となるので、端末装置は、サーバ装置に管理されている符号化データ全部、言い換えるとファイル全体を送信するコマンドを発行する。
【0110】
以上の処理により、所定のサイズの画像をプリンタ208に出力したい場合であっても、所定のサイズの画像を形成するための画像符号化データをサーバ装置から受信することができるので、受信した画像符号化データをデコードし、プリンタドライバを介してプリンタ208に出力することで、所定サイズの画像をプリントすることができる。
【0111】
次に、本実施形態におけるステップS6の処理、すなわち、RAM205にキャッシュした部分画像符号化データからJPEG2000準拠のビットストリーム(画像符号化データ)を作成する処理について、同処理のフローチャートである図14を用いて以下説明する。
【0112】
まずステップS1400では、以上説明した処理により発行されたコマンドが、部分画像符号化データをパケット単位で受信要求するものであるのか否かを判断する。この判断の結果、パケット単位で部分画像符号化データを要求するコマンドである場合には処理をステップS1402に進め、RAM205にキャッシュしている各部分画像符号化データから1つのJPEG2000準拠のビットストリームを作成する。ステップS1402における処理の詳細については後述する。
【0113】
一方、ステップS1400における判断の結果、パケット単位で部分画像符号化データを要求するコマンドではない場合には処理をステップS1401に進め、この時点でRAM205にキャッシュされている全ての部分画像符号化データを削除すると共に、新たにユーザから指示が入力されてもこの指示に従った処理を行わないようにする。例えば、ステップS1400からステップS1402への処理の分岐を行わないようにする。
【0114】
次に、ステップS1402における処理の詳細について、同処理の詳細を示すフローチャートである図15を用いて説明する。まずRAM205にキャッシュしている各部分画像符号化データを参照して、ステップS900ではタイル数を、そしてステップS901ではパケット数をチェックし、夫々変数iTMax,iPMaxに代入する。次に、ステップS902でJPEG2000のMainヘッダを出力する。次にステップS903では、後述の処理で用いる変数iTを0に初期化する。次にステップS904では、Tileヘッダ(SOTマーカコード)を生成し、仮出力する。次にステップS905では後述の処理で用いる変数iPを、ステップS906では後述の処理に用いる変数iLを夫々0に初期化する。
【0115】
上記変数iPは各パケットを特定するためのインデックスとして用いる変数である。よって次にステップS907ではこの変数iPで表されるパケットがRAM205にキャッシュされているかをチェックする。このチェックの結果、変数iPで表されるパケットデータがRAM205にキャッシュ済み、すなわちサーバ装置から送信済みである場合には処理をステップS908に進め、変数iPに対応するパケットデータを出力し、ステップS909ではステップS908で出力したパケットデータのサイズを変数iLが保持する値に加算し、その結果を再度変数iLに記憶保持させる。
【0116】
一方、ステップS907におけるチェックの結果、変数iPで表されるパケットデータがRAM205にキャッシュ済みでない、すなわちサーバ装置から送信済みでない場合には処理をステップS910に進め、ZLP(Zero Length Packet)データを出力し、ステップS911では変数iLが保持する値に1を加算し、その結果を再度変数iLに記憶保持させる。そしてステップS912では変数iPが保持する値に1を加算し、その結果を再度変数iPに記憶保持させる。
【0117】
次にステップS913では上記変数iPと変数iPMaxとを比較する。本ステップにおける処理は1つのタイルに含まれる全てのパケットデータに対して処理を行ったか否かをチェックする処理である。
【0118】
そして変数iP<変数iPMaxの場合、すなわち1つのタイルに含まれる全てのパケットデータに対する処理が終了していない場合には処理をステップS906に戻し、以上の処理を行う。一方、変数iP≧変数iPMaxの場合、即ち1つのタイルに含まれる全てのパケットデータに対する処理が終了した場合には処理をステップS914に進め、タイル全体のデータ数を管理しているフィールドの値を変数iLから更新し、ステップS904で出力したSOTマーカコード内のタイルに含まれるパケットデータの数を出力する。
【0119】
次にステップS915では変数iTが保持する値に1を加算し、その結果を再度変数iTに記憶保持させる。変数iTは各タイルの数をカウントするための変数である。よってステップS916では、全てのタイルを処理したか否かをチェックする。全てのタイルを処理していなければ処理をステップS904に戻し、上記処理を行う。
【0120】
一方、全てのタイルを処理している場合には処理をステップS917に進め、JPEG2000準拠の符号化データを完成させるための公知の処理を行う。
例えばEOCマーカコードなどを出力する。
【0121】
以上の説明により、本実施形態によって、要求する部分画像符号化データのサイズが上記比較処理により比較的大きい場合には高速に受信することができ、円滑に部分画像符号化データを受信することが出来る。
【0122】
[第5の実施形態]
本実施形態では、ネットワークの使用状況に応じて、上記2つのコマンドのいずれを使用するのかを決定する。よって本実施形態における端末装置上で実行されるウェブブウザが行う、サーバ装置に対してJPEG2000ファイルの送信を要求し、要求したJPEG2000ファイルをデコードして表示部203に表示する処理は、ステップS4におけるコマンド発行処理のみが第4の実施形態とは異なる。
【0123】
図16は本実施形態におけるコマンド発行処理のフローチャートである。図13と同じステップには同じステップ番号を付けており、その説明を省略する。
【0124】
まずステップS1600において、ネットワークの利用状況を検知する。これは例えば公知の”ping”コマンドを例えば以下のようにして用いる。
【0125】
ping ホスト名(サーバ名)
これはこのコマンドを発行した装置からホスト名(サーバ名)で指定した装置までのネットワークを利用したタイムレスポンスを調べることができる。よって本実施形態では端末装置において、上記ホスト名にサーバ装置を指定した上記pingコマンドを用いることで、端末装置とサーバ装置との間のネットワークを利用したタイムレスポンスを調べることができる。このタイムレスポンスが一定時間以上を要するものであればこのネットワークは非常に混んでいる(多くの装置によって使用されている)と判断することができ、タイムレスポンスが一定時間以上要さないものであればこのネットワークはそれほど混んでいない(あまり多くの装置は使用していない)と判断することができる。よって、端末装置とサーバ装置との間のネットワークの使用状況が分かる。
【0126】
次にステップS1601において、上記調査によりネットワークが混んでいないと判断する場合、処理をステップS1316に進め、上記ステップS1316と同じ処理、ファイル全体の転送要求コマンドを発行する。
【0127】
一方、ステップS1601において、ネットワークが混んでいると判断された場合には、処理をステップS1315に進め、上記ステップS1315と同じ処理、パケット単位で部分画像符号化データを受信するためにサーバ装置に対して送信するコマンドを発行する。
【0128】
以上の処理により、ネットワークの使用状況、言い換えると混み具合に応じて部分画像符号化データの受信形態を異ならせることができる。これはすなわち、ネットワークがそれほど混んでいない場合にはファイル全体をサーバから受信し、逆にネットワークが混んでいる場合にはより短い時間で部分画像符号化データを受信できるようにパケット単位のコマンドを発行する。これによりより円滑に部分画像符号化データを受信することができる。
【0129】
[第6の実施形態]
第4の実施形態では端末装置は、これからサーバ装置に対して要求しようとする部分画像符号化データのサイズは、サーバ装置から送信してもらうことで知ることができた。本実施形態では、これからサーバ装置に対して要求しようとする部分画像符号化データのサイズを端末装置において推定する。
【0130】
図17はJPEG2000に従って符号化された画像符号化データにおける各解像度の符号化データを示す図である。一般に矩形1700、矩形1701a、1701b、1701c、矩形1702a、1702b、1702c、矩形1703a、1703b、1703cの4種類の矩形のそれぞれにはそれぞれ異なる解像度の画像の周波数成分を示すDWT係数が含まれている。
【0131】
例えば矩形1700内に含まれるDWT係数のみを用いて復号すると、最も低い解像度(解像度レベル0)の画像が復元される。更にこれに加えて矩形1701a、1701b、1701c内に含まれるDWT係数を復号することで、より高い解像度(解像度レベル1)の画像が復元される。更にこれに加えて矩形1702a、1702b、1702c内に含まれるDWT係数を復号することで、より高い解像度(解像度レベル2)の画像が復元される。更にこれに加えて矩形1703a、1703b、1703c内に含まれるDWT係数を復号することで、より高い解像度(解像度レベル3)の画像が復元される。
【0132】
ここで、一般にJPEG2000においてロスレスモードで画像を符号化した場合、矩形の面積比はそのまま矩形に含まれるDWT係数のデータ量の比に正比例している。例えば矩形1700、矩形1701a、矩形1701b、矩形1701cのそれぞれはすべて同じ面積であるので、矩形1700と矩形1701a、1701b、1701cとの面積比は1:3であって、矩形1700に含まれるDWT係数のデータ量と、矩形1701a、1701b、1701cに含まれるDWT係数のデータ量との比はほぼ1:3となる。
【0133】
また矩形1700と矩形1702a(1702b、1702c)との面積比は1:4となる。また矩形1700と矩形1703a(1703b、1703c)との面積比は1:8となる。
【0134】
JPEG2000に従った画像符号化データのパケットはDWT係数により構成されているので、各矩形に対応するパケットのサイズもまた、各矩形の面積比に正比例している。
【0135】
これを利用して、ロスレスモードで符号化された部分画像符号化データを要求する場合には、すでに受信している部分画像符号化データのデータ量から、これから要求する部分画像符号化データのデータ量や、ファイル全体のバイト数を推測することができる。例えばすでに解像度レベル0の部分画像符号化データを受信しているとする。すなわち図17において、矩形1770に対応する部分画像符号化データを受信しているとする。
【0136】
この部分画像符号化データのデータサイズを64バイトとすると、上記説明により、矩形1701a、1701b、1701cに対応する部分画像符号化データのサイズは64×3=192バイトとなる。また、矩形1702a、1702b、1702cに対応する画像符号化データのサイズは64×4×3=768バイトとなる。また、矩形1703a、1703b、1703cに対応する画像符号化データのサイズは64×4×4×3=3072バイトとなる。このようにして、各面積比は予め把握しておくことができるので、すでに受信している部分画像符号化データのデータサイズから、これから受信しようとするデータのサイズを推測することができる。
【0137】
以下ではウェブブラウザに表示されている複数の画像から1つを指示した場合に、指示した画像において端末装置から要求する部分画像符号化データのサイズ、及び指示した画像の画像符号化データのサイズの推測結果に応じて端末装置がコマンドを発行する処理について、同処理のフローチャートを示す図18を用いて説明する。同図のフローチャートに従った処理は上記ステップS4における処理のサブルーチンの処理を示すものである。なお図18に示す処理は、上記第4の実施形態におけるコマンド発行処理において、指示した画像において端末装置から要求するパケット群(所望の解像度の画像を得るために必要な部分画像符号化データを構成するパケット群)のサイズ、指示した画像の画像符号化データのサイズをサーバ装置から受信せずに、端末装置側で推測する以外は同じである。よって同図において図13と同じステップについては同じステップ番号を付けている。
【0138】
まず画像を1つ指示した時点で、指示した画像の解像度レベル0の部分画像符号化データはRAM205にすでにキャッシュされているので、ステップS1800ではこの部分画像符号化データのサイズから、指示した画像に対応する画像符号化データ全体のサイズを推定する。推定する方法については上述の通りである。
【0139】
次に、キャッシュされている解像度レベル0の部分画像符号化データのサイズを用いて、これから要求しようとする部分画像符号化データのサイズを推定する。そして推定した画像符号化データのサイズ、これから要求しようとする部分画像符号化データのサイズを用いると、受信していない部分画像符号化データのサイズを求めることができるので、これら3つのサイズに従ってステップS1314以降の処理を行う。ステップS1314以降の処理については上述の通りであるので、ここでの説明は省略する。
【0140】
なお、上述の、これから要求する部分画像符号化データのサイズをサーバ装置に要求することなく、端末装置側で推定する処理は上述の実施形態に適用しても良い。
【0141】
[第7の実施形態]
上記実施形態では、部分画像符号化データを要求する場合に、パケット単位で要求するコマンドと、部分画像符号化データ全体を一度に要求するためのコマンドを様々な状態に応じて使い分けてきた。
【0142】
本実施形態では、タイルに分割された画像の符号化データがタイル毎にサーバ装置に保持されている場合に、タイル単位で、パケット要求コマンドと、タイル全体の符号化データを要求するコマンドとを使い分ける。
【0143】
図19に、本実施形態におけるコマンド発行処理のフローチャートを示す。なお同図のフローチャートに従った処理は、上記ステップS4における処理のサブルーチンである。なお、図13,図18と同じステップについては同じステップ番号を付けており、その説明を省略する。
【0144】
まずステップS1900では、変数iTMaxにタイルの総数を代入すると共に、角田イルに対して付けられたインデックスを表す変数iTを0に初期化する。次にステップS1901では、変数iTをインデックスとするタイルが、ユーザから要求されたものであるか否かを判断する。要求されたタイルである場合には処理をステップS1904に進め、上記ステップS1800と同じ処理行う。ただしサイズを求める対象は受信済みのパケットのデータサイズではなく、受信済みの1つのタイルのデータサイズである。
【0145】
次に、ステップS1801と同じ処理を行う。すなわち、今回要求するパケットのサイズを求める。そしてステップS1314以降の処理、すなわち、第4の実施形態で説明したようなコマンド決定処理を行う、ただし、決定するコマンドは、部分画像符号化データを1回の送信で要求するコマンドを、1つのタイルを1回の要求で受信するためのコマンドと読み替える必要がある。また、パケット単位で要求するコマンドは、1つのタイルをパケット単位で受信するためのコマンドと読み替える必要がある。
【0146】
次に、本実施形態におけるステップS6の処理、すなわち、RAM205にキャッシュした符号化データからJPEG2000準拠のビットストリーム(画像符号化データ)を作成する処理について、同処理のフローチャートである図20を用いて以下説明する。尚、図14,図19と同じステップについては同じステップ番号を付けており、その説明を省略する。
【0147】
ステップS1400では、以上説明した処理により発行されたコマンドが、タイルをパケット単位で受信要求するものであるのか否かを判断する。この判断の結果、パケット単位で要求するコマンドである場合には処理をステップS2001に進め、RAM205にキャッシュしているタイルの符号化データから1つのJPEG2000準拠のビットストリームを作成する。ステップS2001における処理の詳細については後述する。
【0148】
一方、ステップS1400における判断の結果、パケット単位でタイルを要求するコマンドではない場合には処理をステップS1401に進め、この時点でRAM205にキャッシュされている全てのデータを削除すると共に、新たにユーザから指示が入力されてもこの指示に従った処理を行わないようにする。例えば、ステップS1400からステップS1402への処理の分岐を行わないようにする。そして次に、ステップS2002において、発行したコマンドに基づいてサーバ装置から受信したタイルのデータをそのまま作成すべきビットストリームとする。
【0149】
ステップS2001における処理のフローチャートは図21に示すとおりである。同図のフローチャートは、図15において、ステップS904からステップS914までの処理を示すものであって、その説明は上述の通りであるのでここでの説明を省略する。
【0150】
[他の実施形態]
本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体(または記録媒体)を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0151】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0152】
また上記記憶媒体には、インターネットやLANなどのネットワークに使用される通信ケーブルなどの通信媒体が含まれる。すなわち、前述した実施形態のプログラムコードがネットワーク上のサーバ装置に保持されている場合には、このサーバ装置から上記ネットワークを介してコンピュータにダウンロードすることで、コンピュータにプログラムを導入することができる。よって、導入されたプログラムはコンピュータ上のCPUやMPUなどの制御回路により実行され、その結果、コンピュータは前述した実施形態に機能が実現されるわけであるから、前述した記憶媒体に上記ネットワークに使用される通信ケーブルなどの通信媒体が含まれることはいうまでもない。
【0153】
本発明の実施様態の例を以下に列挙する。
【0154】
[実施態様1] スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された当該画像符号化データを受信する画像処理装置であって、
ユーザからの各種の入力を受け付ける入力手段と、
当該入力手段から入力された入力の種別応じて、当該入力手段により指示された画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを1回の受信処理で受信するために前記サーバ装置に対して送信する第1のコマンド、もしくは前記画像符号化データにおける前記部分画像符号化データを特定する情報を当該第1のコマンドよりも詳細に記述し、且つ前記部分画像符号化データを前記サーバ装置から所定の単位毎に受信するために前記サーバ装置に対して送信する第2のコマンドの何れかを生成し、前記サーバ装置に対して送信する送信手段と、
前記サーバ装置から送信される、当該送信手段により送信されたコマンドに応じた画像符号化データを受信してデコードし、デコード結果を所定の出力装置に出力する出力手段と
を備えることを特徴とする画像処理装置。
【0155】
[実施態様2] 前記入力手段は、ユーザからの連続した操作入力を受け付け可能であって、
前記送信手段は、前記入力手段から入力された夫々の操作入力が同じであって、且つ当該夫々の操作入力が所定の時間内になされたものである場合には、前記第2のコマンドを、それ以外の場合には前記第1のコマンドを生成して前記サーバ装置に対して送信することを特徴とする実施態様1に記載の画像処理装置。
【0156】
[実施態様3] 前記第2のコマンドには、前記指示された画像符号化データにおける前記部分画像符号化データの位置情報、且つ前記サーバ装置から一度に受信するデータのサイズが含まれていることを特徴とする実施態様1又は2に記載の画像処理装置。
【0157】
[実施態様4] 前記送信手段が前記第2のコマンドを前記サーバ装置に対して送信した場合、
前記出力手段は更に、受信すべき部分画像符号化データのうち、受信したデータのサイズと、まだ受信していないデータのサイズを示す情報とを受信することを特徴とする実施態様1に記載の画像処理装置。
【0158】
[実施態様5] 前記出力手段が前記情報を受信した場合、前記送信手段は前記部分画像符号化データのうちまだ受信していないデータを所定の単位毎に前記サーバ装置から受信するためのコマンドを前記第2のコマンドとして前記サーバ装置に対して送信することを特徴とする実施態様4に記載の画像処理装置。
【0159】
[実施態様6] スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された当該画像符号化データを受信する画像処理装置であって、
前記指示された画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを指示する指示手段と、
前記サーバ装置から受信した部分画像符号化データを記憶保持する記憶保持手段と、
前記画像符号化データにおいて前記記憶保持手段に記憶保持されているデータのサイズ、及び前記指示手段により指示した部分画像符号化データのサイズ、及び前記画像符号化データにおいて前記記憶保持手段への記憶保持対象外のデータのサイズを用いて、前記指示手段により指示された部分画像符号化データを1回の受信処理で受信するために前記サーバ装置に対して送信する第1のコマンド、もしくは前記指示手段により指示された部分画像符号化データを所定の単位毎に受信するために前記サーバ装置に対して送信する第2のコマンドの何れかを前記サーバ装置に対して送信する送信手段と、
前記サーバ装置から送信される、当該送信手段により送信されたコマンドに応じた画像符号化データを受信してデコードし、デコード結果を所定の出力装置に出力する出力手段と
を備えることを特徴とする画像処理装置。
【0160】
[実施態様7] 前記送信手段は、前記画像符号化データにおいて前記記憶保持手段に記憶保持されているデータのサイズと、前記画像符号化データにおいて前記記憶保持手段への記憶保持対象外のデータのサイズの総和である第1のサイズと、前記指示手段により指示した部分画像符号化データのサイズである第2のサイズとを比較し、前記第1のサイズが少なくとも前記第2のサイズ以上である場合には前記第2のコマンドを、前記第1のサイズが大きくとも前記第2のサイズ以下である場合には前記第1のコマンドを前記サーバ装置に対して送信することを特徴とする実施態様6に記載の画像処理装置。
【0161】
[実施態様8] 前記画像符号化データのサイズ、及び前記指示手段により指示した部分画像符号化データのサイズを推定する推定手段を備え、前記画像符号化データにおいて前記記憶保持手段への記憶保持対象外のデータのサイズは推定手段により求めたそれぞれのサイズを用いて求めることを特徴とする実施態様6に記載の画像処理装置。
【0162】
[実施態様9] スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された当該画像符号化データを受信する画像処理方法であって、
ユーザからの各種の入力を受け付ける入力工程と、
当該入力工程で入力された入力の種別に応じて、当該入力工程で指示された画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを1回の受信処理で受信するために前記サーバ装置に対して送信する第1のコマンド、もしくは前記画像符号化データにおける前記部分画像符号化データを特定する情報を当該第1のコマンドよりも詳細に記述し、且つ前記部分画像符号化データを前記サーバ装置から所定の単位毎に受信するために前記サーバ装置に対して送信する第2のコマンドの何れかを生成し、前記サーバ装置に対して送信する送信工程と、
前記サーバ装置から送信される、当該送信工程で送信されたコマンドに応じた画像符号化データを受信してデコードし、デコード結果を所定の出力装置に出力する出力工程と
を備えることを特徴とする画像処理方法。
【0163】
[実施態様10] コンピュータを実施態様1乃至8の何れか1項に記載の画像処理装置として機能させることを特徴とするプログラム。
【0164】
[実施態様11] コンピュータに実施態様9に記載の画像処理方法を実行させることを特徴とするプログラム。
【0165】
[実施態様12] 実施態様10又は11に記載のプログラムを格納することを特徴とするコンピュータ読み取り可能な記憶媒体。
【0166】
【発明の効果】
以上の説明により、本発明によって、複数の解像度の画像を有する符号化データの受信形態を、目的に応じて切り替える技術を提供することができ、これにより、より快適に画像符号化データの受信を行うことができる。
【図面の簡単な説明】
【図1】インターネットやLANに代表されるネットワーク上に複数のコンピュータが接続されている本発明の第1の実施形態におけるシステムの概略構成を示す図である。
【図2】サーバ装置101,103、端末装置102a,102bの基本構成を示すブロック図である。
【図3】Layer−resolution level−component−position progressionに従って生成されたJPEG2000ファイルの概略構成を示す図である。
【図4】解像度(画像サイズ)とResolution番号との関係を示す図である。
【図5】パケット単位でのリクエスト及びレスポンスの概念図である。
【図6】本発明の第1の実施形態におけるサーバ装置101(もしくは103)に接続されたハードディスクに保持されているJPEG2000ファイルの構成の一例を示す図である。
【図7】端末装置102a(端末装置102bも同様)におけるウェブブウザが行う、サーバ装置101(サーバ装置103でも良い)に対してJPEG2000ファイルの送信を要求し、要求したJPEG2000ファイルをデコードして表示部203に表示する処理のフローチャートである。
【図8】ステップS3における処理の詳細を示すフローチャートである。
【図9】サーバ装置と端末装置との間でのコマンド送信、レスポンス返信のシーケンスを示す図である。
【図10】キャッシュ管理をするためのテーブルのデータ構造を示す図である。
【図11】CPU201がユーザからの要求から必要なパケットを計算した時に、キャッシュ上にデータがあるか否かを判断し、コマンドを発行するかどうかを判断する処理のフローチャートである。
【図12】ユーザの操作の連続性を判断して、「部分的なパケット要求コマンド」において1度に転送するバイト数を動的に決定する処理のフローチャートである。
【図13】端末装置から指示した画像符号化データのサイズと今回受信するデータのサイズとの比較結果に応じて発行するコマンドの発行処理のフローチャートである。
【図14】本発明の第4の実施形態におけるステップS6の処理のフローチャートである。
【図15】ステップS1402における処理の詳細を示すフローチャートである。
【図16】本発明の第5の実施形態におけるコマンド発行処理のフローチャートである。
【図17】JPEG2000に従って符号化された画像符号化データにおける各解像度の符号化データを示す図である。
【図18】ウェブブラウザに表示されている複数の画像から1つを指示した場合に、指示した画像において端末装置から要求する部分画像符号化データのサイズ、及び指示した画像の画像符号化データのサイズの推測結果に応じて端末装置がコマンドを発行する処理のフローチャートである。
【図19】本発明の第7の実施形態におけるコマンド発行処理のフローチャートである。
【図20】本発明の第7の実施形態におけるステップS6の処理のフローチャートである。
【図21】ステップS2001における処理のフローチャートである。
Claims (1)
- スケーラビリティを有する画像符号化データを保持するサーバ装置から、指示された当該画像符号化データを受信する画像処理方法であって、
ユーザからの各種の入力を受け付ける入力工程と、
当該入力工程で入力された入力の種別に応じて、当該入力工程で指示された画像符号化データのうち、デコードすることで所望のレベルの画像を形成するために必要な部分画像符号化データを1回の受信処理で受信するために前記サーバ装置に対して送信する第1のコマンド、もしくは前記画像符号化データにおける前記部分画像符号化データを特定する情報を当該第1のコマンドよりも詳細に記述し、且つ前記部分画像符号化データを前記サーバ装置から所定の単位毎に受信するために前記サーバ装置に対して送信する第2のコマンドの何れかを生成し、前記サーバ装置に対して送信する送信工程と、
前記サーバ装置から送信される、当該送信工程で送信されたコマンドに応じた画像符号化データを受信してデコードし、デコード結果を所定の出力装置に出力する出力工程と
を備えることを特徴とする画像処理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002356736A JP3958198B2 (ja) | 2002-12-09 | 2002-12-09 | 画像処理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002356736A JP3958198B2 (ja) | 2002-12-09 | 2002-12-09 | 画像処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004193752A true JP2004193752A (ja) | 2004-07-08 |
JP3958198B2 JP3958198B2 (ja) | 2007-08-15 |
Family
ID=32756986
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002356736A Expired - Fee Related JP3958198B2 (ja) | 2002-12-09 | 2002-12-09 | 画像処理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3958198B2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006295386A (ja) * | 2005-04-07 | 2006-10-26 | Ricoh Co Ltd | 画像送信方法、画像送信プログラム、記録媒体及び画像送信装置 |
JP2013541917A (ja) * | 2010-10-22 | 2013-11-14 | クゥアルコム・インコーポレイテッド | ビデオコーディングのための変換係数の適応走査 |
CN113475091A (zh) * | 2019-02-22 | 2021-10-01 | 三星电子株式会社 | 显示设备及其图像显示方法 |
-
2002
- 2002-12-09 JP JP2002356736A patent/JP3958198B2/ja not_active Expired - Fee Related
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006295386A (ja) * | 2005-04-07 | 2006-10-26 | Ricoh Co Ltd | 画像送信方法、画像送信プログラム、記録媒体及び画像送信装置 |
JP2013541917A (ja) * | 2010-10-22 | 2013-11-14 | クゥアルコム・インコーポレイテッド | ビデオコーディングのための変換係数の適応走査 |
US9641846B2 (en) | 2010-10-22 | 2017-05-02 | Qualcomm Incorporated | Adaptive scanning of transform coefficients for video coding |
CN113475091A (zh) * | 2019-02-22 | 2021-10-01 | 三星电子株式会社 | 显示设备及其图像显示方法 |
CN113475091B (zh) * | 2019-02-22 | 2023-08-25 | 三星电子株式会社 | 显示设备及其图像显示方法 |
Also Published As
Publication number | Publication date |
---|---|
JP3958198B2 (ja) | 2007-08-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4377103B2 (ja) | サーバクライアント環境におけるjpeg2000のための画像処理 | |
US7580577B2 (en) | Methods, apparatus and computer products for generating JPEG2000 encoded data in a client | |
EP3333715B1 (en) | Cache system and method for generating uncached objects from cached and stored object components | |
US7284069B2 (en) | Method for document viewing | |
JP4603947B2 (ja) | 画像通信システム、サーバ装置およびその制御方法、並びにコンピュータプログラム | |
JP4934462B2 (ja) | 部分的な書類画像にアクセスするための方法、サーバー及びコンピュータプログラム | |
US20030067627A1 (en) | Image processing method and its data cache method | |
AU2001283542A1 (en) | Cache system and method for generating uncached objects from cached and stored object components | |
JP2004274760A (ja) | 圧縮されたディジタル画像を通信する方法及び製造物 | |
US7558430B2 (en) | Apparatus method and computer-readable medium for processing hierarchical encoded image data | |
JP2004274758A (ja) | Jpp−ストリームからjpeg2000符号ストリームへの変換方法及び変換装置 | |
JP4789192B2 (ja) | 符号処理装置、プログラム及び情報記録媒体 | |
JP3958198B2 (ja) | 画像処理方法 | |
JP3897691B2 (ja) | スクロール表示方法及び装置 | |
JP4065535B2 (ja) | 符号データ作成方法及び装置 | |
JP3768866B2 (ja) | 符号化データの作成方法及びその装置 | |
JP2002503900A (ja) | 高効率のクライアントサーバ、タイル化およびキャッシングアーキテクチャを使用するネットワーク画像ビューサーバ | |
JP3768934B2 (ja) | 画像処理装置及びそのデータキャッシュ方法 | |
JP2004145759A (ja) | 画像処理方法 | |
JP5146145B2 (ja) | 画像処理装置、画像処理方法、コンピュータプログラム、及び、情報記録媒体 | |
JP4125087B2 (ja) | 画像処理方法 | |
JP5141886B2 (ja) | 画像処理装置、画像処理方法、プログラム及び記録媒体 | |
JP2003224704A (ja) | 画像処理方法及び装置 | |
JP2007142581A (ja) | 画像処理方法、画像処理装置 | |
JP2006319482A (ja) | 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070115 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070126 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070327 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070427 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070509 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100518 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110518 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120518 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120518 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130518 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140518 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |