JP2007318694A - 画像処理方法、画像処理装置 - Google Patents

Abstract

【課題】 ファイルサイズを大きくせず、かつ、個々のアプリケーションが必要な解像度の画像のみが保存されるようなファイルフォーマットを有する画像ファイルを生成するための技術を提供すること。
【解決手段】 画像を複数のタイルに分割する。それぞれのタイルを複数の解像度で復号可能なように符号化することで得られるそれぞれのタイルの符号化データを含む符号化画像データがグルーピングフォーマットに従っていない場合、それぞれのタイルの符号化データにおいて、指定仕様を有する画像を得るために復号する復号部分を特定し、それぞれのタイルの符号化データにおいて特定した復号部分を、タイルの並び順に並べたデータ群として保持すべく、符号化画像データを再構成する。
【選択図】 図１０

Description

本発明は、複数の解像度で復号可能なように符号化された画像を扱う技術に関するものである。

近年普及したデジタルカメラは画素数も膨大になり、200万画素から500万画素程度のものが一般的になっている。さらに、プロ向けのデジタルカメラになると、1000万画素クラスのものが普及し始め、今後も高精細化が進むことは想像に難くない。

このような大きなサイズを有する画像を扱うアプリケーションでは、複数の解像度データを生成し、一つのファイルに保存することがある。この複数解像度データの保存方法は、主に２つある。

一つは、オリジナルの画像から完全に独立した複数の解像度データを作成し、１つのファイルに保存する方法である。もう一つは、解像度スケーラビリティを持つ符号化方法を用いてオリジナル画像を符号化し、保存する方法である。前者は、デジタルスチルカメラが作成するExif／DCFが、後者は、JPEG2000ファイルフォーマットが例として挙げられる。
特開平０６−０７８１５７号公報

複数の独立したデータを保存する前者の方法を使った例としては、デジタルスチルカメラが作成するExif／DCFなどがある。Exif／DCFでは、オリジナル画像から、サムネイル画像を独立した画像データとして作成し、１つのファイルの中にサムネイル画像とオリジナル画像とを保存している。このように必要な解像度の画像を１つのファイルに保存する場合、アプリケーションが常に利用するサムネイル表示や全画面表示と１対１に対応する解像度の画像のみを保存しているため、アプリケーションが利用しやすい。

しかし、すべての画像が、それぞれが独立した符号化データであるため、冗長なデータも多く含まれる。また、１つのファイルの中に保存される画像サイズの種類が増えると、画像ファイルサイズが大きくなるという問題がある。

解像度スケーラビリティを持つ符号化方法を使って保存する後者の方法としては、たとえば、JPEG2000が挙げられる。JPEG2000符号化方式は、各解像度の間の差分データを使っているので、複数解像度の画像を持っても、そのファイルサイズが大きくなることはない。しかし、JPEG2000では、ある解像度の画像は必ず、それより一つ上の解像度画像の縦横を半分にした大きさになっており、よく利用する解像度以外にも多くの解像度を有している。

また、その符号化データは、自由度が高いため、表示に必要なデータが必ずしも一塊になっておらず、ファイル全体に散逸している可能性もある。そのため、アプリケーションは、必要な解像度の画像を得るために、デコードすべきデータを捜す必要があり、ファイル内のシーク回数が増え、表示時間の短縮は難しい。

高精細画像を扱うアプリケーションが必要とする解像度画像のみを保存しようとすれば、各解像度が独立した画像データとなり、もともとデータサイズの大きい画像データが、さらに大きなデータサイズのファイルとなるという問題が生じる。また、差分データを利用した、解像度スケーラビリティをもつ符号化データを用いて、アプリケーションの必要とする解像度の画像を用意する方法では、ファイルサイズは大きくならないが、不必要な解像度の画像までも用意されることになる。更にこの方法では、アプリケーションが画像を利用するたびに、複数の解像度画像の中から、符号化データを解析して、必要な解像度画像を選択する必要がある。

本発明は以上の問題に鑑みてなされたものであり、ファイルサイズを大きくせず、かつ、個々のアプリケーションが必要な解像度の画像のみが保存されるようなファイルフォーマットを有する画像ファイルを生成するための技術を提供することを目的とする。

本発明の目的を達成する為に、例えば、本発明の画像処理方法は以下の構成を備える。

即ち、画像を複数のタイルに分割し、それぞれのタイルを複数の解像度で復号可能に符号化することにより得られるそれぞれのタイルの符号化データ、を含む符号化画像データを取得する取得工程と、
それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために必要な部分を復号する復号工程と、
前記復号工程により復号されたそれぞれのタイルを出力する出力工程と
を備える画像処理方法であって、
前記取得工程で取得した符号化画像データが第１のフォーマットに従っていない場合には、それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために復号する復号部分を特定する特定工程と、
それぞれのタイルの符号化データにおいて前記特定工程で特定した復号部分を、タイルの並び順に並べたデータ群として保持すべく、前記符号化画像データを再構成する再構成工程と
を備えることを特徴とする。

本発明の目的を達成する為に、例えば、本発明の画像処理装置は以下の構成を備える。

即ち、画像を複数のタイルに分割し、それぞれのタイルを複数の解像度で復号可能に符号化することにより得られるそれぞれのタイルの符号化データ、を含む符号化画像データを取得する取得手段と、
それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために必要な部分を復号する復号手段と、
前記復号工程により復号されたそれぞれのタイルを出力する出力手段と
を備える画像処理方法であって、
前記取得手段が取得した符号化画像データが第１のフォーマットに従っていない場合には、それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために復号する復号部分を特定する特定手段と、
それぞれのタイルの符号化データにおいて前記特定手段が特定した復号部分を、タイルの並び順に並べたデータ群として保持すべく、前記符号化画像データを再構成する再構成手段と
を備えることを特徴とする。

本発明の構成によれば、ファイルサイズを大きくせず、かつ、個々のアプリケーションが必要な解像度の画像のみが保存されるようなファイルフォーマットを有する画像ファイルを生成することができる。

以下添付図面を参照して、本発明を好適な実施形態に従って詳細に説明する。

［第１の実施形態］
図１は、本実施形態に係る画像処理装置に適用可能なコンピュータのハードウェア構成を示すブロック図である。なお、このようなコンピュータとしては、周知のＰＣ（パーソナルコンピュータ）やＷＳ（ワークステーション）が適用可能である。

ＣＰＵ１０１はＲＡＭ１０２にロードされたプログラムやデータを用いてコンピュータ全体の制御を行うと共に、本コンピュータを適用する画像処理装置が行う後述の各処理を実行する。

ＲＡＭ１０２は、ハードディスク１０３からロードされたプログラムやデータを一時的に記憶するエリアや、ＣＰＵ１０１が各種の処理を実行するために使用するワークエリア等を有する。即ち、ＲＡＭ１０２は、各種のエリアを適宜提供することができる。

ハードディスク１０３は、ＯＳ（オペレーティングシステム）や、後述の各処理をＣＰＵ１０１に実行させるためのプログラムやデータを保存するためのものである。このプログラムやデータはＣＰＵ１０１による制御によって適宜ＲＡＭ１０２にロードされ、ＣＰＵ１０１による処理対象となる。

入力デバイス１０４は、例えばマウスやキーボードなどに代表される指示入力装置であって、本コンピュータの操作者が操作することで、各種の指示をＣＰＵ１０１に対して入力することができる。

出力デバイス１０５は、例えばディスプレイやプリンタに代表される装置であって、本コンピュータで処理した画像を表示やプリントアウト等、様々な形態で出力することのできる装置である。

１０６は上記各部を繋ぐバスである。なお、本実施形態に係る画像処理装置に適用可能なコンピュータのハードウェア構成については、図１に示した構成に限定されるものではない。

次に、一般的なＪＰＥＧ２０００に従ったビットストリームについて説明する。図２はＬａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎ（以下、ＬＲＣＰと記す）に従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。ＬＲＣＰに準じた場合、符号化データ（同図において”Ｄａｔａ”で示された部分）は、Ｌａｙｅｒ／Ｒｅｓｏｌｕｔｉｏｎ／Ｃｏｍｐｏｎｅｎｔ／Ｐｏｓｉｔｉｏｎの順にデータが配置された構成を備える。このような構成はｐｒｏｇｒｅｓｓｉｏｎ ｏｒｄｅｒ（プログレッションオーダ）と呼ばれる。また、ここで記されているｐｏｓｉｔｉｏｎとは、ＪＰＥＧ２０００符号化データにおけるｐｒｅｃｉｎｃｔのことである。

