JP6794284B2 - カメラ機能を有する携帯可能な情報処理装置、その表示制御方法、及びプログラム - Google Patents

Description

本発明は、カメラ機能を有する携帯可能な情報処理装置における、被写体を撮影する際のガイド表示の制御技術に関する。

近年、帳票等の文書に含まれる文字等の情報を取得する際に、専用のスキャナ等で読み取るのではなく、スマートフォンやタブレットといった携帯型のデバイス（以下、「モバイル端末」と呼ぶ。）に付属するカメラ機能で撮影することが多くなっている。ただし、一般的にモバイル端末のカメラの解像度はスキャナに比べて低い。そのため、A3などの大きな用紙サイズの文書全体を、その後の文字認識処理（OCR処理）において一定精度以上の文字認識が可能な状態で撮影するためには、複数回に分けて撮影しなければならない。

この点、文書を複数回に分けて撮影を行う場合において、例えば特許文献１には、現にカメラで撮影中の領域の表示に併せ、カメラの移動に伴い画角から外れた領域であって既に撮影が済んだ領域をガイドとして表示する手法が開示されている。図１（ａ）は、特許文献１の手法を用いて文書を4回に分けて撮影を行なった場合の各回の撮影における表示状態を示している。図１（ａ）に示す通り、撮影対象文書の全領域のうち撮影済領域が認識可能に、撮影中領域と共に表示されるので、ユーザは表示された撮影済領域を参照しながらモバイル端末を移動させて次の撮影を行なうことができる。

特開２００２−０２４７６２号公報

上記特許文献１の手法では、撮影対象文書の全領域のうち撮影済領域と撮影中領域とを同時にディスプレイ上に表示させることになる。このとき、撮影中領域は常にディスプレイ上に表示されることから、ガイド用の撮影済領域がディスプレイの外にはみ出してしまう場合がある（図１（ｂ）を参照）。そうなると、ユーザが視認できる撮影済領域が十分に確保できないことになり、本来のガイド表示としての機能が損なわれてしまう。

本発明に係る情報処理装置は、カメラ機能を有する携帯可能な情報処理装置であって、 カメラを介して取得されたライブビュー画像を、表示手段に表示させる表示制御手段と、前記カメラ機能を用いて被写体の全体を複数回に分けて撮影する場合に、前記被写体のうち既に撮影を終えた撮影済領域を、前記ライブビュー画像と共に前記表示手段に表示させるための画像解析を行う画像解析手段と、を備え、前記表示制御手段は、前記画像解析手段での解析結果に従って、前記ライブビュー画像の平面空間に、前記撮影済領域を表示させる、ことを特徴とする。

本発明によれば、モバイル端末で被写体の全体を複数回に分けて撮影する場合において、撮影済領域が果たすガイド表示機能が損なわれないように、撮影済領域を撮影中領域と共にディスプレイに表示させることができる。

従来技術を説明する図である。 モバイル端末の外観の一例を示す図である。 モバイル端末のハードウェア構成の一例を示す図である。 図４は、モバイル端末のソフトウェア構成の一例を示す図である。 モバイルアプリ起動時のタッチパネルの表示状態を示す図である。 モバイルアプリの基本フローを示すフローチャートである。 全体画像生成処理の流れを示すフローチャートである。 縮小率算出の説明図である。 全3回で撮影を行う場合の1回目撮影時におけるディスプレイの状態を示す図である。 全3回で撮影を行う場合の2回目撮影時におけるディスプレイの状態を示す図である。 全3回で撮影を行う場合の3回目撮影時におけるディスプレイの状態を示す図である。 全3枚の撮影画像を結合して、1枚の全体画像が出来上がる様子を示す図である。

以下、添付図面を参照して、本発明を好適な実施例に従って詳細に説明する。なお、以下の実施例において示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。

本実施形態に係る、カメラ機能を有する携帯可能な情報処理装置の一例として、以下ではカメラ付きのモバイル端末を例に説明する。いわゆるタブレットPCやスマートフォンは、無線通信機能などの装備によって自由な場所で撮影やデータ通信などができるモバイル端末の代表例である。

