JP2008140361A - 画像処理装置、または画像処理方法 - Google Patents

Abstract

【課題】複数のサムネイルを一覧表示し、一覧表示からユーザが検索対象画像を検索する場合に、操作性を向上させると共に、検索効率を向上させる。
【解決手段】ユーザはサムネイルの一覧表示をサーバ装置１１０へ指示する。サーバ装置は一覧表示指示を受信すると、表示画面制御処理部１１８がサムネイル一覧表示画面を生成し、クライアント装置１００へ送信する。ユーザは表示画面１１９を閲覧し、表示倍率の変更を指示し、この指示が画面制御データ１２０としてサーバ装置へ送信され、サーバ装置では画面制御データに応じてサムネイル一覧ビュー画面を変更し、表示画面１０１に表示する。
【選択図】図１

Description

本発明は、画像データベースなどに蓄積された画像データに対して、サムネイル一覧などの複数画像の一覧表示画面を生成する画像処理装置、画像処理方法に関し、例えば、複合機などのＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）、ファイルサーバ、画像処理プログラムなどに好適な技術に関する。

紙文書をスキャナなどの入力デバイスを使用して電子化する例えば電子ファイリングなどの装置があるが、専ら紙文書を大量に扱う業務用途として使用されていた。近年、スキャナの低価格化やスキャナ機能を搭載したＭＦＰの普及やｅ−文書法などの法制化により、オフィスでもそのハンドリングの良さや利便性が認知され、紙文書が電子化されている。一方、紙文書が電子化された画像データ、ＰＣなどのアプリケーションによって作成された文書データなどをデータベース（以下ＤＢ）化して一元管理する画像ＤＢの利用も増大している。例えば紙文書の原本を保存する必要があっても管理や検索のし易さから、画像ＤＢを構築する場合もある。

上記した画像ＤＢは、サーバ装置を設置して多数のユーザがアクセスする大規模なものから、個人のＰＣ内にＤＢを構築するパーソナル用途まで様々であり、例えば、近年のＭＦＰは内蔵のＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）に紙文書を電子化した画像データを蓄積する機能が備えられ、ＭＦＰをベースとした画像ＤＢが構築されている。

複数の画像が蓄積されている画像ＤＢ内の画像を閲覧する場合、ユーザは画像の検索手法を用いて目的の画像を検索する。すなわち、検索対象画像の画像名（ファイル名）が既知であれば、通常はサムネイルの一覧表示が使用される。例えば、文書画像を検索する場合、キーワード検索した後に、キーワードにヒットした候補画像をサムネイル一覧表示する。最終的に検索対象画像をサムネイル一覧表示から選択し、あるいは最初からサムネイル一覧表示のみを使用し、検索対象画像を探索する方法が採られている。

サムネイル一覧表示は縮小画像を画面上に複数個配列することにより、画像内容の把握を容易にするものであるが、限られた画面上に複数の画像を一度に表示するため、個々のサムネイルの解像度は一般的に低い。写真画像をサムネイル一覧表示した場合、低解像度の縮小画像でもその内容把握は比較的容易であるが、文字中心の文書画像の場合は、その縮小画像では文字の判読が困難になり文書画像の内容把握が難しい。従って、文書画像の検索では、ユーザは個々の文書画像をビューアなどの機能を使って拡大表示して確認しなければならず、検索時の操作性が非常に悪い。特に、ネットワークを介したサーバ・クライアントシステムの場合では、ビューアで画像を表示する際に新たに解像度の高い画像データの転送が必要となり、この結果、多数の画像の確認に、多くの処理時間を要し、検索効率が著しく低下する。

そこで、サムネイル一覧表示では多数のサムネイル数を表示すると時間がかかるため、特にネットワークを介したサーバ・クライアントシステムの場合では、一度に一覧できる表示数を少なくしてページをめくるように画面を変更することにより、表示までの待ち時間を短縮している。しかし、これでも一画面に表示できるサムネイル数が少ないため、何度もページをめくる（画面を変更する）必要があり、またサムネイル一覧表示に含まれる画像の全容が容易に掴めないため、最終ページまで閲覧しても所望の画像が見つからないこともあり、検索効率を一層悪化させる。このように、１画面（ページ）に表示するサムネイル数が増すと、表示までの時間がかかり、検索効率が低下する。

ところで、画像ＤＢでサムネイル一覧表示を行う場合に、つまり表示画面を作成する度に蓄積された原画像からの動的なサムネイル作成を行わない。一般的には、原画像を縮小したサムネイル用の画像を予め保持（蓄積）し、サムネイル用の画像を使用する方法を採る。この方法は処理速度の点で優れている。例えば、サーバ・クライアントシステムにおいて、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇａｇｅ）などを使用してサムネイル一覧の表示画面を作成する場合、通常、ビットマップの表示画面をサーバ側が作成することはなく、サーバはＨＴＭＬ文書に表示する画像（ファイル）名によるリンクのみを作成し、クライアント側のブラウザソフトによってＨＴＭＬ文書を展開（レンダリング）して、いわゆるビットマップの表示画面が生成される。このような場合、表示画面上でのサムネイルサイズ（通常はサーバ側が指定する）にかかわらず、サーバからクライアントへ表示画面上のサムネイル画像を全て転送する必要がある（通常、画面からはみ出た部分があっても全て転送する）。そのため、１画面に表示するサムネイル数が多くなると、それに応じて転送すべきデータ量が多くなる。また、小容量のデータを多数回転送するためデータの転送効率が低下し、クライアント側の画面表示に時間がかかる（通常、データ転送時のパケット長は固定であり、異なるファイルを同一パケットにしないため、小ファイルでは冗長な転送データが発生する。小ファイルの転送データが多くなると、冗長データが無視できず、これにより転送効率が低下する）。また、一般的にサーバ側でも表示するサムネイル数が多くなるとディスクアクセスなどの負荷が増える。

