JP6356552B2 - 情報処理装置 - Google Patents

Description

本発明の実施形態は、情報処理装置に関する。

従来、メガネ型や腕時計型などのウェアラブル機器のカメラ応用アプリやジェスチャなどの認知的（Ｐｅｒｃｅｐｔｕａｌ）ＵＩ、ＩｏＴ／Ｍ２Ｍシステムでの監視用カメラ、タブレットやスマートフォンのカメラ応用、電子内視鏡などのヘルスケア応用、車載カメラなどイメージセンサを搭載した情報処理装置が知られている。

例えば撮像手段（イメージセンサ）を有する電子内視鏡（上記情報処理装置の一例）において、グリップ部に対して一定時間以上に亘り所定値以上の圧力が検知されない場合、撮像手段に対する電力供給を停止する技術が知られている。

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

しかしながら、例えば、顔認識処理などの高度なカメラ応用では、１回の顔認識処理に時間が掛かるうえに重要なイベントを撮り損ねないようにイメージセンサによる撮像（「キャプチャ」と称する場合もある）を続ける必要があり、その撮像により得られた画像を用いた画像処理（顔認識処理）を常に実行し続けることになるので、アイドル期間（情報処理装置上で実行する処理がない期間）がないかあるいは非常に限定的であるために低消費電力状態に遷移できず、大きな電力を消費し続けてしまうという問題がある。

実施形態の情報処理装置は、イメージセンサから入力する第１の画像の変化がない場合は、第１の画像の変化を判定する第１の処理を実行しているときの電力よりも低い第１電力で次の第１の画像の入力を待つ。イメージセンサから入力する第１の画像は、画像を処理する処理装置内に設けられる内部メモリに格納され、内部メモリに格納された第１の画像の変化を判定する第１の処理の実行中は、処理装置外に設けられる主記憶装置に供給される電力は第６電力である。第１の画像の変化が検出された場合は、第２の画像は主記憶装置に格納され、主記憶装置に供給される電力は、主記憶装置にアクセス可能な第７電力である。第６電力は第７電力よりも小さく、内部メモリの容量は主記憶装置の容量より小さい。第１の画像の変化がない場合は次の第１の画像の入力を第５時間待ち、第１の画像の変化があった場合は次の第１の画像の入力を、第５時間よりも短い第６時間待ち、第１の画像の変化領域が画像の中央付近である場合に、第１の画像よりも解像度の高い第２の画像をイメージセンサから入力し、第２の画像を用いた処理を実行する。次の第１の画像の入力を第５時間待つ場合の情報処理装置の電力は第４電力であり、次の第１の画像の入力を第６時間待つ場合の情報処理装置の電力は、第４電力よりも高い第５電力である。

第１実施形態の情報処理装置の構成を示す図。 第１実施形態のイメージセンサモジュールの構成を示す図。 第１実施形態のイメージセンサモジュールの省電力モードを示す図。 第１実施形態の情報処理装置の消費電力の推移の例を示す図。 第１実施形態のイメージセンサ管理部の構成を示す図。 第１実施形態の画像処理アルゴリズムの設定を説明するための図。 第１実施形態のアプリケーションによる処理を示す図。 第１実施形態のイメージセンサ管理部による処理を示す図。 第４実施形態の第１の画像処理のバリエーションを示す図。 第５実施形態の変化検出対象領域の例を示す図。 第５実施形態の変化検出対象領域を指定する場合を説明するための図。 第６実施形態のイメージセンサの消費電力の推移を示す図。 第７実施形態のイメージセンサの消費電力の推移を示す図。 第７実施形態のイメージセンサ管理部の構成を示す図。 第７実施形態のイメージセンサ管理部による処理を示す図。 第８実施形態の情報処理装置の消費電力の推移を示す図。 第１１実施形態のイメージセンサ管理部の構成を示す図。 第１１実施形態の統計情報を説明するための図。 第１２実施形態の動作例を説明するための図。 第１４実施形態のイメージセンサ管理部の構成を示す図。 第１４実施形態の動作を示す図。 第１５実施形態の情報処理装置の構成を示す図。 第１５実施形態のイメージセンサ管理部の構成を示す図。 第１５実施形態のイメージセンサ管理部による処理を示す図。 第１６実施形態の情報処理装置の構成を示す図。 第１６実施形態のイメージセンサモジュールの構成を示す図。 第１６実施形態のイメージセンサ管理部の構成を示す図。 第１６実施形態のイメージセンサ管理部による処理を示す図。 第１８実施形態の情報処理装置の構成を示す図。 第１８実施形態の情報処理装置およびスマートフォンの構成を示す図。 第１８実施形態のアプリケーションによる処理を示す図。 第１８実施形態の同期設定部による設定を説明するための図。

以下、添付図面を参照しながら、本発明に係る情報処理装置の実施形態を詳細に説明する。

（第１実施形態）
図１は、本実施形態の情報処理装置１のハードウェア構成の一例を示す図である。図１に示すように、情報処理装置１は、ＳｏＣ(System On Chip)１０と、電源装置２０と、ＰＭＩＣ(Power Management IC)３０と、ストレージデバイス４０と、メインメモリ５０と、ネットワークデバイス６０と、イメージセンサデバイス７０とを有する。以下の説明では、ストレージデバイス４０、メインメモリ５０、ネットワークデバイス６０およびイメージセンサデバイスを区別しない場合は、単に「Ｉ／Ｏデバイス」と称する場合がある。ＳｏＣ１０は、例えばＩ２Ｃ、ＳＰＩ、ＵＡＲＴ、ＵＳＢなどの汎用で様々な用途に使えるシリアルインタフェースを備えることもでき、Ｉ／Ｏデバイスとしては様々なデバイスを使用することができる。

ＳｏＣ１０は、様々な内部モジュールを有する。図１の例では、ＳｏＣ１０は、内部モジュールとして、プロセッサコア１０１、ＳｏＣ１０内部の記憶領域であるＳＲＡＭなどの内部メモリ（ローカルメモリなどとも呼ばれる）１０２、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やハードウェアエンジンなどのアクセラレータ１０３、イメージセンサコントローラ１０４、メインメモリ５０を制御するメモリコントローラ１０５、ネットワークデバイス６０を制御するネットワークコントローラ１０６、ストレージデバイス４０を制御するストレージコントローラ１０７、内部モジュールを接続するバス１０８、オシレータなどの高周波クロックを生成する高周波発振器１０９、低周波クロックを生成する低周波発振器１１０、クロックの周波数の変換やクロック供給の可否（オン／オフ）を制御するクロック制御モジュール１１１、Ｉ／Ｏデバイスなどからの受信した割込みをプロセッサコア１０１に送る割込みコントローラ１１２、計時機能を有するＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）１１３などを有する。以下の説明では、イメージセンサコントローラ１０４、メモリコントローラ１０５、ネットワークコントローラ１０６およびストレージコントローラ１０７を互いに区別しない場合は、単に「デバイスコンロトーラ」と称する場合がある。

プロセッサコア１０１はＡＲＭプロセッサなどであり、キャッシュメモリ（Ｌ１キャッシュ、Ｌ２キャッシュ）１１４やＮＥＯＮなどの汎用ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）エンジン１１５などを備えている。図１に示したＳｏＣ１０は、プロセッサコア１０１を１つ持つシングルコアの例である。このほかに、ＳｏＣ１０内に複数のプロセッサコア１０１を持つマルチコアの構成（マルチコアプロセッサ）をとることもできる。

ＳｏＣ１０は、低い電力で待機可能な省電力モードであるＷＡＩＴモードとＤＥＥＰ ＳＬＥＥＰモードなどを備えている。ＤＥＥＰ ＳＬＥＥＰモードは、ＷＡＩＴモードより消費電力が低い。ＷＡＩＴモードでは、プロセッサコア１０１は停止（クロックゲーティング）しており状態保持できる範囲で供給電圧も下げられているが、キャッシュメモリ１１４など、イベントを割込みコントローラ１１２から通知されればすぐに再開できる状態を保持するのに必要な電力を消費している。また、デバイスコントローラなどのペリフェラルの動作に必要な電圧やクロックは供給され続けており、メインメモリ５０もアクセス可能な状態が保持されている。一方、ＤＥＥＰ ＳＬＥＥＰモード（ＳＴＯＰモードとも呼ばれる）では、プロセッサコア１０１の停止に加えて、キャッシュメモリ１１４への電力供給を停止（パワーゲーティング）し、内部メモリ１０２の内容や、デバイスコントローラなどのペリフェラルへ供給する電源電圧を、内部レジスタの値を保持できる範囲で下げる。また、メインメモリ５０が揮発性の場合は後述の省電力モードに明示的に設定し、メインメモリ５０が不揮発性の場合には電源供給を停止する。さらに、消費電力が低い低周波発振器１１０からクロックを供給されている割込みコントローラ１１２やＲＴＣ１１３やクロック制御モジュール１１１などのＤＥＥＰ ＳＬＥＥＰモードから復帰するために必要な内部モジュールだけ電力供給を継続し、消費電力が高い高周波発振器１０９やクロック制御モジュール１１１内のＰＬＬ(Ｐｈａｓｅ Ｌｏｃｋｅｄ Ｌｏｏｐ)を停止させることで、消費電力が極めて低い待機状態にできる。その一方で、ＤＥＥＰ ＳＬＥＥＰモードは、ＷＡＩＴモードよりも状態の遷移に時間を要する。なお、ＳｏＣ１０が有する省電力モードの形態はＳｏＣ１０によって様々であり、以上の例に限定されるものではない。

電源装置２０は、ＡＣ電源、一次電池、二次電池などの様々な種類のものを用いることができる。あるいは、太陽電池などのエナジーハーベスト装置と大容量キャパシタなどの蓄電装置の組み合わせなどを用いることもできる。その場合などでは、アイドル期間（情報処理装置１が処理を実行しない期間）に発電した余剰電力を蓄電部に充電しておき、アクティブ期間（情報処理装置１が処理を実行する期間）のピークの消費電力を蓄電部に蓄積している電力と太陽電池などが発電した電力とをあわせて情報処理装置１に供給するピークアシスト型の電源制御を行うこともできる。

ＰＭＩＣ３０は、電源装置２０の供給する電力を、ＳｏＣ１０やＩ／Ｏデバイスに必要な電圧に変換して供給する。

ストレージデバイス４０は、情報処理装置１の２次ストレージとして、データやプログラムを記憶するために使用する。ストレージデバイス４０は、例えばＮＡＮＤフラッシュメモリやＳＤカードなどのメモリカードやハードディスクなどで構成され得る。

メインメモリ５０は、ＤＲＡＭなどの揮発性メモリでもよいし、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＰＣＭ（Ｐｈａｓｅ Ｃｈａｎｇｅ Ｍｅｍｏｒｙ）、ＲｅＲＡＭ（Ｒｅｓｉｓｔａｎｃｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＦｅＲＡＭ（Ｆｅｒｒｏｅｌｅｃｔｒｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの不揮発性メモリでもよい。揮発性メモリの場合は、例えばＬＰＤＤＲ２などのＤＲＡＭはセルフリフレッシュモードに遷移させることで消費電力を抑制できる。不揮発性メモリの場合は、電力供給を停止することで省電力化できる。

ネットワークデバイス６０は、８０２．１１a、８０２．１１ｂ、８０２．１１ｇ、８０２．１１n、８０２.１１ａｃなどの伝送規格の無線ＬＡＮデバイスやＢｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇｂｅｅ（登録商標）などの近距離無線通信デバイスなどでもよい。

イメージセンサデバイス７０は、例えば図２のような、ＣＭＯＳイメージセンサ（撮像素子）を搭載したＣＭＯＳイメージセンサモジュールである。以下の説明では、イメージセンサデバイス７０を、「ＣＭＯＳイメージセンサモジュール７０」と称する場合がある。ＣＭＯＳイメージセンサは、ＣＣＤイメージセンサなどの他のイメージセンサあってもよい。ＣＭＯＳイメージセンサモジュール７０は、クロックを生成するオシレータ７１、クロックを制御するクロック制御部７２、ＣＭＯＳイメージセンサ７３、レンズ（不図示）などを有する。以下の説明では、ＣＭＯＳイメージセンサ７３を、「イメージセンサ７３」と称する場合がある。ここでは、ＣＭＯＳイメージセンサモジュール（イメージセンサデバイス）７０が「イメージセンサ」に対応していると考えることもできるし、ＣＭＯＳイメージセンサ７３が「イメージセンサ」に対応していると考えることもできる。

なお、イメージセンサ７３は、オートフォーカスなどの鮮明な画像を撮像するための自動調整機能等を持っていてもよい。

イメージセンサ７３は複数のフレームレートに対応しており、設定されたフレームレートに応じて、画像がＳｏＣ１０に入力され続ける。フレームレートは、例えば、３０ｆｐｓ（frames per second）などである。このように、連続した画像（「ストリーム」や「ビデオ」などと称する場合もある）が到着し続けるため、到着するデータを格納するバッファがあるメインメモリ５０もアクセス可能な状態にしておかなければならないし、イメージセンサコントローラ１０６やデータ転送用のバスにクロックを提供し続けなければならず、ＳｏＣ１０を省電力モードに移行させるアイドル期間が確保できない課題がある。本実施形態では、イメージセンサ７３やイメージセンサコントローラ１０６を細かく制御することにより必要な画像（「静止画」などと称する場合もある）だけ入力してすぐにこれらを停止させることでアイドル期間を確保する。これは、要するに、従来のいわゆる、ビデオを撮影中（あるいは、情報処理装置１の使用中／作動中（アプリケーションは実行を継続しているのでアプリケーションから見ると変化検出処理をし続けている最中）の状況下においても、イメージセンサ７３やＳｏＣ１０やメインメモリ５０を（内部的には）細かく停止あるいは省電力モードに遷移させるということになる。

イメージセンサコントローラ１０４は、イメージセンサ７３から画像を入力するためのＭＩＰＩのカメラ・シリアル・インターフェイス(ＣＳＩ)などのインタフェースを備えている。イメージセンサコントローラ１０４は、到着し続ける画像をストリーム処理する。イメージセンサコントローラ１０４は、入力した画像の解像度を変化するなどの変換処理機能などを有していてもよい。そのため、イメージセンサコントローラ１０４はＩＰＵ（Ｉｍａｇｅ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などとも呼ばれることもある。また、入力した画像をメインメモリ５０に転送するＤＭＡコントローラを内蔵していてもよい。また、例えばイメージセンサ７３の制御にＩ２Ｃインタフェースを用いる場合は、イメージセンサコントローラ１０４はＩ２Ｃコントローラを含んでいてもよいし、Ｉ２Ｃコントローラそのものであってもよい。

また、図３に示すように、ＣＭＯＳイメージセンサモジュール７０は複数の省電力モードを有する。例えば、省電力モードから撮像可能な状態に復帰するまでの復帰時間が短い第１省電力モードや、より復帰時間が長いが待機電力が低い第２省電力モードなどを有する。第１省電力モードは、内部クロックのみを停止（クロックゲーティング）する。第２省電力モードは、内部クロックの停止に加えてオシレータ７１も停止させ、さらにＣＭＯＳイメージセンサ７３の内部レジスタもオフにする（電力供給を停止する）。省電力モードから復帰して撮像可能な状態に復帰するまでに省電力モードごとに必要なレジスタ等の再設定や解像度を動的に変更する際に行うレジスタ等の再設定などの処理も「初期化」と称する。イメージセンサデバイス７０が有する省電力モードの形態はイメージセンサデバイス７０の種類によって様々であり、以上の例に限定されるものではない。これらの省電力モードを、後述するようにＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させる際に適切に利用することで情報処理装置１の一層の低消費電力化を図ることができる。

なお、情報処理装置１は、９軸センサ、赤外線センサ、音センサ（マイク）、脈拍センサなどの各種センサや、Ｍｉｒａｓｏｌなどの各種電子ペーパーや不揮発性ディスプレイ、メモリ液晶ディスプレイやＩＧＺＯ ＬＣＤのような低いリフレッシュレートで動作するディスプレイ、ＰＳＲ（Ｐａｎｅｌ Ｓｅｌｆ Ｒｅｆｒｅｓｈ）対応の液晶ディスプレイ、メガネ型のウェアラブル機器などではヘッドマウントディスプレイのディスプレイデバイス、そして、それらを制御するコントローラを備えていてもよい。以降の全ての実施形態においても同様である。

本実施形態では、イメージセンサデバイス７０から取得（入力）した画像に、処理すべき対象が映っていない期間や検出すべき動きのない期間（これらは「画像変化のない、あるいは小さい期間、または、検出すべき画像変化のない、あるいは小さい期間」、要するに「アプリケーションにとって意味のある画像変化」、「アプリケーションが要求する画像変化」のない、あるいは小さい期間であると考えることができる）などに、情報処理装置１を低消費電力化することを目的とし、周辺環境や状況の変化やアプリケーションの高度な画像処理（例えば顔認識処理など）のトリガとなるイベントを、短時間かつ低消費電力で検知可能な待機状態の画像処理（アプリケーションによる処理の前処理）を導入し、アプリケーション側で、トリガとなるイベントが無いのに高度な画像処理を実行してしまうなど本来不必要な高度な画像処理を実行してしまう時間を削減することで、情報処理装置１を低消費電力状態にできるアイドル期間をできるだけ確保する。さらに、導入した待機状態の画像処理を、アプリケーション側で実行せずにＯＳ（オペレーティングシステム）側に分離し、ＯＳ側で、僅かなアイドル期間でも積極的にＤＥＥＰ ＳＬＥＥＰモードなどの省電力モードに遷移させて省電力化する。僅かなアイドル期間とは例えば数ｍｓ〜数十ｍｓである。さらに、待機状態の画像処理を、イメージセンサデバイス７０から取得した、アプリケーションが実行する高度の画像処理に用いられる画像よりも解像度が低い画像（以下の説明では、「低解像度画像」と称する場合がある）を利用して計算処理量を削減し、アクセラレータ１０３やＳＩＭＤエンジン１１５など（以下、これらを総称して「アクセラレータ」とする場合がある）を利用して高速化することで、短時間で完了させ、アイドル期間をさらに長くすることができる。待機状態の画像処理の結果、環境変化、状況変化、特定の対象物などが検出（総称して「変化検出」と称する）されると、これをトリガとして、アプリケーションに通知し、さらに、アプリケーション側の高度の画像処理に必要な画像（上述の低解像度画像よりも解像度が高い高解像度画像）を渡し、アプリケーションに制御を移す。アプリケーションに渡すのは、アプリケーションの要求に応じて、１枚の画像であってもよいし、ビデオやストリームなど複数の画像でもよい。そして、アプリケーションは、ＯＳから渡された高解像度画像を用いて、独自の高度の画像処理を実行する。