図２は、モバイル端末の外観の一例を示す図である。図２（ａ）は、表示手段としてのタッチパネル１０１があるモバイル端末１００の表側（正面）を示している。タッチパネル１０１は、例えば静電容量式のＬＣＤ等で構成され、情報の出力（表示）と入力との2つの機能を備えている。図２（ｂ）は、モバイル端末１００の裏側（背面）を示している。モバイル端末の背面には、画像を取り込むための撮像用レンズ（以下、「レンズ」）１０２を備える。本実施例では、モバイル端末１００のユーザは、被写体となる文書（ここでは、注文書１１０）を後述のモバイルアプリケーション（以下、「モバイルアプリ」）を使って撮影する。なお、被写体は、注文書１１０のような紙文書の他、大判の写真やホワイトボードに書き込まれた文字等であっても良い。後述のモバイルアプリは、被写体の画像を取り込み、タッチパネル１０１に当該取り込んだ画像を表示することができる。

［ハードウェア構成］
続いて、モバイル端末１００のハードウェア構成について説明する。図３は、モバイル端末１００のハードウェア構成の一例を示す図である。モバイル端末１００は、CPU２０１、RAM２０２、ROM２０３、入出力I/F２０４、NIC２０５、カメラ部２０６、加速度／ジャイロセンサ２０７で構成され、これら各部はバス２０８で相互に接続されている。

CPU２０１は、各種のプログラムを実行して、様々な機能を実現する演算処理装置である。RAM２０２は、各種の情報を記憶する読み書き可能なメモリである。また、RAM２０２は、CPU２０１のワークエリアとしても利用される。ROM２０３は、OSや上述の撮影アプリ等の各種プログラムを記憶するメモリである。例えば、CPU２０１は、ROM２０３に記憶されているプログラムをRAM２０２にロードしてプログラムを実行する。また、CPU２０１は、フラッシュメモリ、HDD、SSDといった外部記憶装置（不図示）に記憶されているプログラムをRAM２０２に読み込んで実行することもできる。なお、モバイル端末１００の機能及び後述するシーケンスに係る処理の全部又は一部については専用のハードウェアを用いて実現してもよい。

入出力I/F２０４は、タッチパネル１０１に対して表示データを出力したり、タッチパネル１０１からの入力情報を受け付けるインタフェースである。NIC(Network Interface Card)２０５は、モバイル端末１００をネットワーク（不図示）に接続するためのインタフェースである。カメラ部２０６は、レンズ１０２を介して被写体の画像をモバイル端末１００に取り込む。バス２０８は、上述した各部を繋ぐデータ通信路である。加速度／ジャイロセンサ２０７は、モバイル端末１００の姿勢情報を検出するセンサである。

［ソフトウェア構成］
次に、モバイル端末１００のソフトウェア構成について説明する。図４は、モバイル端末１００のソフトウェア構成の一例を示す図である。モバイル端末１００のソフトウェアは、データ管理モジュール３００とモバイルアプリ３１０で構成される。そして、モバイルアプリ３１０は、メイン制御、表示制御、操作情報取得、画像取得、画像解析、画像結合の各機能に対応する複数のモジュール３１１〜３１６で構成される。前述の通り、これら各モジュールに相当するプログラムは、ROM２０３等に記憶されている。

データ管理モジュール３００は、カメラ部２０６で撮影された画像データやモバイルアプリ３１０における処理データ（アプリデータ）などを管理する。モバイルアプリ３１０は、不図示のOSが提供する制御API(Application Programming Interface)を利用することで、データ管理モジュール３００が管理する各種データにアクセスする。

ユーザは、モバイル端末１００のOSのインストール機能を利用することによって、モバイルアプリ３１０のダウンロードとインストールが可能である。モバイルアプリ３１０は、カメラ部２０６を用いて被写体を撮影し、得られた撮影画像データに対して各種の処理を行う。

メイン制御モジュール３１１は、モバイルアプリ３１０を統括的に制御するモジュールであり、以下の各モジュール３１２〜３１６に対する指示及び管理を行う。表示制御モジュール３１２は、メイン制御モジュール３１１からの指示に従い、モバイルアプリ３１０のユーザインタフェース（UI）を提供する。図５は、モバイルアプリ３１０起動時のタッチパネル１０１の表示状態を示す図である。いま、タッチパネル１０１の表示領域４００にはカメラ部２０６の撮像センサを介して取り込まれた画像（ライブビュー画像）が表示され、ユーザは当該ライブビュー画像に対して各種操作を行うことができる。なお、モバイルアプリ３１０のUIの形態（位置、大きさ、範囲、配置、表示内容など）は、図示するものに限定されないことはいうまでもない。

