JP3768934B2 - 画像処理装置及びそのデータキャッシュ方法 - Google Patents
画像処理装置及びそのデータキャッシュ方法 Download PDFInfo
- Publication number
- JP3768934B2 JP3768934B2 JP2002222021A JP2002222021A JP3768934B2 JP 3768934 B2 JP3768934 B2 JP 3768934B2 JP 2002222021 A JP2002222021 A JP 2002222021A JP 2002222021 A JP2002222021 A JP 2002222021A JP 3768934 B2 JP3768934 B2 JP 3768934B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- encoded data
- file
- dummy
- packet
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Image Processing (AREA)
- 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)
Description
【発明の属する技術分野】
本発明は、符号化された画像データを送受して処理する画像処理装置及びそのデータキャッシュ方法に関するものである。
【0002】
【従来の技術】
インターネットに接続可能なパーソナルコンピュータ(以下、単にコンピュータと称する)等の画像処理装置のユーザは、その装置が有するウエブブラウザの機能を利用して、インターネット上のWWW(World Wide Web)サーバにアクセスすることにより、各種の文書データや画像データ等の閲覧を行なっている。
【0003】
このようなウエブブラウザを利用した情報の閲覧は、インターネット上において各種情報を公開するWWWサーバ(以下、単にサーバと称する場合がある)と、その情報を閲覧するコンピュータ(ユーザ端末)等のクライアントとの間で行われ、クライアント側において、ユーザは、ウエブブラウザを操作することによってサーバ上の情報を閲覧することができる。
【0004】
このWWWサーバには、情報提供者がインターネット上での公開を希望する各種の情報が、所謂、ホームページといわれるHTML形式で記述された情報で格納されており、その情報は、クライアント側のウエブブラウザの機能により、クライアント側のコンピュータに表示される。またクライアント側のユーザは、ウエブブラウザを操作することにより、ディスプレイに表示されているホームページ内のリンクを辿ってユーザ所望の情報を得ることができる。
【0005】
また、サーバにて管理されている各種のデータファイルをクライアント側のコンピュータにダウンロードする方法として、File Transfer Protocol(以下、FTPと略す)なる通信プロトコルを利用する方法がある。このFTPは、通信ネットワークを介して、サーバ上にあるファイルをクライアント側のコンピュータに転送する手順を規定している。
【0006】
これに対して、上述したWWWサーバとウエブブラウザによってインターネット上で構成される情報閲覧システムにおいては、Hyper Text Transfer Protocol(以下、HTTPと略す)なる通信プロトコルを用いて、サーバ/クライアント間の通信が行われており、このHTTPは、以下のように動作する。
【0007】
例えば、クライアント側のユーザ端末でウエブブラウザを利用して、ユーザがあるホームページ内のリンク情報が張られている部分をクリックすると、ウエブブラウザは、そのクリックされた部分のリンク情報を解読すると共に、その解読結果に従って新しいURL(Uniform Resource Locator)をオープンする。ここで、オープンとは、目的のサーバに対して、ドキュメント情報の送信リクエストを発行することである。
【0008】
この送信リクエストを受けたサーバは、そのリクエストに対応するドキュメント全体をクライアントに返す。この時、サーバから送られてくるドキュメントは、ヘッダ情報とドキュメント情報本体とからなり、ウエブブラウザにてURLによって指定されたドキュメント全部のデータであって、当該サーバからクライアント側のコンピュータに一度に転送される文書データである。
【0009】
この文書データを受信したクライアント側のウエブブラウザは、まず、サーバから受信した文書データに含まれるヘッダ情報を解析する。具体的には、ヘッダ情報に含まれるMIME−TYPEに従って、当該ヘッダ情報に続くドキュメント情報を開くことが可能なアプリケーションを特定する。その後、ウエブブラウザは、ユーザ端末に予めインストールされている、特定されたアプリケーションを起動し、このヘッダ情報の後に続くドキュメント情報本体を、その起動したアプリケーションに渡す。これにより、ウエブブラウザから受信した文書データ(ドキュメント)が、そのユーザ端末のディスプレイに表示され、ユーザによる閲覧が可能になる。
【0010】
上述したようにHTTPでは、基本的にクライアント側からあるURLのオープン要求がサーバ側に伝えられると、サーバ側では、そのURLで指定されている文書データ全体をクライアント側に送信する動作が行われる。
【0011】
これに対して、上述したFTPでは、上記のHTTPの場合と同様に、URLを利用してユーザが所望するドキュメントが指定されるが、ここで指定されるドキュメントは、サーバ内で管理されているファイルである。よって、このサーバは、指定されたファイル全体をクライアント側のコンピュータに転送し、クライアント側でファイルとして格納する。
【0012】
【発明が解決しようとする課題】
上述したHTTPやFTP等の通信プロトコルでは、サーバでファイルとして管理されているドキュメントのうち、ダウンロード対象のドキュメントを構成する全データが、ユーザ端末からの送信リクエストに応じて、そのユーザ端末(コンピュータ)に送信されることになる。このため、そのドキュメント内に含まれる、ある画像データファイルだけにアクセスする等といった、あるドキュメントにおける部分的なデータのアクセスを、ユーザ端末から行なうことができないという問題がある。
【0013】
係る状況に対して、ユーザ端末において所望の画像を表示するためのプロトコルとして、例えばFlashpix/IIPがある。このIIP(Internet Imaging Protocol)は、Flashpixという画像データのファイルフォーマットに最適なプロトコルになっており、画像データファイルへの部分的なアクセスを実現している。但し、このFlashpix/IIPにおいて、画像データに部分的にアクセスできる単位は、Flashpixで定められたタイル単位である。このFlashpixのタイルは、1つのタイルを構成する画像データ(圧縮されている場合を含む)のみで、そのタイルの画像データを復号(デコード)して再生できる構成になっている。このため、クライアント側のユーザ端末で起動される画像データのデコード及び表示用のアプリケーションは、その受信したタイル画像データを自装置内で一時的に保存(キャッシュ)しなくても、そのタイル単位で画像をデコードして表示できる。
【0014】
また、近年においては、ISO/IEC-15444に準拠したJPEG(Joint Photographic Experts Group)2000方式の画像符号化の技術が提案されているが、インターネットを含む一般的な通信ネットワーク上に構成されたクライアント/サーバ環境において、上記のFlashpix/IIPをJPEG2000方式に基づいて符号化された画像データ(以下、符号化データ)にそのまま適用した場合、JPEG2000方式における各スケイラビリティの符号化データは、そのスケイラビリティより1つ下のスケイラビリティのデータに基づく差分データとなる。
【0015】
従って、上述したようにFlashpixでは、1つのタイルを構成する画像データのみで、そのタイルの画像データをデコードできる構成になっているのに対して、JPEG2000方式に基づくデコードを行う場合には、クライアント側のコンピュータ(ユーザ端末)では、今回表示されるべき画像のスケイラビリティより下の符号化データも必要になる。
【0016】
また、JPEG2000方式に基づく符号化データをクライアント側のコンピュータでキャッシュする場合、そのコンピュータは、サーバ側から部分的な符号化データを受信することになるため、受信した複数の部分的な符号化データを、1つの符号化データのデータファイルとして編成することができる。しかしながら、この場合は、クライアント側での編集処理等が煩雑になり、必要な機能を実現するソフトウエアのコストの低減が容易でないという問題がある。
【0017】
また、サーバから受信した部分的な符号化データを、クライアント側のコンピュータにおいて独自形式のキャッシュファイルとして構成することも可能である。しかしこのような場合には、クライアントにおいて動作するJPEG2000方式のデコーダが、この独自形式のキャッシュファイルを読み取る処理が複雑になるという問題がある。
【0018】
本発明は上記従来例に鑑みてなされたもので、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、キャッシュする画像処理装置とそのデータキャッシュ方法を提供することを目的とする。
【0019】
【課題を解決するための手段】
上記目的を達成するために本発明の画像処理装置は以下のような構成を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信手段と、
前記受信手段により受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出手段と、
前記算出手段により算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成手段と、
前記ダミーデータ生成手段によって設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換手段と、を有することを特徴とする。
【0020】
上記目的を達成するために本発明の画像処理装置におけるデータキャッシュ方法は以下のような工程を備える。即ち、
通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置におけるデータキャッシュ方法であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信工程と、
受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出工程と、
前記算出工程で算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成工程と、
前記ダミーデータ生成工程で設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換工程と、を有することを特徴とする。
【0021】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【0022】
<実施の形態1>
図1は、本発明の実施の形態1に係る画像処理装置としてのコンピュータ機器の概略構成を示すブロック図である。
【0023】
同図において、CPU101は、一次記憶102に格納されたプログラムを実行して、このコンピュータ機器全体の動作制御を行なう。本実施の形態において、一次記憶ユニット(以下、一次記憶と略称する)102は、記憶媒体の一例として、主にメモリが想定され、二次記憶ユニット(以下、二次記憶と略称する)103に記憶されたプログラム等が読み込まれて格納される。この二次記憶103には、ハードディスク等の記憶媒体を利用することができる。
【0024】
一般に、一次記憶102に格納可能なデータ容量は、二次記憶103に格納可能なデータ容量よりも小さく、一次記憶102に格納しきれないプログラムやデータ等は二次記憶103に格納される。また、長時間記憶しておかなければならないデータ等も二次記憶103に格納される。本実施の形態では、このコンピュータ機器の動作制御処理が記述されたソフトウエア・プログラムが二次記憶103に格納されており、係るソフトウエア・プログラムは、CPU101による実行に先立って、一次記憶102に読み込まれる。
【0025】
入力デバイス104は、例えば、マウス等の補助入力装置やキーボード等の入力装置であり、ユーザの操作をコンピュータに設定するために用いられる。出力デバイス105は、例えば、モニタやプリンタ等である。そして106は、外部装置との双方向の通信が可能な通信インターフェースである。
【0026】
図1に示すこれら各部は、内部バス107によって相互にデータ転送可能に接続されており、CPU101によるコンピュータ機器全体の動作制御を実現している。
【0027】
本実施の形態に係る画像処理装置としてのコンピュータ機器の構成には、この他にも様々な形態が考えられるが、現在では一般的なコンピュータ機器及びその周辺デバイスを利用可能であり、本実施形態における詳細な説明は省略する。
【0028】
図2は、本発明の実施の形態における通信ネットワークの概略を示す図であり、所謂サーバ・クライアント環境を示している。
【0029】
同図において、201及び202は、クライアントとしてのユーザ端末であり、個々のユーザ端末は、図1を参照して上述した画像処理装置としてのコンピュータ機器(コンピュータシステム)である。ユーザ端末201及び202とサーバ204とは、インターネットを含む一般的な通信ネットワーク(以下、単にネットワークと称する)203を介して、互いにデータ通信を行なうことが可能である。
【0030】
サーバコンピュータ(以下、単にサーバと称する)204は、画像ファイルを蓄積するハードディスク等の大容量の記憶装置205を備える。本実施の形態において、記憶装置205には、JPEG2000符号化方式に従って予め符号化された画像データが数多く格納されている。
【0031】
以下の説明では、JPEG2000符号化方式に従って符号化された符号化画像データ(符号化データ)のデータファイルを、ユーザ端末201(202)でキャッシュする方法を具体的な例に従って詳述する。本実施の形態では、具体的に、ユーザ端末201(又は202)のユーザが、そのユーザ端末にて動作するウエブブラウザを操作しながら、ネットワーク203を介して、所望のホームページにアクセスすると共に、そのホームページに含まれるJPEG2000方式の画像データへのリンク部分をクリック(選択操作)することにより、その画像データをユーザが所望するサイズや解像度で取得し、当該ユーザ端末のディスプレイに表示する場合を例にして説明する。
【0032】
ここで、本実施の形態に係るキャッシュ方法の理解を容易にすべく、一般的なJPEG2000方式の符号化データについて概説する。
【0033】
図3は、JPEG2000方式の符号化データの構成を示す図であり、Layer-resolution level-component-position progression(以下、LRCPと記す)に従って記録されたJPEG2000ファイル(JPEG2000方式の符号化データファイル)の構造を示す。
【0034】
このLRCPに準じた場合、一般に、JPEG2000ファイルは、各種の記憶媒体において、レイヤ/resolution/コンポーネント(component)/位置(position)というデータブロックの順に記録される。このようなデータブロックの並び方(配列)は、progression order と呼ばれる。上記位置(position)の概念は、JPEG2000符号化方式では「precinct」という技術の中で考慮されており、ウェーブレット変換を施した後に得られる各解像度の周波数成分において、異なる周波数成分であっても、レイヤ/resolution/コンポーネントが同種/同レベルであれば、オリジナル画像において分割された同じ小領域の位置を示すデータ群として連続的に並ぶ様に配列される様になっている。
【0035】
図4は、JPEG2000の解像度スケイラビリティを説明する図であり、解像度(画像サイズ)と、resolution番号との関係を示している。
【0036】
同図に示すように、最も小さい解像度の画像のresolution番号を「0」とし、resolution番号が1つ大きくなると、その画像サイズは幅と高さがそれぞれ2倍になる。
【0037】
また、図3に示す符号化データの構造において、レイヤ(Layer)番号に対応する各レイヤ内には、resolution番号の小さい順にデータが格納されている。レイヤ番号は、復元されるべき画像の原画(元画像)に対するS/N比に対応しており、レイヤ番号が小さい画像ほど原画に対するS/N比が悪化する傾向を有している。
【0038】
1つのJPEG2000ファイルにおいて、resolution番号とレイヤ番号、並びにコンポーネント番号の最大値は、JPEG2000方式に準拠したエンコーダによって予め設定されており、それらパラメータは、符号化データに格納されている。各パケットは、そのパケット内に格納されているコードブロック(code-block)の情報を管理しているパケットヘッダ(packet header)部と、各コードブロックの符号化データとから構成されている。
【0039】
[キャッシュファイルの作成]
図3及び図4に示すようなJPEG2000方式の符号化データを、本実施の形態において以下に説明するキャッシュ手順に従って、ユーザ端末201(202)においてファイルとして記憶すれば、サーバ204に存在する所望の画像に対応する全ての符号化データを当該ユーザ端末に取得しなくても、ユーザが必要な部分(解像度)の符号化データのみを当該サーバから受信して効率的に画像を閲覧することが可能になる。
【0040】
ユーザ端末における受信データの単位としては、JPEG2000のパケット(パケット)、或いはパケットよりも更に小さい符号化単位であるコードブロック単位が考えられるが、本実施の形態では、ユーザ端末がサーバ204から受信するデータ単位としてパケット単位を想定する。
【0041】
図5は、本発明の実施の形態におけるサーバ/クライアント間での通信プロトコルを説明する図であり、パケット単位のリクエスト及びレスポンスの概念を示している。
【0042】
同図において、ユーザ端末201,202は、ユーザによる選択操作に応じて、画像のタイル(Tile)番号、resolution level、レイヤ、コンポーネント(component)、並びに位置(position)番号を指定して、対応する画像データをサーバ204に要求する。サーバ204は、この要求を受信すると、記憶装置205に格納されている画像データ503(図3に示すデータ構造と同様である)のコードストリームを解析した後、ユーザ端末より指定されたタイル番号、resolution levelとレイヤ、コンポーネント、位置番号に相当するパケットデータを取り出し、その取り出したパケットデータを、ユーザ端末に送信する。以下、この一連の動作を実現するユーザ端末の動作について説明する。
【0043】
図3の例では、ユーザ端末からタイル1、resolution 0、レイヤ0、コンポーネント0,位置0のデータが要求されており、これを含むタイル1のパケット0のデータがサーバ204からユーザ端末に返送されている。
【0044】
図6は、本発明の実施の形態1乃至6に係るユーザ端末(201又は202)における受信データのキャッシュ処理を示すフローチャートで、CPU101が実行するソフトウエア・プログラムに記述された手順を示している。
【0045】
同図において、まずステップS601において、ユーザ端末はネットワーク203を介して、複数の画像が格納されているサーバ204に対して、必要な画像の名前と、その画像データのメインヘッダとを要求する。次にステップS602に進み、ステップS601の要求に対してサーバ204から送信されるパケットデータのメインヘッダを受信したかを調べ、受信した場合はステップS603に進み、このユーザ端末は、その受信したメインヘッダに基づいて、図7に示すような画像全体の情報及びキャッシュファイルを管理するためのファイル(以下、メインファイルと記す)701を作成し、ステップS602で取得したメインヘッダを、メインファイル701の領域703に書き込む。
【0046】
即ち、ユーザ端末は、メインヘッダを受信すると、ステップS603にて、図7に示すようなデータフォーマットを有する画像全体の情報を管理するメインファイル701を、二次記憶103の所望の領域(例えばCドライブのTempフォルダ)内に、オリジナル画像の名前を先頭に挿入したファイル名のファイルを作成すべく、そのファイル名の入力操作を促す。例えば、ユーザが「image.jp2」ファイルを要求した場合、そのユーザ端末は、「image.iip2k」という名前のメインファイル701を二次記憶103のフォルダ内に作成する(尚、ステップS603における処理の詳細については、図9を参照して後述する)。
【0047】
次にステップS604に進み、ユーザ端末におけるユーザの選択操作に応じて必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク203を介してサーバ204に要求する。このステップS604におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関係ないので、その説明を省略する。
【0048】
これによりサーバ204は、ユーザ端末から指示された画像部分を、JPEG2000方式のパケット単位で、そのユーザ端末に送信する。
【0049】
そしてステップS605に進み、そのパケット(packet)データを受信するとステップS606に進み、その受信したパケットデータをファイルとして編成し、ステップS603で作成したメインファイル701の当該パケットデータに関連する情報の記述部分を書き換える(尚、ステップS606における処理の詳細については、図12を参照して後述する)。
【0050】
次にステップS607に進み、更なる画像データを要求する操作がユーザによって行われたかを判断し、要求操作が検出された場合にはステップS604に戻り、要求操作が検出されない場合にはリターンする。
【0051】
図9は、本発明の実施の形態1におけるメインファイルの作成処理(ステップS603)を示すフローチャートである。
【0052】
同図において、ステップS901で、サーバ204から受信したメインヘッダ(main header)を解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、位置(position)数、progression orderを取得する。次にステップS902に進み、原画像の高さと幅、及び最大解像度時のタイルの高さと幅に基づいて、タイル数を計算する。次にステップS903に進み、ステップS901で取得したresolution level数、レイヤ数、コンポーネント数、並びに位置数に基づいて、各タイルに含まれるパケット数を計算する。次にステップS904に進み、JPEG2000方式の符号化データにおいて「zero length packet」であることを示す1バイトの値「0」が入っているファイル(以下、ゼロレングス・パケットファイルと記す)を、ステップS903で得られた、各タイルに含まれるパケット数と同じ数だけ作成する。例えば前述の「image.jp2」ファイルのタイル番号が「0」、パケット番号が「2」のパケットに対して、1バイトの値「0」が入った「image_tile00000_pkt0002.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じCドライブのTempフォルダ(C:/Temp/)に作成される。即ち、このステップ904では、各パケットに対して、JPEG2000方式のビットストリーム・シンタックスで規定されているゼロレングス・パケットを示す値(ダミー符号化データ)を持ったメインファイル701が作成されることになる。
【0053】
次にステップS905に進み、ステップS901にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、並びにメインヘッダのデータ長を、画像管理情報として、メインファイル701の領域706に書き込む。尚、このメインファイル701の領域703には、受信したメインヘッダのデータが書き込まれる。
【0054】
次にステップS906に進み、メインファイル701の領域702に、図7の右側に拡大して示すような、各タイルの基本情報を作成する(尚、このステップS906の処理の詳細については、図10を参照して後述する)。次にステップS907に進み、ステップS906で作成した各タイルの基本情報を、メインファイル701の領域702に書き込んで、このメインファイルの作成処理を終了する。
【0055】
図10は、本実施の形態1に係るタイル基本情報の作成処理(ステップS906)を示すフローチャートである。この図10に示すフローチャートは、メインファイル701の作成時にのみ行われる処理を示すフローチャートであって、この処理は初期状態にのみ実行される。尚、ステップS906では、図10に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図7に示すメインファイル701の領域702が作成される。またこの領域702の詳細構成は、図8に示すような構成である。
【0056】
図10において、まずステップS1001で、図9のステップS903で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末は、サーバ204から未だパケットデータを受け取っておらず、上述したステップS904の処理が実行されることにより、メインファイル701の全てのパケットはゼロレングス・パケットである。そこで、ステップS1002では、各タイルのデータ長を、
(タイルヘッダの長さ)+(タイルに含まれるパケット数)×1バイト
により算出する。
【0057】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、1タイルに36パケットが含まれている場合、このタイルのデータ長は、14+1×36=50[バイト]となる。
【0058】
次にステップS1003に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカが作成される。タイル番号が「0」、含まれるパケット数が「36」のタイルに対して作成されるSOTマーカの構成とそのデータサイズを図11に示す。
【0059】
次にステップS1004に進み、メインファイル701に、タイルのデータ長804、タイル番号805及び、そのタイルに含まれるパケット数806、タイルが含むresolution数、レイヤ数、コンポーネント数等を、タイルデータ管理用データ704に書き込む。次にステップS1005に進み、メインファイル701の領域705にタイルヘッダを書き込む。次にステップS1006に進み、パケット番号に「0」を設定し、以後、パケットの番号順にステップS1007以下の処理を繰り返し実行する。
【0060】
まずステップS1007では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップS1008に進み、注目するパケットのデータ長1と、このパケットデータに対応するゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル701の領域702の領域802に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとしては、例えばファイル名「image_tile0000_pkt0002.iip2k」等、注目するパケットのデータが入っているファイルを特定する値を領域803に書き込む。次にステップS1009に進み、注目すべきパケットのパケット番号を一つ進め、ステップS1010において、ステップS1007からの一連の処理が、そのタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「36」の場合には、ステップS1009の後のパケット番号が「36」だった場合は、このフローチャートを終了する。つまり、初期状態では、サーバ204の画像ファイルに含まれるパケットの数と同数のゼロレングス・パケットデータを持つデータファイルがユーザ端末にキャッシュされる。
【0061】
ここまでの処理によって作成されたキャッシュファイルのデータ部分が、ユーザ端末のJPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件の値でデコード処理できる。つまりデコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【0062】
図12は、本発明の実施の形態1に係る、図6のステップS606におけるメインファイル701の上書き処理を示すフローチャートである。
【0063】
同図において、ステップS1201では、受信したパケットデータを含むタイル番号とそのパケットの番号とを取得する。例えば、図13に示すようなバイナリ形式のレスポンスデータが、サーバ204からユーザ端末に送られてきた場合、TIdx(1301)、PIdx(1302)は、それぞれ受信したパケットデータを含むタイル番号とそのパケット番号を表しており、ステップS1201ではこれらの値が利用される。このレスポンスデータはバイナリ形式に限らず、XMLのようなテキスト形式でも可能である。ステップS1202では、受信したパケットデータが書き込まれたファイルを、メインファイル701が作成されたフォルダと同一のフォルダ内に作成する。例えば、「image.jp2」ファイルのタイル番号が「0」、パケット番号が「2」のパケットに対しては、上述した図9のステップS904において、「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルがCドライブのTempフォルダに作成されているので、そのファイルは新たに受信したパケットデータに書き換えられる。
【0064】
次にステップS1203以下の各ステップにおいて、メインファイル701のこのパケット(注目するパケット)に関する情報が書き換えられる。ステップS1203では、メインファイル701の作成時に、注目するパケットのデータ長として「1」を書き込んでいた領域807を、サーバ204から実際に受信したパケットデータのデータ長に書き直す。次にステップS1204に進み、注目するパケットに対応するゼロレングス・パケットファイルを指し示すポインタ情報803を、当該注目するパケットデータが入っているファイルとして、ステップS1202で作成されたファイルへのポインタ情報に書き換える。例えば、ファイルへのポインタ情報としてファイル名が書かれており、図9のステップS904において、「image.jp2」ファイルのタイル番号が「0」、パケット番号が「2」のパケットに対して「image_tile00000_pkt0002.iip2k」という名前のゼロレングス・パケットファイルが作成されていて、図12のステップS1202において、受信したパケットデータがそのファイルに上書きされた場合は、書き直す必要はない。
【0065】
次にステップS1205に進み、注目するパケットが含まれているタイルのデータ長を新たに計算し直し、図8の領域801で示されるメインファイル701のタイルのデータ長が記述された領域804を書き換える。例えば、一度に1つのパケットデータしか更新されないと仮定すると、今回新たに受信したパケットデータのバイト数を512バイトとした場合、図8の領域804のタイルデータ長は、ゼロレングス・パケットの長さ「1」を引いて、新たに受け取ったバイト数「512」を足せばよいので、その値は「511」(=512−1)に更新される。次にステップS1206に進み、パケットデータが含まれるタイルのSOTマーカ705のタイルデータ長を記述した部分、即ち図11におけるPsot(1101)を、領域804に上書きした値で更新する。
【0066】
従って、例えばタイル数が「4」、各タイル内のパケット数が「36」の場合、本実施の形態では、図14に示すようなファイルがユーザ端末のCドライブのTempフォルダに作成される。図6のステップS603において、メインファイル701とゼロレングス・パケットファイルをユーザが作成してからは、図14に示されたキャッシュのファイル数(1+36×4=)145個と、ファイル名とは変更されない。
【0067】
上述した本実施の形態1に係るキャッシュ方法をユーザ端末201(又は202)で実行すれば、サーバ204に用意された全ての画像データ(差分符号化データ)を受信しなくても、未受信部分のパケットデータは、メインファイル701において、図9のステップS904の処理においてゼロレングス・パケットデータとして埋められるので、JPEG2000の所定フォーマットに準拠したストリームとして格納できる。従って、ユーザ端末では、データの一部を受け取った場合に、サーバ204から受信したメインヘッダを書き換えることなく、その作成したメインファイル701に含まれるメインヘッダ部分とタイルヘッダ部分とを、それぞれのパケットデータのファイルとして1つのファイルにつなぎ合わせることにより、一般的なJPEG2000デコーダでデコード可能なファイルを当該ユーザ端末において容易に編成することができる。
【0068】
<実施の形態2>
上述した実施の形態1では、ユーザ端末201(又は202)が未だ受信していないパケットに対して作成されるゼロレングス・パケットファイルを、各パケット毎に作成していた。しかし、このこのゼロレングス・パケットファイルのデータは全て同じ値である。このため、1つの画像に対しては1つのゼロレングス・パケットファイルを作成し、パケットデータを受け取っていない全てのパケットがそのファイルを参照するように構成しても良い。この場合、上述の実施の形態1とは、図6で示したクライアント側(ユーザ端末)のキャッシュ作成処理を示すフローチャートのステップS603のメインファイル作成処理と、パケットデータ受信後のステップS606でメインファイルを書き換える処理とが異なる。本実施の形態2では、係る構成について説明する。
【0069】
図15は、本発明の実施の形態2に係るメインファイル701の作成処理を示すフローチャートであり、ステップS901乃至ステップS903、並びにステップS905及びステップS907の処理は、図9を参照して説明した前述の実施の形態1における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0070】
ステップS1504では、JPEG2000方式の符号化データにおいてゼロレングス・パケットであることを示す1バイトの値「0」が入っているファイル、即ち、ゼロレングス・パケットファイルを1つだけ作成する。例えば、「image.jp2」ファイルに対しては、「image_zero.iip2k」という名前のファイルが、メインファイル「image.iip2k」と同じCドライブのTempフォルダに作成される。即ち、1画像に対して1ファイルのゼロレングス・パケットが作成される。
【0071】
そしてステップS1506では、図7に領域702で示すような各タイルの基本情報を作成するが、前述の実施の形態1において作成されたタイルの基本情報の構成とは少々異なるので、図16を参照して説明する。
【0072】
図16は、本実施の形態2に係るタイル基本情報の作成処理(ステップS1506)を示すフローチャートであり、ステップS1001乃至ステップS1007、並びにステップS1009及びステップS1010の処理は、図10を参照して説明した実施の形態1における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0073】
図16に示すフローチャートは、前述の実施の形態1の場合と同様に、メインファイル701の作成時にのみ実行される処理を示すフローチャートであって、初期状態にのみ行われるフローチャートである。
【0074】
図15のステップS1506では、図16に示すフローチャートの動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図7に示すメインファイル701の領域702が作成される。また、この領域702は、その内部において、図8に示すような詳細な構成を有する。
【0075】
ステップS1608では、注目するパケットのデータ長1と、ゼロレングス・パケットファイルへのポインタ、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル701の領域802に書き込む。このとき、ゼロレングス・パケットファイルへのポインタとして、例えば「image_zero.iip2k」のようなファイル名等、そのパケットのデータが入っているファイルを特定する値を領域803に書き込む。
【0076】
本実施の形態2では、上述したように、ゼロレングス・パケットファイルを1つしか作成していないので、初期状態においては、メインファイル701に書かれている全てのパケットデータファイルへのポインタ、即ち図8の領域803が指す示す先は「image_zero.iip2k」となる。
【0077】
次に、本実施の形態2におけるメインファイル701の上書き処理(図6のステップS606)について、図17を参照して説明する。
【0078】
図17は、本発明の実施の形態2に係るメインファイルの上書き処理を示すフローチャートであり、ステップS1201乃至ステップS1203、並びにステップS1205及びステップS1206の処理は、図12を参照して説明した実施の形態1における同一ステップ番号の処理構成と同じであるため、そのステップの説明を省略する。
【0079】
ステップS1704では、注目するパケットのデータが入っているファイルとして、ゼロレングス・パケットファイルを指し示していたポインタ803の情報を、ステップS1202で作成されたファイルへのポインタ情報に書き換える。例えば、ポインタ803に書き込まれていたファイル名「image_zero.iip2k」は、新たに作成した「image_tile00000_pkt0002.iip2k」というファイル名に書き換えられる。
【0080】
本実施の形態2によって、ユーザ端末で作成されるキャッシュファイルの構成を図18に示す。このようなキャッシュファイルの構成を採ることにより、初期状態ではメインファイル1801とゼロレングス・パケットファイル1802の2つのファイルのみが作成される。初期状態においては、メインファイル701のパケットデータファイルを指し示すポインタ803には、全てのパケットにおいてゼロレングス・パケットファイル1802へのポインタ情報が書かれており、その後、パケットデータをサーバ204から受信する度にファイルが増えていく。これにより、前述の実施の形態1の手順と比較して、作成すべきファイルの数を削減することができる。
【0081】
<実施の形態3>
上述した実施の形態1及び2では、ユーザ端末201(又は202)に未だ受信していないパケットに対して作成される1バイトのゼロレングス・パケットファイルを作成していた。しかし、まだ受信していないパケットデータであることを示す値を、メインファイル701のパケットデータ管理部分802に明記しておき、ファイルを読み出す際に、1バイトの値「0」を返してもよい。従って本実施の形態3では、前述の実施の形態1及び2とは異なり、ゼロレングス・パケットファイルを作成しない方法について説明する。
【0082】
本実施の形態3に係る処理構成において、実施の形態1及び2とは、図6に示すキャッシュ作成処理を示すフローチャートのステップS603で行われるメインファイル作成処理と、ステップS606で行われる受信パケットに関するデータを上書き処理とが異なる構成となる。
【0083】
図19は、本発明の実施の形態3に係るメインファイル701の作成処理(図6のS603に相当)を示すフローチャートであり、ステップS901乃至ステップS903、並びにステップS905及びステップS907の処理は、図9を参照して前述した実施の形態1における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0084】
つまり、本実施の形態3におけるメインファイルの作成処理では、図9のステップS904、即ち、受信していないパケットに関するゼロレングス・パケットファイルを作成するステップを行う必要がない。また、この処理構成に対応して、本実施の形態3では、図19のステップS1906において作成されるタイル基本情報は、前述の実施の形態1や2の場合と異なる。そこで、本実施の形態3におけるタイル基本情報の作成処理について、図20を参照して説明する。
【0085】
図20は、本実施の形態3に係るタイル基本情報の作成処理(S1906)を示すフローチャートであり、ステップS101乃至ステップS1007、並びにステップS1009及びステップS1010の処理は、図10を参照して説明した前述の実施の形態1における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0086】
ステップS2008では、注目するパケットのデータ長1と、このパケットがゼロレングス・パケットであることを示す値、resolution level、レイヤ、コンポーネント、position番号等の、当該注目するパケットを管理する際に必要になる情報を、メインファイル701の領域802に書き込む。このゼロレングス・パケットファイルであることを指し示す値としては、例えば、NULL等の値を803に書き込めばよい。
【0087】
本実施の形態3では、ゼロレングス・パケットに対するファイルが作成されないので、図20に示すフローチャートの処理を終了するに際して、初期状態においては、メインファイル701だけがユーザ端末で作成される。
【0088】
ここまでの処理によって作成されたキャッシュファイル中のデータ部分と、各パケットに対応する値「0」とが、メインファイル701の記述に従って、JPEG2000のデコーダに対してシーケンシャルに送られると、画像データの基本的な情報である画像サイズ等は、そのままの条件でデコード処理できる。つまり、デコーダでは、全てのパケットは「無い」状態であると判断され、デコード可能である。
【0089】
図21は、本実施の形態3に係るメインファイルの上書き処理(S606)を示すフローチャートであり、ステップS1201乃至ステップS1203、並びにステップS1205及びステップS1206の処理は、図12を参照して説明した前述の実施の形態1における同一ステップ番号の処理と同じであるため、その説明を省略する。
【0090】
ステップS2104では、注目するパケットがゼロレングス・パケットであることを示す値が入っていた領域803を、ステップS1202で作成されたファイルへのポインタ情報に書き換える。例えば、ゼロレングス・パケットであることを示す値NULLが書かれていた領域803は、「image_tile00000_pkt0002.iip2k」という名前に書き換えられる。
【0091】
このようなキャッシュ方法がユーザ端末において行なわれる本実施の形態3によれば、メインファイル701と、受信したパケットデータのファイルとだけが作成されるので、前述の実施の形態1及び2と比較して、作成すべきファイル数を削減することができる。
【0092】
<実施の形態4>
上述した実施の形態1乃至3では、全てのファイルを、同一フォルダの下に作成していた。しかしながら、サーバ204から受信するパケット数が多い場合には、それらパケットを、複数のフォルダに分散して管理しても良い。
【0093】
図22は、本発明の実施の形態4に係る、パケットデータをタイル毎にフォルダに保存する例を説明する図であり、この例では、同一タイルに含まれるパケットデータのファイルが、同じフォルダ内に保存される。
【0094】
図22において、オリジナル(原画像)である画像2201が4つのタイルに分割されている。サーバ204は、ユーザ端末から受信した要求に応じて、画像データからパケットデータ2202だけを抜き出し、そのパケットデータ2202を当該ユーザ端末に送る。そして、このユーザ端末は、各タイルのために4つのフォルダ2203,2204,2205,2206を用意し、サーバ204から受信したパケットデータに対応するフォルダに、そのパケットデータから作成されたパケットデータファイルを保存する。
【0095】
本実施の形態4が上述した実施の形態1乃至3と異なるのは、ユーザ端末がサーバ204から受信したデータをキャッシュする動作処理(図6)におけるステップS603の処理である。
【0096】
図23は、本実施の形態4に係る、メインファイル701の作成処理(S603)を示すフローチャートで、ステップS901乃至ステップS903、並びにステップS904乃至ステップS907の処理は、図9を参照して説明した前述の実施の形態1における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0097】
ステップS2301では、ステップS903で得られたパケット数が所定数を超えているかを判断することにより、タイル毎にフォルダを作成するか否かを判断する。この判断は、必ずタイル毎のフォルダを作るというシステムならば必要ないが、例えば、ユーザ端末のCPU101の処理能力を表わす情報に基づいて、1つのフォルダで無理なく扱えるファイル数(閾値)を判断し、その閾値以上のパケット数がある場合にはタイル毎にフォルダを作る。この閾値を得る方法としては様々な方法が考えられるが、本願の特徴ではないので説明を省略する。
【0098】
ステップS2301においてタイル毎のフォルダは作らないと判断した場合はステップS904に進む。一方、ステップS2301でタイル毎にフォルダを作成すると判断した場合はステップS2302に進み、ユーザ端末は、タイル数だけフォルダを作成する。例えば、「image.jp2」ファイルが50個のタイルに分割されている場合、「image_tile0000」から「image_tile0049」という名前のフォルダが、メインファイル「image.iip2k」と同じ、CドライブのTempフォルダに作成される。
【0099】
本実施の形態4では、各パケットに対応するゼロレングス・パケットファイルがそれぞれのフォルダ内に作成される。このため、図23のステップS906において作成されるタイル基本情報の詳細な手順は、前述の実施の形態1におけるタイル基本情報の作成処理(図10)と同様である。この場合、各パケットファイルを指し示すポインタ情報、即ちメインファイル701の領域803には、ファイル名、例えば「image_tile0000_pkt0002.iip2k」というファイル名が書き込まれても良いし、パスも含めて「C:/Temp/image_tile0000/image_tile0000_pkt0002.iip2k」が書き込まれても良い。
【0100】
図24は、本実施の形態4に係るキャッシュファイルの構成を示す概念図である。
【0101】
また本実施の形態4では、各パケットに1つのゼロレングス・パケットファイルが作成される実施の形態1と同様の方法のみを記述したが、前述の実施の形態2のように1つのゼロレングス・パケットファイルを作成する方法、或いは実施の形態3のように、ゼロレングス・パケットファイルを一切作らずに、ゼロレングス・パケットであることを示す値、例えばNULLを、メインファイル701の領域803に書き込む方法によっても実現できる。また前述の実施の形態2と同様に、1つのゼロレングス・パケットファイルを作成する場合、そのファイルは、メインファイル701と同じフォルダ内、例えばCドライブのTempフォルダに作成すればよい。
【0102】
更に、ユーザ端末において複数画像を扱う可能性がある場合には、画像毎にフォルダを作成しても良い。例えば、図25に示すようにCドライブのTempフォルダに画像別のフォルダを作り、更に、そのフォルダをタイル毎のフォルダに分けてもよい。画像別のフォルダの下は、上述した実施の形態1乃至4で説明したキャッシュファイルの作り方が可能である。
【0103】
このように本実施の形態4によれば、キャッシュファイルは複数のパケットデータファイルから構成されるが、タイル毎にフォルダに分割することにより、1つのフォルダ内で作成されるファイル数を制限することができるため、ファイルの作成、削除等のユーザ端末のOS(オペレーションシステム)に依存する処理を、上述した他の実施の形態と比較して迅速に行うことができるという利点がある。
【0104】
<実施の形態5>
本実施の形態では、上述した実施の形態1,2,4において作成されたキャッシュファイルを読み出す方法について、図面を用いて具体的に説明する。
【0105】
図26は、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートであり、上述した実施の形態1,2,4において、ユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示す。
【0106】
まずステップS2601で、図6のステップS603で作成されたメインファイル701をオープンする。例えば、「image.jp2」に対して、CドライブのTempフォルダに「image.iip2k」というファイル名のメインファイルが作成された場合には、「C:/Temp/image.iip2k」が開かれる。次にステップS2602に進み、読み出し対象のデータがメインヘッダのデータであるかどうかを判断する。ここでメインヘッダを読まないと判断した時はステップS2604に進むが、メインヘッダを読むと判断した場合はステップS2603に進み、メインファイル701の、サーバ204から取得したメインヘッダのデータがそのまま書き込まれた領域703にファイルポインタを移動すると共に、そのメインヘッダのデータを読み出す。そしてステップS2604では、読み出し対象のデータがタイルヘッダのデータなのかを判断する。ここでタイルヘッダのデータを読み出すと判断した場合は、ステップS2605に進む。タイルヘッダのデータは読み出さないと判断した場合は、ステップS2606に進む。
【0107】
ステップS2605では、メインファイル701の、読み出し対象のタイルヘッダ705が記述されている部分にファイルポインタを移動させて、そのタイルヘッダのデータを読む。
【0108】
ここで例えば、ステップS2605において、タイル番号が「0」から始まっていて、読み出し対象のタイルヘッダがタイル番号1のヘッダの場合には、図7に示すメインファイル701の先頭から、画像情報706及びメインヘッダデータ703、及びタイル番号0に関するデータ702を読み飛ばした先に格納されているところの、タイル番号1のタイルに関するデータ702の先頭にファイルポインタを移動し、更に、その中のタイルデータの管理用データ704の次にあるタイルヘッダデータ705の先頭にファイルポインタを移動させ、その後、そのタイルヘッダ705のデータを読み出す。
【0109】
次にステップS2606に進み、読み出し対象のデータがパケットデータであるかを判断する。ここでパケットデータを読み出すと判断した場合にはステップS2607に進み、パケットデータを読み出さないと判断した場合はステップS2608へ進む。ステップS2607では、読み出し対象のパケットのデータが格納されているパケットファイルからデータを読み出す(尚、ステップS2607の詳細については、図27を参照して後述する)。
【0110】
次にステップS2608に進み、読み出し対象のデータがあるかを判断し、読み出し対象のデータがあればステップS2602へ戻って前述の処理を繰り返す。一方、ステップS2608で、読み出し対象のデータを全て読んだと判断した場合にはステップS2609へ進み、オープンしていたメインファイル701をクローズして、この読み出し処理を終了する。
【0111】
図27は、本発明の実施の形態5に係るパケットデータの読み出し処理(ステップS2607)を示すフローチャートである。
【0112】
同図において、まずステップS2701で、読み出し対象のパケットのデータが入っているファイルへのポインタ803の情報に従ってファイル名を取得する。例えば、タイル番号1のパケット番号0のデータを読み出す場合には、メインファイル701からタイル番号1に関するタイル情報が書かれている領域702を求め、その中からパケット番号が「0」のパケットデータ管理用データ802を検索する。そして、そのパケット管理用データ802の、そのパケットデータが記述されているファイルへのポインタ803の情報に基づいて、そのファイル名を取得する。
【0113】
次にステップS2702に進み、ステップS2701で取得したファイル名のファイルを開く。例えば、ステップS2702で取得したファイル名が、CドライブのTempフォルダのファイル「image_zero.iip2k」であれば、このフォルダのファイル「image_zero.iip2k」が開かれる。またステップS2702で取得したファイル名が「C:/Temp/Tile0001/image_tile0000_pkt0000.iip2k」であれば、CドライブのTempフォルダのTile0001フォルダにあるファイル「image_tile0000_pkt0000.iip2k」をオープンする。
【0114】
次にステップS2703に進み、ステップS2702でオープンされたファイル中のデータを読み出す。次にステップS2704に進み、ステップS2702でオープンされたファイルをクローズし、パケットデータの読み出し処理を終了する。
【0115】
このように本発明の実施の形態5に係る上述した読み出し方法では、パケットデータをユーザ端末が読み出す場合に、メインファイル701に記述されている、そのパケットファイルへのポインタ803の情報が指し示すファイルをオープンしてから、そのファイルのデータを読み出している。
【0116】
このような本実施の形態5によれば、上述した実施の形態1,2,4において作成されたキャッシュファイルを効率良く読み出すことができる。
【0117】
<実施の形態6>
上述した実施の形態1,2,4では、ユーザ端末に未だ受信していないパケットデータに対しても、ゼロレングス・パケットデータが作成されるので、全てのパケットデータは、ファイル中に書き込まれている。
【0118】
しかしながら前述の実施の形態3では、受信したパケットのみに対してファイルが作成されるので、未受信のパケットに対応するファイルは、当該ユーザ端末には存在しない。このため、上述した実施の形態5に係る読み出し方法では、読み出すことのできないパケットデータが存在する。そこで、本実施の形態6では、係る実施の形態3において作成されたキャッシュファイルの読み出し方法について説明する。
【0119】
本実施の形態6において、前述の実施の形態5で説明したキャッシュファイルの読み出し処理(図26)とはステップS2607の処理構成が異なるので、以下の説明では、この点を中心に説明する。
【0120】
図28は、本発明の実施の形態6に係る、パケットデータの読み出し処理を示すフローチャートであり、ステップS2702乃至ステップS2704の処理は、図27を参照して説明した実施の形態5における同一ステップ番号の処理構成と同じであるため、その説明を省略する。
【0121】
同図において、まずステップS2801で、メインファイル701の読み出し対象のパケットに対するポインタ803の情報を取得する。次にステップS2802に進み、ステップS2801で取得したポインタ803の情報がパケットデータファイルへのポインタかどうか判断する。例えば、取得した情報が「C:/Temp/image_tile0000_pkt2.iip2k」というファイル名であれば、ファイルへのポインタ情報である判断し、取得した情報がNULLだった場合には、ファイルを指し示していないと判断できる。そして、ステップS2802において、ポインタ情報803がファイルを指し示す情報であると判断した場合はステップS2702に進み、その後の処理は、実施の形態5と同様である。
【0122】
一方、ポインタ803がファイルを指し示していないと判断された場合には、ステップS2803に進み、パケットに対するファイルが存在しないので、未受信データであると判断し、ゼロレングス・パケットを示す1バイトの値「0」を読み出した情報として返す。
【0123】
このような本実施の形態6によれば、上述した実施の形態3において作成されたキャッシュファイルを効率良く読み出すことができる。
【0124】
尚、上述した本実施の形態6は、未受信データに対してゼロレングス・パケットファイルを作成しない場合の読み出し方法であるので、前述の実施の形態4で説明したように、タイル毎または画像毎にフォルダが作成される場合であっても、未受信データにゼロレングス・パケットファイルを作成しない場合には、同様の読み出し方法を適用できる。
【0125】
<実施の形態7>
上述した実施の形態1乃至6では、それぞれのパケットデータを一つのキャッシュファイルに保存して管理していたが、複数パケットを一つのファイルの中に保存して管理することも可能である。つまり、1つの画像に付き1つのキャッシュファイルで保存管理を行うことができる。
【0126】
図29は、本発明の実施の形態7に係るユーザ端末(画像処理装置:201又は202)における受信データのキャッシュ処理を示すフローチャートである。尚、この図において、前述の図6と同様の動作をするステップには同じ番号を付している。
【0127】
まずステップS601において、ネットワーク203を介して、複数の画像が格納されているサーバ204に対して、ユーザ端末から必要な画像の名前と画像のメインヘッダとを要求する。これによりサーバ204から送られてくるパケットデータを受信し、ステップS602で、メインヘッダを受信したかを判断し、メインヘッダを受信するとステップS2903に進み、その受信したメインヘッダに基づいて、図7に示すような画像全体の情報及びキャッシュデータを管理するための情報、そしてキャッシュデータそのものを保存するファイル(以下、一括キャッシュファイル)を作成し、ステップS602で取得したメインヘッダを、一括キャッシュファイルの領域703に書き込む。ここで作成される一括キャッシュファイルは、前述の実施の形態1乃至4で作成されたメインファイル701と同様のデータ形式ではあるが(そのデータ構成は図7参照)、次の2点が異なる。
(1)実際のキャッシュデータそのものも書き込む
(2)図8のパケットデータの管理用データ802に含まれるポインタ803がオフセット値3002(図30)に変更されている。
【0128】
図30は、本実施の形態7に係る一括キャッシュファイル701a(図31)の領域702a(図8の領域702に対応)のパケット管理用データ802aの構成を示す図である。
【0129】
つまりユーザ端末は、ステップS602でメインヘッダを受信するとステップS603に進み、一括キャッシュファイル701aを、二次記憶103の所望の領域(例えばCドライブのTempフォルダ)に、オリジナル画像の名前を先頭に挿入したファイル名のファイルとして作成する。例えば、ユーザが「image.jp2」ファイルを要求した場合、ユーザ端末は、「image.iip2k」というような名前の一括キャッシュファイルを二次記憶103のフォルダ内に作成する。
【0130】
次にステップS604に進み、ユーザの選択操作に応じて、必要な画像の領域及びresolution、レイヤ、コンポーネントを、ネットワーク203を介して、サーバ204に要求する。ここで、ステップS604におけるユーザの選択操作は、本願の主たる目的であるキャッシュ方法の本質には関らないので詳しい説明は省略する。
【0131】
これによりサーバ204は、ユーザ端末から指示された画像部分をJPEG2000方式のパケット単位で、そのユーザ端末に送信する。これによりステップS605で、そのパケットデータを受信するとステップS2906に進み、その受信したパケットデータに関するキャッシュデータを管理するための情報を書き換え、図31に示すように、一括キャッシュファイル701aの後ろにアペンドするような形式で、領域3101にパケットデータを書き込む。次にステップS607に進み、更なる画像データを要求する操作がユーザによって行なわれたかを判断し、要求操作が検出された場合にはステップS604に戻って前述の動作を実行するが、要求操作が検出されない場合にはリターンする。
【0132】
図32は、図29のステップS2903における一括キャッシュファイル701aの作成処理を説明するフローチャートである。尚、図9に示すメインファイルの作成処理を示すフローチャートと同様の動作には同じ番号を付している。
【0133】
まずステップS901で、サーバ204から受信したメインヘッダを解析することにより、原画像の高さと幅、最大解像度時のタイルの高さと幅及びresolution level数、レイヤ数、コンポーネント数、position数、progression orderを取得する。次にステップS902に進み、原画像の高さと幅、及び最大解像度でのタイルの高さと幅に基づいてタイル数を計算する。次にステップS903に進み、ステップS901で取得したresolution level数、レイヤ数、コンポーネント数、並びにposition数に基づいて、各タイルに含まれるパケット数を計算する。
【0134】
次にステップS3204に進み、ステップS901にてメインヘッダを解析して得られたタイル数、resolution level数、レイヤ数、コンポーネント数等の原画像の基本情報、ゼロレングス・パケットのデータ、並びにメインヘッダのデータ長を、画像管理情報として、一括キャッシュファイル701aの領域706a(図31)に書き込む。この一括キャッシュファイル701aの領域703aには、受信したメインヘッダのデータが書き込まれる。次にステップS3205に進み、一括キャッシュファイル701aの領域702aに、図30の右側に拡大して示すような、各タイルの基本情報を作成する。そしてステップS3206に進み、ステップS3205で作成された各タイルの基本情報を一括キャッシュファイル701aに書き込んで、この一括キャッシュファイルの作成処理を終了する。
【0135】
図33は、本実施の形態7に係る図32のステップS3205におけるタイルの基本情報の作成処理を示すフローチャートで、前述の図10に示すフローチャートと共通するステップには同じ番号を付している。尚、このステップS3205では、図33のフローチャートで示された動作が、タイル番号順に、タイル数分だけ繰り返し行われることにより、図30に示す一括キャッシュファイル701aの領域702aが作成される。
【0136】
図33において、まずステップS1001で、図32のステップS903で既に計算されている、各タイルに含まれるパケット数を取得する。この時点において、ユーザ端末はサーバ204からパケットデータを受け取っておらず、それらの未受信パケットは、全てゼロレングス・パケットとして処理されることが想定されているので、次のステップS1002では、各タイルのデータ長を、
(タイルヘッダの長さ)+(タイルに含まれるパケット数)×1バイト
により算出する。
【0137】
例えば、タイルヘッダに含まれるマーカがSOTマーカのみで、1タイルに36パケットが含まれている場合、タイルのデータ長は、14+1×36=50[バイト]となる。
【0138】
次にステップS1003に進み、タイルの番号及びタイルのデータ長から、JPEG2000方式においてタイルのヘッダに含まれるべきSOTマーカを作成する。ここでタイル番号が「0」、含まれるパケット数が「36」のタイルに対して作成されるSOTマーカの構成と、そのデータサイズ及び具体的な値を図11に示す。
【0139】
次にステップS3304に進み、タイルのデータ長804a、タイルの番号805a及び含まれるパケット数806a、タイルが含むresolution数、レイヤ数、コンポーネント数等を、一括キャッシュファイル701aのタイルデータ管理用データ704aに書き込む。次にステップS3305に進み、一括キャッシュファイル701aの領域705aにタイルヘッダを書き込む。次にステップS1006に進み、パケット番号に「0」を設定し、それ以後、パケットの番号順にステップS1007以下の処理を繰り返す。
【0140】
ステップS1007では、原画像のprogression order に従って、パケット番号に相当するresolution level、レイヤ、コンポーネント、並びにposition番号を特定する。次にステップS3308に進み、注目するパケットのデータ長1と、このパケットデータのオフセット値としてステップS3204で一括キャッシュファイル701aの領域706aに書き込まれたゼロレングス・パケットデータまでのオフセット値、resolution level、レイヤ、コンポーネント、position番号等の、現在注目しているパケットを管理する際に必要になる情報を、一括キャッシュファイル701aの領域802aに書き込む。
【0141】
次にステップS1009に進み、注目すべきパケットのパケット番号を一つ進め、ステップS1010において、ステップS1007からの一連の処理がタイルに含まれる全てのパケットに対して行われたかどうかを判断し、全てのパケットに関して終わったと判断したらこの動作を終了する。例えば、パケット数が「36」の場合には、ステップS1009の後のパケット番号が「36」だった場合はこの処理を終了する。
【0142】
図34は、図29のステップS2906における一括キャッシュファイル701aの上書きの処理を示すフローチャートで、前述の図12に示す処理と共通する処理ステップには同じ番号を付している。
【0143】
まずステップS1201では、キャッシュに書き込むパケットが含まれるタイル番号とパケット番号を特定する情報を取得する。次にステップS3402に進み、一括キャッシュファイル701aのファイル長(last_byte)を取得する。次にステップS3403に進み、一括キャッシュファイル701aに書かれていたこのパケットデータの長さを、受信したパケット、つまり、これからキャッシュに書き込むパケットのデータ長に書き換える。次にステップS3404に進み、一括キャッシュファイル701aで、このパケットのデータのオフセット値3002に、ステップS3402で取得したlast_byteの値を上書きする。そしてステップS3405に進み、このパケットに含まれるタイルの情報として、一括キャッシュファイル701aに書かれていた図30の領域801aのタイルのデータ長804aを再度計算して上書きをする。例えば、キャッシュに書きこむパケットのデータ長が128バイトであった場合、この一括キャッシュファイル701aでは、未受信パケットのデータ長をゼロレングス/パケットの長さである1バイトとして計算している。よって、ここで再計算されタイルのデータ長は(128−1)=127[バイト]となる。この値を既に書かれていたタイルのデータ長804aに足すことで、新たなタイルのデータ長を求める。次にステップS1206に進み、前述の図12と同様に、タイルヘッダ内のタイル長を示す部分を、ステップS3405で再計算された値で書き換える。次にステップS3407に進み、一括キャッシュファイル701aにパケットデータ3101をアペンドする。つまり、一括キャッシュファイル701aの最後尾に、このパケットデータを書き込み、このルーチンを終了する。
【0144】
以上説明した本実施の形態7に係るキャッシュ方法を用いれば、一つの画像について一つのキャッシュファイルを管理すればよいので、データの管理が煩雑になることを避けることができる。
【0145】
<実施の形態8>
本実施の形態8では、上述した実施の形態7において作成された一括キャッシュファイル701aを読み出す方法を、図面を用いて具体的に説明する。
【0146】
図35は、本発明の実施の形態8に係るユーザ端末において、一括キャッシュファイル701aを読み出す処理を示すフローチャートであり、上述した実施の形態7においてユーザ端末に作成されたキャッシュファイルを読み出す処理の詳細を示している。尚、前述の図26と同様の動作をするステップには同じ番号を付している。この図26と異なる点は、図26でメインファイルと呼ばれていたテーブルだけを格納していたキャッシュファイルを読むのではなく、実施の形態7で一括キャッシュファイルと呼んでいた、テーブルデータと共にパケットデータもキャッシュしているキャッシュファイル701aを読む点にある。従って、図35のステップS3507では、ステップS2601でオープンしたファイルからパケットデータを読み出す点が異なる。
【0147】
図36は、この実施の形態8に係る図35のステップS3507におけるパケットデータ読み出し処理を示すフローチャートである。
【0148】
まずステップS3601で、このルーチンで読み出すパケットデータに関して、図30に示すキャッシュ管理用データ802aのデータ長807a及びオフセット値3002から、パケットデータのデータ長(p_length)と一括キャッシュファイル701aの先頭から実際にキャッシュされているパケットデータの先頭までのオフセット値(p_offset)をそれぞれ取得する。次にステップS3602に進み、ステップS3601で取得したオフセット値(p_offset)とデータ長(p_length)とを基に、目的のパケットデータを読み出して、この読み出し処理を終了する。
【0149】
つまり、一括キャッシュファイル701aの先頭からオフセット値(p_offset)が示すバイトの位置までポインタを移動し、そのポインタ位置からデータ長(p_length)が示すバイト数のデータを読み出すことにより、目的のパケットデータを取得することができる。
【0150】
前述の実施の形態7で説明したキャッシュの書き込み方法と、本実施の形態8に係るキャッシュ読み込み方法を用いれば、未受信パケットデータに対応するデータが実際にキャッシュファイル701に書き込まれていれば、データ読み出しの際に未受信パケットデータか否かの条件分岐を設けることなく、全て同じ操作で、そのパケットデータを読み出すことができる
<実施の形態9>
前述の実施の形態7では、未受信パケットデータの位置にゼロレングス・パケットを挿入して、一括キャッシュファイル701aの領域706aにゼロレングス・パケットを書き込んだ。これに対して本実施の形態9では、未受信パケットデータに対応したゼロレングス・パケットのデータを実際に一括キャッシュファイル701aに書き込むのではなく、未受信であることを示す値を図30のパケットデータ管理用データ802aのオフセット値を書き込む領域3002に「NULL」を書き込む。
【0151】
このように作成したキャッシュファイル701aを読み出す際に、前述の実施の形態8と異なるのは、図35のステップS3507で示されるパケットデータの読み出し方法である。
【0152】
図37は、本発明の実施の形態9に係る、パケットデータの読み出し処理を示すフローチャートで、前述の図36と共通するステップには同じ番号を付している。この図37のフローチャートが図36のフローチャートと異なる点は、図37におけるステップS3702の条件分岐以降である。
【0153】
ステップS3702では、ステップS3601で取得したオフセット値(p_offset)が「NULL」かどうかを判断し、そうであればステップS3704に進み、NULLでなければステップS3602に進む。つまりオフセット値(p_offset)がNULLであればこのパケットは未受信であると判断されてステップS3704に進み、NULL以外の値であれば、受信されキャッシュされているパケットであると判断してステップS3602に進む。このステップS3602の処理は、前述の図36と同様の動作によりパケットデータを読み出す処理である。
【0154】
一方、ステップS3704では、未受信データであるのでキャッシュファイル701aの中にはデータが存在しないため、未受信データの代わりとなるゼロレングス・パケットデータの読み出し用バッファに書き出す。
【0155】
本実施の形態9によれば、未受信データの読み出しのためのファイルのシークが削減されるため、データ読み出しの高速化が図れる。
【0156】
上述した説明では、便宜上、全てのキャッシュファイルまたは、キャッシュファイル用フォルダを、CドライブのTempフォルダに作成したが、キャッシュファイルやキャッシュ用のフォルダが作成される場所は、これに限定されるものではなく、環境変数に応じてキャッシュファイルを作成する場所を適宜変えることも可能である。
【0157】
以上説明した画像データのキャッシュ・リード・ライト方法(即ち、実施の形態1乃至4のキャッシュファイルの作成方法、実施の形態5,6に係るキャッシュファイルの読み出し方法、実施の形態7,9に係るキャッシュファイルの作成方法、及び実施の形態8,9に係るキャッシュファイル読み出し方法)によれば、断片的な符号化データを、ユーザ端末201(又は202)において容易に管理することができ、作成したキャッシュファイルをシーケンシャルにリードすることにより、表示すべき画像の断片的な符号化データを実際には全て受信していない場合であっても、JPEG2000符号化データの形式に準拠した1つの符号化データとして読み出すことが可能になる。このため、一般的な仕様のJPEG2000デコーダを当該ユーザ端末に用意しておけば、当該ユーザ端末は、ユーザ所望の解像度の画像を表示することができる。
【0158】
また、キャッシュファイルに1枚の画像の符号化データが完全に充填されていない状態であっても、上述した如くシーケンシャルにリードした結果、ユーザ端末の一次記憶102に読み込まれる符号化データは、JPEG2000符号化データ形式に完全に準拠した符号化データであり、このキャッシュファイル用の特別なJPEG2000デコーダは必要ないという利点がある。
【0159】
更に、サーバ204から断片的に送られてくる途中に符号化データを追加する場合であっても、該当するパケットデータのファイルを置きかえることで高速に追加できるという利点がある。
【0160】
[他の実施形態]
尚、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体(または記録媒体)を、上述した画像処理装置として動作する装置に供給し、それらシステム或いは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。或いは、処理対象の画像データを外部より入手可能であって、且つディスプレイへの圧縮画像の表示までの処理であれば、パーソナル・コンピュータ等の一般的な情報処理装置においても、前述した実施形態の機能を実現するソフトウェアのプログラムコードを実行することにより、同目的は達成される。これらの場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体、並びに電気通信回線等を介してコンピュータプログラム製品として取得した当該プログラムコードは、本発明を構成することになる。
【0161】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【0162】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【0163】
【発明の効果】
以上説明したように本発明によれば、所定形式で断片化された画像データを、その所定の形式に基づいてデコードし、容易にキャッシュすることができる。
【図面の簡単な説明】
【図1】本発明の実施の形態に係る画像処理装置であるコンピュータ機器の概略構成を示すブロック図である。
【図2】本実施の形態に係る通信ネットワークの概略を示す図である。
【図3】 JPEG2000方式の符号化データの構成を示す図である。
【図4】 JPEG2000の解像度スケイラビリティを説明する図である。
【図5】本実施の形態におけるサーバ/クライアント間での通信プロトコルを説明する図である。
【図6】本発明の実施の形態1乃至6に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図7】本実施の形態において画像情報全体を管理するメインファイルのデータ構成を説明する図である。
【図8】図7に示すメインファイルに含まれるタイルデータの管理用データの構成図である。
【図9】図6のステップS603におけるメインファイルの作成処理を示すフローチャートである。
【図10】図9のステップS906におけるタイル基本情報の作成処理を示すフローチャートである。
【図11】 SOTマーカの構成を説明する図である。
【図12】図6のステップS606におけるメインファイルの上書き処理を示すフローチャートである。
【図13】サーバからのレスポンスデータの構成例を示す図である。
【図14】本実施の形態1におけるユーザ端末におけるキャッシュファイルの構成例を示す図である。
【図15】本発明の実施の形態2におけるメインファイルの作成処理を示すフローチャートである。
【図16】図15のステップS1506におけるタイル基本情報の作成処理を示すフローチャートである。
【図17】実施の形態2に係る、メインファイルの上書き処理を示すフローチャートである。
【図18】実施の形態2に係るユーザ端末におけるキャッシュファイルのデータ構成を示す図である。
【図19】本発明の実施の形態3に係るメインファイルの作成処理を示すフローチャートである。
【図20】図19のステップS1906で示すタイル基本情報の作成処理を示すフローチャートである。
【図21】実施の形態3におけるメインファイルの上書き処理(S606)を示すフローチャートである。
【図22】本発明の実施の形態4に係るパケットデータをタイル毎にフォルダに保存する例を説明する図である。
【図23】実施の形態4におけるメインファイルの作成処理を示すフローチャートである。
【図24】実施の形態4におけるキャッシュファイル構成の概念図である。
【図25】実施の形態4に係る、画像毎のキャッシュ用フォルダを示す概念図である。
【図26】本発明の実施の形態5に係る、ユーザ端末においてキャッシュファイルを読み出す処理を示すフローチャートである。
【図27】図26のステップS2607におけるパケットデータの読み出し処理を示すフローチャートである。
【図28】本発明の実施の形態6に係るパケットデータの読み出し処理を示すフローチャートである。
【図29】本発明の実施の形態7に係るユーザ端末における受信データのキャッシュ処理を示すフローチャートである。
【図30】本実施の形態7に係る一括キャッシュファイル内のパケットデータの管理用データを説明する図である。
【図31】実施の形態7に係る一括キャッシュファイル内へのパケットデータの書込み後の様子を説明する図である。
【図32】図29のステップS2903における一括キャッシュファイルの作成処理を示すフローチャートである。
【図33】図32のステップS3205におけるタイル基本情報の作成処理を示すフローである。
【図34】図29のステップS2906におけるキャッシュファイルの上書きを処理を示すフローである。
【図35】本発明の実施の形態8に係るユーザ端末において、実施の形態7で作成された一括キャッシュファイルを読み出す処理を示すフローチャートである。
【図36】実施の形態8に係る図35のステップS3507におけるパケットデータ読み出し処理を示すフローチャートである。
【図37】本発明の実施の形態9におけるパケットデータの読み出し処理を示すフローチャートである。
Claims (26)
- 通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信手段と、
前記受信手段により受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出手段と、
前記算出手段により算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成手段と、
前記ダミーデータ生成手段によって設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換手段と、
を有することを特徴とする画像処理装置。 - 前記ダミーデータ生成手段による前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成手段を更に備え、
前記データ置換手段は、前記ダミー符号化データと前記符号化データとを、前記管理ファイルを用いて記憶媒体の内部で別々の領域参照情報に基づいて管理すると共に、前記領域参照情報を書き換えることにより前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項1に記載の画像処理装置。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであることを特徴とする請求項1又は2に記載の画像処理装置。
- 前記ダミー符号化データは、前記JPEG2000方式に準拠したビットストリーム・シンタックスで規定されているzero length packetのデータであることを特徴とする請求項3に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記zero length packetのデータを前記パケット毎にそれぞれ設定することを特徴とする請求項4に記載の画像処理装置。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は、前記zero length packetのデータを、1つのキャッシュ中では1つのファイルで構成しており、前記データ置換手段は、前記パケット単位の前記符号化データを管理する前記管理ファイルのファイル名に従って前記1つのファイルを参照することを特徴とする請求項2に記載の画像処理装置。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は、前記zero length packetのデータとしてNULLを設定することを特徴とする請求項2又は6に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記符号化データの数量としての前記パケットの個数に応じて、それらパケットを複数のフォルダに分散して格納することを特徴とする請求項3に記載の画像処理装置。
- 前記ダミーデータ生成手段は、前記符号化データ毎にフォルダを生成することを特徴とする請求項3に記載の画像処理装置。
- 更に、前記データ置換手段によって置き換えがなされたキャッシュファイルをシーケンシャルに読み出すと共に、読み出したデータを前記所定形式に準拠したデコード手順に基づいてデコードするデコード手段を備えることを特徴とする請求項1乃至9のいずれか1項に記載の画像処理装置。
- 前記ダミーデータ生成手段による前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成手段を更に備え、
前記データ置換手段は、前記ダミー符号化データと前記符号化データとを、前記管理ファイルと同一のファイル内で保存すると共に、前記管理ファイル内の領域参照情報を書き換えることにより、前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項1に記載の画像処理装置。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成手段は1つのキャッシュ中では1つのzero length packetデータを生成し、
前記データ置換手段は、パケット単位の前記符号化データの保存場所を指し示すオフセット情報に従って前記zero length packetのデータを参照することを特徴とする請求項11に記載の画像処理装置。 - 通信ネットワークを介して双方通信可能に接続された外部装置からユーザ所望の画像について所定形式で断片化された符号化データを受信すると共にキャッシュする画像処理装置におけるデータキャッシュ方法であって、
前記符号化データの受信に先立って、前記外部装置から前記画像に関するヘッダデータを受信する受信工程と、
受信した前記ヘッダデータに基づいて、前記画像を構成するタイルの数量と、個々のタイルを構成するために必要な前記符号化データの数量とを算出する算出工程と、
前記算出工程で算出されたタイルのそれぞれに対して、前記符号化データの数量分だけ所定のダミー符号化データを設定するダミーデータ生成工程と、
前記ダミーデータ生成工程で設定された前記ダミー符号化データのうち、前記外部装置から実際に受信した前記符号化データに対応するダミー符号化データを、前記外部装置から受信した前記符号化データで置き換えるデータ置換工程と、を有することを特徴とする画像処理装置におけるデータキャッシュ方法。 - 前記ダミーデータ生成工程での前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成工程を更に備え、
前記データ置換工程では、前記ダミー符号化データと前記符号化データとを、前記管理ファイルを用いて記憶媒体の内部で別々の領域参照情報に基づいて管理すると共に、前記領域参照情報を書き換えることにより前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項13に記載のデータキャッシュ方法。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであることを特徴とする請求項13又は14に記載のデータキャッシュ方法。
- 前記ダミー符号化データは、前記JPEG2000方式に準拠したビットストリーム・シンタックスで規定されているzero length packetのデータであることを特徴とする請求項15に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では、前記zero length packetのデータを前記パケット毎にそれぞれ設定することを特徴とする請求項16に記載のデータキャッシュ方法。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程では、前記zero length packetのデータを、1つのキャッシュ中で1つのファイルで構成しており、前記データ置換工程では、前記パケット単位の前記符号化データを管理する前記管理ファイルのファイル名に従って前記1つのファイルを参照することを特徴とする請求項14に記載のデータキャッシュ方法。
- 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程では、前記zero length packetのデータとしてNULLを設定することを特徴とする請求項14又は18に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では、前記符号化データの数量としての前記パケットの個数に応じて、それらパケットを複数のフォルダに分散して格納することを特徴とする請求項15に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程では前記符号化データ毎にフォルダを生成することを特徴とする請求項15に記載のデータキャッシュ方法。
- 更に、前記データ置換工程で置き換えがなされたキャッシュファイルをシーケンシャルに読み出すと共に、読み出したデータを前記所定形式に準拠したデコード手順に基づいてデコードする工程を備えることを特徴とする請求項13乃至21のいずれか1項に記載のデータキャッシュ方法。
- 前記ダミーデータ生成工程における前記ダミー符号化データの設定に先立って、前記ヘッダデータに含まれる属性情報に基づいて、前記符号化データの管理ファイルを作成する管理ファイル作成工程を更に備え、
前記データ置換工程では、前記ダミー符号化データと前記符号化データとを、前記管理ファイルと同一のファイル内で保存すると共に、前記管理ファイル内の領域参照情報を書き換えることにより、前記ダミー符号化データを、前記外部装置から実際に受信した前記符号化データで置き換えることを特徴とする請求項13に記載のデータキャッシュ方法。 - 前記所定形式で断片化された符号化データは、JPEG2000方式に基づくパケット単位の符号化データであって、前記ダミーデータ生成工程は1つのキャッシュ中では1つのzero length packetデータを生成し、
前記データ置換工程は、パケット単位の前記符号化データの保存場所を指し示すオフセット情報に従って前記zero length packetのデータを参照することを特徴とする請求項23に記載のデータキャッシュ方法。 - 請求項13乃至24の何れか1項に記載のデータキャッシュ方法を実行させるようにコンピュータを動作させることを特徴とするコンピュータプログラム。
- 請求項25に記載のコンピュータプログラムを格納したことを特徴とする、コンピュータにより読み取り可能な記憶媒体。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002222021A JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
US10/231,206 US20030067627A1 (en) | 2001-08-30 | 2002-08-30 | Image processing method and its data cache method |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001261799 | 2001-08-30 | ||
JP2001-261799 | 2001-08-30 | ||
JP2002222021A JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003179760A JP2003179760A (ja) | 2003-06-27 |
JP3768934B2 true JP3768934B2 (ja) | 2006-04-19 |
Family
ID=26621313
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002222021A Expired - Fee Related JP3768934B2 (ja) | 2001-08-30 | 2002-07-30 | 画像処理装置及びそのデータキャッシュ方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3768934B2 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7711834B2 (en) | 2002-12-13 | 2010-05-04 | Ricoh Co., Ltd. | Network access to partial document images |
JP2006191159A (ja) | 2004-12-28 | 2006-07-20 | Canon Inc | 画像処理方法及び画像処理装置 |
JP4716949B2 (ja) | 2005-09-02 | 2011-07-06 | 株式会社リコー | 画像処理装置および画像処理方法 |
JP2007142614A (ja) * | 2005-11-16 | 2007-06-07 | Ricoh Co Ltd | 画像処理装置、画像処理方法、プログラム及び情報記録媒体 |
JP2009122847A (ja) | 2007-11-13 | 2009-06-04 | Ricoh Co Ltd | ファイルアクセス装置 |
-
2002
- 2002-07-30 JP JP2002222021A patent/JP3768934B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2003179760A (ja) | 2003-06-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20030067627A1 (en) | Image processing method and its data cache method | |
US6711572B2 (en) | File system for distributing content in a data network and related methods | |
US5838927A (en) | Method and apparatus for compressing a continuous, indistinct data stream | |
US8868690B2 (en) | System and method for support wireless device access to external storage | |
JP4975882B2 (ja) | コンピュータ・システムにおけるオブジェクトの別のストレージ・ロケーションへの部分的移動 | |
US7636765B2 (en) | Data transfer scheme using caching technique for reducing network load | |
KR100512388B1 (ko) | 정보전송방법및장치 | |
CN110401724B (zh) | 文件管理方法、文件传输协议服务器及存储介质 | |
US8555324B2 (en) | Video download mechanism for transferring large data | |
JP3560758B2 (ja) | データ管理方法およびそれを用いたデータ管理装置 | |
US20040003117A1 (en) | Method and apparatus for dynamic optimization and network delivery of multimedia content | |
KR100855997B1 (ko) | 전자 문서의 구성 가능한 변환 방법 | |
US20100023594A1 (en) | Content processing apparatus, content processing method, and recording medium | |
US20170010824A1 (en) | Previewing File Information Over a Network | |
JP7105675B2 (ja) | 送信装置、サーバ装置、送信方法およびプログラム | |
JP2000222088A (ja) | 情報提供サーバ,仲介サーバ,および閲覧端末 | |
US7069297B2 (en) | Data transfer scheme using re-direct response message for reducing network load | |
US20150089181A1 (en) | Use of wireless devices external storage | |
JP2007025843A (ja) | データ記憶装置及びバージョン管理プログラム | |
JP2006191159A (ja) | 画像処理方法及び画像処理装置 | |
US20020129373A1 (en) | Contents playback method and apparatus | |
JP3768934B2 (ja) | 画像処理装置及びそのデータキャッシュ方法 | |
US20190026047A1 (en) | Random file i/o and chunked data upload | |
Seshan et al. | Benefits of transparent content negotiation in HTTP | |
JP3768866B2 (ja) | 符号化データの作成方法及びその装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040611 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051122 |
|
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: 20060111 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060202 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 3768934 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120210 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140210 Year of fee payment: 8 |
|
LAPS | Cancellation because of no payment of annual fees |