要するに、本実施形態の情報処理装置１は、イメージセンサ７３から入力する第１の画像（この例では「低解像度画像」）の変化がない場合は、次の第１の画像の入力を待ち、第１の画像の変化があった場合は、第１の画像よりも解像度の高い第２の画像（この例では「高解像度画像」）をイメージセンサ７３から入力し、第２の画像を用いた処理を実行する。本実施形態では、第２の画像の変化を検出するために、第１の画像を用いて第１の画像の変化を判定する処理を行っていると考えることもできる。

ただし、これに限らず、例えばアプリケーションの画像処理に用いられる画像の解像度と、待機状態の画像処理に用いられる画像の解像度とが同じであってもよい。要するに、本実施形態では、常にアプリケーションの画像処理を実行し続けるのではなく、アプリケーションの画像処理の前処理として、アプリケーションの画像処理よりも処理量が少ない画像処理であって、アプリケーションの画像処理の実行の可否を決定するための画像処理を実行する。

なお、ＯＳとは、情報処理装置１が備えるハードウェア資源（イメージセンサデバイス７０等）を制御する機能を提供するための基本プログラムである。例えばＬｉｎｕｘ（登録商標）などである。また、アプリケーションとは、ＯＳを利用して、特定の機能を提供するためのプログラムであり、その種類は任意である。プロセッサコア１０１が、ＯＳやアプリケーションを実行することにより、各種の機能を実現することができる。また、本明細書において、「撮像」とは、レンズなどの光学系により結像された被写体（撮像対象）の像を、電気信号に変換することなどを指す。

図４は、本実形態の情報処理装置１の利用時に観測される情報処理装置１全体の消費電力の推移の例を示す図である。図４を用いて、本実施形態の概要を説明する。図４に示すように、まずは時刻Ｔ０に、アプリケーションが実行を開始すると、アプリケーションの初期化やＣＭＯＳイメージセンサ７３の初期化などの初期化処理が行われる。なお、初期化処理には、アプリケーションの実行を開始する際に一度行えばよい処理と、イメージセンサ７３を省電力モードから復帰させて撮像する度に行う処理や、動的に設定を変更する時に行う処理などがあり、ここにはそれらすべてが含まれてもよい。時刻Ｔ１から、アプリケーションは、ＯＳ側に対して、環境変化やイベントを検出する（画像変化を検出する）待機状態の画像処理の開始を要求し、ＯＳから画像変化を検出した旨の通知が来るまで待機状態に入る。一方のＯＳ側は、アプリケーションから、待機状態の画像処理の開始を要求されると、ＣＭＯＳイメージセンサ７３から低解像度画像を取り込み、これを入力とする待機状態の画像処理を開始する。

この待機状態の画像処理は、ＣＭＯＳイメージセンサ７３から取得する画像の変化を検出する処理（以下の説明では、「変化検出処理」と称する場合がある）であり、様々な例が考えられる。例えば、アプリケーションで高度な顔認識処理をする場合、この前処理として、人が映っていない期間（アイドル状態にできる期間）を検出するための画像処理が考えられる。本実施形態の情報処理装置１が、監視カメラのような固定型カメラか、あるいは、メガネ型ウェアラブル機器の非固定型カメラでもこれを装着している人が静止しているような場合、待機状態の画像処理の画像処理アルゴリズムの例として、背景画像などの人が入ってくる前の変化がない期間の画像（ＣＭＯＳイメージセンサ７３による撮像で得られた画像）と、ＣＭＯＳイメージセンサ７３から取得できる現在の画像との差分を計算して変化を検出することで、現在の画像に人が映っているか否かを検出することができる。背景画像とは、背景差分法などで一般的に利用されるさまざまな種類のものであってよく、一枚の画像であってもよいし、変化がない期間の複数の入力画像の平均画像でもよいし、平均的な動作や変化を計算しモデル化した画像であってもよいし、入力される画像の多くの画素で値が変化するような場合などに再設定される画像などであってもよいのは言うまでもない。あるいは、ＣＭＯＳイメージセンサ７３から取得できる現在の画像の中に肌色が存在するかを調べることで、当該画像に人が映っているか否かを検出することもできる。また、アプリケーションでバーコードの内容を読み取る高度な画像処理を実行する場合、この前処理として、バーコードが映っていない期間（アイドル状態にできる期間）を検出するための画像処理が考えられる。本実施形態の情報処理装置１がメガネ型ウェアラブル機器の非固定型カメラやスマートフォンなどのカメラ応用で、撮像により得られた画像に映っているバーコードを検出するような場合、待機状態の画像処理アルゴリズムの例としては、例えば、ＣＭＯＳイメージセンサ７３から取得できる現在の画像の中に、バーコードの特徴を表す濃淡の変化が大きい部分が存在するか否かを検出することで、現在の画像にバーコードが存在するか否かを検出することができる。メガネ型ウェアラブル機器やカプセル型の内視鏡などＣＭＯＳイメージセンサ７３自体が移動する場合は、背景画像と差分を取ることで背景画像を入力した時点から移動したか否かを判定するような処理であってもよい。また、内視鏡のように例えば側方３６０度の画像が取得できるような場合は、どの方向に高解像度で撮像し保存しておきたいものが写っているのか(撮像目標がどの方向にあるのか)判定するような処理も考えられるし、さらにその方向の画像に変化があるかをさらに検出する処理であってもよい。

また、待機状態の画像処理では、アプリケーション側の高度な画像処理に必要な高解像度画像を利用する必要はない。低消費電力状態にできる期間を可能な限り確保するためのアイドル状態を検出することが可能な範囲であれば、解像度をいくらでも低くすることができる。低解像度画像は、イメージセンサ７３が低解像度で撮像したものでもよいし、イメージセンサ７３から入力された画像をイメージセンサコントローラ１０４で低解像度画像に変換したものを用いてもよい。解像度を低くできれば、計算量が減ることにより処理時間を短くできる。また、イメージセンサ７３が低解像度で撮像し、それによって高いフレームレートを利用すれば（例えば、高解像度での撮像時は３０ｆｐｓを利用し、低解像度での撮像時は１２０ｆｐｓを利用する）、イメージセンサ７３からＳｏＣ１０やメインメモリ５０のバッファまでの画像データ転送時間を短くできるので、撮像で得られた画像を用いた処理を早く開始できるので待機時の画像処理に要する時間を短くすることができる。さらに、単純に計算量が減ったりするだけでなく、後述の他の実施形態で説明するように一般的に容量の少ない内部メモリ１０２などを利用し易くなるのでさらに低消費電力化できる。また、後述の他の実施形態で説明するように、内部メモリ（ローカルメモリ）１０２上では電力効率が高いＮＥＯＮなどを利用できるようになるのでアクセラレータ１０３の効率的な利用を促進する。また、後述の他の実施形態で説明するように待機状態の画像処理をマイコンにオフロードする際にはマイコンの負荷を減らすことができるのでよりローパワーなマイコンを利用できる。さらに、他の実施形態で説明するように、待機状態の画像処理をＣＭＯＳイメージセンサ７３の内部で実行する際にバッファが小さくて済むので実現しやすくなる。以上のように、待機状態の画像処理に用いられる画像の解像度を、アプリケーションの画像処理に用いられる画像の解像度よりも低くする、あるいはフレームレートを高くする（あるいはその両方を行う）ことで、アプリケーションから分離して変化検出処理を行うフレームワークにおける様々な仕掛けとの連携を高める効果があり、変化検出処理の処理時間を大幅に削減し、情報処理装置１を低消費電力状態に出来る期間を最大化できる。

また、待機状態の画像処理では、アプリケーションが必要とするような鮮明な画像を利用する必要がない。変化の有無を検出できる範囲であれば、不鮮明な画像を用いてもよく、変化を検出した場合にはアプリケーション側が必要とする鮮明な画像を改めて取得し直せばよい。鮮明な画像を取得するためにＣＭＯＳイメージセンサ７３の初期化処理などに時間が掛かるようであれば、初期化処理の時間（以下、「初期化時間」と称する場合がある）を、鮮明な画像を取得するのに必要な時間よりも短い時間に設定して不鮮明な画像を利用することで、変化検出処理を短時間で実行できる。これには、例えば、従来は破棄していた鮮明な画像が取得できるまでに入力されるフレーム（画像）を変化検出処理に利用したり、オートフォーカスをしないように設定しその状態で撮像される画像を利用したり、十分な明るさがない状態で撮像したり、画像の入力が開始されるまでの時間が短い撮像モードを利用するなどが含まれる。

要するに、本実施形態の情報処理装置１において、イメージセンサ７３の電力は、画像の入力時には第２電力であり、画像の入力時以外は第２電力よりも低い第３電力であり、第１の画像（この例では「低解像度画像」）の変化がない期間においては、イメージセンサ７３は、画像の入力に掛かる時間が第１時間の入力を行い、第１の画像の変化があった場合は、イメージセンサ７３は、画像の入力に掛かる時間が第２時間の入力を行い、第１時間は第２時間よりも短いという形態であってもよい。また、例えば第１の画像の変化がない期間においては、第１の画像を入力する際の入力要求処理が開始されてから第１の画像の入力処理が開始されるまでの時間は第３時間であり、第１の画像の変化があった場合は、第２の画像（この例では「高解像度画像」）を入力する際の入力要求処理が開始されてから第２の画像の入力処理が開始されるまでの時間は第４時間であり、第３時間は第４時間よりも短いという形態であってもよい。

以上のようにして、低消費電力状態にできるアイドル期間を長く確保することができる。このような待機状態の画像処理で変化が検出されると、その旨をアプリケーションに通知し、アプリケーション側の画像処理に必要な高解像度画像を撮像して渡し、アプリケーションに制御を移す。そして、アプリケーションは、顔認識処理やバーコードの内容を読み取る処理、あるいは画像をストレージデバイス４０などに保存・記録する処理やネットワークデバイス６０を介して転送する処理などのアプリケーション独自の画像処理を行う。

以上のように、ＣＭＯＳイメージセンサ７３から順次に取得する画像に変化が現れない期間（画像変化の無い期間）においては、アプリケーションの高度な画像処理を上記のような軽量な前処理に置き換えることで、人やバーコードなどの処理すべき対象物が画像に映っていないときまでアプリケーションの画像処理を実行させ続ける必要がなくなり、画像変化が無い場合には、情報処理装置１を低消費電力状態にできる期間を最大化できる。これにより、一層の低消費電力化を実現できる。待機状態の画像処理に用いられるアルゴリズムは、背景画像との差分を計算するような多くのアプリケーションで共通に利用できるものや、アプリケーションに固有のものでもよく、様々なものがあり、ここに示した限りでない。また、本実施形態のフレームワークにより、多くのアプリケーションで共通に利用できる変化検出処理は、アクセラレータ１０３やＳＩＭＤエンジン１１５などのアクセラレータに対して最適化された実装をＯＳ内に用意しておくことが可能で、アプリケーションから容易に最適化された実装とそれを用いた変化検出処理を利用することができる利点もある。ＯＳ内で変化検出処理を実行するとユーザ空間などへのデータコピーの回数を減らせるなどの利点もある。

図４に戻って説明を続ける。図４に示す時刻Ｔ２では、待機状態の画像処理の結果、画像変化を検出しなかったので、即座に情報処理装置１全体を消費電力が極めて低い低消費電力状態に明示的に遷移させる。具体的には、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させ、ＣＭＯＳイメージセンサモジュール７０を省電力モードに遷移させ、メインメモリ５０が揮発性メモリの場合は省電力モード（例えばセルフリフレッシュモード等）に遷移させ、不揮発性メモリの場合は電力供給を停止させる。低消費電力状態のまま一定時間経過するのを待った後、各々を省電力モードから復帰させ、再び待機状態の画像処理を実行する。以上の一連の処理を、待機状態の画像処理で画像変化が検出されるまで繰り返す。

情報処理装置１全体を消費電力が極めて低い低消費電力状態へ高速に遷移させる方法の例を示す。まず、Ｖｉｄｅｏ ｆｏｒ Ｌｉｎｕｘ Ｔｗｏ(Ｖ４Ｌ２)などのビデオキャプチャをするＬｉｎｕｘのフレームワークなどのシーケンスでは、画像入力のストリーム処理を開始してから、入力される画像を用いた画像処理を行い、画像処理が完了してからストリーム処理を停止する。しかし、これでは第１の画像処理中もイメージセンサが動作し続けてしまうので、本実施形態では、画像入力のストリーム処理を開始し、必要な画像（例えば１枚）だけ入力し終えたらストリーム処理を停止し、そのあとで入力された画像を用いて第１の画像処理を実行するというシーケンスに変換することで第１の画像処理を実行中でイメージセンサ７３の画像入力が必要ない時に（画像入力後すぐに）イメージセンサ７３を省電力モードに設定あるいは停止させることで省電力化する。通常、カメラなどではユーザが連写を要求することがあるのでこのような制御はできないが、本実施形態の基本動作は、画像を入力して変化を検出しない場合は待つことが決まっているのでこのような積極的な省電力化が可能になる。また、キャプチャ処理の場合、連続して画像を入力するため、入力処理を効率よくするためにダブルバッファなどを利用することがあるが、画像を１枚利用して変化を検出する場合には、ダブルバッファに画像が２枚入力されるまで待たずに、１枚入力されたら割り込みが発生するように設定し、１枚入力されたら即座にイメージセンサ７３やＩＰＵを停止させる。イメージセンサ７３の停止が完了するのを待たずにＩＰＵを先に停止させるなどの操作を積極的に行ってもよい。

要するに、情報処理装置１は、第１の画像（この例では「低解像度画像」）の変化がない場合は第１電力で次の第１の画像の入力を待ち、第１電力は、第１の画像の変化を判定する第１の処理（この例では「待機状態の画像処理」）を実行しているときの電力よりも低い。

次に、時刻Ｔ４で、待機状態の画像処理の結果、画像変化が検出されると、アプリケーションの画像処理に必要な高解像度画像をＣＭＯＳイメージセンサ７３から取得し直し、画像変化がＯＳ側で検出されるのを時刻Ｔ１から待っているアプリケーションに、画像変化を検出した旨を通知するとともに、取得し直した高解像度画像を渡し、制御をアプリケーションに移す。時刻Ｔ４からは、アプリケーションがＯＳ側から受け取った高解像度画像を利用して顔認識処理などのアプリケーション独自の画像処理を行う。時刻Ｔ５に、アプリケーションの画像処理が完了すると、再びアプリケーションは、ＯＳ側に対して、環境変化やイベントを表す画像変化を検出する待機状態の画像処理の開始を要求し、上述した一連の処理が繰り返される。図４の点線は、本方式を用いずに、常時アプリケーションの高度な画像処理を実行し続けた場合の消費電力を示し、図４の実線は、本方式を用いた場合の消費電力を示している。図４の点線が示す消費電力と実線が示す消費電力との差分が、本方式によって削減できる消費電力に相当する。なお、図４では、アプリケーションの画像処理をした場合に掛かる１回分の時間に１回の待機状態の画像処理を実行しているが、この限りではなく、待機状態の画像処理が何回行われてもよい。このように、本実施形態の構成によれば、従来よりも短い間隔でこまめに多くの画像を処理することができる。そのため、画像変化に素早く反応できるので(応答性を高めることができるので)、認識能力・変化検出能力も高くすることができる。このように、情報処理装置１のユーザビリティを高めることができ、さらにこれを少ない消費電力で実現できることが分かる。なお、図４は、あくまで一例でありこの限りではない。

図５は、本実施形態の情報処理装置１に搭載されたＯＳによって提供されるイメージセンサ管理部１２０の機能構成の一例を示す図である。イメージセンサ管理部１２０は、例えばＳｏＣ１０上で動作するＯＳに含まれるデバイスドライバ（ＣＭＯＳイメージセンサモジュール７０のデバイスドライバ）などの形態で実施される。図５の例では、イメージセンサ管理部１２０は、第１画像処理部１２１と、待機状態制御部１２２と、待機状態電力制御部１２３と、イメージセンサ制御部１２４とを有する。イメージセンサ制御部１２４は、ＣＭＯＳイメージセンサモジュール７０（ＣＭＯＳイメージセンサ７３）を制御してＩ２Ｃなどのインタフェース経由でレジスタの設定や画像（ＣＭＯＳイメージセンサ７３による撮像で得られた画像）のＣＳＩなどのインタフェース経由での取得などを行う。また、図５に示すように、アプリケーションは、アプリケーション独自の画像処理（以下の説明では、「第２の画像処理」と称する場合がある）を実行する第２画像処理部１３０を有している。本実施形態では、アプリケーションと、ＯＳ内のイメージセンサ管理部１２０とが連携して、情報処理装置１の低消費電力化を実現する。

第１画像処理部１２１は、待機状態の画像処理を行う。以下の説明では、待機状態の画像処理を「第１の画像処理」と称する場合がある。第１画像処理部１２１は、イメージセンサ制御部１２４がイメージセンサ７３から取得した画像を用いて、アプリケーション側の高度な画像処理（以下の説明では、「第２の画像処理」と称する場合がある）の実行の可否を決定するための第１の画像処理を実行する。第１の画像処理（この例では請求項の「第１の処理」に対応）は、第２の画像処理（この例では請求項の「第２の処理」に対応）よりも処理量が少ない、あるいは消費電力が小さい処理である。

要するに、情報処理装置１は、イメージセンサ７３から入力する第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）の結果、第１の画像の変化を検出しなかった場合は、次の第１の画像の入力を待ち、第１の画像の変化を検出した場合は、第２の処理（この例では「第２の画像処理」）を実行し、第１の処理を実行するときの電力は、第２の処理を実行するときの電力よりも小さい。また、情報処理装置１は、第１の画像の変化がない場合は第１電力で次の第１の画像の入力を待ち、第１電力は、第１の画像の変化を判定する第１の処理を実行しているときの電力よりも低い。

また、本実施形態の情報処理装置１は、イメージセンサ７３から入力する第１の画像の対象物を認識する第１の処理（この例では「第１の画像処理」）の結果、対象物を認識しなかった場合は、次の第１の画像の入力を待ち、対象物を認識した場合は、第１の画像よりも解像度の高い第２の画像をイメージセンサ７３から入力し、第２の画像を用いた第２の処理（この例では「第２の画像処理」）を実行する形態であってもよい。また、本実施形態の情報処理装置１は、イメージセンサ７３から入力する第１の画像の対象物を認識する第１の処理の結果、対象物を認識しなかった場合は、次の第１の画像の入力を待ち、対象物を認識した場合は、第２の処理を実行し、第１の処理を実行するときの電力は、第２の処理を実行するときの電力よりも小さい形態であってもよい。この場合、第２の処理に用いられる第２の画像の解像度は、本実施形態のように第１の画像よりも高くてもよいし、第１の画像と同じ解像度であってもよい。