操作情報取得モジュール３１３は、タッチパネル１０１を介したユーザ操作に係る入力情報を取得し、取得した入力情報をメイン制御モジュール３１１に渡す。例えば、表示領域４００をユーザが手で触れると、操作情報取得モジュール３１３は、触れられた位置を検知し、当該検知した位置の情報をメイン制御モジュール３１１に送信する。

画像取得モジュール部３１４は、カメラ部２０６の撮像センサによって取り込まれた画像を取得する。さらに、例えば保存用の画像よりも解像度を落としてタッチパネル１０１に表示するような場合など、取得した画像を必要に応じて任意の解像度に変換する。

画像解析モジュール３１４は、画像取得モジュール部３１４が取得した撮影画像に対して様々な画像処理を行う。例えば、撮影領域を追跡するための特徴点抽出、文字情報を取得するための文字認識（OCR）、撮影画像に対する射影変換や縮小率の算出などを行う。

画像結合モジュール３１６は、複数回に分けて撮影された複数の画像を繋ぎ合わせて、被写体の全体に対応する一つの画像〈全体画像〉を生成する。このとき、撮影画像に対して、被写体以外の領域を除外する紙面検出や拡大・縮小、歪み部分を補正する歪み補正などの処理も行う。

［基本フロー］
続いて、モバイル端末１００を用いて被写体を複数回に分けて撮影して全体画像を生成し、当該全体画像にOCR処理を行って、被写体に含まれる文字情報を取得するまでの大まかな流れ（基本フロー）について説明する。図６は、この基本フローを示すフローチャートである。この基本フローは、例えば、ユーザがモバイルアプリ３１０を起動させることをトリガーに開始する。

ステップ６０１では、帳票等の文書を複数回に分けて撮影して全体画像を生成する処理（全体画像生成処理）が実行される。全体画像生成処理の詳細については後述する。続くステップ６０２では、ステップ６０１で得られた全体画像に対してOCR処理が実行される。そして、ステップ６０３では、OCR処理によって得られた文字認識結果が良好であるかどうかが判定される。具体的には、表示領域４００に文字認識結果の全部又は一部を表示し、文字が正しく認識されているかどうかをユーザに確認させるようにする。そして、ユーザは確認した結果を表示領域４００を介して入力する。ユーザによって文字認識結果が良好ではないと判断された場合は、ステップ６０１に戻って全体画像生成処理をやり直す。一方、文字認識結果が良好であると判断された場合は、ステップ６０４に進む。なお、文字認識結果が良好ではなかった場合に、文字認識に誤りがある個所をユーザが手動で正しい内容に修正した上でステップ６０４に進むようにしてもよい。

ステップ６０４では、OCR処理に用いた全体画像とその文字認識結果がデータ管理モジュール３０１によって保存される。この際の保存先としては、モバイル端末１００内のRAM２０２や不図示のSDカードの他、ネットワーク上のPCやサーバでも良い。また、モバイル端末１００内に一旦保存した上で、一定時間経過後にまとめてPCやサーバにアップロードしてもよい。

［全体画像生成処理］
続いて、前述のステップ６０１における全体画像生成処理の詳細について説明する。具体的な説明に入る前に、以降の説明で登場する用語について確認しておく。まず、「ライブビュー画像」とは、撮像センサによって取り込まれ、モバイル端末のディスプレイ上に現に映し出されている画像を指し、前述の図１における「撮影中領域」に相当する。「撮影画像」とは、帳票等の被写体の一部に相当する画像として保存された、全体画像の生成に用いられる画像を指す。なお、本実施例におけるディスプレイはタッチパネル１０１である。

以下、図７に示すフローチャートに沿って全体画像生成処理について詳しく説明する。全体画像生成処理は、2つの処理グループに大別される。1つは、ステップ７０３〜ステップ７１１で行われる処理であり、既に保存された撮影画像をガイドとして、ライブビュー画像と共に表示する処理である。もう1つは、ステップ７１２〜７１７で行われる処理であり、被写体の一部を写したライブビュー画像を撮影画像として保存し、ガイド表示のために必要な解析を行う処理である。本実施例では、被写体である文書の左側から右側に向かって計3回の撮影を行って全3枚の撮影画像を取得し、その後に3枚の撮影画像を結合して1枚の全体画像を生成する場合を例に説明する。なお、撮影の開始位置や終了位置、総撮影回数、撮影順序といった基本的な撮影条件に関する情報は予めＲＡＭ２０２等に設定・保持されるものとする。モバイルアプリ３１０実行時の実際の撮影フローに合わせ、図７のフローの各ステップを説明する。