そこで、上記した問題を解決するものとして特許文献１の検索方法が提案されている。すなわち、サムネイルを２次元マップ上に配置して表示するマップ表示手順と、マップを分割した複数の小領域のうち特定の小領域内のポイントを利用者が指示したとき、特定の小領域を中心とする小領域群を拡大対象領域とし、拡大対象領域内に配置されたサムネイルを拡大して内容を詳細に表示するサムネイル詳細表示手順により、簡易な操作で目的の情報を検索している。

特開２００４−２５８８３８号公報

しかしながら、上記の特許文献１に開示される方法では、サムネイルと詳細表示との２値的な表示切替のため、マップ上で検索対象画像の位置を把握することが出来ないと、しらみつぶしに拡大表示して探索する必要が生じ、拡大率が不足する可能性ある。また、マップ上に表示するサムネイルの数が多くなると、サムネイルを重ねて表示できないため、サムネイルサイズが小さくなり、サムネイル一覧の意味がなくなる可能性もある。さらに、一覧表示上のサムネイル数が多くなると、前述したように、表示に時間が非常にかかる。

本発明は上記した問題点に鑑みてなされたもので、
本発明の目的は、複数のサムネイルを一覧表示し、一覧表示からユーザが検索対象画像を検索する場合に、操作性を向上させると共に、検索効率を向上させた画像処理装置、画像処理方法を提供することにある。

本発明は、複数のサムネイルを表示するための一覧表示画面を生成する画像処理装置において、前記一覧表示画面は、表示倍率が変更可能なサムネイル一覧ビューと、前記サムネイル一覧ビューの少なくとも一部を表示する一覧ビューウィンドウと、前記表示倍率に応じてサイズまたは解像度が変更可能な複数のサムネイルとにより構成されていることを最も主要な特徴とする。

請求項１、６、７、１２：サムネイル一覧ビューからの画像検索方法において、ビューアなどの別ウィンドウを開くことなく軽快に、かつ連続して複数の画像の内容を確認しながら検索が可能となり、操作性が向上する。また、表示倍率に応じて、サムネイルサイズまたは解像度を変更することにより、サムネイルの精細度を変更しているため、拡大率を上げても画質が低下することなく内容の確認が可能となる。また、画像毎に異なる複数サイズのサムネイルを保持しているので、簡易に画像内容を確認する場合でも必要以上に大きなサイズの画像を転送する必要がなく、さらに、表示倍率に適合したサイズのサムネイル画像のみの転送が可能であるので、画像内容を確認するまでの転送量が少なくまた転送時間が短縮され、検索効率が向上する。また、サムネイル数が非常に多い画面を表示する場合は、一般的に使用されるよりも小さいサイズのサムネイル画像が使用可能であるため、その場合の転送時間が一層短縮され、検索効率が向上する。

請求項２、３、８、９；サムネイル一覧ビューに所定条件で配置し、同一属性の画像が近接して配置され、かつ画質を低下させない状態で表示倍率の拡大が可能であるので、効率的に文書画像を絞り込むことが可能となり、検索効率が向上する。

請求項４、１０；サイズの異なる複数のサムネイルを生成する代わりに登録画像を階層符号へ変換し、解像度（サイズ）の異なるサムネイルを階層符号から生成しているので、原画像の符号データ量のみで本発明が実現可能となり、画像ＤＢへ保存するデータ量の削減が可能となる。

請求項５、１１；サムネイル一覧ビューを一つの画像データとして処理しているので、表示領域画面生成時の処理がサムネイル一覧ビューの簡易な切り出し処理のみであり、これにより画面表示までの時間が短縮され、検索効率が向上する。

請求項６、１２；画面の表示領域内のサムネイル画像のみデータを転送するように構成しているので、大きなサイズのサムネイル画像においても転送時間が短縮され、検索効率が向上する。

以下、発明の実施の形態について図面により詳細に説明する。

実施例１：
図１は、本発明の実施例１のシステム構成を示す。図１において、１００はパーソナルコンピュータ（以下ＰＣ）、ＰＤＡや携帯電話などのモバイル端末などのクライアント装置である。１０１はモニタなどの表示デバイス、１０２はユーザ指示の解釈、サーバ１１０との通信、表示デバイス１０１の制御を行うアプリケーションプログラム、１０３はユーザからの指示入力手段であるキーボードやマウスなどの入力デバイス、１０４はＬＡＮやインターネットなどの外部通信路である。

１１０はクライアントからのコマンドに応じて画像分類を行い分類結果をクライアント１００へ出力するサーバ装置、１１１は外部通信路１０４とのインターフェース（以下Ｉ／Ｆ）、１１２は画像ＤＢ１１４へ登録する登録画像データ、１１３は登録画像１１２を所定サイズ以下に変倍して複数のサムネイル画像を生成するサムネイル生成処理部、１１４は登録画像１１２の画像データ、登録画像１１２のサムネイル画像データを蓄積する画像ＤＢ、１１８はクライアント１００へ表示するための表示画面を生成し、かつ画面制御データ１２０の内容に応じて表示画面を制御する表示画面制御処理部、１１９はクライアント１００の表示デバイス１０１上へ表示するための表示画面データ、１２０はクライアント１００によって指定され、入力される画面制御データである。図中の点線は、画像登録時のデータの流れを表し、実線はサムネイル一覧表示画面の生成時のデータの流れを表している。

図２は、サーバ装置１１０／クライアント１００装置の構成を示す。図２において、２０１はプログラムに応じた演算や処理を行うＣＰＵ、２０２はプログラムのコードや画像の符号データなどのデータを一時的に記憶、保持するワーク領域として使用される揮発性のメモリ、２０３は画像データやプログラムなどを保存、蓄積するためのハードディスク（以下ＨＤＤ）であり、画像ＤＢ１１４を保持する。２０４はモニタ２０５へ表示するためのデータバッファであるビデオメモリである。ビデオメモリ２０４に書き込まれた画像データは、定期的にモニタ２０５へ表示される。２０６はマウスやキーボードなどの入力デバイス、２０７はインターネットやＬＡＮなどの外部通信路１０４を介してデータを送受信する外部Ｉ／Ｆ、２０８は各々の構成要素を接続するバスである。