本実施形態では、第１画像処理部１２１は、第２の画像処理に用いられる画像よりも解像度が低い画像（低解像度画像）をイメージセンサ制御部１２４に取得させ、その取得させた低解像度画像を用いて第１の画像処理を実行する。なお、画像の解像度は第１の画像処理と第２の画像処理で同じであってもよく、その場合は、第１の画像処理で利用した画像をそのまま第２画像処理で利用すればよく、第２の画像処理のために画像を取得しなおす必要はない。これも他の実施例についても同様である。

なお、第１の画像処理は、イメージセンサ制御部１２４が取得した画像の変化を検出するための処理であり、第１の画像処理によって、イメージセンサ制御部１２４が取得した画像の変化が検出された場合は、第２の画像処理の実行条件を満たすことになる。ここでは、イメージセンサ制御部１２４が取得した画像の変化を検出するための処理には、例えばフレーム間の差分を計算して画像変化を検出する処理だけでなく、イメージセンサ制御部１２４が取得した画像に特定の対象物（例えばバーコード等）が映っているか否かを検出するための処理も含まれる。例えば第１の画像処理が、イメージセンサ制御部１２４が取得した画像に特定の対象物（例えばバーコード等）が映っているか否かを検出するための処理である場合、この第１の画像処理によって、イメージセンサ制御部１２４が取得した画像に特定の対象物が映っていることが検出された場合は、第２の画像処理の実行条件を満たすことになる。

待機状態制御部１２２は、イメージセンサ管理部１２０の動作を統括的に制御する。本実施形態では、待機状態制御部１２２は、第１の画像処理の結果が、第２の画像処理の実行条件を満たしている場合（画像変化が検出された場合）は、第２画像処理部１３０に第２の画像処理を実行させる制御を行う。本実施形態では、待機状態制御部１２２は、第１の画像処理の結果が、第２の画像処理の実行条件を満たしている場合、第２の画像処理に必要な解像度の画像（高解像度画像）をイメージセンサ制御部１２４に取得させ、その取得させた画像と、第２の画像処理の実行条件を満たすことを示す情報（画像変化を検出したことを示す情報）とを第２画像処理部１３０（アプリケーション）に通知する。ここでは、この通知制御が、第２画像処理部１３０に第２の画像処理を実行させる制御に相当するが、第２画像処理部１３０に第２の画像処理を実行させる制御の形態はこれに限られるものではない。なお、この例では、待機状態制御部１２２は、「実行制御部」に対応していると考えることができる。

また、本実施形態では、待機状態制御部１２２は、アプリケーションからの指定に応じて、予め第１画像処理部１２１に用意されている複数種類の画像処理アルゴリズムのうちの少なくとも１つを、第１の画像処理に用いる画像処理アルゴリズムとして設定する制御を行う。この例では、待機状態制御部１２２は、「設定制御部」に対応していると考えることができる。図６の例では、第１画像処理部１２１には、３種類のアルゴリズムが予め用意されており、それぞれに割り当てられるアルゴリズム識別子（図６の例ではアルゴリズム１〜３）によって識別される。例えば図６に示すアルゴリズム１で識別されるアルゴリズムは、イメージセンサ制御部１２４が取得した画像に、特定の対象物（例えばバーコード等）が映っているか否かを検出するための処理のアルゴリズムであり、アルゴリズム２で識別されるアルゴリズムは、イメージセンサ制御部１２４が取得した画像の変化を検出するための処理のアルゴリズムであってもよい。

本実施形態では、ＯＳ（見方を変えれば情報処理装置１）は、アプリケーション（この例では第２画像処理部１３０であると考えてもよい）が、予め第１画像処理部１２１に用意されている複数種類の画像処理アルゴリズムのうちの少なくとも１つを、第１の画像処理に用いる画像処理アルゴリズムとして指定するためのインタフェース部（ＡＰＩ）を有している。例えばアプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、ＣＭＯＳイメージセンサモジュール７０のデバイスドライバ内のイメージセンサ管理部１２０に対して、第１画像処理部１２１に用意されている様々な画像処理アルゴリズムからアプリケーションが利用したいものを指定することができる。アプリケーションは、所望のアルゴリズムを識別するアルゴリズム識別子（図６のアルゴリズム１〜３）を選択することで、当該アルゴリズム識別子で識別されるアルゴリズムを指定することができる。また、例えば、人とバーコードのような複数の種類の物体を対象とする高度な画像処理をするために、複数種類の変化などを検出する必要がある場合は、第１画像処理部１２１で利用するアルゴリズムとして、複数のアルゴリズムを指定することもできる。図６に示すように、例えばアプリケーションＡは、図６のアルゴリズム１とアルゴリズム２を指定することもできる。また、画像処理アルゴリズム毎にＣＭＯＳイメージセンサ７３から取得する画像（第１の画像処理に用いられる画像）の解像度のデフォルト値（例えば９６ｘ１２８）やＣＭＯＳイメージセンサ７３の初期化の待ち時間（初期化時間）などが定義されているが、デフォルト値以外の値を利用するために、ＯＳは、これらを指定または設定するためのインタフェース部（ＡＰＩ）も有している。

また、待機状態制御部１２２は、アプリケーションからの要求に応じて、第１の画像処理に用いる画像処理アルゴリズムを外部から取得することもできる。この例では、待機状態制御部１２２は、「取得制御部」に対応していると考えることができる。また、この例では、ＯＳは、アプリケーションが、第１の画像処理に用いる画像処理アルゴリズム（第１画像処理部１２１が有していない独自のアルゴリズム）を第１画像処理部１２１に取得させるためのインタフェース部（ＡＰＩ）を有している。このインタフェース部は、例えばアプリケーションが独自に作成した、第１の画像処理の画像処理アルゴリズムをＯＳ内にダウンロードするための手段として機能する。これにより、アプリケーションに適した画像処理アルゴリズムが予めＯＳ内に用意されていない場合でも、アプリケーションに適した画像処理アルゴリズムをダウンロードし、そのダウンロードした画像処理アルゴリズムを用いて第１の画像処理を実行することができる。ここで、アプリケーションは、第２の画像処理を行わず、第１の画像処理に用いる画像処理アルゴリズムの追加や、イメージセンサ管理部１２０のバージョンのアップグレードを行うためだけのソフトウェアなどであってもよい。他の実施形態においても同様である。

アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、ＣＭＯＳイメージセンサモジュール７０のデバイスドライバ内のイメージセンサ管理部１２０に対して、独自に作成した画像処理アルゴリズムを第１画像処理部１２１にダウンロードさせることができる。

図６の例では、アプリケーションＢが、独自に定義した画像処理アルゴリズム４を第１画像処理部１２１にダウンロードさせたことを示している。第１画像処理部１２１が、アプリケーションからの要求に応じて、予め用意された画像処理アルゴリズム以外の画像処理アルゴリズムをダウンロードした場合は、待機状態制御部１２２は、そのダウンロードした画像処理アルゴリズムを、第１の画像処理に用いる画像処理アルゴリズムのリストに追加登録し、追加登録した画像処理アルゴリズムを識別するアルゴリズム識別子（図６の例ではアルゴリズム４）をアプリケーションに通知する。以降、アプリケーションは、その通知されたアルゴリズム識別子を利用して、当該アルゴリズム識別子で識別されるアルゴリズムを指定することができる。

図５に戻って説明を続ける。待機状態電力制御部１２３は、情報処理装置１の省電力モードを制御する。本実施形態では、待機状態電力制御部１２３は、第１の画像処理の結果が、第２の画像処理の実行条件を満たしていない場合は、第１の画像処理を実行可能な第１状態よりも消費電力が小さい第２状態（低消費電力状態）に情報処理装置１を遷移させる制御を行う。この例では、待機状態電力制御部１２３は、第１の画像処理の結果が、第２の画像処理の実行条件を満たしていない場合は、情報処理装置１の各部に対する電力供給を制御する電力管理部１４０に対して、情報処理装置１を第２状態に遷移させるように指示する。なお、この例では、待機状態電力制御部１２３は、「電力制御部」に対応していると考えることができる。

図７は、アプリケーションによる処理の一例を示すフローチャートである。図７に示すように、まず、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどの手段を介して、イメージセンサ管理部１２０（デバイスドライバ）に対して、必要な様々な初期化処理を要求する（ステップ４０１）。なお、アプリケーションが、イメージセンサ管理部１２０の機能（ＯＳの機能）を呼び出すための手段は以降も同様である。例えば、アプリケーションは、ＣＭＯＳイメージセンサモジュール７０のデバイス初期化処理の他、前述したように、所望の画像処理アルゴリズムを識別するアルゴリズム識別子を指定することで、その指定したアルゴリズム識別子で識別される画像処理アルゴリズムを、第１の画像処理に用いる画像処理アルゴリズムとして設定することを要求することができる。また、例えば図６の例では、画像処理アルゴリズム毎に、ＣＭＯＳイメージセンサ７３から取得する画像（第１の画像処理に用いられる画像）の解像度のデフォルト値（例えば９６ｘ１２８）やＣＭＯＳイメージセンサ７３の初期化の待ち時間（例えば数ｍｓ）などが予め定義されているが、デフォルト値から変更する必要があれば、その変更後の値を指定することで、その変更後の値に応じた設定を行うことを要求することもできる。また、例えばアプリケーションが、予め第１画像処理部１２１に用意された画像処理アルゴリズム以外の独自定義の画像処理アルゴリズムを第１の画像処理に用いる画像処理アルゴリズムとして利用したい場合は、イメージセンサ管理部１２０に対して、これをダウンロードする処理を要求することもできる。また、アプリケーションは、第２の画像処理に必要な画像の解像度（例えば９６０ｘ１２８０）や、第１の画像処理を繰返し実行する際の時間間隔などをイメージセンサ管理部１２０に通知することもできる。

ステップＳ４０１の初期化処理の要求が完了すると、アプリケーションは、イメージセンサ管理部１２０に対して、ステップＳ４０１で指定した画像処理アルゴリズムでの第１の画像処理の実行を要求する（ステップＳ４０２）。

ステップＳ４０２の後、アプリケーションは、イメージセンサ管理部１２０から、画像変化を検出した旨の通知（第２の画像処理の実行条件を満たすことを示す情報の通知であると考えることもできる）を待つ（ステップＳ４０３）。アプリケーションは、イメージセンサ管理部１２０から、画像変化を検出した旨の通知を受けると、これと同時に受け取る高解像度画像を利用して、第２画像処理部１３０でアプリケーション独自の第２の画像処理を実行する（ステップＳ４０４）。第２の画像処理終了後、アプリケーションは、再びステップＳ４０２以降の処理を繰り返す。なお、アプリケーションが通知を受けた後も画像変化検出の処理が継続される形態でもよく、その場合は、ステップＳ４０４終了後にステップＳ４０３に戻ってもよい。

図８は、上述のアプリケーションによる処理に連動するイメージセンサ管理部１２０による処理の一例を示すフローチャートである。図８のフローは、イメージセンサ管理部１２０は、図７のステップＳ４０１のアプリケーションからの要求を受けて、初期化処理を完了していることを前提としている。イメージセンサ管理部１２０が実行する初期化処理では、前述したアプリケーションから指定された初期化処理の設定内容を受信した待機状態制御部１２２が、その受信した設定内容に基づく情報を、イメージセンサ管理部１２０内に記録する、あるいは、イメージセンサ７３のレジスタなどに設定していく。例えば、アプリケーションから所定のアルゴリズム識別子を指定された場合、待機状態制御部１２２は、当該アルゴリズム識別子で識別される画像処理アルゴリズムが指定されたことを、待機状態制御部１２２内に記録しておく。また、アプリケーションから指定された第１の画像処理に用いられる画像の解像度や初期化の待ち時間がデフォルト値と異なる場合、待機状態制御部１２２は、これを第１画像処理部１２１に反映する制御を行う。また、例えばアプリケーションから、予め第１画像処理部１２１に用意されたもの以外の独自定義の画像処理アルゴリズムのダウンロードを要求された場合、待機状態制御部１２２は、その要求された画像処理アルゴリズムをダウンロードして第１の画像処理に用いる画像処理アルゴリズムのリストに追加登録し、追加登録したアルゴリズム識別子をアプリケーションに通知する。以降、アプリケーションは、通知されたアルゴリズム識別子を利用して、当該アルゴリズム識別子で識別されるアルゴリズムを指定することができるようになる。また、例えばアプリケーションから、アプリケーションが実行する第２画像処理に用いる画像の解像度が指定された場合、待機状態制御部１２２は、その指定された情報を待機状態制御部１２２内に記録する。また、アプリケーションから、第１の画像処理を繰返し実行する際の時間間隔が指定された場合、待機状態制御部１２２は、その指定された情報を元にタイマー情報を設定し、その設定したタイマー情報を、低消費電力状態から復帰させる制御を行う待機状態電力制御部１２３に記録しておく。

以下、図８のフローチャートを説明する。まず、図７のステップＳ４０２において、アプリケーションが、ステップＳ４０１で指定した画像処理アルゴリズムでの第１の画像処理の実行を要求すると、この要求を受けた待機状態制御部１２２は、指定されたアルゴリズム識別子を用いて、当該アルゴリズム識別子で識別される画像処理アルゴリズムを用いる第１の画像処理を実行することを第１画像処理部１２１に対して指示する。この指示を受けた第１画像処理部１２１は、指定されたアルゴリズム識別子で識別される画像処理アルゴリズムを用いる第１の画像処理を実行する（ステップＳ５０１）。より具体的には、第１画像処理部１２１は、指定された画像処理アルゴリズムに設定されている解像度や初期化待ち時間をイメージセンサ制御部１２４に通知し、画像の取得を指示する。この例では、画像処理アルゴリズムに設定されている解像度は、第２の画像処理に必要な解像度よりも低い解像度に設定され、画像処理アルゴリズムに設定される初期化待ち時間は、鮮明な画像を得るのに必要な時間よりも短い時間に設定されている。第１画像処理部１２１からの指示を受けたイメージセンサ制御部１２４は、第１画像処理部１２１から通知された情報（解像度や初期化待ち時間）を、既に設定されていない場合はＣＭＯＳイメージセンサ７３のレジスタに設定するなど必要な初期化処理を行い、低解像度画像を取得する。この際に、鮮明な画像の取得が必要な場合には初期化後に十分な時間を待つ必要があるが、この例では、画像変化の検出が可能な画像を取得できればよいので、通知された時間（第２の画像処理で利用する高解像度画像を取得する時間より短い時間）だけ待つようにする。第１画像処理部１２１は、イメージセンサ制御部１２４が取得した低解像度画像を用いて、指定された画像処理アルゴリズムを用いる第１の画像処理を行う。

次に、第１の画像処理の結果、画像変化が検出された場合（ステップＳ５０２：Ｙｅｓ）、処理はステップＳ５０６へ進む。一方、画像変化が検出されなかった場合（ステップＳ５０２：Ｎｏ）、待機状態制御部１２２は、待機状態電力制御部１２３に対して、情報処理装置１を低消費電力状態に遷移させるように指示する（ステップＳ５０３）。この例では、第１の画像処理に用いる画像処理アルゴリズムは、画像変化を高速に検出できるように設計・実装されているので、情報処理装置１全体を低消費電力状態にできる期間が確保できる。待機状態制御部１２２からの指示を受けた待機状態電力制御部１２３は、例えば、ＣＭＯＳイメージセンサモジュール７０を第２省電力モードに設定し、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させるように電力管理部１４０に指示する。この際に、待機状態電力制御部１２３に記録されている、第１の画像処理を繰返し実行する際の時間間隔を示す情報を利用して、ＤＥＥＰ ＳＬＥＥＰモードから復帰する時刻をタイマーに設定しておき、タイマーで設定された時刻まで待つ（ステップＳ５０４）。このアイドル期間中は、情報処理装置１を非常に消費電力が低い状態にすることができ、第１の画像処理とアイドル期間を繰返す待機状態の平均消費電力を大幅に削減できる。そして、タイマイベントをトリガにＳｏＣ１０はＤＥＥＰ ＳＬＥＥＰモードから復帰し、その旨が待機状態電力制御部１２３に通知される（ステップＳ５０５）。低消費電力状態からの復帰後は、ステップＳ５０１以降の処理が繰り返される。

一方、ステップＳ５０６では、待機状態制御部１２２は、待機状態制御部１２２に記録されている第２の画像処理に必要な解像度の画像（高解像度画像）を取得するようにイメージセンサ制御部１２４に指示する。この指示を受けたイメージセンサ制御部１２４は、高解像度画像を取得するためにイメージセンサ７３のレジスタ等の再設定を行い、高解像度画像をイメージセンサ７３から取得し、その取得した高解像度画像を待機状態制御部１２２へ渡す(Ｉ２Ｃなどのインタフェース経由で再設定するため変化検出時には同インタフェースの信号線の電圧情報から観測できる)。待機状態制御部１２２は、アプリケーションに対して、画像変化を検出したことを通知し、イメージセンサ制御部１２４に取得させた高解像度画像を、それを必要としている第２画像処理部１３０へ渡す（ステップＳ５０６）。そして、待機状態制御部１２２は、アプリケーションがイメージセンサ管理部１２０に対して第１の画像処理の再開を呼び出す（実行を要求する）まで待ち（ステップＳ５０７）、呼び出されたらステップＳ５０１以降の処理を繰り返す。

以上のように、本実施形態では、アプリケーションと、ＯＳ内のイメージセンサ管理部１２０とが連携して、情報処理装置１の低消費電力化を実現する。要するに、本実施形態の情報処理装置１は、オペレーティングシステム（ＯＳ）が実行する処理部と、アプリケーションとを備える情報処理装置であって、処理部は、アプリケーションから画像入力要求を受けると、イメージセンサ７３から第１の画像を入力して、第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）を実行し、第１の処理の結果、第１の画像の変化を検出しなかった場合は、次の第１の画像の入力を待ち、第１の処理の結果、第１の画像の変化を検出した場合は、第１の画像よりも解像度の高い第２の画像をイメージセンサ７３から入力して、アプリケーションへ渡し、アプリケーションは、処理部から渡された第２の画像を用いた第２の処理（この例では「第２の画像処理」）を実行する形態であると考えることができる。