ステップ７０１では、画像取得モジュール３１４が、カメラ部２０６を介して取り込まれたライブビュー画像のデータを所定のタイミングで取得する。ライブビュー画像を取得するタイミング（カメラ部２０６の撮像センサが画像を取り込むタイミング）は例えば20〜100msec毎といった所定の間隔である。

ステップ７０２では、保存済みの撮影画像があるかどうかによって処理の切り分けがなされる。保存済みの撮影画像があれば、ライブビュー画像を表示しつつ撮影画像をガイド表示する処理を行うべく、ステップ７０３に進む。一方、保存済みの撮影画像がなければステップ７１２に進む。全体画像生成処理の実行開始直後の段階（撮影を開始した段階）では、保存済みの撮影画像は存在しないため、ステップ７１２に遷移することになる。そして、ステップ７１２では、表示制御モジュール３１２が、ステップ７０１で取得したライブビュー画像をタッチパネル１０１に表示する。

ステップ７１２に続くステップ７１３では、画像解析モジュール３１５が、現在表示中のライブビュー画像が全体画像の生成に用いる画像として十分かどうか（撮影画像として保存する条件を満たしているかどうか）を判定する。保存条件を充足していればステップ７１３に進み、充足していなければステップ７０１に戻る。ここで、保存条件としては、例えば、被写体となっている対象文書内の適切な部分が撮影されている、ピンボケではない（手ブレが発生していない）、明るさが足りている、などが挙げられる。対象文書内の適切な部分が撮影されているかどうかは、文書の角や端が検出されたかどうかや、撮影済領域とのオーバラップの程度などに基づいて判断される。本発明は、被写体の全体を複数回に分けて撮影することを前提としているため、ライブビュー画像は被写体の一部に対応する画像となる。被写体である文書を3回に分けて撮影するケースの場合、1回目の撮影では左上隅と左下隅の角、2回目の撮影では上下の端、3回目の撮影では右上隅と右下隅の角がそれぞれ検出されていると適切な部分が撮影できていることになる。また、撮影済領域とどの程度オーバラップしているかは、表示中のライブビュー画像に対して特徴点の抽出を行い、そのマッチングを行うことで判定できる。このマッチングの精度や後述の結合処理におけるマージンを考慮すると、例えば25％程度のオーバラップ部分があることが望ましい。このとき、十分なマッチング精度を得られるだけの特徴点（例えば5組以上）が抽出できるのであれば、オーバラップ部分はもっと小さくても構わない。ここで特徴点とは、特徴的な情報を持つ画像上の点である。特徴点の抽出方法としては、Harrisのコーナー検出やSIFT（scale‐invariant feature transform）、SURF（Speeded Up Robust Features）などが知られている。なお、被写体が注文書のような帳票である場合は、一般的に罫線の交わる部分やコーナーが特徴的な部分に該当すると考えられる。しかし、実際にはそのような部分は似たような箇所が多くあり、特徴点として適さないことがある。その場合には、罫線やコーナー以外の特徴的なイラストや文字などを特徴点として抽出するようにすればよい。上述したような保存条件の充足が確認された時点でステップ７１４に自動的に遷移してもよいし、ユーザ指示を待って遷移してもよい。

ステップ７１４では、画像結合モジュール３１５が、表示中のライブビュー画像のデータを、結合処理で使用する撮影画像として保存（RAM２０２に格納）する。この際、ステップ７１３での保存条件の解析結果、すなわち、抽出された特徴点の情報や検出された角や端の位置座標の情報も、撮影画像と対応付けて保存される。

ステップ７１６では、画像解析モジュール３１５が、文書全体の撮影が完了したかどうかを判定する。計3回の撮影を行う本実施例では、3枚分の撮影画像が画像結合モジュール３１６に保存されていれば、文書全体の撮影が完了したと判定される。文書全体の撮影が完了している場合は、ステップ７１７に進む。一方、未撮影の領域がある場合は、ステップ７０１に戻る。