本実施例では、サーバ装置１１０がサーバコンピュータにより構成され、表示画面生成などの処理がソフトウェによって実現する例を示す。すなわち、サーバ内の処理は図示しないアプリケーションプログラムによって実現される。本発明の実施形態はこれに限定されず、ＭＦＰなどの装置内にハードウェアによって処理を行うように構成しても良いし、また、サーバ、クライアント構成を採らずに、例えば１つのＰＣやＭＦＰなどの機器内に、図１の構成を構成するようにしても良い。

以下、本実施例の動作概要を説明する。実施例１のシステムは、大別すると二つの動作に分かれている。一つは画像の登録動作であり、他の一つは所望の画像を検索し、閲覧し、取得（サーバからのダウンロード）する「ＤＢ内の画像を利用する」動作である。画像の利用においては、まず所望の画像を検索し、その後、アプリケーションのビューアーを使用して画像を閲覧し、ユーザのＰＣ内へ蓄積する。また、キーワード検索や類似画像検索などの画像検索の技術があるが、本実施例では説明を簡略するため、それらの検索処理の後に行う、サムネイル一覧表示から検索対象画像を探索する動作を検索処理の対象とするが、キーワード検索や類似画像検索などの処理を行うことなく、サムネイル一覧表示のみから画像を検索するケースもある。

図３は、画像登録時の動作フローチャートを示す。図１（破線は登録時の動作を示す）、図３を参照して画像登録動作を説明する。
ステップＳ００１において、ユーザは、クライアント装置１００からアプリケーションプログラム１０２を介してサーバ装置１１０へ画像データの登録の指示と登録する登録画像データ１１２を指示する。

ステップＳ００２において、登録画像データ１１２は、外部通信路１０４を介してサーバ装置１１０へ入力され、外部Ｉ／Ｆ１１１を経由して画像ＤＢ１１４へファイル名などの付随するメタ情報などと共にＩＤが付与されて登録される。同時に、サムネイル生成処理部１１３は登録画像１１２を縮小処理して複数の所定サイズ以下のサイズの異なる「複数のサムネイル画像」を生成し、画像ＤＢ１１４へＩＤを付与して登録する。登録画像データ１１２が複数ページの画像データの場合には、ページ単位でサムネイルを生成する。

本実施例では、登録画像毎にサイズの異なるサムネイル画像を複数生成する。ここでのサムネイル生成方法は、例えば、図４に示すように、サイズの異なる各サムネイル毎に長辺のサイズを規定して、原画像の長辺サイズがそれ以上であれば、登録画像データ１１２を縮小処理し、長辺が該サイズのサムネイルを作成するようにすれば良い。短辺は、長辺との比を保持して縮小する。

例えば、入力された登録画像データ１１２の画像サイズが、縦４０００画素×横２０００画素の場合、縦が図４のサイズ、横がその１／２のサイズのＳａｍ１〜Ｓａｍ７の７つの異なるサイズのサムネイルが生成される。本実施例ではサイズ（画素数）によりサムネイルの大きさを規定する例を示しているが、解像度を変更するように構成しても良い。

上記画像ＤＢ１１４における、ＩＤやファイル名などの付随するメタ情報は、一般的なＲＤＢ（リレーショナルデータベース）を使用することにより、情報の登録、管理、検索などの処理を簡易に実現できる。また、サムネイルおよび原画像データは、必要に応じて圧縮符号化して蓄積し、上記したメタ情報からリンクされて読み込み可能に構築しておけばよい。また、画像ＤＢ１１４は上述の機能を満たせば、例えばＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇａｇｅ）などの言語を使用し、階層的なデータ構造などを構築して蓄積しても良く、また、異なるサーバ毎にそれぞれＤＢとして蓄積してもよい。画像登録は、スキャナやデジタルカメラなどの画像入力装置から直接、画像データをサーバ装置１１０へ登録するようにしても良い。

図５は、画像検索時の動作フローチャートを示す。
ステップＳ１０１において、ユーザは、クライアント装置１００のアプリケーションプログラム１０２を使用して、サムネイルの一覧表示をサーバ装置１１０へ指示する。

ステップＳ１０２において、サーバ装置１１０は、一覧表示指示を受信すると、表示画面制御処理部１１８は図６（ａ）に示すサムネイル一覧表示画面の初期画面を生成する。図６（ａ）は、サムネイル一覧表示画面の一例を示す。図６（ａ）において、３０１はサムネイル一覧ビュー３０２の表示領域を規定するウィンドウ、３０２はサムネイルの表示フレームであるサムネイル一覧ビュー、３０３は個々のサムネイル（各矩形が一つのサムネイルを表している）、３０４はサムネイル一覧ビューの表示倍率を設定するスライダ、３０５はサムネイル一覧ビューを水平方向へスクロールするスライダ、３０６はサムネイル一覧ビューを垂直方向へスクロールするスライダである。

本実施例のサムネイル一覧表示画面は、大きく二つの画面構造からなる。一つはサムネイル一覧ビュー３０２であり、他の一つはユーザインターフェース部分と外枠のフレーム部分である。クライアント装置１００内のアプリケーション１０２は、これら二つのフレームを合成して表示デバイス１０１用の表示画面を生成し、図６（ａ）の画面を作成する。図６（ｂ）は、サムネイル一覧ビュー３０２を示し、３０７はウィンドウ３０１の境界を表す表示領域である。

表示画面制御処理部１１８は、前述の通り二種類の表示画面を生成するが、外枠のフレーム部分は、サムネイル一覧ビュー３０２の表示倍率や表示領域のスライダ３０５、３０６の位置を変更する程度であるので、その説明は省略し、サムネイル一覧ビュー３０２の画面生成を詳述する。

表示画面制御処理部１１８が初期画面を生成する場合、サムネイル一覧ビュー３０２の表示倍率（図６（ａ）は最低倍率）と表示領域３０７を所定の値に設定して、サムネイル一覧ビュー３０２を生成し、外枠のフレーム部分と共に表示画面１１９として外部Ｉ／Ｆ１１１より外部通信路１０４を経由してクライアント１００へ送信する。