また、本実施形態の情報処理装置１は、イメージセンサ７３から入力する第１の画像の変化がない場合は、次の第１の画像の入力を待ち、変化があった場合は、第１の画像よりも解像度の高い第２の画像をイメージセンサ７３から入力し、その入力した第２の画像を出力（この例ではアプリケーションへ出力）する形態であると捉えることもできる。

さらに、本実施形態の情報処理装置１は、アプリケーションから、第１の画像よりも解像度の高い第２の画像の入力要求を受けてから、イメージセンサ７３から繰り返し第１の画像を入力し、第１の画像の変化があった場合にイメージセンサ７３から第２の画像を入力してアプリケーションへ渡すまでの間に、イメージセンサ７３の電力は、少なくとも、画像を入力しているときの第２電力と、第２電力よりも小さい第３電力とに変化する形態であると捉えることもできる。

以上に説明したように、本実施形態では、ＣＭＯＳイメージセンサ７３から取得する画像の変化がない期間においては、アプリケーションの高度な画像処理（第２の画像処理）を、第２の画像処理よりも処理量が少ない画像処理であって、画像変化を検出するための第１の画像処理（第２の画像処理の実行の可否を決定するための第１の画像処理）に置き換える。これにより、本来不必要な第２の画像処理を実行する時間を削減し、情報処理装置１を低消費電力状態にできる期間を最大限確保することができるので、一層の低消費電力化を実現できる。

なお、本実施形態では、イメージセンサ７３を制御するためにＳｏＣ１０を利用する例を示したが、例えばマイコンなどで同様の省電力制御をしてもよく、この限りではないのは言うまでもない。これは他の実施例についても同様である。

（第２実施形態）
本実施形態では、第１の画像処理に用いられる画像を取得する場合と、第２の画像処理に用いられる画像を取得する場合とで、イメージセンサ７３の初期化時間が異なる。ここで初期化とは、前述した通り、イメージセンサ７３を省電力モードから復帰させる際に毎回行うレジスタ等の再設定の処理を含んでいる。前述したように、待機状態の画像処理では、アプリケーションが必要とするような鮮明な画像を利用する必要がない。変化の有無を検出できる範囲であれば、不鮮明な画像を用いてもよい。待機状態の画像処理に用いられる画像として、不鮮明な画像を採用する場合、イメージセンサ７３の初期化処理の待ち時間（初期化時間）を短くして、例えば本来であればデバイスドライバ側やイメージセンサ７３側で待つなどすることで破棄して利用しない最初の何枚かのキャプチャ画像を利用することで、アイドル状態の期間をより長く確保することができる。一方、アプリケーションの画像処理には、鮮明な画像が必要な場合が一般的なので、イメージセンサ７３の初期化時間は、待機状態の画像処理に用いられる画像を取得する場合に比べて長くする必要がある。そのため、待機状態の画像処理で利用する画像を取得する場合と、アプリケーション側に渡す画像を取得する場合とで、イメージセンサ７３の初期化時間が異なる。例えば、Ｉ２Ｃなどのインタフェース経由で設定するため同インタフェースの信号線の電圧情報で同設定が観測されてから、ＣＳＩなどの画像が転送されるインタフェースで転送される連続した画像データの枚数が第１の画像処理に用いられる画像と第２の画像処理に用いられる画像を取得する場合とで異なることなどが同インタフェースの信号線の電圧情報から観測できる。

本実施形態では、イメージセンサ制御部１２４は、第１の画像処理に用いられる画像を取得する場合のイメージセンサ７３の初期化時間を、第２の画像処理に用いられる画像を取得する場合のイメージセンサ７３の初期化時間よりも短い値に設定する。

また、本実施形態では、アプリケーションが、イメージセンサ７３の初期化時間を指定するためのインタフェース部を備える。この例では、ＯＳは、アプリケーションが、イメージセンサ７３の初期化時間を指定するためのインタフェース部を備えている。例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、イメージセンサモジュール７０のデバイスドライバ内のイメージセンサ管理部１２０に対して、イメージセンサ７３を初期化する時間を指定することができる。また、上記ＡＰＩは、アプリケーションで独自の待機状態の画像処理アルゴリズムを開発する際にも利用可能である。ここでは、アプリケーションが、イメージセンサ７３の初期化時間を指定するための手段の一例を示したがこの限りではない。イメージセンサ制御部１２４は、アプリケーションからの指定に応じて、イメージセンサ７３の初期化時間を設定する。

（第３実施形態）
本実施形態では、アプリケーションが、第１の画像処理を実行する間隔を指定するためのインタフェース部を備える。待機状態制御部１２２（この例では「間隔設定制御部」に対応）は、アプリケーションからの指定に応じて、上記間隔を設定する。これにより、アプリケーションに適した時間間隔で待機状態の画像処理（第１の画像処理）を実行することができる。間隔の指定方法は任意であり、例えば１秒間に実行する回数を指定するなどの様々な方法で指定することができる。また、間隔の設定変更は任意のタイミングで指定することができる。これにより、アプリケーションの都合や周辺環境などの状態変化に応じて動的に間隔を変更することが可能になる。なお、周辺環境の状態変化を検出する方法は任意であり、本願明細書中に登場する他の様々なセンサを補助的に利用してもよい。これは他の実施例についても同様である。

例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、イメージセンサモジュール７０のデバイスドライバ内のイメージセンサ管理部１２０に対して、上記間隔を指定することができる。

（第４実施形態）
本実施形態では、待機状態制御部１２２は、第１の画像処理の結果が、第２の画像処理の実行条件を満たしている場合は、第１の画像処理に用いられた画像のうち、第２の画像処理の実行条件を満たす領域の画像を少なくとも含み、かつ、第１の画像処理に用いられた画像よりも解像度が高い高解像度画像を、イメージセンサ制御部１２４に取得させてアプリケーションへ通知する。この例では、待機状態制御部１２２は、「実行制御部」に対応している。

例えば図９の（Ａ）は、第１の画像処理の画像処理アルゴリズムが、バーコードが映っているか否かを検出する処理を示す場合を例示している。まず、アプリケーションが変化検出処理を要求する。この要求を受けて、第１画像処理部１２１は、ＣＭＯＳイメージセンサ７３から取得した（イメージセンサ制御部１２４に取得させた）低解像度画像を用いて、その低解像度画像にバーコードが映っているか否かを検出する処理（第１の画像処理）を行い、バーコードが映っていることを検知する。バーコードが映っていることを検知すると、画像の中でバーコードが存在する可能性が高い領域を求める。この例では、図の点線で示している検出領域に映っている可能性が高いと判断する。なお、複数のバーコードを検出した場合、検出領域は複数になってもよい。そして、待機状態制御部１２２は、全体の高解像度画像を取得し直し、画像変化を検知したことを、高解像度画像（この例では全体の高解像度画像）や検出領域を示す情報とともに第２画像処理部に通知する。つまり、この例では、待機状態制御部１２２は、イメージセンサ制御部１２４に取得させた高解像度画像（この例では全体の高解像度画像）と、当該高解像度画像のうち第２の画像処理の実行条件を満たしている領域を示す情報とをアプリケーションに通知していると考えることができる。アプリケーションは、高解像度画像と一緒に検出領域を示す情報（対象物体や変化などの位置情報）も受け取る。この例では、待機状態制御部１２２は、高解像度画像と、高解像度画像のうち第２の画像処理の実行条件を満たしている領域を示す情報とをアプリケーションに通知している。

また、例えば図９の（Ｂ）は、第１の画像処理の画像処理アルゴリズムが、人が映っているか否かを検出する処理を示す場合を例示している。まず、アプリケーションが変化検出処理を要求する。この要求を受けて、第１画像処理部１２１は、ＣＭＯＳイメージセンサ７３から取得した（イメージセンサ制御部１２４に取得させた）低解像度画像を用いて、その低解像度画像に人が映っているか否かを検出する処理（第１の画像処理）を行い、人が映っていることを検知する。人が映っていることを検知すると、さらに顔が映っている場所（検出領域）を検出し、検出領域だけを詳細に、第１の画像処理に用いられた画像よりも高解像度の画像で取得し直す。その際には、ズームの倍率の変更やレンズの向きや角度の変更など、検出領域だけを詳細に高解像度で取得し直すのに必要な再設定処理をしてもよい。そして、待機状態制御部１２２は、画像変化を検出したことを、検出領域の高解像度画像とともに第２画像処理部１３０に通知する。アプリケーションは、検出領域の高解像度画像を受け取り、その受け取った検出領域の高解像度画像を用いて、独自の高度な画像処理を行う。なお、例えば複数の人が検出された場合は、検出領域の高解像度画像は、それぞれの人を映した複数の画像であってもよい。

このために、本実施形態では、ＯＳは、アプリケーションが、上記高解像度画像（全体の高解像度画像、検出領域の高解像度画像を含む）や、検出領域の高解像度画像などの取得した画像の数、などを取得するためのインタフェース部を備える。例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、高解像度画像（全体の高解像度画像）とその中の変化検出領域の座標などの位置情報や、変化検出領域の高解像度画像を得ることができる。なお、通知を待つＡＰＩと結果の画像等を受け取るＡＰＩは別であってもよいし、単一のＡＰＩであってもよいのは言うまでもない。

（第５実施形態）
待機状態の画像処理で画像変化の有無を検出する場合、イメージセンサ７３から取得可能な全体画像の必ずしもすべての領域で変化が起こるわけではない。そこで、本実施形態では、イメージセンサ制御部１２４は、第１の画像処理に用いられる画像として、イメージセンサ７３から取得可能な全体画像のうちの一部の領域の画像を取得する。より具体的には、待機状態の画像処理の入力画像として、イメージセンサ制御部１２４は、全データを取り出さずにイメージセンサ７３が有する部分読み出しや画像間引きの機能を利用して、より解像度が低い（解像度の合計が小さい）画像を取得する。これにより、イメージセンサモジュール７０からＳｏＣ１０に転送されるデータも削減され、転送時間が短くなる。そのため第１の画像処理の開始を早めることができる。また、解像度がさらに低くなるので、第１画像処理の実行時間も短くなり、変化検出処理を軽量化でき、アイドル期間をさらに長く確保することができる。また、解像度を低くできれば、後述の実施形態で説明するように、一般的に容量の少ない内部メモリ１０２などを利用できる可能性が高まるのでさらに低消費電力化できるし、後述の実施形態で説明するように待機状態の画像処理をマイコンにオフロードする際にはマイコンの負荷を減らすことができるので、よりローパワーなマイコンを採用できシステム全体を低消費電力化できるし、後述の実施形態で説明するように待機状態の画像処理をイメージセンサ７３内部で実行する際にバッファが小さくて済むので、実現することが容易になる。

図１０は、変化検出処理の対象となる領域（以下の説明では、「変化検出対象領域」と称する）の例を示す。図１０では、イメージセンサ７３から取得可能な全体画像（イメージセンサ７３による撮像で得られる全体画像）のうち、太線で囲まれた領域が、変化検出対象領域を示している。図１０の（Ａ）では、変化検出対象領域は一つである。例えば、ドアから室内に入ってくる人を顔認識処理する監視カメラ応用などにおいては、変化検出時はドアノブ付近だけを見ておけばよいので、予め定められた位置に固定されたイメージセンサ７３による撮像で得られる全体画像のうち、ドアノブ付近に対応する領域を、変化検出対象領域とすることが好適である。そして、変化検出後は、イメージセンサ７３から画像全体を取得して顔認識処理をすればよい。

また、図１０の（Ｂ）のように、イメージセンサ７３による撮像で得られる全体画像のうち、対象物体が映り込む可能性が高い領域が、左右の両端（ここでは、左端の領域を第１対象領域、右端の領域を第２対象領域と称する）である場合は、イメージセンサ７３による撮像で得られる全体画像のうち、第１対象領域および第２対象領域の２つの領域を変化検出対象領域とし、第１対象領域および第２対象領域の画像を、イメージセンサ７３から部分的に読み出し、その低解像度画像を用いて画像変化を検出すればよい。また、図１０の（Ｃ）のように、対象物体がどこから映り込むかは分からないが対象物体の大きさがある程度既知な場合などは、対象物体の幅よりも狭い間隔で間引いた領域のみを、変化検出対象領域としてイメージセンサ７３から読み出せば、対象物体が検出されないことを防止しつつ（対象物体が検出されることを担保した上で）、変化検出処理を軽量化できる。なお、以上の例は、あくまで一例である。

変化検出対象領域は、アプリケーション側から設定することができる。本実施形態では、ＯＳは、アプリケーションが、変化検出対象領域を指定するためのインタフェース部を備える。例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、イメージセンサモジュール７０のデバイスドライバ内のイメージセンサ管理部１２０に対して、変化検出対象領域を指定することができる。

変化検出対象領域の設定は、イメージセンサ管理部１２０のイメージセンサ制御部１２４が、ＣＭＯＳイメージセンサ７３のレジスタに、水平方向の先頭位置と末尾位置と垂直方向の先頭位置と末尾位置などを示す情報を書き込む形式で行う。なお、変化検出対象領域は任意のタイミングで指定できるため、アプリケーションの都合や変化の状況などに応じて動的に変更することもできる。

図１１は、変化検出対象領域を指定する場合の一例を示す図である。アプリケーションは、上記ＡＰＩを利用して、変化検出対象領域を指定する。ここでは、図１０の（Ｂ）の例を想定しており、イメージセンサ７３から取得可能な全体画像の左右の２つの領域である第１対象領域と第２対象領域が指定されている。指定された変化検出対象領域は、第１画像処理部１２１に記録される。第１画像処理部１２１は、第１画像処理の実行が指示されると、記録された変化検出対象領域の取得の指示をイメージセンサ制御部１２４に指示し、イメージセンサ制御部１２４による取得処理が実行される。なお、第１画像処理の画像処理アルゴリズムごとに変化検出対象領域を設定することも可能である。

（第６実施形態）
本実施形態では、第１の画像処理を実行する間隔（以下の説明では、「実行間隔」と称する場合がある）が動的に変化する。より具体的には、待機状態制御部１２２は、第１の画像処理の結果に応じて、上記実行間隔を可変に設定する。例えば、人などの対象物体が映っていない、あるいは、動き（変化）のない場合には、第１の画像処理に用いられる画像の取り込み間隔（アイドル状態にできる期間）をさらに長くして、情報処理装置１全体を低消費電力状態にできる期間をさらに長くして省電力化することができる。この例では、待機状態制御部１２２は、画像変化が検出されなかった場合は、上記実行間隔を、画像変化が検出された場合に比べて長い値に設定することができる。この例では、待機状態制御部１２２は、「間隔設定制御部」に対応する。

実行間隔が動的に変化すると、情報処理装置１全体やＣＭＯＳイメージセンサモジュール７０の消費電力も図１２のように変化が観測できる。つまり、第１の画像処理を実行可能な第１状態、および、第１状態よりも消費電力が低い第２状態を含む待機状態の消費電力が異なり、これらの間隔が実行間隔に対応しており、この実行間隔が動的に変化することが観測できる。ここでは、待機状態は、アプリケーションによる第２の画像処理の実行待ちの状態であり、情報処理装置１が第２の画像処理を実行する状態とは区別される。

図１２の例では、人などの対象物体が映っていない、あるいは、変化がないとき、あるいは組み合わせて利用する他のセンサなどの情報で変化がすぐには起きないことが分かるときなどは、画像の取り込み間隔を長く設定する。逆に、第１画像処理部１２１による第１の画像処理（待機状態の画像処理）で、例えばイメージセンサ７３から取得した画像（この例では全体画像）のうち、左端の領域に人が映っていることを検出すると、実行間隔を短い値に設定して待機状態の画像処理を繰返す。この例では、第２の画像処理の実行条件は、イメージセンサ７３による撮像で得られる全体画像のうち中央付近の領域に人が映っていることであるとする。人が映っている領域（変化領域）が画像の中央付近であれば、第２の画像処理の実行条件が成立するので、顔認識処理や人が中央に映っている状態の画像を記録しておくなどの第２の画像処理を実行する第２画像処理部１３０が要求する高解像度画像を取得し直し、第２画像処理部１３０に対して、全体画像の中央付近で人を検出したこと（第２の画像処理の実行条件が成立したこと）を通知し、取得し直した高解像度画像を渡す。このように、第１画像処理の画像処理アルゴリズムは、条件ごとに複数の実行間隔を持っていてもよい。例えば第１画像処理部１２１が待機状態の画像処理終了後に待機状態制御部１２２に結果を返す際に、同時に、その結果に応じた実行間隔を渡すように実装されていてもよい。対象物体が特定の領域（例えば中央付近の領域）に映った画像を取得し、情報処理装置１にローカルに録画する、あるいは、ネットワークデバイス６０を介して外部装置へ転送するような応用では、本実施形態の構成を適用することで、消費電力を下げつつＩｏＴ／Ｍ２Ｍシステムやメガネ型のウェアラブル機器で自動的に保存容量や通信量を間引いて省電力化することもできるし余計なデータを減らして効率化する効果も得られる。

要するに、本実施形態の情報処理装置１は、第１の画像の変化がない場合は次の第１の画像の入力を第５時間待ち、第１の画像の変化があった場合は次の第１の画像の入力を第６時間待ち、第６時間は第５時間よりも短い形態とすることができる。

（第７実施形態）
本実施形態では、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに積極的に遷移する際に、ＣＭＯＳイメージセンサモジュール７０の持つ複数の省電力モードをさらに動的に使い分けることでさらなる最適化を実現する。例えば、上述の第６実施形態でも述べた実行間隔に応じて、イメージセンサモジュール７０の持つ複数の省電力モードを使い分けることができる。例えば、切換時間（ここでは、イメージセンサ７３が画像の取得を行うことができない（撮像を行うことができない）第３状態（省エネ状態）と、イメージセンサ７３が画像の取得を行うことが可能な第４状態（通常状態）とを切り換えるのに要する時間）が短い第１省電力モードと、停止させたオシレータ７１を安定させる、あるいは、レジスタの初期化などで遷移／復帰時間が長く（切換時間が長く）切り換えに必要な消費電力は高いが待機電力はさらに低い第２省電力モードなどを有するような場合を考える。実行間隔が長い場合は待機電力が低い方が相対的に重要なので第２省電力モードを利用し、実行間隔が短い場合は切り換え時の消費電力が相対的に重要になるので第１省電力モードを利用する。この際の消費電力の推移は図１３のように観測される。