次に、保存された撮影画像をガイドとして表示するための処理グループ（ステップ７０３〜ステップ７１１）について説明する。

ステップ７０８では、未処理の撮影画像があるかどうか判定される。保存されている全ての撮影画像が注目撮影画像として処理されている場合はステップ７０９に進む。一方、未処理の撮影画像が残っている場合は、ステップ７０６に戻って次の注目撮影画像を決定して処理を続行する。

ステップ７０９では、画像解析モジュール３１５が、ライブビュー画像とその平面空間上に射影変換された撮影済領域とを包含する最も小さな矩形を導出する。導出の際、各撮影画像に対応付けて保存された文書の角や端の位置情報を参照して、文書部分のみを包含する最小矩形を求めてもよい。

ステップ７１０では、画像解析モジュール３１５が、ステップ７０９で求めた最小矩形がディスプレイの表示領域内に収まるような縮小率を算出する。図８は、縮小率算出の説明図である。図８の上段は、縮小する前の最小矩形８００を示しており、撮影済領域の一部がディスプレイの枠（タッチパネル１０１の表示領域４００）の外にはみ出している。一方、図８の下段は、縮小率αで縮小した後の最小矩形８００’を示しており、撮影済領域の全部がディスプレイの表示領域内に収まっているのが分かる。縮小率αは、最小矩形の頂点を表す座標とディスプレイの構成画素数から求められる。図８の例において、タッチパネル１０１の構成画素数を水平方向が600ピクセル、垂直方向が800ピクセルとする。そして、表示領域４００の中央を原点(0,0)＝(水平方向,垂直方向)としたきに、最小矩形の各頂点座標が(−400,300)、(−400,−300)、(250,300)、(250,−300)であったとする。この場合において、まず、水平方向、垂直方向それぞれにおいて、ディスプレイの構成画素数の範囲を超えていて、かつ絶対値が最も大きい値を求める。この場合において、ディスプレイの中央を原点としているため、水平方向、垂直方向共に構成画素数の半分の値を基準とする。上述の例の場合、水平方向については600ピクセルの半分の値300を超える絶対値となるのは、−400と400の値を持つ2つの頂点なので、400ピクセルとなる。また、垂直方向については800ピクセルの半分の値400を超える絶対値を持つ頂点はない。従って、水平方向の400ピクセルを、縮小率αの算出に用いる。具体的には、
縮小率α＝300（水平方向の構成画素数の半分）／400＝0.75となる。

なお、水平方向と垂直方向の両方に該当する頂点がある場合は、絶対値が大きい方を算出に用いればよい。また、該当する頂点が1つもない場合は、縮小を行う必要がないことを意味するので、縮小率α＝1.0となる。

ステップ７１１では表示制御モジュール３１２が、ステップ７１０で算出した縮小率αを用いて、最小矩形に含まれる画像（すなわち、ライブビュー画像に撮影済領域を足した画像）を縮小して、ディスプレイに表示する。図９Ａ〜図９Ｃは、全3回で撮影を行う場合の1回目〜3回目の各撮影時におけるディスプレイ（タッチパネル１０１の表示領域４００）の状態を示している。図９Ａは1回目の撮影時の状態を示しており、撮像センサで取り込まれたライブビュー画像９１０が、表示領域４００の画面いっぱいに表示されている。図９Ｂは、2回目の撮影時の状態を示しており、撮像センサで取り込まれたライブビュー画像９２０と1回目の撮影で得られている画像領域９２１が表示領域４００内に収まるように縮小されて表示されている。また、縮小表示に伴い、画像領域９２１が網掛け表示されている。図９Ｃは、3回目の撮影時の状態を示しており、撮像センサで取り込まれたライブビュー画像９３０、及び1回目と2回目の撮影で得られている画像領域９３１及び９３２が表示領域４００内に収まるようにさらに縮小されて表示されている。また、図９Ｃにおいては、2回目の撮影で得られた画像領域９３２の方を、1回目の撮影で得られた画像領域９３１よりも粗い網掛け表示とすることで両者を識別可能に表している。ここでは、網掛けの粗密によって1回目の撮影で得られた画像領域と2回目の撮影で得られた画像領域とを識別できるようにしているがこれに限定されない。要は、異なる撮影で得られたことがユーザに識別可能になっていればよく、例えばそれぞれを異なる色で表示するなどでも構わない。