サムネイル一覧ビュー３０２は、図６（ｂ）に示す画面となるが、表示画面制御処理部１１８では、このような画像を保持する必要はなく、個々の表示画像の位置情報（座標情報）と表示画像のＩＤ情報を保持しておけばよい。また、サムネイル一覧ビュー３０２は、表示領域３０７内の画面のみをクライアント装置１００へ送信する。サムネイル一覧ビューの生成については後述する。また、図６（ｂ）の画面の余白部分は、表示倍率を拡大したときに画面中央部が拡大されるが、端部のサムネイルを拡大するために必要となる余白部分である。

上記したような表示画面の作成方法やサーバクライアント間の通信方法には種々の手法があるが、一般的によく使用される手法としてサーバ装置１１０をＷｅｂサーバとしてＷｏｒｌｄＷｉｄｅＷｅｂベースの技術を使用することにより実現可能となる。そして、表示画面１１９はＨＴＭＬによって記述され、アプリケーション１０２は一般的なＷｅｂブラウザを使用すれば良い。また、本実施例では、表示倍率や表示領域を変更するためのスクロールのスライダを画面内に構成しているが、例えば、クライアント装置１００内のマウスなどの入力デバイスにそれらの機能を設けるように構成しても良い。

図５に戻り、ステップＳ１０３において、クライアント装置１００のアプリケーション
１０２は、表示画面１１９を展開（レンダリング）し、表示デバイス１０１上に表示画面
１１９を表示する。

ステップＳ１０４において、クライアント装置１００を使用しているユーザは、表示画面１１９を閲覧し、検索対象画像を探すために、表示領域を変更するスライダ３０５、３０６を操作し、また、表示倍率を変更する表示画面倍率設定用スライダ３０４を操作し、画面スクロールや表示倍率の変更を指示する。このスライダの操作は、マウスなどの図示しない入力デバイス１０３により実行される。

ステップＳ１０５において、画面スクロールや表示倍率の変更指示は、画面制御データ１２０として表示倍率と表示領域のデータへ変換されてサーバ装置１１０へ送信される。

ステップＳ１０６において、サーバ装置１１０では、画面制御データ１２０を受信すると、後述するように、サムネイル一覧ビュー画面を変更する。ステップＳ１０７において、ステップＳ１０３と同様に、表示デバイス１０１上に変更後の表示画面１１９を表示する。ステップＳ１０８において、ユーザが検索対象画像を見つけられない場合は、ステップＳ１０４〜Ｓ１０７の動作を繰り返す。

図７は、サムネイル一覧ビューの表示領域画面生成時のサーバ装置の動作フローチャートを示す。図７を参照して、サムネイル一覧ビュー画面の変更処理（ステップＳ１０６）を説明する。

ステップＳ２０１において、クライアント装置１００から画面制御データ１２０が入力されると、表示倍率とサムネイル一覧ビューの表示領域３０７を設定する。初期設定画面の場合は、サーバ装置１１０にそれらの所定値が設定される。

ステップＳ２０２において、表示倍率に応じて表示するサムネイルサイズを設定する。つまり、サムネイルサイズの設定とは、サムネイル一覧ビュー画面に使用するサムネイル種（図４のＳａｍ１〜Ｓａｍ８もしくは原画像）を設定することである。例えば、表示倍率に対応するサムネイルの長辺サイズが「４０」である場合、図４のＳａｍ１サムネイルが選択される。また、ユーザによって選択指示される表示倍率の代わりに、サムネイルサイズを直接、ユーザが指示するように構成しても良い。

表示倍率に対応するサムネイルサイズが図４に示す値の間である場合には、予め定められた所定のルールでサムネイル種を選択すれば良い。例えば、最も近いサムネイルサイズのサムネイルを選択するか、もしくは、対応するサイズよりも小さいサムネイルサイズを選択（画像転送量が減少する効果がある）すれば良い。

ステップＳ２０３において、サムネイル一覧ビューの表示領域３０７内に含まれる画像データに対応するサムネイル種を選択、決定する。

ステップＳ２０４において、選択されたサムネイルについて、サムネイル一覧ビューの表示領域内の画面を生成する。サムネイル一覧ビュー内の画面データを、ビットマップデータとする方法があるが、ＨＴＭＬでは、画像の座標情報とリンク情報を構造化文書に記載する方法が一般的であるので、構造化文書と表示領域内の各サムネイル画像データをサーバ装置１１０からクライアント装置１００へ転送する必要がある。

図８は、クライアント装置の表示デバイス１０１に表示される拡大表示の例を示す。ユーザは、多くのサムネイル画像から検索対象画像の候補画像をスライダ３０５、３０６を使用して画面中央へ表示させ（図８（ａ））、徐々に拡大率を上げていく過程で、周囲画像と比較し、画像内容を確認しながら、検索対象画像か否かを確認する（図８（ｂ）〜（ｃ））。検索対象画像ではないと確認できた場合は、表示倍率を縮小して候補の画像を探索する。一方、検索対象画像である場合には、サムネイル一覧ビューの画面の状態で、表示倍率を上げることにより画像内容を詳細に確認することができる（図８（ｄ））。

以上説明したように、本実施例によれば、サムネイル一覧ビューからの画像検索方法において、ビューアなどの別ウィンドウを開くことなく軽快に、かつ連続して複数の画像の内容を確認しながら検索が可能となり、操作性が向上する。また、本実施例では、表示倍率に応じてサムネイルサイズ（または解像度）を変更し、サムネイルの精細度を変更しているため、拡大率を上げていくたびに画質が低下することなく内容の確認が可能となる。例えば、単純に画像を拡大する方法として、従来の画像毎の単一のサムネイルを拡大する方法があるが、この方法では一度縮小した画像を拡大しても精細な画像が得られないので文字画像などの判読が困難となる。図９（ａ）は、従来方式の拡大画像を示し、（ｂ）は本発明の方式による画像を示す。