つまり、実行間隔に応じて、第１の画像処理に要する時間が変化すると考えることができる。この例では、待機状態制御部１２２は、実行間隔に応じて、イメージセンサ７３の切換時間を可変に設定する。より具体的には、待機状態制御部１２２は、実行間隔が閾値以上の場合は、アイドル期間（前述の第２状態）におけるイメージセンサ７３の状態を第２省電力モードに設定する制御を行い、実行間隔が閾値を下回る場合は、アイドル期間におけるイメージセンサ７３の状態を、第２省電力モードよりも切換時間の短い第１省電力モードに設定する制御を行うことができる。つまり、待機状態制御部１２２は、実行間隔が閾値以上の場合は、イメージセンサ７３の切換時間を、実行間隔が閾値を下回る場合に比べて長い値に設定する。この例では、待機状態制御部１２２は、「切換時間設定部」に対応している。

（第８実施形態）
上述の第１実施形態で説明したように、ＤＥＥＰ ＳＬＥＥＰモードでは、キャッシュメモリ１１４への電力供給が停止される。そのため、ＤＥＥＰ ＳＬＥＥＰモードに遷移する際にはキャッシュライン上のダーティなデータをメインメモリ５０に書き出すクリーン処理、ＤＥＥＰ ＳＬＥＥＰモードから復帰する際はインバリデート処理などのキャッシュに対する処理が必要となり、このキャッシュに対する処理を行うための時間と電力が必要となる。そこで、ＤＥＥＰ ＳＬＥＥＰモードの際に、キャッシュメモリ１１４への電力供給を停止せずにキャッシュ処理を省略する、待機電力は比較的高いが遷移時間が高速なＤＥＥＰ ＳＬＥＥＰモードを第２ＤＥＥＰ ＳＬＥＥＰモードとして利用してもよい。これに対して、キャッシュメモリ１１４への電力供給を停止する、遷移時間は比較的遅いが待機電力はより低いＤＥＥＰ ＳＬＥＥＰモードを第１ＤＥＥＰ ＳＬＥＥＰモードとする。

本実施形態では、図１４に示すように、イメージセンサ管理部１２０は、キャッシュ電源制御判定部１２５をさらに有する。キャッシュ電源制御部１２５は、情報処理装置１全体が低消費電力状態（前述の第２状態）に遷移する際に、第１の画像処理に使用されるキャッシュメモリ１１４に対する電力の供給を継続するか否かを判定する。この例では、キャッシュ電源制御判定部１２０は、ＤＥＥＰ ＳＬＥＥＰモードに遷移する際に、第１ＤＥＥＰ ＳＬＥＥＰモードと第２ＤＥＥＰ ＳＬＥＥＰモードを動的に切り替える。

図１５は、図８のステップＳ５０３において追加で実行される、キャッシュ電源制御判定部１２５による処理の一例を示すフローチャートである。この処理は、待機状態電力制御部１２３が、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させるようとする際に開始される。まず、待機状態電力制御部１２３が、キャッシュメモリ１１４に対する電力の供給を継続するか否かの問い合わせを受信する(ステップＳ９０１)。次に、キャッシュ電源制御判定部１２５は、キャッシュメモリ１１４に対する電力供給を継続するか否かを判定する。つまり、キャッシュ電源制御判定部１２５は、第１ＤＥＥＰ ＳＬＥＥＰモードに切り替えるか第２ＤＥＥＰ ＳＬＥＥＰモードに切り替えるかを判定する（ステップＳ９０２）。次に、キャッシュ電源制御判定部１２５は、ステップＳ９０２の判定結果を待機状態電力制御部１２３に返す（ステップＳ９０３）。

待機状態電力制御部１２３は、キャッシュ電源制御判定部１２５からの判定結果を受け取ると、この情報を付加して、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させるように電力管理部１４０に指示する。これにより、ＳｏＣ１０が適切なＤＥＥＰ ＳＬＥＥＰモードに遷移できる。この処理は、ＤＥＥＰ ＳＬＥＥＰモードに遷移するたびに行ってもよいし、情報処理装置１の状態や周辺環境が変化する時だけなどと、様々なタイミングで実行することができる。

上記ステップＳ９０２の判定条件は、アプリケーションや利用シーンなどによって様々である。例えば、待機状態の画像処理を行っている時間間隔（前述の実行間隔）とキャッシュ電源制御判定部１２５に事前に記録されている閾値を比較して判定してもよい。実行間隔が長い場合は、アイドル時の低消費電力状態の消費電力が相対的に重要になる。実行間隔が短い場合は、低消費電力状態（第２状態）から、第１の画像処理を実行可能な状態（第１状態）への遷移回数が増えるので、遷移に必要な消費電力が相対的に重要になる。そのため、キャッシュ電源制御判定部１２５は、実行間隔が閾値よりも長い場合は、キャッシュメモリ１１４に対する電力の供給を停止すると判定し、実行間隔が閾値以下の場合は、キャッシュメモリ１１４に対する電力の供給を継続すると判定する。

一般に、実行すべき処理は非同期的に（不定期に）に起こるため、アイドル状態がどの程度の期間続くのかを正確に予測するのは難しい。しかし、本実施形態においては、変化検出処理を定期的に行う前提があり、システムが次にいつアイドル状態から復帰するのかを当然分かっている（設定されている、待機状態の画像処理の時間間隔を見るだけでよい）ので、適切な消費電力モードに設定することができる。これはキャッシュだけでなく、イメージセンサ７３の省電力モードやＳｏＣ１０の省電力モードについても同じである。これは他の実施例についても同様である。

上記閾値は、例えば、低消費電力状態から、第１の画像処理を実行可能な状態への遷移に必要な電力量の合計と、低消費電力状態時に移行することで削減できる電力量が等しくなる時間のことである。そのため、情報処理装置１を利用する前に、低消費電力状態から、第１の画像処理を実行可能な状態への遷移時の電力量と低消費電力状態に遷移することで削減できる電力量を測定し、その測定結果を用いて閾値を求めておき、その求めた閾値をキャッシュ電源制御判定部１２５に記録しておけばよい。

本実施形態の情報処理装置１の利用時に観測される情報処理装置１全体の消費電力の推移は、図１６のようになる。つまり、実行間隔に応じて、第１の画像処理を実行可能な第１状態、および、第１状態よりも消費電力が低い第２状態を含む待機状態の消費電力が異なり、これらの間隔が実行間隔に対応しており、この間隔が長い時は短い時と比較して待機状態時の情報処理装置の消費電力（あるいは、キャッシュに供給される電力）が低いことが観測できる。

要するに、本実施形態の情報処理装置１は、上述の第６実施形態と同様、第１の画像の変化がない場合は次の第１の画像の入力を第５時間待ち、第１の画像の変化があった場合は次の第１の画像の入力を第６時間待ち、第６時間は第５時間よりも短い形態とすることができる。そして、次の第１の画像の入力を第５時間待つ場合の情報処理装置１の電力は第４電力であり、次の第１の画像の入力を第６時間待つ場合の情報処理装置１の電力は第５電力であり、第４電力は第５電力よりも低い形態とすることができる。

キャッシュ電源制御判定部１２５による別の判定方法として、繰り返し実行する第１の画像処理に用いる画像処理アルゴリズムの特性（キャッシュメモリ１１４の利用特性）で判定してもよい。第１の画像処理で背景画像との差分を取るようなアルゴリズムの場合は、背景画像を繰り返し利用するので、キャッシュメモリ１１４をオンのままにしておいた方がよい（キャッシュメモリ１１４に対する電力供給を継続する方がよい）。そこで、アプリケーションが、例えば、画像処理アルゴリズムごとに設定できる手段（ＡＰＩ）を持っていてもよい。

さらに別の判定方法として、第１の画像処理に用いる画像処理アルゴリズムで使用するデータサイズとキャッシュメモリ１１４の容量とを比較するなどのヒューリスティックスを用いてイメージセンサ管理部１２０側で判定してもよいし、使用するすべてのデータのサイズが分からない場合は第１の画像処理で利用する画像の解像度と事前に決定しておく閾値を比較するヒューリスティックスなどを用いて判定してもよい。そのため、アプリケーションが、例えば、第１の画像処理で利用するデータサイズや繰返し同じデータを使用する可能性が高いかなどのアルゴリズムの特性（キャッシュメモリ１１４の利用特性）を示す情報を、イメージセンサ管理部１２０に通知する手段（ＡＰＩ）を持っていてもよい。

要するに、本実施形態の情報処理装置１は、第１の画像の変化がない場合は、第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）の特性に応じて、メインメモリ５０に記憶されるデータの一部を記憶するキャッシュメモリ１１４への電力供給が停止される期間と継続される期間とが変化する形態とすることができる。

さらに別の判定方法として、情報処理装置１がキャッシュメモリ１１４を保持することが有意義な状態にあるかを判定してもよい。例えば、第１画像処理に用いる画像処理アルゴリズムが、前述の背景画像を繰り返し利用するような画像処理アルゴリズムの場合でも、この画像処理アルゴリズムを用いる第１の画像処理が、メガネ型のウェアラブル機器（以下、単に「グラス」と称する場合がある）である情報処理装置１で実行される場合、グラスを掛けている（装着している）人が見る方向を変えるために頭の向きを変えている最中は背景画像そのものが変化し続けることにより、キャッシュメモリ１１４が有効ではない処理となる。このようにグラスを掛けた人の頭が動いている場合は、画像処理アルゴリズムが仮に静的にオンにするように決まっていてもこれに従うのではなく、グラスを掛けた人の頭が動いていることを、第１の画像処理で著しい変化や画像全体がほぼ均一に変化していることを検出することや、９軸センサなどの情報処理装置１に搭載されている他のセンサで検出することで検出し、動的にキャッシュメモリ１１４をオフにする（キャッシュメモリ１１４に対する電力供給を停止する）ように切り替えてもよい。つまり、上記のケースと同様に、人の頭の動いている最中もしくは直後の待機状態時には頭が静止している時の待機状態時よりもキャッシュメモリ１１４に供給される電力あるいは情報処理装置１の消費電力が低いことが観測できる。

要するに、本実施形態の情報処理装置１は、第１の画像の変化を判定する第１の処理に繰り返し利用される背景画像の変化がある場合は、主記憶装置（メインメモリ５０）に記憶されるデータの一部を記憶するキャッシュメモリ１１４への電力供給が停止される形態であってもよい。

また、判定条件は、以上の態様の組み合わせであってもよい。ここでは、判定条件の一例を述べたが、この限りではないのは言うまでもない。

（第９実施形態）
本実施形態では、上記のように、ユーザがメガネ型のウェアラブル機器（グラス）などを装着している場合、グラスを掛けた人の頭が動いている場合などイメージセンサ７３自体が移動していること（例えば、一定以上の速度・加速度で動作している、向きや傾きが変化している、振動があるなど）を他のセンサなどイメージセンサ７３以外の別の手段で検出している時は、変化検出処理を行わず、グラスを掛けた人の頭が静止するなどイメージセンサ自体が停止したことが確認できたら変化検出処理を再開してもよい。これはイメージセンサ７３自体の動きによっては、変化検出処理によっては意味のない画像が入力され続けることがあるので、この期間はイメージセンサ７３等を停止させることで低消費電力化する。要するに、イメージセンサ７３の動きの変化に応じて、次の第１の画像の入力を待つ時間が変化する形態とすることもできる。あるいは、カプセル型の内視鏡のように移動していない（進んでいない）ことを検出した場合は同じ画像しか得られないことになるので変化検出処理を停止し、移動していることが確認できたら再開してもよい。

（第１０実施形態）
本実施形態では、図８に示した全ての処理を、一般的にはサイズが小さいがＤＥＥＰ ＳＬＥＥＰモードからの復帰後にすぐにアクセスでき、オンチップメモリゆえアクセスレイテンシも低いＳｏＣ１０内の内部メモリ１０２を利用して実行することで、第１の画像処理を高速化でき、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰにして情報処理装置１を低消費電力状態にできる期間を最大化できる。これにより、情報処理装置１の消費電力を大幅に削減することができる。ＤＥＥＰ ＳＬＥＥＰモードへの遷移も内部メモリ１０２を利用して行い、第１の画像処理も内部メモリ１０２を利用して実行する。また、全てのデータやコードを内部メモリ１０２に格納することができれば、第１の画像処理の実行中もメインメモリ５０が不揮発性の場合はメインメモリ５０に対する電力供給を停止することができ、メインメモリ５０が揮発性メモリの場合（例えばＬＰＤＤＲ２などのＤＲＡＭの場合）はメインメモリ５０をセリフリフレッシュモードに遷移させることで消費電力をさらに抑制することができる。

要するに、本実施形態の情報処理装置１では、イメージセンサ７３から入力する第１の画像は、画像を処理する処理装置（この例では「ＳｏＣ１０」）内に設けられる内部メモリ１０２に格納され、内部メモリ１０２に格納された第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）の実行中は、処理装置外に設けられるメインメモリ５０に供給される電力は第６電力であり、第１の画像の変化が検出された場合は、メインメモリ５０に供給される電力は、メインメモリ５０にアクセス可能な第７電力であり、第６電力は第７電力よりも小さい形態であればよい。

内部メモリ１０２は、ＤＥＥＰ ＳＬＥＥＰモード中も通電されているので、全部でなくても一部のデータやコードだけでも内部メモリ１０２に格納しておくことでオフチップのメインメモリ５０へのアクセス（メインメモリ５０からのデータの読み出し／メインメモリ５０に対するデータの書き込み）を抑制でき、特にアクセスペナルティが比較的高い不揮発性メモリの場合は効果が大きい。第１の画像処理で繰り返し読み書きする画像などのデータを内部メモリ１０２に格納しておくことが好ましい。繰り返し利用するデータとは、例えば、画像の差分を計算する際に利用する背景画像や、動き検出の際の対象物体の画像や、後述の実施形態で説明する統計情報などである。これらのデータを内部メモリ１０２に保存し、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードに遷移させる。ＤＥＥＰ ＳＬＥＥＰモードから復帰後は、ＣＭＯＳイメージセンサ７３から取得した画像を内部メモリ１０２に保存する。内部メモリ１０２上に保存されている例えば背景画像と、ＣＭＯＳイメージセンサ７３から内部メモリ１０２に読み出した現在の画像とを用いて、画像変化を検出するための第１の画像処理を実行することができる。メインメモリ５０へのアクセスを抑制するために、第１の画像処理のコードも内部メモリ１０２上に保存され、そこから実行される。つまり、第１の画像処理のコードや、第１の画像処理に必要な画像やデータをできるだけ比較的小さな内部メモリ１０２上に配置できるように、第１の画像処理で利用する画像の解像度を低くするなどの調整が重要である。

通常、アプリケーションが利用できるメモリはメインメモリ５０であり、サイズが小さい内部メモリ１０２はカーネルでシステム全体の処理のために管理・利用されるため、アプリケーションからは利用できない。本実施形態では、アプリケーションによる高度な画像処理の実行の可否を決定するための軽量な画像処理（第１の画像処理）を、アプリケーションから分離してカーネル内に組み込むことで、内部メモリ１０２を利用する省電力制御と連動させることができ、アプリケーションもその恩恵を受けることができるようになる。

つまり、本実施形態では、第１の画像処理を実行する場合のメインメモリ５０（請求項の「主記憶装置」に対応）へのアクセス頻度は、第２の画像処理を実行する場合に比べて少ない。なお、第１の画像処理に必要なデータやコードの全てが内部メモリ１０２に格納できる場合は、第１の画像処理を実行する場合は、メインメモリ５０へのアクセスが発生しないことになる。要するに、本実施形態では、第１の画像処理に利用されるデータの少なくとも一部を保存する内部メモリ１０２を備え、第１画像処理部１２１は、内部メモリ１０２に保存されたデータを用いて第１の画像処理を実行する。観測できる消費電力の観点では、第１の画像処理中にメインメモリアクセスを示す消費電力を観測しないことがあることが観測できる。なお、第１の画像処理が消費電力から観測できることはこれまで説明してきた通りである。

（第１１実施形態）
本実施形態では、イメージセンサ制御部１２４が取得する、第１の画像処理に用いられる画像が、時間の経過とともに変化する。本実施形態では、図１７に示すように、イメージセンサ管理部１２０は、統計情報管理部１２６をさらに有する。この例では、統計情報管理部１２６は、学習期間内に繰り返し実行された第１の画像処理の結果に基づいて、イメージセンサ７３から取得可能な全体画像を構成する複数のサブ領域ごとに、変化が検出された回数を対応付けた統計情報を生成する。そして、第１画像処理部１２１は、全体画像のうち、変化が検出された回数が閾値以上のサブ領域の画像をイメージセンサ制御部１２４に取得させ、その取得させた画像を用いて第１の画像処理を実行する。

つまり、本実施形態では、情報処理装置１に、各種の統計情報を利用した学習機能を追加することで、前述の第５実施形態で述べた変化検出対象領域の設定を自動化するとともに、各種の統計情報を利用して変化を検出すべき領域を学習し、第１の画像処理をさらに軽量化し、低消費電力化する。

統計情報としては、様々なものが考えられるが、例えば、固定型カメラにおける画面を構成する複数のサブ領域毎の特徴量を示す情報であってもよく、これを待機状態の画像処理（第１の画像処理）を繰り返しながら蓄積していく。例えば、第１の画像処理で最初の画像変化が検出された時の変化検出領域を記録していく（図１８）。図１８の（Ａ）では、アプリケーションが行った初期設定では、変化検出対象領域として２つの領域（ここでは２つの領域を「第１変化検出対象領域」と呼ぶ）が指定されているが、アプリケーションなどが設定する学習時間の間、一定時間にわたって画像の変化がない状態から対象物体が映り込んだことにより画像の変化が起きた回数をサブ領域毎に記録していく。図１８の（Ｃ）に示すような、８つのサブ領域ごとに変化が検出された回数を対応付けた統計情報を参照すると、学習時間が終了した時点で、太線で示すサブ領域２００のみが、アプリケーションの高度な画像処理（第２の画像処理）を実行する状態への遷移の契機となる変化が起こっていることが分かる。よって、図１８の（Ｂ）に示すように、サブ領域２００を、新たな変化検出対象領域である第２変化検出対象領域として自動的に再設定することができる。これにより、イメージセンサ７３からの画像の転送時間を削減できたり、第１の画像処理に用いる画像処理アルゴリズムで利用する画像の解像度を小さくしたりすることが可能になったり、解像度が小さくなったことで、第１の画像処理に用いられる画像の全部を内部メモリ１０２に保存できるようになったりするため、フレームワークにより利用可能になる様々な省電力機能と連携性が高まり、さらなる低消費電力化が可能になる。さらに、各種の統計情報を、第１の画像処理に必要なデータとして、前述の第１０実施形態で述べた内部メモリ１０２に蓄積することにより、統計処理に関するメインメモリ５０へのメモリアクセスをなくすあるいは低減させることなどで、より低消費電力化を図ることができる。

