(57)【特許請求の範囲】
【請求項１】
画像データが符号化された符号データであり所定の分解単位により部分符号に分解可能な符号データの全部又は一部を復号して表示手段に表示させる画像処理装置であって、
前記部分符号を記憶する第１記憶手段と、
前記部分符号が前記符号データの分解されたいずれの部分であるのかを特定するための第１情報と、前記部分符号と依存関係にある他の部分符号を示す依存符号と、前記部分符号の優先度と、を含む属性情報を前記部分符号毎に記憶する第２記憶手段と、
前記部分符号を情報処理装置から受信する受信手段と、
前記第１記憶手段の空き容量が所定の容量を超えるか否かを判断し、該所定の容量を超えると判断した場合、受信した前記部分符号を前記第１記憶手段に記憶し、該所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記第１記憶手段に記憶される前記部分符号を前記優先度に基づいて削除した後に、受信した前記部分符号を前記第１記憶手段に記憶する記憶制御手段と、
受信した前記部分符号と依存関係にある前記依存符号を特定する特定手段と、
受信した前記部分符号を前記記憶制御手段が前記第１記憶手段に記憶させるとき、当該部分符号に対応する前記優先度を設定すると共に、前記特定手段が特定した前記依存符号によって示される部分符号に対応する前記優先度を設定する設定手段とを備える
ことを特徴とする画像処理装置。
【請求項２】
前記優先度は、前記部分符号が前記第１記憶手段に記憶されたとき及び前記第１記憶手段に記憶される前記部分符号がアクセスされたときの時間に応じて、前記時間が古いほど低い優先度を示し、
前記設定手段は、前記部分符号が前記第１記憶手段に記憶されたとき及び前記部分符号が前記第１記憶手段においてアクセスされたときの時間に基づいて、前記部分符号に対応する前記優先度及び当該部分符号と依存関係にある前記依存符号によって示される部分符号に対応する前記優先度を設定することを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記記憶制御手段は、前記所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記優先度に基づいて前記第１記憶手段に記憶されている部分符号の内アクセス時間の古い部分符号から順に削除することによって、より低い優先度に対応する部分符号を前記第１記憶手段から削除する
ことを特徴とする請求項２に記載の画像処理装置。
【請求項４】
前記特定手段は、前記部分符号を復号する際に必要な他の部分符号を前記依存符号として特定する
ことを特徴とする請求項１乃至請求項３のいずれか一項に記載の画像処理装置。
【請求項５】
前記符号データは、ＪＰＥＧ２０００により符号化されたデータであり、
前記所定の分解単位は、タイル、コンポーネント、解像度、プレシンクト及びレイヤののうち少なくとも１つである
ことを特徴とする請求項１乃至請求項４のいずれか一項に記載の画像処理装置。
【請求項６】
前記符号データは、前記タイル、コンポーネント、解像度及びプレシンクトの各単位により前記部分符号に分解可能であり、
前記第１情報は、前記部分符号が属する前記タイル、コンポーネント及びプレシンクトと、当該部分符号の解像度とを特定するための情報であり、
前記特定手段は、前記部分符号に対応する前記属性情報に含まれる前記第１情報によって特定される前記タイル及び前記コンポーネントが同じで且つ前記解像度よりも低い解像度を特定する他の前記第１情報を含む他の前記属性情報に対応する他の部分符号を前記依存符号として特定する
ことを特徴とする請求項５に記載の画像処理装置。
【請求項７】
画像データが符号化された符号データであり所定の分解単位により部分符号に分解可能な符号データの全部又は一部を復号して表示手段に表示させる画像処理方法であって、
前記部分符号を情報処理装置から受信する受信ステップと、
前記部分符号を記憶する第１記憶手段の空き容量が所定の容量を超えるか否かを判断し、該所定の容量を超えると判断した場合、受信した前記部分符号を前記第１記憶手段に記憶し、該所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記第１記憶手段に記憶される前記部分符号を前記優先度に基づいて削除した後に、受信した前記部分符号を前記第１記憶手段に記憶する記憶制御ステップと、
受信した前記部分符号と依存関係にある前記依存符号を特定する特定ステップと、
受信した前記部分符号を前記記憶制御手段が前記第１記憶手段に記憶させるとき、当該部分符号に対応する前記優先度を設定すると共に、前記特定手段が特定した前記依存符号によって示される部分符号に対応する前記優先度を設定する設定ステップとを含む
ことを特徴とする画像処理方法。
【請求項８】
請求項７に記載された画像処理方法をコンピュータで実行させることを特徴とする画像処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の分解単位により部分符号に分割可能な符号データの全部又は一部を復号して表示手段に表示させる画像処理装置、画像処理方法及び画像処理プログラムに関するものである。
【背景技術】
【０００２】
従来、インターネットでは、クライアントは、ＷＷＷサーバにアクセスすることで、ＷＷＷサーバ内に存在するＷｅｂページのデータをダウンロードし、ブラウザを用いて文書や画像を表示することができる。ユーザは、このように表示された文書や画像を閲覧することができる。このようなインターネットの技術では、一度ダウンロードしたＷｅｂページ内の文書や画像のデータを、クライアントに備わる記憶装置に一時的に記憶し、ユーザから再度閲覧の要求があった場合には、ＷＷＷサーバからダウンロードする代わりに記憶装置に記憶したデータ（キャッシュデータ）を再利用するキャッシュシステムがある。このキャッシュシステムにより、高速かつ効率の良い閲覧が可能になる。
【０００３】
しかし、記憶装置の容量には限界がある。このため、キャッシュシステムは、キャッシュデータの合計容量が所定の容量を超える場合には、不必要なキャッシュデータを削除する機能も有する。
【０００４】
ところで、クライアントがＷＷＷサーバからデータをダウンロードして文書や画像の表示を可能とする方法の一つにJPIP(JPEG2000 Interactive Protocol)がある。これはISO/IEC 15444-9に準拠したJPEG2000という画像符号化方式により画像データを符号化した符号データを送受信するためのプロトコルであり、この符号データの空間的位置だけでなく解像度やあるレイヤの部分符号を指定して、符号データの特定の部分に任意にアクセスできるという特徴を持つ。
【０００５】
このようなプロトコルを利用して受信した符号データをキャッシュに記憶する場合、不必要となった部分符号をキャッシュから削除する際には、符号データの特徴を考慮して削除しなければ、キャッシュに記憶された部分符号をより効率的に再利用することはできない。なぜならば、例えば異なる解像度に分解された部分符号は、その部分符号よりも低い解像度の部分符号からの差分を表すものになっている。このため、部分符号を表示のために復号する際により低い解像度の部分符号が必要となる。即ち、低い解像度の部分符号をキャッシュから削除してしまうと、高解像度の部分符号のみをキャッシュに記憶していても、この高解像度の部分符号を復号することができない恐れがある。
【０００６】
例えば、特許文献１の技術ではJPEG2000により画像データを符号化した符号データをパケットデータとして受信してキャッシュに記憶する際、キャッシュの合計容量が制限を越えてしまう場合に、削除するデータ量を算出し、算出されたデータ量分のレイヤをパケットデータの最後尾から削除してその残りのデータをキャッシュに記憶する。つまり、特許文献１の技術では、高解像度の部分符号を削除して残りの部分符号をキャッシュに記憶する。
【０００７】
【特許文献１】特開2003-224704号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、特許文献１の技術においては、異なる画像の符号データから分解された部分符号をどのような優先順位でキャッシュに記憶するのかについては考慮されておらず、また低解像度、低レイヤから高解像度、高レイヤの順番でキャッシュに記憶するため、特定の高解像度の部分符号のみを読み出す場合にコストがかかるという問題があった。また、高レイヤ部分を追加でキャッシュに記憶する場合に低レイヤ部分も重複して再記憶しなくてはならない問題があった。
【０００９】
本発明は、上記に鑑みてなされたものであって、所定の分割単位により符号データから分解された部分符号のキャッシュからの削除をより効果的に行うことが可能な画像処理装置、画像処理方法及び画像処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、画像データが符号化された符号データであり所定の分解単位により部分符号に分解可能な符号データの全部又は一部を復号して表示手段に表示させる画像処理装置であって、前記部分符号を記憶する第１記憶手段と、前記部分符号が前記符号データの分解されたいずれの部分であるのかを特定するための第１情報と、前記部分符号と依存関係にある他の部分符号を示す依存符号と、前記部分符号の優先度と、を含む属性情報を前記部分符号毎に記憶する第２記憶手段と、前記部分符号を情報処理装置から受信する受信手段と、前記第１記憶手段の空き容量が所定の容量を超えるか否かを判断し、該所定の容量を超えると判断した場合、受信した前記部分符号を前記第１記憶手段に記憶し、該所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記第１記憶手段に記憶される前記部分符号を前記優先度に基づいて削除した後に、受信した前記部分符号を前記第１記憶手段に記憶する記憶制御手段と、受信した前記部分符号と依存関係にある前記依存符号を特定する特定手段と、受信した前記部分符号を前記記憶制御手段が前記第１記憶手段に記憶させるとき、当該部分符号に対応する前記優先度を設定すると共に、前記特定手段が特定した前記依存符号によって示される部分符号に対応する前記優先度を設定する設定手段とを備えることを特徴とする。
【００１２】
請求項２にかかる発明は、請求項１にかかる発明において、前記優先度は、前記部分符号が前記第１記憶手段に記憶されたとき及び前記第１記憶手段に記憶される前記部分符号がアクセスされたときの時間に応じて、前記時間が古いほど低い優先度を示し、前記設定手段は、前記部分符号が前記第１記憶手段に記憶されたとき及び前記部分符号が前記第１記憶手段においてアクセスされたときの時間に基づいて、前記部分符号に対応する前記優先度及び当該部分符号と依存関係にある前記依存符号によって示される部分符号に対応する前記優先度を設定することを特徴とする。
【００１３】
請求項３にかかる発明は、請求項２にかかる発明において、前記記憶制御手段は、前記所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記優先度に基づいて前記第１記憶手段に記憶されている部分符号の内アクセス時間の古い部分符号から順に削除することによって、より低い優先度に対応する部分符号を前記第１記憶手段から削除することを特徴とする。
【００１５】
請求項４にかかる発明は、請求項１乃至請求項３のいずれか一項にかかる発明において、前記特定手段は、前記部分符号を復号する際に必要な他の部分符号を前記依存符号として特定することを特徴とする。
【００１６】
請求項５にかかる発明は、請求項１乃至請求項４のいずれか一項にかかる発明において、前記符号データは、ＪＰＥＧ２０００により符号化されたデータであり、前記所定の分解単位は、タイル、コンポーネント、解像度、プレシンクト及びレイヤののうち少なくとも１つであることを特徴とする。
【００１７】
請求項６にかかる発明は、請求項５にかかる発明において、前記符号データは、前記タイル、コンポーネント、解像度及びプレシンクトの各単位により前記部分符号に分解可能であり、前記第１情報は、前記部分符号が属する前記タイル、コンポーネント及びプレシンクトと、当該部分符号の解像度とを特定するための情報であり、前記特定手段は、前記部分符号に対応する前記属性情報に含まれる前記第１情報によって特定される前記タイル及び前記コンポーネントが同じで且つ前記解像度よりも低い解像度を特定する他の前記第１情報を含む他の前記属性情報に対応する他の部分符号を前記依存符号として特定することを特徴とする。
【００１８】
請求項７にかかる発明は、画像データが符号化された符号データであり所定の分解単位により部分符号に分解可能な符号データの全部又は一部を復号して表示手段に表示させる画像処理方法であって、前記部分符号を情報処理装置から受信する受信ステップと、前記部分符号を記憶する第１記憶手段の空き容量が所定の容量を超えるか否かを判断し、該所定の容量を超えると判断した場合、受信した前記部分符号を前記第１記憶手段に記憶し、該所定の容量を超えないと判断した場合、受信した前記部分符号を前記第１記憶手段に記憶するために必要な容量に応じて、前記第１記憶手段に記憶される前記部分符号を前記優先度に基づいて削除した後に、受信した前記部分符号を前記第１記憶手段に記憶する記憶制御ステップと、受信した前記部分符号と依存関係にある前記依存符号を特定する特定ステップと、受信した前記部分符号を前記記憶制御手段が前記第１記憶手段に記憶させるとき、当該部分符号に対応する前記優先度を設定すると共に、前記特定手段が特定した前記依存符号によって示される部分符号に対応する前記優先度を設定する設定ステップとを含むことを特徴とする。
【００１９】
請求項８にかかる発明は、画像処理プログラムであって、請求項７に記載された画像処理方法をコンピュータで実行させることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、第１記憶手段に記憶された部分符号のより効果的な削除を実現することを可能にすることができる。
【発明を実施するための最良の形態】
【００２１】
以下に添付図面を参照して、この発明にかかる画像処理装置、画像処理方法及び画像処理プログラムの最良な実施の形態を詳細に説明する。
【００２２】
[第１の実施の形態]
（１）構成
図１は、本実施の形態にかかる画像処理システムの構成を例示する図である。画像処理システムは、サーバ１と、クライアント２とから構成される。サーバ１は、符号化された画像データをクライアント２にネットワークＮＴを介して送信する。ここでは、サーバ１とクライアント２との間の通信は、ISO/IEC 15444-9 に準拠したJPIP(JPEG2000 Interactive Protocol)というプロトコルを用いて行うものとする。ネットワークＮＴは、例えば、ＬＡＮ、イントラネット、イーサネット（登録商標）又はインターネットなどである。
【００２３】
クライアント２は、ＣＰＵ（Central Processing Unit）と、各種プログラムや各種データを記憶するＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）などから構成される記憶部と、通信部と、これらを接続するバス（いずれも図示せず）とを備え、表示装置及びキーボードやマウス等の入力装置（いずれも図示せず）が接続された構成となっている。表示装置は、ＣＲＴ（Cathode Ray Tube）や液晶モニタなどである。操作装置は、ユーザからの操作が入力される操作キーや操作ボタン、マウスなどを備える。クライアント２のＣＰＵが記憶部に記憶された各種プログラムを実行することにより、クライアント２において各種機能が実現される。また、クライアント２は、データを一時的に記憶するキャッシュ（図示せず）を有する。このキャッシュは、上述したＲＡＭなどの記憶部により実現されるものであっても良いし、ファイルとしてＨＤＤなどに記憶されるものであっても良い。
【００２４】
サーバ１は、ＣＰＵと、各種プログラムや各種データを記憶するＲＯＭ、ＲＡＭ、ＨＤＤなどから構成される記憶部と、通信部と、これらを接続するバス（いずれも図示せず）とを備える。サーバ１のＣＰＵが記憶部に記憶された各種プログラムを実行することにより、サーバ１において各種機能が実現される。また、サーバ１の記憶部は、JPEG2000の画像符号化方式により画像を符号化した画像符号を記憶する。また、記憶部は、クライアント２の有するキャッシュに関する情報をキャッシュモデルとして記憶する。
【００２５】
ここで、JPEG2000の画像符号化方式について簡単に説明する。符号化対象の画像は色空間変換やDCレベルシフトが行われた後に、独立して符号化が行われるタイルの単位に領域が分割される。図２は、このタイル分割を例示する図である。同図においては、このタイル分割によって、タイル「０」〜「３」の各タイルコンポーネントに分割されている。以降、各タイルコンポーネントのデータをタイルデータという。この後タイルコンポーネント毎に、サブバンド解像度分解が行われる。図３は、サブバンド解像度分解を例示する図である。サブバンド解像度分解は、ウェーブレット変換を施した後に「ＨＨ」,「ＨＬ」,「ＬＨ」,「ＬＬ」成分ともに１／２ダウンサンプリングされて並べ替えられる。次に解像度分解をするときには、「ＬＬ」成分のみを対象として同様に行う。この結果、例えば解像度分解を２回行うと、同図に示されるように、「１ＨＬ」,「１ＬＨ」,「１ＨＨ」,「２ＨＬ」,「２ＬＨ」,「２ＨＨ」,「ＬＬ」に分けられる。同図において、数字は分解レベルを表していて、数字が小さい程高い解像度の部分の符号を表すことになる。また、これら解像度毎に「ＨＨ」,「ＨＬ」,「ＬＨ」（最低解像度のみ「ＬＬ」）の成分があり、これらの成分をサブバンド、成分中の係数をサブバンド係数と呼ぶ。
【００２６】
次にタイルコンポーネントの各解像度のサブバンド係数は、プレシンクトと呼ばれるかたまりの単位に分割される。プレシンクトは、タイル、コンポーネント、解像度ごとに異なる大きさを取ることができる。以降、プレシンクトの単位のデータをプレシンクトデータという。図４は、プレシンクト分割を例示する図である。各プレシンクトには、後述するプレシンクトインデックスが付与されている。例えば、図２におけるサブバンドの成分LLは、プレシンクトインデックス「０」〜「３」の各プレシンクトに分割される。プレシンクト分割は、JPIPのような、サーバ１及びクライアント２間で表示に必要な符号のみを送受信する場合に有効である。サーバ１及びクライアント２間の送受信については後述する。
【００２７】
また、プレシンクトはさらに、レイヤという単位に分割され、ビットプレーン分割によって、上位ビットプレーンから順番に、画像の品質を向上させる画像符号の一部となる。図５は、レイヤ分割を例示する図である。尚、原画像を符号化した画像符号といい、画像符号の一部の符号を部分符号という。
【００２８】
図６は、部分符号としてタイルデータが画像符号のうちのどのような意味を表すのかという情報を示した図である。タイルは色の成分を表すいくつかのコンポーネント(=component)、ウェーブレット変換の段階を表すいくつかの解像度(=resolution)、ウェーブレット変換されたサブバンドの空間的位置を表すいくつかのプレシンクト(=precinct)、そしてウェーブレット変換された係数ビットの品質を表すいくつかのレイヤ(=layer)に分解される。最後にパケット(=packet)とは、それらを任意に細かく分割した最小の単位である。
【００２９】
サーバ１からクライアント２に送信される符号は基本的にパケットの集まりで表される。パケットは、さらにタイルごとにまとめられ、タイルパートを形成する。符号の先頭には、その符号を復号する上で必要な情報を含んだメインヘッダと、タイルを復号する上で必要な情報を含んだタイルパートヘッダとが付与される。このタイルパートヘッダには、パケットがどのようなプログレッションオーダで並んでいるかという情報が書かれている。この情報と、それぞれの符号の区切りを表すマーカとを検出することで、クライアントでは、画像を構成する全部の符号（画像符号）又は一部の符号（部分符号）を記憶することが可能となる。また同時に、パケットやタイルパートといった部分符号が属している固有の属性（コンポーネント、解像度、プレシンクト、レイヤ）を特定することができるため、このような属性をテーブルなどにより記憶することが好ましい。図７は、各属性を記憶するための属性テーブル（第１情報）のデータ構成を例示する図である。同図においては、画像名、タイル番号、コンポーネントの番号、解像度、プレシンクト位置及びレイヤの番号の各属性が記憶されることが示されている。プレシンクト位置とは、タイルコンポーネント中のプレシンクトの通し番号のことである。ちなみに属性の各値は変化しない。
【００３０】
また、サーバ１からクライアント２に送信する符号の単位は、上述したタイル単位とプレシンクト単位との２種類がある。いずれの単位を用いても良いが、ここでは、プレシンクト単位を用いる。オリジナルのプレシンクトデータを表すものはデータビン(data-bin)と呼ばれる。尚、プレシンクトデータを表すデータビンをプレシンクトデータビンというものとする。一度のレスポンスで送信するプレシンクトデータは、オリジナルのプレシンクトデータを全て送信するとは限らず、オリジナルのプレシンクトデータの一部を送信することもある。これはメッセージ(message)と呼ばれる。
【００３１】
図８は、原画像をJPEG2000符号化方式により符号化した画像符号であるJPEG2000ファイル、データビン、メッセージ及びサーバからクライアントに符号として送信するコードストリームの関係を示す図である。図９は、データビンとメッセージとを例示する図である。メッセージは、メッセージヘッダ（図示せず）とメッセージボディとから構成される。メッセージヘッダには、そのメッセージボディがどのプレシンクトデータビン中の何バイト目から何バイト目までのデータなのかを表す情報が含まれている。このため、クライアントがメッセージを受け取ると、ただちにプレシンクトデータビン毎にデータを記憶できる。即ち、クライアントは、画像符号から分解された任意の部分符号にアクセス可能である。
【００３２】
例えば、図４に示されるようにプレシンクト分割された場合において、クライアント２がサーバ１に、原画像を４×４の１６つの領域に分けたうちの、真ん中の部分のみを解像度レベル２でサーバに要求したとする。このときサーバ１は、真ん中の部分のみを表示するために必要最低限のプレシンクトデータを送れば良い。この例の場合、まず解像度レベル３のデータは送信する必要が無い。解像度レベル２の係数に関しては、真ん中のプレシンクト「９」,「１０」，「１３」，「１４」のデータのみを送信すればよい。続いて、解像度レベル１に関しては、解像度レベル２の係数は解像度レベル１のデータからの差分をウェーブレット変換したものなので、重なっている領域のプレシンクトデータが必要となってくる。つまり、解像度レベル１に関しては「０」から「３」の全てのプレシンクトデータを送信しなくてはならない。
【００３３】
このように、プレシンクトデータなどの部分符号には、復号の際に必要となる別の部分符号が存在することがある。この例では、同じ場所(Position)の、低解像度の部分符号が必要になっている。逆に、このようにプレシンクトデータ「０」，「１」,「２」,「３」,「９」,「１０」，「１３」，「１４」を受信して記憶しているものが、さらに４×４の１６つに分けた領域の真ん中を最高解像度で表示しようとすると、今度は既に送信したものは送らずに、不足分のプレシンクトデータのみを送信すれば良い。つまり解像度レベル３の「２５」，「２６」，「２９」，「３０」のプレシンクトデータのみを送れば良い。
【００３４】
以上の性質から、JPIPでは、クライアントが既に受信した符号を記憶するキャッシュの記憶容量が所定の容量を超えて、いずれかの部分符号を削除しなくてはならない場合、他の部分符号に依存された部分符号よりも、他の部分符号に依存している部分符号を削除した方が良いことが分かる。
【００３５】
次に、サーバ１からクライアント２に送信されキャッシュに記憶される部分符号を、クライアント２がどのようなデータ構造で管理するかについて説明する。図１０はプレシンクト単位で部分符号を送受信する場合のキャッシュ内のデータ構造を表しており、またキャッシュ内の部分符号がファイル形式で記憶される場合のデータ構造を例示する図である。クライアント２は、サーバから送信された部分符号を受信すると、当該部分符号に含まれる情報に基づいて、図１０に示されるデータ構造により当該部分符号をキャッシュに記憶する。尚、キャッシュ内の部分符号はファイル形式で管理されるのではなく、記憶部におけるメモリアドレスなどにより管理されても良い。
【００３６】
同図においては、最上位層に、キャッシュデータを記憶するためのフォルダ（ＪＰＩＰクライアントキャッシュフォルダ）があり、その下位層に画像名毎に異なるフォルダ（lena.jp2,fountaiin.jp2,mandrill.jp2）が作られている。更に、画像名毎のフォルダの下位層に、画像符号を復号する際に必要な情報を持つメインヘッダのファイル及びプレシンクト毎のファイルが作られる。メインヘッダとは、JPEG2000方式で符号化されたコードストリームにおけるメインヘッダを表しており、クライアント２は、メインヘッダ内のマーカを読むことで、画像のオリジナルサイズや、タイルサイズ、参照グリッドにおけるオフセット、プログレッションオーダなどを取得することができる。また、メインヘッダの他に、タイルパートヘッダ（タイルヘッダ）を格納したファイルが作られることがある。このタイルパートヘッダは、画像符号をタイルパートの単位に区切った場合の、それぞれのタイルパートの復号に必要な情報を持っている。プレシンクト毎のファイルは、ファイル名として一意なプレシンクトのインデックスを持ち、ファイル中には部分符号としてプレシンクトデータが格納されている。
【００３７】
また、最上位層のフォルダ直下には、キャッシュデータの情報を管理するためのキャッシュデータ管理ファイルが作られている。このため、該当するプレシンクトデータビンを格納したファイルが存在するか否かの判断が容易になる。また、クライアント２は、サーバから送信された部分符号を受信すると、当該部分符号に含まれる情報に基づいてキャッシュデータ管理ファイルの情報を更新する。このためキャッシュデータの情報を常に最新の状態で管理することができる。
【００３８】
図１１は、キャッシュデータ管理ファイルのデータ構成を例示する図である。同図に示されるキャッシュデータ管理ファイル２１は、プレシンクトデータビン毎に、画像名及びプレシンクトインデックス（プレシンクトＩＤ）の各属性を含み、キャッシュデータ管理ファイル２１では、このプレシンクトＩＤをキーにして一意に各プレシンクトデータビンを識別できる。なぜなら、プレシンクトＩＤは、後述するように、タイル番号、コンポーネント番号、解像度及びプレシンクト位置から算出されるからである。即ち、プレシンクトＩＤによりこれらの各属性を識別可能であり、これらの各属性が記憶された上述の図７に示した属性テーブルにより各プレシンクトデータビンを識別することができるからである。尚、画像名は、異なるサーバ１からダウンロードした符号をキャッシュに同時に蓄える場合、サーバ１のホスト名、サーバ１におけるパス名及びファイル名を画像名とするようにしても良い。
【００３９】
更に、本実施の形態においては、キャッシュデータ管理ファイル２１は、これらの属性に加え、プレシンクトデータビン毎に、依存先プレシンクトＩＤと、タイムスタンプ（第２情報）との各属性を含む。これらの属性は、キャッシュの記憶容量が所定の容量を超えるときに削除すべきキャッシュデータを特定するために用いられる。タイムスタンプはそれぞれのデータがアクセスされた時（つまり記憶された時と取得された時に常に）に更新されるもので、アクセスされた瞬間の時間（アクセス時間）を表す。この時間は例えばＯＳ（オペレーションシステム）の内部クロック（図示せず）を使って、ある日時ある時刻からの絶対経過秒などで表すことができる。また、ＯＳの機能として、キャッシュデータ管理ファイル２１自体にタイムスタンプが付与される場合は、タイムスタンプをその時点の日時、時刻で上書きすることのできるＯＳの命令があるので、これを利用しても良い。このタイムスタンプにより各プレシンクトデータビンは順序付けることができる。
【００４０】
依存先プレシンクトＩＤとは、依存先プレシンクト（依存符号）のプレシンクトインデックスを表すものである。依存先プレシンクトとは、表示対象のプレシンクトデータを復号する際に必要となる他のプレシンクトデータであり、当該依存先プレシンクトが復号されなければ画像を正しく表示できない関係にあるプレシンクトデータである。
【００４１】
尚、依存先プレシンクトを特定するのは、例えば、クライアント２がサーバ１からプレシンクトデータを受信しキャッシュに記憶させるときである。ここで、クライアント２が、あるプレシンクトデータが依存する他のプレシンクトデータを特定する機能について説明する。ここでは、依存先プレシンクトは、同じ画像符号から分解されたタイルパートで、コンポーネントが同じで、受信したプレシンクトデータより解像度の低いプレシンクトデータである。
【００４２】
これが依存先の部分符号であるのは、次のことに起因する。図４に示すように、画像に対してウェーブレット変換を行うごとにウェーブレット変換を施した回数に応じた分解レベルのサブバンドが作成され、それぞれのサブバンドは一つ下の分解レベルのサブバンドの差分となっている。例えば分解レベル１のサブバンド(「１ＨＨ」,「１ＨＬ」,「１ＬＨ」)が分解レベル２のサブバンド(「２ＨＨ」,「２ＨＬ」,「２ＬＨ」)と分解レベル３のサブバンド(「３ＨＨ」,「３ＨＬ」,「３ＬＨ」,「３ＬＬ」)との差分となっている。ちなみに分解レベル３のサブバンドが最も低解像度の部分符号である。このことは、高解像度に画像を復号する場合には、低解像度の部分符号が必要であることを表している。
【００４３】
以上のような構成において、クライアント２において実現される機能的構成について説明する。クライアント２の機能的構成は、受信部と、特定部と、更新部と、記憶制御部とを有する。受信部は、サーバ１からプレシンクトデータを受信する。記憶制御部は、上述したキャッシュの記憶容量が所定の容量を超えていない場合、当該プレシンクトデータをキャッシュに記憶する。特定部は、当該プレシンクトデータのメインヘッダを用いて属性テーブル(図７参照)を参照し、当該プレシンクトデータと同じ画像符号から分解されたタイルパートで、コンポーネントが同じで、解像度の低いプレシンクトデータを検索して、サーバ１から受信したプレシンクトデータの依存先プレシンクトを特定する。そして、特定部は、キャッシュデータ管理ファイル２１(図１１参照)において、この依存先プレシンクトのプレシンクトインデックスを、サーバ１から受信したプレシンクトデータの依存先プレシンクトとして記憶する。更新部は、受信したプレシンクトデータ及び依存先プレシンクトとして特定したプレシンクトデータのタイムスタンプをキャッシュデータ管理ファイル２１において更新する。また、記憶制御部は、キャッシュの記憶容量が所定の容量を超える場合、キャッシュデータ管理ファイル２１のタイムスタンプに基づいて、キャッシュに記憶されたプレシンクトデータを削除した後、サーバ１から受信したプレシンクトデータをキャッシュに記憶する。
【００４４】
（２）動作
次に、JPIP(JPEG2000 Interactive Protocol)を用いたサーバ１及びクライアント２の動作の概要を説明する。図１２は、JPIPを用いたサーバ１及びクライアント２の動作の概要を示すシーケンスチャートである。JPIPは、サーバ１及びクライアント２間で、クライアント２が、サーバ１に記憶された画像に対する表示要求を行い、それに対してサーバ１が表示に必要な部分符号を返す、という一連のシーケンスを繰り返すプロトコルである。
【００４５】
クライアント２は、表示対象の画像を指定する指定情報をサーバ１に送信し、サーバ１とクライアント２とでキャッシュ２０とキャッシュモデル１０とを対応付けるためのチャネルと呼ばれるリンクを生成する(ステップＳ１)。サーバ１はチャネルのＩＤをクライアント２に返す(ステップＳ２)。今後この画像に関するキャッシュ２０及びキャッシュモデル１０の情報は、チャネルを通じてやりとりされる。チャネルは、通信が切断されるまで又はチャネルを閉じるまで存続する。
【００４６】
クライアント２は、指定した表示対象の画像のうち、表示したい領域や表示したい大きさを指定し、当該画像を要求する(ステップＳ１０)。これはビューウィンドウ(ViewWindow)リクエストと呼び、サーバ１はこれに従って、指定された表示対象の画像が符号化された画像符号のうち、表示に必要な空間領域に関する部分符号や、表示サイズに必要な解像度の部分符号のみを送信することができる。このためクライアント２は表示に必要な最低限の符号のみを受信すれば良いことになる。サーバ１はまずメインヘッダの符号を送信する(ステップＳ１１)。メインヘッダは復号時に必要な情報を含んでいるため、一度でも画像符号を要求されていれば必ず送信される。サーバ１は、ここでクライアントがビューウィンドウに適応した表示を行うために必要な部分符号を求め、これを送信する(ステップＳ１２)。ここではプレシンクト単位で部分符号が送信されるため、プレシンクトデータが送信される。
【００４７】
サーバ１はクライアント２にプレシンクトデータを送信すると、クライアント２が記憶しているキャッシュデータの情報を表すキャッシュモデル１０を更新する(ステップＳ１３)。一方、クライアント２はプレシンクトデータの全てもしくは一部をメッセージとして受信し、これをキャッシュ２０に記憶する(ステップＳ１４)。ここでは説明を簡単にするため、データビンとしてオリジナルのプレシンクトデータの全部を受信した場合のみ、ＨＤＤにファイルとして記憶するものとする。
【００４８】
続いて、クライアント２はステップＳ１０と同様にして、別のビューウィンドウリクエストを送る(ステップＳ２０)。サーバ１は、別のビューウィンドウリクエストを受信すると、表示に必要な符号の差分を追加プレシンクトデータとしてクライアント２に送信する(ステップＳ２１)。サーバ１は、ステップＳ１３と同様にして、ステップＳ２１で送信した追加プレシンクトデータに基づいてキャッシュモデル１０を更新する(ステップＳ２２)。クライアント２は、追加プレシンクトデータを受信すると、これをキャッシュ２０に記憶する(ステップＳ２３)。このとき、例えばキャッシュ２０の記憶容量が所定の容量を超え、キャッシュ２０に記憶されたいずれかのデータを削除しなければならなくなったとする。このときクライアント２は、例えば、キャッシュ２０に記憶された時間が最も古いプレシンクトデータを削除する(ステップＳ２４)。クライアント２は、キャッシュに記憶された一部のデータを削除したので、その旨をサーバ１に通知するために、モデル更新リクエストを行う(ステップＳ３０)。サーバ１はモデル更新リクエストを受信すると、これに従って、キャッシュモデル１０を更新する(ステップＳ３１)。このモデル更新リクエストは、以上のようにキャッシュ２０内のデータを削除した場合以外にも用いることができる。例えば、チャネルが一度クローズされてキャッシュモデル１０がリセットされた後チャネルが再度生成された際、クライアント２がそのとき記憶されているキャッシュデータをサーバ１に通知する場合などである。
【００４９】
尚、サーバ１からクライアント２が受信するデータは全て、上述した画像符号又は部分符号であり、キャッシュに記憶されるキャッシュデータも全て画像符号又は部分符号であるものとする。以降、画像符号又は部分符号を単に符号という。
【００５０】
＜概要シーケンス＞
ここで、クライアント２が表示対象の画像の符号を取得する動作の流れについて簡単に説明する。図１３は、クライアント２が表示対象の画像の符号を取得する動作の流れの概要を示すシーケンスチャートである。クライアント２は、表示対象の画像を表示するために必要な符号をサーバ１からダウンロードする前にキャッシュ２０から取得する（ステップＳ４０〜Ｓ４１）。そして、クライアント２は、キャッシュ２０から取得した符号に基づいて、キャッシュ２０に記憶されているキャッシュデータの情報をサーバ１に送信する（ステップＳ４２）。サーバ１は、キャッシュの情報を受信すると、当該情報に基づいて、表示に必要でキャッシュに不足している符号を再構成してコードストリーム形式に変換し、変換した当該符号をクライアント２に送信する（ステップＳ４３）。クライアントは、当該符号を受信すると、これとキャッシュに記憶していた部分符号とを必要に応じて利用して符号を合成し、その符号を復号して、得られた画像を表示装置に表示させる。さらにクライアント２はサーバ１から受信した符号をキャッシュに記憶する（ステップＳ４４）。
【００５１】
次に、クライアント２がキャッシュ２０から符号を取得する処理と、キャッシュ２０へ符号を記憶する処理とについて説明する。ここでは、符号としてプレシンクトデータを取り扱う。
【００５２】
＜取得処理＞
図１４は、キャッシュ２０から符号を取得する処理の手順を示すフローチャートである。クライアント２は、表示対象の画像について、表示に必要なプレシンクトデータがキャッシュ２０に記憶されているか否かを判断する（ステップＳ５１）。具体的には、クライアント２は、以下のようにして判断する。尚、クライアント２は、表示のために必要な部分符号をサーバ１に一度要求し当該符号を受信した場合はメインヘッダを必ず受信している。メインヘッダはキャッシュ２０に記憶され、画像名のフォルダが破棄されない限りはメインヘッダのデータは残っているものとする。メインヘッダの内部には復号に必要な情報を格納した様々なマーカ及びマーカセグメントが含まれている。画像サイズやタイルサイズ、コンポーネントの数の情報を格納したSIZマーカ、プログレッションオーダやプレシンクトサイズの情報を格納したCODマーカ、量子化ステップなどの情報を格納したQCDマーカなどである。このメインヘッダに含まれる情報に基づいて、画像のある領域を表示するために必要なプレシンクトデータビンのインデックス（プレシンクトＩＤ）が計算できる。ちなみにプレシンクトデータビンのプレシンクトインデックスは以下の式１で求められる。
【００５３】
l＝t＋(c＋s×num＿components)×num_tiles…(式１)
【００５４】
式１では、lはプレシンクトインデックスであり、tはタイルインデックスであり、cはそのプレシンクトが含まれるコンポーネント番号であり、sは含まれるタイルコンポーネント中の通し番号である。通し番号の割り当て方は、図４に示すように、まずタイルコンポーネントにおける解像度毎に独立してラスタ順に順番付けを行い、最低解像度から高解像度の方向に通し番号（インデックス）「０」から連続して付けられる。
【００５５】
ステップＳ５１では、クライアント２は、以上のようにして、表示に必要なプレシンクトデータビンのプレシンクトインデックスをメインヘッダから求め、キャッシュデータ管理ファイル２１を参照して当該プレシンクトインデックスと一致するプレシンクトインデックスを有するプレシンクトデータビンがキャッシュ２０に記憶されているか否かを判断する。そして、当該判断結果が肯定的である場合、クライアント２は、キャッシュ２０に記憶された当該プレシンクトデータを読み込む（ステップＳ５５）。次いで、クライアント２は、キャッシュデータ管理ファイル２１において、ステップＳ５５で読み込んだプレシンクトデータの属性として含まれるタイムスタンプを更新する（ステップＳ５６）。次いで、クライアント２は、キャッシュデータ管理ファイル２１において、ステップＳ５５で読み込んだプレシンクトデータの属性の一つである依存先プレシンクトを参照し、依存先プレシンクトのプレシンクトインデックスを特定する（ステップＳ５７）。即ち、ステップＳ５５で読み込んだプレシンクトデータが他のプレシンクトデータに依存している場合、例えば、他のプレシンクトデータの差分を表すプレシンクトデータであった場合、その依存先のプレシンクトデータを特定する。次いで、クライアント２は、キャッシュデータ管理ファイル２１において、ステップＳ５７で特定したプレシンクトインデックスのプレシンクトデータの属性の一つであるタイムスタンプを更新する（ステップＳ５８）。このとき、依存先プレシンクトのプレシンクトデータビンは必ず参照され使用されることで、キャッシュ２０からの取得時には依存先プレシンクトのタイムスタンプを更新する必要が無い場合も有り得る。
【００５６】
一方、ステップＳ５１の判断結果が否定的である場合、クライアント２は、ネットワークＮＴを介して、表示するために必要なプレシンクトデータをサーバ１に要求し、ダウンロードを行う（ステップＳ５２）。そして、クライアントは、サーバ１からダウンロードしたプレシンクトデータをキャッシュ２０に記憶する記憶処理を行う（ステップＳ５３）。
【００５７】
＜記憶処理＞
次に、ステップＳ５３の記憶処理の詳細な手順について説明する。図１５は、記憶処理の手順を示すフローチャートである。クライアント２は、サーバ１から受信したプレシンクトデータを記憶するための空き容量がキャッシュ２０にあるか否かを判断する（ステップＳ１０１）。ここで、キャッシュ２０が利用可能な最大容量は予め設定されているものとする。空き容量は、最大容量から、キャッシュ２０に既に記憶されているデータのデータ量の合計と、ステップＳ５２で受信しキャッシュ２０に記憶しようとしているプレシンクトデータのデータ量とを引いたものである。空き容量がある場合（ステップＳ１０１：ＹＥＳ）、クライアント２は当該プレシンクトデータをキャッシュ２０に書き込む（ステップＳ１０２）。そして、クライアント２は、キャッシュデータ管理ファイル２１において、ステップＳ１０２で書き込んだプレシンクトデータの属性の一つであるタイムスタンプを更新する（ステップＳ１０３）。尚、ステップＳ１０２でキャッシュ２０に書き込んだプレシンクトデータは、他のプレシンクトデータの依存先であったり、当該プレシンクトデータが他のプレシンクトデータに依存していたりする可能性がある。即ち、当該プレシンクトデータが、以前に受信しキャッシュ２０に記憶したプレシンクトデータの差分であったり、当該プレシンクトデータを復号して正しく表示する際に必要なプレシンクトデータがキャッシュ２０に既に記憶されていたりする可能性がある。ここでは、クライアント２は、キャッシュデータ管理ファイル２１を参照して、ステップＳ１０２でキャッシュ２０に書き込んだプレシンクトデータが依存しているプレシンクトデータ（依存先プレシンクト）を特定し、当該依存先プレシンクトのプレシンクトインデックスをキャッシュデータ管理ファイル２１に記憶する。そして、クライアント２は、特定した依存先プレシンクト自体の属性の一つとしてキャッシュデータ管理ファイル２１に記憶されているタイムスタンプを、ステップＳ１０２でキャッシュ２０に書き込んだプレシンクトデータのタイムスタンプと同じアクセス時間で更新する（ステップＳ１０４）。
【００５８】
一方、ステップＳ１０１の判断結果が否定的である場合、クライアント２は、サーバ１から受信したプレシンクトデータをキャッシュ２０に記憶するために必要な容量を算出する（ステップＳ１０５）。当該記憶容量は、記憶しようとするプレシンクトデータのデータ量からキャッシュ２０の空き容量を引くことで算出される。次いで、クライアント２は、キャッシュ２０に記憶されているプレシンクトデータのうち優先度の低いプレシンクトデータから順にキャッシュから削除する(ステップＳ１０６)。優先度は、例えば、キャッシュデータ管理ファイル２１に含まれるタイムスタンプに示されるアクセス時間が古いものから順に低いものとする。クライアント２は、このような優先度の低いプレシンクトデータのデータ量の合計がステップＳ１０５で算出した容量以上となるよう、キャッシュ２０からプレシンクトデータを削除する。
【００５９】
図１６は、例えば、ステップＳ５５で読み込んだプレシンクトデータ（対象プレシンクト）と、当該プレシンクトデータの依存先プレシンクトとのタイムスタンプを各々更新した場合、更新前後の各プレシンクトデータのタイムスタンプによって示されるアクセス時間によるデータの並び順の変化を示したものである。同図においては、各プレシンクトデータをアクセス時間の順に並べた場合、タイムスタンプの更新後には、対象プレシンクトと、当該対象プレシンクトの依存先プレシンクトとが前後に並んだ状態となっていることが示されている。即ち、依存先プレシンクトのアクセス時間を対象プレシンクトのアクセス時間と同じに更新することで、当該依存先プレシンクトの優先順位が上がり、その結果、依存先プレシンクトだけが先に削除されてしまうことが防止される。
【００６０】
ステップＳ１０６の後は、ステップＳ１０２に進み、上述と同様の処理が行われる。
【００６１】
以上のようにして、プレシンクトデータがキャッシュに記憶されるときに、依存先プレシンクトのプレシンクトデータを特定し、両者のタイムスタンプを同じものにして更新する。これにより、キャッシュからプレシンクトデータを削除する必要があり、アクセス時間の古い順に優先的にプレシンクトデータをキャッシュから削除する際に、あるプレシンクトデータと依存先のプレシンクトデータとの優先順位を同じにすることができる。従って、以上のような構成によれば、依存関係にある部分符号の依存先の部分符号のみを削除してしまうことがないため、キャッシュから部分符号を効率良く削除することができる。
【００６２】
[変形例]
また、上述した各実施の形態に限定されるものではなく、以下に例示するような種々の変形が可能である。
【００６３】
＜変形例１＞
上述した実施の形態のサーバ１で実行される各種プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記憶媒体に記憶して提供するように構成してもよい。また、当該各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。クライアント２で実行される各種プログラムについても同様である。
【００６４】
＜変形例２＞
上述の実施の形態においては、キャッシュデータ管理ファイル２１に各プレシンクトデータのタイムスタンプを記憶させ、当該タイムスタンプを用いて、キャッシュから削除すべきプレシンクトデータを決定した。しかし、これに限らず、各プレシンクトデータにアクセスしたアクセス時間の古い順にリストに記憶し、リストの先頭から順番に削除すべき容量を越えるまでプレシンクトデータを削除するようにしても良い。
【００６５】
また、キャッシュから削除すべきプレシンクトデータの優先順位は、アクセス時間によらず、他の方法により決定させるものであっても良い。
【００６６】
＜変形例３＞
上述の実施の形態においては、クライアント２は、キャッシュデータ管理ファイル２１において依存先プレシンクトのプレシンクトインデックスを記憶するようにした。しかし、クライアント２は、これをキャッシュデータ管理ファイル２１に記憶せず、ステップＳ５７及びステップＳ１０４の処理の都度、例えば図７に示されるような属性テーブルを参照して、依存先プレシンクトを検索してこれを特定するようにしても良い。
【００６７】
＜変形例４＞
上述の実施の形態においては、部分符号としてプレシンクトデータについて主に説明したが、部分符号としてタイルデータやその他の単位のデータについても同様に取り扱うようにしても良い。
【００６８】
また、上述の実施の形態においては、部分符号間の依存関係としてプレシンクトデータの依存関係を用いたが、これに限らずパケットデータ間の依存関係を用いるようにしても良い。具体的には、同じ画像符号から分解されたパケットデータで、コンポーネント、解像度、プレシンクトが同じで、レイヤの低いパケットデータを依存先のデータとするようにしても良い。これは上述の実施の形態と同様に、ある係数に対して、高レイヤの部分符号が下位ビットを表し、低レイヤの部分符号が上位ビットを表していることから、高品質の部分符号を復号するには低品質の部分符号が必要であることに起因する（図５参照）。このような依存先のパケットデータを特定するには、レイヤ「１」の部分符号はレイヤ「０」の部分符号に依存し、レイヤ「２」の部分符号はレイヤ「１」の部分符号に依存するというように、それぞれのレイヤが直接依存する先を記憶し、順次辿って探すという方法も考えられる。
【００６９】
＜変形例５＞
上述の実施の形態においては、部分符号の属性を記憶する属性テーブルと、キャッシュに記憶される部分符号を管理するためのキャッシュデータ管理ファイルとを別体として記載したが、これらを一体的に形成するようにしても良いし、キャッシュデータ管理ファイルのみ備えるように構成しても良いし、属性テーブルにおいて依存先プレシンクトとタイムスタンプとを対応付けるように構成しても良い。
【図面の簡単な説明】
【００７０】
【図１】本実施の形態にかかる画像処理システムの構成を例示する図である。
【図２】タイル分割を例示する図である。
【図３】サブバンド解像度分解を例示する図である。
【図４】プレシンクト分割を例示する図である。
【図５】レイヤ分割を例示する図である。
【図６】部分符号としてタイルデータが画像符号のうちのどのような意味を表すのかという情報を示した図である。
【図７】各属性を記憶するための属性テーブルのデータ構成を例示する図である。
【図８】原画像をJPEG2000符号化方式により符号化した画像符号であるJPEG2000ファイル、データビン、メッセージ及びサーバからクライアントに符号として送信するコードストリームの関係を示す図である。
【図９】データビンとメッセージとを例示する図である。
【図１０】プレシンクト単位で部分符号を送受信する場合のキャッシュ内のデータ構造を表しており、またキャッシュ内の部分符号がファイル形式で記憶される場合のデータ構造を例示する図である。
【図１１】キャッシュデータ管理ファイルのデータ構成を例示する図である。
【図１２】JPIPを用いたサーバ１及びクライアント２の動作の概要を示すシーケンスチャートである。
【図１３】クライアント２が表示対象の画像の符号を取得する動作の流れの概要を示すシーケンスチャートである。
【図１４】キャッシュ２０から部分符号を取得する処理の手順を示すフローチャートである。
【図１５】記憶処理の手順を示すフローチャートである。
【図１６】プレシンクトデータ及び依存先プレシンクトの更新前後のタイムスタンプによって示されるアクセス時間によるデータの並び順の変化を示した図である。
【符号の説明】
【００７１】
１  サーバ
２  クライアント
１０  キャッシュモデル
２０  キャッシュ
２１  キャッシュデータ管理ファイル
ＮＴ  ネットワーク
【図１】
0005078467.tif 000002
【図２】
0005078467.tif 000003
【図３】
0005078467.tif 000004
【図４】
0005078467.tif 000005
【図５】
0005078467.tif 000006
【図６】
0005078467.tif 000007
【図７】
0005078467.tif 000008
【図８】
0005078467.tif 000009
【図９】
0005078467.tif 000010
【図１０】
0005078467.tif 000011
【図１１】
0005078467.tif 000012
【図１２】
0005078467.tif 000013
【図１３】
0005078467.tif 000014
【図１４】
0005078467.tif 000015
【図１５】
0005078467.tif 000016
【図１６】
0005078467.tif 000017