同図に示す如く、ＪＰＥＧ２０００に従ったビットストリームは、メインヘッダ（Ｍａｉｎ Ｈｅａｄｅｒ）２０１と、複数のタイルデータと、で構成されている。更に、タイルデータは、タイルヘッダ（Ｔｉｌｅ Ｈｅａｄｅｒ）と符号化データ（Ｄａｔａ）とで構成されている。

メインヘッダ２０１には、resolution level数、layer数等、画像全体の符号化条件が記されている。

タイルデータは、圧縮符号化元の画像を所定のサイズの矩形（タイル）毎に分割し、分割したそれぞれのタイルを符号化することで生成されるものであり、１つのタイルに１つ生成されるものである。従って、ビットストリーム内には、分割したタイルの数だけタイルデータが存在する。タイルデータは、上述の通り、ヘッダ部分（タイルヘッダ）と符号化データ本体部分（符号化データ）とで構成されている。

同図に示す如く、符号化データは大まかにはLayer毎のデータに分けることができる。各Layerのデータは公知のビットプレーン符号化による各ビットプレーンの符号化データであり、ＭＳＢ側のビットプレーン（Ｌａｙｅｒ０）から順にＬＳＢのビットプレーン（ＬａｙｅｒＬ）までが配置される。Layer番号は復元する画像の原画に対するＳ／Ｎ比に対応し、Layer番号が小さいほどＳ／Ｎ比が悪く（低く）なる。すなわち、同図のＪＰＥＧ２０００のデータは、Ｓ／Ｎの悪い順に各Ｌａｙｅｒのデータが配置されていることになる。

更に各Ｌａｙｅｒのデータは各Ｒｅｓｏｌｕｔｉｏｎのデータにより構成されている。各Ｒｅｓｏｌｕｔｉｏｎのデータは解像度（画像のサイズ）に応じたＲｅｓｏｌｕｔｉｏｎ番号に従った順序で配置されている。最も小さい解像度の画像のＲｅｓｏｌｕｔｉｏｎ番号を０とし、Ｒｅｓｏｌｕｔｉｏｎ番号が一つ増加するごとに画像の幅と高さが倍になっていく。各Ｌａｙｅｒ内は、Ｒｅｓｏｌｕｔｉｏｎ番号の小さい順にデータが格納されている。

各Ｒｅｓｏｌｕｔｉｏｎのデータは各Ｃｏｍｐｏｎｅｎｔのデータにより構成されている。各Ｃｏｍｐｏｎｅｎｔのデータは画像の各色データに対応している。例えば画像がＲＧＢの各データにより構成されている場合には、Ｃｏｍｐｏｎｅｎｔ０のデータはＲ成分のデータ、Ｃｏｍｐｏｎｅｎｔ１のデータはＧ成分のデータ、Ｃｏｍｐｏｎｅｎｔ２のデータはＢ成分のデータである。すなわち、Ｃｏｍｐｏｎｅｎｔ数は画像の色空間の次元数に一致する。

また各Ｃｏｍｐｏｎｅｎｔデータには圧縮符号化元の画像における空間的な各位置のデータ（Ｐｏｓｉｔｉｏｎデータ）が順番に記録されている。各Ｐｏｓｉｔｉｏｎデータには、各Resolutionの各タイル内において、空間的な順番通りに番号（ポジション番号）が付けられている。つまり、あるResolutionのタイルの左上隅を０としてタイルの右方向に１つずつ番号が増加し、右端に達したら１つ下、且つ左端からタイルの右方向に番号が増加する。

一つのＪＰＥＧ２０００ファイル内でのＲｅｓｏｌｕｔｉｏｎ番号とレイヤ番号、コンポーネント番号、ｐｏｓｉｔｉｏｎ番号の最大値は、エンコーダによって予め設定されている。圧縮符号化元の画像はそのパラメータに従ってエンコードされており、その情報はメインヘッダに記録されている。また各パケット（ｐａｃｋｅｔ）は、そのパケットに格納されているコードブロック（ｃｏｄｅ−ｂｌｏｃｋ）の情報を管理しているパケットヘッダ（ｐａｃｋｅｔ ｈｅａｄｅｒ）部と、各コードブロックの符号化データから構成されている。同図では１つのＰｏｓｉｔｉｏｎデータがパケットに相当する。この「パケット」なるものは、論理単位の一種である。

ここで、図２では説明を簡単にするために、１つのタイルデータは１まとまりのタイルヘッダと１まとまりの符号化データとで構成されているものとしているが、実際には、１つのタイルデータを複数のタイルパートデータに分割している。

図３（ａ）は、タイルデータを示す図である。同図に示したタイルデータ３００は図２に示したタイルデータと同様の構成を有しており、タイルヘッダ３０１と符号化データ３０２とで構成されている。タイルヘッダ３０１は、タイルＸについて圧縮符号化した場合に得られるヘッダデータで、符号化データ３０２はこの圧縮符号化によるタイルＸの符号化データである。ここで、このタイルＸのタイルデータ３００を３つのタイルパートに分割した場合について図３（ｂ）に示す。

図３（ｂ）は、図３（ａ）に示したタイルデータ３００を３つのタイルパートデータに分割した場合に、それぞれのタイルパートデータの構成例を示す図である。図３（ｂ）に示した３つのタイルパートデータは、図３（ａ）に示した符号化データ３０２を構成する各部分３１０，３１１，３１２のそれぞれを符号化データ部分として保持する。符号化データ部分３１０にはタイルパートヘッダ３２０（タイルパート番号＝０）が付加されている。符号化データ部分３１１にはタイルパートヘッダ３２１（タイルパート番号＝１）が付加されている。符号化データ部分３１２にはタイルパートヘッダ３２２（タイルパート番号＝２）が付加されている。

このように、タイルデータを複数のタイルパートデータに分割する場合には、上述のパケットを単位として分割する。つまり、パケットの途中でタイルデータを分割することはできない。以下では、タイル番号＝ＮのタイルデータをタイルデータＮと呼称する場合があるし、タイルパート番号＝ＮのタイルパートデータをタイルパートデータＮと呼称する場合がある。

図３（ｃ）は、タイルパートヘッダの構成例を示す図である。同図に示す如く、タイルパートヘッダには、タイル番号、タイルパートのデータ長、タイルパート番号、このタイル中におけるタイルパート総数（いくつのタイルパートに分割したか）が記述されている。

図４（ａ）は、ビットストリーム中における各タイルパートデータの配置例を示す図である。同図ではメインヘッダの直後に、各タイルデータにおけるタイルパートデータ０がタイル番号順に配置されている。即ち、タイルデータ０のタイルパートデータ０，タイルデータ１のタイルパートデータ０，タイルデータ２のタイルパートデータ０がこの順に配置されている。もちろん、タイルの数が３以上であれば、それ以降のタイルデータのタイルパートデータ０がこれに後続して配置される。

そして次に、各タイルデータにおけるタイルパート１のデータがタイル番号順に配置されている。即ち、タイルデータ０のタイルパートデータ１，タイルデータ１のタイルパートデータ１，タイルデータ２のタイルパートデータ１がこの順に配置されている。もちろん、タイルの数が３以上であれば、それ以降のタイルデータのタイルパートデータ１がこれに後続して配置される。

このように、同図では、各タイルデータから同じタイルパート番号を有するタイルパートデータを抽出し、抽出したタイルパートデータを自身が属するタイルデータのタイル番号の小さい順に並べてビットストリーム中に配置する。また、同じタイルパート番号を有するタイルパートデータ群は、タイルパート番号の小さい順に配置される。

図４（ｂ）は、タイルパートデータがランダムにビットストリーム中に配置されている場合のビットストリームの構成例を示す図である。

次に、ＪＰＥＧ２０００のファイルフォーマットについて説明する。図５は、ＪＰＥＧ２０００のファイルフォーマットの概略を示す図である。

ISO／IECでは、ＪＰＥＧ２０００ビットストリームを格納するファイルのフォーマットをオプショナルとして定義している。JPEG 2000 Part 1で定義しているファイルフォーマットは、JP2ファイルフォーマットと呼ばれている。JP2ファイルフォーマットは、"box structure"と呼ばれる構造を持つ。これは、boxと呼ばれるデータ単位を積み重ねることで構成されるフォーマットである。

JPEG 2000符号化データも、JP2ファイルフォーマットの中では、Contiguous Codestream boxと呼ばれる一つのboxに格納される。また、boxのコンテンツとして、複数のboxを格納しているboxも存在する。このようなboxをsuper boxと呼ぶ。JP2ファイルフォーマットで定義されているJP2 Header boxもその一つである。このJP2 Header boxには、画像の基本情報を格納しているImage Header box, 色空間を指定するColour Specification boxなどがコンテンツとして格納される。