以上の統計情報を活用した学習機能を利用することで、図１８に示すように、学習期間（一定期間）が経過すると、変化検出対象領域が、第１変化検出対象領域から第２変化検出対象領域に変化する。変化検出対象領域の変化に伴い、観測できる消費電力も変化するので、様々な周辺環境で利用すると待機状態の画像処理の消費電力が異なることが観測できる。

上記学習時間は、アプリケーションが指定することができる。本実施形態では、ＯＳは、アプリケーションが、学習期間を指定するためのインタフェース部を備える。例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、イメージセンサモジュールのデバイスドライバ内のイメージセンサ管理部に対して、変化検出対象領域の学習のための時間（学習期間）を指定することができる。

また、本実施形態の統計情報は、第１画像処理部だけが利用するものではなく、第２画像処理部１３０（アプリケーション）側で利用されてもよい。よって、任意のタイミングで（当然変化が検出されたタイミングであってもよい）、その時点までに蓄積されている統計情報をＯＳから取得するための手段を提供する。

本実施形態では、ＯＳは、アプリケーションが、上記統計情報を取得するためのインタフェース部を備える。例えば、アプリケーションは、Ｌｉｎｕｘのｉｏｃｔｌ（Ｉ／Ｏ Ｃｏｎｔｒｏｌ）などのシステムコールなどアプリケーションプログラムインタフェース（ＡＰＩ）を呼び出して、イメージセンサモジュールのデバイスドライバ内のイメージセンサ管理部１２０から、統計情報を取得することができる。

なお、上述の第１実施形態では、第１の画像処理（待機状態の画像処理）において、画像変化を検出すると、これをトリガとしてアプリケーションが必要とする高解像度画像をアプリケーションに渡し、その後は、アプリケーションが、渡された高解像度画像を用いて、アプリケーション独自の画像処理（第２の画像処理）を実行していたが、これに限られるものではない。例えばアプリケーションは、高解像度画像は取得せず、本実施形態の統計情報のみを小さい電力で効率よく集めるための画像処理を行う形態であってもよい。そのため、高解像度画像を取得しないことを設定するためのＡＰＩが設けられてもよい。

（第１２実施形態）
第１の画像処理（待機状態の画像処理）は、ＳＩＭＤエンジン１１５やＧＰＵなどのＳｏＣ１０に内蔵された、電力効率の優れたアクセラレータ１０３を使い分けることでさらに低消費電力化できる。

図１９に、高速化・省電力化を目的として、ＳＩＭＤエンジン１１５とＧＰＵを使い分ける場合の動作例を示している。第１の画像処理（待機状態の画像処理）は、ＧＰＵよりは小さいサイズのデータに対しても効果を発揮するＮＥＯＮを利用してＳｏＣ１０の内部メモリ１０２のみを利用して実行することで、ＤＥＥＰ ＳＬＥＥＰから復帰後、直ちに第１の画像処理を開始することができる。また、メインメモリ５０が不揮発性メモリで構成される場合は、第１の画像処理中も、メインメモリ５０に対する電力供給を停止したままにすることができる。従来のように、アプリケーション側で、高解像度の画像を利用してメインメモリ５０上にデータを配置する必要があるＧＰＵを用いて高度な画像処理（第２の画像処理）を実行し続けると、メインメモリ５０へのアクセスも継続的に行われることになってしまうが、変化検出処理（第１の画像処理）をカーネル側に分離した本発明のフレームワークにより、内部メモリ１０２上にデータ（第１の画像処理に必要なデータ）を置いたままＮＥＯＮを利用することができるので(通常アプリケーションからＮＥＯＮを利用する際はメインメモリ５０上のデータしか利用することができない)、ＧＰＵとメインメモリ５０の両方を省電力化することが可能になり、消費電力をさらに削減することができる。

要するに、第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）で第１のアクセラレータ（この例では「ＮＥＯＮ」）を利用し、第２の画像を用いた第２の処理（この例では「第２の画像処理」）で第２のアクセラレータ（この例では「ＧＰＵ」）を利用する形態とすることもできる。

（第１３実施形態）
本実施形態では、ＳｏＣ１０が、内部に複数のプロセッサコア１０１を持つマルチコアの構成の場合に、これを効率よく利用することでさらに低消費電力化できる。

具体的には、第１の画像処理では、処理量が少なく複数コアの並列性を十分に活用できない場合があることに加えて、頻繁にＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードなどへ遷移させる、あるいはＤＥＥＰ ＳＬＥＥＰモードから復帰させる必要があるため、単一のコアあるいは少ない数のコアを利用することで前述したキャッシュメモリ１１４に対する処理など遷移処理を簡素化できる。一方で、第２の画像処理は処理量も十分で並列性を十分に活用できることが多く、遷移処理時間は相対的に小さい。そのため、第１の画像処理を単一あるいは少ない数のコアを利用して実行し、第２の画像処理を第１の画像処理で利用する数より多い複数のコアを利用して実行することで、高効率化できる。また、コア数が多いほど遷移処理に時間が掛かるような場合、遷移時間（ＤＥＥＰ ＳＬＥＥＰモードへの遷移時間と同モードからの復帰時間）とコア数を増やした時の並列処理効果（高速化効果）にはトレードオフが存在する。そこで、遷移時と、第１の画像処理あるいは第２の画像処理の並列計算時の消費電力量のそれぞれの合計が小さくなるようなコア数を選択し、それぞれの画像処理を実行する。適切なコア数は第１の画像処理のアルゴリズムをダウンロードする際に決まっていてもよいし、ダウンロードする際にコア数や画像の解像度などを変化させるプログラムを動かして実験的に決定し、プラットフォームごとに適切なコア数を設定してもよい。なお、遷移時間を考慮して適切なコア数を選択する手法は任意の処理に適用できる。

（第１４実施形態）
本実施形態では、図２０に示すように、イメージセンサ管理部１２０は、プリロード部１２７をさらに有する。プリロード部１２７は、第１の画像処理の開始前に、第１の画像処理に利用されるデータを事前に読み出す（以下、「プリロード」と称する）。

本実施形態では、ＣＭＯＳイメージセンサ７３から、第１の画像処理に用いられる画像（例えば低解像度画像）を転送する間に、第１の画像処理に必要なデータをキャッシュメモリ１１４へプリロードしておくことで、図２１に示すように、データ転送（ＣＭＯＳイメージセンサ７３からの、第１の画像処理に用いられる画像の転送）が完了した後に、第１の画像処理に必要なデータを取得する従来手法に比べて、第１の画像処理を高速に実行できるので、アイドル期間をさらに長くすることができる。プリロードは、プリロード命令などを利用して行い、第１の画像処理が開始するときまでに完了するようにスタートすればよいので、データ転送より前に開始してもよい。待機状態の画像処理に必要なデータとは、例えば、背景画像などの繰り返し利用する画像データや上述の第１１実施形態で述べた統計処理情報など様々であり、この限りではない。また、例えば、上述の第８実施形態で説明したＤＥＥＰ ＳＬＥＥＰ時にキャッシュメモリ１１４に対する電力供給を停止する第１ＤＥＥＰ ＳＬＥＥＰモードでは、ＤＥＥＰ ＳＬＥＥＰモードから復帰後に可能なタイミングでメインメモリ５０あるいは内部メモリ１１２から、第１の画像処理で利用するデータをプリロードすればよい。この場合でも、データ転送を開始する前にプリロードを開始してもよい。

（第１５実施形態）
本実施形態では、上述の第１実施形態の構成に、ローパワーなマイコンを追加し、上述の第１実施形態ではＳｏＣ１０上で実行していた第１の画像処理（待機状態の画像処理）を、マイコンにオフロードする（第１の画像処理をマイコンに行わせる）。つまり、情報処理装置１は、第１画像処理部１２１を有するマイコンを備える。これにより、変化が検出された場合のみ（第１の画像処理の結果、第２の画像処理の実行条件を満たす場合のみ）、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰモードから復帰させてアプリケーションに高度な画像処理を実行させればよいので、動作時の消費電力が大きいＳｏＣ１０のアイドル時間をより長く確保することができ、低消費電力化できる。第１の画像処理が繰り返し実行され、画像変化が検出されない間は、ＳｏＣ１０はＤＥＥＰ ＳＬＥＥＰモードを維持するので、ＳｏＣ１０の消費電力が低いままであることが観測される。

図２２は、本実施形態の情報処理装置１の構成の一例を示す図である。図２２に示すように、Ｉ／Ｏデバイスとしてマイコン８０が新たに追加され、ＳｏＣ１０には、マイコン８０を制御するシリアルデバイスコントローラ１５０が新たに追加される点で上述の第１実施形態の構成と相違する。シリアルバスコントローラ１５０は、例えばＩ２Ｃ、ＳＰＩ、ＵＡＲＴ、ＧＰＩＯなどで構成され得る。図２２の例では、マイコン８０が、上述の第１画像処理部１２１を有していて第１の画像処理を実行し、ＳｏＣ１０が、上述の第２画像処理部１３０を有していて第２の画像処理を実行する形態である。

図２３は、本実施形態のイメージセンサ管理部１２０の機能構成の一例を示す図である。マイコン８０側で第１の画像処理を実行できるよう、イメージセンサ管理部１２０の機能は、ＯＳ側と、マイコン８０上で実行するソフトウェア（以下、「マイコンソフトウェア」と称する場合がある）側とに分離されている。図２３の例では、ＯＳ側のイメージセンサ管理部１２０を「１２０Ａ」、マイコンソフトウェア側のイメージセンサ管理部１２０を「１２０Ｂ」と称している。なお、以下の説明では、両者を区別しない場合は、単に「イメージセンサ管理部１２０」と称する。

図２３に示すように、マイコンソフトウェア側にあるイメージセンサ管理部１２０Ｂは、第２待機状態制御部１６１と、第１画像処理部１２１と、第２待機状態電力制御部１６２と、イメージセンサ制御部１２４とを有する。第２待機状態制御部１６１は、イメージセンサ管理部１２０の動作を統括的に制御する。第１画像処理部１２１は、待機状態の画像処理（第１の画像処理）を実行する。第２待機状態電力制御部１６２は、イメージセンサ７３とマイコン８０に供給する電力を制御する。イメージセンサ制御部１２４は、イメージセンサ７３を制御する。

図２３に示すように、ＯＳ側にあるイメージセンサ管理部１２０Ａは、第１待機状態制御部１６３と、第１待機状態電力制御部１６４とを有する。第１待機状態制御部１６３は、アプリケーションやマイコン側の第２待機状態制御部１６１と通信する。第１待機状態電力制御部１６４は、ＳｏＣ１０に供給する電力を制御する。例えば、第１待機状態電力制御部１６４は、電力管理部１４０に対して、ＳｏＣ１０のＤＥＥＰ ＳＬＥＥＰモードへの遷移などを指示する。

図２４は、イメージセンサ管理部１２０による処理の一例を示すフローチャートである。この処理は、アプリケーションから変化検出処理の要求（第１の画像処理の要求）を第１待機状態制御部１６３が受信すると開始される。第１待機状態制御部１６３は、マイコン８０側に、第１の画像処理の実行を依頼する（ステップＳ２２０１）。そして、第１待機状態電力制御部１６４は、電力管理部１４０に対して、ＤＥＥＰ ＳＬＥＥＰモードに設定することを指示する（ステップＳ２２０２）。

次に、マイコン８０側の第１画像処理部１２１は、第１の画像処理を実行する（ステップＳ２２０３）。画像変化を検出した場合（ステップＳ２２０４：Ｙｅｓ）、処理はステップＳ２２０８に進む。画像変化を検出しなかった場合（ステップＳ２２０４：Ｎｏ）、第２待機状態電力制御部１６２は、マイコン８０をローパワーモード（第１の画像処理を実行可能な状態よりも消費電力が少ない省電力状態）に設定する（ステップＳ２２０５）。その後、タイマーなどを利用して一定時間待つ（ステップＳ２２０６）。一定時間経過すると、第２待機状態電力制御部１６２は、マイコン８０を、ローパワーモードから、第１の画像処理を実行可能な状態へ復帰させる制御を行い（ステップＳ２２０７）、処理はステップＳ２２０３に戻る。そして、第１画像処理部１２１は、再び第１の画像処理を実行する。

一方、上述のステップＳ２２０４において、画像変化を検出した場合（ステップ２２０４：Ｙｅｓ）、第２待機状態制御部１６１は、ＳｏＣ１０を割り込みで復帰させるとともに、イメージセンサ制御部１２４に高解像度画像を取得させ、その取得させた高解像度画像をＳｏＣ１０へ転送する制御を行う（ステップＳ２２０８）。その後、第２待機状態制御部１６１は、第１待機状態制御部１６３（見方を変えればアプリケーション）からの、変化検出処理（第１の画像処理）の要求を待つことになり（ステップＳ２２０９）、処理は上述のステップＳ２２０１に戻る。なお、ステップ２２０９の直前にマイコン８０をローパワーモードにして、要求が到着したらローパワーモードから復帰するようにしてもよい。

（第１６実施形態）
本実施形態では、上述の第１実施形態ではＳｏＣ１０上で実行していた第１の画像処理（待機状態の画像処理）を、図２５のようにイメージセンサデバイス（ＣＭＯＳイメージセンサモジュール）７０内部で行う。つまり、イメージセンサデバイス７０は、第１画像処理部１２１を有する。第１の画像処理の全部あるいは一部をＣＭＯＳイメージセンサモジュール７０で実行することで、画像変化を検出した場合のみＳｏＣ１０を動作させればよいので、動作時の消費電力が大きいＳｏＣ１０のアイドル時間をより長くすることができ、低消費電力化を図ることができる。

図２６は、本実施形態のＣＭＯＳイメージセンサモジュール７０の構成の一例を示す図である。図２６に示すように、ＣＭＯＳイメージセンサモジュール７０は、図２に示す構成に、イメージセンサ管理部１２０を機能統合している。

図２７は、本実施形態のイメージセンサ管理部１２０の機能構成の一例を示す図である。ＣＭＯＳイメージセンサモジュール７０側で第１の画像処理を実行できるよう、イメージセンサ管理部１２０の機能は、ＯＳ側と、ＣＭＯＳイメージセンサモジュール７０側とに分離されている。図２７の例では、ＯＳ側のイメージセンサ管理部１２０を「１２０Ａ」、ＣＭＯＳイメージセンサモジュール７０側のイメージセンサ管理部１２０を「１２０Ｃ」と称している。なお、以下の説明では、両者を区別しない場合は、単に「イメージセンサ管理部１２０」と称する。

図２７に示すように、ＣＭＯＳイメージセンサモジュール７０側のイメージセンサ管理部１２０Ｃは、第２待機状態制御部１７１と、第１画像処理部１２１と、第２待機状態電力制御部１７２と、イメージセンサ制御部１２４とを有する。第２待機状態制御部１７１は、イメージセンサ管理部１２０の動作を統括的に制御する。第１画像処理部１２１は、待機状態の画像処理（第１の画像処理）を実行する。第２待機状態電力制御部１７２は、イメージセンサ７３に供給する電力を制御する。イメージセンサ制御部１２４は、ＣＭＯＳイメージセンサモジュール７０を制御する。

図２７に示すように、ＯＳ側のイメージセンサ管理部１２０Ａは、第１待機状態制御部１７３と、第１待機状態電力制御部１７４とを有する。第１待機状態制御部１７３は、アプリケーションやＣＭＯＳイメージセンサモジュール７０側の第２待機状態制御部１７１と通信する。第１待機状態電力制御部１７４は、ＳｏＣ１０に供給する電力を制御する。例えば、第１待機状態電力制御部１７４は、電力管理部１４０に対して、ＳｏＣ１０のＤＥＥＰ ＳＬＥＥＰモードへの遷移などを指示する。

図２８は、イメージセンサ管理部１２０による処理の一例を示すフローチャートである。この処理は、アプリケーションから変化検出処理の要求（第１の画像処理の要求）を第１待機状態制御部１７３が受信すると開始される。第１待機状態制御部１７３は、ＣＭＯＳイメージセンサモジュール７０側に、第１の画像処理の実行を依頼する（ステップＳ２５０１）。そして、第１待機状態電力制御部１７３は、電力管理部１４０に対して、ＤＥＥＰ ＳＬＥＥＰモードに設定することを指示する（ステップＳ２５０２）。

次に、ＣＭＯＳイメージセンサモジュール７０側の第１画像処理部１２１は、第１の画像処理を実行する（ステップＳ２５０３）。画像変化を検出した場合（ステップＳ２５０４：Ｙｅｓ）、処理はステップＳ２５０８に進む。画像変化を検出しなかった場合（ステップＳ２５０４：Ｎｏ）、第２待機状態電力制御部１７２は、ＣＭＯＳイメージセンサ７３を省電力モードに設定する（ステップＳ２５０５）。その後、タイマーなどを利用して一定時間待つ（ステップＳ２５０６）。一定時間経過すると、第２待機状態電力制御部１７２は、ＣＭＯＳイメージセンサ７３を、省電力モードから、第１の画像処理を実行可能な状態へ復帰させる制御を行い（ステップＳ２５０７）、処理はステップＳ２５０３に戻る。そして、第１画像処理部１２１は、再び第１の画像処理を実行する。

一方、上述のステップＳ２５０４において、画像変化を検出した場合（ステップ２５０４：Ｙｅｓ）、第２待機状態制御部１７１は、ＳｏＣ１０を割り込みで復帰させるとともに、イメージセンサ制御部１２４に高解像度画像を取得させ、その取得させた高解像度画像をＳｏＣ１０へ転送する制御を行う（ステップＳ２５０８）。その後、第２待機状態制御部１７１は、第１待機状態制御部１７３（見方を変えればアプリケーション）からの、変化検出処理（第１の画像処理）の要求を待つことになり（ステップＳ２５０９）、処理は上述のステップＳ２５０１に戻る。なお、ステップＳ２５０９の直前にＣＭＯＳイメージセンサ７３を省電力モードにして、要求が到着したら省電力モードから復帰するようにしてもよい。

