(57)【要約】【課題】  解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルについて、所定の階層位置までの符号化データを復号対象とする処理に特化したデータ構造にすることにより、その処理が多数のデータを扱う場合に高いレスポンスを得る。【解決手段】  ＪＰＥＧ２０００の画像データファイルのサムネイル画像の一覧を表示する際のデコード処理に対して、ユーザが、layer3までの符号化データをデコードし、layer4以上の符号化データは復号しないように設定する。この設定を行なった後、Number of Decompression levels = 5, Number of layers = 4, Losslessモード, Progression order = ＲＬＣＰの条件で符号化したJPEG2000の符号データファイルを入力した場合、layer1乃至3だけの符号化データが並んだ符号列６００と、layer４についての符号データを別々のＢＯＸに格納し、layer４を含めたデコード順をFragment tableに記述し、これらを１つのファイルとして保存する。【選択図】  図６
2006319482.tif 000002
【特許請求の範囲】
【請求項１】
解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルを処理する画像処理装置であって、
所定の階層位置までの符号化データを復号対象として処理する処理手段と、
前記符号化画像データファイルを入力し、当該符号化画像データファイルを、前記処理手段での復号処理用のデータ構造に変換するファイル変換手段とを備え、
当該ファイル変換手段は、
前記符号化画像データファイルから、前記処理手段での復号対象となる符号化データのみで構成され、且つ、前記処理手段で復号する順に並べた第１のデータ構造部分と、
前記処理手段で非復号対象の符号化データで構成される第２のデータ構造部分と、
前記第１データ構造部分に前記第２のデータ構造部分を含めた復号順序を記述した第３のデータ構造部分と
で構成されるファイルに変換することを特徴とする画像処理装置。
【請求項２】
更に、前記処理手段で復号する対象となる階層位置を設定する設定手段を備えることを特徴とする請求項１に記載の画像処理装置。
【請求項３】
前記処理手段は、画像ファイルの一覧を表示するための復号処理であることを特徴とする請求項１又は２に記載の画像処理装置。
【請求項４】
変換元の符号化画像データファイルは、ＪＰＥＧ２０００による符号化データファイルであることを特徴とする請求項１乃至３のいずれか１項に記載の画像処理装置。
【請求項５】
解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルを処理する画像処理装置の制御方法であって、
所定の階層位置までの符号化データを復号対象として処理する処理工程と、
前記符号化画像データファイルを入力し、当該符号化画像データファイルを、前記処理工程での復号処理用のデータ構造に変換するファイル変換工程とを備え、
当該ファイル変換工程は、
前記符号化画像データファイルから、前記処理工程での復号対象となる符号化データのみで構成され、且つ、前記処理工程で復号する順に並べた第１のデータ構造部分と、
前記処理工程で非復号対象の符号化データで構成される第２のデータ構造部分と、
前記第１データ構造部分に前記第２のデータ構造部分を含めた復号順序を記述した第３のデータ構造部分と
で構成されるファイルに変換することを特徴とする画像処理装置の制御方法。
【請求項６】
コンピュータが読込み実行することで、解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルを処理する画像処理装置として機能するコンピュータプログラムであって、
所定の階層位置までの符号化データを復号対象として処理する処理手段と、
前記符号化画像データファイルを入力し、当該符号化画像データファイルを、前記処理手段での復号処理用のデータ構造に変換するファイル変換手段として機能し、
前記ファイル変換手段は、
前記符号化画像データファイルから、前記処理手段での復号対象となる符号化データのみで構成され、且つ、前記処理手段で復号する順に並べた第１のデータ構造部分と、
前記処理手段で非復号対象の符号化データで構成される第２のデータ構造部分と、
前記第１データ構造部分に前記第２のデータ構造部分を含めた復号順序を記述した第３のデータ構造部分と
で構成されるファイルに変換することを特徴とするコンピュータプログラム。
【請求項７】
請求項６に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、階層構造を持った符号化画像データを処理する技術に関するものである。
【背景技術】
【０００２】
近年、パーソナルコンピュータ（以下、ＰＣ）に代表されるコンピュータの表示装置として用いられているディスプレイも技術の進化と共に、その解像度が向上している。例えば従来であれば、ＶＧＡ(640×480画素)、ＳＶＧＡ(800×600画素)程度であった解像度が、現在ではノートＰＣでさえ、ＸＧＡ(1024×768画素)以上になり、ディスクトップＰＣにいたっては、ＳＸＧＡ(1280×1024画素), ＵＸＧＡ(1600×1200画素)が普及しており、更に今後はＱＸＧＡ,ＱＵＸＧＡなどの高解像度をサポートすることは、容易に推察できる。このため、画像表示するディスプレイ装置の種類が多くなり、それぞれの装置に合った画像表示が必要になってきた。特に解像度に関してはディスプレイの解像度に合わせ、サムネイル画像データのサイズを調整することも必要になってきている。
【０００３】
一方、デジタルカメラについても、その撮影できる画像の解像度（画素数）も高くなり、ディスプレイの解像度がいくら高くなっても、撮像画像全体を最大解像度で表示できなくなってきている。そこでデジタルカメラなどで撮影した多数の画像データのサムネイル画像を同時に表示し、その中から選択することで、１枚表示に切り替え、その画像に対してズームやスクロールなどの表示技術により、より詳細な画像データを表示するようなアプリケーションが必要になってきた。この場合、同時に多数の画像データの一覧を一度に表示する場合には、高速性が重要視されるため、主画像データとは異なる予め作成されているサムネイル画像データを用いることが多い。一方そのサムネイル表示から選択された画像データの１枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示し、それ以上の拡大表示になると、画像の一部分を表示することになる。
【０００４】
また、プリンタ技術の進歩により、プリンタで出力できる画像データの解像度も前記デジタルカメラと同様に年々高くなっている。このプリンタで出力できる画像データの解像度は、ディスプレイの解像度よりはるかに高い解像度まで出力できる。このため一般的に、画面上に表示する画像データと印刷するときの画像データは、異なる解像度の画像データを使用する。
【０００５】
このような、１枚の画像データを表示する際に、元々の画像データの画像サイズより小さい画像サイズを使用するようなアプリケーションの場合（画像一覧表示する場合等）、必要に応じてデコード処理を行い、一旦元々の画像データの画像サイズを再生し、その後目的の画像サイズになるように、画像データを縮小することを行っていた。この場合、画像データは、非圧縮か、あるいはＪＰＥＧ Ｂａｓｅｌｉｎｅのようなシーケンシャルの符号化方式で圧縮されているのがほとんどである。また、画像データを階層符号化して圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装することも行われていた。階層符号化としては、ＪＰＥＧ２０００が代表的である。
【０００６】
このＪＰＥＧ２０００は、１枚の画像データを１つ以上のタイルに分割し、その分割されたタイル毎に、１つ以上の解像度等を持つ階層符号化するものであり、２００１年にＩＳＯ／ＩＴＣで標準化された画像符号化技術でもある。
【０００７】
このＪＰＥＧ２０００には、解像度の階層の他に、画質方向の階層もあり、例えば符号データでの最後までデコードするとLossless（可逆）でデコードでき、途中の階層では、Lossy（非可逆）でデコードすることも可能である。このような符号データを表示する時は、画面などに表示する場合は、途中階層まで、すなわちLossyで表示を行い、印刷などのように最終的な出力や、画面上でも拡大表示などでの最高画質での編集というようにある特定の場合のみ、Losslessのデコードを行うという使い方が、デコードの時間などの関係から一般的である。このような階層符号データの格納法として、特許文献１が挙げられる。
【０００８】
この特許文献１は、階層符号データをグループに分け、符号データを記憶媒体に格納するときに、容量等の問題により、書き込めない場合に対応するための技術である。このグループ毎に書き込み位置を変え、特に破棄される優先順位が高いデータを破棄しやすい領域に書き込むものである。
【特許文献１】特開平６−７８１５７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
今、2048×2048画素サイズの画像データをNumber of decomposition levels = 5、Number of layers=3でLossless符号化した解像度スケーラビリティのJPEG2000符号データファイル“A.j2k”があるとする。この場合、ファイル“A.j2k”からは、64×64, 128×128, 256×256, 512×512, 1024×1024, 2048×2048の６種類の異なる解像度の画像データを再現できる。またレイヤ数が３であることから、各解像度の画像データは、３種類の画質の画像データを再現できる。この様なＪＰＥＧ２０００の画像ファイルをデコード/表示するアプリケーション“APP_1.exe”について考察する。このアプリケーションは、画像一覧を表示する際に、256×256画素相当の画像サイズを表示するものとする。
【００１０】
上記条件では、アプリケーションプログラム“APP_1.exe”が画像データを表示する時の処理は、64×64, 128×128, 256×256の３つの解像度の符号データを順にデコードして、デコードされた画像を表示することになる。すなわち、このアプリケーション“APP_1.exe”では、256×256画素以下の解像度の画像データは扱わないので、256×256画素以下の解像度の符号データがある場合は、必ず256×256画素以上の画像データをデコードするまで、デコーダをループさせなければならない。このデコード処理の時に、画面上に一覧表示する場合には、さほど高い画質が望まれないであろうから、Losslessの画質は必要なく、せいぜいLayerは２までで良いと考える。
【００１１】
256×256画素のLayer=2の符号データをデコードすることを考察すると、それまでの解像度（すなわち64×64画素と128×128画素の符号データ）を含め、デコードする際にはLayerは２まででよく、Layer=3の符号データをスキップしてデコードする必要があり、無駄な読込み処理が介在することになり、デコードに時間がかかるという問題がある。
【００１２】
あるいは、128×128画素まではLosslessで、最後の256×256画素の符号データだけLayer=2までというデコード方法もあるが、この場合は、符号データのスキップはないが、余計なLayer=3の部分のデコード処理を行う必要があり、余計に時間がかかるという問題がある。
【００１３】
また先の特許文献１では、符号データを破棄するための技術であり、破棄する場合に格納位置の変更を少なくするためのものである。そのため、メディアの中でどのよう格納するかというための技術であり、１つの階層符号データ内で利用頻度の高い通常の符号データのデコード処理を高速に行うことはできない。
【００１４】
本発明はかかる問題点に鑑みなされたものであり、一覧表示等、複数の画像を一度に処理し、且つ、符号化データファイル中の全符号を復号しないでも構わない処理に好適なデータ構造に変換することで、高いレスポンが期待でき、且つ、全符号を復号する処理も可能にする技術を提供しようとするものである。
【課題を解決するための手段】
【００１５】
この課題を解決するため、例えば本発明の画像処理装置は以下の構成を備える。すなわち、
解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルを処理する画像処理装置であって、
所定の階層位置までの符号化データを復号対象として処理する処理手段と、
前記符号化画像データファイルを入力し、当該符号化画像データファイルを、前記処理手段での復号処理用のデータ構造に変換するファイル変換手段とを備え、
当該ファイル変換手段は、
前記符号化画像データファイルから、前記処理手段での復号対象となる符号化データのみで構成され、且つ、前記処理手段で復号する順に並べた第１のデータ構造部分と、前記処理手段で非復号対象の符号化データで構成される第２のデータ構造部分と、前記第１データ構造部分に前記第２のデータ構造部分を含めた復号順序を記述した全符号復号順序データ部分で構成されるファイルに変換することを特徴とする。
【発明の効果】
【００１６】
本発明の構成によれば、解像度或いは／および画質についての符号化データが階層構造の符号化画像データファイルについて、所定の階層位置までの符号化データを復号対象とする処理に特化したデータ構造にすることにより、その処理が多数のデータを扱う場合に高いレスポンスを得ることができる。
【発明を実施するための最良の形態】
【００１７】
以下、添付図面に従って本発明に係る実施形態を詳細に説明する。
【００１８】
図１は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。同図において、１００はインターネットに代表されるネットワーク、１０１はサーバ・コンピュータ（単にサーバ１０１という）であり、例えば画像データを送信するためのＪＰＧ２０００用の通信プロトコルであるＪＰＩＰサーバをはじめ、ＷＷＷサーバ機能に必要なソフトウエアが実行される。また１０４は大容量の画像データを格納するストレージ装置（実施形態ではＨＤ）であり、ＪＰＥＧ２０００符号化方式で符号化された圧縮画像データが多数保存されている。
【００１９】
１０２及び１０３はクライアント・コンピュータ（以下、クライアントＰＣ）であり、ＷｅｂブラウザをはじめＷｅｂの各ページを表示するために必要なクライアント・ソフトウエアと、実施形態におけるＪＰＥＧ２０００符号化データをデコード/表示するためのクライアント・ソフトウエアならびに、ＪＰＩＰのクライアント機能を実装したソフトウエアなどが実行される。
【００２０】
図２は、図１においてクライアントＰＣのブロック構成図である。図中、２０１はシステム全体の制御などを行っているＣＰＵである。２０２はキーボードで、２０１ａはマウス（登録商標）等のポインティングデバイスであり、共にシステムに情報などを入力するために使用される。２０３は表示部で、ＣＲＴや液晶ディスプレイなどで構成されている。２０４はＢＩＯＳやブートプログラムを記憶しているＲＯＭ、２０５はＲＡＭで、システムの記憶装置を構成し、システムが実行するプログラムやシステムが利用するデータを記憶する。２０６はハードディスク装置であり、ＯＳ、各クライアント・ソフトウエアを格納しており、各種データファイルを記憶するものである。２０７はフロッピー（登録商標）・ディスク装置で、システムのファイルシステムに使用される外部記憶装置を構成している。２０８はプリンタインタフェースである。２０９はネットワークインタフェースであり、ここからインターネットなどのネットワーク上に接続されているサーバ・コンピュータなどのネットワーク上の資源にアクセスする。また、図１におけるサーバ・コンピュータ１０１も基本的には図２で示した構成を持つものであるが、ハードディスクに格納されているＯＳ、アプリケーションはサーバとして機能するものとなる点で異なる。
【００２１】
次に図３を用いて一般的なＪＰＥＧ２０００符号化データの構造を説明する。同図では、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=0)のみでresolution level = 0の解像度の画像となる。そしてHL(NL=1), LH(NL=1), HH(NL=1)の3つのサブバンドをLL(NL=0)に続けてデコードすることでlevel = 1の解像度の画像が生成可能になる。そして、NL=1の解像度の画像とNL=2のサブバンドでlevel = 2の解像度の画像が生成可能となり、NL=2の解像度の画像とNL=3のサブバンドでlevel = 3の解像度の画像、NL=3の解像度の画像とNL= 4のサブバンドでlevel = 4の解像度の画像、というように計５種類の解像度の画像データを再現できる。このようにresolution level番号が1つずつ増加する毎に再現される画像データの画像サイズは、幅、高さ共に２倍になっていく。
【００２３】
図３で示した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から構成されている。
【００２５】
図５にNumber of Decompression levels = 5, Number of layers = 4, Losslessモード, Progression order = ＲＬＣＰの条件で符号化したJPEG2000の符号データの例を示す。図中、各Layerの符号データの中には、Component, Positionの各パケットのデータが入っているものとする。本実施形態では、その説明を簡単にするため、Layerより小さな単位での説明は行わない。またこの符号データの最大解像度の画像サイズが２０４８×２０４８画素である。
【００２６】
各条件の階層符号データからデコードされる各階層の画像サイズは、以下のようになる。
階層番号５：  ２０４８×２０４８画素（最大解像度）
階層番号４：  １０２７×１０２４画素
階層番号３：  ５１２×５１２画素
階層番号２：  ２５６×２５６画素
階層番号１：  １２８×１２８画素
階層番号０：  ６４×６４画素（最小解像度）
【００２７】
さらには、各解像度の画像データは、４つのLayerから構成されているため、最低画質のLayer=0から、最高画質（Lossless）のLayer=4までの画像データを再現することができる。
【００２８】
具体的には、ヘッダ５００で示されるＪＰＥＧ２０００のヘッダ情報中、COD(Coding style default)マーカ・コード内にあるSGcod parameter５０１の“Progression order”フィールド５０１−１がＲＬＣＰ(Resolution level-layer-component-position progression)であることを示す値0x01, “Number of layers”フィールド５０１−２には“４”が入っており、SPcoc parameter５０２の“Number of decomposition levels”フィールド５０２−１には“５”、“Transformation”フィールド５０２−２には“5-3 reversible filter”を示す値0x01が各々格納されている。これらの値で上記のエンコード条件を示すことになる。その他のパラメタは本実施形態では特に関係がないため説明を割愛する。
【００２９】
さて、図１に示すシステムにおいて、サーバ１０１からＪＰＥＧ２０００形式の符号化画像データファイルを、クライアントＰＣ１０２でダウンロードし、ハードディスク２０６に適当なフォルダ（ディレクトリ）内に保存する。なお、ＪＰＥＧ２０００形式の符号化画像データの入力元は図１に示すようにサーバ１０１に限らず、ＣＤ−ＲＯＭ等の記憶媒体であっても構わない（但し、その記憶媒体をアクセスするドライブを必要とする）。
【００３０】
本実施形態では、このクライアントＰＣ１０２に実装するアプリケーションプログラム（ハードディスク２０６にインストールされている）にその特徴を有する。本実施形態におけるアプリケーションは、処理対象となるＪＰＥＧ２０００形式の圧縮符号化された画像ファイル（実施形態ではデジタルカメラで撮像されたものとする）を電子アルバム化（アルバム化アプリケーション）するものであり、外部から入力したＪＰＥＧ２０００の画像ファイルを電子アルバムとして登録し、必要に応じて、登録された画像を編集、印刷するものである。
【００３１】
先に説明したように、一般に、デジタルカメラ等で撮像された画像のサイズ（画素数）は、表示装置の解像度（画素数）と比べて十分に大きい。そこで、登録画像の一覧表示する場合について考察した場合、各画像の内容が確認できれば良く、解像度は適当な段階（階層番号）で良く、また、画質（レイヤ）も適当なものでよい。むしろ、多数の画像が登録され得るので、一覧表示する際の高いレスポンスが求められる。
【００３２】
そこで、実施形態では、図１３に示すように、ＪＰＥＧ２０００のＲＬＣＰ形式の画像ファイル（図示ではファイル名“１００００．ｊ２ｋ”）を、電子アルバムアプリケーションが管理するフォルダ（図示では、“C:\E-Album”）に登録（インポート）する際には、実施形態のアプリケーションで一覧表示する際のデコード処理を高速なものとするため、そのファイル構造を変換し保存する。
【００３３】
例えば、一覧表示する際の画質としてユーザがlayer3までを利用し、それ以上のレイヤを不要にする旨を設定した場合、図５に示すＪＰＥＧ２０００形式のデータ構造を、図６に示す形式のデータに変換する。図６のデータ構造と図５のそれとの違いは、図６では各解像度におけるlayer１〜３が連続して格納されており、layer４の符号がFragment table６０２を介して独立して管理されている点である。画像の編集とか印刷を行なう場合には、図示の矢印６１１で示されるように、読み出すアドレスを頻繁に変更する必要があるが、１つの画像データファイルについてのみ行なえば良いので、人間には知覚できないか、できたとしても許容範囲内のものである。
【００３４】
しかし、一覧表示の場合、表示すべき画像数に依存した回数だけデコードする必要がある。すなわち、表示画像数がＮ個存在する場合、全画像のデコードに要する時間はＮ倍になり、数秒とか数十秒といった無視できない時間がかかることが予想される。実施形態の場合、図６の矢印６１０に示すように、一覧表示する際には利用しないレイヤ４を除いたレイヤ１乃至３を一覧表示に最適化された順序で格納する。この結果、一覧表示の際にスキップ処理等の処理が不要になり、連続した符号をその順序でデコードすれば良いので、そのデコードに要する時間を短縮させることが可能になる。従って、多数の画像データの一覧表示する場合であっても、これまでよりは十分に短時間で、一覧表示させることができ、高いレスポンスを維持することができるようになる。
【００３５】
なお、図５のファイル構造から図６のファイル構造に変換した場合のファイル名の拡張子は「JPX」とするが、ファイルの構造は、ＪＰＥＧ２０００に準拠した構造でもあるので、他のＪＰＥＧ２０００に対応したデコードアプリケーションでデコード可能である。
【００３６】
図１４は実施形態における電子アルバムアプリケーションの全体の処理手順を示すフローチャートである。
【００３７】
先ず、本アプリケーションが起動すると、ステップＳ１４０１で各種初期化を行い、ステップＳ１４０２でアプリケーションウインドウ（不図示）を表示する。このウインドウが表示されると、ステップＳ１４０３に進み、ユーザによるポインティングデバイス２０２ａを用いた処理すべき項目の入力待ちになり、ステップＳ１４０４で指示された処理を判別する。
【００３８】
環境設定が指示された場合には、ステップＳ１４０５に進み、各種環境を設定する。この設定項目の中には、登録画像の一覧表示する際のサイズ、画質の設定が含まれる。
【００３９】
例えば画像サイズとして２５６×２５６にし、レイヤ３とする等でも構わないが、これだと専門的な知識が要求されるので、サイズ、画質ともスライダーバーのようなＵＩを用いて設定する。設定された内容は、実施形態のアプリケーションプログラムが管理する管理用データとして保存する。因に、ＯＳが米国マイクロソフト社が提供するＷｉｎｄｏｗｓ（登録商標）である場合にはレジストリに保存すればよい。なお、これらの値は、ユーザが所有するクライアントＰＣの表示部の解像度に従って、ユーザが任意に設定可能である。
【００４０】
また、電子アルバムへの登録が指示された場合には、ステップＳ１４０６に進んで、登録対象とする画像を選択するためのウインドウを表示し、その中から指示された画像ファイルを、実施形態のアプリケーションが管理するフォルダ（図１３ではc:\E-Album）に、そのファイルを格納する。このとき、登録対象のファイルがＪＰＥＧ２０００符号化されＲＬＣＰ形式の画像データファイルである場合、環境設定された画質に従ってファイル構造を変換する（詳細後述）。
【００４１】
また、一覧表示の指示がなされたと判断した場合には、ステップＳ１４０７に進んで、管理フォルダ内の画像の一覧を表示し、その中の所望とするファイルが選択されたか否かを判断し（ステップＳ１４０８）、選択された場合には該当するファイルを全デコードして画像編集や印刷等の処理を行なう（ステップＳ１４０９）。この画像編集や印刷に関しては、本発明とは直接は関係がないのでその説明は省略する。また、上記以外の操作がなされたと判断した場合には、ステップＳ１４１０に進んで、対応する処理を行なう。
【００４２】
次に、ステップＳ１４０６における登録処理内の変換処理を図７のフローチャートに従って説明する。
【００４３】
先ず、ステップＳ７０１では、指定された画像ファイル（ＪＰＥＧ２０００のＲＬＣＰ形式の階層符号データを持った画像ファイル）のProgression Orderを取得する。具体的には、図５のフィールド５０１−１の値を取得する。
【００４４】
次に、ステップＳ７０２に進み、先に説明した環境設定での画質に関する情報に従って、設定された画質で高速にデコードすることを可能にする新たな形式のファイル構造に変換し、ステップＳ７０３にて、管理フォルダに保存（登録）する。
【００４５】
上記のステップＳ７０２における新階層符号データ作成の詳細を図８のフローチャートに従って説明する。
【００４６】
ステップＳ８００では指定された符号データがタイル分割されているか否か、あるいはタイル分割されている場合は、いくつに分割されているかを計算する。タイル分割されていない場合は、タイル数は１であり、分割されている場合にはその分割数を最大解像度の画像サイズと最大解像度におけるタイルサイズがから計算する。
【００４７】
次いで、ステップＳ８０１に進み、各種階層情報を取得する。具体的には、“Number of decomposition levels”、 “Number of layers”、色数など符号データ内に格納されている全パケット数を計算するために必要な情報や、その他以降の処理で必要な情報を取得する。そして、ステップＳ８０２にて、設定した画質以上の画像データを得るためのパケットを特定する。
【００４８】
具体的には、ユーザが設定した画質に基づく一覧表示時のlayerが“３”である場合には、layerが４以上のパケット全てとなる。このパケットを特定するためには、例えばステップＳ８０１で全パケット数を計算し、このパケット数分の配列を確保し、ここにこのステップで特定されたパケット（layer４以上のパケット）に対応する部分のみ「１」で、その他のパケットには「０」をセットするなど、さまざまな特定方法がある。
【００４９】
ステップＳ８０３では、これから作成する符号データ用のヘッダ情報を作成する。具体的には、本実施形態の場合はLayer ４以上のパケットを別の領域に移すため、Layer数を３に下げる。すなわち、”Number of layers”フィールド５０１−２の“４”を“３”にする。その他のヘッダ情報は変更する必要はない。その後にステップＳ８０４で新符号用パケット抜き出し処理を行い、ステップＳ８０５でファイルを作成し、本処理を終了する。
【００５０】
次に上記ステップＳ８０４の新符号用パケット抜き出しの詳細な処理を図９のフローチャートに従って説明する。
【００５１】
先ず、ステップＳ９００では、ステップＳ８０３で作成した新ヘッダ６０１を”Contiguous Codestream box”に出力する。
【００５２】
ステップＳ９０１では元々符号データに付いていたヘッダ５０４を“Media Data box”に出力する。ステップＳ９０７−１では、ステップＳ９０１で出力した旧ヘッダのバイト数を“fragment table”に各込む。その後ステップＳ９０２及びステップＳ９０３で処理済みタイルの個数用変数“TileNum”、処理済みパケットの個数用変数“PacketNum”をそれぞれ「０」で初期化する。
【００５３】
ステップＳ９０４では、これから処理しようとしているパケットがステップＳ８０２で特定した抜き出し用のパケットであるか否かを判断する。この判断で抜き出し用のパケットであると判断した場合はステップＳ９０５−２へ、一方抜き出し用のパケットではない場合はステップＳ９０５−１へ各々移る。ステップＳ９０５−１では、着目パケットをステップＳ９００で出力したヘッダと同じＢＯＸ、すなわち“Contiguous Codestream box”に出力する。その後ステップＳ９０６−１において、出力したパケットのバイト数を計算する。
【００５４】
一方ステップＳ９０５−２に処理が進んだ場合には、着目パケットをステップＳ９０１で出力したＢＯＸ、すなわち“Media Data box”に出力する。その後、ステップＳ９０６−２にて、ステップＳ９０６−１と同様にパケットのバイト数を、ステップＳ９０６−１とは独立して計算する。具体的には、全ての解像度内の“Layer=４”（かそれ以上）のパケットが抜き出し用パケットとして判断される。
【００５５】
ステップＳ９０７−２では、各ＢＯＸに出力したパケットのバイト数を“fragment table”の形式でそれぞれ格納する。その後ステップＳ９０８では、このタイルにおける全パケットを処理したか否かを判断する。具体的には、変数“PacketNum”に「１」をインクリメントし、この値がステップＳ８０１で取得したパケット総数と比較することで判断する。カウントしたパケット数がパケット総数未満である場合はステップＳ９０４に戻る。また、カウントしたパケット数が、パケット総数になると、注目タイルにおける全パケットについての処理が終了したことになるので、ステップＳ９０９に移る。ステップＳ９０９では、この符号データ内の全タイルを処理したか否かを判断する。具体的には、変数“TileNum”を「１」インクリメントし、この値がステップＳ８００で計算したタイルの総数と比較する。カウントしたタイル数がタイル総数未満の場合はステップＳ９０３に戻る。一方パケット総数以上の場合は全タイルに対して処理が終了したことになり、本処理を終了する。
【００５６】
次にステップＳ９０７−１及びステップＳ９０７−２で示したfragment tableへの書き込みの詳細な処理フローを図１１を用いて説明する。
【００５７】
この処理の中で使用する変数、BoxFlag, TableInxは、あらかじめ特定の値が設定されているものとする。すなわちBoxFlagは、“Contiguous Codestream box”を示す値を「０」、“Media Data box”を示す値を「１」とすると、本処理ではまず“Media Data box”への出力があるので、BoxFlagにはContiguous Codestream boxであることを示す値「０」が入っている。またTableInxは、fragment table内の何番目のテーブルを参照するかの変数であり、これも値「０」が入っている。
【００５８】
ステップＳ１１００では、着目パケットの符号データが出力されたBOXを判断する。すなわちステップＳ９０４で抜き出すパケットと判断した場合は「１」、抜き出さないと判断された場合は「０」となるが、これと変数BoxFlagを比較する。この判断で値が一致するとBOXの変更がないと判断しステップＳ１１０４へ、一方値が不一致の場合はステップＳ１１０１に分岐する。
【００５９】
ステップＳ１１０１では、現状のTableInxが指すFragment table内のOffsetとバイト数の各フィールドに現状の値をセットする。その後ステップＳ１１０２でBoxFlagの値をひっくり返す。すなわち「１」の場合は「０」に、「０」の場合は「１」にする。そしてステップＳ１１０３でTableInxを「１」インクリメントする。
【００６０】
一方ステップＳ１１０４では現状のTableInxが指すバイト数フィールドの値に、今回のパケットのバイト数を加算する。具体的には、旧ヘッダ５０４を出力する場合は、BoxFlagは「０」であり、ステップＳ９０１で“Media Data box”へ出力するため、ステップＳ１１００ではステップＳ１１０１へ移る。その後、旧ヘッダのOffset＝０バイト数をセットし、BoxFlagを「１」にして、TableInxを「１」にする。その後Reso.0のLayer1からLayer3までを出力するが、このLayer 1を出力する時にステップＳ１１００でBOXの変更を判断する。その後Layer 3まではBOXの変更はない。そのため、TableInxのバイト数はLayer1からLayer3までの総バイト数がセットされる。その後、Layer4のパケットを出力する時に、BOXの切替が起こる。この処理により、Fragment table ６０２は、符号６０３で示すように符号データをリードするためのテーブルの値が格納されることになる。
【００６１】
次に、図１４におけるステップＳ１４０４の一覧表示処理を図１０Ａのフローチャートに従って説明する。
【００６２】
先ず、ステップＳ１０００で、本アプリケーションが管理しているフォルダ内に存在するファイル数を取得する。次いで、ステップＳ１００１で、１つのファイルについて、そのヘッダを調べ、そのヘッダに従って符号化データを順に読み出す。図６では、矢印６１０に沿って符号化データを読み出すことになる。このとき、読み出される符号化データは、この矢印の順位格納されているので、高速に読み出しが行なえる。ステップＳ１００２では、読出した順にデコード処理を行い、ユーザが設定したサイズ（解像度）以上になった時点でデコードを終了する。次いで、ステップＳ１００３で、デコードした結果の画像を、本アプリケーションのウインドウ内に表示する。ステップＳ１００４では、デコードしたファイル数が、先のステップＳ１０００で取得したファイル数になったか否かを判断し、否の場合にはステップＳ１００１以降の処理を繰り返す。
【００６３】
以上の結果、本アプリケーションが管理する符号化画像データファイル（拡張子がJXPのファイル）については、高速にその一覧を表示することが可能になる。
【００６４】
さて、一覧表示された画像の１つをユーザがポインティングデバイス２０２ａで指示した場合、その指示された画像を編集や印刷するため、全符号を用いて復号処理を行なう。この場合には、図１０Ｂの処理を行なう。
【００６５】
先ず、ステップＳ１０１０において、指示された画像ファイルのFragment tableを読込み、符号の読込み順を決定し、その順序に従って符号を読み出す。図６の場合には、矢印６１１に示す順序に読み出すことになる。次いで、ステップＳ１０１１にて、読出した符号を順に復号する。この後、ステップＳ１０１２にて、印刷処理を含む編集処理に、デコードした結果を渡し、本処理を終了する。
【００６６】
なお、編集処理については、公知のものであるとし、本実施形態ではその説明は省略する。
【００６７】
図１２にＪＰＥＧ２０００における各ＢＯＸ単位でのファイル構造を示す。図中、１２００は、fragment tableを格納するＢＯＸである。１２０１が通常良く使用する部分の階層符号データを格納するためのContiguous Codestreamを格納するＢＯＸである。１２０２は抜き出したパケット（実施形態ではlayer４以上のパケット）の符号データなどを格納するためのＢＯＸである。
【００６８】
このように、元々の階層符号データのうち、一覧表示等、利用頻度の少ない階層の符号データを取り除き通常良く使う部分のみを連続的に格納した通常階層符号データと、前記通常階層符号データと前記取り除いた階層の符号データを連続的に読み出せる仕組みを利用した特別な階層符号データの両方の符号データ読み出しができる階層符号データの管理をおこなうことにより、通常の表示には通常階層符号データを利用することで、デコード時の余計な符号データのシークや、余計なデコードによる時間の無駄を省くことができるため、高速なデコード処理を行うことができる。
【００６９】
また、通常ではあまり利用しない部分のデータをデコードする場合は、Fragment tableを利用しながら、通常階層符号データをそのまま利用するため、余計な符号データを追加することなく、最大画質（Lossless）の符号データを管理することができる。さらには、fragment tableをしながらのデコード処理は、通常階層符号データのデコード処理よりは処理時間がかかるが、あまり利用しない符号データのデコード時間が多少長くなっても、その為のファイル数は一覧表示の場合と比較して１つとか、せいぜい数個程度であろうから、ユーザにとってのデメリットは少ない。
【００７０】
さらに元々の符号データは、Losslessでエンコードされている場合を説明したが、これに限るものではなく、Lossyでエンコード去れている場合でも、通常の画面に表示する時の画質が符号データ内の途中までの画質でよい場合は、同様に本発明が利用可能となる。
【００７１】
上記実施形態では、１つのfragment tableであったが、複数個のfragment tableを用意し夫々の用途に合わせた読み方ができるようにしてもよいことは容易に推察できる。また、この場合でも各fragment tableから読み出せる複数種類の階層符号データを構成するパケットのデータには重複はなく、必要最低限のファイルサイズで構成することが可能となる。
【００７２】
また、上記実施形態では、変換元の画像ファイルはＲＬＣＰ形式で各符号データが格納されているものとして説明したが、ＬＲＣＰ形式の符号化データに適用しても構わない。
【００７３】
例えば、図１５に示すNumber of Decompression levels = 5, Number of layers = 4, LosslessモードのＬＲＣＰ形式のＪＰＥＧ２０００によるファイル１５００があって、ユーザが一覧表示する際の最低解像度として２５６×２５６を指定したとする。この解像度に合致する符号化データがReso.0〜2である場合には、符号１５０１に示す形式のデータに変換する。一覧表示する際には、図示の符号１５０２で示す順にデコードし、ユーザが設定したlayerまでデコードするようにする。また、画像の編集等の場合には、図示の符号１５０３で示す順にデコードすれば良い。
【００７４】
また、上記実施形態では、１つのファイルで全ての情報を格納するものとしたが、複数のファイルでそれそれのFragment tableを管理し、基本となる符号データを参照することも可能である。この場合、どのfragment tableがどういう符号データをデコードできる符号データを指し示しているかを記述するために、Association BOXを利用して、各fragment tableの意味づけを行うことも可能であり、この場合ファイル中には図１２で示す１２０２の位置に格納すればよい。
【００７５】
また他のProgression Orderで格納されている場合や、上記のProgression Orderの場合でも、最も外側のループをなす階層のエレメント以外のエレメントに関して、同様のことが可能である。
【００７６】
以上説明したように本実施形態によれば、ＪＰＥＧ２０００等の解像度、画質について階層符号化されたデータ構造を有する画像データファイルに対して、一覧表示等、利用頻度が高く一度に複数の画像を処理する場合に備えて、そのデータ構造を変換することで、高いレスポンスの処理が可能になる。
【００７７】
なお、実施形態では、電子アルバムアプリケーションを例にしたが、処理対象となる画像を選択するための一覧表示する処理と、１つの画像を処理する場合の処理とを切り替えるアプリケーションであれば、如何なるアプリケーション（例えば、画像編集アプリケーション等）に適用しても良い。
【００７８】
また、ＰＣの処理速度は、その中のＣＰＵ、メモリ、ハードディスク等の要因によって変わってくる。また、表示するまでの時間に対する時間が遅い／早いの感覚は、ユーザ毎の主観であり、ユーザによって異なる。従って、ＲＬＣＰ構造等のＪＰＥＧ２０００のファイルをｊｐｘファイルに変換する際には、どのレイヤ以上をfragment tableを利用してデコードするかを例えばスライダーバー等でユーザの好みに併せて設定登録するようにしても構わない。
【００７９】
なお、上記実施形態での説明から明らかなように、本実施形態における特徴は、ＰＣ等で実行するアプリケーションプログラムにある。通常、アプリケーションプログラムは、ＣＤ−ＲＯＭ等のコンピュータ可読記憶媒体に格納されていて、それを読み出す装置にセットし、システムにコピーもしくはインストールすることで実行可能になるから、当然そのようなコンピュータ可読記憶媒体も本発明の範疇に入る。
【図面の簡単な説明】
【００８０】
【図１】サーバ、クライアントのシステム構成図である。
【図２】図１におけるクライアントＰＣのブロック構成図である。
【図３】ＪＰＥＧ２０００の符号化データの階層符号化の構造を示す図である。
【図４】ウェーブレット変換とサブバンドとの関係を示す図である。
【図５】ＲＬＣＰデータ構造を示す図である。
【図６】実施形態における２つのデコード順に対処するための符号データのファイルの格納状態を示す図である。
【図７】実施形態における画像データファイルの登録処理時における処理手順を示すフローチャートである。
【図８】図７における新階層符号化データの作成処理手順を示すフローチャートである。
【図９】図８におけるパケット抜き出し処理の詳細を示すフローチャートである。
【図１０Ａ】実施形態における一覧表示時のデコード処理手順を示すフローチャートである。
【図１０Ｂ】実施形態における編集対象画像のデコード処理手順を示すフローチャートである。
【図１１】実施形態におけるfragment tableの作成処理手順を示すフローチャートである。
【図１２】実施形態における変換後のデータ構造を示す図である。
【図１３】実施形態における電子アルバムアプリケーションにおけるインポート処理を概念的に示す図である。
【図１４】実施形態における電子アルバムアプリケーションの全体の処理手順を示すフローチャートである。
【図１５】ＬＲＣＰ構造のデータファイルと、その変換結果の関係を示す図である。
【図１】
2006319482.tif 000003
【図２】
2006319482.tif 000004
【図３】
2006319482.tif 000005
【図４】
2006319482.tif 000006
【図５】
2006319482.tif 000007
【図６】
2006319482.tif 000008
【図７】
2006319482.tif 000009
【図８】
2006319482.tif 000010
【図９】
2006319482.tif 000011
【図１０Ａ】
2006319482.tif 000012
【図１０Ｂ】
2006319482.tif 000013
【図１１】
2006319482.tif 000014
【図１２】
2006319482.tif 000015
【図１３】
2006319482.tif 000016
【図１４】
2006319482.tif 000017
【図１５】
2006319482.tif 000018