(57)【要約】【課題】  より高速に、且つメモリ効率を鑑みた画像復号を可能にするための画像符号化データを作成するための技術を提供すること。【解決手段】  Ｓ５０３では、符号化データを用いて、復号解像度レベルで画像を復号し、この復号された画像を符号化する。そして、Ｓ５０４では、符号化データのうち復号解像度レベルで画像を復号する為に必要な部分の代わりに、この符号化された画像を用いる為に参照するfragment tableを作成し、Ｓ５０５では、符号化された画像、及びfragment tableを、符号化データと共に管理する。【選択図】    図５
2007142581.tif 000002
【特許請求の範囲】
【請求項１】
複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する工程と、
前記復号解像度レベルを取得する工程と、
前記符号化データを用いて、前記復号解像度レベルで画像を復号する復号工程と、
前記復号工程で復号された画像を符号化する符号化工程と、
前記符号化データのうち前記復号解像度レベルで画像を復号する為に必要な部分の代わりに、前記符号化工程で符号化された画像を用いる為に参照する参照情報を作成する作成工程と、
前記符号化工程で符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理工程と
を備えることを特徴とする画像処理方法。
【請求項２】
前記管理工程では、前記符号化工程で符号化された画像と、前記符号化データと、前記参照情報と、を１つのファイルで管理することを特徴とする請求項１に記載の画像処理方法。
【請求項３】
前記作成工程では、前記符号化工程で符号化された画像の前記ファイルにおける所在情報、前記符号化データのうち前記復号解像度レベルで画像を復号する為に必要な部分以外の部分の前記ファイルにおける所在情報を、この順に登録したテーブルを前記参照情報として作成することを特徴とする請求項２に記載の画像処理方法。
【請求項４】
前記復号工程、前記符号化工程、前記作成工程による処理は、前記復号解像度レベルの画像サイズを有する画像が、前記符号化データと共に管理されていない場合に行う処理であることを特徴とする請求項１に記載の画像処理方法。
【請求項５】
更に、前記復号解像度レベルの画像サイズを有する画像が、既に前記符号化データと共に管理されている場合には、当該画像を復号して出力する工程を備えることを特徴とする請求項１に記載の画像処理方法。
【請求項６】
複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する工程と、
前記復号解像度レベルを取得する工程と、
前記符号化データにおいて最も低い解像度レベルの画像を復号する復号工程と、
前記復号解像度レベルの画像サイズから前記最も低い解像度レベルの画像サイズまでの間の画像サイズの画像が再現可能なように、前記復号工程で復号した画像を符号化する符号化工程と、
前記最も低い解像度レベルの画像の代わりに、前記符号化工程で符号化された画像を用いる為に参照する参照情報を作成する作成工程と、
前記符号化工程で符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理工程と
を備えることを特徴とする画像処理方法。
【請求項７】
前記符号化データが再現可能な最小の画像サイズ、及び前記符号化データと共に既に前記管理工程で管理されている画像のサイズのうち最も小さいサイズと、前記復号解像度レベルの画像サイズとの大小関係に基づいて、請求項１乃至５に記載の画像処理方法、請求項６に記載の画像処理方法の何れかを実行することを特徴とする画像処理方法。
【請求項８】
複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する手段と、
前記復号解像度レベルを取得する手段と、
前記符号化データを用いて、前記復号解像度レベルで画像を復号する復号手段と、
前記復号手段によって復号された画像を符号化する符号化手段と、
前記符号化データのうち前記復号解像度レベルで画像を復号する為に必要な部分の代わりに、前記符号化手段によって符号化された画像を用いる為に参照する参照情報を作成する作成手段と、
前記符号化手段によって符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理手段と
を備えることを特徴とする画像処理装置。
【請求項９】
複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する手段と、
前記復号解像度レベルを取得する手段と、
前記符号化データにおいて最も低い解像度レベルの画像を復号する復号手段と、
前記復号解像度レベルの画像サイズから前記最も低い解像度レベルの画像サイズまでの間の画像サイズの画像が再現可能なように、前記復号手段によって復号した画像を符号化する符号化手段と、
前記最も低い解像度レベルの画像の代わりに、前記符号化手段によって符号化された画像を用いる為に参照する参照情報を作成する作成手段と、
前記符号化手段によって符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理手段と
を備えることを特徴とする画像処理装置。
【請求項１０】
コンピュータに請求項１乃至７の何れか１項に記載の画像処理方法を実行させることを特徴とするプログラム。
【請求項１１】
請求項１０に記載のプログラムを格納したことを特徴とする、コンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像符号化技術に関するものである。
【背景技術】
【０００２】
近年、コンピュータの表示装置として用いられているディスプレイも技術の進化と共に、解像度が向上している。例えば従来であれば、VGA(640x480画素)、SVGA(800x600画素)程度であった解像度が、現在ではノートPCでさえ、XGA(1024x768画素)以上になっている。また、デスクトップPCに至っては、SXGA(1280x1024画素)、UXGA(1600x1200画素)が普及しており、更に今後はQXGA、QUXGAなどの高解像度をサポートすることは、容易に推察できる。このため、画像表示するディスプレイ装置の種類が多くなり、それぞれの装置に合った画像表示が必要になってきた。特に解像度に関してはディスプレイの解像度に合わせ、サムネイル画像データのサイズを調整することも必要になってきた。
【０００３】
更に、ディジタルカメラの進歩により、撮影できる画像の解像度も年々高くなり、ディスプレイの解像度がいくら高くなっても、一度に全体を最大解像度で表示できなくなってきている。そこで、ディジタルカメラ等で撮影した多数の画像データのサムネイル画像を一覧表示し、その中から選択することで１枚表示に切り替え、その画像に対してズームやスクロール等の表示技術により、より詳細な画像データを表示するようなアプリケーションが必要になってきた。この場合、多数の画像データを一度に表示する場合には、高速性が重要視されるため、主画像データとは異なる予め作成されているサムネイル画像データを用いることが多い。一方、そのサムネイル表示から選択された画像データの１枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズ或いは、ディスプレイ装置に表示できるまでは、画像全体を表示し、それ以上の拡大表示になると、画像の一部分を表示する。
【０００４】
このような１枚の画像データを表示する際に、元々の画像データの画像サイズとは異なる元々の画像データの画像サイズより小さい画像サイズを複数種類使用するようなアプリケーションの場合、必要に応じてデコード処理を行い、一旦元々の画像データの画像サイズを再生し、その後、目的の画像サイズになるように、画像データを縮小することを行っていた。この場合、画像データは、非圧縮、或いはJPEG baselineのようなシーケンシャルの符号化方式で圧縮されている。
【０００５】
或いは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。階層符号化方式としては、JPEG2000がある。このJPEG2000は、1枚の画像データを1つ以上のタイルに分割し、その分割されたタイル毎に、1つ以上の解像度を持つ階層符号化方式として、2001年にISO／ITCで標準化された画像符号化方式である。また、ネットワーク上でこのJPEG2000で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとして、JPEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols(以下、JPIPと記す)がある。このJPEG2000の場合、解像度の数、即ち最低解像度の画像サイズは、エンコード（符号化時）に決定するものである。
【０００６】
また上記JPIPに関連した技術としては、特許文献１，２が挙げられる。
【０００７】
特許文献１によれば、サーバにJPEG2000で符号化された圧縮画像ファイルを置き、クライアントからコードストリームを部分的に要求し、バッファして格納する。そして、格納されていない部分のみを新規にサーバに対して要求を発行し、受信した符号データと既にバッファリングしている符号データとを接合し、デコードすることを繰り返す。この時の部分的な要求の単位は、JPEG2000符号内のパケット、タイル、コードブロックから選択される。また、バイト単位での要求も可能となっている。一方サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。
【０００８】
一方、特許文献２によれば、JPEG2000符号データのうち、サブバンド単位でサーバにデータを要求するもので、デコード時で使用した係数を保持する。そして、次に上位のサブバンドの符号データを要求した場合は、その係数に今回のデータを付加することでデコードする。そして、デコードで使用した係数を保持することを繰り返す。これにより、クライアント側で受信した符号データをバッファして格納する必要がないシステムを提供する。また、これにより、解像度方向のプログレッシブ表示を可能にする。
【０００９】
また、１つの階層符号データには１つの最低解像度データが存在し、この最低解像度の符号データから順にデコードすることで、解像度方向の階層デコードを実現するのが一般的である。そのため、この符号データから最低解像度の画像サイズより大きな画像サイズの画像データを取り出すためには、要求する出力画像サイズにより複数回の階層デコード処理を繰り返す必要がある。具体的には、JPEG2000の場合では、DWTを必要回数繰り返す、ことで目的とする画像データを得る。また逆に、最低解像度の画像サイズより小さなサイズの画像データを要求する場合は、まず最低解像度の画像データをデコードし、その後に縮小処理を行なう必要がある。
【００１０】
これら1度処理した途中の階層の画像データ或いは、最低解像度より小さな画像データ等の中間データを保存するには、元の画像データファイルとは別のファイルで、且つこの元の階層符号データと独立した新たな画像データとして符号化処理などを施し、別のファイルとして保存する必要がある。この別ファイルとして保存する場合は、ファイルを管理するということを考えると１つの画像に対して複数のファイルが存在することになり、ファイルを移動、削除、複写等を行なう場合、処理が煩雑になる。またファイル名のつけ方などにも気をつける必要がある。
【００１１】
一方、中間データの保存をしない場合では、ユーザの要求が発生する度に上記の処理を行う必要がある。すなわち、同じ画像サイズを複数回要求する場合でも、その要求回数、上記の処理を行なう必要がある。
【特許文献１】特開2003-023630号公報
【特許文献２】特開2004-040674号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
例えば画像サイズが2048x2048画素の画像データをdecomposition level = 5で符号化したJPEG2000符号データ”A.j2k”があるとする。この場合、”A.j2k”は、64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048の6種類の異なる解像度の画像データを再現できる。また、画像をデコード／表示するアプリケーション”APP_1.exe”でサムネイル画像から選択された時に表示する画像サイズは、256x256画素相当の画像サイズを表示するとする。
【００１３】
このような条件では、”APP_1.exe”で選択された1枚の画像データを表示する時の処理は、64x64,128x128,256x256の3つの解像度の符号データをデコードし、デコードされた画像を表示することになる。すなわち、このアプリケーション”APP_1.exe”では、256x256画素以下の解像度の画像データは扱わないので、256x256画素以下の解像度の符号データがある場合は、必ず256x256画素以上の画像データをデコードするまで、デコーダをループさせなければならない。そのため、デコードに時間がかかるという問題がある。また、そのアプリケーションで使用しない解像度の符号データをバッファなどで格納しなければならず、格納のための領域を余計に使用してしまうという問題点もある。さらには、JPIPでサーバに符号データを要求する場合は、通信のための時間も余計にかかるという問題もある。
【００１４】
更に、特許文献２においては、デコード処理を途中で止めて、デコード処理で使用した係数を保持するため、符号データを保持する場合に比べて、保持のためのメモリを多く使用することになる。またデコーダも途中で止めたり、更には、サブバンドのデータを追加したりと、特殊なデコーダが必要になる。
【００１５】
また、特許文献１，２では、サーバに保持されているJPEG2000符号データの圧縮パラメタは変更なしで、断片的に符号データの一部分をクライアントに送信し、クライアントで受信した符号データを変換などしないでそのままデコードするため、クライアント側のアプリケーションで使わない部分の解像度の符号データまでをも処理しなければならないという問題がある。さらには解像度の階層数が、デコーダ側でサポートしている階層数を越している場合は、受信した符号データを最後までデコードできないということが生じる場合があるという問題点もある。
【００１６】
本発明は以上の問題に鑑みて成されたものであり、より高速に、且つメモリ効率を鑑みた画像復号を可能にするための画像符号化データを作成するための技術を提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明の目的を達成するために、例えば、本発明の画像処理方法は以下の構成を備える。
【００１８】
即ち、複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する工程と、
前記復号解像度レベルを取得する工程と、
前記符号化データを用いて、前記復号解像度レベルで画像を復号する復号工程と、
前記復号工程で復号された画像を符号化する符号化工程と、
前記符号化データのうち前記復号解像度レベルで画像を復号する為に必要な部分の代わりに、前記符号化工程で符号化された画像を用いる為に参照する参照情報を作成する作成工程と、
前記符号化工程で符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理工程と
を備えることを特徴とする。
【００１９】
本発明の目的を達成するために、例えば、本発明の画像処理方法は以下の構成を備える。
【００２０】
即ち、複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する工程と、
前記復号解像度レベルを取得する工程と、
前記符号化データにおいて最も低い解像度レベルの画像を復号する復号工程と、
前記復号解像度レベルの画像サイズから前記最も低い解像度レベルの画像サイズまでの間の画像サイズの画像が再現可能なように、前記復号工程で復号した画像を符号化する符号化工程と、
前記最も低い解像度レベルの画像の代わりに、前記符号化工程で符号化された画像を用いる為に参照する参照情報を作成する作成工程と、
前記符号化工程で符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理工程と
を備えることを特徴とする。
【００２１】
本発明の目的を達成するために、例えば、本発明の画像処理装置は以下の構成を備える。
【００２２】
即ち、複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する手段と、
前記復号解像度レベルを取得する手段と、
前記符号化データを用いて、前記復号解像度レベルで画像を復号する復号手段と、
前記復号手段によって復号された画像を符号化する符号化手段と、
前記符号化データのうち前記復号解像度レベルで画像を復号する為に必要な部分の代わりに、前記符号化手段によって符号化された画像を用いる為に参照する参照情報を作成する作成手段と、
前記符号化手段によって符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理手段と
を備えることを特徴とする。
【００２３】
本発明の目的を達成するために、例えば、本発明の画像処理装置は以下の構成を備える。
【００２４】
即ち、複数の解像度レベルで画像が復号可能なように構成されている符号化データを取得する手段と、
前記復号解像度レベルを取得する手段と、
前記符号化データにおいて最も低い解像度レベルの画像を復号する復号手段と、
前記復号解像度レベルの画像サイズから前記最も低い解像度レベルの画像サイズまでの間の画像サイズの画像が再現可能なように、前記復号手段によって復号した画像を符号化する符号化手段と、
前記最も低い解像度レベルの画像の代わりに、前記符号化手段によって符号化された画像を用いる為に参照する参照情報を作成する作成手段と、
前記符号化手段によって符号化された画像、及び前記参照情報を、前記符号化データと共に管理する管理手段と
を備えることを特徴とする。
【発明の効果】
【００２５】
本発明の構成により、より高速に、且つメモリ効率を鑑みた画像復号を可能にするための画像符号化データを作成することができる。
【発明を実施するための最良の形態】
【００２６】
以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。
【００２７】
［第１の実施形態］
図１は、本実施形態に係るシステムの概略構成図である。同図に示す如く、本実施形態に係るシステムは、２台のクライアントコンピュータ１０２，１０３、サーバ１０１、画像データベース１０４により構成されている。また、２台のクライアントコンピュータ１０２、１０３とサーバ１０３とはネットワーク１００を介して接続されており、互いにデータ通信が可能な構成となっている。
【００２８】
ネットワーク１００は、ＬＡＮやインターネット等により構成されており、無線、有線の何れか、若しくはその組み合わせにより構成されている。画像データベース１０４には、ＪＰＥＧ２０００によって圧縮符号化された画像符号化データがファイル形式で複数保存されている。クライアントコンピュータ１０２、１０３からは、画像データベース１０４に保存されている画像符号化データのうち、所望の画像符号化データの取得要求がサーバ１０３に送信されるので、サーバ１０３は要求された画像符号化データを画像データベース１０４から取得し、クライアントコンピュータ１０２、１０３に返信する。
【００２９】
そのため、サーバ１０３には、画像符号化データをクライアントコンピュータ１０２、１０３に送信するためのJPEG2000用の通信プロトコルであるJPIPサーバをはじめ、WWWサーバ機能に必要なソフトウエア等がインストールされている。
【００３０】
また、クライアントコンピュータ１０２、１０３には、サーバ１０３に対して所望の画像符号化データの取得要求を送信し、この要求に応じてサーバ１０３から送信された画像符号化データを復号し、復号結果を表示する、という一連の処理を行う為に必要なソフトウェア、例えば、Webブラウザをはじめ、Webの各ページを表示するために必要なクライアント・ソフトウエアや、画像符号化データを復号／表示するために必要なクライアント・ソフトウエア、並びに、JPIPのクライアント機能を実装したソフトウエア等がインストールされている。
【００３１】
なお、同図に示したシステムの構成については一例であり、サーバやクライアントコンピュータの数等については特に同図の構成に限定するものではない。
【００３２】
図２は、クライアントコンピュータ１０２、１０３やサーバ１０３に適用可能なコンピュータのハードウェア構成を示すブロック図である。
【００３３】
２０１はＣＰＵで、ＲＯＭ２０４やＲＡＭ２０５に格納されているプログラムやデータを用いてコンピュータ全体の制御を行うと共に、本コンピュータを適用した各装置が行う後述の各処理を実行する。
【００３４】
２０２はキーボードで、本コンピュータの操作者が操作することで、各種の指示をＣＰＵ２０１に対して入力することができる。なお、同図ではマウスやジョイスティックなどのポインティングデバイス２０２ａがキーボード２０２に接続されており、このポインティングデバイス２０２ａはキーボード２０２と同様、操作者が操作することで各種の指示をＣＰＵ２０１に対して入力することができる。
【００３５】
２０３は表示部で、ＣＲＴや液晶画面などにより構成されており、ＣＰＵ２０１による処理結果を画像や文字などで表示することができる。
【００３６】
２０４はＲＯＭで、本コンピュータの設定データやブートプログラムなどを格納する。
【００３７】
２０５はＲＡＭで、ハードディスク２０６やフロッピー（登録商標）ディスク２０７からロードされたプログラムやデータを一時的に記憶するためのエリア、ネットワークＩ／Ｆ２０９を介して外部から受信したデータを一時的に記憶するためのエリア、ＣＰＵ２０１が各種の処理を実行する為に用いるワークエリアなど、各種のエリアを適宜提供することができる。
【００３８】
２０６はハードディスクで、ＯＳや、本コンピュータを適用した各装置が行う後述の各処理をＣＰＵ２０１に実行させるためのプログラムやデータなどを保存しており、これらはＣＰＵ２０１による制御に従って適宜ＲＡＭ２０５にロードされるものである。なお上述の通り、サーバとクライアントコンピュータとではそれぞれ異なるソフトウェアがインストールされているので、このハードディスク２０６に保存されている情報に関しては、本コンピュータをクライアントコンピュータに適用した場合と、サーバに適用した場合とで異なるものもある。
【００３９】
２０７はフロッピー（登録商標）ディスク２０７で、記憶媒体の一例としてのフロッピー（登録商標）に記録されているプログラムやデータを読み出して、ＲＡＭ２０５やハードディスク２０６に出力する。
【００４０】
２０８はプリンタＩ／Ｆで、本コンピュータにプリンタなどの印刷装置を接続するためのインターフェースとして機能するものであり、本コンピュータはこのプリンタＩ／Ｆ２０８を介して印刷装置に印刷対象のデータ等を出力することができる。
【００４１】
２０９はネットワークＩ／Ｆで、本コンピュータを図１に示したネットワーク１００に接続するためにインターフェースとして機能するものであり、このネットワークＩ／Ｆ２０９を介して本コンピュータはネットワーク１００に接続されている各装置とのデータ通信を行うことができる。
【００４２】
次に、画像データベース１０４に保存されている画像符号化データについて説明する。図３は、一般的なJPEG2000を用いて画像を圧縮符号化することで得られる画像符号化データの構成例を示す図である。同図に示した構成は、Resolution level-Layer-Component-Position progression(以下Resolution Progressionと記す)の符号化オプションで符号化されたJPEG2000符号化データの構成の一例である。
【００４３】
Resolution Progressionに準じた場合、resolution／layer／component／positionの順に符号化データが記録される。その他にもSNR Progressionなどの符号順が選択可能であるが、これら符号化データの並び順をprogression orderと呼ぶ。本実施形態では説明を簡単にするため、画像符号化データはResolution Progressionに従った構成（即ち図３に示した構成）を有するものとして説明する。
【００４４】
次に、ウェーブレット変換による各サブバンドと解像度との関係について説明する。図４は、６つの解像度レベルの画像が再現可能なように、ウェーブレット変換を行った場合に得られるサブバンドの構成を示す図である。このようなサブバンドは、decomposition level = ５となる。
【００４５】
先ず、サブバンドＬＬ（ＮＬ＝０）を復号すると、解像度レベル０（resolution level = 0）の画像が得られる。そして更に、ＨＬ（ＮＬ＝１），ＬＨ（ＮＬ＝１），ＨＨ（ＮＬ＝１）の３つのサブバンドをＬＬ（ＮＬ＝０）に続けて復号することで、解像度レベル１（resolution level = 1）の画像が得られる。
【００４６】
更に続けてNL=2のサブバンドを復号すると、解像度レベル２（resolution level = 2）の画像が得られ、更に続けてNL=3のサブバンドを復号すると、解像度レベル３（resolution level = 3）の画像が得られ、更に続けてNL=4のサブバンドを復号すると、解像度レベル４（resolution level = 4）の画像が得られ、更に続けてNL=5のサブバンドを復号すると、解像度レベル５（resolution level = 5）の画像が得られる。
【００４７】
このように、decomposition level = ５の画像符号化データは、各ＮＬのサブバンドを順次復号することで、６つの解像度レベルの画像が再現できる。解像度レベルが1つずつ増加する毎に、再現される画像データの画像サイズは、幅、高さ共に2倍になっていく。
【００４８】
図３に示したResolution Progressionの場合は、1つのresolution levelの符号データは、layer番号が小さい順で、component番号が小さい順に、position番号が小さい順になるように並べられている。ここでのlayer番号は復元する画像の原画に対するS／N比に対応し、layer番号が小さいほどS／N比が悪い画像データを再現することになる。
【００４９】
更に、ＪＰＥＧ２０００符号化データファイル内でのresolution番号数、layer番号数、component番号数の各値は、エンコード時のエンコード・パラメタによって予め設定され、そのパラメタにしたがってエンコード処理されており、その各パラメタが符号化データの中にヘッダ情報として格納されている。また、符号化データにおける論理的な最小単位であるパケットは、各パケットに格納されている全code-blockの情報を管理しているpacket header部と、そのpacketを構成する全code-blockの符号データであるpacket dataから構成されている。
【００５０】
ここで、本実施形態で用いる画像符号化データは、図３に示す如く構成を有し、且つ図４に示す如く、６つの異なる解像度レベルの画像が再現可能なようにＮＬ＝０〜５のサブバンドで構成されているものとする。本実施形態では、ＮＬ＝０〜５の全てのサブバンドを復号した結果得られる画像のサイズを２０４８画素×２０４８画素とするので、ＮＬ＝０〜５のそれぞれまでを復号した結果得られる画像のサイズは以下のようになる。
【００５１】
NL=0のサブバンドを復号した結果得られる画像のサイズ        64画素×64画素
NL=0、1のサブバンドを復号した場合に得られる画像のサイズ  128画素×128画素
NL=0〜2のサブバンドを復号した場合に得られる画像のサイズ  256画素×256画素
NL=0〜3のサブバンドを復号した場合に得られる画像のサイズ  512画素×512画素
NL=0〜4のサブバンドを復号した場合に得られる画像のサイズ  1024画素×1024画素
NL=0〜5のサブバンドを復号した場合に得られる画像のサイズ  2048画素×2048画素
即ち、本実施形態に係る画像符号化データはＮＬに応じて、６４画素×６４画素のサイズから２０４８画素×２０４８画素のサイズまでの６種類のサイズ（解像度レベル）の画像を再現することができる。
【００５２】
更に、本実施形態では、説明を簡単にするために、このような画像符号化データは、クライアントコンピュータが有するハードディスク２０６内に保存されているものとし、クライアントコンピュータがこの画像符号化データをハードディスク２０６から読み出し、取り扱う場合について説明する。なお、このクライアントコンピュータは、図１に示したクライアントコンピュータ（クライアントコンピュータ１０２、１０３）の何れでも良いが、以下の説明では例としてクライアントコンピュータ１０２を用いるものとする。
【００５３】
図６は、本実施形態に係る画像符号化データの構成例を示す図である。同図において６００が１つの画像符号化データ全体を示す。６００−１は、”Start Of Codestream”であり、画像符号化データの始まりを示すマーカ・コードである。６０１は、エンコード・パラメタ等が格納されているメインヘッダである。例えば最大の画像サイズが２０４８画素×２０４８画素であり、”decomposition level = 5”、“Resolution Progression”で画像符号化データが構成されていることを示す。
【００５４】
６０２−０〜６０２−５はそれぞれ、“Resolution Progression”で格納された各解像度レベル（ＮＬ）におけるサブバンドのデータである。即ち、Resolution 0なるもの（６０２−０）は、ＮＬ＝０のサブバンド（即ち図４に示したＬＬサブバンド）の符号化データであり、復号すれば６４画素×６４画素の画像（解像度レベル０の画像）が得られる。
【００５５】
また、Resolution 1なるもの（６０２−１）は、ＮＬ＝１のサブバンド（図４に示したＨＬ（ＮＬ＝１），ＬＨ（ＮＬ＝１），ＨＨ（ＮＬ＝１）の３つのサブバンド）の符号化データであり、先のResolution 0の符号化データと共に復号することで、１２８画素×１２８画素の画像（解像度レベル１の画像）を得ることができる。
【００５６】
また、Resolution 2なるもの（６０２−２）は、ＮＬ＝２のサブバンド（図４に示したＨＬ（ＮＬ＝２），ＬＨ（ＮＬ＝２），ＨＨ（ＮＬ＝２）の３つのサブバンド）の符号化データであり、先のResolution 0,1の符号化データと共に復号することで、２５６画素×２５６画素の画像（解像度レベル２の画像）を得ることができる。
【００５７】
また、Resolution 3なるもの（６０２−３）は、ＮＬ＝３のサブバンド（図４に示したＨＬ（ＮＬ＝３），ＬＨ（ＮＬ＝３），ＨＨ（ＮＬ＝３）の３つのサブバンド）の符号化データであり、先のResolution 0〜2の符号化データと共に復号することで、５１２画素×５１２画素の画像（解像度レベル３の画像）を得ることができる。
【００５８】
また、Resolution 4なるもの（６０２−４）は、ＮＬ＝４のサブバンド（図４に示したＨＬ（ＮＬ＝４），ＬＨ（ＮＬ＝４），ＨＨ（ＮＬ＝４）の３つのサブバンド）の符号化データであり、先のResolution 0〜3の符号化データと共に復号することで、１０２４画素×１０２４画素の画像（解像度レベル４の画像）を得ることができる。
【００５９】
また、Resolution 5なるもの（６０２−５）は、ＮＬ＝５のサブバンド（図４に示したＨＬ（ＮＬ＝５），ＬＨ（ＮＬ＝５），ＨＨ（ＮＬ＝５）の３つのサブバンド）の符号化データであり、先のResolution 0〜4の符号化データと共に復号することで、２０４８画素×２０４８画素の画像（解像度レベル５の画像）を得ることができる。
【００６０】
このように、各サブバンドの符号化データが解像度レベルが低い順に画像符号化データに含められている。なお、以下では、ＮＬ＝Ｘのサブバンドを「解像度レベルＸのサブバンド」と呼称する場合がある。
【００６１】
６００−２は、”End of codestream”であり、画像符号化データの終わりを示すマーカ・コードである。
【００６２】
ここで、例えば２５６画素×２５６画素以上のサイズの画像しか扱わないようなアプリケーションがこのような画像符号化データを取り扱う場合、このアプリケーションによって画像表示など、この画像符号化データを復号する要求が発生した場合には、少なくともＮＬ＝０〜２のサブバンドの符号化データは必ず復号する必要がある。これは最低でも２５６画素×２５６画素のサイズの画像は復号し、更にこれ以上のサイズの画像が必要となった場合には、ＮＬ＝３以上のサブバンドの符号化データを更に復号する必要があるからである。更に、ＮＬ＝０〜２のサブバンドの符号化データを復号する処理は、このような要求が発生する度に行う必要がある。
【００６３】
即ち、このようなアプリケーションでは、画像を復号することが必要な処理が発生する毎に、必ずＮＬ＝０〜２のサブバンドの符号化データの復号処理を行うことになり、処理が毎回冗長する。本実施形態ではこのような問題に対処するために、復号要求を受けるたびに毎回復号する符号化データ（この例では、ＮＬ＝０〜２のサブバンドの符号化データ）については、最初の復号処理で復号したものを新たに新ＬＬサブバンドとする処理を行う。
【００６４】
これにより、毎回復号していた符号化データ部分は１回目の復号処理で既に新ＬＬサブバンドの形態で復号されているので、これを用いればよい。これにより、２回目以降の復号処理では、この冗長した復号処理は行わなくても良くなる。従って、２回目以降の復号処理をより高速に行うことができると共に、１回目に復号した冗長部分を別途別ファイルの形態で保持しておかなくても良いので、メモリ効率の観点でも好適である。
【００６５】
図５は、ハードディスク２０６に保存している画像符号化データを復号する要求が発生した場合に、クライアントコンピュータ１０２が行う処理のフローチャートである。なお、同図のフローチャートに従った処理をＣＰＵ２０１に実行させるためのプログラムやデータは、ハードディスク２０６に保存されており、ＣＰＵ２０１による制御に従って適宜ＲＡＭ２０５にロードされる。そして、ＣＰＵ２０１がこれを用いて処理を実行することで、クライアントコンピュータ１０２は以下説明する各処理を実行することになる。
【００６６】
先ず、ステップＳ５００では、処理対象の画像符号化データに対する復号要求が、今回が最初であるか否かをチェックする。一般に、ファイルに対してアクセスするアプリケーションは、過去にどのファイルにアクセスしたかの履歴を保持している。従って、本ステップでも、過去の履歴を参照することで、この画像符号化データに対する同じ復号要求が過去になされているか否かをチェックし、なされている場合には今回の要求は２回目以降と判断するし、なされていない場合には今回の要求は１回目と判断する。
【００６７】
従って、ステップＳ５００における処理の結果、今回の復号処理が最初ではない場合には処理をステップＳ５０６に進め、最初である場合には処理をステップＳ５０１に進める。ステップＳ５０１では、復号する画像の解像度レベル（復号解像度レベル）を取得する。取得形態については特に限定するものではなく、様々な形態が考えられる。例えば、予め定められた復号解像度レベルを記したデータをハードディスク２０６から取得するようにしても良い。また、表示部２０３に復号解像度レベルの入力を促すＧＵＩ（グラフィカルユーザインターフェース）を表示し、ユーザがキーボード２０２やポインティングデバイス２０２ａを用いて、このＧＵＩを介して入力した復号解像度を取得するようにしても良い。
【００６８】
本実施形態ではこの復号解像度レベルを「２」（resolution level = 2、即ちＮＬ＝２）とする。即ち、復号する画像のサイズを２５６画素×２５６画素とする。なお、ステップＳ５０１では、各サブバンドのうち、ユーザが所望する解像度の画像を得るべく復号する部分が特定できるような情報であれば、何れの情報を入力するようにしても良い。
【００６９】
次に、ステップＳ５０２では、画像符号化データを含むファイル内を参照し、この入力された復号解像度レベルのサブバンドの符号化データが存在するか否かをチェックする。即ち、復号解像度レベルのサブバンドが、画像符号化データ内のＬＬサブバンドであるか、若しくは、このファイル内に後述の新ＬＬサブバンドが既に管理されている場合にはこの新ＬＬサブバンドである場合には、この入力された復号解像度レベルのサブバンドの符号化データがこのファイル内に存在していると判断する。また、復号解像度レベルのサブバンドが、画像符号化データ内のＬＬサブバンドではなく、更に、このファイル内に後述の新ＬＬサブバンドが既に管理されている場合であってもこの新ＬＬサブバンドではない場合には、この入力された復号解像度レベルのサブバンドの符号化データがこのファイル内に存在していないと判断する。
【００７０】
このチェック処理の結果、存在している場合には処理をステップＳ５０６に進める。一方、存在していない場合には、処理をステップＳ５０３に進める。
【００７１】
そして、ステップＳ５０３では、指定された復号解像度レベルの画像（即ち、２５６画素×２５６画素のサイズの画像）を得るために復号すべき全てのサブバンドを復号し、復号した結果の画像を新ＬＬサブバンドとする。ステップＳ５０３における処理の詳細については後述する。
【００７２】
ステップＳ５０４では、指定された復号解像度レベルの画像を得るために復号すべき全てのサブバンドの代わりに、ステップＳ５０３で作成した新ＬＬサブバンドを用いる為に参照される後述のfragment table、及びステップＳ５０３で作成した新ＬＬサブバンドを含む新画像符号化データを作成する処理を行う。ステップＳ５０４で作成するものを総称して「新符号」と呼称する。ステップＳ５０４における処理の詳細については後述する。
【００７３】
そして、ステップＳ５０５では、画像符号化データ、及びステップＳ５０４で作成した新符号を１つの同じファイルに書き込む処理を行う。ステップＳ５０５における処理の詳細については後述する。
【００７４】
一方、ステップＳ５０６では、ファイルから所望の符号化データを読み出す場合の読み出し方法を特定する処理を行う。ステップＳ５０６における処理の詳細については後述する。
【００７５】
次にステップＳ５０７では、ステップＳ５０６で特定した読み出し方法に従って所望の符号化データを読み出し、復号（デコード）する。
【００７６】
そして、ステップＳ５９０では、ステップＳ５０３で作成した新ＬＬサブバンド、若しくはステップＳ５０７で復号した結果を、出力画像データとして出力する。出力先は、画像復号の要求に応じて異なるが、例えば画像表示の要求がキーボード２０２やポインティングデバイス２０２ａによって入力されていたのであれば、出力先は表示部２０３となる。
【００７７】
次に、上記ステップＳ５０３における、新ＬＬサブバンドの作成処理について、図７Ａを用いて説明する。図７Ａは、ステップＳ５０３における処理の詳細を示すフローチャートである。
【００７８】
先ず、ステップＳ７００では、メインヘッダに格納されているエンコードパラメータに基づいて、画像符号化データ内のタイル数を求める。求める方法としては、最大画像サイズと、１つのタイルのサイズとを用いて、最大画像サイズ／１つのタイルのサイズを計算すれば、容易に求めることができる。
【００７９】
次に、ステップＳ７０１では、上記ステップＳ５０１で取得した復号解像度レベルをデコード階層数としてデコーダに設定する。本実施形態ではデコーダはデコードプログラムをＣＰＵ２０１が実行することにより実現するので、この場合、ステップＳ５０１で取得した復号解像度レベルは、デコードプログラムの実行時に用いる変数に設定することになる。なお、エンコード条件はタイル毎に変更することも可能である。
【００８０】
デコーダをハードウェアで実現する場合には、このハードウェアがデコード時に使用するメモリに設定すればよい。ここで、デコード解像度を制御する変数Dlevelを０にする。
【００８１】
次に、ステップＳ７０２では、１つのタイルを選択し、選択したこのタイルのDlevelで示される解像度レベルのサブバンドの符号化データを復号する処理を行う。そしてこの復号化処理を終えると、次にステップＳ７０３では、ステップＳ７０２で復号したサブバンドの解像度レベルが復号解像度レベルに達したか否かをチェックする。本実施形態の場合、復号解像度レベルは「２」であるので、ステップＳ７０２で復号したサブバンドの解像度レベルが「２」であるのか否かをチェックする。
【００８２】
そしてこのチェックの結果、ステップＳ７０２で復号したサブバンドのDlevelで示される解像度レベルが復号解像度レベルに達していない場合、即ち、ステップＳ５０１で取得した復号解像度レベルにおけるこのタイルの復号処理がステップＳ７０２にて未だ行われていない場合には、Dlevelを１つインクリメントし、処理をステップＳ７０２に戻し、このタイルの次の解像度レベルにおけるサブバンドの符号化データについて復号処理を行う。
【００８３】
一方、ステップＳ７０２で復号したサブバンドの解像度レベルが復号解像度レベルに達した場合、即ち、ステップＳ５０１で取得した復号解像度レベルにおけるこのタイルの復号処理がステップＳ７０２にて行われた場合には、処理をステップＳ７０４に進め、全てのタイルについて上記復号処理を行ったかをチェックする。
【００８４】
このチェックの結果、全てのタイルについて復号処理を行っていない場合には処理をステップＳ７０１に戻し、次の未処理のタイルを選択し、選択したこのタイルについてステップＳ７０２以降の処理を行う。
【００８５】
以上説明した、図７Ａのフローチャートに従った処理を行うことで、全てのタイルについて、解像度レベル０から復号解像度レベル（「２」）までの全ての解像度レベルにおけるサブバンドを復号することができるので、結果として、２５６画素×２５６画素の画像を得ることができる。本実施形態ではこの画像を新ＬＬサブバンドとして用いる。なお、ここで、以上の処理によって、元の画像符号化データについては何等変更処理は行っていないことに注意されたい。
【００８６】
次に、上記ステップＳ５０４における、新符号作成処理について、図７Ｂを用いて説明する。図７ＢはステップＳ５０４における処理の詳細を示すフローチャートである。
【００８７】
先ず、ステップＳ７０５では、元の画像符号化データに含まれているメインヘッダ（旧メインヘッダ）を取り出す。そして、ステップＳ７０６では、取り出したメインヘッダを用いて新メインヘッダを作成する処理を行う。そのうちの１つの処理として、メインヘッダに記述されているdecomposition level＝５を新メインヘッダにはdecomposition level＝３と記述する。これは、上記ステップＳ５０３における処理で、ＮＬ＝０〜２のサブバンドを１つのサブバンド（新ＬＬサブバンド）としたからである。即ち、この新ＬＬサブバンドをＮＬ＝０とすると、ＮＬ＝１のサブバンドは、元ＮＬ＝３のサブバンド、ＮＬ＝２のサブバンドは元ＮＬ＝４のサブバンド、ＮＬ＝３のサブバンドは元ＮＬ＝５のサブバンドとなり、結果としてこのＮＬの最大値が「３」となるからである。この新メインヘッダは、新ＬＬサブバンドと共に後述の新符号化データを構成する。
【００８８】
次に、ステップＳ７０７では、ステップＳ５０３で作成された画像を、新ＬＬサブバンドの符号化データとすべく、この画像に対してEBCOTで符号化処理を行う。そして、ステップＳ７０８では、ＮＬ＝０〜２のサブバンドの替わりに、新ＬＬサブバンドを用いるために参照される後述の各情報を作成する処理を行い、ステップＳ７０９では、ステップＳ７０８で作成した情報を後述のfragment tableに書き込む処理を行う。
【００８９】
以上の処理の結果作成される新符号の具体的な構成について図６を用いて説明する。同図において６０３で示す部分が、ステップＳ５０３で作成した新ＬＬサブバンドを含む新画像符号化データである。また、６０３−１、６０４で示す部分が、ステップＳ７０６で作成した新メインヘッダである。また、６０５−１で示す部分が、ステップＳ７０７で作成した新ＬＬサブバンドの符号化データである。
【００９０】
上記ステップＳ７０８における処理では、上記６０３−１、６０４、６０５−１で示される部分のバイト数を６０７−２で示すLengthフィールドに格納する。６０７−１で示すフィールド（Offsetフィールド）には、画像符号化データ６００、新画像符号化データ６０３を書き込んだファイルの先頭からの新符号化データ６０３のOffsetを格納する。
【００９１】
その後、画像符号化データ６００内のResolution 3のサブバンドの符号化データ（６０２−３）以降の符号化データを指し示すため、６０８−１で示すフィールドには、画像符号化データ６００、新画像符号化データ６０３を書き込んだファイルの先頭からの６０２−３のResolution 3のOffsetを格納する。６０８−２で示すフィールドには、６０２−３のResolution 3以降の符号化データ６０２−４，６０２−５、及び６００−２で示すＥＯＣの総バイト数を格納する。
【００９２】
これにより、６０７で示すfragment tableを完成させることができる。従って、このfragment tableを先頭（上部）から参照すれば、先ず、元のResolution 0〜2の符号化データ（６０２−０〜６０２−２）の代わりに用いるべき新ＬＬサブバンドの符号化データ（６０５−１）を特定できるし、次に、Resolution 3以降の符号化データを特定できる。
【００９３】
次に、上記ステップＳ５０５におけるファイル書き込み処理の詳細について、図８Ａを用いて説明する。図８Ａは、ステップＳ５０５における処理の詳細を示すフローチャートである。
【００９４】
先ず、ステップＳ８０１では、上記ステップＳ７０６において作成した新メインヘッダ（図６において６０４）を取得する。次に、ステップＳ８０２では、この取得した新メインヘッダを参照し、新ＬＬサブバンドの符号化データを特定し、これを読み出す。次に、ステップＳ８０３では、ステップＳ７０９で作成したfragment tableを取得する。そして次にステップＳ８０４では、新ＬＬサブバンドが最低解像度レベル（最小画像サイズ）のサブバンドであることを示すために、「２５６画素×２５６画素が最小画像サイズ」を示す情報６０６と、fragment table７０６とを、JPEG2000の場合ではAssociation BOX等の仕組みを用いて関連付ける。
【００９５】
そして最後にステップＳ８０５では、情報６０６が関連付けられたfragment tableと、上記新符号化データ（図６において６０３）とをそれぞれBOX（新BOX）に格納し、画像符号化データ６００、新画像符号化データ６０３を格納しているファイルに、新BOXを書き込む（アペンドする）処理を行う。
【００９６】
これにより、２つのＬＬサブバンド（６０２−０のResolution 0の符号化データ、６０５−１のResolution 0の符号化データ）を有する画像符号化データファイルを作成することができる。
【００９７】
次に、上記ステップＳ５０６における読み出し方法を特定する処理の詳細について、図８Ｂを用いて説明する。図８Ｂは、ステップＳ５０６における処理の詳細を示すフローチャートである。
【００９８】
先ずステップＳ８１１では、上記ステップＳ５０１における処理と同様の処理を行う。このチェック処理の結果、今回の復号処理が最初ではない場合には処理をステップＳ８１０に進め、最初である場合には処理をステップＳ８０６に進める。
【００９９】
ステップＳ８０６では、画像符号化データファイル内を参照し、上記ステップＳ５０１で取得した復号解像度レベルのサブバンドの符号化データが存在するか否かをチェックする。即ち、復号解像度レベルが、元の画像符号化データ（図６における６００）における解像度レベル０（即ち、図６における６０２−０）であるのか、それとも新符号化データ（図６に示す６０３）における解像度レベル０（即ち、図６における６０５−１）であるのかをチェックする。
【０１００】
本実施形態では、ステップＳ５０１で入力された復号解像度レベルは２５６画素×２５６画素のサイズの画像である。また、元の画像符号化データにおける解像度レベル０の画像サイズは６４画素×６４画素であり、新符号化データにおける解像度レベル０の画像のサイズは２５６画素×２５６画素のサイズであるので、この場合は、ステップＳ５０１入力された復号解像度レベルは、新画像符号化データにおける解像度レベル０を意味する。
【０１０１】
以上のチェック処理の結果、ステップＳ５０１で入力された復号解像度レベルが、元の画像符号化データにおける解像度レベル０を意味するのであれば処理をステップＳ８０９に進め、通常通り元の画像符号化データのＬＬサブバンドを復号する、と決定する。
【０１０２】
一方、新符号化データにおける解像度レベル０を意味するのであれば、処理をステップＳ８０７に進める。ステップＳ８０７では、「２５６画素×２５６画素が最小画像サイズ」を示す情報６０６を検索し、ステップＳ８０８ではこの情報６０６と関連付けられているfragment tableを読み出し、このfragment tableを参照して復号する、と決定する。
【０１０３】
従って、図８Ｂに示したフローチャートに従った処理の後に行う上記ステップＳ５０７では、この読み出されたfragment tableを上部から順に参照すれば、復号する順にサブバンドの符号化データを特定することができるので、この特定した符号化データを順に復号すれば、所望の画像を得ることができる。
【０１０４】
一方、ステップＳ８１０では、既に読み出し方法はステップＳ８０８，Ｓ８０９の何れかで決まっているので、この決まっている方法を用いる、と決定する。
【０１０５】
図１７は、上記各BOXを管理している画像符号化データファイルの構成を示す図である。当然、このファイルはＪＰＥＧ２０００に従ったものである。同図において１７００はfragment tableを保持するためのBOXで、このfragment tableを複数個有する場合には１７００−１で示すfragment list boxをfragment tableの数だけ有するようにすればよい。
【０１０６】
１７０１は、元の画像符号化データを保持するBOXである。１７０２は、新符号化データを保持するためのBOXである。１７０３は、Associationの情報を入れるBOXである。この形式でこれまで説明してきた各データを格納、追加することで、一般的なJPEG2000のデコーダでデコード処理を行うことができる。
【０１０７】
以上の説明により、本実施形態によれば、元々の画像符号化データ内にある任意の解像度のデータを新たなLLサブバンドの符号化データとして持つことにより、元々の画像符号化データ内にある、使わない解像度の低い部分をデコードすることを省くことができる。これにより、デコード処理を高速に行うことが可能となる。
【０１０８】
特に、LLサブバンドのみのデコードで処理できると、階層符号のデコードに必要なデコードの繰り返しがなくなる。また、元々の符号データについては何等変更せず、新しい情報を付加するだけなので、元の符号データはそのまま使用することができる。
【０１０９】
また、本実施形態では、１つの新符号を画像符号化データファイルに追加する場合について説明したが、要求に応じて複数の新符号を追加するようにしても良い。即ち、６つの解像度レベルの画像が再現可能な画像符号化データの場合、ＬＬサブバンド以外の５種類のサブバンド（ＮＬ＝１〜５のサブバンド）について、新符号を作成し、追加することができる。
【０１１０】
また、上記ステップＳ７０７における新ＬＬサブバンドの符号化では離散ウェーブレット変換処理は全く必要はなく、EBCOT符号化のみで行なうことができるため、高速に符号化処理を行なうことができる。
【０１１１】
更に、本実施形態で用いているfragment tableは、JPEG2000のPart2で規定されているテーブル、管理方法であり、新たに追加したLLサブバンドからのデコード処理時にfragment tableを用いながら符号データをリードする処理系に対して特別な処理系は必要ない。
【０１１２】
［第２の実施形態］
第１の実施形態では、元の画像符号化データにおけるＬＬサブバンドの代わりに用いるべき新ＬＬサブバンドとして、このＬＬサブバンドよりも画像サイズの大きいものを作成した。本実施形態では、新ＬＬサブバンドとして元の画像符号化データにおけるＬＬサブバンドよりも画像サイズの小さいものを作成する。
【０１１３】
図１４は、本実施形態に係る画像符号化データの構成例を示す図である。同図において図６と同じ部分には同じ番号を付けており、その説明は省略する。１４００は画像符号化データ全体を示しており、その構成については実質的には図６に示した構成と同様である。異なる点は、図６に示した画像符号化データ６００では”decomposition level = 5”であったものが、図１４に示した画像符号化データ１４００では、”decomposition level = 3”となっている点である。
【０１１４】
本実施形態でも、ＮＬ＝０〜３の全てのサブバンドを復号した結果得られる画像のサイズを２０４８画素×２０４８画素とするので、ＮＬ＝０〜３のそれぞれまでを復号した結果得られる画像のサイズは以下のようになる。
【０１１５】
NL=0のサブバンドを復号した結果得られる画像のサイズ      256画素×256画素
NL=0、1のサブバンドを復号した場合に得られる画像のサイズ  512画素×512画素
NL=0〜2のサブバンドを復号した場合に得られる画像のサイズ  1024画素×1024画素
NL=0〜3のサブバンドを復号した場合に得られる画像のサイズ  2048画素×2048画素
即ち、本実施形態に係る画像符号化データはＮＬに応じて、２５６画素×２５６画素のサイズから２０４８画素×２０４８画素のサイズまでの４種類のサイズ（解像度レベル）の画像を再現することができる。
【０１１６】
ここで、本実施形態では、図１４に示した構成を有する画像符号化データ１４００を用いて、１２８画素×１２８画素のサイズの画像を復号、表示する場合について説明する。ここで、従来では同様の目的を達成するためには、最小画像（解像度レベル０の画像）を復号し、これを縦横半分に縮小する。本実施形態では、元のＬＬサブバンドについて階層符号化処理を行い、新ＬＬサブバンドを作成する。新ＬＬサブバンドを作成した以降の処理については第１の実施形態と同様である。
【０１１７】
ここで、ハードディスク２０６に保存している画像符号化データ１４００を復号する要求が発生した場合に、クライアントコンピュータ１０２が行う本実施形態に係る処理のフローチャートについては基本的には図５に示したものと同様であるが、ステップＳ５０３〜Ｓ５０５における処理が若干異なる。以下では、本実施形態で行うステップＳ５０３〜Ｓ５０５における処理について説明する。
【０１１８】
図１５Ａは、本実施形態に係るステップＳ５０３における処理の詳細を示すフローチャートである。同図において図７Ａと同じステップについては同じステップ番号を付けており、その説明は省略する。
【０１１９】
先ず、ステップＳ１５００では、画像符号化データ１４００のＬＬサブバンドを復号する。これにより、２５６画素×２５６画素のサイズの画像を得る。次に、ステップＳ７００では、上述の通り、タイル数を求める。次に、ステップＳ１５０１では、２５６画素×２５６画素のサイズの画像をこのタイル数分タイル分割した場合に、各タイルについて階層符号化を行う際の階層数を設定する。本実施形態では、２５６画素×２５６画素のサイズの画像、及び１２８画素×１２８画素のサイズの画像の２階層（２つの解像度レベル）が表現可能な階層符号化を行うので、符号化階層数は「２」となる。そこで、ステップＳ１５０１で設定する階層数は「２」となる。
【０１２０】
次に、ステップＳ１５０２では、１つタイルを選択し、選択したタイルについて、２階層を有するような階層符号化処理を行う。ステップＳ７０３では、全ての階層について符号化を行ったのかを判断し、行っていない場合には処理をステップＳ１５０２に戻すのであるが、行ったのであれば処理をステップＳ７０４に進め、全てのタイルについて符号化処理を行ったのかをチェックする。そして全てのタイルについて符号化処理を行ったのであれば本処理を終了するのであるが、全てのタイルについて符号化処理を行っていないのであれば処理をステップＳ１５０１に戻し、未だ符号化処理の対象となっていないタイルについて以降の処理を行う。
【０１２１】
以上の処理により、２５６画素×２５６画素のサイズの画像に基づいて、１２８画素×１２８画素のサイズの画像と、２５６画素×２５６画素のサイズの画像の２つの解像度レベルが再現可能な符号化データを作成することができる。以下では、この作成した１２８画素×１２８画素のサイズの画像を新ＬＬサブバンドとして用いる。
【０１２２】
図１５Ｂは、本実施形態に係るステップＳ５０４における処理の詳細を示すフローチャートである。同図に示したフローチャートは、図７Ｂに示したフローチャートにおいてステップＳ７０７を省略したものであり、基本的に行う処理については同様であるので、これに関する説明は省略する。即ち、本実施形態では、新ＬＬサブバンドとして用いるものが異なるのみであって、それ以外については第１の実施形態と同様である。
【０１２３】
従って、ステップＳ５０４における処理では、上記６０３−１、１４０４，１４０５−１，１４０５−２で示される部分のバイト数を１４０７−２で示すLengthフィールドに格納する。１４０７−１で示すフィールド（Offsetフィールド）には、新画像符号化データ１４０３を格納しているファイル先頭からの新符号化データ１４０３のOffsetを格納する。
【０１２４】
その後、画像符号化データ１４００内のResolution  Level=1以降の符号化データを指し示すため、１４０８−１で示すフィールドには、画像符号化データ１４００を格納しているファイルの先頭からの１４０２−１のResolution 1のOffsetを格納する。１４０８−２で示すフィールドには、１４０２−１のResolution 1以降の符号化データ１４０２−２，１４０２−３、及び６００−２で示すＥＯＣの総バイト数を格納する。
【０１２５】
図１６は、本実施形態に係るステップＳ５０５における処理の詳細を示すフローチャートである。同図に示したフローチャートは、図８Ａに示したフローチャートにおいてステップＳ８０２をステップＳ１６００に変更したものである。従って、以下では、このステップＳ１６００における処理について説明する。ステップＳ１６００では、ステップＳ８０１で取得した新メインヘッダを参照し、新ＬＬサブバンドの符号化データを特定し、これを読み出す。
【０１２６】
以上の処理により、図１４に示した各部を含む画像符号化データファイルを作成することができる。新符号化データ１４０３において、画像符号化データ１４００におけるResolution 0（１４０２−０）を、２つの解像度レベル（１４０５−１と１４０５−２）に分けている点が第１の実施形態とは異なる。
【０１２７】
また上述の通り、fragment table１４０７において、上記６０３−１、１４０４，１４０５−１，１４０５−２で示される部分のバイト数を１４０７−２で示すLengthフィールドに格納する。１４０７−１で示すフィールド（Offsetフィールド）には、新画像符号化データ１４０３を格納しているファイル先頭からの新符号化データ１４０３のOffsetを格納する。
【０１２８】
その後、画像符号化データ１４００内のResolution  Level=1以降の符号化データを指し示すため、１４０８−１で示すフィールドには、画像符号化データ１４００を格納しているファイルの先頭からの１４０２−１のResolution 1のOffsetを格納する。１４０８−２で示すフィールドには、１４０２−１のResolution 1以降の符号化データ１４０２−２，１４０２−３、及び６００−２で示すＥＯＣの総バイト数を格納する。
【０１２９】
そして、新ＬＬサブバンドが再現可能な最低解像度レベル（最小画像サイズ）が「１２８画素×１２８画素のサイズ」であることを示すために、「１２８画素×１２８画素が最小画像サイズ」を示す情報１４０６と、fragment table１４０７とを、JPEG2000の場合ではAssociation BOX等の仕組みを用いて関連付ける。
【０１３０】
そして最後にステップＳ８０５では、情報１４０６が関連付けられたfragment table１４０７と、上記新符号化データ（図１４において１４０３）とをそれぞれ、BOX（新BOX）に格納し、画像符号化データ１４００を格納しているファイルに、新BOXを書き込む（アペンドする）処理を行う。
【０１３１】
以上の説明により、本実施形態によれば以下の点を解消することができる。即ち、アプリケーションによっては、階層符号データ内に格納されている最低解像度の画像データより小さな画像データが必要になる場合がある。この時、最低解像度の画像データをデコードした後、単純な縮小処理によって目的とする画像サイズの画像データを得るのではなく、階層符号化により縮小処理および符号化を行い、新しいLLサブバンドの画像サイズを目的とする画像サイズにすることで、以降のアプリケーションの処理上で、再度この１２８画素×１２８画素のサイズの画像データが必要になったときにでも、高速にデコード処理を行なうことが可能となる。
【０１３２】
さらには、この階層符号化による符号化処理は、小さい画像サイズの画像データを対象とするため、高速に行なうことが可能である。
【０１３３】
また、本実施形態では、１つの新符号を画像符号化データファイルに追加する場合について説明したが、要求に応じて複数の新符号を追加するようにしても良い。
【０１３４】
［第３の実施形態］
第１，２の実施形態では、画像符号化データがクライアントコンピュータ１０２が有するハードディスク２０６内に保存されているものとし、クライアントコンピュータ１０２がこの画像符号化データをハードディスク２０６から読み出し、取り扱う場合について説明した。本実施形態では、画像符号化データは図１に示した画像データベース１０４に保持されているものとする。この場合、クライアントコンピュータ１０２は、第１の実施形態でも説明したとおり、この画像データベース１０４を管理しているサーバ１０１に対して画像取得要求を送信する。その際、サーバ１０１は、要求された解像度レベルに応じて、第１，２の実施形態で説明した各処理を行うことになる。なお、本実施形態では、クライアントコンピュータ１０２とサーバ１０１との間の通信プロトコルについては、JPIPを用いるものとして説明する。
【０１３５】
JPIP／JPEG2000符号化データを使えば、ユーザはサーバ１０１にある全ての画像データを取得せず、必要な部分のデータのみをサーバ１０１から受信することが可能である。ユーザの受信データの単位としては、JPEG2000のpacket、あるいはpacketよりも大きい符号化単位であるタイル単位が考えられる。例えばユーザがサーバ１０１から受信するデータ単位としてpacket単位を想定する。Packet単位のリクエストおよびレスポンスの概念図を図９に示す。
【０１３６】
図９は、クライアントコンピュータ１０２がサーバ１０１から所望の符号化データを取得するために、互いの間で行われるやり取りを説明する図である。クライアントコンピュータ１０２側では所望の画像のタイル番号、resolution level、layer、component、position番号を指定し、その後、指定した符号化データの要求９００をサーバ１０１に送信する。
【０１３７】
サーバ１０１はこの要求９００を受信すると、画像符号化データ９０３のコードストリームを解析し、要求９００によって指定されたタイル番号、resolution level、layer、component、position番号に相当するpacketデータ９１１を抜き出し、クライアントコンピュータ１０２に送信する。このpacketデータ９１１は９１０に示す如く、要求９００によって指定されたタイル番号、resolution level、layer、component、position番号に相当するものである。
【０１３８】
次に、JPIPを使ってpacketデータを送信単位として、データを送受信する場合のレスポンスデータの構成を、図１０、図１１を用いて説明する。
【０１３９】
図１０は、packetデータ群により構成されているprecinct data-binの構成例を示す図である。同図において１００１はこのprecinct data-binである。同図に示す如く、precinct data-binは複数のpacketデータ１００３により構成されている。
【０１４０】
JPIPでは、このprecinct data-binと呼ばれるJPEG2000のpacketデータの塊を基本としてレスポンスデータを作成する。precinct data-binとは、Tile tnの中のprecinct pnのresolution level rn、 component番号cnを構成する全てのlayerのpacketを、layer番号が昇順になるように並べてつなげたデータの塊である。
【０１４１】
図１０に示すprecinct data-binから抜き出したPacket(tn, rn, cn, pn, 1)を使って、作成されたJPIP response dataの例を図１１に示す。JPIP response dataは、message header１１０１とmessage body １１０３から構成される。
【０１４２】
message body １１０３には、precinct data-bin１００１から切り出されたJPEG2000符号化データが入る。つまり、図１０のPacket(tn, rn, cn, pn, 1)１００３を抜き出してJPIP response dataを作成すると、Packet(tn, rn, cn, pn, 1) １００３がmessage body １１０３に格納される。message header １１０１は、４つのパラメタから構成されている。
【０１４３】
１番最初のパラメタは、message body １１０３に入っているデータがprecinct data-binであることを示す識別子が入る。２番目のパラメタには、precinct data-bin ID(PrID)が入る。これは、タイル番号tn, resolution level番号rn, component番号cn, precinct番号 pnから一意に決まり、次式で求めることができる。
【０１４４】
PrID(tn, rn, cn, pn)=tn+(cn+s×(component数))×tile数
ただし、
s = pn + tn×(resolution level rnにおける1 tileあたりのprecinct数)
+(resolution level 0から(rn-1)までのタイル trのprecinct数の総和)
3番目のパラメタは、レスポンスデータのprecinct data-binにおけるオフセット値PrOffset １００２である。つまり、message body １１０３に入っているデータは、PrID(tn, rn, cn, pn)のprecinct data-bin １００１において何Byte目からのデータであるのかを示す値であり、図１０の１００２で示したPrOffstの値と同じである。PrOffstは、precinct data-binの先頭からのオフセット値を示すものである。message header １１０１の最後のパラメタは、response data、つまり、message body １１０３のバイト長である。つまり、ResLen １１０２には、ResLen[byte] １１０４の値が入る。
【０１４５】
ここで、クライアントコンピュータ１０２からサーバ１０１に対して以下のようなリクエストが発行されたとする。
【０１４６】
http:／／www.image.com／jpip.cgi?target=d.jp2&fsiz=256,256&type=jpp-stream
このようなリクエストを受けた場合に、サーバ１０１が行う処理について、同処理のフローチャートを示す図１２を用いて説明する。なお、同図のフローチャートに従った処理をサーバ１０１のＣＰＵ２０１が行うためのプログラムやデータはサーバ１０１のハードディスク２０６に格納されており、サーバ１０１のＣＰＵ２０１がこれをＲＡＭ２０５にロードした後に、これを用いて処理を実行することで、サーバ１０１は以下説明する各処理を実行する。
【０１４７】
先ずステップＳ１２０１では、上記リクエストを受信する。なおこのリクエスト文字列は、”target”によりサーバ１０１に格納されている画像符号化データファイル名を指定し、”fsiz”により画像全体の大きさを指定し、”type”により送信データ形式を指定している。
【０１４８】
次に、ステップＳ１２０２では、ステップＳ１２０１でクライアントコンピュータ１０２から受信したリクエストの文字列を解析する。これにより、要求されているファイル名、返送データの形式、返信する画像データのサイズなどの条件を取得することができる。即ち、本実施形態の場合には、”d.jp2”というファイル名の画像ファイルを、画像全体が２５６画素×２５６画素のサイズに収まるサイズになるように要求しており、更にその返送形式は、JPIPのprecinct data-binである。
【０１４９】
次に、ステップＳ１２０３では、この要求に応じたレスポンスデータを生成する。ステップＳ１２０３における処理の詳細については後述する。そして、ステップＳ１２０４では、ステップＳ１２０３で作成したレスポンスデータをクライアントコンピュータ１０２に送信する。
【０１５０】
図１３は、上記ステップＳ１２０３におけるレスポンスデータの作成処理の詳細を示すフローチャートである。なお、同図において図５と同じステップについては同じステップ番号を付けており、その説明は省略する。
【０１５１】
先ず、ステップＳ５００では、クライアントコンピュータ１０２から前回同じものが要求されたか否か（今回が１回目のアクセスか否か）をチェックする。これは、JPIPの通信をステートフルで行う場合は、１回目か否かはその要求のフローの中で簡単に判断できる。一方ステートレスの場合は、サーバのログ情報などを利用することで判断することができる。
【０１５２】
このようなチェック処理の結果、クライアントコンピュータ１０２から前回同じものが要求されている場合には処理をステップＳ５０６に進める。一方、クライアントコンピュータ１０２から前回同じものが要求されていない場合には、処理をステップＳ５０１に進める。そしてステップＳ５０１では、クライアントコンピュータ１０２から受けたリクエストに記述された画像サイズを、復号解像度レベルとして取得する。
【０１５３】
そしてステップＳ５０２では、リクエストに記述されているファイル名で特定される画像符号化データファイル内を参照し、この取得した復号解像度レベルのサブバンドの符号化データが存在するか否かをチェックする。このチェック処理については実質的には第１の実施形態と同様にして行う。
【０１５４】
このチェック処理の結果、存在すると判断した場合には処理をステップＳ５０６に進め、存在しないと判断した場合には処理をステップＳ１３０１に進める。ステップＳ１３０１では、上記ステップＳ５０３からステップＳ５０５における処理を行う。上記第２の実施形態において説明したように、ステップＳ５０３からステップＳ５０５における処理は第１の実施形態と第２の実施形態とで異なる。従って、画像符号化データファイル内に存在するＬＬサブバンドの画像サイズ、そして存在すれば既存の新ＬＬサブバンドの画像サイズのうち小さい方を選択し、選択した画像サイズが復号解像度レベルの画像サイズよりも小さい場合には第１の実施形態に係るステップＳ５０３〜ステップＳ５０５における処理を行い、大小関係が逆であれば第２の実施形態に係るステップＳ５０３〜ステップＳ５０５における処理を行う。本実施形態の場合には、２５６画素×２５６画素のサイズの画像がクライアントコンピュータ１０２から要求されているので、第１の実施形態に係るステップＳ５０３〜ステップＳ５０５における処理を行うことになる。
【０１５５】
次に、ステップＳ１３０２では、ステップＳ１３０１で作成した新ＬＬサブバンドの読み出し方法を特定する処理を行う。本ステップでは、図８Ｂのフローチャートに従った処理を行う。
【０１５６】
そして、ステップＳ１３０３では、ステップＳ１３０２，Ｓ５０６の何れかで決定した読み出し方法で読み出された符号化データを返送データとして作成する。そしてその後、サーバ１０１はこの返送データをクライアントコンピュータ１０２に送信する。
【０１５７】
ここで、上記ステップＳ５００において、今回の要求が一回目の要求か否かを判断しているのは、この一回目の要求で今後の要求に対してどの読み出し方を利用するかを決定するためである。具体的には、一回目の要求で２５６画素×２５６画素のサイズの画像データを要求する本実施形態の場合、ユーザの要求等により拡大要求が発生し、次に５１２画素×５１２画素の画像データをサーバ１０１に要求した場合は、クライアントコンピュータ１０２側ではLLサブバンドが２５６画素×２５６画素のサイズの画像の符号データだと認識しているため、２５６画素×２５６画素のサイズの画像の符号化データからの差分の符号データを返送する必要がある。そのため2回目以降の要求の場合は、一回目で特定した読み出し方法に従って、処理を行なう必要があるためである。
【０１５８】
以上説明したように、元々サーバ１０１にはLLサブバンドが６４画素×６４画素のサイズの画像の符号化データが格納されている場合でも、クライアントコンピュータ１０２からの要求が２５６画素×２５６画素のサイズの画像の符号化データから始まる要求の場合には、あたかもLLサブバンドが２５６画素×２５６画素のサイズの画像の符号化データであるかのように返送データを返すため、クライアントコンピュータ１０２側のアプリケーション、特にデコーダにおいて、クライアントコンピュータ１０２のアプリケーションが使用しない画像サイズのデコード、具体的には６４画素×６４画素のサイズ、１２８画素×１２８画素のサイズの画像データをデコードすることなく、２５６画素×２５６画素のサイズの画像データを直接デコードできるため、高速にデコードを行なうことができる。
【０１５９】
さらには、サーバ１０１から送られる符号化データの量においても、３階層分（６４画素×６４画素のサイズ、１２８画素×１２８画素のサイズ、２５６画素×２５６画素のサイズ）の符号化データを送るよりは、１つのLLサブバンドの符号化データを返送した方が、データ量的にも少なくて済み、ネットワーク上でのトラフィックを下げることができる。従って、システム全体におけるスループットを向上させることができる。
【０１６０】
ここで、以上の各実施形態によれば、以下のような効果が期待できる。
【０１６１】
即ち、アプリケーションが使用する最低解像度の画像サイズに符号データの最低解像度を合わせることができ、デコードにかかる時間を短縮することができる。またアプリケーションは、最初に画像を表示する画像サイズから拡大表示する場合など、符号データ内のどの階層符号データをデコードすればよいかも簡単に判断することができる。
【０１６２】
またこの符号変換処理は、画像サイズの小さい画像データを対象に行うため、高速に変換できる。あるいはこの符号変換処理で、既に階層符号データの中に存在する途中の階層の符号データをLLサブバンドに変換する処理は、DWT処理を行うことは無く、単に画像データをLLサブバンドとしてEBCOT符号化処理を行うだけであるため、演算コストは低い。
【０１６３】
さらには、符号データのLLサブバンドの画像サイズより小さなサイズのLLサブバンドを生成するための、再符号化処理を行なう場合においても、画像サイズが小さいを対象に階層符号化を行なうため、高速に行なうことができる。
【０１６４】
また使い方によっては、全ての解像度の符号データをLLサブバンドの符号データでデコードすることも可能になる。この場合は、各階層の符号データを独立した符号データとして扱うことが可能となる。
【０１６５】
更には、符号データをサーバに要求するような場合は、JPIPの仕組みを利用し、サーバがリクエスト文字列を判断することにより、サーバ側で自動的に判断することも可能である。このためクライアントはサーバで管理されている符号データのエンコード・オプションを意識することなく、アプリケーションが設定する最低解像度の画像データを簡単に入手することができ、さらには階層数を削減することで、サーバから返送する符号の通信量まで削減できる。
【０１６６】
更には、サーバで管理している符号化データは、他のクライアントからの要求に対して、再利用することができるため、符号データを効率的に利用することが可能となる。
【０１６７】
あるいは、サーバとクライアント間で画像データの通信の前に、ネゴシエーションすることも可能であり、これを行うことでより正確に双方の状態などを知らせることが可能となる。さらにはこのネゴシエーションには、JPIPの”vendor capability”として実装も可能であり、JPIPの仕組みの範囲内での実装が可能である。
【０１６８】
また、上記各実施形態は適宜組み合わせて用いるようにしても良い。
【０１６９】
［その他の実施形態］
また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。
【０１７０】
また、コンピュータが読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行う。その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１７１】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１７２】
本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【０１７３】
【図１】本発明の第１の実施形態に係るシステムの概略構成図である。
【図２】クライアントコンピュータ１０２、１０３やサーバ１０３に適用可能なコンピュータのハードウェア構成を示すブロック図である。
【図３】一般的なJPEG2000を用いて画像を圧縮符号化することで得られる画像符号化データの構成例を示す図である。
【図４】６つの解像度レベルの画像が再現可能なように、ウェーブレット変換を行った場合に得られるサブバンドの構成を示す図である。
【図５】ハードディスク２０６に保存している画像符号化データを復号する要求が発生した場合に、クライアントコンピュータ１０２が行う処理のフローチャートである。
【図６】本発明の第１の実施形態に係る画像符号化データの構成例を示す図である。
【図７Ａ】ステップＳ５０３における処理の詳細を示すフローチャートである。
【図７Ｂ】ステップＳ５０４における処理の詳細を示すフローチャートである。
【図８Ａ】ステップＳ５０５における処理の詳細を示すフローチャートである。
【図８Ｂ】ステップＳ５０６における処理の詳細を示すフローチャートである。
【図９】クライアントコンピュータ１０２がサーバ１０１から所望の符号化データを取得するために、互いの間で行われるやり取りを説明する図である。
【図１０】packetデータ群により構成されているprecinct data-binの構成例を示す図である。
【図１１】図１０に示すprecinct data-binから抜き出したPacket(tn, rn, cn, pn, 1)を使って、作成されたJPIP response dataの例を示す図である。
【図１２】リクエストを受けた場合に、サーバ１０１が行う処理のフローチャートである。
【図１３】ステップＳ１２０３におけるレスポンスデータの作成処理の詳細を示すフローチャートである。
【図１４】本発明の第２の実施形態に係る画像符号化データの構成例を示す図である。
【図１５Ａ】本発明の第２の実施形態に係るステップＳ５０３における処理の詳細を示すフローチャートである。
【図１５Ｂ】本発明の第２の実施形態に係るステップＳ５０４における処理の詳細を示すフローチャートである。
【図１６】本発明の第２の実施形態に係るステップＳ５０５における処理の詳細を示すフローチャートである。
【図１７】各BOXを管理している画像符号化データファイルの構成を示す図である。
【図１】
2007142581.tif 000003
【図２】
2007142581.tif 000004
【図３】
2007142581.tif 000005
【図４】
2007142581.tif 000006
【図５】
2007142581.tif 000007
【図６】
2007142581.tif 000008
【図７Ａ】
2007142581.tif 000009
【図７Ｂ】
2007142581.tif 000010
【図８Ａ】
2007142581.tif 000011
【図８Ｂ】
2007142581.tif 000012
【図９】
2007142581.tif 000013
【図１０】
2007142581.tif 000014
【図１１】
2007142581.tif 000015
【図１２】
2007142581.tif 000016
【図１３】
2007142581.tif 000017
【図１４】
2007142581.tif 000018
【図１５Ａ】
2007142581.tif 000019
【図１５Ｂ】
2007142581.tif 000020
【図１６】
2007142581.tif 000021
【図１７】
2007142581.tif 000022