また、本発明では、画像毎に異なる複数サイズのサムネイルを保持しているので、簡易に画像内容を確認する場合でも必要以上に大きなサイズの画像を転送する必要がなく、表示倍率に適合したサイズのサムネイル画像のみを転送するので、画像内容を確認するまでの転送量が少なくまた転送時間が短縮され、検索効率が向上する。また、サムネイル数が非常に多い画面を表示する場合は、一般的に使用されるよりも小さいサイズのサムネイル画像が使用可能であるため、その場合の転送時間が一層短縮され、検索効率が向上する。また、画面の表示領域内のサムネイル画像のみのデータを転送しているため、サイズの大きなサムネイル画像についても転送時間が短縮され、検索効率が向上する。

実施例１では、ＨＴＭＬのように構造化文書とリンクによりサムネイル一覧ビューを構成する方法を説明したが、低倍率時のように、表示領域内にサムネイルが多数存在する場合は、画像登録時に低倍率時の画像を作成し、画像ＤＢ１１４に画像やサムネイルデータと共に蓄積し、一つの画像データとして処理することにより、さらにデータ転送時間が短縮され、サーバ装置の処理量が少なくなり、画面表示までの時間が短縮され、検索効率が向上する。

実施例２：
実施例１では、特にサムネイルの配置を考慮しなかったが、サムネイルの一覧ビューからの画像検索では、同一属性の画像が近くに配置されている方が検索の効率がよい。そこで、本実施例では、画像分類処理を行い、分類の態様を画面上で表現して検索効率を向上させる実施例を示す。本実施例が対象とする画像は、オフィスでの使用頻度が高い文書画像であるものとして、以下説明する。

図１０は、実施例２のシステム構成を示す。図１０において、１１５は画像の特徴量を算出し、所定のカテゴリに分類を行う分類処理部、１１４は分類カテゴリなどを蓄積する画像情報ＤＢであり、他の構成要素は、実施例１と同様であるので説明は省略する。
・分類処理
文書画像のクラスタリングや分類処理の手法が種々、提案されているが、ここでは、一例として以下のような分類処理技術を用いる。例えば、登録文書画像から複数の特徴量（色特徴量、形状特徴量、レイアウト特徴量）を算出する。すなわち、登録文書画像から文書画像の背景色や色の分布等の画像の色味に関する特徴量である色特徴量を算出し、また、登録文書画像から文書画像のエッジやテクスチャ等、画像の形状に関する特徴量である形状特徴量を算出する。レイアウト特徴量の算出は、画像要素単位でオブジェクトに分割し、オブジェクトの属性を判定してレイアウト情報を得た後、オブジェクト属性（例えばタイトル、文字、図形、写真、表等）毎の配置や面積率等を算出する。

そして、上記した複数の特徴量を用いて、以下のような複数のカテゴリ識別処理を行う。識別するカテゴリ種は、色カテゴリ識別、形状カテゴリ識別、レイアウトカテゴリ識別、文書タイプ識別である。すなわち、色カテゴリ識別は、色特徴量として背景色や最も使用されている色等を代表色として入力し、赤、青、緑、黄色、白等の複数のカテゴリを設け、近い色へ分類する。形状カテゴリ識別は、文書画像のエッジやテクスチャ等、複数の特徴量の類似度から分類を行う。レイアウトカテゴリ識別は、形状カテゴリ識別データと同様に分類すれば良い。文書タイプ（種類）識別は、レイアウト特徴量の複数の特徴量から段組等の文書種類の性質を用いて二分岐探索的に分類し、あるいは予め機械学習等の学習機によってレイアウトの特徴量データと識別する文書種類の正解データの対を教師データとして学習させ、レイアウト特徴量から学習データを用いて文書種類を識別する。

以下、本実施例では、上記した分類手法によって分類が行われるものとする。図１１は、本実施例における登録時のフローチャートである。実施例１と異なるステップＳ００３のみを説明する。

ステップＳ００３において、登録画像１１２に対して、サムネイルの生成と共に分類処理部１１５により上記分類処理を行い、各カテゴリデータを画像ＤＢ１１４に、他のメタ情報と共に登録する。

画像登録時に設定された分類カテゴリは、サムネイル一覧ビュー３０２上での画像の配置に使用される。動作は実施例１と同様であるので説明は省略する。以下、本実施例のサムネイル一覧ビューを説明する。

図１２（ａ）は、サムネイル一覧画面の初期画面例を示す。図の３１１は、分類カテゴリの境界を示す。本実施例では、画像登録時に文書分類処理が行われ、そのカテゴリ情報に基づき画像を分類した態様を示している。本実施例の場合は、大分類として文書タイプの分類が行われ、大分類をさらに、中分類、小分類として、色や形状レイアウトなどのカテゴリ分けを行う。中分類、小分類は、文書タイプに応じたものを使用すれば良い。例えば、図１２（ｂ）に示すように、大分類の文書タイプがプレゼンテーション資料である場合には、中分類は背景色を基に分類を行った色分類を使用し、さらに小分類としてレイアウト分類や形状分類を使用すれば良い。このようなサムネイル一覧ビュー上の配置は、図５のステップＳ１０２における、初期画面生成時に、表示画面制御処理部１１８によって生成しても良いが、画像登録時に配置を決定し、その配置情報（サムネイル一覧ビュー上の各画像の座標）を保持しておいた方が、表示までの処理時間を短縮できる。なお、上記した分類カテゴリの代わりに日付やＩＤ順を用いてもよい。

図１２では、各カテゴリ名を文字で示したが、文字はなくても良い。また、レイアウトや形状などの分類に対してはカテゴリ名が付けにくいものがあるが、カテゴリ名が付いていない場合でも、ユーザがサムネイルの集合を見ることによりカテゴリを判断できる。そして、本発明では表示倍率を変更することにより複数の画像内容を同時に参照できるため、サムネイル群の内容理解に役立つ。また、サムネイルのサイズが固定され、多数のサムネイルで分類の態様を表現する場合に、多数の画像を一画面で表示できなくなる。その場合には、サムネイルの代わりに、点や色、画素の濃度などで擬似的に表現するように構成してもよい。

以上説明したように、本実施例によれば、サムネイル一覧ビューに、分類の態様を表示しているので、同一属性の画像が近接して配置され、その状態で、画質を低下させることなく表示倍率の拡大が可能であるため、文書画像の絞り込みが効率的に行われる。