図5に示されるboxは、JP2ファイルフォーマットで定義されている必須boxである。この他に、XML boxやuuid boxが規定されている。JP2ファイルフォーマット内のBoxの格納順番は、JPEG2000 Signature boxがファイルの先頭に格納され、その直後に、File Type boxを格納することは決められている。その他のboxの格納順番は、基本的に自由に決められる。したがって、同じ種類のboxを持つ2つのファイルがあっても、そのboxの格納順番が異なることもある。

図６は、ボックスの基本構成を示す図である。Box Length601にbox全体のデータ長のバイト数が格納されており、Box Type 602にはこのboxのタイプが格納されており、Box contentsにはこのボックスに対して定義されたデータが格納されている。

Box Length 601とBox Type 602とを合わせて、Box Headerと呼ぶ。たとえば、”JPEG 2000 Signature box”であれば、Box Typeの値は’jp(スペース)(スペース)’(0x6A50 2020)で、’Box contentsとして、4バイトのデータ(0x0D0A 870A)を格納する。よって、Box Length 601には、12(=0x0000 000C)、Box Type 602には、’jp ‘(=0x6A50 2020)、Box Contents 603には、0x0D0A 870Aが格納されることになる。

次に、操作者から指示された解像度で画像を表示する為に、本実施形態に係る画像処理装置が行う処理について説明する。この説明では、操作者は、図７（ａ）〜７（ｃ）に示す３種類の画像表示形態のうち何れかの表示形態（解像度）を指示するものとする。

図７（ａ）は、ハードディスク１０３に保持されているそれぞれの画像（実際にはビットストリーム）のサムネイルを一覧表示している場合の表示例を示している。サムネイルのサイズは、２５６画素×２５６画素相当のサイズとする。ここで「相当」としているのは、ハードディスク１０３に保持されているオリジナルの画像のアスペクト比によっては、必ずしも２５６画素×２５６画素のサイズには成らない場合があるからである。例えば、４９９２画素×３３２８画素のサイズの画像のサムネイルのサイズは、２５６画素×１７０画素となる。

同図の画面で１つのサムネイルを操作者が入力デバイス１０４を用いて指示すると、図７（ｂ）に示す如く、指示した画像を、出力デバイス（ここでは表示装置）１０５の表示画面のサイズに合わせて表示（全画面表示）する。または、図７（ｃ）に示す如く、出力デバイス１０５の表示画面上に等倍のサイズで表示する。何れの表示を行うのかは、操作者が指示する。

図７（ｂ）は、指示された画像を全画面表示した場合の表示例を示す図である。本実施形態では説明上、出力デバイス１０５の表示画面のサイズは、１９２０画素×１２００画素とする。従って、画像を全画面表示する場合には、この画像を１９２０画素×１２００画素にリサイズしてから表示する必要がある。

図７（ｃ）は、指示された画像を等倍表示した場合の表示例を示す図である。本実施形態では説明上、指示した画像のオリジナルのサイズは、４９９２画素×３３２８画素であるとする。

図８は、出力デバイス１０５の表示画面上に画像を表示する為に画像処理装置が行う処理のフローチャートである。なお、同図のフローチャートを含め、以下説明する各フローチャートに従った処理を画像処理装置に実行させるためのプログラムやデータはハードディスク１０３に保存されている。このプログラムやデータはＣＰＵ１０１による制御に従って適宜ＲＡＭ１０２にロードされる。ＣＰＵ１０１はこのロードされたプログラムやデータを用いて処理を実行することで、画像処理装置は以下説明する各処理を実行することになる。

画像処理装置の操作者が入力デバイス１０４を用いて、画像表示に係る指示（表示対象の画像とその表示サイズ（表示形態）の指示を含む）を入力すると、ステップＳ８０１では、ＣＰＵ１０１はこの指示から、表示対象の画像とその表示サイズを取得する。

例えば、図７（ａ）に示した表示形態が指示された場合には、表示対象の画像は、ハードディスク１０３に保持されている全ての画像であり、個々の画像の表示サイズは２５６画素×２５６画素相当である。図７（ｂ）に示した表示形態が指示された場合には、表示対象の画像も指示することになるので、この指示された画像を表示対象とするし、表示サイズは１９２０画素×１２００画素である。図７（ｃ）に示した表示形態が指示された場合には、表示対象の画像はこの表示を指示したときに指示した画像若しくは従前に全画面表示されている画像を表示対象とするし、表示サイズは４９９２画素×３３２８画素である。

以下の説明では一例としてサムネイル表示（図７（ａ）に示した表示形態）が指示されたものとする。この場合、ステップＳ８０１では、表示対象の画像としてハードディスク１０３に保持されている全ての画像を選択するし、表示サイズを２５６画素×２５６画素相当として設定する。

次に、ステップＳ８０２では、ステップＳ８０１で表示対象として選択された画像のビットストリームのフォーマット（画像フォーマット）を判別する。この判別処理の詳細については図９を用いて後述する。

そして、ステップＳ８０２での判断別処理の結果、画像フォーマットが後述するグルーピングフォーマットである場合には処理をステップＳ８０３を介してステップＳ８０４に進める。もし、グルーピングフォーマットではない場合には処理をステップＳ８０３を介してステップＳ８１０に進める。

ステップＳ８０４では、ビットストリーム中のuuid boxからタイルパート情報を読み出す。本実施形態では、画像フォーマットがグルーピングフォーマットである場合、後述するステップＳ８１３による処理で、このuuid box内にタイルパート情報が格納される。従って、ステップＳ８０４では、このuuid box内に格納されたタイルパート情報を読み出すことができる。このタイルパート情報は図１１（ｂ）に示す構成を有する。図１１（ｂ）は、タイルパート情報の構成を示す図である。本実施形態ではこのような構成を有するタイルパート情報として、図１１（ｃ）に示したものを用いるものとする。そしてこのタイルパート情報を読み出すことで、ビットストリーム中のタイルパートについては以下の情報が得られるものとする。

タイルパート数は３
タイルパートデータ０を復号することで得られる画像のサイズは３１２画素×２０８画素
タイルパートデータ１を復号することで得られる画像のサイズは２４９６画素×１６６４画素
タイルパートデータ２を復号することで得られる画像のサイズは４９９２画素×３３２８画素
図８に戻って、次にステップＳ８０５では、この３つのタイルパートデータのうち、何れを復号するのかを、ステップＳ８０１で設定した表示サイズに基づいて決定する。ここでは、ステップＳ８０１において表示サイズとして２５６画素×２５６画素相当が設定されたので、これに最も近いサイズである３１２画素×２０８画素の画像を復号すべく、タイルパートデータ０を復号対象として決定する（Ｘ＝０）。

ステップＳ８０６では、ビットストリーム中の全てのタイルのうち、復号するタイルDispTを決定する。ここでは、サムネイル、即ち、画像を構成する全てのタイルを表示することになるので、必然的にビットストリーム中の全てのタイルを復号対象とすることになる。仮に、出力デバイス１０５の表示画面のサイズが１５００画素×１０００画素であり、１つのタイルのサイズが５１２画素×５１２画素であり、表示対象の画像を等倍表示する場合には、縦３つ、横２つの合計６つのタイルを表示する必要がある。この場合、この６つのタイルがDispTとなる。この復号対象タイルDispTの求め方については、ここでの説明の趣旨ではないので、その説明は省略する。

次にステップＳ８０７では、ステップＳ８０６で復号対象として決定したタイルのそれぞれについて、ステップＳ８０５で決定したタイルパートデータのみを復号する処理を行う。ここでは、全てのタイルについてタイルパートデータ０を復号すると決定したので、この決定したタイルパートデータを復号する。これにより、３１２画素×２０８画素の画像が得られる。

そしてステップＳ８０８では、復号した画像のサイズが２５６画素×２５６画素相当となるようにリサイズし、ステップＳ８０９では、このリサイズした画像を出力デバイス１０５の表示画面上に表示する。

一方、ステップＳ８１０では、表示対象の画像のビットストリームをデコードし、表示対象の画像を復元する。なお、このデコードの際には、ビットストリームを一端コピーし、このコピーしたビットストリームをデコードする。つまり、ビットストリームのデータは後述するステップＳ８１３における処理対象となるので、そのまま残しておく。

上述の通り、この復元した画像のオリジナルのサイズは４９９２画素×３３２８画素である。従ってステップＳ８１１では、この復元した画像のサムネイルを表示するために、この画像のサイズを２５６画素×２５６画素相当にリサイズする。実際にはこの画像は２５６画素×１７０画素のサイズにリサイズされることになる。

そしてステップＳ８１２では、このリサイズした画像をサムネイルとして出力デバイス１０５の表示画面上に表示する。そして、ステップＳ８１３では、ステップＳ８１０でデコードした画像のビットストリームを再構成し、そのフォーマットをグルーピングフォーマットに変換する。ステップＳ８１３における処理の詳細については図１０を用いて後述する。