上述の図９Ｂ及び図９Ｃの例では、ディスプレイの中心とライブビュー画像の中心とが常に一致するように縮小表示している。しかし、縮小表示のやり方はこれに限定されない。例えば、ライブビュー画像に撮影済領域を足した画像の中心が、ディスプレイの中心に位置するように表示してもよい。また、本実施例では、ライブビュー画像と撮影済領域とがオーバラップしている部分については常にライブビュー画像を優先（撮影画像に上書き）して表示しているが、オーバラップ部分の任意の位置で境界線を決めてもよい。例えば、オーバラップ部分の中央を境界線としたり、文章の固まりと認識した部分を避けて境界線を決めてもよい。

予定された回数の撮影が完了すると、ステップ７１７では、画像結合モジュール３１６が、保存された全ての撮影画像を結合（合成）して、対象文書の全体に対応する全体画像を生成する。具体的には、ステップ７１４で得た特徴点やステップ７１５で得たホモグラフィ行列を用いたスティッチング処理によって、全体画像が生成される。図１０は、全3枚の撮影画像を結合することで、1枚の全体画像が出来上がる様子を示している。撮影画像１００１〜１００３のそれぞれは、他の撮影画像とオーバラップする部分を持っている。例えば、撮影画像１００１と１００２との間では一点鎖線の矩形１０１０の部分、撮影画像１００２と１００３との間では一点鎖線の矩形１０１１の部分がオーバラップしている。そのため、各撮影画像の特徴量に基づきオーバラップ部分を特定した上で、図１０の下部に示すような一つの画像に結合して全体画像１０２０を得る。このとき、出来上がった全体画像に対するOCR処理の文字認識精度を上げるために、文字が存在しない部分で繋ぎ合わせたり、各撮影画像の倍率を調整したりしてもよい。さらには、他の撮影画像とのオーバラップ部分がなるべく多くなるようにガイド表示を制御し、取得・保存された各撮影画像のうち他の撮影画像とのオーバラップ部分については画質の良い方を結合時に採用するようにしてもよい。全体画像の生成が完了すると本処理を終える。

以上が、全体画像生成処理の内容である。

本実例によれば、モバイル端末で帳票等の被写体の全体を複数回に分けて撮影する場合において、撮影済領域が果たすガイド表示機能が損なわれないように、撮影済領域を撮影中領域と共にディスプレイに表示させることができる。

実施例１では、ガイドの役割を果たす撮影済領域がディスプレイからはみ出ないように縮小表示させていた。その場合、総撮影回数や帳票のサイズによっては、撮影済領域と共に表示されるライブビュー画像がディスプレイに対して、小さくなり過ぎてしまう。そこで、縮小率の下限値を設定し、撮影済領域やライブビュー画像が小さくなり過ぎないように制限する態様を、実施例２として説明する。なお、実施例１と共通する内容については説明を省略ないしは簡略化し、以下では差異点を中心に説明するものとする。

本実施例では、縮小率の下限値α_minを予め決定してRAM等に保持しておく。そして、前述の全体画像生成処理における縮小率を算出するステップ（Ｓ７１０）において当該下限値α_minを読み出し、これを下回らないように縮小率を決定する。ここで、下限値α_minは、使用するモバイル端末のディスプレイの物理サイズを基にユーザが決定した値、例えば0.5や0.7といった固定値とする。この場合において、例えば、タブレットのようにディスプレイの物理サイズが比較的大きい場合は下限値α_minを小さくし、スマートフォンのようにディスプレイの物理サイズが比較的小さい場合は下限値α_minを大きくすることが考えられる。そして、ステップ７１０で算出された縮小率が下限値α_minより小さい場合は下限値α_minを、適用する縮小率として決定する。こうして決定された縮小率に従って最小矩形に含まれる画像が縮小され、ディスプレイに表示されることになる。