実施例３：
上記した実施例１、２は、登録画像毎にサイズ（または解像度）が異なる複数のサムネイル画像を生成したが、画像ＤＢに蓄積するデータ量が増加してしまう。そこで、本実施例では、階層符号化により原画像を圧縮し、画像ＤＢに保存するデータ量を削減する。

図１３は、実施例３のシステム構成を示す。１１６は入力された登録画像を階層符号へ変換する階層符号化変換処理部であり、他の構成要素は、実施例１と同様である。

階層符号化変換処理部１１６は、入力された登録画像データ１１２を階層符号化する。
通常、画像データは圧縮処理されているので、圧縮符号を復号し、解凍した上で、階層符
号化する。

階層符号化方式として、本発明では、例えばＪＰＥＧ２０００の基本方式（（ｐａｒｔ１）、ＩＳＯ、ＩＳ１５４４４−１）を用いる。以下、ＪＰＥＧ２０００ｐａｒｔ１（以下、ＪＰＥＧ２０００）の符号化方式とプログレッシブ順序の概要を説明する。

図１６は、ＪＰＥＧ２０００の圧縮符号化処理のブロック図である。入力画像データがカラーのＲｅｄ，Ｇｒｅｅｎ，Ｂｌｕｅ（以下、ＲＧＢ）である画像データ例を説明する。入力されたＲＧＢの画像データは、タイリング処理部１でタイルと呼ばれる矩形のブロック単位に分割される。ラスタ形式の画像データが入力された場合は、タイリング処理部１においてラスタ／ブロック変換を行う。ＪＰＥＧ２０００におけるタイルは、タイル単位に独立して符号化、復号化が可能であり、ハードウェアにより符号化、復号化を行う上ではハード量が削減され、必要なタイルのみ復号して表示することが可能となる。ＪＰＥＧ２０００ではタイリングはオプションであり、タイリングを行うのは任意であるが、タイリングを行わない場合は、タイル数１として扱われる。

次に、画像データは色変換処理部２で、輝度／色差系の信号に変換される。ＪＰＥＧ２０００では離散ウェーブレット変換（以下ＤＷＴ）に使用するフィルタの種類（５ｘ３と９ｘ７の２通り）によって２通りの色変換が定められている。上記の色変換に先立ち、ＲＧＢ各々の信号毎にＤＣレベルシフトが行われる。

色変換後の信号は、ＤＷＴ処理部３において各々のコンポーネント毎にＤＷＴが行われ、ウェーブレット係数が出力される。ＤＷＴは２次元で行われるが、通常はリフティング演算と呼ばれる演算方法により１次元フィルタ演算のコンボリューションで実施される。

図１７は、オクターブ分割されたウェーブレット係数を示す。ＤＷＴは、１デコンポジション（分解）レベル毎にＬＬ，ＨＬ，ＬＨ，ＨＨの４つのサブバンドと呼ばれる方向成分が出力され、ＬＬに対してＤＷＴを再帰的に行うことによって、より低解像度へとデコンポジションレベルをあげていく。解像度の最も高い１デコンポジションレベルの係数を１ＨＬ，１ＬＨ，１ＨＨと表し、以下２ＨＬ，２ＬＨ・・・ｎＨＨと表す。図１７は、３デコンポジションレベルに分割した例である。一方、解像度レベルは、デコンポジションレベルとは逆方向に解像度の低い係数から０，１，２，３というように呼ばれる。

各デコンポジションレベルにおけるサブバンド内は、プレシンクトと呼ばれる領域に分割して符号の集合を形成することが可能である。また、符号化はコードブロックとよばれる所定のブロック単位で実施される。図１８は、タイル内ウェーブレット係数におけるタイル、プレシンクトおよびコードブロックの関係を示す。

ＤＷＴ処理部３から出力されたウェーブレット係数は、量子化部４によってスカラー量子化が行われるが、可逆変換を実施する場合にはスカラー量子化は行わないか“１”により量子化する。また、後段のポスト量子化においても、量子化とほぼ同様な効果が得られる。スカラー量子化はタイル単位にパラメータを変更可能である。

量子化処理部４から出力された量子化データは、エントロピー符号化部５でエントロピー符号化が行われる。ＪＰＥＧ２０００におけるエントロピー符号化方式は、サブバンド内をコードブロックと呼ばれる矩形領域に分割（但し、サブバンド領域のサイズがコードブロックサイズ以下の場合は分割しない）し、コードブロック単位に符号化される。

また、コードブロック内のデータは、図１９に示すようにビットプレーンに分解された後、ビットプレーンを変換係数の画質への影響度を表す状態に従って３つのパス（Ｓｉｇｎｉｆｉｃａｎｃｅ ｐｒｏｐａｇａｔｉｏｎパス，Ｍａｇｎｉｔｕｄｅ ｒｅｆｉｎｅｍｅｎｔパス，Ｃｌｅａｎ ｕｐパス）に分割し、各々でＭＱコーダと呼ばれる算術符号化方式により符号化される。ビットプレーンはＭＳＢ側、符号化パスはＳｉｇｎｉｆｉｃａｎｃｅ ｐｒｏｐａｇａｔｉｏｎ、Ｍａｇｎｉｔｕｄｅ ｒｅｆｉｎｅｍｅｎｔ、Ｃｌｅａｎ ｕｐの順に重要度（画質への寄与度）が高くなっている。また、各パスの終端は、切り捨て点（トランケーションポイント）とも呼ばれ、後段でのポスト量子化の符号の切り捨て可能な単位となっている。

エントロピー符号化された符号データをポスト量子化部６で必要に応じて符号を切り捨てる。可逆の符号を出力する必要がある場合には、ポスト量子化は実行しない。ＪＰＥＧ２０００は、符号化後に符号量の切り捨てが可能であり、符号量の制御にフィードバックを必要としない構成（１パスの符号化）が特徴の１つである。ポスト量子化後の符号データは、符号ストリーム生成処理部７で、所定のプログレッシブ順序（符号データの復号順
序）に従って符号の並べ替えとヘッダの付加を行い、当該タイル分の符号ストリームが完成する。