図９は、上記ステップＳ８０２における判別処理の詳細を示すフローチャートである。

先ず、ステップＳ９０１では、表示対象の画像のビットストリームの拡張子を取得する。ステップＳ９０２では、この取得した拡張子が”.jp2”であるのか否かをチェックする。このチェックの結果、拡張子が”.jp2”であれば、処理をステップＳ９０３に進め、その他の拡張子であれば処理をステップＳ９０６に進める。ステップＳ９０６では、この画像のビットストリームのフォーマットがグルーピングフォーマットではないと判断し、処理を上記ステップＳ８０３にリターンする。

一方、ステップＳ９０３では、ビットストリーム（jp2ファイル）の中に、uuid boxが格納されているか否かをチェックする。格納されている場合には処理をステップＳ９０４に進めるし、格納されていない場合には処理をステップＳ９０６に進める。

ステップＳ９０４では、uuid boxのIDがグルーピングフォーマット識別子と一致しているか否かをチェックする。

図１１（ａ）は、uuid boxのBox Contents６０３のフォーマットを示す図である。上記ステップＳ９０４では、16[Byte]のID 1101の値を参照し、この値がグルーピングフォーマットを示すものであるのか否かをチェックする。本実施形態では、グルーピングフォーマットのIDの値は図１１（ｃ）に示す如く、「0x6369 7A65 6772 6F75 7065 666F 726D 6174」としている。よって、ID 1101の値が「0x6369 7A65 6772 6F75 7065 666F 726D 6174」と一致すれば、uuid boxのIDがグルーピングフォーマット識別子と一致しているので、処理をステップＳ９０５に進める。一方、一致していない場合には処理をステップＳ９０６に進める。

ステップＳ９０５では、表示対象の画像のビットストリームのフォーマットはグルーピングフォーマットであると判断し、処理を上記ステップＳ８０３にリターンする。

図１０は、上記ステップＳ８１３における処理の詳細を示すブロック図である。

先ず、ステップＳ１００１では、上記ステップＳ８１０で行ったデコードがＪＰＥＧ２０００に従ったものであるのか否かをチェックする。即ち、表示対象の画像のビットストリームがＪＰＥＧ２０００に従ったものであるのか否かをチェックする。

このチェックの結果、ＪＰＥＧ２０００に従ったものではない場合には処理をステップＳ１００２に進める。ステップＳ１００２では、上記ステップＳ８１０でデコードした画像に対してＪＰＥＧ２０００に従った圧縮処理を行うことで、表示対象の画像のビットストリームを新たに生成する。この圧縮処理では以下のようなビットストリームを生成する。

最高解像度時のタイルサイズ：５１２画素×５１２画素
Layer数：１
Position数：１タイルにつき１position
Resolution level：最小解像度時の画像サイズがサムネイルサイズ相当となるまで、離散ウェーブレット変換処理を繰り返す
Progression order：RLCP
本実施形態の場合には、オリジナル画像の横サイズが４９９２画素であるため、横サイズが５１２のタイルを横に並べると１０個必要となる。またオリジナル画像の縦サイズが３３２８画素であるため、縦サイズが５１２のタイルを縦に並べると７個必要となる。よって１０×７＝７０となり、タイル数は７０である。また、resolution level数は５になる。

また、表示対象の画像のビットストリームがＪＰＥＧ２０００に従ったものであったとしても、本実施形態では、最高解像度時のタイルサイズを５１２画素×５１２画素、ビットストリームを復号したときの最小画像サイズを３１２画素×２０８画素としている。従って、タイル数は70、resolution level数は5になる。

一方、上記ステップＳ１００１におけるチェックの結果、上記ステップＳ８１０で行ったデコードがＪＰＥＧ２０００に従ったものである場合には処理をステップＳ１００３に進める。

ステップＳ１００３では、上記ステップＳ８１０でデコードした元のビットストリーム中のメインヘッダを参照し、このビットストリームを復号した場合に得られる最小サイズ（最小解像度）の画像が、サムネイルサイズよりも小さいか否かをチェックする。即ち、このビットストリームを復号することで、要求される最小サイズの画像が得られるのか否かをチェックする。

要求される最小サイズ（サムネイルサイズ）の２倍未満の画像サイズが、ビットストリームを復号することで得られるのであれば、このビットストリームを復号した場合に得られる最小サイズ（最小解像度）の画像が、サムネイルサイズよりも小さいと判断する。本実施形態の場合には、サムネイルサイズは２５６画素×２５６画素相当である。従って、resolution level 0の画像サイズが５１１画素×５１１画素以下のサイズであれば、このビットストリームを復号した場合に得られる最小サイズ（最小解像度）の画像が、サムネイルサイズよりも小さいと判断する。Resolution level 0の画像サイズは、JPEG2000のメインヘッダを解析することで用意に計算できる。

ビットストリームを復号した場合に得られる最小サイズ（最小解像度）の画像が、サムネイルサイズよりも小さくない場合には処理をステップＳ１００２に進め、上記処理を行う。一方、最小解像度がサムネイルサイズよりも小さい場合には、処理をステップＳ１００４に進める。

ステップＳ１００４では、ビットストリームのメインヘッダ、及び各タイルのヘッダを参照し、ビットストリームのprogression orderがRLCPの順になっているか否かをチェックする。このチェックの結果、RLCPであれば処理をステップＳ１００６に進め、ＲＬＣＰではない場合には処理をステップＳ１００５に進める。ステップＳ１００５では、ビットストリーム中のパケットデータを並び替え、progression orderをRLCPにし、main headerのprogression order情報をRLCPに書き換える。

次に、ステップＳ１００６では、全ての表示形態における表示サイズを取得する。本実施形態の場合、全ての表示形態は図７（ａ）〜７（ｃ）に示した３種類の表示形態であり、それぞれの画像表示サイズは、２５６画素×２５６画素相当、１９２０画素×１２００画素、４９９２画素×３３２８画素である。従って本実施形態では、この３種類の表示サイズを取得する。例えば、全画面表示における画像表示サイズの取得を、Ｃ言語でインプリメントされたプログラムを実行することで取得する場合には、以下のコード
SystemParametersInfo(SPI_GETWORKAREA, 0, &rect, 0);
等を用いる。

ステップＳ１００７では、ステップＳ１００６で取得した各表示サイズと、resolution levelとの対応付けを行う。本実施形態では、表示対象の画像の元のサイズは４９９２画素×３３２８画素であり、ビットストリームを復号したときの最小画像サイズが３１２画素×２０８画素である。よって、この画像に対して４レベルの離散ウェーブレット変換処理が施されていることになる。従って、resolution levelと画像サイズとの関係は以下のようになる。

resolution level 0： ３１２画素× ２０８画素
resolution level 1： ６２４画素× ４１６画素
resolution level 2：１２４８画素× ８３２画素
resolution level 3：２４９６画素×１６６４画素
resolution level 4：４９９２画素×３３２８画素
これにより、この画像のサムネイル表示を行う場合には、resolution level０を復号すれば良いし、この画像の全画面表示を行う場合には、resolution level０に加えてresolution level１，resolution level２、resolution level３を復号すればよいし、この画像の等倍表示を行う場合には、resolution level０、１，２，３に加えてresolution level４を復号すればよい。従って、サムネイル表示にはresolution level０が対応するし、全画面表示にはresolution level３が対応するし、等倍表示にはresolution level４が対応する。ステップＳ１００７ではこの対応付けを決定する。

ステップＳ１００８では、各タイルデータを複数のタイルパートデータに分割し、それぞれのタイルパートデータを図４（ａ）に示す如く配置する。即ち、全てのタイルパートデータを同じタイルパート番号を有するタイルパートデータ毎にグループ分割し、それぞれのグループをタイルパート番号の小さい順に配置する。グループ内におけるタイルパートデータは、自身が属するタイルデータのタイル番号の小さい順に配置される。

本実施形態では、タイルパートデータ０にはresolution level 0のデータを格納し、タイルパートデータ１には、resolution level 1, 2, 3のデータを格納し、タイルパートデータ２にはresolution level 4のデータを格納する。以上のようにして、画像のビットストリームを再構成する。

図１２は、上記ステップＳ１００８における処理の結果、再構成されたビットストリームの構成を示す図である。

同図に示す如く、各タイルデータにおけるタイルパートデータ０のデータ群１２０１，タイルパートデータ１のデータ群１２０２、タイルパートデータ２のデータ群１２０３がこの順にビットストリーム中に配置されている。