要するに、本実施形態のイメージセンサデバイス７０は、イメージセンサ７３を有する画像入力装置であって、画像入力要求を受け取ると、イメージセンサ７３から第１の画像を入力し、第１の画像の変化がない場合は、次の第１の画像の入力を待ち、変化があった場合は、第１の画像よりも解像度の高い第２の画像をイメージセンサ７３から入力し、その入力した第２の画像を出力していると考えることができる。また、本実施形態のイメージセンサデバイス７０は、第１の画像の変化がない場合は、次の第１の画像の入力を待ち、画像を入力しているときの第２電力から、第２電力よりも低い第３電力に切り替えていると考えることもできる。

なお、後述の実施形態で説明するメガネ型ウェアラブル機器の構成に、本実施形態を適用することも可能である。

本実施形態では、低解像度画像や鮮明でない画像を利用して第１の画像処理（待機状態の画像処理）を実行し、画像変化の有無を検出しているが、同様に、カメラなどセキュリティやプライバシ保護の観点から撮影が禁止される対象物（以下、「禁止対象物」と称する）が映っていないかを検出することもできる。つまり、イメージセンサモジュール７０が第１画像処理部１２１を有する構成においては、第１画像処理部１２１は、ＣＭＯＳイメージセンサ制御部１２４に取得させた画像が、情報処理装置１で取得可能な画像であるか否かを判定する処理を実行することもできる。

例えば第１の画像処理の際に、変化を検出した場合は、さらに禁止対象物が映っているか否かを検出する処理を実行し、禁止対象物が映っている場合は、ＳｏＣ１０への高解像度画像の転送を防止したり、禁止対象物をぼかしたり、セキュリティやプライバシの観点から許容される範囲の低い解像度の画像を返したりすることで、低消費電力、かつ、イメージセンサ７３の外にはセキュリティやプライバシの観点から問題となる画像が出力されないセキュアなイメージセンサ搭載型の情報処理装置を実現できる。同様に、撮影が許可される対象物が写っていることを検出しない限りは、イメージセンサ７３の外に画像を出力しない形態であってもよい。

（第１７実施形態）
本実施形態は、上述の第１６実施形態のように第１の画像処理をイメージセンサデバイス７０（ＣＭＯＳイメージセンサモジュール７０）内部で行う形態ではないが、本実施形態のイメージセンサデバイス７０は、第１実施形態などを効率よく実施するのに適した複数の撮像モードを有する。

具体的には、画像入力要求を受け取ると、ＣＭＯＳイメージセンサ７３からの第１の画像を入力する際に、アプリケーションなどから指定された解像度で指定された枚数の画像だけを指定された間隔で入力する変化検出に特化した省電力な第１の撮像モードを有する。当然、低解像度の画像１枚だけ撮像できてもよい。一般に、撮像を開始するとイメージセンサ７３からは連続して画像が入力され続けるので、イメージセンサ７３から必要以上に画像が入力されてしまい、イメージセンサ７３の動作時間も必要以上に長く消費電力も大きくなってしまうが、第１の撮像モードでは、必要最低限の画像を入力でき、イメージセンサ７３の動作時間も最小化できる。第１の撮像モードは、第１の画像処理を行うことを前提としているので、画像入力後にすぐにイメージセンサデバイス７０はすぐに省電力モードに自動的に遷移してもよい。第１の画像処理（変化検出処理）に特化したモードであり、オートフォーカスなどの機能を省略していて変化検出処理ができる低解像度で鮮明でない画像だけ撮像できてもよい。当然第１の撮像モードを第２の画像処理で利用してもよい。

第２の撮像モードは、第２の画像処理で利用することを前提としている。第２の撮像モードでは別途指定されるまで連続した画像が入力され続けるので、第２の画像処理で連続した画像を入力したい際には第２の撮像モードを利用すればよい。つまり、イメージセンサ７３から指定された第１の画像を返して入力を終了する少ない電力で変化検出可能な第１の撮像モードと、指定された第２の画像を返して別途指定されるまで入力を続ける第２の撮像モード、を有する画像入力装置（イメージセンサモジュール７０）である。

第３の撮像モードは、第１の画像処理と第２の画像処理の遅延を小さくするモードである。第１の画像処理が完了してから第２の画像を撮像していると遅延が生じる場合がある。第３の撮像モードは、第１の画像処理で利用する第１の画像（低解像度画像）と、第２の画像処理で利用する第２の画像（高解像度画像）の両方を先に取得しておきイメージセンサデバイス７０上のバッファに格納し、低解像度画像だけをまず返す。アプリケーションで第１の画像処理が実行され、変化が検出された場合は、第２の画像の画像入力要求を受け取り、格納してあった第２の画像を返す。このようにすることで、第１の画像と第２の画像の撮像の時間差を非常に小さくできるので、変化検出の可能性が高い場合はこの撮像モードを利用するとよい。

つまり、本実施形態の画像入力装置（イメージセンサモジュール７０）は、イメージセンサ７３から、第１の画像と、第１の画像よりも解像度の高い第２の画像を連続して入力し、入力した第２の画像を記憶し、第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）の結果、第１の画像の変化が検出された場合、記憶された第２の画像を出力（この例ではアプリケーションへ出力）する形態であってもよい。なお、以上に示した撮像モードの例は一例でありこの限りではない。

（第１８実施形態）
本実施形態の情報処理装置１は、メガネ型のウェアラブル機器で構成される。図２９に示すように、本実施形態の情報処理装置１は、図１の構成に加えて、センサデバイス２１０、センサデバイス２１０を制御するセンサコントローラ２１１、ディスプレイデバイス２２０、ディスプレイデバイス２２０を制御するディスプレイコントローラ２２１をさらに備える。例えばセンサデバイス２１０は、３軸ジャイロセンサと３軸加速度センサと３軸電子コンパスを内蔵した９軸センサモジュールで構成される。また、センサデバイス２１０として、赤外線センサや音センサ（マイク）などの各種センサを備えていてもよい。例えばディスプレイデバイス２２０は、Ｍｉｒａｓｏｌなどの各種電子ペーパーや不揮発性ディスプレイ、ＩＧＺＯやメモリ液晶のような低いリフレッシュレートで動作するＬＣＤなどを搭載したヘッドマウントディスプレイで構成される。また、本実施形態以外の他の全ての実施形態においても、本実施形態のようなメガネ型のウェアラブル機器で情報処理装置１を構成することもできる。

本実施形態では、第２の画像処理を、情報処理装置１とは異なる第２の情報処理装置に実行させる（第２の画像処理を、第２の情報処理装置にオフロードする）オフロード制御部を備える。例えば無線ＬＡＮや近距離無線通信などを利用してスマートフォン（第２の情報処理装置に対応）などと連携して、高度な第２の画像処理やその他の負荷が高い処理をスマートフォン（不図示）などにオフロードしてもよい。例えば、メガネ型ウェアラブル機器のＳｏＣ１０上で実行する第１の画像処理の結果、人を検出した場合は、高度な顔認識処理である第２の画像処理に必要な解像度の高解像度画像をスマートフォンに転送し、スマートフォンに、顔認識処理と、認識した顔が誰であるかなどを検索する処理（これを含めて第２の画像処理であると考えてもよい）とを実行させてもよい。この際に、スマートフォンからさらにクラウドなどの第３の情報処理装置に処理をオフロードしてもよい。スマートフォンは、第２の画像処理の結果を、情報処理装置１（この例ではメガネ型ウェアラブル機器）に返し、情報処理装置１は、スマートフォンから受け取った第２の画像処理の結果を画像に合成した合成画像を生成してＬＣＤに表示する。また、スマートフォン側で第２画像処理を実行中の場合は、情報処理装置１は低消費電力状態に遷移する。

図３０は、本実施形態の情報処理装置１と、第２の情報処理装置として機能するスマートフォンの機能構成の一例を示す図である。ＯＳによって提供される機能の中には、イメージセンサ管理部１２０、ディスプレイデバイス管理部１８０、電力管理部１４０、同期設定部１９０などが含まれる。イメージセンサ管理部１２０は、第１画像処理部１２１と、待機状態制御部１２２と、待機状態電力制御部１２３と、イメージセンサ制御部１２４とを有する。これらの機能は、第１実施形態とほぼ同様であり、待機状態制御部１２２は、第１実施形態と同様にアプリケーションと通信する。

ディスプレイデバイス管理部１８０は、第２待機状態制御部１８１と、ディスプレイデバイス制御部１８２とを有する。第２待機状態制御部１８１は、ディスプレイデバイス管理部１８０の動作を統括的に制御する。ディスプレイデバイス制御部１８２は、ディスプレイデバイス２２０を制御する。

同期設定部１９０は、情報処理装置１が有するデバイスが定期的に実行する処理と、第１の画像処理の実行タイミングとを同期させる。この例では、デバイスはディスプレイデバイス２２０（表示装置）であり、デバイスが定期的に実行する処理は、表示内容を保持するためのリフレッシュ処理であるが、これに限られるものではない。要するに、本実施形態の情報処理装置１は、第１の画像の変化を判定する第１の処理（この例では「第１の画像処理」）の実行タイミングと、情報処理装置１上で実行する第３の処理（この例では「リフレッシュ処理」）の実行タイミングとが同期する形態であればよい。

また、図３０の例では、アプリケーションは、第２の画像処理をスマートフォンに実行させる制御を行うオフロード制御部１９５を有し、スマートフォンは、第２の画像処理を実行する第２画像処理部１３０を有している。

第１実施形態と同様に、アプリケーションは、イメージセンサ管理部１２０に対して、第１の画像処理の実行を要求する。この要求を受けた待機状態制御部１２２は、第１の画像処理を実行することを第１画像処理部１２１に対して指示し、この指示を受けた第１画像処理部１２１は第１の画像処理を実行する。第１の画像処理の結果、画像変化が検出された場合、待機状態制御部１２２は、第２の画像処理に必要な高解像度画像をイメージセンサ制御部１２４に取得させ、その取得させた高解像度画像と、第２の画像処理の実行条件を満たすことを示す情報とをアプリケーションに通知する。この通知を受けたアプリケーション（オフロード制御部１９５）は、スマートフォンに対して、高解像度画像を転送し、第２の画像処理の実行を指示する。この指示を受けたスマートフォン（第２画像処理部１３０）は、第２の画像処理を実行し、第２の画像処理の結果をアプリケーションに返す。アプリケーションは、スマートフォンから受け取った第２の画像処理の結果を画像に合成した合成画像を生成し、ディスプレイデバイスドライバ（ディスプレイデバイス管理部１８０）へ転送する。合成画像を受け取った第２待機状態制御部１８１は、ディスプレイデバイス制御部１８２に対して合成画像の表示を指示し、ディスプレイデバイス制御部１８２は、第２待機状態制御部１８１の指示に従って、合成画像をディスプレイデバイス２２０に表示する制御を行う。

図３１は、アプリケーションによる処理の一例を示すフローチャートである。図３１に示すように、まずアプリケーションは、イメージセンサ管理部１２０に対して、第１の画像処理の実行を要求する（ステップＳ２７０１）。ステップＳ２７０１の後、アプリケーションは、イメージセンサ管理部１２０から、画像変化を検出した旨の通知（第２の画像処理の実行条件を満たすことを示す情報の通知であると考えることもできる）を待つ（ステップＳ２７０２）。アプリケーションは、イメージセンサ管理部１２０から、画像変化を検出した旨の通知を受けると、これと同時に受け取る高解像度画像をスマートフォンに転送し、第２の画像処理の実行を要求する（ステップＳ２７０３）。ステップＳ２７０３の後、アプリケーションは、第２の画像処理の実行結果の通知待ちとなる（ステップＳ２７０４）。そして、スマートフォンから、第２の画像処理の結果を受け取ると、第２の画像処理の結果を画像に合成した合成画像を生成し、ディスプレイデバイス管理部１８０へ転送する（ステップＳ２７０５）。アプリケーションは以上の処理を繰り返し実行する。なお、イメージセンサ管理部１２０による処理は、図８の内容とほぼ同様であるので詳細な説明は省略する。

以上のように第２の画像処理をオフロードすると、画像などのデータの転送に伴って電力を消費するが、それと引き換えに第２の画像処理に必要な電力は削減することができるし、スマートフォン側で高速に処理を完了させることができる場合もある。情報処理装置の表示装置ではディスプレイに関連する消費電力が大きいため、表示内容に変化がない場合には電力供給を停止しても（あるいは僅かな電力供給で）表示を保持できる不揮発性の電子ペーパーやメモリ液晶ディスプレイ、ＰＳＲ（Ｐａｎｅｌ Ｓｅｌｆ Ｒｅｆｒｅｓｈ）対応の液晶ディスプレイ、あるいはＩＧＺＯなどの低リフレッシュレートで動作する低消費電力ディスプレイを利用することで、情報処理装置のユーザがディスプレイを閲覧している間や表示内容に変化がない場合などの待機時の消費電力を抑制することができる。ＩＧＺＯなどの低リフレッシュレートで動作する低消費電力ディスプレイでは、例えば１秒に１回、定期的な書換えを実行すれば表示内容が保持される。そのため、図３２に示すように、同期設定部１９０は、第１の画像処理（待機状態の画像処理）の実行間隔(ＣＭＯＳイメージセンサ７３からの画像を取り込むタイミング)を、ＩＧＺＯなどのディスプレイの表示内容を保持するための定期的なリフレッシュ処理にタイミングを同期させる。これにより、ＳｏＣ１０を、これらの処理のためにＤＥＥＰ ＳＬＥＥＰモード（あるいはその他の省電力モードでもよいのは言うまでもない）から復帰させる回数を削減できるので、より省電力化を図ることができる。

なお、図３２では、２つの処理が完全に同期しているが、リフレッシュ処理間に複数回第１の画像処理が実行されてもよいし、その逆でもよく、またそのようになるように合わせ込みを行ってもよい。このように、消費電力が大きい複数のデバイス（この場合はディスプレイデバイス２２０とイメージセンサ７３）の動作タイミング（あるいはアクティブ時間）を合わせ込んでアイドル時間を最大化することで大きな省電力効果を得ることができる。また、ＰＳＲや電子ペーパーで書換処理（表示内容を変更する処理）を非同期的に行う処理についても、ＳｏＣ１０をＤＥＥＰ ＳＬＥＥＰから復帰させる必要があるので、そのタイミングで第１の画像処理を行うようにしてもよい。当然、９軸センサなどのセンシング処理の実行間隔と、第１の画像処理の実行間隔とを同期させてもよいのは言うまでもない。

（第１９実施形態）
上述の第１実施形態において、例えば情報処理装置１が太陽電池で駆動する場合は、キャパシタなどの電力を蓄える蓄電部の残量（あるいは太陽電池の発電量）に応じて、第１の画像処理（待機状態の画像処理）の方法を動的に切り替えることで、厳しい電力制約下でも安定的に情報処理装置１の動作を継続させるようにする。例えば、待機状態制御部１２２は、蓄電部の残量が閾値を下回ると、画像の取り込み間隔を長くする、あるいは、第１の画像処理に用いる画像処理アルゴリズムを切り替えることで、消費電力を抑制することができる。この例では、待機状態制御部１２２は、「切替制御部」に対応している。

以上の各実施形態は任意に組み合わせることが可能である。

また、上述の情報処理装置１で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するようにしてもよい。また、上述の情報処理装置１で実行されるプログラムを、インターネット等のネットワーク経由で提供または配布するようにしてもよい。また、上述の情報処理装置１で実行されるプログラムを、ＲＯＭ等の不揮発性の記録媒体に予め組み込んで提供するようにしてもよい。