図２０は、ＪＰＥＧ２０００におけるレイヤプログレッションによる符号ストリームの全体を示す。全体符号は、メインヘッダと画像を分割した複数のタイルで構成される。タイル符号は、タイルヘッダとタイル内符号をレイヤとよばれる符号単位（詳細は後述する）に区切った複数のレイヤにより構成されており、レイヤ０、レイヤ１・・・というように下位レイヤから順番に並んでいる。レイヤ符号の構成は、レイヤ用のタイルヘッダと複数のパケットにより構成されており、パケットはパケットヘッダと符号データから構成されている。パケットは、符号データの最小単位であり、１つのタイルコンポーネント内の１つの解像度レベル（デコンポジションレベル）における１つのプレシンクト内の１つのレイヤの符号データから成っている。

次に、ＪＰＥＧ２０００におけるプログレッシブ順序について説明する。ＪＰＥＧ２０００では、画質（レイヤ（Ｌ））、解像度（Ｒ）、コンポーネント（Ｃ）、位置（プレシンクト（Ｐ））という４つの画像の要素の優先順位を変更することによって以下に示す５通りのプログレッションが定義されている。

・ＬＲＣＰプログレッション
プレシンクト、コンポーネント、解像度レベル、レイヤの順序に復号されるため、レイヤのインデックスが進む毎に画像全面の画質が改善されることになり、画質のプログレッションが実現出来る。レイヤプログレッションとも呼ばれる。
・ＲＬＣＰプログレッション
プレシンクト、コンポーネント、レイヤ、解像度レベルの順序に復号されるため、解像度のプログレッションが実現出来る。
・ＲＰＣＬプログレッション
レイヤ、コンポーネント、プレシンクト、解像度レベルの順序に復号されるため、ＲＬＣＰ同様、解像度のプログレッションであるが、特定位置の優先度を高くすることが出来る。
・ＰＣＲＬプログレッション
レイヤ、解像度レベル、コンポーネント、プレシンクトの順序に復号されるため、特定部分の復号が優先されるようになり空間位置のプログレッションが実現出来る。
・ＣＰＲＬプログレッション
レイヤ、解像度レベル、プレシンクト、コンポーネントの順序に復号されるため、例えばカラー画像のプログレッシブ復号の際に最初にグレーの画像を再現するようなコンポーネントのプログレッションが実現出来る。

図２１（ａ）は、ＬＲＣＰプログレッション（以下レイヤプログレッション）、（ｂ）は、ＲＬＣＰプログレッションまたはＲＰＣＬプログレッション（以下解像度プログレッション）のプログレッシブ順序を模式的に表した図である。（ａ）、（ｂ）の横軸はデコンポジションレベル（数字が高いほど低解像度）、縦軸はレイヤ番号（数字が高いほど上位レイヤであり、下位レイヤに上位レイヤの符号を付加して復号することによってより高画質な再生が可能となる）である。図中、塗りつぶされた長方形の図形は、当該デコンポジションレベル、レイヤにおける符号を表し、その大きさは符号量の割合を模式的に表している。図中の点線の矢印は、符号順序を表している。

（ａ）は、レイヤプログレッションに復号する符号順序を表しており、同一レイヤ番号の全ての解像度の復号を行って、次段の上位レイヤの復号を行う。ウェーブレット係数レベルでみれば、係数の上位ｂｉｔから復号を行うことになり、徐々に画質が向上するプログレッションが実現可能となっている。（ｂ）は、解像度プログレッションに復号する符号順序を表しており、同一デコンポジション（解像度）レベルの全てのレイヤの復号を行って次段のデコンポジション（解像度）レベルの復号を行うことになり、徐々に解像度が向上するプログレッションが実現可能となっている。

ＪＰＥＧ２０００に代表される階層符号化によって画像ＤＢ１１４内に画像データを保持し、サムネイルサイズに適合する解像度レベルでサムネイル画像を生成することによって、原画像の符号データのみから解像度（サイズ）の異なる複数種類のサムネイルを生成可能となる。図２１は３階層の例を示しているが、実際にはさらに多くの階層数を持つことにより、表示領域３０７内に表示されるサムネイル数が多い場合のデータ転送量を削減することができる。階層数の決定方法としては、個々の画像サイズに対応して階層数（デコンポジションレベル数）を決定し、解像度レベル０を復号した場合の画像サイズが略同一となるようにすることが望ましい。

図１４は、本実施例におけるサムネイル一覧ビューの表示領域画面生成のフローチャートである。ステップＳ３０１の処理は実施例１の図７のステップＳ２０１の処理と同様である。すなわち、ステップＳ３０１において、クライアント装置１００から画面制御データ１２０が入力されると、表示倍率とサムネイル一覧ビューの表示領域３０７を設定する。初期設定画面の場合は、サーバ装置１１０が所定値を設定する。

ステップＳ３０２において、表示倍率に応じて表示に使用する解像度レベルを設定する。ステップＳ３０３において、サムネイル一覧ビューの表示領域３０７内に含まれる画像データに対応する画像を選択、決定する。ステップＳ３０４において、選択された画像データの解像度レベルに基づいてサムネイル画像を生成し、サムネイル一覧ビューの表示領域内の画面を生成する。

以上説明したように、本実施例によれば、サイズの異なる複数のサムネイルを生成する代わりに登録画像を階層符号へ変換し、解像度（サイズ）の異なるサムネイルを階層符号から生成するように構成しているので、原画像の符号データ量のみで本発明が実現可能となり、画像ＤＢへ保存するデータ量を削減できる。なお、本実施形態では、階層符号化方式としてＪＰＥＧ２０００を用いているが、これに限らず他の階層符号化方式でも実現可能なことはいうまでもない。

本実施例では、実施例１の構成を例にして説明したが、実施例２のように分類処理を備えた構成についても適応可能である。

実施例４：
上記実施例では、サムネイル一覧ビューの表示領域画面生成時に画像ＤＢ１１４に蓄積された表示領域内の画像を選択する例を示したが、サムネイルの数が多い場合などは処理が冗長となる可能性がある。本実施例では、この冗長処理を解消した例を示す。