また、データ群１２０１内には、タイルデータ０におけるタイルパートデータ０、タイルデータ１におけるタイルパートデータ０、、、タイルデータ６９におけるタイルパートデータ０がこの順に配置されている。また、同図に示す如く、タイルデータ１におけるタイルパートデータ０内には、タイルパートヘッダとタイルデータ１におけるresolution level 0のデータとが格納されている。このように、タイルデータＸにおけるタイルパートデータ０内には、タイルパートヘッダとタイルデータＸにおけるresolution level 0のデータとが格納されている。

また、データ群１２０２内には、タイルデータ０におけるタイルパートデータ１、タイルデータ１におけるタイルパートデータ１、、、タイルデータ６９におけるタイルパートデータ１がこの順に配置されている。また、同図に示す如く、タイルデータ１におけるタイルパートデータ１内には、タイルパートヘッダとタイルデータ１におけるresolution level１，２，３のデータとが格納されている。このように、タイルデータＸにおけるタイルパートデータ１内には、タイルパートヘッダとタイルデータＸにおけるresolution level１，２，３のデータとが格納されている。

また、データ群１２０３内には、タイルデータ０におけるタイルパートデータ２、タイルデータ１におけるタイルパートデータ２、、、タイルデータ６９におけるタイルパートデータ２がこの順に配置されている。また、同図に示す如く、タイルデータ１におけるタイルパートデータ２内には、タイルパートヘッダとタイルデータ１におけるresolution level４のデータとが格納されている。このように、タイルデータＸにおけるタイルパートデータ２内には、タイルパートヘッダとタイルデータＸにおけるresolution level４のデータとが格納されている。

なお、各タイルパートヘッダは、基本的には、タイルパートデータ長Psot、tile-part番号Tpsot、tile-part総数Tnsotの３つのデータを使って容易に作成できる。

以上のようにして、ビットストリームをグルーピングフォーマットに従ったものに再構成することができる。

図１０に戻って、次にステップＳ１００９では、タイルパート情報、即ち、タイルパート数と各タイルパートの画像サイズを上記uuid boxに書き込む。本実施形態では、図１１（ｃ）に示すuuid boxがJP2ファイルの中に書き込まれる。

このように、全ての表示形態それぞれが要求する表示サイズ毎に、タイルパートを使って解像度データをグループ化することで、低・中解像度の全体画像を表示する際には、シーク回数を削減し、表示までの時間を短縮することができる。

また、タイルパート情報をファイルの中に保存することで、メインヘッダを解析し、各タイルパートのパケット数を調べなくても、必要な画像サイズを得るためのタイルパート数が容易に分かる。

さらに、タイル分割しておくことで、高解像度で画像の一部分しか表示しない場合には、タイル単位で必要な部分をデコードすればよいので、高解像度部分のランダムアクセス性を確保でき、表示までの時間の短縮が期待できる。

また、uuid boxの中に格納するため、その識別子を見るだけで、このファイルの構成が、解像度毎のタイルパートに分割されており、ファイルの中にタイルパートが昇順で並んでいることがわかる。さらに同じ理由で、各タイルパートはタイル番号の昇順に並んでいることも分かる。アプリケーション側で、目的の解像度のデータをデコードする際に、符号化データの先頭から順にデコードすればよいので、ファイル内のシーク回数が減り、表示までの時間が短縮される。

さらに、以上の処理で再構成されたビットストリームは、JPEG2000のJP2ファイルフォーマットに準拠しているため、このフォーマットを知らない端末・アプリケーションがこのデータを受け取っても、画像のデコードに影響はない。

なお、本実施形態で用いた表示画像サイズや、各resolution levelにおける画像サイズ等、説明上用いた具体的な数値についてはあくまで一例であり、本実施形態はこれらの数値に限定されるものではない。

また、上記説明による処理は、表示形態が複数ではなく、１つの場合であっても適用可能である。

また、上記３つの表示形態の何れで画像を表示するのかを指定する形態については操作者がアプリケーションを操作することで、アプリケーションがその操作に応じた表示形態に切り替えても良いし、操作者がダイレクトに指定しても良い。即ち、その指定方法は限定するものではなく、どのように指定しても良い。

［第２の実施形態］
第１の実施形態では、図８のフローチャートにおけるステップＳ８０２でビットストリームがグルーピングフォーマットであると判断した場合には、このビットストリームにおいて、要求された表示の為に復号すべき部分を復号し、復号した結果を表示していた。

画像データを一つの端末・アプリケーションで利用する場合には常に、その端末・アプリケーションに最適化されたフォーマットであるので、第１の実施形態に係る処理でじゅうぶんである。しかし、このフォーマットに準拠したファイルを、他の端末・アプリケーションで利用するときには、修正した方が使いやすい事もある。

本実施形態では、第１の実施形態に係る処理で再構成されたビットストリームを、表示画面サイズが１０２４画素×７６８画素であるノートＰＣに入力し、この表示画面にこのビットストリームに基づいた画像を表示する。以下ではこの状況を想定し、事前に画像処理装置側で行う処理について説明する。ここで、第１の実施形態に係る処理で再構成されたビットストリームに係る情報は以下の通りである。

画像サイズ：4992×3328[pixel]
タイルサイズ：512×512[pixel]
resolution level数：5
resolution level 0の画像サイズ：312×208[pixel]
resolution level 1の画像サイズ：624×416[pixel]
resolution level 2の画像サイズ：1248×832[pixel]
resolution level 3の画像サイズ：2496×1664[pixel]
resolution level 4の画像サイズ：4992×3328[pixel]
タイルパートデータ０はresolution level 0のデータを格納
タイルパートデータ１はresolution level 1, 2, 3のデータを格納
タイルパートデータ２はresolution level 4のデータを格納
また、本実施形態においても、全ての表示形態は、図７（ａ）〜７（ｃ）に示すものとする（しかし、全画面表示では、ノートＰＣの画面サイズ（１０２４画素×７６８画素）に対して全画面表示を行う）。また、以下の説明では、第１の実施形態と同じ画像処理装置を用いるものとし、特に本実施形態が第１の実施形態と同じものについては説明を省略し、異なる点については詳細に説明する。これは以下の各実施形態についても同様である。

図１３は、出力デバイス１０５の表示画面上に画像を表示する為に画像処理装置が行う処理のフローチャートである。同図のフローチャートにおいて、図８に示したステップと同じものについては同じステップ番号を付け、その説明は省略する。即ち、図１３のフローチャートが図８に示したフローチャートと異なる点は、ステップＳ８０９の次に、ステップＳ１３０１，Ｓ１３０２の処理を実行する点のみである。従って以下では、このステップＳ１３０１，Ｓ１３０２について説明する。

ますステップＳ１３０１では、上記ステップＳ８０８で行ったリサイズによる拡大／縮小率が５０％以下であるか、若しくは２００％以上であるのかをチェックする。このチェックの結果、拡大／縮小率が５０％から２００％である場合には本処理を終了する。一方、拡大／縮小率が５０％以下であるか、若しくは２００％以上である場合には処理をステップＳ１３０２に進める。

ここで、JPEG2000では、resolution levelの番号が一つ小さくなると、画像のサイズが半分になる。従って、あるresolution levelにおける画像を２倍以上拡大すること、若しくは１／２倍以下に縮小することは、別のresolution levelにおける画像を使用することに他ならない。従って、上記ステップＳ８０５でデコード対象のタイルパートデータを選択したにもかかわらず、これを２倍以上拡大した、若しくは１／２倍以下に縮小したということは、デコード対象のタイルパートの構成そのものが間違いとなる。本実施形態の場合、上記ステップＳ８０８でタイルパートデータ２を復号して表示しようとすると、表示画像サイズが２４９６画素×１６６４画素となるが、ノートＰＣの画面サイズが１０２４画素×７６８画素であるので、画像を約40%に縮小する必要がある。

従って、このよう場合には処理をステップＳ１３０２に進める。ステップＳ１３０２では、再度タイルパート分割処理を行うと共に、タイルパート情報において該当する箇所の更新を行う。

図１４は、ステップＳ１３０２における処理の詳細を示すフローチャートである。

先ずステップＳ１４０１では、全ての表示形態（表示サイズ）の数Ｋを取得する。本実施形態の場合、全ての表示形態は図７（ａ）〜７（ｃ）に示した３種類の表示形態であるので、Ｋ＝３となる（しかし、全画面表示では、ノートＰＣの画面サイズ（１０２４画素×７６８画素）に対して全画面表示を行う）。

次にステップＳ１４０２では、タイルパートデータの数をカウントするために用いる変数ＴＰｎを０に初期化すると共に、上記表示サイズの数をカウントするために用いる変数Ｋｘを１に初期化する。

