(57)【要約】【課題】  低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することになり、次回の復号処理に要する処理を簡略化させる。【解決手段】  decomposition level＝４でＪＰＥＧ２０００方式で符号化されている符号化画像データ（オリジナルの画像サイズが１０２４×１０２４画素サイズ）を、デフォルトで２５６×２５６画素サイズの解像度で表示する場合に最適化するため、resolution lebel 0〜２をデコードして、２５６×２５６の解像度（画像サイズ）の画像を得る。この２５６×２５６の解像度の画像データをＪＰＥＧ２０００の最低解像度であるＬＬ成分とし、resolution level=０の符号化データと再構成する。【選択図】  図６
2006135792.tif 000002
【特許請求の範囲】
【請求項１】
画像が少なくとも１つのタイルに分割され、各タイルについて低解像度から高解像度の画像を段階的にデータ生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置であって、
出力しようとする画像の出力解像度を判定する判定手段と、
該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定した位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段と
を備えることを特徴とする画像処理装置。
【請求項２】
前記再符号化手段は、変換対象の画像符号化データの符号化条件が記述されているヘッダ部を、変換後の符号化条件で書換える手段を含むことを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記判定手段は、所定の通信手段を介してのネットワーク上のクライアント端末からの要求情報に含まれる出力解像度を判定し、
更に、前記再符号化手段で再符号化された画像符号化データを前記通信手段を介して要求元のクライアントＰＣに送信する手段を備えることを特徴とする請求項１に記載の画像処理装置。
【請求項４】
前記クライアント端末との通信は、ＪＰＩＰを用いることを特徴とする請求項３に記載の画像処理装置。
【請求項５】
更に、変換対象となる画像符号化データのファイル一覧を表示する一覧ウインドウと、選択された画像符号化データの復号した画像を表示する画像表示ウインドウとを表示する表示制御手段を備え、
前記判定手段は、前記画像表示ウインドウのサイズに基づいて出力解像度を判定することを特徴とする請求項１に記載の画像処理装置。
【請求項６】
画像が少なくとも１つのタイルに分割され、各タイルについて低解像度から高解像度の画像を段階的にデータ生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置の制御方法であって、
出力しようとする画像の出力解像度を判定する判定工程と、
該判定工程で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定した位置までの符号化データを用いて復号し、出力用画像データを生成する復号工程と、
該復号工程で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号工程で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化工程と
を備えることを特徴とする画像処理装置の制御方法。
【請求項７】
画像が少なくとも１つのタイルに分割され、各タイルについて低解像度から高解像度の画像を段階的にデータ生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置として機能するコンピュータプログラムであって、
出力しようとする画像の出力解像度を判定する判定手段と、
該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定した位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段
として機能することを特徴とするコンピュータプログラム。
【請求項８】
請求項７に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は圧縮符号化された画像データを処理する技術に関するものである。
【背景技術】
【０００２】
近年、コンピュータの表示装置として用いられているディスプレイも技術の進化と共に、解像度が向上している。例えば従来であれば、VGA(640x480画素)、SVGA(800x600画素)程度であった解像度が、現在ではノートＰＣでさえ、XGA(1024x768画素)以上になり、ディスクトップＰＣにいたっては、SXGA(1280x1024画素), UXGA(1600x1200画素)が普及しており、更に今後はQXGA, QUXGAなどの高解像度をサポートすることは容易に推察できる。
【０００３】
更に、デジタルカメラなどで撮影した多数の画像データを同時に表示し、その中から選択的に１枚表示に切り替えて、ズームやスクロールなどの表示技術により、より詳細な画像データを表示するようなアプリケーションがある。この場合、同時に多数の画像データを一度に表示する場合には、高速性が重要視されるため、主画像データとは異なる予め作成されているサムネイル画像データを用いることが多い。一方そのサムネイル表示から選択された画像データの一枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示し、それ以上の拡大表示になると、画像の一部分を表示する。
【０００４】
このような、１枚の画像データを表示する際に、元々の画像データの画像サイズとは異なる元々の画像データの画像サイズより小さい画像サイズを複数種類使用するようなアプリケーションの場合、必要に応じてデコード処理を行い、一旦元々の画像データの画像サイズを再現し、その後目的の画像サイズになるように、画像データを縮小することを行っていた。この場合画像データは、非圧縮かあるいはJPEG baselineのようなシーケンシャルの符号化方式で圧縮されている。
【０００５】
あるいは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。階層符号化方式としては、ＪＰＥＧ２０００が知られている。このＪＰＥＧ２０００は、１枚の画像データを１つ以上のタイルに分割し、その分割されたタイル毎に、１つ以上の解像度を持つ階層符号化方式として、２００１年にＩＳＯ／ＩＴＣで標準化された画像符号化方式である。またネットワーク上でこのＪＰＥＧ２０００で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとして、JEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols(以下、JPIPと記す)があり、現在策定中である。
【０００６】
例えば、特許文献１として、サーバにＪＰＥＧ２０００で符号化された圧縮画像ファイルを置き、クライアントからコードストリームを部分的に要求し、バッファして格納する。格納されていない部分のみを新規にサーバに対して要求を発行し、受信した符号データと既にバッファリングしている符号データとを接合し、デコードすることを繰り返す。この時の部分的な要求の単位は、ＪＰＥＧ２０００の符号内のパケット、タイル、コードブロックから選択される。また、バイト単位での要求も可能となっている。一方サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。
【０００７】
また、特許文献２には、ＪＰＥＧ２０００符号データのうち、サブバンド単位でサーバにデータを要求するもので且つ、デコード時で使用した係数を保持し、次に上位のサブバンドの符号データを要求した場合は、その係数に今回のデータを付加することでデコードし、デコードで使用した係数を保持することを繰り返すことにより、クライアント側で受信した符号データをバッファして格納する必要がないシステムである。これにより解像度方向のプログレッシブ表示を可能にするものである。
【特許文献１】特開２００３−０２３６３０公報
【特許文献２】特開２００４−０４０６７４公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
例えば、この特許文献２によると、画像サイズが２０４８×２０４８画素の画像データをdecomposition level =５で符号化したＪＰＥＧ２０００の符号化データファイル“A.jk2”があるとする。この場合、ファイル“A.j2k”は、６４×６４,１２８×１２８,２５６×２５６,５１２×５１２,１０２４×１０２４,２０４８×２０４８の６種類の異なる解像度の画像データを再現できる。また画像をデコード/表示するアプリケーションプログラムファイル“APP_1.exe”でサムネイル画像から選択された時に表示する画像サイズは、２５６×２５６画素相当の画像サイズを表示するとする。
【０００９】
このような条件では、“APP_1.exe”で選択された１枚の画像データを表示する時の処理は、６４×６４→ １２８×１２８→２５６×２５６の３つの解像度の符号データをデコードして、デコードされた画像を表示することになる。すなわち、このアプリケーション“APP_1.exe”では、２５６×２５６画素以下の解像度の画像データは扱わないので、２５６×２５６画素サイズ以下の解像度の符号データがある場合は、必ず２５６×２５６画素以上の画像データをデコードするまで、デコーダをループさせなければならない。そのため、デコードに時間がかかるという問題がある。またそのアプリケーションで使用しない解像度の符号データをバッファなどで格納しなければならず、格納のための領域を余計に使用してしまうという問題点もある。さらには、JPIPでサーバに符号データを要求する場合は、通信のための時間も余計にかかるという問題もある。
【００１０】
更にこの特許文献２においては、デコード処理を途中で止めて、デコード処理で使用した係数を保持するため、符号データを保持する場合に比べて、保持のためのメモリを多く使用することになる。またデコーダも途中で止めたり、更には、サブバンドのデータを追加したりと、特殊なデコーダが必要になる。
【００１１】
また、これら特許文献１、２では、サーバに保持されているＪＰＥＧ２０００符号データの圧縮パラメータは変更なしで、断片的に符号データの一部分をクライアントに送信し、クライアントで受信した符号データを変換などしないでそのままデコードするため、クライアント側のアプリケーションで使わない部分の解像度の符号データまでをも処理しなければならないという問題がある。さらには解像度の階層数が、デコーダ側でサポートしている階層数を越している場合は、受信した符号データを最後までデコードできないということが生じる場合があるという問題点もある。
【００１２】
本発明はかかる問題点に鑑みなされたものであり、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することで、次回の復号処理に要する処理を簡略化させる技術を提供しようとするものである。
【課題を解決するための手段】
【００１３】
この課題を解決するため、本発明の画像処理装置は以下の構成を備える。すなわち、
画像が少なくとも１つのタイルに分割され、各タイルについて低解像度から高解像度の画像を段階的にデータ生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置であって、
出力しようとする画像の出力解像度を判定する判定手段と、
該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定した位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段とを備える。
【発明の効果】
【００１４】
本発明によれば、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することになり、次回の復号処理に要する処理を簡略化させることが可能になる。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面に従って、本発明にかかる実施形態を詳細に説明する。
【００１６】
図１は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。同図において、１００はインターネットに代表されるネットワーク、１０１はサーバ・コンピュータであり、例えば画像データを送信するためのＪＰＥＧ２０００用の通信プロトコルであるＪＰＩＰサーバをはじめ、ＷＷＷサーバ機能に必要なソフトウエアが実行される。また１０４は大容量の画像データを格納するストレージ装置（実施形態ではＨＤ）であり、ＪＰＥＧ２０００符号化方式で符号化された圧縮画像データが多数保存されている。１０２及び１０３はクライアント・コンピュータ（以下、クライアントＰＣ）であり、ＷｅｂブラウザをはじめＷｅｂの各ページを表示するために必要なクライアント・ソフトウエアと、ＪＰＥＧ２０００符号化データをデコード/表示するためのクライアント・ソフトウエアならびに、ＪＰＩＰのクライアント機能を実装したソフトウエアなどが実行される。
【００１７】
図２は、図１においてクライアントＰＣのブロック構成図である。図中、２０１は、システム全体の制御などを行っているＣＰＵである。２０２はキーボードで、２０２ａはマウス（登録商標）等のポインティングデバイスと共にシステムに情報などを入力するために使用される。２０３は表示部で、ＣＲＴTや液晶ディスプレイなどで構成されている。２０４はＲＯＭ、２０５はＲＡＭで、システムの記憶装置を構成し、システムが実行するプログラムやシステムが利用するデータを記憶する。２０６はハードディスク装置であり、ＯＳ、各クライアントソフトウェアを格納しており、各種データファイルを記憶するものである。２０７はフロッピー（登録商標）・ディスク装置で、システムのファイルシステムに使用される外部記憶装置を構成している。２０８はプリンタインタフェースである。２０９はネットワークインタフェースであり、ここからインターネットなどのネットワーク上に接続されているサーバ・コンピュータなどのネットワーク上の資源にアクセスする。また、図１におけるサーバ・コンピュータ１０１も基本的には図２で示した構成を持つものであるが、ハードディスクに格納されているＯＳ、アプリケーションはサーバとして機能するものとなる点で異なる。
【００１８】
次に図３を用いて一般的なＪＰＥＧ２０００符号化データの構造を説明する。図示は、Resolution level-Layer-Component-Position progression(以下Resolution Progressionと記す)の符号化オプションで符号化されたＪＰＥＧ２０００符号データの例である。
【００１９】
Resolution Progressionに準じた場合、resolution/layer/component/positionの順に符号データが記録される。その他にもSNR Progressionなどの符号順が選択可能であるが、これら符号データの並び順をprogression orderと呼ぶ。本実施形態では、説明を簡単にするため、Resolution Progressionとして説明する。
【００２０】
次に図４を用いてウェーブレット変換による解像度とサブバンドの関係を説明する。同図では、decomposition level = 4の場合を説明している。まずはLL(NL=１)のみでresolution level = ０の解像度の画像となる。そして、ＬＬの画像とHL(NL=1), LH(NL=1), HH(NL=1)の３つのサブバンドをデコードすることでlevel=１の解像度の画像が生成可能になる。そして、NL=１の解像度の画像とNL=２のサブバンドでlevel=２の解像度の画像が生成可能になる。NL=２の解像度の画像とNL=３のサブバンドでlevel=３の解像度の画像が生成可能になる。そして、NL=３の解像度の画像とNL=４のサブバンドでlevel =４の解像度の画像が生成可能、というように計５種類の解像度の画像データを再現できる。このようにresolution level番号が１つずつ増加する毎に再現される画像データの画像サイズ（水平、垂直方向の画素数）は、幅、高さ共に２倍になっていく。図３で示したResolution Progressionの場合は、１つのresolution levelの符号データは、layer番号が小さい順で、component番号が小さい順に、position番号が小さい順になるように並べられている。ここでのlayer番号は復元しる画像の原画に対するS/N比に対応し、layer番号が小さいほどS/N比が悪い画像データを再現することになる。
【００２１】
さらにＪＰＥＧ２０００符号データファイル内でのresolution番号、layer番号、component番号の各最大値は、エンコード時のエンコード・パラメータによって予め設定され、そのパラメータにしたがってエンコード処理されており、その各パラメタが符号化データの中にヘッダ情報として格納されている。また符号データにおける論理的な最小単位であるパケットは、各パケットに格納されている全code-blockの情報を管理しているpacket header部と、そのpacketを構成する全code-blockの符号データであるpacket dataから構成されている。
【００２２】
本第１の実施形態では、ローカル、つまり、クライアントＰＣのハードディスク等に格納されたＪＰＥＧ２０００形式のファイルのデコード方法について説明する。本実施形態におけるサンプル・アプリケーションは、ローカルに格納されているファイル一覧をそれぞれのサムネイル画像（先頭フレーム）を表示ウィンドウに表示し、その所望とするファイルを１枚の表示ウィンドウに表示することを想定する。
【００２３】
ここでサムネイル表示ウィンドウ内に表示する１枚の画像サイズは６４×６４画素固定で、１枚表示ウィンドウのウィンドウサイズは２５６×２５６画素の画像データが表示できるサイズとし、この１枚表示ウィンドウは、この最初に表示される画像サイズを最低解像度サイズとして、それ以上の解像度の画像データをユーザの指示に従って、拡大、縮小、スクロールなどの処理を行うことを想定する。
【００２４】
またローカルにある画像ファイルは、全て画像サイズが１０２４×１０２４画素サイズであり、それらの画像データを”decomposition level = 4”, “Resolution Progression”でＪＰＥＧ２０００符号化方式を用いて符号化しているとする。すなわち最低解像度が６４×６４画素サイズであり、次が１２８×１２８画素サイズ、その次が２５６×２５６画素サイズ、５１２×５１２画素サイズと続き、最後の最大解像度の画像サイズが１０２４×１０２４画素サイズの５種類の解像度を持つ階層符号化で符号化されている。
【００２５】
よって本実施形態の場合、１枚表示用ウィンドウは、２５６×２５６画素サイズ、５１２×５１２画素サイズ、１０２４×１０２４画素サイズの３種類の画像サイズの画像データを表示するものである。ただし、５１２×５１２、１０２４×１０２４の画素サイズは、表示可能サイズ２５６×２５６画素サイズを超えるので、その一部を表示することになる。
【００２６】
図５では、上記サンプル・アプリケーションでの画像表示の例を示している。図中、５００は、サムネイル表示用ウィンドウであり、６４×６４画素サイズの画像データファイル“Ａ”, ”Ｂ”, “Ｃ”, “Ｄ”, “Ｅ”, “Ｆ”の６枚を表示しているところを表している。なお、表示している画像ファイルが６個を超える場合には、スクロールバーを表示して、それ以外のファイルを表示する。ユーザは、ポインティングデバイス２０２ａなどで、例えば画像“Ｄ”が選択すると、該当する画像ファイル“Ｄ”を選択し、一枚表示の画像表示ウィンドウ５０１に２５６×２５６画素サイズの画像データをデフォルトとして図示のように表示する。
【００２７】
図６は、ＪＰＥＧ２０００で符号化された６枚の画像それぞれの符号データを示している。図示において、６００は、“Start of codestream”であり、符号データの始まりを示すマーカ・コードである。６０１は、エンコード・パラメータを格納しているメインヘッダである。例えば画像サイズが１０２４×１０２４画素サイズであり、”decomposition level = 4”とか, “Resolution Progression”で符号データが格納されていることをしめす。６０２から６０６までは、“Resolution Progression”で格納された各resolutionの符号データである。６０７は“End of codestream”であり、符号データの終りを示すマーカ・コードである。
【００２８】
画像サイズが１０２４×１０２４である場合、resolution level = ０で示される領域６０２には、６４×６４画素サイズの画像データをデコードするための符号データが格納されている。すなわち、図４で示すＬＬ(NL=0)部分の符号化データである。
【００２９】
resolution level =１で示される領域６０３には、１２８×１２８画素サイズの画像データをデコードするための符号データが格納される。つまり、図４のＨＬ(NL=1),ＬＨ(NL=1),ＨＨ(NL=1)で示す部分の符号データである。
【００３０】
resolution level =２で示される領域６０４には、２５６×２５６画素サイズの画像データをデコードするための符号データであり、図４のHL(NL=2), LH(NL=2), HH(NL=2)の部分に相当する符号データである。
【００３１】
resolution level =３で示される領域６０５には、５１２×５１２画素サイズの画像データをデコードするための符号データが格納される。図４のＨＬ(NL=3),ＬＨ(NL=3),ＨＨ(NL=3)の部分の符号データでもある。
【００３２】
最後の、esolution level =４で示される領域には、１０２４×１０２４画素の画像データをデコードするための符号データが格納される。図４のＨＬ(NL=4),ＬＨ(NL=4),ＨＨ(NL=4)で示すサブバンド部分の符号データである。
【００３３】
よって本実施形態の場合、図５のたサムネイル表示用ウィンドウ５００には、各画像データファイルにおける、図６で示したＪＰＥＧ２０００の符号データの内のresolution level = ０の領域までの符号データをデコードして得られた画像データを表示していることになる。このＪＰＥＧ２０００のデータのデコード処理そのものは本発明の主眼ではないので説明を割愛する。
【００３４】
では次に図５で示すサムネイル表示５００内の“Ｄ”で示している画像をユーザが指定し、その画像を画像表示ウインドウ５０１に表示する処理について説明する。
【００３５】
実施形態の場合、画像表示ウインドウ５０１は２５６×２５６画素の画像を表示可能なので、画像ファイルが選択されたデフォルト状態では、図６で示すＪＰＥＧ２０００の符号データのうち、符号６０４で示すresolution level = 2の領域までの符号データをデコードし、表示することになる。このデコード処理も前記サムネイル表示用のウィンドウで表示するためのデコード処理と同様であるので説明は要しないであろう。
【００３６】
ここで、この画像表示ウインドウ５０１に表示する画像データは、この２５６×２５６画素の画像サイズの画像データを最低解像度の画像データとして、これ以下の画像サイズの画像を表示する時は、２５６×２５６画素の画像データを縮小して表示するものとし、さらには、拡大表示する場合は、上の解像度の符号データをデコードして表示する。この時、高解像度の画像データは、画像表示ウインドウ５０１のサイズを超えてしまうため、画像の一部を表示して、残りの部分はスクロールなどの処理により、表示するものとする。
【００３７】
あるいは、表示ウィンドウサイズよりデコードして得られる画像データの画像サイズが大きい場合に、符号データがタイルに分割されている場合は、表示される部分のみのタイルをデコードし、スクロールなどで新規に必要になった部分のタイルをデコードしても良い。
【００３８】
では、decomposition levelを下げる処理を図７（ａ）、（ｂ）、図８（ａ），（ｂ）を用いて説明する。
【００３９】
説明を簡単にするため、画像“Ｄ”の符号データがタイル分割されていない場合（つまり、画像全体が１タイルの場合）で説明する。
【００４０】
まずステップＳ７０１で符号データのタイル数を取得する。今回の場合は、１である。次にステップＳ７０２ではデコードする階層数を計算する。今回の場合は、取得したい画像データの画像サイズが２５６×２５６画素であるので、階層数「２」の符号データまでをデコードすれば目的の画像サイズの画像を得ることができる。そのため、ステップＳ７０２で取得する階層数は「２」となる。
【００４１】
ステップＳ７０３では、実際の各タイルの１階層分のデコードを行う部分である。このデコード処理は、必ず最低解像度からデコードを行うことを想定しているので、ステップＳ７０３では、１回目のコールのときに、階層番号として「０」を設定する。この階層番号は、ステップＳ７０３を処理する毎に、１インクリメントされる。ステップＳ７０４では、目的の階層数デコードしたかを判断する部分であり、ステップＳ７０３で設定する階層番号と、ステップＳ７０２で設定した階層数の値を比較する。目的の階層までデコードまでステップＳ７０３を繰り返す。今回の場合は、ステップＳ７０３を３回ループすることにより目的の階層までをデコードしたことになる。
【００４２】
ステップＳ７０５では、デコードして得られた画像データを表示用の画像データに変換する部分である。
【００４３】
このステップＳ７０５の詳細は、図７（ｂ）に示す通りで、ステップＳ７０５−１で、今回デコードしたタイルのタイル番号から、表示画像データの空間的な位置を特定する。ステップＳ７０５−２で、ステップＳ７０５−１で特定された位置に対して、画像データをコピーするなどの処理を行い、表示用の画像データの形式に変換して、ステップＳ７０５の処理を終了する。
【００４４】
次にステップＳ７０６で、階層数を削減するための、最低解像度用のＬＬサブバンドデータに変換する。ステップＳ７０７では、全てのタイルに対して上記の処理を行ったの判断であり、全タイルを処理するまで、ステップＳ７０２からステップＳ７０７までを繰り返す。実施形態では、タイルが１つの例を説明しているので、ステップＳ７０７からステップＳ７０２に戻ることはなく、次のステップＳ７０８に進む。勿論、原画像が複数のタイルに分割されている場合には、ステップＳ７０２に戻ることになる。ステップＳ７０８では、ステップＳ７０６で変換された符号データを１つの符号データに変換し、新しい符号データを生成する部分である。
【００４５】
次に、上記ステップＳ７０６及びステップＳ７０８の詳細を図８（ａ），（ｂ）のフローチャートに従って説明する。まずステップＳ７０６の符号変換を図８（ａ）のフローチャートに従って説明する。
【００４６】
ますステップＳ８０１において、今回デコードしたタイルの符号化オプションを取得する。具体的には、符号データのMainHeaderとTilePartHeaderの中に入っているCOD,COC、QCD,QCCなどのマーカ・コードを検索し、エンコード時の符号化オプションを取得する。
【００４７】
次いで、ステップＳ８０２では、ステップＳ８０１で取得した符号化オプションの特にＬＬサブバンド部分の符号化オプションにしたがって、先に説明したステップＳ７０３、７０４でデコードした画像データをＥＢＣＯＴ（Embedded Bitplane COding by Truncation）を用いてＬＬ成分として再符号化する。ステップＳ８０３では、ステップＳ８０２で符号化して出力された符号データを取得し、ステップＳ８０４において、旧符号データの階層番号０から階層番号２までの符号データをステップＳ８０３で取得した符号データで置き変える。
【００４８】
次にステップＳ７０８の新符号データ作成の処理を図８（ｂ）のフローチャートにしたがい説明する。
【００４９】
まずステップＳ８０５において、旧符号データのMainHeaderを取得し、ステップＳ８０６で階層数を減らしたことを符号データに反映させるため、旧符号データでは、ＣＯＤマーカ・コード内の“Number of decomposition level”フィールド が「４」となっているところを、「２」に変える。これにより、最低解像度の画像サイズを６４×６４画素から２５６×２５６画素に変更したことになる。次にステップＳ８０７において、新MainHeaderとステップＳ８０４で作成した各タイルの新しい符号データ接合し、新しい１つの符号データを生成する。
【００５０】
サブバンドの具体例は、図４に示すサブバンドのＬＬ(NL=0),ＨＬ(NL=1),ＬＨ(NL=1),ＨＨ(NL=1),ＨＬ(NL=2),ＬＨ(NL=2),ＨＨ(NL=2)で示す７つのサブバンドの符号データをデコードし、それを図１４に示すようにＬＬ(NL=0)’に変換し、その他のHL(NL=3)〜HH(NL=4)は無変換で、符号データを接合し、ハードディスク等に保存することになる（階層数が削減されることになる）
なお、保存する際には、変換前のファイルに上書きしても良いが、予め設定されたフォルダ（ディレクトリ）に保存するようにしても構わない。
【００５１】
これらの処理を行うことにより、図６内の符号データ６０８を符号データ６０９に変換したことになる。すなわち６０２，６０３，６０４の３つの階層の符号データを６０４−１という１つの階層の符号データにまとめ、符号データ内の階層数を削減すると同時に、最低解像度の画像データの画像サイズを上げることができる。
【００５２】
このように階層数を削減することにより、アプリケーションが必要とする最低解像度の画像データに符号データを合わせることにより、次回、ＪＰＥＧ２０００で符号化されている符号データのデコードの時間を短縮することができる。例えば、本実施形態の場合、５１２×５１２画素の画像データをデコードする場合、旧符号データであれば、４種類の階層（６４×６４、１２８×１２８、２５６×２５６、５１２×５１２）をデコードする必要があるが、新符号データの場合は、２種類（２５６×２５６、５１２×５１２）で済むため、デコードのループ回数を削減することができる。
【００５３】
また新しい最低解像度の画像データをデコードするという処理は、アプリケーションで表示する最低解像度の画像データを表示する時に行う処理であるため、特別なデコード処理ではない。よってこの最低解像度の画像データをＬＬサブバンドで再符号化することだけが追加される処理であるが、ＬＬサブバンドでの再符号は、実際のＤＷＴのフィルタリング処理を伴わず、ＥＢＣＯＴによる符号化処理のみであるため、大変高速に処理することができる。
【００５４】
ここまでの実施形態では元々の符号データがタイルに分割されていない場合を説明してきたが、タイル分割されている場合でも処理は同じである。さらにタイル分割されている方が、本実施形態の効果は多きい。すなわち高解像度の画像データを表示する再には、１つのウィンドウ内にその解像度で全体像を１度に表示できないため、画像の一部分のみを表示し、その後、ユーザの操作などで画像をスクロールさせて画像全体を表示することが多い。この場合、タイルに分割されている符号データの場合は、タイル毎にスクロール表示に従ってデコードを繰り返す必要がある。この時、解像度の階層数が少ない方がデコード処理を高速に行える。
【００５５】
なお、上記実施形態では、オリジナルの符号化画像データを再構成する最低解像度（ＬＬ成分）を、画像表示ウインドウのサイズに合わせる例を説明したが、利用者がどの解像度にするかをキーボードから入力したり、或いは、可能なサイズ（解像度）一覧を表示してポインティングデバイスでその中の所望とするものを選択することで決定しても構わない。
【００５６】
＜第２の実施形態＞
上記第１の実施形態では、符号データが自分のコンピュータから直接参照できる位置にある場合を説明したが、本実施例では、サーバ/クライアントシステムの場合でかつ、通信プロトコルにはJPIPを使用し、サーバ側で符号データを変換する場合を説明する。
【００５７】
ＪＰＩＰ／ＪＰＥＧ２０００の符号化データを使えば、ユーザはサーバにある全ての画像データを取得せず、必要な部分のデータのみをサーバから受信することが可能である。ユーザの受信データの単位としては、ＪＰＥＧ２０００のpacket、あるいはpacketよりも大きい符号化単位であるタイル単位が考えられる。ここでは、ユーザがサーバから受信するデータ単位としてpacket単位を想定する。
【００５８】
Packet単位のリクエストおよびレスポンスの概念図を図９に示す。クライアントＰＣ９０１はサーバ９０２に画像のタイル番号とresolution levelとlayer、component、position番号を指定して、データを要求する。サーバ９０２は、画像９０３のコードストリームを解析して、指定されたタイル番号、resolution levelとlayer、component、position番号に相当するpacketデータを抜き出し、クライアントＰＣ９０１に送り返す。
【００５９】
次に、ＪＰＩＰを使ってpacketデータを送信単位として、データを送受信する場合のレスポンスデータの構成を図１０および図１１を使って説明する。
【００６０】
ＪＰＩＰでは、図１０の符号１００１に示すように、precinct data-binと呼ばれるＪＰＥＧ２０００の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 １００１から切り出されたＪＰＥＧ２０００の符号化データが入る。つまり、図１０の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目からのデータであるのかを示す値であり、図１０の符号１００２の値と同じである。message header １１０１の最後のパラメータは、response dataつまり、message body １１０３のバイト長である。つまり、ResLen １１０２には、ResLen[byte] １１０４の値が入る。
【００６４】
本第２の実施形態では、第１の実施形態と同様の符号データがサーバに格納されているものとする。
【００６５】
以下図１２などを用いて、本第２の実施形態の詳細な説明をする。またクライアントは、図５で示す画像表示ウインドウ５０１に画像を表示するための要求を出したところから説明を行う。
【００６６】
すなわちクライアントから、例えば、
http://www.image.com/jpip.cgi?target=d.jp2&fsiz=256,256&type=jpp-stream
いうリクエストをサーバ９０２に発行したとする。ここで、サーバ９０２のアドレスは、「www.image.com」となる。
【００６７】
この場合のサーバでの処理を図１２を用いて説明する。まずステップＳ１２０１で上記のリクエストを受信する。なおこのリクエスト文字列は、“target”によりサーバに格納されているファイル名を指定し、“fsiz”により画像全体の大きさを指定し、“type”により送信データ形式を指定している。
【００６８】
ステップＳ１２０２では前記ステップＳ１２０１で受信したリクエスト文字列を解析する。これにより要求されているファイル名、返送データの形式、返信する画像データのサイズなどの条件を取得することができる。すなわち本第２の実施形態の場合は、ファイル名“d.jp2”という画像ファイルを、画像全体が２５６×２５６画素に収まるサイズになるように要求しており、またその返送形式は、ＪＰＩＰのprecinct data-binである。ステップＳ１２０３では、この条件に当てはまるようにレスポンスデータを生成する部分である。ステップＳ１２０４は、ステップＳ１２０３で生成したレスポンスデータをクライアントに返送する。
【００６９】
上記ステップＳ１２０３の詳細を図１３のフローチャートに従って説明する。このフローは、第１の実施形態で説明した部分と大半が同じあるため、同一の処理には同一の番号を付けている。
【００７０】
まずステップＳ１３０１で今回の要求が、要求するファイルに対して１回目の要求かどうかを判断する。この判断方法は、ＪＰＩＰの通信をステートフルで行う場合は、１回目か否かはその要求のフローの中で簡単に判断できる。一方ステートレスの場合は、サーバのログ情報などを利用することで判断することができる。このような方法を用いて判断する。
【００７１】
このステップ１３０１で２回目以降の要求の場合はステップＳ１３０３へ、１回目の要求の場合は、ステップＳ７０１に進み、返信する画像データを構成するタイル数を計算する。この計算結果からステップＳ１３０２で今回要求されている画像データが画像全域を要求しているかどうかを判断する。ここで画像の一部分の要求であれば、ステップＳ１３０３に進む。
【００７２】
一方、画像全域の場合は、ステップＳ７０２に進む。ここからは、第１の実施形態と同じであり、違いは第１の実施形態であったステップＳ７０５が無くなっていることである。そのため詳細な説明は割愛する。一方ステップＳ１３０３は、通常の返信データの作成であり、要求された画像の符号データを返信するために作成すればよい。
【００７３】
以上説明したように、本第２の実施形態によると、クライアントから１回目の要求で、図１４のＬＬ(NL=0)’に示す部分の符号データをクライアントに返送する。これ以降の階層の符号データの要求に対するサーバの処理に関しては、通常の場合と同じであるため、説明は割愛する。またクライアント側で受信した符号データをキャッシュする必要があるが、この場合は、この１回目の要求でサーバから返送される符号データを元にキャッシュすれば、これまでどおりのキャッシュ方法で実現できる。
【００７４】
これにより、クライアントから１回目の要求で、画像全域を要求するリクエストが来た場合、そのコマンドから、要求を発行したクライアント側のアプリケーションで必要な最低解像度の画像サイズを判断し、その画像サイズを返信する符号データの最低解像度になるように符号データを変換してクライアントに返信することで、返信する符号データのバイト数を削減することができ、ネットワーク上でのトラフィックを下げることができる。更には、受信したクライアントでも第１の実施形態で説明したように、このリクエスト以降のデコード時間を短縮することが可能となる。またＪＰＩＰを利用する場合は、クライアント側で受信した符号データをキャッシュしなければならないが、階層数が削減されるために、キャッシュしなければならないデータ量も削減することができる。
【００７５】
＜第３の実施形態＞
上記第２の実施形態では、クライアントから発行されるリクエスト文字列からサーバ側で、クライアント側のアプリケーションが必要とする最低解像度の画像サイズを推測する場合を説明したが、これにこれに限るものではなく、例えば、サーバとクライアントで画像データを通信する前に、ネゴシエーションする仕組みを付加して、双方で取り決めを行い、その後その結果を基にリクエスト発行、データの返送を行ってもよい。このネゴシエーションは、ＪＰＩＰの“vendor capability”として定義して行うことが可能である。
【００７６】
また、これまでの実施形態では、アプリケーションが必要とする最低解像度の画像サイズと符号データの最低解像度の画像サイズが一致していたが、これに限るものではなく、一致しない場合は、アプリケーションが必要とする最低解像度の画像サイズの画像データを作成するために必要な画像サイズを符号データの最低解像度の画像サイズにすればよいことは容易に推察できる。たとえば、アプリケーションが必要とする最低解像度の画像サイズより大きく、符号データ内の解像度の画像サイズで最低解像度の画像サイズにすればよい。
【００７７】
以上説明したように、本実施形態によれば、アプリケーションが使用する最低解像度の画像サイズに符号データの最低解像度を合わせることができ、デコードにかかる時間を短縮することができる。またアプリケーションは、最初に画像を表示する画像サイズから拡大表示する場合など、符号データ内のどの階層符号データをデコードすればよいかも簡単に判断することができる。
【００７８】
またこの符号変換処理は、画像サイズの小さい画像データを対象に行うため、高速に変換できる。さらにはこの変換処理には、ＤＷＴ（Discrete Wavelet Transform）のＬＬサブバンドデータへの変換であるため、再エンコード時においても、ＤＷＴ処理を行うことなく、符号化処理だけを行えばよい。
【００７９】
更には、符号データをサーバに要求するような場合は、JPIPの仕組みを利用し、サーバがリクエスト文字列を判断することにより、サーバで自動的に判断することも可能である。このためクライアントはサーバで管理されている符号データのエンコード・オプションを意識することなく、アプリケーションが設定する最低解像度の画像データを簡単に入手することができ、さらには階層数を削減することで、サーバから返送する符号の通信量まで削減できる。
【００８０】
あるいは、サーバとクライアント間で画像データの通信の前に、ネゴシエーションすることも可能であり、これを行うことでより正確に双方の状態などを知らせることが可能となる。さらにはこのネゴシエーションには、JPIPの“vendor capability”として実装も可能であり、JPIPの仕組みの範囲内での実装が可能である。
【００８１】
なお、上記実施形態から明らかなように本発明は、コンピュータで実行するコンピュータプログラムがその主要部にあるわけであるから、当然、そのようなコンピュータプログラムは本発明の範疇に入る。また、通常、コンピュータプログラムはＣＤ−ＲＯＭ等のコンピュータ可読記憶媒体に格納されていて、それをコンピュータにセットしてシステムにコピーもしくはインストールすることで実行可能になるわけであるから、当然そのようなコンピュータ可読記憶媒体も本発明の範疇に入る。
【図面の簡単な説明】
【００８２】
【図１】実施形態におけるネットワーク構成を示す図である。
【図２】実施形態におけるクライアントＰＣのブロック構成図である。
【図３】ＪＰＥＧ２０００の符号化データの構造を示す図である。
【図４】ウェーブレット変換によるタイルとサブバンドの概念図である。
【図５】実施形態におけるアプリケーションプログラムを実行した際の表示ウインドウを示す図である。
【図６】実施形態におけるオリジナル符号化データと符号変換後の符号化データの関係を示す図である。
【図７】実施形態における符号変換の処理手順を示すフローチャートである。
【図８】符号変換の詳細を示すフローチャートである。
【図９】ＪＰＩＰPのプロトコルの概念図である。
【図１０】Precinct data-binの概念図である。
【図１１】JPIPレスポンスデータの概念図である。
【図１２】第２の実施形態における符号変換の処理手順を示すフローチャートである。
【図１３】第２の実施形態における符号変換の詳細フローチャートである。
【図１４】符号変換処理におけるサブバンドの概念図である。
【図１】
2006135792.tif 000003
【図２】
2006135792.tif 000004
【図３】
2006135792.tif 000005
【図４】
2006135792.tif 000006
【図５】
2006135792.tif 000007
【図６】
2006135792.tif 000008
【図７】
2006135792.tif 000009
【図８】
2006135792.tif 000010
【図９】
2006135792.tif 000011
【図１０】
2006135792.tif 000012
【図１１】
2006135792.tif 000013
【図１２】
2006135792.tif 000014
【図１３】
2006135792.tif 000015
【図１４】
2006135792.tif 000016