本実施例の構成は実施例３と同様である。実施例１〜３の画像ＤＢにおける画像データの蓄積形態には特に制約がなく、例えば、パーソナルコンピュータのようなディレクトリ構造中に個々の画像ファイルが存在するような形式で良い。

本実施例では、画像登録時に図６（ｂ）に示すサムネイル一覧ビューの画像を、登録画像の原画像データから作成する。つまり、登録画像１１２をサムネイル一覧ビューのキャンバスに貼り付けていき、最終的にサムネイル一覧ビューという画像を生成する。さらに、各登録画像単位にタイリングする。

図１５は、各登録画像とタイリングを示す。図１５の点線はタイル境界を示す。タイリングは各登録画像単位に一つにする必要はなく、図１５の点線内部がさらに複数のタイルに分割されていても良い。サムネイル一覧ビュー３０２をこのように一つの画像データとして構成することにより、表示領域３０７内のサムネイル一覧ビューの作成が非常に簡易な処理で実現できる。これは、表示領域３０７がそのまま「サムネイル一覧ビュー画像」上の領域座標となるため、表示領域３０７でサムネイル一覧ビュー画像を切り出し、表示領域内の画面とすれば良いためである。従って、図１４のサムネイル一覧ビュー表示領域画面生成のフローチャートでステップＳ３０３が不要になる。

以上説明したように、本実施例では、サムネイル一覧ビューを一つの画像データとして処理することにより、表示領域画面生成時の処理が簡単化され、これにより画面表示までの時間が短縮され、検索効率が向上する。また、本実施例のように登録画像単位にタイリングしているので、登録画像単位に「サムネイル一覧ビュー画像」の切り出しが容易になり、さらに処理が簡素化されると共に、各登録画像単位での処理が容易となる。例えば、サムネイル一覧ビュー画像上で各登録画像を並べ替える場合でも、ヘッダ情報を書き換えるのみで実現可能となる。

本発明の実施例１のシステム構成を示す。 実施例１のサーバ装置／クライアント装置の構成を示す。 実施例１の画像登録時の動作フローチャートを示す。 サムネイルと長辺のサイズの関係を示す。 実施例１の画像検索時の動作フローチャートを示す。 実施例１のサムネイル一覧表示画面の例を示す。 サムネイル一覧ビューの表示領域画面生成時のサーバ装置の動作フローチャートを示す。 実施例１の拡大表示の例を示す。 実施例１の効果を説明する図である。 本発明の実施例２のシステム構成を示す。 実施例２の画像登録時の動作フローチャートを示す。 実施例２のサムネイル一覧表示画面の例を示す。 本発明の実施例３のシステム構成を示す。 実施例３におけるサムネイル一覧ビューの表示領域画面生成のフローチャートである。 実施例４における各登録画像とタイリングを示す。 ＪＰＥＧ２０００の圧縮符号化処理のブロック図である。 デコンポジションレベルと解像度レベルの関係を示す。 タイル、プレシンクト、コードブロックの関係を示す。 ビットプレーンとサブビットプレーンの関係を示す。 符号の構成を示す。 レイヤプログレッションと解像度プログレッションの符号順序を示す。

符号の説明

１００ クライアント装置
１０１ 表示デバイス
１０２ アプリケーションプログラム
１０３ 入力デバイス
１０４ 外部通信路
１１０ サーバ装置
１１１ 外部インターフェース
１１２ 登録画像データ
１１３ サムネイル生成処理部
１１４ 画像ＤＢ
１１８ 表示画面制御処理部
１１９ 表示画面データ
１２０ 画面制御データ

Claims (12)

1. 複数のサムネイルを表示するための一覧表示画面を生成する画像処理装置において、前記一覧表示画面は、表示倍率が変更可能なサムネイル一覧ビューと、前記サムネイル一覧ビューの少なくとも一部を表示する一覧ビューウィンドウと、前記表示倍率に応じてサイズまたは解像度が変更可能な複数のサムネイルとにより構成されていることを特徴とする画像処理装置。
2. 前記サムネイル一覧ビューは、前記複数のサムネイルを所定の条件に基づき配置して生成することを特徴とする請求項１記載の画像処理装置。
3. 前記所定の条件は、分類、日付、Ｄ順のいずれか一つの条件であることを特徴とする請求項２記載の画像処理装置。
4. 前記サムネイルは、階層符号化された圧縮画像データの一部の符号に基づき生成されることを特徴とする請求項１または２記載の画像処理装置。
5. 前記サムネイル一覧ビューの画面を一つの画像データとして蓄積し、前記一つの画像データに基づき前記一覧表示画面を生成することを特徴とする請求項１記載の画像処理装置。
6. 前記一覧ビューウィンドウ内に含まれるサムネイルに基づき前記一覧表示画面を生成することを特徴とする請求項１記載の画像処理装置。
7. 複数のサムネイルを表示するための一覧表示画面を生成する画像処理方法において、前記一覧表示画面の生成は、表示倍率が変更可能なサムネイル一覧ビューを生成するステップと、前記サムネイル一覧ビューの少なくとも一部を表示する一覧ビューウィンドウを生成するステップと、前記表示倍率に応じてサイズまたは解像度が変更可能な複数のサムネイルを生成するステップとを有することを特徴とする画像処理方法。
8. 前記サムネイル一覧ビューは、前記複数のサムネイルを所定の条件に基づき配置して生成することを特徴とする請求項７記載の画像処理方法。
9. 前記所定の条件は、分類、日付、ＩＤ順のいずれか一つの条件であることを特徴とする請求項８記載の画像処理方法。
10. 前記サムネイルは、階層符号化された圧縮画像データの一部の符号に基づき生成されることを特徴とする請求項７または８記載の画像処理方法。
11. 前記サムネイル一覧ビューの画面を一つの画像データとして蓄積し、前記一つの画像データに基づき前記一覧表示画面を生成することを特徴とする請求項７記載の画像処理方法。
12. 前記一覧ビューウィンドウ内に含まれるサムネイルに基づき前記一覧表示画面を生成することを特徴とする請求項７記載の画像処理方法。

Images