ステップＳ１４０３では、タイルパートデータＴＰｎを復号した場合に得られる画像のサイズを、Ｋｘ番目に小さい表示サイズで割った結果の小数点以下を切り捨てた結果Ａを求める。より具体的には、タイルパートデータＴＰｎを復号した場合に得られる画像の縦サイズを、Ｋｘ番目に小さい表示サイズの縦サイズで割った結果の小数点以下を切り捨てた結果Ａ１を求める。そして、タイルパートデータＴＰｎを復号した場合に得られる画像の横サイズを、Ｋｘ番目に小さい表示サイズの横サイズで割った結果の小数点以下を切り捨てた結果Ａ２を求め、Ａ１とＡ２のうち大きい方をＡとする。

なお、タイルパートデータＴＰｎを復号した場合に得られる画像のサイズについては、このタイルパートデータＴＰｎを復号しなくても、タイルパートヘッダを参照すれば取得可能である。

そしてステップＳ１４０４では、この求めたＡが２以上であるのか否かをチェックする。このチェックの結果、Ａ≧２であれば処理をステップＳ１４０５に進め、Ａ＜２であれば処理をステップＳ１４１０に進める。

本実施形態では、ＴＰｎ＝０、Ｋｘ＝１であれば、ステップＳ１４０３で、タイルパートデータ０を復号して得られる画像の縦サイズ３１２画素を、最も小さい表示サイズの縦サイズ２５６画素で割った結果の小数点以下を切り捨てた結果Ａ１＝１を求める。更に、タイルパートデータ０を復号して得られる画像の横サイズ２０８画素を、最も小さい表示サイズの横サイズ２５６画素で割った結果の小数点以下を切り捨てた結果Ａ２＝０を求める。そして、Ａ１とＡ２のうち大きい方であるＡ１＝１をＡとする。従って、この場合には処理をステップＳ１４１０に進めることになる。

また、ＴＰｎ＝２、Ｋｘ＝２であれば、ステップＳ１４０３で、タイルパートデータ２を復号して得られる画像の縦サイズ２４９６画素を、２番目に小さい表示サイズの縦サイズ１０２４画素で割った結果の小数点以下を切り捨てた結果Ａ１＝２を求める。更に、タイルパートデータ２を復号して得られる画像の横サイズ１６６４画素を、２番目に小さい表示サイズの横サイズ７６８画素で割った結果の小数点以下を切り捨てた結果Ａ２＝２を求める。そして、Ａ１とＡ２のうち大きい方であるＡ１（Ａ２）＝２をＡとする。従って、この場合には処理をステップＳ１４０５に進めることになる。

ステップＳ１４０５では、タイルデータの数をカウントするために用いる変数Ｔを０に初期化する。

ステップＳ１４０６では、タイルデータＴにおける各タイルパートデータのうち、復号画像サイズの大きい方から（Ａ−１）個のresolution levelのデータを抜き出す。これは、タイルパートの先頭からパケット数を数えることで可能である。

本実施形態の場合、タイルパートデータ２にはresolution level１，２，３のデータが含まれているので、復号画像サイズの大きい方（resolution level３）から１（Ａ＝２であるので、２−１＝１）個のresolution levelのデータを抜き出す。そのために、タイルパートの先頭から、layer数×component数×position数×２＝１×３×１×２＝６パケットを残し、残り３パケットを抜き出す。ここで、抜き出すということは、元のタイルパートデータから取り除くということである。この結果、タイルパートデータ２内には、resolution level１，２のデータが保持されていることになる。

次にステップＳ１４０７では、タイルパートデータＴＰｎのタイルパートヘッダを更新する。即ち、タイルパートデータＴＰｎのデータ長を示すPsotの値を、ステップＳ１４０６で抜き出したデータ長分少ない値に書き換え、更に、タイルパートの総数を示すTNsotをステップＳ１４０１で取得した表示形態の数Ｋで書き換える。本実施形態の場合、ステップＳ１４０６で抜き出されたresolution level 3のデータ量を５０[byte]、もともとPsotに格納されていた値を３５０とすると、Psotの値として３００（＝３５０−５０）を上書きする。また、タイルパート数TNsotは、表示形態の数Ｋ＝３であるので、書き換えても変わらない。

ステップＳ１４０８では、ステップＳ１４０６で抜き出したresolution levelのデータをタイルデータＴにおけるタイルパートデータ（ＴＰｎ＋１）のタイルパートヘッダの直後に移動させる。そして、タイルパートデータ（ＴＰｎ＋１）のタイルパートヘッダ中のデータ長を示すPsotと、タイルパートの総数を示すTNsotを更新する。

本実施形態の場合、タイルパートデータ１から抜き出したresolution data 3のデータ量が５０[Byte]、タイルパートデータ２のタイルパートヘッダにおいてPsot＝２００, TNsot＝３とする。この場合、タイルパートデータ２のヘッダの直後にresolution data 3のデータを挿入し、タイルパートデータ２のタイルパートヘッダのPsotを２５０（＝２００＋５０）に更新し、TNsotの値を表示形態の数Ｋ＝３に書き換えて更新する。

ステップＳ１４０９では、変数Ｔの値に１を加えることで変数Ｔの値を更新し、更新後の変数Ｔの値が総タイル数に一致するか否かをチェックする。一致する場合には、全てのタイルについてステップＳ１４０６からステップＳ１４０８の処理が終わったものとして判断されるので、処理をステップＳ１４１０に進める。

一方、一致しない場合には、全てのタイルについてステップＳ１４０６からステップＳ１４０８の処理が終わっていないものとして判断されるので、処理をステップＳ１４０６に戻し、以降の処理を繰り返す。

ステップＳ１４１０では、変数ＴＰｎの値に１を加えることで変数ＴＰｎの値を更新すると共に、変数Ｋｘの値に１を加えることで変数Ｋｘの値を更新する。

そしてステップＳ１４１１では、変数Ｋｘの値が、上記Ｋの値に達したか否かを判断する。達した場合には本処理を終了するが、達していない場合には処理をステップＳ１４０３に戻し、以降の処理を繰り返す。

以上の処理の結果、本実施形態の場合には、タイルパートデータ０，１，２は以下のようになる。

タイルパートデータ０が保持するresolution levelデータ：resolution level 0→resolution level 0
タイルパートデータ１が保持するresolution levelデータ：resolution level 1, 2, 3 → resolution level 1, 2
タイルパートデータ２が保持するresolution levelデータ：resolution level 4 → resolution level 3, 4
図１５は、図１４に示したフローチャートに従った処理を実行する前におけるタイルパートデータ０，１，２のデータ構成と実行後のタイルパートデータ０，１，２のデータ構成とを示す図である。同図左側が実行前における構成を示し、同図右側が実行後における構成を示している。

本実施形態では、第１の実施形態のように、グルーピングフォーマットであるかの判断だけでなく、各タイルパートデータが使用目的に適したものであるのか否かをチェックし、そのチェック結果によっては、再度、タイルパートデータの再構成処理を行う。また、この再構成処理は、表示の際に行ったリサイズの割合のみで判断できるので、大きな負荷にはならない。

また、タイルパートデータを再分割し、タイルパートヘッダを書き直すことで、ディスプレイサイズの異なる端末との間でデータを交換しても、それぞれに適したファイルフォーマットとすることができる。また、表示サイズの種類が異なるアプリケーションとの間でデータを交換しても、それぞれに適したファイルフォーマットとすることができる。

さらに、タイルパートデータの再分割の際には、再デコードする必要がなく、パケットデータの入れ替えとtile-part headerの書き換えのみで実現できるので、処理が軽く、この処理によるオーバーヘッドも少ない。

［第３の実施形態］
第１，２の実施形態では、JP2ファイルフォーマットのuuid boxの中に、バイナリ形式でタイルパート情報を格納していたが、これをXMLで記述し、XML boxの中に格納しても良い。この場合、第１，２の実施形態と異なるのは、図９におけるステップＳ９０３，Ｓ９０４における処理である。

本実施形態では、ステップＳ９０３の時点において、ＪＰ２ファイルの中からXML boxを探す。そしてステップＳ９０４の時点において、XML boxの中のXMLをパースして、グルーピングフォーマット定義のタグが書かれているかどうかを判断することで、グルーピングフォーマットであるか否かを判断する。これは、本実施形態では、XML形式でタイルパート情報を格納しているためである。たとえば、XMLのNamespaceが”http:／／www.format.cano.co.jp”であるタグが、グルーピングフォーマットのタグである、と定義されていれば、このnamespaceのタグがXML内に記述されている場合に、グルーピングフォーマットであると言える。

図１６は、ＸＭＬ形式で記述したタイルパート情報の一例を示す図である。同図のタイルパート情報は、タイルパート数が3、タイルパートデータ０を復号して得られる画像のサイズが312画素×208画素であることを示す。またこの情報は、タイルパートデータ１を復号して得られる画像のサイズが2496画素×1664画素、タイルパートデータ２を復号して得られる画像のサイズが4992画素×3328画素であることを示す。