ここで、以上に説明した各実施形態に記載された情報処理装置の特徴を列記する。
（態様１）
情報処理装置であって、イメージセンサを制御するイメージセンサ制御部と、前記イメージセンサ制御部が前記イメージセンサから取得した画像を用いて、第２の画像処理よりも処理量が少ない画像処理であって、前記第２の画像処理の実行の可否を決定するための第１の画像処理を実行する第１画像処理部と、を備える情報処理装置。
（態様２）
前記第１画像処理部は、前記第２の画像処理に用いられる画像よりも解像度が低い画像を前記イメージセンサ制御部に取得させ、その取得させた画像を用いて前記第１の画像処理を実行する態様１に記載の情報処理装置。
（態様３）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしていない場合は、前記第１の画像処理を実行する第１状態よりも消費電力が小さい第２状態に前記情報処理装置を遷移させる制御を行う電力制御部を備える態様１に記載の情報処理装置。
（態様４）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしている場合は、アプリケーションに前記第２の画像処理を実行させる制御を行う実行制御部を備える態様１に記載の情報処理装置。
（態様５）
前記第１の画像処理は、前記イメージセンサ制御部が取得した画像の変化を検出するための処理であり、前記第１の画像処理によって、前記イメージセンサ制御部が取得した画像の変化が検出された場合は、前記第２の画像処理の実行条件を満たす態様１に記載の情報処理装置。
（態様６）
前記第１の画像処理は、前記イメージセンサ制御部が取得した画像に特定の対象物が映っているか否かを検出するための処理であり、前記第１の画像処理によって、前記イメージセンサ制御部が取得した画像に前記特定の対象物が映っていることが検出された場合は、前記第２の画像処理の実行条件を満たす態様５に記載の情報処理装置。
（態様７）
アプリケーションからの指定に応じて、予め前記第１画像処理部に用意されている複数種類の画像処理アルゴリズムのうちの少なくとも１つを、前記第１の画像処理に用いる画像処理アルゴリズムとして設定する制御を行う設定制御部を備える態様１に記載の情報処理装置。
（態様８）
アプリケーションが、予め前記第１画像処理部に用意されている複数種類の画像処理アルゴリズムのうちの少なくとも１つを、前記第１の画像処理に用いる画像処理アルゴリズムとして指定するためのインタフェース部を備える態様１に記載の情報処理装置。
（態様９）
アプリケーションからの要求に応じて、前記第１の画像処理に用いる画像処理アルゴリズムを外部から取得する取得制御部を備える態様１に記載の情報処理装置。
（態様１０）
アプリケーションが、前記第１の画像処理に用いる画像処理アルゴリズムを前記取得制御部に取得させるためのインタフェース部を備える態様１に記載の情報処理装置。
（態様１１）
前記第１の画像処理に用いられる画像を取得する場合と、前記第２の画像処理に用いられる画像を取得する場合とで、前記イメージセンサの初期化時間が異なる態様１に記載の情報処理装置。
（態様１２）
前記イメージセンサ制御部は、前記第１の画像処理に用いられる画像を取得する場合の前記イメージセンサの初期化時間を、前記第２の画像処理に用いられる画像を取得する場合の前記イメージセンサの初期化時間よりも短い値に設定する態様１１に記載の情報処理装置。
（態様１３）
アプリケーションが、前記イメージセンサの初期化時間を指定するためのインタフェース部を備える態様１に記載の情報処理装置。
(態様１４)
前記イメージセンサ制御部は、アプリケーションからの指定に応じて、前記イメージセンサの初期化時間を設定する態様１３に記載の情報処理装置。
（態様１５）
アプリケーションが、前記第１の画像処理を実行する間隔を指定するためのインタフェース部を備える態様１に記載の情報処理装置。
（態様１６）
アプリケーションからの指定に応じて、前記間隔を設定する間隔設定制御部を備える態様１５に記載の情報処理装置。
（態様１７）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしている場合は、前記第１の画像処理に用いられた画像のうち、前記第２の画像処理の実行条件を満たす領域の画像を少なくとも含み、前記第１の画像処理に用いられた画像よりも解像度が高い高解像度画像を、前記イメージセンサ制御部に取得させてアプリケーションへ通知する実行制御部を備える態様１に記載の情報処理装置。
（態様１８）
前記実行制御部は、前記高解像度画像と、前記高解像度画像のうち前記第２の画像処理の実行条件を満たしている領域を示す情報とを、アプリケーションへ通知する態様１７に記載の情報処理装置。
（態様１９）
アプリケーションが、前記高解像度画像を取得するためのインタフェース部を備える態様１７に記載の情報処理装置。
（態様２０）
前記イメージセンサ制御部は、前記第１の画像処理に用いられる画像として、前記イメージセンサから取得可能な全体画像のうちの一部の領域の画像を取得する態様１に記載の情報処理装置。
（態様２１）
アプリケーションが、前記一部の領域を指定するためのインタフェース部を備える態様２０に記載の情報処理装置。
（態様２２）
前記第１の画像処理を実行する間隔が動的に変化する態様１に記載の情報処理装置。
（態様２３）
前記第１の画像処理の結果に応じて、前記間隔を可変に設定する間隔設定制御部を備える態様２２に記載の情報処理装置。
（態様２４）
前記第１の画像処理を実行する間隔に応じて、前記第１の画像処理に要する時間が変化する態様１に記載の情報処理装置。
（態様２５）
前記間隔に応じて、前記イメージセンサが画像の取得を行うことができない第３状態と、前記イメージセンサが画像の取得を行うことが可能な第４状態とを切り換えるのに要する時間を示す切換時間を可変に設定する切換時間設定部を備える態様２４に記載の情報処理装置。
（態様２６）
前記第２状態に遷移する際に、前記第１の画像処理に使用されるキャッシュメモリに対する電力の供給を継続するか否かを判定するキャッシュ電源判定制御部を備える態様３に記載の情報処理装置。
（態様２７）
前記キャッシュ電源判定制御部は、前記第１の画像処理を実行する間隔が閾値よりも長い場合は、前記キャッシュメモリに対する電力の供給を停止すると判定し、前記第１の画像処理を実行する間隔が前記閾値以下の場合は、前記キャッシュメモリに対する電力の供給を継続すると判定する態様２６に記載の情報処理装置。
（態様２８）
前記第１の画像処理を実行する場合の主記憶装置へのアクセス頻度は、前記第２の画像処理を実行する場合に比べて少ない態様１に記載の情報処理装置。
（態様２９）
前記第１の画像処理に利用されるデータの少なくとも一部を保存する、前記主記憶装置とは異なる内部メモリを備え、前記第１画像処理部は、前記内部メモリに保存されたデータを用いて前記第１の画像処理を実行する態様２８に記載の情報処理装置。
（態様３０）
前記イメージセンサ制御部が取得する、前記第１の画像処理に用いられる画像が、時間の経過とともに変化する態様１に記載の情報処理装置。
（態様３１）
学習期間内に繰り返し実行された前記第１の画像処理の結果に基づいて、前記イメージセンサから取得可能な全体画像を構成する複数のサブ領域ごとに、変化が検出された回数を対応付けた統計情報を生成する統計情報管理部を備え、前記第１画像処理部は、前記全体画像のうち、変化が検出された回数が閾値以上の前記サブ領域の画像を前記イメージセンサ制御部に取得させ、その取得させた画像を用いて前記第１の画像処理を実行する態様３０に記載の情報処理装置。
（態様３２）
アプリケーションが、前記学習期間を指定するためのインタフェース部を備える態様３１に記載の情報処理装置。
（態様３３）
アプリケーションが、前記統計情報を取得するためのインタフェース部を備える態様３１に記載の情報処理装置。
（態様３４）
前記第１の画像処理の開始前に、前記第１の画像処理に利用されるデータをプリロードするプリロード部を備える態様１に記載の情報処理装置。
（態様３５）
前記第１画像処理部を有するマイコンを備える態様１に記載の情報処理装置。
（態様３６）
前記イメージセンサは前記第１画像処理部を有する態様１に記載の情報処理装置。
（態様３７）
前記第１画像処理部は、前記イメージセンサ制御部に取得させた画像が、前記情報処理装置が取得可能な画像であるか否かを判断する処理を行う態様３６に記載の情報処理装置。
（態様３８）
前記第２の画像処理を、前記情報処理装置とは異なる第２の情報処理装置に実行させるオフロード制御部を備える態様１に記載の情報処理装置。
（態様３９）
前記情報処理装置が有するデバイスが定期的に実行する処理と、前記第１の画像処理の実行タイミングとを同期させる同期設定部を備える態様１に記載の情報処理装置。
（態様４０）
前記デバイスは表示装置であり、前記デバイスが定期的に実行する処理は、表示内容を保持するためのリフレッシュ処理である態様３９に記載の情報処理装置。
（態様４１）
電力を蓄える蓄電部の残量に応じて、前記第１の画像処理の方法を切り替える切替制御部を備える態様１に記載の情報処理装置。
（態様４２）
情報処理装置であって、イメージセンサを制御するイメージセンサ制御部と、前記イメージセンサ制御部が前記イメージセンサから取得した画像を用いて、第１の画像処理の実行の可否を決定するための画像処理であって、前記第１の画像処理よりも消費電力が少ない第２の画像処理を実行する第１画像処理部と、を備える情報処理装置。

また、以上に説明した各実施形態に記載された情報処理装置（プロセッサ）が実行する情報処理方法の特徴を列記する。
（態様４３）
イメージセンサを制御するイメージセンサ制御ステップと、前記イメージセンサ制御ステップで前記イメージセンサから取得した画像を用いて、第２の画像処理よりも処理量が少ない画像処理であって、前記第２の画像処理の実行の可否を決定するための第１の画像処理を実行する第１画像処理ステップと、を含む情報処理方法。
（態様４４）
前記第１画像処理ステップは、前記第２の画像処理に用いられる画像よりも解像度が低い画像を前記イメージセンサ制御部に取得させ、その取得させた画像を用いて前記第１の画像処理を実行する態様４３に記載の情報処理方法。
（態様４５）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしていない場合は、前記第１の画像処理を実行する第１状態よりも消費電力が小さい第２状態に前記情報処理装置を遷移させる制御を行う電力制御ステップを含む態様４３に記載の情報処理方法。
（態様４６）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしている場合は、アプリケーションに前記第２の画像処理を実行させる制御を行う実行制御ステップを含む態様４３に記載の情報処理方法。
（態様４７）
前記第１の画像処理は、前記イメージセンサ制御ステップで取得した画像の変化を検出するための処理であり、前記第１の画像処理によって、前記イメージセンサ制御ステップで取得した画像の変化が検出された場合は、前記第２の画像処理の実行条件を満たす態様４３に記載の情報処理方法。
（態様４８）
前記第１の画像処理は、前記イメージセンサ制御ステップで取得した画像に特定の対象物が映っているか否かを検出するための処理であり、前記第１の画像処理によって、前記イメージセンサ制御ステップで取得した画像に前記特定の対象物が映っていることが検出された場合は、前記第２の画像処理の実行条件を満たす態様４７に記載の情報処理方法。
（態様４９）
アプリケーションからの要求に応じて、前記第１の画像処理に用いる画像処理アルゴリズムを外部から取得する取得制御ステップを含む態様４３に記載の情報処理方法。
（態様５０）
前記第１の画像処理に用いられる画像を取得する場合と、前記第２の画像処理に用いられる画像を取得する場合とで、前記イメージセンサの初期化時間が異なる態様４３に記載の情報処理方法。
（態様５１）
前記イメージセンサ制御ステップは、前記第１の画像処理に用いられる画像を取得する場合の前記イメージセンサの初期化時間を、前記第２の画像処理に用いられる画像を取得する場合の前記イメージセンサの初期化時間よりも短い値に設定する態様５０に記載の情報処理方法。
（態様５２）
前記イメージセンサ制御ステップは、アプリケーションからの指定に応じて、前記イメージセンサの初期化時間を設定する態様４３に記載の情報処理方法。
（態様５３）
アプリケーションからの指定に応じて、前記第１の画像処理を実行する間隔を設定する間隔設定制御ステップを含む態様４３に記載の情報処理方法。
（態様５４）
前記第１の画像処理の結果が、前記第２の画像処理の実行条件を満たしている場合は、前記第１の画像処理に用いられた画像のうち、前記第２の画像処理の実行条件を満たす領域の画像を少なくとも含み、前記第１の画像処理に用いられた画像よりも解像度が高い高解像度画像を、前記イメージセンサ制御部に取得させてアプリケーションへ通知する実行制御ステップを含む態様４３に記載の情報処理方法。
（態様５５）
前記実行制御ステップは、前記高解像度画像と、前記高解像度画像のうち前記第２の画像処理の実行条件を満たしている領域を示す情報とを、アプリケーションへ通知する態様５４に記載の情報処理方法。
（態様５６）
前記イメージセンサ制御ステップは、前記第１の画像処理に用いられる画像として、前記イメージセンサから取得可能な全体画像のうちの一部の領域の画像を取得する態様４３に記載の情報処理方法。
（態様５７）
前記第１の画像処理を実行する間隔が動的に変化する態様４３に記載の情報処理方法。
（態様５８）
前記第１の画像処理の結果に応じて、前記間隔を可変に設定する間隔設定制御ステップを含む態様５７に記載の情報処理方法。
（態様５９）
前記第１の画像処理を実行する間隔に応じて、前記第１の画像処理に要する時間が変化する態様４３に記載の情報処理方法。
（態様６０）
前記間隔に応じて、前記イメージセンサが画像の取得を行うことができない第３状態と、前記イメージセンサが画像の取得を行うことが可能な第４状態とを切り換えるのに要する時間を示す切換時間を可変に設定する切換時間設定ステップを含む態様５９に記載の情報処理方法。
（態様６１）
前記第２状態に遷移する際に、前記第１の画像処理に使用されるキャッシュメモリに対する電力の供給を継続するか否かを判定するキャッシュ電源判定制御ステップを含む態様４５に記載の情報処理方法。
（態様６２）
前記キャッシュ電源判定制御ステップは、前記第１の画像処理を実行する間隔が閾値よりも長い場合は、前記キャッシュメモリに対する電力の供給を停止すると判定し、前記第１の画像処理を実行する間隔が前記閾値以下の場合は、前記キャッシュメモリに対する電力の供給を継続すると判定する態様６１に記載の情報処理方法。
（態様６３）
前記第１の画像処理を実行する場合の主記憶装置へのアクセス頻度は、前記第２の画像処理を実行する場合に比べて少ない態様４３に記載の情報処理方法。
（態様６４）
前記第１画像処理ステップは、前記第１の画像処理に利用されるデータの少なくとも一部を保存する、前記主記憶装置とは異なる内部メモリに保存されたデータを用いて前記第１の画像処理を実行する態様６３に記載の情報処理方法。
（態様６５）
前記イメージセンサ制御ステップで取得する、前記第１の画像処理に用いられる画像が、時間の経過とともに変化する態様４３に記載の情報処理方法。
（態様６６）
学習期間内に繰り返し実行された前記第１の画像処理の結果に基づいて、前記イメージセンサから取得可能な全体画像を構成する複数のサブ領域ごとに、変化が検出された回数を対応付けた統計情報を生成する統計情報管理ステップを含み、前記第１画像処理ステップは、前記全体画像のうち、変化が検出された回数が閾値以上の前記サブ領域の画像を前記イメージセンサ制御ステップで取得させ、その取得させた画像を用いて前記第１の画像処理を実行する態様６５に記載の情報処理方法。
（態様６７）
前記第１の画像処理の開始前に、前記第１の画像処理に利用されるデータをプリロードするプリロードステップを含む態様４３に記載の情報処理方法。
（態様６８）
マイコンが、前記第１画像処理ステップを実行する態様４３に記載の情報処理方法。
（態様６９）
前記イメージセンサが、前記第１画像処理ステップを実行する態様４３に記載の情報処理方法。
（態様７０）
前記第１画像処理ステップでは、前記イメージセンサ制御ステップで取得させた画像が、前記情報処理装置が取得可能な画像であるか否かを判断する処理を行う態様６９に記載の情報処理方法。
（態様７１）
前記第２の画像処理を、前記情報処理装置とは異なる第２の情報処理装置に実行させるオフロード制御ステップを含む態様４３に記載の情報処理方法。
（態様７２）
前記情報処理装置が有するデバイスが定期的に実行する処理と、前記第１の画像処理の実行タイミングとを同期させる同期設定部を備える態様４３に記載の情報処理方法。
（態様７３）
前記デバイスは表示装置であり、前記デバイスが定期的に実行する処理は、表示内容を保持するためのリフレッシュ処理である態様７２に記載の情報処理方法。
（態様７４）
電力を蓄える蓄電部の残量に応じて、前記第１の画像処理の方法を切り替える切替制御ステップを含む態様４３に記載の情報処理方法。
（態様７５）
イメージセンサを制御するイメージセンサ制御ステップと、前記イメージセンサ制御ステップで前記イメージセンサから取得した画像を用いて、第１の画像処理の実行の可否を決定するための画像処理であって、前記第１の画像処理よりも消費電力が少ない第２の画像処理を実行する第１画像処理ステップと、を含む情報処理方法。

１ 情報処理装置
１０ ＳｏＣ
２０ 電源装置
３０ ＰＭＩＣ
４０ ストレージデバイス
５０ メインメモリ
６０ ネットワークデバイス
７０ イメージセンサデバイス
７１ オシレータ
７２ クロック制御部
７３ ＣＭＯＳイメージセンサ
１０１ プロセッサコア
１０２ 内部メモリ
１０３ アクセラレータ
１０４ イメージセンサコントローラ
１０５ メモリコントローラ
１０６ ネットワークコントローラ
１０７ ストレージコントローラ
１０８ バス
１０９ 高周波発振器
１１０ 低周波発振器
１１１ クロック制御モジュール
１１２ 割込みコントローラ
１１３ ＲＴＣ
１１４ キャッシュメモリ
１１５ ＳＩＭＤエンジン
１２０ イメージセンサ管理部
１２１ 第１画像処理部
１２２ 待機状態制御部
１２３ 待機状態電力制御部
１２４ イメージセンサ制御部
１２５ キャッシュ電源制御判定部
１２６ 統計情報管理部
１２７ プリロード部
１３０ 第２画像処理部
１４０ 電力管理部

Claims (6)

1. イメージセンサから入力する第１の画像の変化がない場合は、前記第１の画像の変化を判定する第１の処理を実行しているときの電力よりも低い第１電力で次の前記第１の画像の入力を待ち、
   前記イメージセンサから入力する前記第１の画像は、画像を処理する処理装置内に設けられる内部メモリに格納され、
   前記内部メモリに格納された前記第１の画像の変化を判定する第１の処理の実行中は、前記処理装置外に設けられる主記憶装置に供給される電力は第６電力であり、
   前記第１の画像の変化が検出された場合は、
   前記第２の画像は前記主記憶装置に格納され、前記主記憶装置に供給される電力は、前記主記憶装置にアクセス可能な第７電力であり、
   前記第６電力は前記第７電力よりも小さく、
   前記内部メモリの容量は前記主記憶装置の容量より小さく、
   前記第１の画像の変化がない場合は次の前記第１の画像の入力を第５時間待ち、
   前記第１の画像の変化があった場合は次の前記第１の画像の入力を、前記第５時間よりも短い第６時間待ち、前記第１の画像の変化領域が画像の所定の領域である場合に、前記第１の画像よりも解像度の高い第２の画像を前記イメージセンサから入力し、前記第２の画像を用いた処理を実行し、
   次の前記第１の画像の入力を前記第５時間待つ場合の情報処理装置の電力は第４電力であり、
   次の前記第１の画像の入力を前記第６時間待つ場合の情報処理装置の電力は、前記第４電力よりも高い第５電力である、
   情報処理装置。
2. 次の前記第１の画像の入力を前記第５時間待つ場合は、前記主記憶装置に記憶されるデータの一部を記憶するキャッシュメモリへの電力供給を停止する省電力モードを利用し、
   次の前記第１の画像の入力を前記第６時間待つ場合は、前記キャッシュメモリへの電力供給を停止しない省電力モードを利用する、
   請求項１に記載の情報処理装置。
3. 次の前記第１の画像の入力を前記第５時間待つ場合は、キャッシュメモリへの電力供給を停止する省電力モードを利用し、
   次の前記第１の画像の入力を前記第６時間待つ場合は、前記キャッシュメモリへの電力供給を停止しない省電力モードを利用し、
   前記第１の処理に背景画像との差分をとる処理がある場合は、主記憶装置に記憶されるデータの一部を記憶する前記キャッシュメモリへ電力供給する、
   請求項１または２に記載の情報処理装置。
4. 次の前記第１の画像の入力を前記第５時間待つ場合は、前記主記憶装置に記憶されるデータの一部を記憶するキャッシュメモリへの電力供給を停止する省電力モードを利用し、
   次の前記第１の画像の入力を前記第６時間待つ場合は、前記キャッシュメモリへの電力供給を停止しない省電力モードを利用し、
   ウェアラブル機器である前記情報処理装置を装着したユーザが動いている場合は前記キャッシュメモリへの電力供給を停止する、
   請求項１乃至３のうちの何れか１項に記載の情報処理装置。
5. 前記第２の画像を用いた処理を実行するアプリケーションから前記第１の処理を分離してオペレーティングシステムのカーネル内で実行する、
   請求項３または４に記載の情報処理装置。
6. 前記第２の画像を用いた処理で必要とする鮮明な画像を取得するのに必要な時間よりも短い時間で取得できる画像であって、前記第２の画像を用いた処理では前記イメージセンサから入力され破棄される不鮮明な画像を、前記第１の処理に用いる前記第１の画像として利用する、
   請求項５に記載の情報処理装置。

Images