また、下限値α_minを予め決定してRAM等に保持しておくのに代えて、全体画像生成処理の中でこれを導出して適用するようにしてもよい。この場合は、例えば、ディスプレイの物理サイズ（対角線の長さ）と下限値α_minとを対応付けたテーブル等を予め用意しておき、全体画像生成処理の開始時に当該テーブルを参照して、使用するディスプレイに最適な下限値α_minを決定するようにすればよい。このとき、ディスプレイの物理サイズそのものの情報を読み込んでもよいし、ディスプレイの構成画素数や解像度の情報を読み込んでその物理サイズを算出してもよい。後者の場合、例えばディスプレイの構成画素数が600ピクセル×800ピクセル、解像度が200dpiであれば、その物理サイズは5インチとなり、5インチに応じた下限値α_minがテーブルに基づき導出され適用されることになる。

なお、本実施例は、実施例１で説明した各種バリエーションとの組合せで用いてもよい。例えば、算出された縮小率が下限値を下回らない場合は、ライブビュー画像の中心とディスプレイの中心とを一致させ、下限値を下回る場合は、ライブビュー画像に撮影済領域を足した画像の中心とディスプレイの中心とを一致させる、といった具合である。以上のとおり、本実施例によれば、縮小率に下限を設けることで、撮影済領域やライブビュー画像が小さくなり過ぎるのを防ぐことができる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

Claims (12)

1. カメラ機能により現在撮影されているライブビュー画像を、表示手段に表示させる表示制御手段と、
   所定の保存条件を満たす場合に、前記カメラ機能により撮影される画像を、撮影済み画像として保存する保存手段と、
   前記保存手段により保存された複数の前記撮影済み画像を結合する結合手段と
   を備え、
   前記表示制御手段は、前記保存手段により前記撮影済み画像が少なくとも１つ保存されている場合、前記撮影済み画像を前記ライブビュー画像の平面空間に射影変換することにより得られる撮影済領域の画像と前記ライブビュー画像との両方を縮小して、前記表示手段に表示させる、
   ことを特徴とする情報処理装置。
2. 前記表示制御手段は、
   前記撮影済領域の画像と前記ライブビュー画像とが前記表示手段の表示領域内に収まるような縮小率を算出し、
   前記算出した縮小率に基づいて、前記撮影済領域の画像と前記ライブビュー画像との両方を縮小して前記表示手段に表示させる、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記縮小率は、前記撮影済領域の画像と前記ライブビュー画像とを包含する最も小さな矩形に基づいて算出されることを特徴とする請求項２に記載の情報処理装置。
4. 前記射影変換は、ホモグラフィ行列を用いて実行されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記縮小率は、前記矩形の頂点を表す座標と前記表示手段の構成画素数とに基づいて、算出されることを特徴とする請求項３に記載の情報処理装置。
6. 前記表示制御手段は、前記撮影済領域が、異なる撮影で得られた複数の撮影画像で構成される場合、各撮影に応じた領域を識別可能にして、前記撮影済領域の画像と前記ライブビュー画像との両方を縮小して前記表示手段に表示する、ことを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記表示制御手段は、前記ライブビュー画像の中心と前記表示手段の表示領域の中心とが一致するようにして、前記撮影済領域の画像と前記ライブビュー画像との両方を縮小して前記表示手段に表示することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記表示制御手段は、前記ライブビュー画像に前記撮影済領域の画像を足した画像の中心と前記表示手段の表示領域の中心とが一致するようにして、前記撮影済領域の画像と前記ライブビュー画像との両方を縮小して前記表示手段に表示することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
9. 前記表示制御手段は、算出した前記縮小率が所定の下限値を下回る場合、当該下限値に従って、前記撮影済領域の画像と前記ライブビュー画像との両方を縮小して前記表示手段に表示させることを特徴とする請求項２に記載の情報処理装置。
10. 前記下限値は、前記表示手段の物理サイズに応じて決定されることを特徴とする請求項９に記載の情報処理装置。
11. 情報処理装置における表示制御方法であって、
    カメラ機能により現在撮影されているライブビュー画像を、表示手段に表示させるステップと、
    所定の保存条件を満たす場合に、前記カメラ機能により撮影される画像を、撮影済み画像として保存するステップと、
    前記保存するステップで保存された複数の前記撮影済み画像を結合するステップと
    を含み、
    前記表示させるステップでは、前記撮影済み画像が少なくとも１つ保存されている場合、前記撮影済み画像を前記ライブビュー画像の平面空間に射影変換することにより得られる撮影済領域の画像と前記ライブビュー画像との両方を縮小して、前記表示手段に表示させる、
    ことを特徴とする表示制御方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images