namespaceとして、”http:／／www.format.cano.co.jp”を使い、タイルパート数はnumTilePartタグの値として、各タイルパートの画像サイズは、sizeTilePartImageタグの値として、タイルパート番号はsizeTilePartImageタグの属性idの値として記述すると定義する。同様に、タイルパート情報の読み出しおよび書き出しも変更すればよい。

XMLで記述すると、バイナリによる記述よりもデータ量が大きくなる可能性があるが、バイナリによる記述よりも拡張性が高くなる。たとえば、タイル数の情報をタイルパート情報に追加することも、バイナリよりは容易に可能になる。

［第４の実施形態］
タイルパート情報に符号化データの先頭から各タイルパートの最後までのデータ長を含めても良い。すなわち、タイルパートデータ０のデータ長として、メインヘッダのデータ長とタイルパートデータ０のデータ長とを合わせた値をタイルパート情報として保存する。タイルパートデータ１のデータ長としてメインヘッダのデータ長とタイルパートデータ０のデータ長及タイルパートデータ１のデータ長を足し合わせた値を、各タイルパートデータを復号した場合に得られる画像のサイズと共に、タイルパート情報として保存する。

例えば、図１２に示したようなフォーマットを有するビットストリームにおいて、XMLを使ってタイルパート情報を記述した例を図１７に示す。ここではメインヘッダ1200のデータ長が100byte、タイルパートデータ０のデータ群1201のデータ長が200byteとする。また、タイルパートデータ１のデータ群1202のデータ長が300byte、タイルパートデータ２のデータ群1203のデータ長が400byteとする。また、タイルパート情報にタイルパートデータのデータ長を含めた場合に、uuid boxに記述するバイナリデータの構造の例を図１８に示す。

このように、各タイルパートデータのデータ長を記すことで、画像処理装置は、必要なバイト数のみを先頭から取得して、デコードすればよい。特に、画像処理装置と画像データの保存装置がネットワークで結ばれている際には、このタイルパート情報を先に画像処理装置に送信することで、画像処理装置はダウンロードすべきバイト数をあらかじめ把握することができる。従って、一般的にインターネットで利用されているHTTPプロトコルのContent-rangeの様に、ファイルの必要な範囲のデータのみを受信できる通信プロトコルを利用するクライアントならば、画像ファイル全体を受信する必要はない。またこのようなクライアントならば、あらかじめ取得したダウンロードすべき範囲を指定して、データの受信を行うことができ、無駄なデータ転送を抑制できる。

［第５の実施形態］
上記第１から４の実施形態では、タイルパート情報をファイルフォーマットの中に格納していた。本実施形態では、符号化データの中に格納する。

JPEG2000符号化データの中に、COMマーカという形式でコメントを格納することが可能になっている。COMマーカの構造を図１９に示す。COMマーカは、メインヘッダに含めることも可能であるし、また、各タイルパートヘッダの後ろに含めることも可能である。Rcom 1901の値が0であれば、続くCcom 1902はバイナリで記述されており、Rcom 1901の値が1であれば、続くCcom 1902は、ISO8859-15で定義される文字コードを使って記述されていることを示す。

したがって、COMマーカをメインヘッダに格納し、Rcom = 0として、uuid boxに格納したバイナリ形式のタイルパート情報をCcom 1902に格納しても良い。また、Rcom = 1として、XML boxに記述したテキスト形式のデータをCcomに格納しても良い。

このようにメインヘッダの中に格納することで、ファイルフォーマットの中からタイルパート情報を探さなくても符号化データの先頭にあるメインヘッダを解析するだけで、JPEG2000のエンコード条件と同時にタイルパートの情報を取得ことができる。

［第６の実施形態］
COMマーカは各タイルヘッダに格納しても良い。COMマーカに、上記第１から５の実施形態に示すような、画像全体のタイルパート情報を格納しても良いが、本実施形態では、タイルパート毎のデータを一緒に記述する場合について、図２０を用いて説明する。

タイルパートヘッダに、タイルパート情報を持つCOMマーカを記述する場合には、符号化データを並べ変えるので、上記ステップＳ１００８におけるタイルパートへの分割処理と、ステップＳ１００９における書き込み処理とを同時に処理する。

図２０において、ステップＳ２００１では、タイルパートデータの数をカウントするために用いる変数ＴＰｎを０に初期化する。ステップＳ２００２では、上記ステップＳ１００７における対応付け処理の結果を参照し、タイルパートデータＴＰｎを復号した場合に得られる画像のサイズと、resolution levelのデータの数Ｒｔとを取得する。

本実施形態では、ＴＰｎ＝０の場合には、画像サイズとして３１２画素×２０８画素を取得すると共に、数Ｒｔとして１を取得する。また、ＴＰｎ＝１の場合には、画像サイズとして、２４９６画素×１６６４画素を取得すると共に、数Ｒｔとして３を取得する。ＴＰｎ＝２の場合には、画像サイズとして４９９２画素×３３２８画素を取得すると共に、数Ｒｔとして１を取得する。

次にステップＳ２００３では、タイルデータの数をカウントするための変数Ｔを０に初期化する。ステップＳ２００４では、タイルパートデータＴＰｎのヘッダを初期化する。本実施形態では、ＴＰｎ＝１の場合には、図３（ｃ）に示すタイルパートヘッダのタイル番号にＴ、タイルパート番号に１、タイルパート総数に3を代入する。さらに、タイルパートヘッダの後ろに続くCOMマーカのCcom 1902として、図２１に示す箱２１０１を用意する。タイルパートデータ１に含まれるresolution levelのデータは、resolution level 1, 2, 3の3つのデータである。このタイルパートデータを復号することで得られる画像サイズは2496画素×1664画素であるので、Rinside 2102には3、WIDTH 2103には2496、HEIGHT 2104には1664が入る。RDLen 2105は3つ用意しておく。

図２０に戻って、ステップＳ２００５では、resolution levelのデータの数をカウントする為に用いる変数Ｒｘを０に初期化する。ステップＳ２００６では、タイルパートデータＴＰｎに入るＲｘ番目のresolution levelのパケットデータと、そのデータ長を取得する。本実施形態の場合、まず、resolution level 1のパケットデータが対象となる。

ステップＳ２００７では、ステップＳ２００６で取得したデータをCOMマーカの後ろに書き込み、さらに、Ｒｘ番目のRDLenにそのデータ長を書き込む。ステップＳ２００８では、Ｒｘの値に１を加えることでＲｘの値を更新し、その後、Ｒｘ＝Ｒｔであるのか否かをチェックする。Ｒｘ≠Ｒｔであれば処理をステップＳ２００６に戻し、以降の処理を繰り返す。本実施形態の場合、ＴＰｎ＝１であれば、ステップＳ２００６，Ｓ２００７における処理を３回行えば処理をステップＳ２００９に進める。

一方、Ｒｘ＝Ｒｔであれば処理をステップＳ２００９に進め、変数Ｔの値に１を加えることで変数Ｔの値を更新し、その後変数Ｔの値がタイルの総数と一致するか否かをチェックする。一致しない場合には処理をステップＳ２００４に戻し、以降の処理を繰り返す。

一方、一致する場合には処理をステップＳ２０１０に進め、変数ＴＰｎの値に１を加えることで変数ＴＰｎの値を更新し、その後、ＴＰｎの値がタイルパートデータの総数と一致するか否かをチェックする。このチェックの結果、一致する場合には本処理を終了するが、一致しない場合には、処理をステップＳ２００２に戻し、以降の処理を繰り返す。

以上説明した、図２０のフローチャートに従った処理を実行すると、タイルパートデータ１のCOMマーカは、たとえば、
Rinside 2101 = 3
WIDTH 2102 = 2103
HEIGHT 2104 = 1664
RDLen0 = 30
RDLen1 = 40
RDLen2 = 50
となる。

このように、タイルパートデータ毎に、含まれている各resolution levelのデータ長を記述することで、タイルパートを再分割する際に、処理を容易にすることができる。すなわち、パケットを解析し、抜き出すパケット数を計算しなくても、COMマーカに記載されているバイト数だけ、タイルパートデータの後方から抜き出すだけで、簡単にresolutionデータを分離できるようになる。

［第７の実施形態］
上記第１から６の実施形態では、３つの解像度を持つファイルフォーマットとなっていたが、DCFファイルと同様に、サムネイルと主画像の２つ解像度から構成されるようにしても良い。

また、上記第１から６の実施形態では、ビットストリームのプログレッション・オーダーをRLCPとしたが、RPCLでもresolution levelで分割する場合には同じことである。

