(57)【要約】【課題】クライアントにキャッシュされている断片化された符号データと、サーバから必要な分だけ受信した断片化された符号データとを用いて、クライアントにおいて汎用ＪＰＥＧ２０００デコーダで使用可能な符号データを好適に作成することができる符号データ作成方法及び装置を提供する。【解決手段】クライアントは、サーバが管理する符号データのうち、第１の符号データを格納しており、ＪＰＥＧ２０００符号データの作成に必要となる符号データと第１の符号データとから、不足する第２の符号データを算出する。そして、サーバから第２の符号データを取得し、そのヘッダ情報を解析して、符号データを複数の独立した符号データに分割する。さらに、分割された単位毎に、独立した符号データの全てのデータが格納されていない場合、ダミー符号データを格納し、その符号データをＪＰＥＧ２０００符号データとする。【選択図】  図５
2004242273.tif 000002
【特許請求の範囲】
【請求項１】
サーバが管理する符号データのうち、断片的な第１の符号データを格納した格納手段を備えるクライアントにおいて、ＪＰＥＧ２０００符号データを作成する符号データ作成方法であって、
前記クライアントにおいて前記ＪＰＥＧ２０００符号データの作成に必要となる符号データと、前記格納手段に格納された前記第１の符号データとから、不足する第２の符号データを算出する算出工程と、
前記サーバに対して、算出された前記第２の符号データを要求する要求工程と、
前記サーバから、前記第２の符号データを取得する取得工程と、
取得された前記第２の符号データを前記格納手段に格納する格納工程と、
取得された前記第２の符号データのヘッダ情報を解析して、前記符号データを複数の独立した符号データに分割する分割工程と、
前記分割工程で分割された単位毎に、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されているか否かを判定する判定工程と、
前記独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納するダミー格納工程と、
前記格納手段に格納された符号データをＪＰＥＧ２０００符号データとして出力する出力工程と
を有することを特徴とする符号データ作成方法。
【請求項２】
前記判定工程によって、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されていると判定された場合、該格納手段に格納された該符号データを前記分割工程で分割された前記独立した符号データに置き換える置換工程をさらに有することを特徴とする請求項１に記載の符号データ作成方法。
【請求項３】
前記符号データが、パケット単位で取り扱われることを特徴とする請求項１又は２に記載の符号データ作成方法。
【請求項４】
前記ダミー符号データが、ＪＰＥＧ２０００で規定されているｚｅｒｏ  ｌｅｎｇｔｈ  ｐａｃｋｅｔデータであることを特徴とする請求項１から３までのいずれか１項に記載の符号データ作成方法。
【請求項５】
前記分割工程が、所定サイズのタイル単位で前記符号データを分割することを特徴とする請求項１から４までのいずれか１項に記載の符号データ作成方法。
【請求項６】
前記独立した符号データのそれぞれのヘッダ情報を前記分割工程で分割された前記タイル単位のサイズに変更する変更工程をさらに有することを特徴とする請求項１から５までのいずれか１項に記載の符号データ作成方法。
【請求項７】
前記クライアントが画像データを表示する表示手段をさらに備え、前記第１の符号データが前記画像データの符号データであって、
前記表示手段に表示された画像データの表示領域の移動又は拡大表示に応じて、前記算出工程における前記必要となる符号データを設定する設定工程と、
前記出力工程で出力された前記ＪＰＥＧ２０００符号データをデコードするデコード工程と、
デコードされた画像データを前記表示手段に画面表示する表示工程と
をさらに有することを特徴とする請求項１から６までのいずれか１項に記載の符号データ作成方法。
【請求項８】
前記判定工程によって、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されていると判定された場合、前記分割工程で分割された単位ごとに、該単位に関するメインヘッダをそのまま出力し、該単位のインデックスを所定のインデックスに置換し、該単位に含まれる符号化データ本体を前記分割工程で分割された前記独立した符号データに置き換える置換手段をさらに備えることを特徴とする請求項１に記載の符号データ作成方法。
【請求項９】
前記分割工程で分割された少なくとも２以上の単位について、前記判定工程、前記ダミー格納工程、前記置換工程及び前記出力工程を並列処理することを特徴とする請求項２に記載の符号データ作成方法。
【請求項１０】
第１のコンピュータが管理する符号データのうち、断片的な第１の符号データを格納した格納手段を備える第２のコンピュータにおける符号データ作成装置であって、
前記第１のコンピュータに管理された前記符号データのうち、断片的な第１の符号データを格納する第１の格納手段と、
前記第２のコンピュータにおいてＪＰＥＧ２０００符号データの作成に必要となる符号データと、前記格納手段に格納された前記第１の符号データとから、不足する第２の符号データを算出する算出手段と、
前記第１のコンピュータに対して、算出された前記第２の符号データを要求する要求手段と、
前記第１のコンピュータから、前記第２の符号データを取得する取得手段と、
取得された前記第２の符号データを格納する第２の格納手段と、
取得された前記第２の符号データのヘッダ情報を解析して、前記符号データを複数の独立した符号データに分割する分割手段と、
前記分割手段で分割された単位毎に、前記独立した符号データを構成する全ての符号データが前記第１又は第２の格納手段に格納されているか否かを判定する判定手段と、
前記独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納する第３の格納手段と、
前記第１、第２及び第３の格納手段に格納された符号データを用いてＪＰＥＧ２０００符号データを作成する作成手段と
を備えることを特徴とする符号データ作成装置。
【請求項１１】
前記第１及び第２のコンピュータが、ネットワークを介して互いに通信可能であることを特徴とする請求項９記載の符号データ作成装置。
【請求項１２】
第１のコンピュータが管理する符号データのうち、断片的な第１の符号データを格納した格納手段を備える第２のコンピュータに、ＪＰＥＧ２０００符号データを作成させるためのプログラムであって、
前記第２のコンピュータにおいて前記ＪＰＥＧ２０００符号データの作成に必要となる符号データと、前記格納手段に格納された前記第１の符号データとから、不足する第２の符号データを算出する算出手順と、
前記第１のコンピュータに対して、算出された前記第２の符号データを要求する要求手順と、
前記第１のコンピュータから、前記第２の符号データを取得する取得手順と、
取得された前記第２の符号データを前記格納手段に格納する格納手順と、
取得された前記第２の符号データのヘッダ情報を解析して、前記符号データを複数の独立した符号データに分割する分割手順と、
前記分割手順で分割された単位毎に、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されているか否かを判定する判定手順と、
前記独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納するダミー格納手順と、
前記格納手段に格納された符号データをＪＰＥＧ２０００符号データとして出力する出力手順と
を実行させるためのプログラム。
【請求項１３】
請求項１２記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して受信した断片的な画像データから符号データを作成する技術に関する。
【０００２】
【従来の技術】
インターネット上では、ＷＷＷサーバにＷｅｂ（ウエブ）ブラウザからアクセスして文書データや画像データ等の情報を閲覧することが盛んに行われている。このように、インターネット上に情報を公開するＷＷＷサーバと、その情報を閲覧するためのクライアントとを含むシステム環境において、各クライアントではウエブブラウザを使用して、ＷＷＷサーバによって公開された情報を閲覧することができる。
【０００３】
ＷＷＷサーバには、通常、ホームページといわれる公開するための情報をＨＴＭＬで記述した文書が保存されており、それにクライアント側のウエブブラウザがアクセスしてクライアント側のコンピュータに表示する。また、クライアント側のウエブブラウザは、表示しているページ内のリンクを辿っていくことにより、必要な情報を得ることができる。さらに、ＷＷＷサーバが管理しているファイルをダウンロードする方法として、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  （以下、「ＦＴＰ」と略す。）という方法がある。このＦＴＰとは、ネットワークを通して、ＷＷＷサーバ上にあるファイルの内容を一度にクライアント側のコンピュータに転送する仕組みのことである。
【０００４】
また、サーバが管理する画像ファイルへ断片的にアクセスして、クライアントで表示するためのプロトコルとして、Ｆｌａｓｈｐｉｘ／ＩＩＰがある。このインターネット・イメージング・プロトコル（ＩＩＰ）は、Ｆｌａｓｈｐｉｘという画像データファイルフォーマットに最適なプロトコルになっており、ネットワークを通して画像データの一部分を要求できるものである。このときのアクセスは、Ｆｌａｓｈｐｉｘのタイル単位に行われる。
【０００５】
一方、このＦｌａｓｈｐｉｘ／ＩＩＰをそのままＪＰＥＧ２０００に適用した場合を考える。ここで、ＪＰＥＧ２０００では、各スケーラビリティ（Ｓｃａｌａｂｉｌｉｔｙ）の符号データは、そのスケーラビリティより１つ下のスケーラビリティのデータとの差分データで構成されている。そこで、クライアント側で受信した断片的な符号データをキャッシュしておき、全符号データをデコーダに引き渡して最初から再デコードする方法と、デコーダを途中で止めておいて今回受信した符号データをデコーダに渡し、前回の続きからデコードする方法とがある。
【０００６】
このような方法のうち、マルチ解像度データを有する画像符号データの中から必要な部分のデータのみを取り出して別の符号データに変換する方法が従来から提案されている（例えば、特許文献１参照）。
【０００７】
上記特許文献１においてソースとなる画像データは、ウェーブレット（Ｗａｖｅｌｅｔ）変換、或いはＷａｖｅｌｅｔ−ｌｉｋｅな変換を用いて、マルチ解像度のデータを管理することが可能な符号データである。そして、このソースとなる符号データの中から、ユーザが選択した空間的な領域のデータを処理するために必要な符号データを取り出し、１つの独立した符号データに変換する方法が記載されている。尚、この時ソースの符号データから取り出される部分的な符号データは、ＪＰＥＧ２０００のコードブロックに対応しており、今回のユーザからの要求を処理するために必要な符号データを含んでいる。
【０００８】
ここで、サーバから送られてくる符号データをクライアント側で最初から再デコードする場合、それらの断片的な符号データをキャッシュのような仕組みを持たないで、直接、ＪＰＥＧ２０００準拠の１つの符号データファイルに作り直すことが可能である。
【０００９】
【特許文献１】
米国特許第６０４１１４３号明細書
【００１０】
【発明が解決しようとする課題】
しかしながら、サーバ側から送られてくる断片的な符号データは、クライアント側から要求する順に送られてくるため、クライアント側で受信した符号データをＪＰＥＧ２０００準拠の１つの符号データに変換するためには、クライアント側での煩雑な処理が必要であるという問題点がある。
【００１１】
また、サーバから送られてきた断片的な符号データを独自形式のキャッシュファイルとして構成し、クライアント側のＪＰＥＧ２０００デコーダが直接このキャッシュファイルをリードすることも可能である。しかし、この場合、ＪＰＥＧ２０００デコーダには独自のキャッシュファイルをリードするための処理が必要となり、処理が複雑になると共に、汎用のＪＰＥＧ２０００デコーダが使えないという問題点がある。
【００１２】
そこで、ＪＰＥＧ２０００符号データをパケット（ｐａｃｋｅｔ）単位で受信し、それらのｐａｃｋｅｔデータをキャッシュしておいて、デコーダへ符号データを渡す際に、まだ受信していないｐａｃｋｅｔデータ部分に、ｚｅｒｏ  ｌｅｎｇｔｈ  ｐａｃｋｅｔ（以下、「ＺＬＰ」と略す。）データを挿入し、既に受信したｐａｃｋｅｔデータとあわせて、１つのＪＰＥＧ２０００準拠の符号ファイルを作成することで、メインヘッダの書き換えなどの煩雑な処理を行わずに、一般的なＪＰＥＧ２０００デコーダで処理可能なＪＰＥＧ２０００ファイルを作成することが考えられる。
【００１３】
しかし、受信した全てのｐａｃｋｅｔデータを利用して作成された符号データは、クライアント側のアプリケーションを使っているユーザの要求した画像サイズ、画質及び画像領域等において、ユーザの望む表示形態を考慮していない。そのため、このような符号データを受け取ったデコーダでは、その一部のデータから生成されたデコード結果を利用して表示画面が作成されることがあり、キャッシュされている全ての符号データを使って１つのＪＰＥＧ２０００符号データファイルを作ることは、デコーダ自体の処理にも無駄な処理が生じるという問題がある。
【００１４】
さらに、キャッシュされている符号データが多くなるほど、デコーダへ渡す符号データを作成するときに発生するデータのコピー作業が多くなる。これは、クライアントの表示に要するまでの時間が長くなることにつながり、パフォーマンス低下という問題が生じる。特に、画像の拡大やスクロールという命令をユーザが行うことで、表示に直接必要のないキャッシュデータが多くなり、上記の問題が頻繁に起こることになる。
【００１５】
さらにまた、上記特許文献１には、以下のような問題点がある。すなわち、上記特許文献１に記載の技術をネットワークを通した通信であるＩＩＰにそのまま適用した場合、クライアントからの要求毎に全階層の全コードブロックの符号データを送ることになり、クライアント側で既に受信済みの符号データまでも送信することになる。また、送信する符号データのヘッダ部分は、今回要求した画像データの情報（例えば、画像サイズ、階層情報等）に書き換えられてしまい、サーバで管理されている符号データの本来の情報を取得することができない。
【００１６】
本発明は、このような事情を考慮してなされたものであり、クライアントにキャッシュされている断片化された符号データと、サーバから必要な分だけ受信した断片化された符号データとを用いて、クライアントにおいて汎用ＪＰＥＧ２０００デコーダで使用可能な符号データであって、当該符号データのデコード及び画像データの表示処理を高速に行うことができる符号データを好適に作成することができる符号データ作成方法及び装置を提供することを目的とする。
【００１７】
【課題を解決するための手段】
上記課題を解決するために、本発明は、サーバが管理する符号データのうち、断片的な第１の符号データを格納した格納手段を備えるクライアントにおいて、ＪＰＥＧ２０００符号データを作成する符号データ作成方法であって、
前記クライアントにおいて必要となる符号データと、前記格納手段に格納された前記第１の符号データとから、不足する第２の符号データを算出する算出工程と、
前記サーバに対して、算出された前記第２の符号データを要求する要求工程と、
前記サーバから、前記第２の符号データを取得する取得工程と、
取得された前記第２の符号データを前記格納手段に格納する格納工程と、
取得された前記第２の符号データのヘッダ情報を解析して、前記符号データを複数の独立した符号データに分割する分割工程と、
前記分割工程で分割された単位毎に、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されているか否かを判定する判定工程と、
前記独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納するダミー格納工程と、
前記格納手段に格納された符号データをＪＰＥＧ２０００符号データとして出力する出力工程と
を有することを特徴とする。
【００１８】
また、本発明に係る上記符号データ作成方法は、前記判定工程によって、前記独立した符号データを構成する全ての符号データが前記格納手段に格納されていると判定された場合、該格納手段に格納された該符号データを前記分割工程で分割された前記独立した符号データに置き換える置換工程をさらに有することを特徴とする。
【００１９】
さらに、本発明は、第１のコンピュータが管理する符号データのうち、断片的な第１の符号データを格納した格納手段を備える第２のコンピュータにおける符号データ作成装置であって、
前記第１のコンピュータに管理された前記符号データのうち、断片的な第１の符号データを格納する第１の格納手段と、
前記第２のコンピュータにおいてＪＰＥＧ２０００符号データの作成に必要となる符号データと、前記格納手段に格納された前記第１の符号データとから、不足する第２の符号データを算出する算出手段と、
前記第１のコンピュータに対して、算出された前記第２の符号データを要求する要求手段と、
前記第１のコンピュータから、前記第２の符号データを取得する取得手段と、
取得された前記第２の符号データを格納する第２の格納手段と、
取得された前記第２の符号データのヘッダ情報を解析して、前記符号データを複数の独立した符号データに分割する分割手段と、
前記分割手段で分割された単位毎に、前記独立した符号データを構成する全ての符号データが前記第１又は第２の格納手段に格納されているか否かを判定する判定手段と、
前記独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納する第３の格納手段と、
前記第１、第２及び第３の格納手段に格納された符号データを用いてＪＰＥＧ２０００符号データを作成する作成手段と
を備えることを特徴とする。
【００２０】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について詳細に説明する。
【００２１】
＜第１の実施形態＞
図１は、ネットワーク上に複数のコンピュータが接続されている様子を示す図であり、本発明の第１の実施形態に係るサーバ及びクライアントを含むネットワークシステムの構成を示す概要図である。
【００２２】
図１において、１００はインターネットに代表されるネットワークである。１０１、１０３は、ネットワーク１００に接続されているサーバ・コンピュータであり、画像データを送信するためのＪＰＥＧ２０００用のＩＩＰサーバを始めとして、ＷＷＷサーバ機能に必要なソフトウェアが実行されている。また、大量の画像データも格納されている。また、１０２ａ、１０２ｂはクライアント・コンピュータであり、ウエブブラウザやＪＰＥＧ２０００デコーダ等のクライアント側で必要なソフトウェアが実行されている。
【００２３】
図２は、図１のサーバ・コンピュータ１０１、１０３又はクライアント・コンピュータ１０２ａ、１０２ｂの各コンピュータシステムのハードウェア構成の一例を示す図である。図２において、２０１はＣＰＵであり、システム全体の制御等を行っている。２０２はキーボードであり、マウス２０１ａと共に本システムに対して情報等を入力するために使用される。また、２０３は表示部であり、ＣＲＴや液晶ディスプレイ等で構成されている。
【００２４】
一方、２０４はＲＯＭ、２０５はＲＡＭであり、本システムにおける記憶装置を構成しており、システムが実行するプログラムやシステムが利用するデータ等を記憶する。また、２０６はハードディスク装置、２０７はフレキシブルディスクであり、本システムのファイルシステムに使用される外部記憶装置を構成している。さらに、２０８はプリンタである。さらにまた、２０９はネットワークを制御する部分であり、ここからネットワーク１００（例えば、インターネット等）上に接続されているサーバ・コンピュータ等のネットワーク上の資源にアクセスする。
【００２５】
本実施形態では、既に生成済みのＪＰＥＧ２０００ファイルがサーバ・コンピュータで管理されている。一方、クライアント・コンピュータでは、画像表示アプリケーション等を用いてユーザが要求したＪＰＥＧ２０００ファイル内の必要な部分のみを、ＪＰＥＧ２０００用ＩＩＰを使用して上記サーバ・コンピュータにアクセスし、符号データを断片的に受信し、受信した断片的な符号データをクライアント・コンピュータ上の例えばハードディスク２０６等にキャッシュする。
【００２６】
以下では、ハードディスク２０６等にキャッシュされた断片的なＪＰＥＧ２０００符号データを、ＪＰＥＧ２０００のデコーダに渡すＪＰＥＧ２０００準拠の符号データに変換する部分について説明する。
【００２７】
また、ユーザは、Ｗｉｎｄｏｗｓ（登録商標）マシン等を使用してホームページを開き、そこに書かれているＪＰＥＧ２０００の画像へのリンクをクリックすることで、ＪＰＥＧ２０００の画像をユーザの用途に適した画像サイズや解像度で表示するために必要な断片的なデータを取得し、キャッシュする。そして、それらのキャッシュデータから一つのビットストリームを作り出し、デコードし、表示するという場合を想定する。
【００２８】
ここで、一般的なＪＰＥＧ２０００の符号データについて説明する。図３は、Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎ（以下、「ＳＮＲ  Ｐｒｏｇｒｅｓｓｉｏｎ」と記す。）に沿って記録されたＪＰＥＧ２０００ファイルの構成を示す概念図である。ＳＮＲ  Ｐｒｏｇｒｅｓｓｉｏｎに準じた場合、ｌａｙｅｒ／ｒｅｓｏｌｕｔｉｏｎ／ｃｏｍｐｏｎｅｎｔ／ｐｏｓｉｔｉｏｎの順に記録される。このような符号データの並び方を規定することは、「ｐｒｏｇｒｅｓｓｉｏｎ  ｏｒｄｅｒ」と呼ばれる。
【００２９】
また、図４は、ＪＰＥＧ２０００の解像度スケーラビリティを説明する図である。すなわち、解像度（画像サイズ）とＲｅｓｏｌｕｔｉｏｎ番号との関係を示すための図である。図４では、最も小さい解像度の画像のｒｅｓｏｌｕｔｉｏｎ番号を０とし、ｒｅｓｏｌｕｔｉｏｎ番号が１つ増加するごとに画像の幅と高さが２倍になっていく。また、各ｌａｙｅｒ内は、ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。そして、Ｌａｙｅｒ番号は、復元する画像の原画に対するＳ／Ｎ比に対応しており、ｌａｙｅｒ番号が小さいほどＳ／Ｎ比が悪くなる。
【００３０】
さらに、１つのＪＰＥＧ２０００ファイル内でのｒｅｓｏｌｕｔｉｏｎ番号、ｌａｙｅｒ番号及びｃｏｍｐｏｎｅｎｔ番号の最大値は、エンコーダによって予め設定されており、そのパラメータに従ってエンコードされており、その情報は符号データの中に格納されている。また各ｐａｃｋｅｔは、そのｐａｃｋｅｔ内に格納されているｃｏｄｅ−ｂｌｏｃｋの情報を管理しているｐａｃｋｅｔ  ｈｅａｄｅｒ部と、各ｃｏｄｅ−ｂｌｏｃｋの符号データとから構成されている。
【００３１】
このようなＪＰＥＧ２０００符号データを使うことによって、ユーザは、サーバにある全ての画像データを取得する必要がなく、クライアント側で表示等するために必要な部分の符号データのみをサーバから受信すればよい。尚、ユーザ側（クライアント・コンピュータ）の受信データの単位としては、ＪＰＥＧ２０００のｐａｃｋｅｔ、或いはｐａｃｋｅｔよりも更に小さい符号化単位であるコードブロック単位が考えられる。本実施形態では、ユーザがサーバから受信するデータ単位としてｐａｃｋｅｔ単位を想定する。
【００３２】
図５は、第１の実施形態におけるサーバとクライアント間でのｐａｃｋｅｔ単位のデータのリクエスト及びレスポンスを説明するための概念図である。
【００３３】
図５において、クライアント５０１はサーバ５０２に画像のタイル番号、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌと、ｌａｙｅｒ、ｃｏｍｐｏｎｅｎｔ、ｐｏｓｉｔｉｏｎ番号を指定して必要なデータを要求する。そして、サーバ５０２は、画像５０３のコードストリームを解析して、指定された画像のタイル番号、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌとｌａｙｅｒ、ｃｏｍｐｏｎｅｎｔ、ｐｏｓｉｔｉｏｎ番号に相当するｐａｃｋｅｔデータを抜き出してクライアント５０１に送り返す。
【００３４】
次に、図６Ａ及び図６Ｂを用いて本実施形態で使用するサーバ・コンピュータで管理されているＪＰＥＧ２０００ファイルの一例について説明する。図６Ａは、サーバ・コンピュータに格納されている原画像データをタイルに分割した例を示す図である。図６Ａでは、縦横とも各々４つのタイル、すなわち画像全体で１６個のタイルに分割した例が示されている。
【００３５】
また、図６Ｂは、図６Ａで示したタイル分割された画像データに関するＪＰＥＧ２０００符号データ（すなわち、当該画像データを「ＳＮＲ  Ｐｒｏｇｒｅｓｓｉｏｎ」でエンコードしたデータ）のデータ構造を示す図である。図６Ｂに示される符号データは、ｌａｙｅｒは０〜２の３種類（Ｌａｙ０、Ｌａｙ１、Ｌａｙ２）、ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌは、０〜３の４種類（Ｒｅｓ０、Ｒｅｓ１、Ｒｅｓ２、Ｒｅｓ３）、ｃｏｍｐｏｎｅｎｔとｐｏｓｉｔｉｏｎは各１種類（Ｃｏｍ０、Ｐｏｓ０）である場合のＪＰＥＧ２０００で符号化した時の符号データの構成例である。
【００３６】
例えば、ＪＰＥＧ２０００の最大解像度の画像サイズを１０２４×１０２４画素とした場合、各タイルの画像サイズは２５６×２５６画素となる。また、各タイルが４種類のｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌを持つ場合の各解像度での画像サイズは、２５６×２５６、１２８×１２８、６４×６４、３２×３２画素となる。
【００３７】
さらに、ＪＰＥＧ２０００符号データ内のメインヘッダ部分については、図６Ｂに示すように、画像サイズを示すパラメータであるＸｓｉｚ、Ｙｓｉｚが共に１０２４であり、画像全体の画像サイズを示している。一方、タイルのサイズを示すＸＴｓｉｚ、ＹＴｓｉｚは、上述したタイルのサイズである２５６の値を持っている。これらのパラメータにより、このＪＰＥＧ２０００符号データは、１６個のタイルに分割された符号データを有することになる。そして、これらの各タイルの符号データが、図６Ｂに示すように「Ｔｉｌｅ  ｐａｒｔ  Ｈｅａｄｅｒ」で区切られて格納されている。
【００３８】
図７は、第１の実施形態におけるクライアント・コンピュータ上のアプリケーションでの処理手順の概要を説明するためのフローチャートである。本実施形態においては、クライアント側では、ＪＰＥＧ２０００画像表示アプリケーションが起動しており、図７に示されるフローチャートは、表示したいＪＰＥＧ２０００ファイルをウエブ等の別の手段で指定した後、画像を表示する部分の処理フローである。
【００３９】
まず、これからの処理を制御するための内部変数（パラメータ）を初期化する（ステップＳ７０７）。具体的には、指定されているＪＰＥＧ２０００ファイルの画像サイズや、エンコード・パラメータ等の情報をサーバに対して問い合わせ、図１３に示すこれから表示する符号化データのキャッシュを管理するための情報をメモリやファイル上に作成し、その変数（パラメータ）等を初期化する。すなわち、図１３は、クライアント側で制御している符号データのキャッシュの論理構造を説明するための図である。図１３において、１３００は、キャッシュファイル全体の論理構造であり、図に示すように、キャッシュ全体に関する画像管理情報フィールド１３０２、Ｍａｉｎ  ｈｅａｄｅｒ  ｄａｔａフィールド１３０３、各Ｔｉｌｅに関するデータフィールド１３０１に分けることができる。
【００４０】
ここで、Ｔｉｌｅに関するデータフィールド１３０１には、この画像データをＴｉｌｅ分割した時のＴｉｌｅの個数分のフィールドが存在する。１３０４は、Ｔｉｌｅに関するデータのフィールド１３０１の詳細を示したものである。この中には、Ｔｉｌｅデータ管理用データフィールド１３０４ａ、Ｔｉｌｅ  ｈｅａｄｅｒフィールド１３０４ｂ、ｐａｃｋｅｔデータ管理用データ１３０４ｃに分けられる。尚、ｐａｃｋｅｔデータ管理用データフィールド１３０４ｃは、Ｔｉｌｅ内に存在するｐａｃｋｅｔの個数分のフィールドがある。
【００４１】
次に、Ｔｉｌｅデータ管理用データフィールド１３０４ａの詳細を１３０５に示す。Ｔｉｌｅデータ管理用データフィールド１３０４ａは、１３０５に示すように、Ｔｉｌｅのデータ長１３０５ａ、Ｔｉｌｅ番号１３０５ｂ、ｐａｃｋｅｔ数１３０５ｃ、Ｒｅｓｏｌｕｔｉｏｎ数１３０５ｄ、Ｌａｙｅｒ数１３０５ｅ、Ｃｏｍｐｏｎｅｎｔ数１３０５ｆ、Ｐｏｓｉｔｉｏｎ数１３０５ｇの各パラメータから成る。
【００４２】
さらに、ｐａｃｋｅｔデータの管理用データ１３０４ｃの詳細を１３０６に示す。ｐａｃｋｅｔデータの管理用データ１３０４ｃは、１３０６に示すように、ｐａｃｋｅｔのデータ長１３０６ａ、ポインタ値１３０６ｂ、ｐａｃｋｅｔ番号１３０６ｃ、ｐａｃｋｅｔの基本情報１３０６ｄから成る。サーバから受信した実際のｐａｃｋｅｔのデータは、ポインタ値１３０６ｂで示すポインタの先に保存される。
【００４３】
図１３からも分かるように、ｐａｃｋｅｔデータをフル充填した場合は、テーブルを管理するための情報等が数多く存在するため、サーバで管理している元の符号データのバイト数よりも大きくなってしまう。すなわち、クライアント側では、このキャッシュ情報と、キャッシュ情報から１つの符号データを生成するため、クライアント側で管理する符号データ関連のバイト数は、全タイルがフル充填されたときに最大となり、その時のサイズは、サーバで管理している元の符号データのサイズの２倍以上になる。尚、これらの各Ｔｉｌｅに関するデータ１３０４は、ファイルに格納され、１３００内の１３０１で示すフィールドには、ファイル名で該当するデータと関連付けを行っているものとする。
【００４４】
ステップＳ７０７で内部変数が初期化された後、ユーザが表示のための操作を行う（ステップＳ７００）。例えば、アプリケーション起動時の指定されたファイルの１回目の表示では、開いたウィンドウサイズに収まる画像サイズを計算して、当該ウィンドウサイズに一致する画像サイズで表示するようにする。そして、その後に本ステップＳ７００でユーザの操作を受け付けるようにしてもよい。
【００４５】
次に、上記ステップＳ７００でのユーザ操作により新たに必要になったｐａｃｋｅｔを全て算出する（ステップＳ７０１）。その後、ステップＳ７０１で算出した新規に必要となったｐａｃｋｅｔのデータについてサーバに対して要求を発行する（ステップＳ７０２）。次いで、要求した全ｐａｃｋｅｔのデータをサーバから受信し、クライアント・コンピュータ上にキャッシュする（ステップＳ７０３）。
【００４６】
さらに、高速読み出しが可能なようにキャッシュ形式で管理している符号データを複数のＪＰＥＧ２０００符号データ形式に変換することによって符号データの作成を行う（ステップＳ７０４）。この符号データの作成処理の詳細については後述する。その後、ステップＳ７０４で作成したＪＰＥＧ２０００符号データをデコードして表示する（ステップＳ７０５）。そして、ユーザが終了を要求したか否かを判定する（ステップＳ７０６）。その結果、ユーザが終了を要求した場合（Ｙｅｓ）、本アプリケーションを終了する。一方、ユーザが終了を要求せずに他の表示要求を行った場合（Ｎｏ）、ステップＳ７０１に戻って上記処理を実行する。
【００４７】
以下では、上記クライアント・コンピュータ上のアプリケーションでの処理手順の具体的な処理内容について説明する。
【００４８】
まず、クライアント・アプリケーションが起動した直後で、このアプリケーションの初期画像表示サイズを１２８×１２８画素とし、このサイズに入る画像データを表示することを考える。この場合、ステップＳ７０２で算出される必要なｐａｃｋｅｔは、最低解像度の画像サイズであってＳＮＲが最大のデータを表示することを考えると、図６Ｂ内のタイル０からタイル１５までの全１６タイルにおける、「Ｌａｙ０／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ１／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ２／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」で示す３×１６個のｐａｃｋｅｔが必要なｐａｃｋｅｔである。
【００４９】
そこで、クライアント・プログラムは、これらのｐａｃｋｅｔをサーバ・プログラムに要求する。一方、サーバ・プログラムは、この全タイルの３×１６個のｐａｃｋｅｔを切り出す処理を行う。その後、クライアント・プログラムは、これらのｐａｃｋｅｔを受信した後デコードして表示を行う。
【００５０】
次に、図７のステップＳ７０４における符号データ作成についての詳細な説明を図８〜１０を用いて行う。図８Ａは、図７におけるステップＳ７０４符号データ作成処理の概要を説明するためのフローチャートである。まず、サーバから受信した必要なｐａｃｋｅｔに関するＪＰＥＧ２０００符号データのメインヘッダを解析する（ステップＳ８００）。次に、ステップＳ８００におけるメインヘッダを解析した結果から、符号データ内のタイルの個数を計算する（ステップＳ８０１）。本実施形態においては、タイルの個数の計算は、以下に示す式（１）で行うものとする。
【００５１】
Ｘｔｉｌｅｓ  ＝  （Ｘｓｉｚ  ＋  ＸＴｓｉｚ  −  １）  ／  ＸＴｓｉｚ
Ｙｔｉｌｅｓ  ＝  （Ｙｓｉｚ  ＋  ＹＴｓｉｚ  −  １）  ／  ＹＴｓｉｚ          （１）
Ｔｉｌｅｓ    ＝      Ｘｔｉｌｅｓ  ×  Ｙｔｉｌｅｓ
そして、式（１）で求められたタイルの個数だけ、ステップＳ８０２以下の処理が行われる。
【００５２】
ステップＳ８０２は、各タイルの符号変換処理を行う部分である。この処理の詳細については後述する。そして、全タイルについての符号変換処理が終了したか否かを判断する（ステップＳ８０３）。その結果、未処理のタイルがある場合（Ｎｏ）、ステップＳ８０２に戻る。一方、全タイルについて符号変換処理が終了した場合（Ｙｅｓ）、本処理を終了してステップＳ７０５に進む。
【００５３】
図８Ｂは、ステップＳ８０２における符号変換処理を詳細に説明するためのフローチャートである。まず、今回処理するタイルがフル充填、すなわち全ｐａｃｋｅｔデータがキャッシュされているか否かを判断する（ステップＳ８０４）。具体的には、図１３に示すｐａｃｋｅｔのデータ長１３０６ａ、或いはｐａｃｋｅｔデータへのポインタ値１３０６ｂを見ることで判断できる。これらの値は、未受信の場合は「０」であり、ｐａｃｋｅｔデータを受信すると、ｐａｃｋｅｔデータのバイト数や、実際に格納されているアドレス或いはファイル名等の各値が格納される。これにより、このタイル内の全てのｐａｃｋｅｔに対して、データ長１３０６ａ或いはポインタ値１３０６ｂの値を判断し、各値が「０」でなければフル充填であると判断できる。逆に、１つでも「０」の値が存在すれば、まだフル充填ではないと判断することができる。その結果、フル充填されている場合（Ｙｅｓ）、ステップＳ８０５に進み、それ以外の場合（Ｎｏ）、ステップＳ８０７に進む。
【００５４】
ステップＳ８０５では、フル充填状態の符号データを作成したか否かを判断する。その結果、まだ作成されていない場合（Ｎｏ）はステップＳ８０６に進み、作成済みの場合（Ｙｅｓ）は当該符号変換処理を終了する。ステップＳ８０６では、完全符号データを作成したことを示すフラグをセットする。当該フラグのセットに係る処理の詳細については後述する。そして、実際のキャッシュデータから符号データを作成する「符号ファイル作成」処理が行われる（ステップＳ８０７）。この符号ファイル作成処理の詳細については後述する。
【００５５】
ここで、図８のステップＳ８０６の詳細な処理内容について説明する。図１４は、図８のステップＳ８０６の完全符号データ作成済を示すフラグのセットを詳細に説明するためのフローチャートである。この処理は比較的容易であり、まず、フル充填されたタイルのＴｉｌｅデータ管理用データ１３０４のファイルを削除する（ステップＳ１４００）。これにより、図１３で示すＴｉｌｅに関するデータ１３０４、Ｔｉｌｅデータの管理用データ１３０５、Ｐａｃｋｅｔデータの管理用データ１３０６の領域が削除される。次に、図１１等で示すタイル毎の符号データファイルに置き換えて完全符号データをセットする（ステップＳ１４０１）。すなわち、完全符号データ作成済を示すフラグのセットとは、図１３に示す１３００内の１３０１で示すＴｉｌｅに関するデータの値を変更することである。
【００５６】
上記処理を行うことにより、当該処理後にクライアントのアプリケーションがこのタイルのデータを必要とするときは、１３０１で示すフィールドに格納されているファイル名をアプリケーションに渡すだけでよく、データ変換等の処理は全く発生せず、高速に行うことができる。さらに、キャッシュとして保持しなければならないデータ量が、管理テーブルの形で保持する場合よりも符号データを直接持つことになるため、データ容量的に小さくて済む。
【００５７】
また、タイルがフル充填されているか否かの判断は、キャッシュとして保持されているＴｉｌｅのデータ長のフィールド１３０５ａを確認すればよい。図１５は、タイルがフル充填されて完全な符号データに置き換わった時の状態を示す図である。具体的な確認方法は、図１５に示されるフィールドを１６ビット長の整数のフィールドとする場合、フル充填されて置き換えた場合は、符号データの先頭１６ビットになる。この場合、符号データの先頭は、ＳＯＣマーカ・コード（０ｘＦＦ４Ｆ）であり、整数でこの値を読むと先頭のビット（１５ビット目）が”１”であるので、負の値になる。３２ビット長の整数としても結果は同じであり、ＳＯＣマーカ・コード、ＳＩＺマーカ・コードであるので、（０ｘＦＦ４ＦＦＦ５１）である。すなわち、Ｔｉｌｅデータの管理用データの先頭を必要なビット数の整数としてリードした場合、正の整数の場合はまだ充填中であり、負の整数の場合は、フル充填で符号データに変換済みであると容易に判断することができる。
【００５８】
上述したように、１度フル充填されたキャッシュデータから符号ファイルを生成した後は、再度符号ファイル作成処理（ステップＳ８０７）を行わないように制御することにより、キャッシュが充填されて行くに連れて、符号ファイル作成処理を高速に行うことができる。
【００５９】
図９は、図８に示すステップＳ８０７の符号ファイル作成処理を詳細に説明するためのフローチャートである。まず、タイルに含まれるｐａｃｋｅｔの数をｉＰＭａｘにセットする（ステップＳ９００）。次に、「Ｔｉｌｅ  ｐａｒｔ  Ｈｅａｄｅｒ」を仮出力する（ステップＳ９０１）。ここで仮出力するのは、この「Ｔｉｌｅ  ｐａｒｔ  Ｈｅａｄｅｒ」にはタイルの符号長を格納するフィールドがあり、このタイルの符号長は以下の処理を終了した時点で計算できる値であるためである。
【００６０】
次に、変数ｉＰ、ｉＬに初期値として「０」をセットする（ステップＳ９０２、Ｓ９０３）。ここで、変数ｉＰはｐａｃｋｅｔのＩＤを示す変数であり、変数ｉＬはタイルの符号長を示す変数である。次に、変数ｉＰで示されるｐａｃｋｅｔがキャッシュされているか否かを判断する（ステップＳ９０４）。その結果、変数ｉＰがキャッシュされている場合（Ｙｅｓ）はステップＳ９０５へ進み、変数ｉＰがキャッシュされていない場合（Ｎｏ）はステップＳ９０７に進む。
【００６１】
ステップＳ９０７では、該当するｐａｃｋｅｔデータが無いことを示す「Ｚｅｒｏ  Ｌｅｎｇｔｈ  Ｐａｃｋｅｔ」のコード（以下、「ＺＬＰコード」と略す。）を出力する。そして、このＺＬＰコードのバイト数である「１」を変数ｉＬに加える（ステップＳ９０８）。一方、ステップＳ９０５では該当するｐａｃｋｅｔのデータを出力する。そして、そのバイト数を変数ｉＬに足し込んで更新する（ステップＳ９０６）。
【００６２】
ステップＳ９０６及びＳ９０８の処理の後、変数ｉＰをインクリメントする（ステップＳ９０９）。そして、全ｐａｃｋｅｔについて処理したかを判断する（ステップＳ９１０）。その結果、まだ全ｐａｃｋｅｔを処理していない場合（Ｎｏ）、ステップＳ９０４に戻って上記処理を行う。一方、全ｐａｃｋｅｔを処理した場合（Ｙｅｓ）、変数ｉＬから「Ｔｉｌｅ  ｐａｒｔ  Ｈｅａｄｅｒ」である「ＳＯＴマーカ」を更新して出力し（ステップＳ９１１）、当該符号ファイル生成処理を終了する。そして、前述したように当該符号ファイルを汎用のＪＰＥＧ２０００デコーダでデコードし、デコードされた画像データを表示する（ステップＳ７０５）。
【００６３】
すなわち、上述したように、本実施形態に係るクライアントは、サーバが管理する符号データのうち、断片的な第１の符号データを格納した格納手段（例えば、ハードディスク２０６）を備え、ＪＰＥＧ２０００符号データを作成する符号データ作成装置として機能する。本実施形態に係るクライアントでは、まず、当該クライアントにおいてＪＰＥＧ２０００符号データの作成に必要となる符号データと、予めハードディスク２０６等の格納手段に格納された第１の符号データ（例えば、現在表示部２０３に表示されている画像データについての符号データ）とから、不足する第２の符号データ（例えば、表示部２０３で拡大表示するために必要な画像データについての符号データであって、第１の符号データには含まれていないもの）を算出する。そして、サーバに対して、算出された第２の符号データを要求し、サーバから、第２の符号データを取得し、取得された第２の符号データをハードディスク２０６等の格納手段に格納する。次いで、取得された第２の符号データのヘッダ情報を解析して、対象となる符号データを複数の独立した符号データに分割する。さらに、分割された単位毎に、独立した符号データを構成する全ての符号データがハードディスク２０６等の格納手段に格納されているか否かを判定する。そして、独立した符号データを構成する全ての符号データが格納されていない場合、格納されていない部分にダミー符号データを格納し、格納された符号データをＪＰＥＧ２０００符号データとして出力することを特徴とする。
【００６４】
また、上記クライアント（符号データ作成装置）では、符号データが、パケット単位で取り扱われることを特徴とする。さらに、上記クライアント（符号データ作成装置）では、ダミー符号データが、ＪＰＥＧ２０００で規定されているｚｅｒｏ  ｌｅｎｇｔｈ  ｐａｃｋｅｔデータであることを特徴とする。さらにまた、上記サーバとクライアントが、ネットワークを介して互いに通信可能であることを特徴とする。
【００６５】
さらに、上記クライアント（符号データ作成装置）は、画像データを表示する表示手段（例えば、表示部２０３）をさらに備え、上記第１の符号データが当該画像データの符号データであって、表示部２０３等の表示手段に表示された画像データの表示領域の移動又は拡大表示に応じて、上記第２の符号データの算出において必要となる符号データを設定する。また、上記クライアント（符号データ作成装置）は、出力された上記ＪＰＥＧ２０００符号データをしてデコードし、デコードされた画像データを表示部２０３等の表示手段に画面表示することを特徴とする。
【００６６】
ここで、具体例を用いて、上記フローチャートで示した符号ファイル作成処理を説明する。図１０は、本発明の第１の実施形態における初期画面での符号ファイル処理後の各タイルの符号ファイルの構成を示す図である。ここで、クライアント・コンピュータから要求されるｐａｃｋｅｔは、前述のとおり全タイルの「Ｌａｙ０／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ１／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ２／Ｒｅｓ０／Ｃｏｍ０／Ｐｏｓ０」である。
【００６７】
従って、図１０に示すように、全１６個のタイルに対して、符号１００１で示すように上記３つのｐａｃｋｅｔデータ以外のｐａｃｋｅｔについてはＺＬＰが格納された符号データが作成される。また、各タイル毎に作成される符号データのメインヘッダ部分は、メインヘッダ内のＳＩＺマーカコード内のＸｓｉｚ、Ｙｓｉｚの各フィールドがタイルのサイズである２５６に変更されている。これにより、各タイル毎に独立した符号ファイルを作成することができる。
【００６８】
すなわち、本実施形態に係るクライアント（符号データ作成装置）では、符号データ（画像データ）を所定サイズのタイル単位（例えば、式（１）に記載の方法で算出された単位）で分割することを特徴とする。また、同クライアントでは、独立した符号データのそれぞれのヘッダ情報を、分割されたタイル単位のサイズに変更することを特徴とする。
【００６９】
次に、ステップＳ７０１でユーザから拡大表示が指示された場合について説明する。この拡大表示では、まず初期画面より２倍に拡大するものとする。この場合、表示ウィンドウサイズは１２８×１２８画素であるとすると、表示できるタイルは４個になる。例えば、図６Ａに示すＴｉｌｅ５、Ｔｉｌｅ６、Ｔｉｌｅ９、Ｔｉｌｅ１０の４個のタイルのＲｅｓｏｌｕｔｉｏｎ１（画像サイズ：６４×６４画素）を表示するものとする。この場合、ステップＳ７０２では、Ｔｉｌｅ５、Ｔｉｌｅ６、Ｔｉｌｅ９、Ｔｉｌｅ１０の４つのタイルの「Ｌａｙ０／Ｒｅｓ１／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ１／Ｒｅｓ１／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ２／Ｒｅｓ１／Ｃｏｍ０／Ｐｏｓ０」がクライアント・コンピュータからサーバに対して要求される。
【００７０】
さらに、ユーザから２倍に拡大する要求が発行された場合、表示ウィンドウサイズを１２８×１２８画素から２５６×２５６画素に変更すると、上記４タイルに対してさらに、「Ｌａｙ０／Ｒｅｓ２／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ１／Ｒｅｓ２／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ２／Ｒｅｓ２／Ｃｏｍ０／Ｐｏｓ０」が要求される。
【００７１】
その後、さらに、２倍に拡大する要求がユーザからあったとする。この場合、表示領域のウィンドウサイズを変更しないとすると、タイルが１つ分しか表示することができない。そこで、Ｔｉｌｅ５のみを表示するとすると、Ｔｉｌｅ５の「Ｌａｙ０／Ｒｅｓ３／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ１／Ｒｅｓ３／Ｃｏｍ０／Ｐｏｓ０」、「Ｌａｙ２／Ｒｅｓ３／Ｃｏｍ０／Ｐｏｓ０」をサーバに要求し表示することになる。これにより、Ｔｉｌｅ５は完全にキャッシュが充填されたことになる。図１１は、第１の実施形態における符号データの各タイル毎の符号ファイルの状態の一例を説明するための図である。
【００７２】
図１１に示すように、Ｔｉｌｅ０、Ｔｉｌｅ１、Ｔｉｌｅ２、Ｔｉｌｅ３、Ｔｉｌｅ４、Ｔｉｌｅ７、Ｔｉｌｅ８、Ｔｉｌｅ１１、Ｔｉｌｅ１２、Ｔｉｌｅ１３、Ｔｉｌｅ１４及びＴｉｌｅ１５の各タイルの符号ファイルは、図１０に示したものと同様に符号１００１で示す状態になっている。また、Ｔｉｌｅ６、Ｔｉｌｅ９及びＴｉｌｅ１０の各タイルは符号１１０１に示す状態に、Ｔｉｌｅ５は符号１１０２に示す状態になっている。この状態になるまでは、ステップＳ８０５における完全符号データを作成済みか否かの判断により全てステップＳ８０６に進むようになるが、Ｔｉｌｅ５の符号変換処理後はステップＳ８０５の判断後、ステップＳ８０６には進まずに処理を終了するようになる。これにより、Ｔｉｌｅ５については、これ以降、符号変換処理を行う必要がなくなる。これにより、キャッシュが充填されるほど符号ファイル作成処理を高速にすることができる。すなわち、本実施形態によれば、デコード／表示する領域をタイル単位で行う場合、デコード／表示に必要なタイルのみに対して処理を行うことができる。
【００７３】
また、従来は、キャッシュファイルから１つのＪＰＥＧ２０００符号データファイルを生成する場合、表示するタイル毎のマルチスレッド化は困難であった。これは、１つの符号データファイルを生成するため、ここで処理をシリアライズすることが必須であったためである。しかし、本実施形態のように各タイル毎の符号データファイルを生成することにより、表示するタイル毎に必要なｐａｃｋｅｔ要求からキャッシュファイルの生成、キャッシュファイルから符号データの作成、符号データのデコード及び表示までを各タイル毎スレッドとしてマルチスレッド化することができる。従って、これまでのシングルスレッドの場合に比べて、マルチスレッド化することによる高速化も図ることができる。
【００７４】
さらに、ファイルＩ／Ｏの処理時間がかかるようなシステムにおいては、１つの大きな符号データファイルを作成する代わりに、小さな複数の符号ファイルを生成することで、ファイルＩ／Ｏによる時間のロスを最小限にすることも可能となる。
【００７５】
＜第２の実施形態＞
上述した第１の実施形態では、キャッシュされている全てのタイルに対して符号変換処理を行うことを説明したが、本実施形態では、表示に必要な部分のタイルのみ符号変換処理を行うことにより、第１の実施形態よりもさらに高速に符号変換処理を行う場合について説明する。
【００７６】
図１２は、本発明の第２の実施形態に係る符号データ作成処理の概要を説明するためのフローチャートである。尚、上述した第１の実施形態における図８Ａのフローチャートと同じ処理の部分には同一の番号を付けている。ここでは、第１の実施形態と異なる部分のみを説明する。
【００７７】
ステップＳ８０１のタイル個数の計算の後、ステップＳ７０１でユーザが操作したコマンドを解析する（ステップＳ１２００）。そして、この解析結果を使用して、これから処理しようとしているタイルが今回の表示で表示されるタイルか否かを判断する（ステップＳ１２０１）。その結果、ここで表示に使用しないタイルであると判断された場合（Ｎｏ）、ステップＳ８０３に進む。一方、表示に使用するタイルであると判断された場合（Ｙｅｓ）、ステップＳ１２０２に進む。
【００７８】
ステップＳ１２０２では、ステップＳ７０３で新たにｐａｃｋｅｔを要求した場合に、今回処理しようとしているタイルのｐａｃｋｅｔを取得したか否かを判断する。その結果、新規ｐａｃｋｅｔを取得している場合（Ｙｅｓ）はステップＳ８０２に進み、新規ｐａｃｋｅｔを取得していない場合（Ｎｏ）はステップＳ８０３に進む。尚、これ以降の処理手順については、第１の実施形態で説明した手順と同様である。これらの処理により、表示に必要なタイルであって、まだ完全に充填されていないタイルのみ符号変換処理を行うことができるため、当該符号化処理を第１の実施形態よりも高速に行うことができる。
【００７９】
＜第３の実施形態＞
以下、本発明の第３の実施形態に係る画像データ送信装置について、図面を参照して、詳細に説明する。本実施形態では、キャッシュから１本の符号データを作成する方法について説明する。尚、本実施形態に係るサーバ及びクライアントを含むネットワークシステムの構成は図１と同様であり、各コンピュータシステムのハードウェア構成も図２と同様である。また、クライアントコンピュータ上のアプリケーションでの処理手順についても図７に示すフローチャートと同様である。
【００８０】
図１６は、キャッシュから１本の符号データファイルを作成する場合の処理手順を説明するためのフローチャートである。図１６に示すように、まず、キャッシュ内のフィールド１３０３で保持している情報をＪＰＥＧ２０００符号データ形式に則った形式に変換し、出力ファイルにメインヘッダ（Ｍａｉｎ  Ｈｅａｄｅｒ）を出力する（ステップＳ１６００）。次に、メインヘッダを解析した結果から、符号データ内のタイルの個数を計算する（ステップＳ１６０１）。尚、この際の計算式は、図８のステップＳ８０１の場合と同様である。そして、以下では、前述した式（１）で求められたタイルの個数だけ、ステップＳ１６０２以下の処理が行われる。
【００８１】
そして、各タイルごとに、当該タイルがフル充填しており、タイルの完全な符号データがあるか否かを判断する（ステップＳ１６０２）。尚、この判断方法は、前述の通りである。その結果、フル充填されていると判断された場合（Ｙｅｓ）、ステップＳ１６０４へ進み、フル充填されていない場合（Ｎｏ）、ステップＳ１６０３へ進む。
【００８２】
ステップ１６０３では、図９に示す符号ファイルの作成処理手順と同様にして符号ファイルを作成する。そして、この処理後はステップＳ１６０６へ移り、符号データを出力する。一方、ステップＳ１６０４以降では、タイルの完全な符号データからの変換が行われる。そこで、まず、メインヘッダ部分を読み飛ばす処理が行われる（ステップＳ１６０４）。この処理の具体例としては、例えば、図１５に示す符号データの先頭からＳＯＴマーカ・コードまでを読み飛ばせばよい。次に、タイルパートヘッダ（Ｔｉｌｅ  ｐａｒｔ  Ｈｅａｄｅｒ）内のタイルインデックス（Ｔｉｌｅ  Ｉｎｄｅｘ）の値を当該タイルのインデックス（Ｉｎｄｅｘ）番号に置き換える（ステップＳ１６０５）。さらに、タイルパートヘッダ以降ＥＯＣマーカ・コードまで（但し、ＥＯＣマーカ・コードは含まない）をコピーする（ステップＳ１６０６）。そして、全タイルを処理したかどうかを判断し（ステップＳ１６０７）、未処理の場合（Ｎｏ）はステップＳ１６０２に戻って上記処理を繰り返す。一方、全タイルが処理された場合（Ｙｅｓ）は終了する。
【００８３】
上述した処理によって、本実施形態に係る形式でのキャッシュファイルから、１本の符号データを簡単に、且つ、データ変換等の処理がないため高速に作成することができる。
【００８４】
＜その他の実施形態＞
一般に、キャッシュファイルから１つのＪＰＥＧ２０００符号データファイルを生成する場合には、表示するタイル毎のマルチスレッド化は困難であった。なぜならば、１つの符号データファイルを生成するために、処理をシリアライズすることが必須であったからである。しかし、上述したように、各タイル毎の符号データファイルを生成することにより、表示のタイル毎に必要なｐａｃｋｅｔ要求から、キャッシュファイルの生成、キャッシュファイルからの符号データの作成、符号データのデコード、表示までを各タイル毎スレッドとしてマルチスレッド化を行うことができる。そのため、これまでのシングルスレッドの場合に比べて、マルチスレッド化することによる高速化も図ることができる。
【００８５】
尚、本発明は、複数の機器（例えば、ホストコンピュータ、インタフェース機器、リーダ、プリンタ等）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置等）に適用してもよい。
【００８６】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８７】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００８８】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【００８９】
以上説明したように、本発明による上記実施形態で説明したファイル作成方法を用いれば、ＩＩＰを用いて送られてくるＪＰＥＧ２０００符号化データの断片的なデータをキャッシュし、このキャッシュファイルから通常のＪＰＥＧ２０００デコーダで処理できるＪＰＥＧ２０００符号化データを作る時に、今回のデコード及び表示に必要なタイル毎に独立したＪＰＥＧ２０００符号データファイルを生成することで、デコード／表示までの処理を高速に行うことができる。
【００９０】
また、キャッシュを構成するための、或いはキャッシュから符号データを生成するためのデータ容量或いはファイル容量を最小限に抑えることが可能になる。さらに、キャッシュから符号データを生成する時も、データ変換等の処理を省略することができるため、高速に生成することができる。
【００９１】
また、デコード／表示する領域をタイル単位で行う時、デコード／表示に必要なタイルのみに対して処理を行うことができる。さらに、マルチスレッド化による高速化も行うことができる。さらにまた、ファイルＩ／Ｏの処理時間がかかるようなシステムにおいては、１つの大きな符号データファイルを作る代わりに、小さな複数の符号ファイルを生成することで、ファイルＩ／Ｏによる時間のロスを最小限にすることも可能となる。あるいは、１つの符号データを作成するときでも、容易に変換を行うことができる。
【００９２】
【発明の効果】
以上説明したように、本発明によれば、クライアントにキャッシュされている断片化された符号データと、サーバから必要な分だけ受信した断片化された符号データとを用いて、クライアントにおいて汎用ＪＰＥＧ２０００デコーダで使用可能な符号データであって、当該符号データのデコード及び画像データの表示処理を高速に行うことができる符号データを好適に作成することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るサーバ及びクライアントを含むネットワークシステムの構成を示す概要図である。
【図２】図１のサーバ・コンピュータ１０１、１０３又はクライアント・コンピュータ１０２ａ、１０２ｂの各コンピュータシステムのハードウェア構成の一例を示す図である。
【図３】Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ  ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ  ｐｒｏｇｒｅｓｓｉｏｎ（ＳＮＲ  Ｐｒｏｇｒｅｓｓｉｏｎ）に沿って記録されたＪＰＥＧ２０００ファイルの構成を示す概念図である。
【図４】ＪＰＥＧ２０００の解像度スケーラビリティを説明する図である。
【図５】第１の実施形態におけるサーバとクライアント間でのｐａｃｋｅｔ単位のデータのリクエスト及びレスポンスを説明するための概念図である。
【図６Ａ】サーバ・コンピュータに格納されている原画像データをタイルに分割した例を示す図である。
【図６Ｂ】図６Ａで示したタイル分割された画像データに関するＪＰＥＧ２０００符号データのデータ構造を示す図である。
【図７】第１の実施形態におけるクライアント・コンピュータ上のアプリケーションでの処理手順の概要を説明するためのフローチャートである。
【図８Ａ】図７におけるステップＳ７０４符号データ作成処理の概要を説明するためのフローチャートである。
【図８Ｂ】ステップＳ８０２における符号変換処理を詳細に説明するためのフローチャートである。
【図９】図８に示すステップＳ８０７の符号ファイル作成処理を詳細に説明するためのフローチャートである。
【図１０】本発明の第１の実施形態における初期画面での符号ファイル処理後の各タイルの符号ファイルの構成を示す図である。
【図１１】第１の実施形態における符号データの各タイル毎の符号ファイルの状態の一例を説明するための図である。
【図１２】本発明の第２の実施形態に係る符号データ作成処理の概要を説明するためのフローチャートである。
【図１３】クライアント側で制御している符号データのキャッシュの論理構造を説明するための図である。
【図１４】図８のステップＳ８０６の完全符号データ作成済を示すフラグのセットを詳細に説明するためのフローチャートである。
【図１５】タイルがフル充填されて完全な符号データに置き換わった時の状態を示す図である。
【図１６】キャッシュから１本の符号データファイルを作成する場合の処理手順を説明するためのフローチャートである。
【符号の説明】
５０１  サーバ
５０２  クライアント
【図１】
2004242273.tif 000003
【図２】
2004242273.tif 000004
【図３】
2004242273.tif 000005
【図４】
2004242273.tif 000006
【図５】
2004242273.tif 000007
【図６Ａ】
2004242273.tif 000008
【図６Ｂ】
2004242273.tif 000009
【図７】
2004242273.tif 000010
【図８Ａ】
2004242273.tif 000011
【図８Ｂ】
2004242273.tif 000012
【図９】
2004242273.tif 000013
【図１０】
2004242273.tif 000014
【図１１】
2004242273.tif 000015
【図１２】
2004242273.tif 000016
【図１３】
2004242273.tif 000017
【図１４】
2004242273.tif 000018
【図１５】
2004242273.tif 000019
【図１６】
2004242273.tif 000020