また、上記第１から６の実施形態では、各タイルパートデータはresolution levelで分割していたが、layerまたは、色成分等、他の仕様で分割しても良い。

Layerで分割する場合には、JPEG2000符号化データのプログレッション・オーダーをLRCPとし、タイルパート情報として、各タイルパートの画像サイズではなく、画質のデータ(e.g. bpp)を保存すればよい。Layerによる分割は、複数画質を提供する画像表示システムに、特に有効である。

また、Componentで分割する場合には、JPEG2000符号化データのプログレッション・オーダーは、CPRLとし、各タイルパートの情報として画像サイズではなく、各タイルパートの色成分情報を保存すればよい。これは、特に、JPEG2000データの色成分がYCbCrであり、モノクロとカラーの表示を使い分ける画像表示システムに有効である。

さらに、resolution levelによって分割されたフォーマットと、layerによって分割されたフォーマットを、画像の種類に応じて、使い分けても良い。この場合には、タイルパート情報として、タイルパート分割が、resolution、layer、componentのいずれで行われているのかを記述し、それぞれに応じたデータ、画像サイズ、画質、色成分の記述を行えばよい。

上記各実施形態によれば、グルーピングフォーマットに従った、解像度間の差分データからなるJPEG2000符号化データを利用することで、ファイルサイズを大きくせずに済む。また、画像表示で必要となる解像度画像を用意し、かつ、個々のアプリケーションが必要な解像度(または、画質／色成分)の画像のみに、タイルパートとタイルパート情報を使って、素早くアクセスできる。

また、タイルパートに分割することで、一本のJPEG2000符号化データから必要なデータをピックアップする必要がなく、先頭からデータをデコードすればよいので、シーク回数が減り、表示までの時間を短縮することができる。

さらに、画像を格納する装置と画像を表示する装置が異なり、それらがネットワークでつながれた状況において、画像の表示までの時間を短縮できる。特に、タイルパート情報に各タイルパートデータのデータ長を入れることで、画像データに先立ってタイルパート情報を取得すれば、必要なデータ量だけダウンロードすればよいので、トラフィックを削減し、画像の表示までの時間の短縮につながる。

さらに、画像をタイル分割することで、画像の部分領域へのランダムアクセス性を確保できる。よって、高解像度画像の一部のみ表示する場合に、必要なタイルデータのみをデコードするだけで画像を表示でき、高精細画像も短時間で表示できる。

［その他の実施形態］
また、本発明の目的は、以下のようにすることによって達成されることはいうまでもない。即ち、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体（または記憶媒体）を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する。この場合、記録媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記録した記録媒体は本発明を構成することになる。

また、コンピュータが読み出したプログラムコードを実行することにより、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行う。その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記録媒体に適用する場合、その記録媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

本発明の第１の実施形態に係る画像処理装置に適用可能なコンピュータのハードウェア構成を示すブロック図である。 Ｌａｙｅｒ−ｒｅｓｏｌｕｔｉｏｎ ｌｅｖｅｌ−ｃｏｍｐｏｎｅｎｔ−ｐｏｓｉｔｉｏｎ ｐｒｏｇｒｅｓｓｉｏｎに従ったＪＰＥＧ２０００のビットストリームの構成を示す図である。 （ａ）は、タイルデータを示す図、（ｂ）は、図３（ａ）に示したタイルデータ３００を３つのタイルパートデータに分割した場合に、それぞれのタイルパートデータの構成例を示す図、（ｃ）は、タイルパートヘッダの構成例を示す図である。 （ａ）は、ビットストリーム中における各タイルパートデータの配置例を示す図、（ｂ）は、タイルパートデータがランダムにビットストリーム中に配置されている場合のビットストリームの構成例を示す図である。 ＪＰＥＧ２０００のファイルフォーマットの概略を示す図である。 ボックスの基本構成を示す図である。 （ａ）は、ハードディスク１０３に保持されているそれぞれの画像（実際にはビットストリーム）のサムネイルを一覧表示している場合の表示例を示す図、（ｂ）は、指示された画像を全画面表示した場合の表示例を示す図、（ｃ）は、指示された画像を等倍表示した場合の表示例を示す図である。 出力デバイス１０５の表示画面上に画像を表示する為に画像処理装置が行う処理のフローチャートである。 ステップＳ８０２における判別処理の詳細を示すフローチャートである。 ステップＳ８１３における処理の詳細を示すブロック図である。 （ａ）は、uuid boxのBox Contents６０３のフォーマットを示す図、（ｂ）は、タイルパート情報の構成を示す図、（ｃ）は、本発明の第１の実施形態に係るタイルパート情報を示す図である。 ステップＳ１００８における処理の結果、再構成されたビットストリームの構成を示す図である。 出力デバイス１０５の表示画面上に画像を表示する為に画像処理装置が行う処理のフローチャートである。 ステップＳ１３０２における処理の詳細を示すフローチャートである。 図１４に示したフローチャートに従った処理を実行する前におけるタイルパートデータ０，１，２のデータ構成と実行後のタイルパートデータ０，１，２のデータ構成とを示す図である。 ＸＭＬ形式で記述したタイルパート情報の一例を示す図である。 XMLを使ってタイルパート情報を記述した例を示す図である。 タイルパート情報にタイルパートデータのデータ長を含めた場合に、uuid boxに記述するバイナリデータの構造の例を示す図である。 COMマーカの構造を示す図である。 タイルパート毎のデータを一緒に記述する処理のフローチャートである。 COMマーカの内部構造を示す図である。

符号の説明

１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ハードディスク
１０４ 入力デバイス
１０５ 出力デバイス

Claims (8)

1. 画像を複数のタイルに分割し、それぞれのタイルを複数の解像度で復号可能に符号化することにより得られるそれぞれのタイルの符号化データ、を含む符号化画像データを取得する取得工程と、
   それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために必要な部分を復号する復号工程と、
   前記復号工程により復号されたそれぞれのタイルを出力する出力工程と
   を備える画像処理方法であって、
   前記取得工程で取得した符号化画像データが第１のフォーマットに従っていない場合には、それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために復号する復号部分を特定する特定工程と、
   それぞれのタイルの符号化データにおいて前記特定工程で特定した復号部分を、タイルの並び順に並べたデータ群として保持すべく、前記符号化画像データを再構成する再構成工程と
   を備えることを特徴とする画像処理方法。
2. 前記指定された画質を有する画像とは、指定された解像度を有する画像、指定された色数を有する画像を含むことを特徴とする請求項１に記載の画像処理方法。
3. 前記指定された画質が複数指定されている場合には、前記特定工程、前記再構成工程による処理を指定された画質毎に行うことで、それぞれのタイルの符号化データにおいて、指定された画質の画像を得るために復号する復号部分をタイルの並び順に並べたデータ群を指定された画質毎に生成し、
   指定された画質毎に生成したデータ群を並べることで前記符号化画像データを再構成することを特徴とする請求項１に記載の画像処理方法。
4. 前記第１のフォーマットは、前記再構成工程で得られる符号化画像データのフォーマットであることを特徴とする請求項１に記載の画像処理方法。
5. 更に、
   前記再構成工程で再構成された符号化画像データを構成する各タイルの符号化データのうち、第１の指示解像度の画像を得るために復号する復号部分を復号することで得られる復号画像のサイズが、当該第１の指示解像度のＮ倍（Ｎ≧２となる整数）である場合には、
   当該復号部分を構成する各resolution levelのデータのうち、resolution levelが大きい方からＮ個分のresolution levelのデータを、当該第１の指示解像度の次に大きい第２の指示解像度の画像を得るために復号する復号部分を構成する各resolution levelの先頭部分に移動させる工程を備えることを特徴とする請求項１乃至５の何れか１項に記載の画像処理方法。
6. 画像を複数のタイルに分割し、それぞれのタイルを複数の解像度で復号可能に符号化することにより得られるそれぞれのタイルの符号化データ、を含む符号化画像データを取得する取得手段と、
   それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために必要な部分を復号する復号手段と、
   前記復号工程により復号されたそれぞれのタイルを出力する出力手段と
   を備える画像処理方法であって、
   前記取得手段が取得した符号化画像データが第１のフォーマットに従っていない場合には、それぞれのタイルの符号化データにおいて、指定された画質を有する画像を得るために復号する復号部分を特定する特定手段と、
   それぞれのタイルの符号化データにおいて前記特定手段が特定した復号部分を、タイルの並び順に並べたデータ群として保持すべく、前記符号化画像データを再構成する再構成手段と
   を備えることを特徴とする画像処理装置。
7. コンピュータに請求項１乃至５の何れか１項に記載の画像処理方法を実行させるためのプログラム。
8. 請求項７に記載のプログラムを格納したことを特徴とする、コンピュータ読み取り可能な記憶媒体。

Images