JP2013197608A - 電子カメラ - Google Patents

Abstract

【課題】 本発明は、高ピクセルレートの撮像センサを使用する場合、低コストで汎用性の高いカメラシステムの構築が可能な電子カメラを提供する。
【解決手段】 電子カメラは、撮像部、フロントエンジン、バックエンジンを備える。撮像部は画像データを出力する。フロントエンジンは、第１の入力撮像インターフェース、ピクセルレート低減手段及び出力撮像インターフェースを有する。第１の入力撮像インターフェースは、画像データを受信する。ピクセルレート低減手段は、ピクセルレートを下げる。出力撮像インターフェースは、画像データを出力する。バックエンジンは、第２の入力撮像インターフェース、画像処理手段及び撮影シーケンス制御手段を有する。第２の入力撮像インターフェースは、画像データを受信する。画像処理手段は画像処理を施す。撮影シーケンス制御手段は、フロントエンジンにコマンドを送信し、フロントエンジンは、コマンドを受信して動作を制御する。
【選択図】 図１

Description

本発明は、電子カメラに関する。

従来から、高速な静止画の連写を可能にするため、特許文献１のような電子カメラが提案されている。この電子カメラは、ＹＣＣ（YCrCb）変換処理とＪＰＥＧ（Joint Photographic Experts Group）圧縮処理を行うバックエンジンを複数備えており、連写で得られた一連の画像をこれらのバックエンジンが分担して処理することにより高速化を実現している。

更に、上述した一連の画像にそれぞれ補正処理を施して、この補正された画像を複数のバックエンジンに分配する役割を持つフロントエンジンをも備えており、このフロントエンジンとバックエンジンとの両方でカメラシステムを構成する。

特開２００８−２１９３１９号公報

しかし、上記の電子カメラでは、一例として１０Ｍ画素を超えるフル解像度の画像を60fps以上の速度で読み出すような超Highピクセルレート（以下「高ピクセルレート」という。）の撮像センサを使用するようなカメラシステムについては言及されていなかった。

尚、上記の高ピクセルレートとは、そのまま画像データがバックエンジンに転送された場合、バックエンジン側で受信できなくなる（正常に画像処理ができなくなる）程度のピクセルレートをいう。

そこで、高ピクセルレートの画像データをバックエンジン側で受信できるようにするためには、回路構成が大規模且つ複雑になる等してコストも増加するという新たな問題が生じてしまう。従って、従来のタイプのバックエンジンをなるべく利用できることが望ましい。

また、特許文献１では、高ピクセルレートの撮像センサを使用する場合、フロントエンジンとバックエンジンとの間での撮影シーケンスを工夫することにより、汎用性の高いカメラシステムを構築するといった観点について言及されていなかった。

そこで、本発明は、上述した課題に鑑みてなされたものであり、高ピクセルレートの撮像センサを使用する場合、低コストで汎用性の高いカメラシステムの構築が可能な電子カメラを提供することを目的としている。

第１の発明に係る電子カメラは、撮像部と、フロントエンジンと、バックエンジンとを備える。撮像部は、被写体像を撮像して画像データを出力する。フロントエンジンは、第１の入力撮像インターフェース、ピクセルレート低減手段、及び出力撮像インターフェースを有する。第１の入力撮像インターフェースは、撮像部と電気的に接続することにより画像データを受信する。ピクセルレート低減手段は、受信した画像データの容量に応じてその画像データのピクセルレートを下げる。出力撮像インターフェースは、ピクセルレートの低減された画像データを出力する。バックエンジンは、第２の入力撮像インターフェース、画像処理手段及び撮影シーケンス制御手段を有する。第２の入力撮像インターフェースは、出力撮像インターフェースと電気的に接続することによりピクセルレートの低減された画像データを受信する。画像処理手段は、ピクセルレートの低減された画像データに画像処理を施す。撮影シーケンス制御手段は、撮影シーケンスを制御する。撮影シーケンス制御手段は、フロントエンジンに撮影シーケンスのコマンドを送信し、フロントエンジンは、コマンドを受信して、撮像部の撮像と画像データの読み出しとの少なくとも一方の動作を制御する。

第２の発明は、第１の発明において、フロントエンジンを抽象化し、撮像部と合わせて仮想的な撮像手段として動作させるソフトウェアインターフェースと、撮影シーケンス制御手段上で実行される画像撮影用ソフトウェアとをさらに備える。画像撮影用ソフトウェアは、ソフトウェアインターフェースを呼び出すことにより、仮想的な撮像手段を制御して画像の撮影を行う。

第３の発明は、第２の発明において、ソフトウェアインターフェースは、仮想的な撮像手段に被写体の撮像を行わせる第１のＡＰＩ（Application Programming Interface）と、撮像により取得された画像データを仮想的な撮像手段に出力させる第２のＡＰＩとを有する。画像撮影用ソフトウェアは、第１のＡＰＩと第２のＡＰＩとを順次呼び出すことにより画像の撮影を行う。

第４の発明は、第３の発明において、フロントエンジンは、画像データを記憶する記憶手段を有する。第１のＡＰＩは、仮想的な撮像手段による被写体の撮像から、フロントエンジンの記憶手段に画像データを記憶するまでの動作を行う。第２のＡＰＩは、記憶手段に記憶された画像データをバックエンジンに出力するまでの動作を行う。

第５の発明は、第４の発明において、画像撮影用ソフトウェアは、第１のＡＰＩを続けて呼び出して連写を行う。第２のＡＰＩは、連写によってフロントエンジンの記憶手段に蓄積された複数の画像データを、撮像順とは異なる順序で出力させてバックエンジンに処理させる。

本発明によれば、高ピクセルレートの撮像センサを使用する場合、低コストで汎用性の高いカメラシステムの構築が可能な電子カメラを提供できる。

第１実施形態の電子カメラの構成例を示すブロック図 フロントエンジン１２及びバックエンジン１３の内部構成を説明する図 静止画撮影時の画像データの流れを示す図 第２実施形態の電子カメラの構成例を示すブロック図 電子カメラ２のフロントエンジン１２及びバックエンジン１３の内部構成例を説明する図 第３実施形態の電子カメラのフロントエンジン１２及びバックエンジン１３の構成例を示すブロック図 従来の電子カメラで利用されるソフトウェアの構造の一例を示す図 仮想撮像回路を説明する図 電子カメラ１のソフトウェアの構造の一例を示す図 電子カメラ５０のブロック図の一例を示す図 バックエンジン５１の画像処理回路５１ａの構成例を示すブロック図 電子カメラ５０におけるライブビュー動作時の画像データの流れを示す図 電子カメラ５０における静止画撮影時の画像データの流れを示す図 バックエンジン５１の画像処理回路５１ａの他の形態を示すブロック図 静止画の短冊分割の処理の一例を説明する図

（第１実施形態）
以下、図面に基づいて本発明の実施の形態を詳細に説明する。尚、本発明の実施の形態の内容の理解を容易にするため、本発明の一実施形態の電子カメラ１の基本的な構成を説明した後、比較例として、フロントエンジンを用いない電子カメラ５０（従来型の電子カメラ）の構成及び動作について説明する。特に、電子カメラ５０では、画像の撮影における基本的な処理や画像データの流れについて説明する。これらの説明を踏まえた上で、電子カメラ１の詳細な構成及び動作について説明する。これにより、電子カメラ１と電子カメラ５０との差異点を明確にする。

＜電子カメラ1の構成＞
図１は、第１実施形態の電子カメラの構成例を示すブロック図である。電子カメラ１は、撮影光学系１０と、撮像回路１１と、フロントエンジン１２と、バックエンジン１３と、ＤＲＡＭ（Dynamic Random Access Memory）１４と、ＤＲＡＭ１５と、Flash−ROM（Read Only Memory)１６（図では「Flash」と表記する。）と、ＬＣＤ（Liquid Crystal Display）パネル１７と、レリーズ釦１８と、コネクタＣ１と、コネクタＣ２とを備える。

電子カメラ１は、フロントエンジン１２及びバックエンジン１３を中心に撮像回路１１を始めとする周辺ハードウェアから成る。フロントエンジン１２とバックエンジン１３とは、それぞれ１つのLSI(SoC：System on Chip)として実装される。尚、「フロントエンジン」と「バックエンジン」とは、特許文献１で使われた名称であるが、以下の説明においてもこの名称をそのまま用いる。但し、同じ名称を用いていてもフロントエンジン１２とバックエンジン１３の内部構成は、特許文献１と大きく異なる。特許文献１と違って、本実施形態のバックエンジン１３は、それ１つでも画像処理の行える最小限のカメラシステムを構成することができ、機能的にはメインエンジンと呼ぶべきものである。

撮影光学系１０は、焦点距離を調整するズームレンズと、撮像回路１１内の撮像センサの受光面での結像位置を調整するフォーカスレンズとを含む複数のレンズ群で構成されている。尚、簡単のため、図１では、撮影光学系１０を１枚のレンズとして図示する。

撮像回路１１は、撮像センサ（ＣＭＯＳ（Complementary Metal Oxide Semiconductor）センサ、またはＣＣＤ（Charge Coupled Device）センサ）の他にＴＧ（Timing Generator）センサやＡＦＥ（Analog Front End）等から成る。尚、撮像回路１１は、ＴＧとＡＦＥとを内蔵したＣＭＯＳセンサを採用しても良い。

画像の撮影時には、先ず、撮影光学系１０によって被写体の光学像（被写体像）が撮像センサ上に形成される。次いで、この被写体像が撮像センサによって光電変換(露光)され、最後にデジタルの画像データとなって撮像回路１１から出力される。撮像センサの受光面には、例えばBayer配列のカラーフィルタ(CFA：Color Filter Array)が設けられている。この場合、Bayer配列からなるカラーのデジタルの画像データが撮像回路１１から出力される。露光や画像データの出力といった撮像回路１１の制御は、少数の制御信号や、シリアル通信ポートによって行われる。

フロントエンジン１２は、高ピクセルレートの撮像センサが出力する画像データをバックエンジン１３で処理するための素子である。フロントエンジン１２は、高ピクセルレートの撮像センサが出力する画像データを一旦受信し、そのピクセルレートを低減してからバックエンジン１３に送信する。

バックエンジン１３は、電子カメラ１の殆どの機能を担う最も重要な素子である。ここで、撮像回路１１からフロントエンジン１２に向かう矢印の部分は、撮像回路１１から出力された画像データが流れることを示しており、実際には、(超)高速のインターフェースで繋がる。

一方、フロントエンジン１２からバックエンジン１３に向かう矢印の部分には、ピクセルレートの低減された画像データが流れるが、ここには、フロントエンジン１２の他に一般的な撮像センサを含む撮像回路１１も繋がる。図中のフロントエンジン１２から撮像回路１１に向かう矢印は、この撮像回路１１を制御するためのシリアル通信ポートや制御信号を表す。

更に、図１には、フロントエンジン１２とバックエンジン１３とを繋ぐ幅広の白矢印もあるが、この白矢印は、フロントエンジン１２とバックエンジン１３との間の通信インターフェースを表しており、例えば、単純なシリアル通信インターフェースでも良い。尚、フロントエンジン１２及びバックエンジン１３の内部構成の詳細については、図２、図５で詳しく説明する。

ＤＲＡＭ１４は、フロントエンジン１２と接続しており、例えば、高ピクセルレートの撮像センサが出力する画像データを一時的に記憶する。ＤＲＡＭ１５は、バックエンジン１３と接続しており、電子カメラ１の様々な処理において画像データを一時的に記憶する他、プログラムで使用する変数の記憶やスタック等に使用される。

Flash−ROM１６には、例えば、電子カメラ１における画像の撮影、画像の再生、PC（パーソナルコンピュータ）等への画像の転送といったカメラの機能を実行するプログラム(カメラファームウェア)が記憶される。また、Flash-ROM１６には、電子カメラ１の各種調整データやユーザ設定情報等も記憶される。

ＬＣＤパネル１７は、例えば液晶表示媒体により構成される。ＬＣＤパネル１７は、画像やGraphicデータ(文字やアイコン等)を表示する。レリーズ釦１８は、半押し操作（撮影前におけるオートフォーカス（ＡＦ）や自動露出（ＡＥ）等の撮影準備の動作開始）と全押し操作（本画像を取得するための撮影の動作開始）との指示入力とを受け付ける。コネクタＣ１は、着脱自在のＵＳＢ（Universal Serial Bus）メモリＵ１を接続するための接続端子である。コネクタＣ２は、着脱自在のカード型の不揮発性のメモリカードＭ１を接続するための接続端子である。図１では、コネクタＣ１に接続された後のＵＳＢメモリＵ１と、コネクタＣ２に接続された後のメモリカードＭ１を示している。

＜電子カメラ５０の構成＞
次に、比較例として、電子カメラ５０の構成について説明する。

図１０は、電子カメラ５０のブロック図の一例を示す図である。電子カメラ５０では、１つのバックエンジン５１を中心に撮像回路５２を始めとする周辺ハードウェアから成る。尚、バックエンジン５１は、バックエンジン１３と同様、１つのＬＳＩとして実装される。

電子カメラ５０は、撮影光学系５５、撮像回路５２、バックエンジン５１、ＤＲＡＭ５３、Flash−ROM５４、ＬＣＤパネル５７、レリーズ釦５６、コネクタＣ３、コネクタＣ４及びバス５１ｒを備える。

撮影光学系５５は、図１に示す撮影光学系１０と同様の構成である。撮像回路５２は、撮像回路１１と同様の構成であるが、高ピクセルレートの画像データを出力しない点が異なる。ＬＣＤパネル５７、レリーズ釦５６は、図１に示すＬＣＤパネル１７、レリーズ釦１８と同様の構成である。コネクタＣ３は、メモリカードＭ２を接続するための接続端子であり、コネクタＣ４は、着脱自在のＵＳＢメモリＵ２を接続するための接続端子である。図１０では、コネクタＣ３に接続された後のメモリカードＭ２を示している。

従来のバックエンジン５１は、電子カメラ５０の殆どの機能を担う最も重要な素子であり、撮像回路５２から出力された画像データに画像処理を施す画像処理回路５１ａ（図では「画像処理」と表記する。）、電子カメラ全般の動作をコントロールするＣＰＵ（Central Processing Unit）５１ｂ、静止画の圧縮を行うＪＰＥＧコーデック５１ｃ（図では「ＪＰＥＧ」と表記する。）、画像やGraphicデータをＬＣＤパネル５７に表示するＬＣＤコントローラ５１ｄ、PC等のホスト機器へ画像データを転送するUSBコントローラ５１ｅ（図では「USB」と表記する。）、ＤＲＡＭ５３へのデータ読み書きを行うＤＲＡＭコントローラ５１ｆ（図では「DRAMC」と表記する。）、Flash-ROM５４へのデータ読み書きを行うStaticメモリコントローラ５１ｇ（図では「SMC」と表記する。）、周辺デバイスとの間でデータや信号をやり取りするSIO（Serial Input/Output）＆PIO（Parallel Input/Output）５１ｈ、メモリカードＭ２へのデータ読み書きを行うCARDコントローラ５１ｉ等を内部に含む（図１０参照）。

尚、画像処理回路５１ａ、ＣＰＵ５１ｂ、ＪＰＥＧコーデック５１ｃ、ＬＣＤコントローラ５１ｄ、USBコントローラ５１ｅ、ＤＲＡＭコントローラ５１ｆ、Staticメモリコントローラ５１ｇ、及びSIO＆PIO５１ｈは、バス５１ｒを介して互いに接続されている。

また、図示されてはいないがバックエンジン５１には、その他として、いわゆるH.264等の動画コーデック、画像データの転送を行うＤＭＡコントローラ(DMAC)、割り込みコントローラ、A/D変換器、タイマー等も含まれる（バックエンジン１３も同様とする）。画像の撮影、画像の再生、PC等への画像の転送といった電子カメラ５０の機能は、ＣＰＵ５１ｂが実行するプログラム(カメラファームウェア)として実装され、そのプログラムは、Flash-ROM５４に記憶される。Flash-ROM５４には、電子カメラ５０の各種調整データやユーザ設定情報等も記憶される。ＤＲＡＭ５３は、電子カメラ５０の様々な処理において画像データを一時的に記憶する他、プログラムで使用する変数の記憶やスタック等に使用される。

図１０では、これらの制御信号や通信ポートがバックエンジン５１内から撮像回路５２に向かう１本の矢印で表されており、バックエンジン５１は、これらを駆使して撮像回路５２を制御し画像の撮影を行う。撮像回路５２から出力された画像データは、バックエンジン５１の画像処理回路５１ａに入って様々な画像処理が施される。ここで、この画像処理は、一般にプリプロセス(Pre-Process)とポストプロセス(Post-Process)の２つに大きく分けられる。撮影時の画像処理がこの２つの処理に明確に分かれる場合があるからである。

プリプロセスは、撮像センサのバラツキ等を補正する処理が主体であり、特許文献１でフロントエンジンの信号処理手段が行っている補正処理に対応する。具体的には、プリプロセスは、欠陥画素補正(DPC：Defect Pixel Correction)、OB（Optical Black）クランプ、シェーディング補正、感度補正等の処理を行う。プリプロセスには、その他にノイズ除去や一部のレンズ収差を補正する処理が含まれたりする。

これらの補正処理とは別にプリプロセスは、３種類の評価値を抽出する３Ａ検波の機能も持つ。この３Ａ検波の機能は、AE(Automatic Exposure)、AF(Automatic Focusing)、AWB(Automatic White Balance)のための各評価値を抽出するものである。電子カメラ５０は、各評価値に基づいて、自動露出(AE)、自動焦点調整(AF)、自動ホワイトバランス調整(AWB)の制御を行う。

一方、ポストプロセスは、カラー処理が主体であり、特許文献１でバックエンジンが行っているYCC変換/解像度変換の処理に対応する。その意味から、カラープロセス(Color Process)と称しても良い。具体的には、ポストプロセスは、WB調整、色補間、色空間変換、γ補正、YCC変換、偽色除去、エッジ強調、解像度変換等の処理を行う。

プリプロセスが施された後でも画像データは、未だ１色/pixelのBayer配列データであるが、ポストプロセスが施された後では、３色/pixelのYCbCrデータに変わっている。このYCbCrデータは、表示や印刷に利用できる画像データである。JPEG(静止画)やH.264(動画)等の画像圧縮でもこのYCbCrデータが利用される。

画像処理回路５１ａは、プリプロセスを行うプリプロセス回路とポストプロセスを行うポストプロセス回路（不図示）から成る。ここで、画像処理の動作には、このプリプロセス回路とポストプロセス回路とを直結して２つの処理を一体的に行う１ステップ処理と、プリプロセスの施された１フレーム分の画像データを一旦ＤＲＡＭ５３に記憶し、次いで、その画像データをＤＲＡＭ５３から読み出してポストプロセスを施すという２ステップ処理の２つがある。これらの動作を行う画像処理回路５１ａの内部構成と、その画像データの流れを図１１に示す。

図１１は、バックエンジン５１の画像処理回路５１ａの構成例を示すブロック図である。撮像回路５２から出力された画像データを受信するため、画像処理回路５１ａの前には、入力撮像インターフェース(SIFi)５１ｊ（図では「SIFi」と表記する。）が設けられている。「SIFi」は「Sensor InterFace」と「Input」の文字を組み合わせたものである。撮像回路５２側には、不図示の出力撮像インターフェースがあり、この出力撮像インターフェースから出力された画像データを入力撮像インターフェース５１ｊが受信する構図になる。

入力撮像インターフェース５１ｊは、入力信号から有効画素領域やOB領域のデータを取り出すための処理を行い、それらのデータを後方の画像処理回路５１ａに送っている。画像処理回路５１ａは、先頭にプリプロセス回路５１ｋ（図では「PreProc」と表記する。）が置かれており、プリプロセス回路５１ｋの後方には、２つの入力データの一方選択して出力するセレクタ(Sel)５１ｍ（図では「Sel」と表記する。）が置かれ、セレクタ５１ｍの後方には、ポストプロセス回路(PostProc)５１ｎ（図では「PostProc」と表記する。）が置かれる構造をしている。

プリプロセス回路５１ｋの出力は、２つあり、第１の出力がセレクタ５１ｍの第１の入力に繋がり、第２の出力がＤＲＡＭ５３に繋がる(正確には、図１０に示すDRAMC５１ｆの入力ポートに繋がる)。一方、セレクタ５１ｍの第２の入力は、ＤＲＡＭ５３に繋がり(正確にはDRAMC５１ｆの出力ポートに繋がる)、このセレクタ５１ｍの出力が、ポストプロセス回路５１ｎの入力に繋がり、最後にポストプロセス回路５１ｎの出力がＤＲＡＭ５３に繋がる(正確にはDRAMC５１ｆの入力ポートに繋がる)。

画像処理回路５１ａが１ステップ処理を実行する場合には、プリプロセス回路５１ｋの第１の出力から出力される画像データがセレクタ５１ｍによって選択され、その画像データがポストプロセス回路５１ｎに直接入力されるように設定される。入力撮像インターフェース５１ｊから送られてきた画像データは、プリプロセス回路５１ｋに入って先ずプリプロセスが施され、次いで、その画像データ(Bayer)は、プリプロセス回路５１ｋから出力されてセレクタ５１ｍを通り、更にポストプロセス回路５１ｎに入ってポストプロセスが施される。

ポストプロセスが施された画像データ(YCbCr)は、ポストプロセス回路５１ｎから出力されてＤＲＡＭ５３上に設けられたYCbCrバッファ５３ａに記憶される(図１１参照)。

一方、２ステップ処理を行う場合には、入力撮像インターフェース５１ｊから送られてきた画像データは、セレクタ５１ｍの第２の入力データが選択されてポストプロセス回路５１ｎに入るように設定される。この設定の場合には、ＤＲＡＭ５３から読み出された画像データは、ポストプロセス回路５１ｎに入力され、ポストプロセスが施される。

２ステップ処理の全体の動作は、以下のようになる。先ず、入力撮像インターフェース５１ｊから送られてきた画像データがプリプロセス回路５１ｋに入力され、プリプロセスが施される。そして、プリプロセスが施された画像データ(Bayer)は、プリプロセス回路５１ｋの第２の出力から出力されて一旦ＤＲＡＭ５３上に設けられたＲＡＷバッファ５３ｄに記憶される(図１１参照)。これが１ステップ目の処理である。ＲＡＷデータを記録する機能を持つ電子カメラ５０の場合には、このＲＡＷバッファ５３ｄに記憶されたBayerデータを記録するのが普通である。

次いで、プリプロセスが施されたBayerデータは、ＲＡＷバッファ５３ｄから読み出されてセレクタ５１ｍを通り、更にポストプロセス回路５１ｎに入ってポストプロセスが施される。ポストプロセスが施されたYCbCrデータは、ポストプロセス回路５１ｎから出力されてＤＲＡＭ５３上に設けられたYCbCrバッファ５３ａに記憶される(図１１参照)。これが２ステップ目の処理である。

画像処理の動作が、この様に２種類あるのは、処理結果であるYCbCrデータの横サイズに起因する。大まかに言うとYCbCrデータの横サイズが予め設定した値より小さい場合、画像処理回路５１ａは、１ステップ処理、横サイズが大きい場合（予め設定した値以上）、２ステップ処理を行うことになる。この画像処理の動作は、撮影時の電子カメラ５０の撮影動作にも関係が深いので、次に、図１０に示す電子カメラ５０の撮影動作について説明する。

＜電子カメラ５０の撮影動作＞
本実施形態では、ライブビューを重視しているため、電子カメラ５０におけるライブビューを利用した撮影動作を例に挙げて説明する。

画像の撮影時(撮影モード)には、電子カメラ５０が先ずライブビューの動作に入る。ライブビューの動作では、撮像回路５２を連続出力モードに設定し、30fpsや60fpsのフレームレートで撮像（露光）と画像データの出力を繰り返す。ライブビューでは、撮影者が被写体の生映像をＬＣＤパネル５７で見ながら撮影の構図を決めたり、自動露出(AE)のための測光演算や自動焦点調整(AF)を電子カメラ５０側で行ったりする。

電子カメラ内蔵のＬＣＤパネル５７は、VGA(640×480)程度のものが多く、ＬＣＤパネル５７に表示する生映像(スルー画像)のYCbCrデータもその程度で済む。スルー画像は、記録画像よりも画像サイズが小さいので、ライブビューでは、１ステップ処理を用いる。具体的には、ライブビューでは、撮像回路５２から連続的(例えば30fps或いは60fps)に出力された画像データを画像処理回路５１ａに入力し、その画像処理回路５１ａは、１ステップ処理を行ってスルー画のYCbCrデータを生成する。このスルー画のデータは、一旦ＤＲＡＭ５３上のYCbCrバッファ５３ａに記憶され、次いで、スルー画のデータが読み出されてＬＣＤコントローラ５１ｄに送られＬＣＤパネル５７に表示される。この動作を毎フレーム繰り返すことで被写体の生映像を見ることができる。この時の画像データの流れを図１２に示す。

＜電子カメラ５０の画像データの流れ＞
図１２は、電子カメラ５０におけるライブビュー動作時の画像データの流れを示す図である。図１２では、プリプロセス回路５１ｋとポストプロセス回路５１ｎを１つにまとめて画像処理回路５１ａとして表しているが、その内部は、図１１のようになっている。
ライブビュー中、プリプロセス回路５１ｋは、適宜３Ａ検波を行って３Ａバッファ５３ｂから３Ａ評価値を抽出する。

図１２では、この３Ａ評価値がＤＲＡＭ５３上の３Ａバッファ５３ｂに記憶されている。３Ａ評価値は、プリプロセス回路５１ｋ内の３Ａ検波回路から出力されるので、少し詳しく描くと図１１のようになる。プリプロセス回路５１ｋは、この３Ａ評価値に基づいて輝度調整(AE)や、焦点調整(AF)や、ホワイトバランス調整(AWB)を行う。これによってスルー画の明るさと色が適切に保たれる。

測光演算では、静止画撮影の露光条件も計算される。尚、３Ａ評価値の中でデータ量の少ないものは、その検波回路内のSRAM（Static Random Access Memory）に記憶する方がＣＰＵ５１ｂからの読み出しが速くなって有利である。プリプロセスでは、欠陥画素補正が行われるが、この欠陥画素の位置(アドレス)を記憶した欠陥画素テーブル５３ｃがＤＲＡＭ５３上に置かれる。プリプロセス回路５１ｋ内の欠陥画素補正回路（不図示）は、この欠陥画素テーブル５３ｃの情報を読み出し、その位置の画素が到着したらその周囲の画素から計算された補正値に置き換える処理を行う。

このデータの流れを図１１と図１２に示す。１ステップ処理では、ポストプロセスまで一気に処理されるため、スルー画のYCbCrデータが生成される際のレイテンシが小さい。これにより撮影時のレリーズタイムラグが短縮されるメリットが生まれる。また、１ステップ処理では、画像処理の中間データをＤＲＡＭ５３に記憶することもないのでＤＲＡＭ５３のアクセスが少なく、その分、ＤＲＡＭ５３の帯域を余り占有しないで済むメリットもある。このライブビューの動作は、静止画撮影モードの場合も、動画撮影モードの場合も余り変わらない。ライブビュー中にレリーズ釦５６が全押しされるとその時の撮影モードに応じて静止画撮影や動画撮影の動作に移る。

＜静止画撮影の動作＞
次に、電子カメラ５０の静止画撮影の動作について説明する。図１０に示すレリーズ釦５６が全押しされた時には、その前に半押しが検出されるので焦点調整(AF)が先に行われ、それが完了すると静止画の撮影動作に移るステップを経る。静止画撮影動作に移ると直前に行われた測光演算を基に被写体の自動露出(AE)が行われる。目標の露光量に達すると露光が終了し、次いで、撮影された静止画の画像データ（以下「静止画データ」という。）が撮像回路５２から出力される。

図１３は、電子カメラ５０における静止画撮影時の画像データの流れを示す図である。この画像データは、図１３に示す通り、バックエンジン５１の入力撮像インターフェース５１ｊで受信され、次いで、画像処理回路５１ａに入る。撮影された静止画は、一般的に解像度がスルー画等の動画と比較して大きいので、画像処理回路５１ａは、２ステップ処理を実行する。その理由を以下に説明する。ポストプロセスは、２次元的なフィルタ処理を幾つも含むが、１枚の画像をプログレシブ走査によって処理していくには、それぞれのフィルタ回路が垂直タップ数分のラインメモリを持たなければならず、回路規模が増大する問題があった。

中には、タップ数の多いフィルタ回路もあり、それが図１１に示すポストプロセス回路５１ｎの肥大化を加速させている。スルー画に比べて１枚の巨大な画像（例えば５０Mの容量）を１回で処理するには、その画像の横サイズ分の記憶容量を持つラインメモリが必要であるが、そのような大容量のラインメモリをフィルタ回路毎にそのタップ数分だけ持つことは困難になっている。

そこで、回路規模を抑えるには、（Ａ）フィルタ回路の数やタップ数を減らす、（Ｂ）ラインメモリ１本当たりの記憶容量を減らす等の方法が考えられる。条件（Ａ）の方法は、画質に影響し、条件（Ｂ）の方法は、１回で処理できる画像の大きさに影響する。画質を重視するのであれば、ラインメモリの記憶容量を減らすことになるが、その場合には、高解像度の画像をどのように処理するかが問題となる。この点については、第２実施形態の電子カメラ２の説明の際、後述する。

＜静止画の画像処理の詳細について＞
次に、図１３を基に静止画の画像処理をもう少し具体的に説明する。撮像回路５２から出力された画像データは、バックエンジン５１の入力撮像インターフェース５１ｊで受信され、次いで、画像処理回路５１ａに送られてプリプロセスが施され、更に画像処理回路５１ａから出力されて一旦図中のＲＡＷバッファ５３ｄに記憶される。この時、画像処理回路５１ａは、ライブビューと同様に欠陥画素テーブル５３ｃの情報が読み出す。

但し、撮像回路５２から出力される画素数がライブビューと静止画撮影とで異なる場合には、画像処理回路５１ａは、欠陥画素のアドレスも変わってくるので２つのテーブルを用意しておき使い分ける。図１３中、撮像回路５２から出て入力撮像インターフェース５１ｊを通り、次いで、画像処理回路５１ａを経由してＲＡＷバッファ５３ｄに向かう矢印が、静止画データの流れを表し、欠陥画素テーブル５３ｃから画像処理回路５１ａに向かう矢印の方が欠陥画素情報の流れを表す。この部分をもう少し詳しく示したものが図１１である。

図１１に示す通り、静止画データは、「撮像回路５２→入力撮像インターフェース５１ｊ→プリプロセス回路５１ｋ→ＲＡＷバッファ５３ｄ」と流れ、欠陥画素情報は「欠陥画素テーブル５３ｃ→プリプロセス回路５１ｋ」と流れる。これが１ステップ目の処理である。

続く２ステップ目では、ポストプロセス回路５１ｎは、短冊分割に基づいて、ポストプロセスを実行する。ここで、短冊分割について説明する。

図１５は、静止画の短冊分割の処理の一例を説明する図である。図１５に示す方法により、ポストプロセス回路５１ｎは、大きな画像も処理することができる。つまり、ポストプロセス回路５１ｎは、１枚の大きな画像を図の中の（１）、（２）、（３）のように横サイズの小さな短冊状の部分画像に分割し、この短冊画像を１つずつ処理してＤＲＡＭ５３上で繋ぎ合わせ１枚の画像３１を完成させる。

短冊画像は、横サイズが小さいのでフィルタ回路のラインメモリも小容量で済む。１本のラインメモリの記憶容量から処理可能な短冊画像の横サイズが決まるので、ポストプロセス回路５１ｎは、それを基に元の画像を何個の短冊画像に分割するかを決定する。解像度の大きな画像であれば分割される短冊画像の数も増える。１枚の画像の横サイズが１本のラインメモリの記憶容量以下であれば、ポストプロセス回路５１ｎは、短冊分割せずに処理することができる。図中の実線及び点線の矢印は、各短冊画像の画素データの走査順を表している。上述したフィルタ回路では横（水平）方向のフィルタ処理も行われるので、短冊画像の境界部では、ポストプロセス回路５１ｎは、全フィルタ回路の水平タップの合計分だけ画素が重なるように分割する。

図１５では、この重なり部分を示す帯び３２、３３を明示的にそれぞれ表している。全てのフィルタ処理が済むと境界部では、両方の短冊画像からそれぞれ水平タップ数の半分ずつ画素が減るので、処理後の短冊画像は、境界部で良く合って繋がることになる。図中の縦の点線は、短冊画像の繋ぎ目を表している。この重なり部分ではＤＲＡＭ５３から画素のデータが二重(２回)に読み読み出されるため、短冊画像の横サイズを小さくし過ぎると重なり部分が増大してデータの読み出し回数が増え効率が低下する弊害が出る。この短冊分割処理は、ポストプロセスだけで、プリプロセスの方は通常１フレームの画像全体を１回で処理している。

すなわち、ポストプロセス回路５１ｎは、プリプロセスの施されたBayerデータをＲＡＷバッファ５３ｄ上で幾つかの短冊画像に分割し、それらを１つずつ読み出し画像処理回路５１ａに入力してポストプロセスを施し、ポストプロセスの施されたYCbCrデータをYCbCrバッファ５３ａに記憶する。この処理を全ての短冊画像について実行すると、YCbCrバッファ５３ａ上では、画像処理が完了して１つに繋がった画像が出来上がる。

図１３において、ＲＡＷバッファ５３ｄから画像処理回路５１ａを経由してYCbCrバッファ５３ａに向かう矢印がこの時の画像データの流れを表す。これをもう少し詳しく示したものが図１１である。

図１１に示す通り、各短冊画像のBayerデータは、「ＲＡＷバッファ５３ｄ→セレクタ５１ｍ→ポストプロセス回路５１ｎ→YCbCrバッファ５３ａ」と流れる。これが２ステップ目の処理である。

図１３では、ＤＲＡＭ５３上にYCbCrバッファ５３ａが３つ設けられているが、これはポストプロセスで３つの異なるサイズの画像を作成するからである。1つ目は、主たる記録画像である大サイズの主画像、２つ目は、撮影結果確認用の中サイズの表示用画像(フリーズ画)、３つ目は、検索用の小サイズのサムネイル（縮小画像）で、これらは全てYCbCrデータの画像である。ポストプロセス回路５１ｎがこれら３つの画像を並列に作成して出力する機能があると、１回の処理で全ての画像が生成されるので処理時間が短縮される。

そのような機能が無い場合には、シーケンシャルに作成するので時間が掛かる。ポストプロセスでは、一般に短冊分割が行われるので更に低速となる。静止画は、一般に解像度がスルー画に比べて大きいため短冊分割でポストプロセスを実行する必要があり、それがプリプロセスとポストプロセスを分けて行う２ステップ処理の一因になっている。

一方、スルー画は、解像度が静止画に比べて小さいのでライブビューでは、プリプロセスとポストプロセスを一体的に行う１ステップ処理が用いられるが、その時には補助的な処理が必要なこともあるので説明しておく。ライブビューの時に撮像回路５２から出力される画像データは、必ずしも横サイズ（横画素数）が小さいわけではない。撮像センサで画素加算や間引きが行われる場合、出力される画素数も減るが、その場合でも画像の横サイズは、大きいことが多い。

そのため、ライブビューの際に撮像回路５２から横サイズの大きな画像データが出力されると上述したフィルタ回路のラインメモリの記憶容量が超えることがあり、バックエンジン５１では、図１１に示すプリプロセス回路５１ｋから出力された画像データを直接ポストプロセス回路５１ｎに入力してポストプロセスを施すという１ステップ処理ができないことになる。

しかし、ライブビューの場合には、最終的に生成されるスルー画のYCbCrデータの画像サイズが小さいという理由で、１ステップ処理ができなくなる問題が回避される。短冊分割を行うのは、大きな画像サイズのままポストプロセスを施すためであるが、ライブビューの場合には、小さな画像サイズのスルー画を生成するだけなのでポストプロセスの前に横方向の縮小を行っても構わない。

つまり、バックエンジン５１では、ポストプロセス回路５１ｎの前に横方向の画像縮小回路（不図示）を設け、これで短冊分割が不要になるまで横サイズを縮小してから画像データをポストプロセス回路５１ｎに入力する。ポストプロセス回路５１ｎは、短冊分割なしで目標サイズのスルー画像を生成しなければならないので、内部のフィルタ回路は、そのサイズに対応できるだけのラインメモリを持つ必要がある。スルー画のサイズがVGA（640×480）であればその程度のラインメモリを持つことは困難ではない。

尚、ライブビューの際、必要以上のライン数の画像データが撮像回路５２から出力されるのであれば、バックエンジン５１では、横方向の画像縮小回路の他に縦（垂直）方向の画像縮小回路（不図示）を設けると良い。これにより、バックエンジン５１では、不要な画像データをポストプロセス回路５１ｎに流さないで済む。この画像縮小処理は、プリプロセスやポストプロセスにおいて本質的なものではなく、１ステップ処理を行うために設けられた補助的な処理である。

図１１において、バックエンジン５１では、この画像縮小回路を独立に設けても良いが、予めプリプロセス回路５１ｋかポストプロセス回路５１ｎの適切な場所に入れておくこともできる。例えば、プリプロセス回路５１ｋの最後か、ポストプロセス回路５１ｎの先頭に入れておく。ライブビューの時には、ポストプロセス回路５１ｎは、この画像縮小回路を「実行」に設定して１ステップ処理を行い、静止画撮影の時には、ポストプロセス回路５１ｎは、この画像縮小回路を「バイパス」に設定して２ステップ処理を行う。これにより、ポストプロセス回路５１ｎは、それぞれの動作に適した画像処理を行うことができる。

尚、２ステップ処理は、短冊分割でポストプロセスを実行するためであるが、それとは別にもう１つ、２ステップ処理を行う理由がある。それは、最適な自動ホワイトバランス調整(AWB)を行うためである。ポストプロセスにはWB調整も含まれているが、それを実行するには、WBゲイン(WB：White Balance)を設定する必要がある。ポストプロセス回路５１ｎは、AWB評価値を基にWBアルゴリズムを実行してWBゲインを決定するが、これを何時行うかという問題がある。ライブビュー動作時のWBゲインをそのまま使うこともできるが、撮影した静止画の実データに基づいていないという欠点がある。ポストプロセス回路５１ｎは、より適切なAWB調整を行うため、その静止画データから抽出したAWB評価値を基にWBゲインを決定する必要がある。

ここで、３Ａ検波は、プリプロセス回路５１ｋで行われるので、撮像回路５２から出力された静止画データにプリプロセスを施す際AWB評価値を抽出する。図１３では、このAWB評価値がＤＲＡＭ５３上のAWBバッファ５３ｆに記憶されている。画像処理回路５１ａから出てAWBバッファ５３ｆに向かう矢印が、このAWB評価値の流れを表す。

尚、静止画の撮影は、完了しているのでAE評価値とAF評価値の抽出は不要である。この部分をもう少し詳しく示したものが図１１であり、AWB評価値は「プリプロセス回路５１ｋ→AWBバッファ(図中の３Ａバッファの１つ)５３ｆ」と流れる。このAWB評価値を基にAWBアルゴリズムが実行されWBゲインが決まる。このWBゲインを図１１のポストプロセス回路５１ｎに設定し、次いで、ポストプロセス回路５１ｎは、図中のＲＡＷバッファ５３ｄからプリプロセスの施されたBayerデータを読み出して、ポストプロセスを施す。

つまり、撮影された静止画データの画像処理は、「(プリプロセス/AWB検波)→AWBアルゴリズム実行→WBゲイン設定→ポストプロセス」の順に行われるため、２ステップ処理が必要となる。以上が、静止画の画像処理の内容である。

＜静止画撮影時の画像処理について＞
次に、静止画撮影時の画像処理について更に説明を続ける。画像処理では、３種類（３つ）の画像（主画像、フリーズ画、サムネイル）が作成されるので、静止画撮影後、撮影結果が確認できるように先ずフリーズ画がＬＣＤパネル５７に表示される。

具体的には、図１０に示すＣＰＵ５１ｂの指示により、不図示のＤＭＡコントローラ(DMAC)は、図１３のYCbCrバッファ５３ａの１つからフリーズ画を読み出し、それを図中のＬＣＤコントローラ５１ｄに送ってＬＣＤパネル５７に表示させる。図１３では、YCbCrバッファ５３ａから出てＬＣＤコントローラ５１ｄを経由し、ＬＣＤパネル５７に向かう矢印がこのフリーズ画の流れを表す。Exif（Exchangeable Image File Format）/DCF規格では、JPEG圧縮された主画像とサムネイルを記録するので、フリーズ画の表示と並行してこれら２つの画像をJPEG圧縮する。フリーズ画を一緒に記録しておくと再生が高速に行われるので、JPEGコーデック５１ｃは、フリーズ画もJPEG圧縮しておくことにする。

最近CIPA（Camera ＆ Imaging Products Association）で規格化されたマルチピクチャフォーマット(MPF)では、主画像とサムネイルの他にフリーズ画に相当する「モニタ表示用画像」が記録できるのでそれを利用しても良い。ＤＭＡコントローラ(DMAC)は、YCbCrバッファ５３ａから画像データ(YCbCr)を読み出し、それを図中のJPEGコーデック５１ｃに入力し、JPEGコーデック５１ｃから出力される圧縮データをＤＲＡＭ５３上のJPEGバッファ５３ｅ（図では「JPEG」と表記する）に記憶していく。図１３では、YCbCrバッファ５３ａから出てJPEGコーデック５１ｃを通り、JPEGバッファ５３ｅに向かう矢印が、この時のデータの流れを表す。

ＤＭＡコントローラ(DMAC)は、この処理を３つの画像について順次実行する。ＤＭＡコントローラ(DMAC)は、３つの画像のJPEG圧縮データをフォーマットに従ってタグ情報と共に１つのJPEGバッファ５３ｅ上に配置し、Exif/DCFのファイルやMPFのファイルのファイルイメージを形成していく。このファイルイメージが完成したら、次に、CARDコントローラ５１ｉは、そのデータをメモリカードＭ１に記録する。つまり、ＤＭＡコントローラ(DMAC)は、JPEGバッファ５３ｅからこのファイルイメージを読み出し、それを図中のCARDコントローラ５１ｉに入力してメモリカードＭ２に記録していく。図１３では、JPEGバッファ５３ｅから出てCARDコントローラ５１ｉを通り、メモリカードＭ２に向かう矢印が、この時のデータの流れを表す。これが終わると静止画のファイルがメモリカードＭ２に保存され撮影が終了する。

以上は、１枚の静止画を撮影する場合(単写)の処理であるが、単純にこれを繰り返しても高速な連写とはならない。撮影した静止画がメモリカードＭ２に記録されるまで、撮像回路５２は、次の撮影に入らないからである。

静止画撮影の動作は、（I）露光/画像データ出力/プリプロセス、（II）ポストプロセス、（III）フリーズ画表示/JPEG圧縮、（IV）メモリカードＭ２への記録からなる４つの処理に大別されるが、これらを並列に実行すれば高速に連写を行うことができる。（I）の処理では、撮像回路５２とプリプロセス回路５１ｋとが使われ、（II）の処理では、ポストプロセス回路５１ｎが使われ、（III）の処理では、ＬＣＤコントローラ５１ｄとＬＣＤパネル５７とJPEGコーデック５１ｃが使われ、（IV）の処理では、CARDコントローラ５１ｉとメモリカードＭ２が使われるが、それぞれの処理で使われるリソースは競合していないことが分かる。

従って、バックエンジン５１は、これらの処理を並列に実行することができる。並列処理が行われるには更に条件（Ａ）、（Ｂ）があって、具体的には、（Ａ）処理前のデータ(ソース・データ)が用意されていること、（Ｂ）処理後のデータを記憶するバッファメモリが空いていることの２つである。

例えば、ＲＡＷバッファ５３ｄからプリプロセスの施されたBayerデータを読み出してポストプロセスを施している間は、ＲＡＷバッファ５３ｄが空いていないので、次のコマの静止画を撮影してプリプロセスの施されたBayerデータをそこに記憶することはできない。同じく、バックエンジン５１では、YCbCrバッファ５３ａから主画像を読み出してJPEG圧縮を施している間、YCbCrバッファ５３ａが空いていないので、次のコマの主画像を作成してそこに記憶することはできない。

逆に、前のコマの処理が早く終了してバッファメモリが空いていても、次のコマのソース・データが用意されていない時には、バックエンジン５１では、その処理を実行することができない。つまり、バックエンジン５１では、条件（Ａ）、（Ｂ）が満たされている間、４つの処理（I）〜（IV）を並列に実行し、満たされない条件が出てきた時には、それに対応する処理を停止する動作になる。これらの条件ができるだけ満たされるようにするには、図１３のＲＡＷバッファ５３ｄ、YCbCrバッファ５３ａ、JPEGバッファ５３ｅをそれぞれ２つ用意すると良い。

つまり、バックエンジン５１では、JPEGバッファ５３ｅに記憶された1コマ目のファイルイメージを読み出してメモリカードＭ２に記録しつつ、それと並行してYCbCrバッファ５３ａに記憶された２コマ目の３つの画像(主画像、フリーズ画及びサムネイル)をJPEG圧縮して別のJPEGバッファ５３ｅに記憶する。それと並行して、バックエンジン５１では、ＲＡＷバッファ５３ｄに記憶され３コマ目のBayerデータにポストプロセスを施して別のYCbCrバッファ５３ａに記憶し、それと並行して４コマ目の静止画データにプリプロセスを施して別のＲＡＷバッファ５３ｄに記憶する並列処理が可能になる。

上記の（I）及び（II）の処理は、ＲＡＷバッファ５３ｄ、上記の（II）及び（III）の処理は、YCbCrバッファ５３ａ、上記の（III）及び（IV）の処理はJPEGバッファ５３ｅをそれぞれ共有しているので、これらを並列に実行する時には、バックエンジン５１では、各処理が必ず異なるバッファを使用するよう排他制御を行う。１コマの処理が終わる度に各処理が２つバッファを入れ換えるようにすれば、この並列処理(連写)を継続して続けることができる。

ここで、４つの処理（I）〜（IV）が並列に実行されている時には、バッファメモリに空きがなく、何れかの処理が早く終了しても次のコマの処理に入ることはできない。一方、上述した４つの処理（I）〜（IV）の処理時間が極端に異なる場合、バックエンジン５１では、早く終了した処理が他の処理が終わるのを待つので効率的な並列処理ができない。

従って、処理時間ができるだけ近接するように工夫する。例えばポストプロセスで３つの画像を並列に作成するとか、JPEGコーデック５１ｃを２つ持って符号量制御(Bit Rate Control)に掛かる時間を短縮するとか等の工夫を行う。多くの場合、ＲＡＷバッファ５３ｄとYCbCrバッファ５３ａとを２つずつ設けると共に、JPEGバッファ５３ｅは、例えば５つ設ける。JPEGバッファ５３ｅには、圧縮されたデータが記憶されるので容量が少なく、それを少し多目に設けることは比較的容易である。

尚、メモリカードＭ２は、着脱式であるため、書込速度の遅いメモリカードが使用された時には、連写のコマ速に影響する。JPEGバッファ５３ｅの数が多いと前のコマの記録が終わるのを待たずに次のコマの圧縮データをそこに蓄積していくことができる。そのため、低速のメモリカードが使われた場合でも高速な連写が或る程度長く続けられる。例えば、上述した数のバッファメモリが設けられていると、以下のコマ数だけは高速な連写ができる。

高速連写のコマ数 ＝ 2＋2＋5＋α ＝ 9＋α ------- (1)
（１）式の中の「９」はバッファメモリの総数であり、これらのバッファメモリが満杯になるまでは必ず高速連写ができることを示している。

一方、（１）式の中の「α」は、バッファメモリが満杯になるまでに書き込みが終了しているコマ数を表す。このαは、メモリカードＭ２の書込速度に依存して変わる。これらのバッファメモリが満杯になった後もメモリカードＭ２の書込速度に応じたコマ速で連写は続けられるが、バッファメモリが満杯になる前のコマ速よりも当然遅くなっている。高速連写の中にはプリプロセスが施されただけの画像データをひたすらＲＡＷバッファ５３ｄに蓄積していくものもあり、撮像回路５２からの画像データ出力が極めて速い場合に利用される。

この場合、ＲＡＷバッファ５３ｄを多数設けることになるが、ＲＡＷバッファ５３ｄは、記憶容量が大きいため記憶容量の大きなＤＲＡＭが必要になりコストアップに繋がる。電子カメラ５０では、バッファメモリの数を増やすことでそれらが満杯になるまで高速な連写は行えるが、それ以降は、バッファメモリに蓄積された画像データを処理しながら撮影を行うのでコマ速は遅くなる。連写のコマ速が突然遅くなる場合、一旦、電子カメラ５０は、ライブビューの動作に戻り、焦点調整(AF)や測光演算(AE)や構図合わせをやり直すことも有益である。ライブビューに入っている時間は長くないので速やかに開始される必要がある。

しかし、図１１に示す画像処理回路５１ａの構成では、速やかに開始することが困難である。図中のポストプロセス回路５１ｎは、ＲＡＷバッファ５３ｄに記憶されているBayerデータにポストプロセスを施すため使われている。ＲＡＷバッファ５３ｄの数が多い時には、ポストプロセス回路５１ｎが空くまでに時間が掛かるため、直ぐライブビューに入ることはできない。そこで、電子カメラ５０の動作に対応するため、図１４の画像処理回路５１ａを用いる。

図１４は、バックエンジン５１の画像処理回路５１ａの他の形態を示すブロック図である。図１４では、第１のポストプロセス回路(PostProc1)５１ｐ（図では「PostProc1」と表記する。）と、第２のポストプロセス回路(PostProc2)５１ｑ（図では「PostProc2」と表記する。）とが設けられており、丁度、図１１の画像処理回路５１ａのポストプロセス回路５１ｎが、第１のポストプロセス回路５１ｐと第２のポストプロセス回路５１ｑとに置き換わっている。第１のポストプロセス回路５１ｐの入力は、プリプロセス回路５１ｋの第１の出力に常時接続されており、ライブビューの動作時のみ、この第１のポストプロセス回路５１ｐが使われる。

一方、第２のポストプロセス回路５１ｑの方は、撮影した静止画データの処理に使われる。ライブビューの時には、撮像回路５２から出力された画像データが先ず入力撮像インターフェース５１ｊで受信される。次いで、画像データは、プリプロセス回路５１ｋに送られてプリプロセスが施され、更にプリプロセス回路５１ｋの第１の出力から出力されて第１のポストプロセス回路５１ｐに入り、そこでポストプロセスが施されてスルー画のYCbCrデータに変換される。最後にそのデータが第１のポストプロセス回路５１ｐから出力されてＤＲＡＭ５３上の第１のYCbCrバッファ(YCbCr1)５３ｇに記憶される。

一方、静止画撮影時には、バックエンジン５１では、図１４中のセレクタ５１ｍの第２の入力データが選択されて第２のポストプロセス回路５１ｑに入力されるように設定すると共に、プリプロセス回路５１ｋの第１の出力と第１のポストプロセス回路５１ｐを非動作状態に設定する。撮像回路５２から出力された画像データは、入力撮像インターフェース５１ｊで受信され、次いで、プリプロセス回路５１ｋに送られてプリプロセスが施される。更に、画像データは、プリプロセス回路５１ｋの第２の出力から出力されて一旦ＤＲＡＭ５３上のＲＡＷバッファ５３ｄに記憶される。

この時、プリプロセス回路５１ｋの第１の出力と第１のポストプロセス回路５１ｐとは、非動作状態に設定されているので、バックエンジン５１内では、無駄な電力消費がない。これが１ステップ目である。次いで、プリプロセスの施されたBayerデータがＲＡＷバッファ５３ｄから読み出されてセレクタ５１ｍを通り、更に第２のポストプロセス回路５１ｑに入ってポストプロセスが施される。

図１４に示す通り、ポストプロセスの施されたYCbCrデータは、第２のポストプロセス回路５１ｑから出力されてＤＲＡＭ５３上に設けられた第２のYCbCrバッファ(YCbCr2)５３ｈ（図では「YCbCr2」と表記する。）に記憶される。短冊分割が必要となる大きな画像の場合、ポストプロセス回路５１ｎは、短冊分割でポストプロセスを実行する。これが２ステップ目である。つまり、ライブビューと静止画撮影のポストプロセスでは使用するリソースが全く異なるので、図１４の画像処理回路５１ａを使えば、連写の途中でライブビューに戻って直ぐにそれを開始する動作が可能になる。以上が静止画撮影時の画像処理の全貌である。

＜動画撮影時の画像処理＞
次に、動画撮影時の画像処理についても簡単に説明する。動画撮影のユーザインターフェース(GUI)は、ライブビューに似ているが、その裏で動画フレームの圧縮処理(H.264等)とメモリカードへの記録が行われている点が異なる。つまり、表示用の画像(スルー画)と記録用の画像との２つがあり、最近はHD（High Definition）動画の記録も珍しくないので、この２つの画像は異なることが多い。例えば、ＬＣＤパネル５７への表示(ライブビュー)は、VGA(640×480)のサイズで行い、記録はHD(720/1080ライン)のサイズで行うような場合であり、記録用の画像の方一般にスルー画に比べて解像度が大きい。２つの異なるサイズの画像を作成する場合、図１４の画像処理回路は有用である。

つまり、バックエンジン５１では、図１４に示す通り、ライブビューの画像(スルー画)を第１のポストプロセス回路５１ｐで作成し、記録用の画像を第２のポストプロセス回路５１ｑで作成する。動画撮影時は、バックエンジン５１では、図１４中のセレクタ５１ｍの第１の入力データが選択されて第２のポストプロセス回路５１ｑに入力されるように設定する。この設定をした場合、プリプロセスが施されてプリプロセス回路５１ｋの第１の出力から出力されたBayerデータが第１のポストプロセス回路５１ｐと、第２のポストプロセス回路５１ｑとの両方に入って２つのサイズの画像が並列に作成される。

この時には、最終的に作成された２つのYCbCrデータは、それぞれ、YCbCr１バッファ５３ｇ、YCbCr２バッファ５３ｈに記憶されるだけなので、ＤＲＡＭ５３へのアクセスが少なくてその帯域を余り占有しないメリットを有する。特にHDの動画をH.264圧縮して記録する場合、ＤＲＡＭ５３へのアクセスが多いので、このメリットは有効である。記録用の動画データをプリプロセス回路５１ｋから第２のポストプロセス回路５１ｑに直接流しているため短冊分割することはできず、第２のポストプロセス回路５１ｑは、入力された画像データから少なくともフルHD(1920×1080)の画像(YCbCr)を直接作成するだけの機能を持たなければならない。

これは、第２のポストプロセス回路５１ｑに含まれるフィルタ回路が記憶容量の大きなラインメモリを持つことを意味するが、今のところ動画のサイズにはフルHDという上限があるのでそれが可能になっている。コストは、多少上がるもののライブビューの画像(スルー画)と記録用の画像の間にレイテンシがなくて扱い易い。電子カメラ５０には、この他に記録した静止画や動画を再生したり、記録した動画や静止画データをPC等のホスト機器に転送したりする機能もあるが、これらは本発明に直接関係しないので説明は省略する。

ここで、図１１や図１４の画像処理回路５１ａを持つバックエンジン５１を使用することで、図１０に示す基本的な電子カメラ５０は構成されるが、画像処理回路５１ａやJPEGコーデック５１ｃやＣＰＵ５１ｂ等の処理能力を高めることと、ＤＲＡＭ５３の帯域を十分大きく取ることにより、バックエンジン５１だけで高性能の電子カメラを実現することができる。

しかし、近年、それだけでは対応できないことも起こりつつある。最近ではＣＣＤセンサに代わってＣＭＯＳセンサが多く使われるようになったが、例えば１０Ｍ画素を超えるフルサイズの画像を60fps以上の高フレームレートで読み出すようなＣＭＯＳセンサも技術的には実現可能になっている。撮像回路５２から出力された画像データは、先ず、バックエンジンの５１入力撮像インターフェース５１ｊで受信され、次いで、それは画像処理回路５１ａ内のプリプロセス回路５１ｋに直接入力されるが、その時には、ピクセルレートが問題になる。例えば、高速なＣＭＯＳセンサを含む撮像回路５２から出力される画像データのピクセルレート(pixel/sec：pps)は以下のようになる。

ピクセルレート＝ 10Mpixel/frame×60frame/sec ＝600Mpixel/sec ----- (2)
つまり、「600Mpps」の高ピクセルレートの画像データがプリプロセス回路５１ｋを流れることになるが、高ピクセルレートの画像データを画像処理回路５１ａに流すことは困難である（通常は200Mpps程度）。（２）式のピクセルレートは、1V期間(Vsyncの周期)中のブランキング期間も画像データが出力されるとした平均的なピクセルレートであり、実際はブランキング期間を除いたもっと短い時間に有効データ(１０Ｍ画素)が全て出力されるのでピクセルレートは600Mppsより高くなる。高ピクセルレートの撮像センサは、高速に画像データを出力するため一般的な撮像センサよりも高速な出力インターフェースを備える。つまり、そのインターフェースは通常より伝送クロックの周波数が高く、しかも多数の画素のデータを並列に出力するためデータライン数も多い。

従って、一般的な撮像センサを想定するバックエンジンに超高速の撮像センサを含む撮像回路を直接接続することはできないし、高ピクセルレートの画像データをプリプロセス回路に流すことはできない問題があった。高ピクセルレートの撮像センサの開発の意義としては、多画素でフルサイズの画像を(超)高速に連写する用途の他に、ローリングシャッタに起因する動く被写体の画像の歪みを軽減するという技術的な理由がある。ＣＭＯＳセンサの電子シャッタは、今のところ全画素が同じタイミングで露光されるグローバルシャッタではなく、ライン読み出しのローリングシャッタが用いられている。そのため、動きの速い被写体の場合、撮影された画像が歪む欠点があった。

この歪みは、有効画素の読み出し時間を短縮することで軽減されるため、高ピクセルレートの撮像センサが考えられたものと思われる。動きによる画像の歪みを無くすのであればメカニカルシャッタを使えば良いのであるが、今度は60fpsのような(超)高速な連写ができない問題があった。

そこで、本実施形態の電子カメラ１は、フロントエンジン１２を追加的に利用することにより高ピクセルレートの撮像センサが出力する画像データをバックエンジン１３で処理できるようにした。フロントエンジン１２は、上述した通り、高ピクセルレートの撮像センサが出力する画像データを一旦受信し、そのピクセルレートを低減してからバックエンジン１３に送信する点を特徴とする。すなわち、一般的な撮像センサを使用する場合には、フロントエンジン１２が不要な電子カメラを構成し、高ピクセルレートの撮像センサを使用する場合には、フロントエンジン１２を追加的に利用して電子カメラを構成するように、スケーラブルで柔軟なカメラシステムが実現される。以下、電子カメラ１の詳細な構成について説明する。

＜電子カメラ１の詳細な構成＞
図２は、フロントエンジン１２及びバックエンジン１３の内部構成を説明する図である。また、図２では、電子カメラ１におけるライブビュー動作時の画像データの流れを示している。

ここで、フロントエンジン１２を設けるに当たっては、（Ａ）バックエンジン１３の既存の信号をできるだけ利用すること(コストの増加を抑える)、（Ｂ）ライブビューの時には、スルー画が作成されるまでのレイテンシができるだけ短いこと(レリーズタイムラグを短縮する)、（Ｃ）撮影した静止画データを高解像のままバックエンジンに送信すること、（Ｄ）バックエンジン１３が持っている機能をできるだけ活かすこと、（Ｅ）画像撮影の制御(シーケンス)が複雑にならないこと、といった点に配慮している。

図２に示す通り、フロントエンジン１２は、入力撮像インターフェース(SIFi)１２ａ（図では「SIFi」と表記する。）、画像縮小回路(Resize1)１２ｂ（図では「Resize1」と表記する。）、出力撮像インターフェース(SIFo)１２ｃ（図では「SIFo」と表記する。）、ＳＩＯ１２ｄ、ＤＲＡＭＣ１２ｅ、ＣＰＵ１２ｆ及びバス１２ｐを備える。

尚、入力撮像インターフェース１２ａ、画像縮小回路１２ｂ、出力撮像インターフェース１２ｃ、ＳＩＯ１２ｄ、ＤＲＡＭＣ１２ｅ及びＣＰＵ１２ｆは、バス１２ｐを介して互いに接続されている。

また、バックエンジン１３は、入力撮像インターフェース(SIFi)１３ａ（図では「SIFi」と表記する。）、画像処理回路１３ｂ、JPEGコーデック１３ｃ、ＬＣＤコントローラ１３ｄ、ＣＰＵ１３ｅ、ＤＲＡＭＣ１３ｆ、ＣＡＲＤコントローラ１３ｇ及びバス１３ｑを備える。

尚、入力撮像インターフェース１３ａ、画像処理回路１３ｂ、JPEGコーデック１３ｃ、ＬＣＤコントローラ１３ｄ、ＣＰＵ１３ｅ、ＤＲＡＭＣ１３ｆ及びＣＡＲＤコントローラ１３ｇは、バス１３ｑを介して互いに接続されている。フロントエンジン１２及びバックエンジン１３の内部の詳細は、順次説明して行く。

図１、図２に示す通り、上記の（Ａ）は、フロントエンジン１２から出力される画像データをバックエンジン１３の入力撮像インターフェース１３ａが受信することで達成される。これは、上記の（Ｂ）を達成する上でも都合が良い。一方、上記の（Ｃ）は、フロントエンジン１２がＤＲＡＭ１４（ローカルメモリ）を備えることで達成される。上記の（Ｄ）は、入力撮像インターフェース１３ａが画像データを受信して画像処理を施すことにより達成される。

フロントエンジン１２が出力するピクセルレートの低減された画像データは、バックエンジン１３の入力撮像インターフェース１３ａが受信するので、フロントエンジン１２は、バックエンジン１３に直接繋がる撮像回路１１と同じ出力撮像インターフェースを持たなければならない。

つまり、インターフェース的には、バックエンジン１３の前に撮像回路１１が繋がっているように見える。これは、（Ｅ）を達成する上で都合が良い。フロントエンジン１２は、撮像回路１１から出力される高ピクセルレートの画像データを受信するための入力撮像インターフェース１２ａも備えている。これらの入力撮像インターフェース１２ａ、１３ａは、Vsync信号で始まる１フレーム期間の中に、Hsync信号で始まるライン並びの画素データを伝送クロックに載せて送る形式のインターフェースである。つまり、先頭の幾つかのラインと最後の幾つかのラインとが有効画素を含まない垂直ブランキング期間において、その間に有効画素を含むラインが配置される。更に有効画素を含むラインでは、先頭の幾つかの画素と最後の幾つかの画素が有効画素を含まない水平ブランキング期間において、その間に有効画素が隙間なく並べられ伝送クロックに載って画素データが転送される。

従って、これらの入力撮像インターフェース１２ａ、１３ａは、フロントエンジン１２のＤＲＡＭ１４に記憶された画像データを読み出してバックエンジン１３のＤＲＡＭ１５に記憶させる転送を行うので、特許文献１に記載のインターフェース(ＲＡＷ−Ｉ／Ｆ)とは異なるものである。ここで、ＣＣＤセンサは、一般的に、ＣＭＯＳセンサよりも低速読み出しなのでその撮像回路のデータ出力は各ｂｉｔが分かれたパラレルインターフェースが多い。

一方、ＣＭＯＳセンサは、一般的にＣＣＤセンサよりも高速読み出しなのでパラレルインターフェースでは、ｂｉｔ間のいわゆるＳｋｅｗ（歪み）を合わせるのが困難であり、その撮像回路のデータ出力は、各ｂｉｔをシリアルに伝送するシリアルインターフェースが多い。

シリアルインターフェースの場合には、ＣＭＯＳセンサは、データと伝送クロックがそれぞれ正極と負極である１対の信号から成り、更に伝送クロックの立ち上がりと立ち下がりの両方でデータの各ｂｉｔを伝送するＤＤＲ(Double Data Rate)動作を行う。この正負１対のデータ伝送路のことを一般に「Lane」と呼んでいる。

VsyncやHsyncの信号は、データの中に埋め込まれた同期コードとして伝送されることが多い。ＤＤＲ動作を行っているものの伝送クロックの周波数は、ピクセル周波数の「ｂｉｔ数／２」倍必要である。例えば各画素のデータが「１２ｂｉｔ」の場合、伝送クロックの周波数がピクセル周波数の６倍になる。より高速に画像データを出力する場合には、Laneの数を増やすが、その場合には、Lane数分の画素が並列に撮像回路から出力される。特別に高速なＣＭＯＳセンサでなくてもBayer配列の場合、Laneが２つありR/GrラインのRとGr、それにGb/BラインのGbとBの画素がそれぞれ別のLaneから出力されることが一般的に多い。

つまり、１つのライン上の２色の画素は色分離されて２つの異なるLaneから出力される。従って、高速に画像データを出力するには、この２つのLaneをベースにそれを２倍(４-Lane)、３倍(６-Lane)、４倍(８-Lane)というようにLaneを増やしていく。高ピクセルレートの画像データを出力する撮像回路は、このLane数が多く、且つ伝送クロックの周波数も高い。

フロントエンジン１２は、そのような高ピクセルレートの画像データを受信する。一方、フロントエンジン１２とバックエンジン１３とは、出力撮像インターフェース１２ｃと入力撮像インターフェース１３ａで繋がっている。この構成は、ライブビューの際に都合が良い。

つまり、この構成によれば、低レイテンシでスルー画を作成する上記の（B）が達成されるからである。具体的には、フロントエンジン１２の内部回路とバックエンジン１３の画像処理回路１３ｂとを直結して１つの大きなパイプラインとして動作させる。

ライブビューの時には、図１の撮像回路１１から出力された画像データが、フロントエンジン１２の内部回路を通ってバックエンジン１３に送られるが、その際、ピクセルレートの低減された画像データがフロントエンジン１２から出力されなければならない。この画像データは、フロントエンジン１２の内部回路に留まってから出力されるので、撮像回路１１から入力された画像データを同じ画素数のまま低速で出力していては自身のパイプラインが溢れてしまう。

幸いにもライブビューの時には、フロントエンジン１２は、VGA(640×480)程度のスルー画を作成するだけなので、そのフロントエンジン１２内で画像を適当なサイズまで縮小しても構わない。撮像回路１１から送られてくる画像データのピクセルレートは一定なので、フロントエンジン１２は、そのフロントエンジン１２内でその画像を縮小すればピクセルレートは低減されることになる。

そこで、フロントエンジン１２は、ピクセルレート低減手段として先ず画像縮小回路１２ｂを備える。ライブビューの時には、フロントエンジン１２は、撮像回路１１から受信した画像データをこの画像縮小回路１２ｂで縮小し、バックエンジン１３が受信できるまでピクセルレートを低減してから出力する。

この時の画像データの流れを図２に示す。撮像回路１１から出力された画像データを受信するため、フロントエンジン１２では、そのフロントエンジン１２内の先頭に入力撮像インターフェース１２ａが置かれており、次いで、その後方に画像縮小回路１２ｂが置かれ、更にその後方には、出力撮像インターフェース１２ｃが置かれる構造をしている。

ここで、「SIFo」は、「Sensor InterFace」と「Output」の文字を組み合わせたものである。撮像回路１１から出力された画像データは、先ずフロントエンジン１２の入力撮像インターフェース１２ａで受信され、次いで、画像縮小回路１２ｂに送られて縮小され、更に出力撮像インターフェース１２ｃに送られ、そこからバックエンジン１３に向けて出力される。

画像縮小回路１２ｂでは、横方向の縮小の他、必要に応じて縦方向の縮小も行いバックエンジン１３が受信できるまでピクセルレートを低減する。ピクセルレートが低減されてフロントエンジン１２の出力撮像インターフェース１２ｃから出力された画像データは、次いで、バックエンジン１３の入力撮像インターフェース１３ａで受信され、更に画像処理回路１３ｂに入ってプリプロセスとポストプロセスが施される。尚、このバックエンジン１３におけるプリプロセスとポストプロセスとの処理は、従来の電子カメラ５０と変わりがないので説明を省略する。

図２において、撮像回路１１から出てフロントエンジン１２内の入力撮像インターフェース１２ａと画像縮小回路１２ｂと出力撮像インターフェース１２ｃとを貫き、更にバックエンジン１３の入力撮像インターフェース１３ａと画像処理回路１３ｂを通ってＤＲＡＭ１５上のYCbCrバッファ１５ａに至る矢印が、ライブビューにおける画像データの流れを表しており、最終的に作成されたスルー画のYCbCrデータは、このYCbCrバッファ１５ａに記憶される。

次いで、このYCbCrデータが読み出されてＬＣＤコントローラ１３ｄに送られＬＣＤパネル１７に表示される。

一方、ライブビューの間、バックエンジン１３では、測光演算/輝度調整(AE)や焦点調整(AF)やホワイトバランス調整(AWB)の処理も行うので、バックエンジン１３内の画像処理回路１３ｂは、適宜３Ａ評価値を抽出してＤＲＡＭ１５上の３Ａバッファ１５ｂに記憶する。これらのデータの流れをも併せて図２に示すが、これらは基本的に従来の電子カメラ５０（図１２参照）と同じである。

但し、図２では、欠陥画素テーブル１４ａがバックエンジン１３のＤＲＡＭ１５上に置かれていない点が従来と異なる。これは、フロントエンジン１２で画像の縮小が行われるためである。画像の縮小では、一般的にLPF（ローパスフィルタ）処理と間引きとが行われるが、撮像回路１１から出力された画像データには、欠陥画素のデータも含まれているのでそのままLPF処理を施すのは不適切である。

そこで、本実施形態では、フロントエンジン１２にも欠陥画素補正回路(DPC：Defect Pixel Correction)を設ける。この欠陥画素補正回路は、画像縮小回路１２ｂの前に置く必要があり、本実施形態では、後々の都合のため入力撮像インターフェース１２ａの中に欠陥画素補正回路（不図示）を設けている。

フロントエンジン１２には、ＤＲＡＭ１４が接続されており欠陥画素テーブル１４ａはこのＤＲＡＭ１４上に置かれる。ライブビューの時には、この欠陥画素テーブル１４ａの情報が読み出されて入力撮像インターフェース１２ａに送られ、撮像回路１１から受信した画像データに含まれる欠陥画素のデータを内部の欠陥画素補正回路で補正する。このデータの流れも図２に示す。

撮像回路１１から出力された画像データは、フロントエンジン１２を経由してバックエンジン１３に入るので、従来の電子カメラ５０よりもレイテンシは増えるものの、それは高々ラインレベルのレイテンシである。従って、「メモリtoメモリ」の転送を行っている特許文献１の電子カメラのようなフレームレベルのレイテンシは発生せず、本実施形態では、上述の（B）が達成されている。

尚、フロントエンジン１２には、ＣＰＵ１２ｆも含まれており、フロントエンジン１２内の処理や撮像回路１１の駆動は全てこのＣＰＵ１２ｆが制御する。

一方、図１でレリーズ釦１８がバックエンジン１３に接続されていることからも分かるように、画像の撮影を始めとするカメラ全般の動作はバックエンジン１３内のＣＰＵ１３ｅが制御する。

従って、フロントエンジン１２もバックエンジン１３の制御下に置かれており、フロントエンジン１２のＣＰＵ１２ｆは、バックエンジン１３のＣＰＵ１２ｅから画像の撮影に必要なコマンドを受けて、そのコマンドの処理を行いそのレスポンスを返す動作を行う。フロントエンジン１２側の細部の処理は、ＣＰＵ１２ｆが行うので、その分バックエンジン１３のＣＰＵ１３ｅの負荷が減り、電子カメラ１全体の制御がスムーズに行われるメリットがある。

その場合には、フロントエンジン１２側の処理で必要になる多数のパラメータ類を予めフロントエンジン１２のＤＲＡＭ１４に記憶させておき、バックエンジン１３のＣＰＵ１３ｅは、露光時間や画像サイズや処理モードといった少数のパラメータだけをコマンドと共にフロントエンジン１２のＣＰＵ１２ｆに送ると通信のオーバーヘッドが少なくて済む。

図２には、フロントエンジン１２のＣＰＵ１２ｆとバックエンジン１３のＣＰＵ１３ｅとの間に双方向の矢印が描かれているが、これは、上述したコマンドや少数のパラメータやレスポンスの流れを表す。この通信は、通信インターフェース(幅広の白矢印)を介して行われる。

バックエンジン１３のＣＰＵ１３ｅは、コマンドの実行に必要な少数のパラメータだけを送信するが、これは通信のオーバーヘッドを減らす他フロントエンジン１２を抽象化する役割も持つ。つまり、本実施形態では、フロントエンジン１２のハードウェア構成やその細かな動きを考慮しないで済む。そのため、バックエンジン１３のＣＰＵ１３ｅが実行するプログラムをフロントエンジン１２に依存しない形で作成することができる。

フロントエンジン１２内の処理及び撮像回路１１の駆動は、フロントエンジン１２のＣＰＵ１２ｆが実行するプログラムによって制御される。バックエンジン１３側のプログラム(アプリケーション)は、上位のＡＰＩ（Application Program Interface）を呼び出してその機能を利用する。これは、プログラムの移植性や再利用を高めることになり、ひいては従来の電子カメラのプログラムとの共通化にも繋がる。これを進めることで上述した（Ｅ）が達成される。

フロントエンジン１２側のプログラムは、フロントエンジン１２に接続された不図示のＦｌａｓｈメモリに記憶しておくこともできるが、通信インターフェースを介してバックエンジン１３からフロントエンジン１２側のＤＲＡＭ１４にダウンロードしても良い。これにより、Ｆｌａｓｈメモリがバックエンジン１３側の１つで済むためコストアップが抑えられる。

後者の場合には、先ず、バックエンジン１３のＣＰＵ１３ｅが起動してバックエンジン１３側の初期化を行う。次いで、フロントエンジン１２のＣＰＵ１２ｆが実行するプログラムをＦｌａｓｈメモリ１６（図１参照）から読み出し、そのプログラムを通信インターフェースを介してフロントエンジン１２のＤＲＡＭ１４にダウンロードする。最後に、フロントエンジン１２のＣＰＵ１２ｆが、そのプログラムを実行するシーケンスになるのでシステムの起動が少し遅くなる。

また、バックエンジン１３側からプログラムをダウンロードする場合には、フロントエンジン１２は、上述した多数のパラメータ類もＤＲＡＭ１４に一緒にダウンロードしておく。ここまでソフトウェアの視点から２種類のエンジンの動きについて説明したが、ライブビューの動作をソフトウェアの視点から再度説明しておく。

＜ライブビューの動作＞
図２に示す通り、先ず、バックエンジン１３のＣＰＵ１３ｅは、画像処理回路１３ｂをライブビューの処理モードに設定し、次いで、入力撮像インターフェース１３ａを有効(Active)に設定し、最後にライブビューコマンドをフロントエンジン１２のＣＰＵ１２ｆに送信する。

コマンドの実行に必要なパラメータとしては、撮像回路１１の露光時間(電子シャッタタイム)、撮像回路１１の出力モード番号(画素数とフレームレート)、画像縮小回路１２ｂの縮小率等であるが、撮像回路１１の出力モードが決まるとバックエンジン１３が受信できるピクセルレートまで低減するための縮小率が自動的に決まる。

そこで、撮像回路１１の出力モードと画像の縮小率との組み合わせを決め、フロントエンジン１２側でそのテーブルを持つことにすれば縮小率のパラメータは不要になる。画像の縮小率が決まると画像縮小回路のフィルタ係数も決まるので、そのテーブルも併せて持つことにすればフィルタ係数をコマンドと共に送る必要もない。これらのテーブルも起動時に欠陥画素テーブル１４ａと共にフロントエンジン１２のＤＲＡＭ１４にダウンロードしておく。

結局、本実施形態では、フロントエンジン１２のハードウェアに依存するパラメータをコマンドと一緒に送る必要はなく、上述した抽象化が達成されていることが分かる。必要なパラメータは、撮像回路１１の駆動に関わるものだけであり、この抽象化されたＡＰＩを用いるとフロントエンジン１２と撮像回路１１の全体が１つの仮想的な撮像回路として扱うことができる（詳細は、図８に示す仮想撮像回路の説明の際、後述する）。

従って、本実施形態では、バックエンジン１３からそれらの機能を利用することが容易になり、従来の電子カメラのソフトウェアとの共通化も図れる。これは、ソフトウェアの再利用の観点から好ましい。つまり、実際の電子カメラでは完全な共通化が困難な場合であっても、僅かな修正により他のカメラでも動くプログラムが得られるのは大きなメリットである。

フロントエンジン１２のＣＰＵ１２ｆは、上述したコマンドとパラメータを受信するとそれに基づきフロントエンジン１２の内部回路と撮像回路１１を作動させる。具体的には、フロントエンジン１２のＣＰＵ１２ｆは、デバイスドライバを呼び出してライブビューの処理を行わせ、ピクセルレートの低減されたライブビューの画像データをバックエンジン１３に送信する。

従来の電子カメラ５０では、図１０に示す通り、撮像回路５２がバックエンジン５１に直接繋がっているため、撮像ドライバもバックエンジン５１に実装されており、抽象化されたＡＰＩは最終的にその撮像ドライバを呼び出すことになる。

一方、フロントエンジン１２を有する本実施形態の電子カメラ１の場合、そのＡＰＩが後述する仮想撮像ドライバ（図９参照）を呼び出すことになる。実際には、この仮想撮像ドライバが更に通信ドライバを呼び出して上述したコマンドとパラメータをフロントエンジン１２に送信し、フロントエンジン１２のＣＰＵ１２ｆは、そのコマンドを受けて仮想撮像ドライバ及び通信ドライバを呼び出し最終的にライブビューの動作を行う。

以上より、本実施形態の電子カメラ１では、上述した（Ｃ）、（D）に加え、（Ａ）、（Ｂ）、（Ｅ）も達成することができる。尚、ライブビュー中に被写体の明るさが変化した場合(例えば日陰に入った等)、バックエンジン１３のＣＰＵ１３ｅは、露光時間を変更するコマンドと新しい露光時間(電子シャッタタイム)をフロントエンジン１２のＣＰＵ１２ｆに送信する。

＜電子カメラ１における静止画撮影の動作＞
次に、電子カメラ１の静止画撮影動作について、図１、図３を参照して説明する。

図３は、静止画撮影時の画像データの流れを示す図である。ライブビューの最中に図１に示すレリーズ釦１８が全押しされると、電子カメラ１は焦点調整（AF）を行ってから被写体の露光に進む。そして、３Ａ検波は、バックエンジン１３で行われるのでこの焦点調整（AF）と測光演算（AE）もバックエンジン１３のＣＰＵ１３ｅで行われる。ここまでの処理は、従来の電子カメラ５０と変わりはないが、その後の露光と画像データ出力は、フロントエンジン１２が存在するため動作が異なる。バックエンジン１３のＣＰＵ１３ｅは、先ず、画像処理回路を静止画の処理モードに設定し、次いで、入力撮像インターフェース１２ａを有効（Active）に設定し、最後に静止画撮影コマンドをフロントエンジン１２のＣＰＵ１２ｆに送信する。

コマンドと共に送信するパラメータは、撮像回路１１の露光時間(電子シャッタタイム)と撮像回路１１の出力モード番号(フル解像度)等である。静止画撮影は基本的に1-Shot動作なので、連写の場合にはこれらを繰り返し送信する。

実際には、バックエンジン１３側では、この通信を上述したＡＰＩから行う。このＡＰＩから仮想撮像ドライバが呼び出され、その仮想撮像ドライバから更に通信ドライバが呼び出される。そして、フロントエンジン１２のＣＰＵ１２ｆにコマンドとパラメータが送られる。フロントエンジン１２のＣＰＵ１２ｆがこれらの情報を受信するとフロントエンジン１２の内部回路と撮像回路１１とを作動させて静止画の撮影を行う。

ＣＰＵ１２ｆは、それらのデバイスドライバを呼び出して先ず撮像回路１１に露光を行わせ、次いで撮像回路１１から静止画データを出力させる。更に、ＣＰＵ１３ｅは、フロントエンジン１２にそのピクセルレートを低減させ、最後に、ＣＰＵ１２ｆは、ピクセルレートの低減された静止画データを出力撮像インターフェース１２ｃからバックエンジン１３に向けて出力させる。

ここで、仮想撮像ドライバを設けることで静止画撮影の動作においてもＡＰＩから上層では、従来の電子カメラと同じソフトウェアが利用できる。

ところで、静止画データのピクセルレートをどのように低減するかという問題が残っている。静止画データを高解像のままバックエンジン１３に送信する（Ｃ）の条件があるため、ライブビューの時のようにその画像を縮小する方法は使えない。

基本的には、撮影時の解像度(フル解像度)のままバックエンジン１３に送信しなければならない。これは、フロントエンジン１２にメモリ(ＤＲＡＭ)１４を設けることで達成される。つまり、フロントエンジン１２では、撮像回路１１から出力された静止画データを一旦このＤＲＡＭ１４に記憶し、その静止画データを記憶時よりも低速で読み出すことでピクセルレートの低減された静止画データをバックエンジン１３に送信することができる。

つまり、フロントエンジン１２は、別のピクセルレート低減手段としてローカルメモリ(ＤＲＡＭ)を備えても良い。フロントエンジン１２のＤＲＡＭ１４は、プログラムやパラメータの記憶に利用することを先に述べたが、それは副次的な使い方であり主たる用途は静止画データを一時的に記憶することである。

＜静止画撮影時の画像データの流れ＞
次に、静止画撮影時の画像データの流れについて説明する。撮影された静止画データは、撮像回路１１から出力されて先ずフロントエンジン１２の入力撮像インターフェース１２ａで受信される。次いで、その静止画データは、内部の欠陥画素補正回路（不図示）で欠陥画素のデータが補正され、更に入力撮像インターフェース１２ａから出力されてフロントエンジン１２のＤＲＡＭ１４上に設けられたＲＡＷ1バッファ１４ｂに一旦記憶される。

この時は、同じＤＲＡＭ１４から欠陥画素テーブル１４ａの情報が読み出されて欠陥画素補正回路に入力される。しかし、フロントエンジン１２は、ピクセルレートを低減するだけでも良いので、欠陥画素補正を行わずに静止画データをバックエンジン１３に送り、バックエンジン１３の画像処理回路(プリプロセス回路)に含まれているに欠陥画素補正回路で補正しても構わない。

しかし、バックエンジン１３は、ライブビューと静止画撮影とで統一した処理が行えないので制御が複雑になる欠点がある。そのため、静止画撮影時も欠陥画素補正については、フロントエンジン１２側で行っている。続いて、フロントエンジン１２側では、ＲＡＷ1バッファ１４ｂから静止画データを読み出し、それをフロントエンジン１２の出力撮像インターフェース１２ｃに入力してそこからバックエンジン１３に向けて出力する。

この時には、出力撮像インターフェース１２ｃからピクセルレートの低減された静止画データが出力される。ＤＲＡＭ１４に記憶された静止画データを「低速」で読み出すと先に述べたが、これは結果的にバックエンジン１３側で読み出し可能程度に低速で読み出されることを意味する。

ここで、図３に示す通り、フロントエンジン１２の出力撮像インターフェース１２ｃは、バックエンジン１３の入力撮像インターフェース１３ａに合った伝送速度(伝送クロック)で画像データを送信する。そのため、フロントエンジン１２のＣＰＵ１２ｆがこの出力撮像インターフェース１２ｃの送信動作に合わせて静止画データをＲＡＷ1バッファ１４ｂから読み出すと、結果的に、画像データは、低速で読み出されたことになる。

出力撮像インターフェース１２ｃからの送信とＲＡＷ1バッファ１４ｂからの読み出しは、一般に非同期である。そのため、フロントエンジン１２のＣＰＵ１２ｆがＲＡＷ1バッファ１４ｂから入力されるデータをそのまま送信していては、バックエンジン１３に送られる静止画データに隙間が生じてしまう(歯抜け状になる)。

これは、入出力撮像インターフェース１２ａのフォーマットとして許されないことであり、そのためフロントエンジン１２の出力撮像インターフェース１２ｃは、ラインバッファを持たなければならない。

つまり、出力撮像インターフェース１２ｃは、静止画データを一旦このラインメモリに記憶し、１ライン分の画素のデータが蓄積されたらそれを伝送クロックに載せて隙間なく送信する。このラインバッファを少なくとも２つ設けると送信している間に次のラインのデータが用意されるのでデータの送信がスムーズになる。ライブビューの場合もこれと同様であり、画像縮小回路１２ｂから出力された静止画データは、一旦このラインバッファに記憶してからバックエンジン１３に向けて送信される。フロントエンジン１２の出力撮像インターフェース１２ｃから出力された静止画データは、この後バックエンジン１３に入って画像処理が施される。

この静止画データは、先ず、バックエンジン１３の入力撮像インターフェース１３ａで受信され、次いで、画像処理回路１３ｂに送られて内部のプリプロセス回路(PreProc)でプリプロセスが施される。欠陥画素補正は、予めフロントエンジン１２で行われているので、バックエンジン１３のプリプロセス回路では残りの処理が施される。

プリプロセスの施された静止画データ(Bayer)は、プリプロセス回路から出力されてバックエンジン１３のＤＲＡＭ１５上に設けられたＲＡＷ2バッファ１５ｃに一旦記憶される。画像処理回路１３ｂ内のプリプロセス回路では、AWB検波も行っており、この時、抽出されたAWB評価値が同じＤＲＡＭ１５上に設けられたAWBバッファ１５ｄに記憶される。ここまでが静止画の画像処理の１ステップ目(プリプロセス)であり、この時のデータの流れを図３に示す。

バックエンジン１３のＣＰＵ１３ｅは、このAWB評価値を基にAWBアルゴリズムを実行してWBゲインを求め、そのWBゲインを画像処理回路１３ｂ内のポストプロセス回路(PostProc)に設定する。次いで、画像処理回路１３ｂ内のポストプロセス回路は、画像処理の２ステップ目(ポストプロセス)を実行する。静止画は、一般に巨大なので、ポストプロセス回路は、２ステップ目は、短冊分割で実行する。

ポストプロセス回路は、プリプロセスの施された静止画データ(Bayer)をＲＡＷ2バッファ１５ｃ上で幾つかの短冊画像に分割し、それらを１つずつ読み出し画像処理回路内のポストプロセス回路に入力してポストプロセスを施し、ポストプロセスの施されたYCbCrデータをＤＲＡＭ１５上のYCbCrバッファ１５ａに記憶していく。ポストプロセス回路は、この処理を全ての短冊画像について実行すると、YCbCrバッファ１５ａ上には画像処理が済んで１つに繋がった画像が出来上がっている。

２ステップ目では、主画像、表示用画像(フリーズ画)、サムネイルの３つが作成されてそれぞれのYCbCrバッファ１５ａに記憶される。以上が２ステップ目(プリプロセス)であり、この時のデータの流れも図３に示す。この後は、ＣＰＵ１３ｅの指示により、撮影結果を確認するため先ずフリーズ画をＬＣＤパネル１７に表示させる。具体的には、ＣＰＵ１３ｅの指示により、ＤＭＡコントローラは、YCbCrバッファ１５ａの１つからフリーズ画を読み出し、それをＬＣＤコントローラ１３ｄに送ってＬＣＤパネル１７に表示させる。

一方、ＣＰＵ１３ｅの指示により、JPEGコーデック１３ｃは、それと並行して上述した３つの画像をJPEG圧縮する。ＤＭＡコントローラは、YCbCrバッファ１５ａから画像データ(YCbCr)を読み出し、それをJPEGコーデック１３ｃに入力し、JPEGコーデック１３ｃから出力された圧縮データをＤＲＡＭ１５上のJPEGバッファ１５ｅに記憶していく。

以上の処理を順次実行して、JPEGコーデック１３ｃは、３つの画像を圧縮する。ＣＰＵ１３ｅの指示により、CARDコントローラ１３ｇは、３つの画像のJPEG圧縮データをタグ情報と共に１つのJPEGバッファ１５ｅ上に配置し、Exif/DCFのファイルやMPFのファイルのファイルイメージを形成していく。CARDコントローラ１３ｇは、このファイルイメージが完成したら各々の画像をメモリカードＭ１に記録する。

更に、ＤＭＡコントローラは、JPEGバッファ１５ｅからこのファイルイメージを読み出し、それをCARDコントローラ１３ｇに入力してメモリカードに記録していく。この記録が終わると静止画のファイルがメモリカード２０上に保存されて撮影が完了する。これらの処理におけるデータの流れも併せて図３に示す。フロントエンジン１２側のＤＲＡＭ１４は、静止画のピクセルレートを低減するために設けられたが、ピクセルレートを低減するだけならＲＡＷ1バッファ１４ｂは１つあれば良いので、ＤＲＡＭ１４の記憶領域は、空きが生じて無駄になる。

そこで、この記憶領域を別の目的にも利用する。このＤＲＡＭ１４は、プログラムの記憶やそのプログラムのワークメモリ(変数やスタックの領域)にも使用されるので、それらを除いた記憶領域にＲＡＷ1バッファ１４ｂを幾つも割り当てる。これで撮像回路１１から出力された静止画データをＲＡＷ1バッファ１４ｂに蓄積していく高速な連写（以下、「ＲＡＷバッファ連写」という。）行うことができる。

ＲＡＷ1バッファ１４ｂに静止画データを記憶するのと並行して、出力撮像インターフェース１２ｃは、先に撮影したコマのデータを別のＲＡＷ1バッファ１４ｂから読み出しバックエンジン１３に送って処理すると長く連写を続けることができる。撮像回路１１から出力される画像データは、高ピクセルレートなので、フロントエンジン１２のＤＲＡＭ１４は広帯域でなければならない。更にバックエンジン１３側のＲＡＷ2バッファ１５ｃを複数設けておくと、後段の処理が低速でも画像データの送信が停滞しないので連写が長く続けられる。

全てのバッファメモリ(ＲＡＷ1、ＲＡＷ2、YCbCr、JPEG)が満杯になるか、どこかの画像データの流れが停滞し、それが前方に及んでＲＡＷ1バッファ１４ｂが満杯になると高速な連写は一旦停止する。

それ以降は、蓄積された静止画データが処理されてＲＡＷ1バッファ１４ｂが１つ空く度に撮影が行われる動作になるので、連写のコマ速は遅くなる。これは、従来のカメラと同様であるが、連写のコマ速は遅くなる場合には、一旦ライブビューに戻って焦点調整（AF）や測光演算（AE）や構図合わせをやり直すことも有益である。

以上より、本実施形態の電子カメラ１は、低ピクセルレートの場合には、そのままの画像データをバックエンジン１３側に転送するので、バックエンジン１３だけでも画像処理の行える最小限のカメラシステムを構成することができる。更に、バックエンジン１３が受信できないような高ピクセルレートの撮像センサを使用する場合、フロントエンジン１２の画像縮小回路１２ｂは、バックエンジン１３が受信できるまでピクセルレートを低減できる。つまり、フロントエンジン１２を追加的に利用して対応するというスケーラブルな電子カメラを提供できる。

（第２実施形態）
次に、第２実施形態について説明する。ここで、電子カメラ５０の場合、撮像回路５２から出力される画像データが高ピクセルレートでないため、ライブビューを行いながらその中の或るフレームを静止画として記録してもその解像度は余り高くない。ライブビューのような高フレームレートで画像データを出力するには画素数を落とさなければならないからである。

そこで、第２実施形態の電子カメラでは、高ピクセルレートの画像データを受信した場合、ライブビューを行いながらその中の或るフレームをフル解像度の静止画として記録する手段を提供する。尚、第１実施形態の電子カメラ１の構成（図１〜図３参照）では、このような手段を提供することが困難である。その理由は、ライブビューの画像データと静止画データの２つを並行してフロントエンジン１２からバックエンジン１３に送信しなければならないのであるが、図１〜図３に示した２つのエンジン間には、画像データの送信路が１つしかないからである。そこで、第２実施形態の電子カメラでは、画像データの送信路を２つ有するエンジンを用いることにする。

尚、第１実施形態と第２実施形態とでは、図１に示す同じ構成要素については同じ符号を付し、ここでは、相違点について主に説明する。

図４は、第２実施形態の電子カメラの構成例を示すブロック図である。図中のフロントエンジン１２からバックエンジン１３に向かう実線の矢印は第１の画像データ送信路を表し、同様の点線の矢印は第２の画像データ送信路を表している。実線の矢印の始点には、フロントエンジン１２の第１の出力撮像インターフェース１２ｃがあり、実線の矢印の終点には、バックエンジン１３の第１の入力撮像インターフェース１３ａがあって、これらを繋ぐ信号ラインが第１の画像データ送信路になる。

一方、点線の矢印の始点には、フロントエンジン１２の第２の出力撮像インターフェース１２ｋがあり、点線の矢印の終点には、バックエンジン１３の第２の入力撮像インターフェース１３ｋがあって、これらを繋ぐ信号ラインが第２の画像データ送信路になる。

第１の画像データ送信路には、相対的に低解像度の画像データが流れ、第２の画像データ送信路には、相対的に高解像度の画像データが流れるという風に使い分けられる。具体的には、第１の画像データ送信路には、ライブビューの画像データを流し、第２の画像データ送信路には、静止画データや記録用の動画データを流す。

この使い分けは固定的であって良い。これらの画像データ送信路に流れる画像データは、バックエンジン１３が受信できるようにピクセルレートが低減されていなければならない。フロントエンジン１２は、このピクセルレートの低減を行う。２つの画像データを並行して送信するため、フロントエンジン１２は、複数のピクセルレート低減手段を持つ。

そして、バックエンジン１３は、これらの２つの画像データを受信して処理する。２つの画像データを並行して送受信するため新たなフロントエンジン１２とバックエンジン１３とは、内部構成が電子カメラ１（図２、図３参照）、電子カメラ５０（図１４参照）と異なる。以下、第２実施形態のフロントエンジン１２とバックエンジン１３の内部構成及び画像データの流れについて説明をする。

＜フロントエンジン１２の内部構成例＞
図５は、電子カメラ２のフロントエンジン１２及びバックエンジン１３の内部構成例を説明する図である。図５では、画像データの流れを示している。そこで、画像データの流れに沿って各々のエンジンの内部構成例を説明する。

撮像回路１１から出力された、ピクセルレートの低減が必要な高ピクセルレートの画像データは、先ず、フロントエンジン１２の入力撮像インターフェース１２ａに受信され、次いで、欠陥画素補正回路(DPC：Defect Pixel Correction)で欠陥画素のデータが補正される。フロントエンジン１２のＤＲＡＭ１４上には、欠陥画素の位置(アドレス)を記憶した欠陥画素テーブルが置かれており、DPCブロック１２ｇは、このテーブルの情報を読み出して補正を行う。

図２と図３では、簡略化のためDPCブロック１２ｇを入力撮像インターフェース１２ａに含めたが、図５では分かり易くするためこの２つを分けて表した。図５のフロントエンジン１２内部の左端の点線枠が図２や図３の入力撮像インターフェース１２ａに対応する。欠陥画素補正の施された画像データは、３つのピクセルレート低減手段に送られる。その中で第１のピクセルレート低減手段と第２のピクセルレート低減手段は、画像縮小回路を有し、第３のピクセルレート低減手段は、メモリを有する。

図５中の第１の画像縮小回路１２ｂは、第１のピクセルレート低減手段に、第２の画像縮小回路(Resize2)１２ｉ（図では「Resize2」と表記する。）は、第２のピクセルレート低減手段に、メモリ(ＤＲＡＭ：ＲＡＷ1バッファ１４ｂ)は、第３のピクセルレート低減手段にそれぞれ対応している。

図５では、第２の画像縮小回路１２ｉの後に２入力のセレクタ(Sel)１２ｊ（図では「Sel」と表記する。）が置かれており、セレクタ１２ｊの第１の入力には第２の画像縮小回路１２ｉの出力が繋がり、第２の入力には、ＲＡＷ1バッファ１４ｂの出力(ＤＲＡＭCの出力ポート)が繋がる。更に、このセレクタ１２ｊの出力は、第２の出力撮像インターフェース(SIFo2)１２ｋ（図では「SIFo2」と表記する。）に繋がる。

図２や図３の画像データの流れと比較すると、図５のフロントエンジン１２内部の左端の点線枠内は、図２や図３の入力撮像インターフェース１２ａに対応する。また、図５のフロントエンジン１２内部の右端の点線枠内は、図２や図３の出力撮像インターフェース１２ｃに対応する。また、図５の第２の画像縮小回路１２ｉは、図２や図３の画像縮小回路１２ｂに対応する。また、図５の点線枠内のブロックは、図２や図３の対応するブロックを使用することによって同様の構成にすることができる。

一方、図５の第１の画像縮小回路１２ｂ以降のブロックは新たに設けられたものである。図２は、ライブビュー動作時の画像データの流れであるが動画撮影の場合もこれと同じ流れになる。図２では、ライブビューの場合も動画撮影の場合も同じ画像縮小回路１２ｂを用いてピクセルレートを低減し、同じ出力撮像インターフェース１２ｃから画像データを出力している。動画撮影時は、フロントエンジン１２から出力された画像データがバックエンジン１３の画像処理回路１３ｂ内部で２つに分かれ、第１のポストプロセス回路(PostProc1)１３ｊ（図では「PostProc1」と表記する。）で表示用のスルー画(YCbCr)が作成され、第２のポストプロセス回路(PostProc2)１３ｐ（図では「PostProc2」と表記する。）では、記録用の動画像(YCbCr)が作成される。画像データの送信路が１つの場合、ライブビューと動画撮影の画像データの流れは以上のようになる。

しかし、図５のように画像データの送信路が２つある場合、ライブビューの画像データの流れが変わってくる。具体的には、入力撮像インターフェース１２ａは、ライブビューの画像データを第１の画像縮小回路１２ｂの方に流している。第１の画像縮小回路１２ｂの後には、第１のプリプロセス回路(PreProc1)１２ｈ（図では「PreProc1」と表記する。）が置かれており、その後に第１の出力撮像インターフェース(SIFo1)１２ｃ（図では「SIFo1」と表記する。）が置かれる構造をしているが、これは新設されたデータ経路である。

ライブビューの画像データは、常に「第１の画像縮小回路１２ｂ→第１のプリプロセス回路１２ｈ→第１の出力撮像インターフェース１２ｃ」と流れる。これは動画撮影の場合も変わりがない。一方、記録用の動画データの方は「第２の画像縮小回路１２ｉ→セレクタ１２ｊ→第２の出力撮像インターフェース１２ｋ」と流れる。また、静止画データは「ＲＡＷ1バッファ１４ｂ→セレクタ１２ｊ→第２の出力撮像インターフェース１２ｋ」と流れる。

つまり、静止画データと記録用の動画データとは、第２の画像データ送信路(点線の矢印)を通ってバックエンジン１３に送信されるが、ライブビューの画像データの方は、常に第１の画像データ送信路(実線の矢印)を通ってバックエンジン１３に送信される。第２の画像データ送信路は、図２や図３にあるものと基本的に同じなので、違いはライブビューの画像データが新設された第１の画像データ送信路の方を通って送信されている点である。

画像データ送信路が１つの場合、動画撮影時に送られてくる記録用の動画データをバックエンジン１３がライブビュー（スルー画表示）にも利用していたが、画像データ送信路が２つの場合、ライブビュー用の動画データと記録用の動画データが同時に送られてくるので、バックエンジン１３では、それらを別々に処理することになる。

動画撮影時には、記録用の動画データ１つで足りるので無駄にも思われるが、電子カメラ２では、静止画撮影時も動画撮影時もライブビューの画像データを同じ送信路で送ることができるので処理が統一されるメリットがある。つまり、電子カメラ２では、画像データの送信路を２つ設けたために、図１４に示すバックエンジン５１の構成から図５に示すバックエンジン１３の構成に変更している。

＜バックエンジン１３の内部構成例＞
次に、バックエンジン１３の構成例について図５を用いて説明する。フロントエンジン１２の第２の出力撮像インターフェース１２ｋから出力された画像データを受信するために、バックエンジン１３には、第２の入力撮像インターフェース(SIFi2)１３ｋ（図では「SIFi2」と表記する。）が設けられている。第２の入力撮像インターフェース１３ｋの後には、第２のプリプロセス回路(PreProc2)１３ｍ（図では「PreProc2」と表記する。）が置かれ、その後には、２系統の入力の第２セレクタ(Sel)１３ｎ（図では「Sel」と表記する。）が置かれ、更にその後に第２のポストプロセス回路１３ｐが置かれる構成になっている。

第２のプリプロセス回路１３ｍの出力は、第１の出力がこの第２セレクタ１３ｎの第１の入力に繋がり、第２の出力はバックエンジン１３のＤＲＡＭ１５上に設けられたＲＡＷ2バッファ１５ｃの入力(DRAMCの入力ポート)に繋がっている。

一方、第２セレクタ１３ｎの第２の入力には、同じＲＡＷ2バッファ１５ｃの出力(DRAMCの出力ポート)が繋がっており、更にこの第２セレクタ１３ｎの出力が第２のポストプロセス回路１３ｐの入力に繋がり、最後に第２のポストプロセス回路１３ｐの出力がＤＲＡＭ１５上に設けられたYCbCr2バッファ１５ｇの入力(DRAMCの出力ポート)に繋がる。

図５における第２の入力撮像インターフェース１３ｋから第２のポストプロセス回路１３ｐに至る回路は、図１４における入力撮像インターフェース５１ｊから第２のポストプロセス回路５１ｑに至る回路と構成が同じであり、図５の回路は、図１４の回路を用いることによって構成できる。

静止画撮影の場合、バックエンジン１３では、第２のプリプロセス回路１３ｍの第２の出力から出力された静止画データがＲＡＷ2バッファ１５ｃに送られるようにすると共に、そのＲＡＷ2バッファ１５ｃから読み出された静止画データが第２セレクタ１３ｎの第２の入力から入力されて第２のポストプロセス回路１３ｐに送られるように設定する。

撮影された静止画データは、フロントエンジン１２の第２の出力撮像インターフェース１２ｋから出力されてバックエンジン１３の第２の入力撮像インターフェース１３ｋで受信される。次いで、静止画データは、第２のプリプロセス回路１３ｍに送られてプリプロセスが施され、更に、第２のプリプロセス回路１３ｍの第２の出力から出力されて一旦ＲＡＷ2バッファ１５ｃに記憶される。

第２のプリプロセス回路１３ｍでは、ＡＷＢ検波も行われており、この時抽出されたAWB評価値が図５のＡＷＢバッファ１５ｄに記憶される。ここまでが静止画の画像処理の１ステップ目(プリプロセス)である。バックエンジン１３のＣＰＵ１３ｅ（図２参照）は、このＡＷＢ評価値を基にＡＷＢアルゴリズムを実行してＷＢゲインを求め、そのＷＢゲインを第２のポストプロセス回路１３ｐに設定する。

次いで、第２のポストプロセス回路１３ｐは、画像処理の２ステップ目(ポストプロセス)を実行する。２ステップ目の処理は、一般に短冊分割で実行される。第２のポストプロセス回路１３ｐは、先ず、プリプロセスの施された静止画データ(Bayer)をＲＡＷ2バッファ１５ｃ上で幾つかの短冊画像に分割する。続いて、第２のポストプロセス回路１３ｐは、それらを１つずつ読み出してポストプロセスを施す。更に、第２のポストプロセス回路１３ｐは、ポストプロセスの施されたYCbCrデータを図５のYCbCr2バッファ１５ｇに記憶していく。従って、第２のポストプロセス回路１３ｐが、２ステップ目の処理を全ての短冊画像について実行すると、YCbCr2バッファ１５ｇ上には画像処理が済んで１つに繋がった画像が出来上がっている。

２ステップ目では、主画像，表示用画像(フリーズ画)及びサムネイルの３つが作成されてそれぞれのYCbCr2バッファ１５ｇに記憶される。以上が静止画の画像処理の２ステップ目(プリプロセス)であるが、これらの静止画データの流れは、第２の画像データ送信路を通る点を除くと基本的に図３と変わりがない。静止画撮影におけるこれ以降の処理は以前に説明した通りなので省略する。

一方、動画撮影の場合には、記録用の動画データが第２のプリプロセス回路１３ｍの第１の出力から出力されるようにすると共に、そのデータが第２セレクタ１３ｎの第１の入力から入力されて第２のポストプロセス回路１３ｐに送られるように設定する。

記録用の動画データは、フロントエンジン１２の第２の出力撮像インターフェース１２ｋから出力されてバックエンジン１３の第２の入力撮像インターフェース１３ｋで受信される。次いで、記録用の動画データは、第２のプリプロセス回路１３ｍに送られてプリプロセスが施され、更に第２のプリプロセス回路１３ｍの第１の出力から出力されて第２セレクタ１３ｎの第１の入力に入力され、そこから第２のポストプロセス回路１３ｐに送られてポストプロセスが施される。そして、記録用の動画データは、最後に第２のポストプロセス回路１３ｐから出力されて一旦図５のYCbCr2バッファ１５ｇに記憶される。

この記録用の動画データ(YCbCr)は、不図示の動画コーデック(H.264等)で圧縮された後、メモリカードＭ１に記録されるが詳細は省略する。動画撮影中、第２のプリプロセス回路１３ｍは、一般に被写体が動くので常に焦点調整(AF)を行う必要があり、AF検波回路でAF評価値を抽出しつつそれを用いて焦点調整(AF)を継続して行う。動画撮影中、第２のプリプロセス回路１３ｍは、被写体の明るさとホワイトバランスも適切に保つ必要があり、AE検波回路(AE評価値)とAWB検波回路(AWB評価値)とを適宜稼働させてそれらの調整を行う。尚、３Ａ検波については、後述するライブビュー用の３Ａ検波回路の説明で詳しく述べる。

ここで、記録用の動画データの流れは、第２の画像データ送信路を通る点を除くと基本的に図２と変わりがない。要するに静止画データと記録用の動画データとの流れは、画像データ送信路が２つの場合も１つの場合も同じであり、画像データ送信路を２つ有する図５のフロントエンジン１２とバックエンジン１３とは、図１４におけるプリプロセス回路５１ｋから第２のポストプロセス回路５１ｑに至る回路を上手く利用するように構成されていることが分かる。

つまり、図５の２つのエンジンも図２や図３や図１４に示したエンジンをベースに作られている。これは以下に説明するライブビューの場合にも当てはまる。

＜ライブビューの画像データの流れについて＞
次に、ライブビューの画像データの流れについて説明する。既に説明した通り、ライブビューの画像データは、新設された第１の画像データ送信路を通ってフロントエンジン１２からバックエンジン１３に送信される。フロントエンジン１２がライブビューのために新設されたブロックを含むように、バックエンジン１３にもライブビューのために新設されたブロックがある。

これらのブロックは、図１４における第１のポストプロセス回路５１ｐを有効に利用するために新設された。図５に示す通り、バックエンジン１３の先頭には第１の入力撮像インターフェース(SIFi1)１３ａ（図では「SIFi1」と表記する。）が置かれており、その後に２系統の入力の第１セレクタ(Sel)１３ｉが置かれ、更にその後に第１のポストプロセス回路１３ｊが置かれる構成となっている。バックエンジン１３に新設されたブロックは、第１の入力撮像インターフェース１３ａと第１セレクタ１３ｉの２つである。第１の入力撮像インターフェース１３ａの出力は、第１セレクタ１３ｉの第１の入力に繋がっており、一方、第２のプリプロセス回路１３ｍの第１の出力が同じ第１セレクタ１３ｉの第２の入力に繋がり、更にそのセレクタの出力が第１のポストプロセス回路１３ｊの入力に繋がっている。

フロントエンジン１２を使用する場合、第１の入力撮像インターフェース１３ａから出力されたライブビューの画像データが、常に第１のポストプロセス回路１３ｊに送られるように第１セレクタ１３ｉを設定する。

一方、バックエンジン１３の第２の入力撮像インターフェース１３ｋに撮像回路１１を直接接続する場合、第２のプリプロセス回路１３ｍから出力されたライブビューの画像データが第１のポストプロセス回路１３ｊに送られるように第１セレクタ１３ｉを設定する。これは、図１４におけるプリプロセス回路５１ｋから第１のポストプロセス回路５１ｐに至るデータ経路に対応している。この場合、第１の入力撮像インターフェース１３ａは、使われない。

つまり、バックエンジン１３内の第１セレクタ１３ｉは、フロントエンジン１２から送信されるライブビューの画像データを使うか、或いは、バックエンジン１３の第２の入力撮像インターフェース１３ｋに直接接続された撮像回路１１から出力されるライブビューの画像データを使うか選択するためのものである。これによって、入力撮像インターフェースを２つ(SIFi1とSIFi2)持つバックエンジンが従来の電子カメラでも使える。

ライブビューの場合、フロントエンジン１２の第１の出力撮像インターフェース１２ｃから出力された画像データがバックエンジン１３の第１の入力撮像インターフェース１３ａで受信される。次いで、その画像データは、第１セレクタ１３ｉの第１の入力に入力され、そこから第１のポストプロセス回路１３ｊに送られてポストプロセスが施され、最後に第１のポストプロセス回路１３ｊから出力されて図５のYCbCr1バッファ１５ｆに記憶される。

このライブビュー用のYCbCrデータ(スルー画)は、YCbCr1バッファ１５ｆから読み出され、ＬＣＤコントローラ（不図示）に送られてＬＣＤパネル１７（図４参照）に表示される。動画撮影の場合、ライブビューの画像データが第１の画像データ送信路から送信されるのと並行して、記録用の動画データが第２の画像データから送信されることを既に述べた。

一方、静止画撮影の場合、フロントエンジン１２では、撮影された静止画データを第２の画像データ送信路から送信するのと並行して、ライブビューの画像データを第１の画像データ送信路から送信することができる。これにより、先に述べた電子カメラの特性が全て実現されると共に、上述した（Ｄ）の条件も満たされることになる。

ライブビューの場合、他にも考慮しなければならないことがある。先ず、ライブビューの画像データは、バックエンジン１３でプリプロセスだけが施される点である。ライブビューの画像データは、その前にプリプロセスが施されなければならない。

バックエンジン１３には、第２のプリプロセス回路１３ｍもあるが、これは静止画データや記録用の動画データの処理に使われているためライブビューの画像データのプリプロセスには使えない。ライブビュー用のプリプロセス回路が別に必要となる。フロントエンジン１２内の第１のプリプロセス回路１２ｈは、そのためのもので、第１の画像データ送信路と共に新設された。

第１のプリプロセス回路１２ｈがフロントエンジン１２にあるのでバックエンジン１３のコスト上昇が抑えられ、このバックエンジン１３を従来の電子カメラで利用する場合にも都合が良い。

次に考慮しなければならないことは、３Ａ検波である。第２のプリプロセス回路１３ｍは、静止画データや記録用の動画データを処理しているため、その中に設けられた３Ａ検波回路（不図示）を使うことはできない。

動画撮影の場合、バックエンジン１３では、第２のプリプロセス回路１３ｍ内蔵の３Ａ検波回路を使って記録用の動画データから３Ａ評価値を抽出することもできる。しかし、静止画データを処理している場合、バックエンジン１３では、画像データが異なるのでその３Ａ検波回路をそのまま用いることはできない。

従って、ライブビュー用の３Ａ検波回路が別に必要となるが、これをフロントエンジン１２の第１のプリプロセス回路１２ｈ内に設けると、３Ａのソフトウェア処理をバックエンジン１３で行うのが困難になる。３Ａの評価値がフロントエンジン１２側に存在するため、これをバックエンジン１３側のソフトウェアが利用すると、処理が遅くなってしまう。３Ａ処理のソフトウェアをフロントエンジン１２側に実装することもできるが、従来とは大幅にシステムが変わるのでソフトウェア共通化が難しい問題がある。

そこで、電子カメラ２では、バックエンジン１３側にライブビュー用の３Ａ検波回路を設けることにするが、単純に増設したのでは、バックエンジン１３のコストが上昇して従来の電子カメラで使う際に不利となる。即ち、第２実施形態では、バックエンジン１３の第２のプリプロセス回路１３ｍ内にある３Ａ検波回路を外部に出し、それをライブビューの場合にも使えるようにする。動画撮影の場合には特に問題はないが、静止画撮影の場合には、その３Ａ検波回路を静止画データのために使えない問題が起こる。

しかし、静止画データ処理では、３Ａ検波回路がフルに使われておらず、必要となるのは、ＡＷＢ検波回路だけである。そこで、第２実施形態では、３Ａ検波回路を第２のプリプロセス回路１３ｍの外に出すと共に、その第２のプリプロセス回路１３ｍにはＡＷＢ検波回路だけを追加する。

これにより、バックエンジン１３でライブビューの画像データから３Ａ評価値を抽出すると共に、静止画データをバックエンジン１３の第２のプリプロセス回路１３ｍで処理しつつ、そこからAWB評価値を抽出することができる。

図５において、第２のプリプロセス回路１３ｍの上部にある「３Ａ検波」のブロックが３Ａ検波回路１３ｈを表す。フロントエンジン１２から送信されたライブビューの画像データが第１の入力撮像インターフェース１３ａから入力される場合も、バックエンジン１３の第２の入力撮像インターフェース１３ｋに直接接続された撮像回路１１からライブビューの画像データが入力される場合も、この３Ａ検波回路１３ｈが使えなければならないので、図５のようにバックエンジン１３内の第１セレクタ１３ｉの出力をこの３Ａ検波回路１３ｈの入力に接続する。

この３Ａ検波回路１３ｈの出力は、図５の３Ａバッファ１５ｂの入力(DRAMCの入力ポート)に繋がっており、抽出された３Ａ評価値は、この３Ａバッファ１５ｂに記憶される。

一方、第２のプリプロセス回路１３ｍ内に追加されたＡＷＢ検波回路の出力は、図５のＡＷＢバッファ１５ｄの入力(DRAMCの入力ポート)に繋がっており、抽出されたＡＷＢ評価値は、このＡＷＢバッファ１５ｄに記憶される。これらの評価値を利用することによりバックエンジン１３側のソフトウェアで３Ａの処理を行うことができる。第２の画像データ送信路は、静止画データや記録用の動画データが流れるので相対的に高解像度の画像用であり、第１の画像データ送信路は、ライブビューの画像データが流れるので相対的に低解像度の画像用である。動画撮影における記録用の動画データとライブビューの画像データとは、フレームレート(fps)が同じであるが、解像度は前者の方が高いので２つの画像データ送信路に流れる画像データのピクセルレートには差が生じることになる。第２の画像データ送信路に流れる画像データの方が一般にピクセルレートが高い。

そこで、２つの画像データ送信路の性能に差を持たせてコストを抑えることができる。第１の画像データ送信路の伝送クロック周波数を低くしたり、そのデータラインのLane数を少なくしたりして第２の画像データ送信路よりも低コストなものにする。

以上より、電子カメラ２では、第２実施形態の電子カメラ２では、高ピクセルレートの画像データを受信した場合、例えば、ライブビューを行いながらその中の或るフレームをフル解像度の静止画として記録できる。これにより、電子カメラ２では、２つのエンジンのコストを抑えることができる。

（第３実施形態）
次に、第３実施形態について説明する。ここで、上記の実施形態では、フロントエンジン１２を用いた場合、そのＤＲＡＭ１４上に多数のＲＡＷ1バッファ１４ｂを設けることができ、それによって高速な静止画の連写を長く続けることができると先に説明した。静止画は、一般に解像度が高いため１コマのＲＡＷ1バッファ１４ｂでも記憶容量が大きく、それを多数設けることはコスト的に容易ではない。

しかし、撮影した静止画データを一旦圧縮してＲＡＷ1バッファ１４ｂに記憶するのであれば、１コマ当たりのデータ量が減るのでより多くのＲＡＷ1バッファ１４ｂを設けることができる。そこで、第３実施形態の電子カメラでは、フロントエンジン１２に画像圧縮回路を設けることにする。フロントエンジン１２のＲＡＷ1バッファ１４ｂに記憶される静止画データは元データであるため、上述した画像圧縮は全く歪みのないLossless圧縮か、或いは目立たない程度の歪みしか発生しないNearly Lossless圧縮である必要がある。

尚、第２実施形態と第３実施形態とでは、同じ構成要素については同じ符号を付し、ここでは、相違点について主に説明する。

図６は、第３実施形態の電子カメラのフロントエンジン１２及びバックエンジン１３の構成例を示すブロック図である。尚、第３実施形態では、図４に示す電子カメラ２を用いて説明する。ここで、図５と図６との構成上の違いは、フロントエンジン１２に画像圧縮回路１２ｍ（図では「圧縮」と表記する。）と画像伸長回路１２ｎ（図では「伸長」と表記する。）とを新たに設けた点である。

図６によれば、欠陥画素補正回路(DPC)の出力が画像圧縮回路１２ｍの入力に繋がり、その画像圧縮回路１２ｍの出力がＤＲＡＭ上のＲＡＷ1バッファ１４ｂの入力(DRAMCの入力ポート)に繋がっている。

欠陥画素補正回路(DPC)から出力された静止画データは、この画像圧縮回路１２ｍで圧縮され、その圧縮されたデータが画像圧縮回路１２ｍから出力されて図中のＲＡＷ1バッファ１４ｂに一旦記憶される。画像圧縮では、一般に画素間の相関を利用して圧縮を行うので欠陥画素のデータが含まれていると処理できないが、図６では、先に欠陥画素補正が行われるので問題はない。画像圧縮回路１２ｍは、撮像回路１１から出力された高ピクセルレートの静止画データをリアルタイムで圧縮しなければならないので、内部に画像圧縮コアを複数設けて並列に処理する等して、このリアルタイム圧縮を実現する。

リアルタイム処理は、図６の第１の画像縮小回路１２ｂと第２の画像縮小回路１２ｉでも行われており、複数の画素の平均を取る等してリアルタイムでピクセルレートを低減する。

一方、図６の第１プリプロセス回路(PreProc1)１２ｈは、ピクセルレートの低減された画像データを処理するので通常のパイプライン回路で良い。圧縮したデータをＲＡＷ1バッファ１４ｂに記憶しているので、ＤＲＡＭ１４のアクセス回数が減り、結果としてＤＲＡＭ１４の帯域占有が減るメリットも生まれる。画像圧縮回路１２ｍを備えることで同じＤＲＡＭ１４により多くのＲＡＷ1バッファ１４ｂを設けることはできる。

しかし、次に、そこに記憶された静止画データをどのようにしてバックエンジン１３に渡すかという課題に直面する。圧縮された静止画データをそのまま送信しても、バックエンジン１３は、処理することができない。

そこで、第３実施形態では、フロントエンジン１２に画像伸長回路１２ｎを設け、圧縮された静止画データをこれで伸長してからバックエンジン１３に送信することにする。

つまり、第３実施形態では、伸長された静止画データを送信するので、これまでのバックエンジン１３がそのまま使えることと、追加される画像圧縮回路１２ｍ及び画像伸長回路１２ｎがフロントエンジン１２側に集約されているので、バックエンジン１３のコストが抑えられる２つのメリットがある。

図６のフロントエンジン１２は、上述した通り、画像圧縮回路１２ｍと共に画像伸長回路１２ｎを備えている。画像伸長回路１２ｎの入力には、ＲＡＷ1バッファ１４ｂの出力(DRAMCの出力ポート)が繋がり、その画像伸長回路１２ｎの出力は、図中のセレクタ１２ｊの第２の入力に繋がっている。静止画の圧縮データは、先ずＲＡＷ1バッファ１４ｂから読み出されて画像伸長回路１２ｎに送られ、次いで、その圧縮データが伸長されて画像伸長回路１２ｎから出力され、更にセレクタ１２ｊを通って第２の出力撮像インターフェース１２ｋに送られ、最後にその第２の入力撮像インターフェース１２ｋからバックエンジン１３に送信される。

伸長後の静止画データは、元の量に戻っている(増える)が、第２の画像データ送信路の送信レートに合わせて伸長が行われるので予定通りピクセルレートは低減される。

尚、図５と図６において、フロントエンジン１２内の第１のプリプロセス回路１２ｈ、バックエンジン１３の内の第１のポストプロセス回路１３ｊとは、合わせて１つの画像処理回路(画像処理回路Ｇ１：点線の枠内参照)を構成している。尚、図では「画像処理」と表記する。

また、バックエンジン１３内の第２のプリプロセス回路１３ｍと第２のポストプロセス回路１３ｐとは、合わせて１つの画像処理回路(画像処理回路Ｇ２：点線の枠内参照)を構成している。尚、図では「画像処理」と表記する。

つまり、バックエンジン１３は、低解像度用の第１の入力撮像インターフェース１３ａが受信した第１の画像データを画像処理回路Ｇ１により画像処理を施すと共に、高解像度用の第２の入力撮像インターフェース１３ｋが受信した第２の画像データを画像処理回路Ｇ２により画像処理を施す。したがって、バックエンジン１３では、第１の画像データと第２の画像データとを独立に画像処理することができる。

以上が２つの画像データ送信路を備えたフロントエンジン１２とバックエンジン１３における画像データの流れの全貌である。

続いて、フロントエンジン１２のＤＲＡＭ１４上にＲＡＷ1バッファ１４ｂを多数設けた時の連写について補足説明する。図３を用いて静止画撮影における画像データの流れを説明した時には、電子カメラ１では、静止画データがＲＡＷ1バッファ１４ｂに記憶された後、静止画データを無条件に読み出してバックエンジン１３に送信するような記載をしたが、実際は、バックエンジン１３側のＲＡＷ2バッファ１５ｃが空いていないと送信することはできない。

一方、ＲＡＷ1バッファ１４ｂが空いていない時は、撮像回路１１から静止画データを出力することができない。露光終了後に画像データを長く撮像回路１１(撮像センサ)内に留めておくことはできないので、ＲＡＷ1バッファ１４ｂが空いていない時は露光を始めるべきではない。

つまり、フロントエンジン１２は、撮影した静止画データを勝手にバックエンジン１３に送信してはならず、また、フロントエンジン１２も勝手に静止画の撮影を開始してはならない。

画像の撮影のシーケンスは、バックエンジン１３側のＣＰＵ１３ｅにより撮影シーケンス制御手段として制御されているので、ＲＡＷ1バッファ１４ｂに静止画データが記憶されており、且つＲＡＷ2バッファ１５ｃが空いている時だけフロントエンジン１２からバックエンジン１３にデータ送信コマンドを発行し、また、ＲＡＷ1バッファ１４ｂが空いている時だけフロントエンジン１２からバックエンジン１３に静止画撮影コマンドを送信する。

つまり、静止画撮影時は、フロントエンジン１２がＲＡＷ1バッファ１４ｂとＲＡＷ2バッファ１５ｃの状態を確認した上でコマンドを発行するが、このうちＲＡＷ1バッファ１４ｂの状態を確認する時には、バックエンジン１３とフロントエンジン１２間の通信が発生する。この場合、撮影シーケンス制御手段は、撮影時において、フロントエンジン１２に撮影シーケンスのコマンドを送信する。そして、フロントエンジン１２は、コマンドを受信して、撮像回路１１の撮像と画像データの読み出しとの少なくとも一方の動作を制御する。これにより、バックエンジン１３側で撮影のシーケンスを制御するため、フロントエンジン１２側では、高ピクセルレートの撮像センサとの通信制御に特化することができる。すなわち、バックエンジン１３側では汎用のバックエンジンを採用できる。

一方、バックエンジン１３に撮像回路を直接接続している従来の電子カメラの場合、高ピクセルレートの画像データを受信しないことを前提としているため、ＲＡＷ2バッファが空いていれば静止画の撮影が開始できるという違いがある。

以上より、第３実施形態の電子カメラ２によれば、伸長された静止画データを送信するので、これまでのバックエンジン１３がそのまま使える。また、電子カメラ２によれば、追加される画像圧縮回路１２ｍ及び画像伸長回路１２ｎがフロントエンジン１２側に集約されているので、バックエンジン１３のコストを抑えることができる。従って、電子カメラ２によれば、汎用性の高いカメラシステムを構築することができる。

（第４実施形態）
次に、第４実施形態について説明する。第４実施形態では、上述したコマンドについてより詳細に説明するため、ソフトウェアの視点から静止画の撮影を考察する。目的はソフトウェアの共通化と再利用である。先ず、比較例として、バックエンジンだけを持つ（フロントエンジンを必要としない）従来の電子カメラのソフトウェア(ファームウェア)を説明する。

図７は、従来の電子カメラで利用されるソフトウェアの構造の一例を示す図である。図７において、ソフトウェアは、アプリケーション層１０１、ミドルウェア層１０２、カーネル層１０３、デバイスドライバ層１０４及びハードウェア層１０５を有する。

最上位層は、アプリケーション層１０１であり、その製品固有の機能を実現するプログラムで構成される。

図７には、電子カメラの主な機能を実現するアプリケーションプログラムが載っており、これらのプログラムは、その下位にあるプログラムを呼び出すことによって目的の機能を実現する。つまり、下位のプログラムを呼び出すためのＡＰＩが用意されている。ＡＰＩとしては、例えば、静止画撮影１０１ａ、動画撮影１０１ｂ、ライブビュー１０１ｃ、画像再生１０１ｄ、画像通信１０１ｅ、カメラ設定１０１ｆが用意されている。これらのＡＰＩを標準化しておくことでそのアプリケーションプログラム別の電子カメラで利用することができる。アプリケーション層１０１の下はミドルウェア層１０２であり汎用的なライブラリソフトもここに含めている。ミドルウェア層１０２としては、例えば、ミドルウェア１０２ａ及びライブラリ１０２ｂを有する。

カーネル層１０３は、ＲＴＯＳ（Real Time Operating System）１０３ａを有する。また、デバイスドライバ層１０４は、その他の周辺ドライバ１０４ａ、画像処理ドライバ１０４ｂ、撮像ドライバ１０４ｃを有する。ハードウェア層１０５は、ハードウェア制御用のソフトウェアとして、その他の周辺ハードウェア１０５ａ、バックエンジン１０５ｂ、撮像回路１０５ｃを有する
ここで、ライブラリ１０２ｂには、ソフトウェアベンダから購入するものもある。ミドルウェア層１０２は、複数のアプリケーションプログラムが利用するような共通性の高いプログラムで構成されるが、重要なことはハードウェアの詳細構造に依存しないようなプログラムにすることである。例えば、画像のサイズを変更する解像度変換(変倍)等は、画像の撮影でも画像の再生でも利用されるが、その処理は、バックエンジン１３内の画像処理回路(ポストプロセス回路)１３ｂ（図３参照）で実行される。

しかし、ミドルウェア層１０２のプログラムは、ポストプロセス回路を直接動かすことはせず、一例として、変倍前の画像データが記憶されたバッファメモリのアドレス、変倍前の画像サイズ、変倍前の画像から解像度変換対象の画素を切り出すための座標値と切り出しサイズ、変倍後の画像データを記憶するバッファメモリのアドレス、変倍後の画像サイズ(または倍率)等の引数を指定して下位のプログラムを呼び出す。

例えば、解像度変換の機能を呼び出すＡＰＩでは、その解像度変換の機能の処理を何に行わせるかは指定していない。つまり、解像度変換を行うハードウェアに依存しないようにＡＰＩが構成されている(抽象化)。実際にポストプロセス回路を起動させるのは、このＡＰＩによって呼び出されたプログラムである。

具体的には、デバイスドライバ層１０４のプログラムである画像処理ドライバ１０４ｂがポストプロセス回路を起動させる。ミドルウェア層１０２の下は、カーネル層１０３であり、ＲＴＯＳ１０３ａが置かれている。上述した通り、電子カメラでは、複数の処理が並列に実行されるが、これらの処理を行うプログラムをＲＴＯＳ１０３ａのタスクとすることで並列処理が実現される。カーネル層１０３の下は、デバイスドライバ層１０４であり、その下のハードウェア層１０５に含まれる色々なハードウェアを動かすプログラムが置かれる。

ハードウェア層１０５には、画像処理回路(プリプロセス回路、ポストプロセス回路)、JPEGコーデック、ＬＣＤコントローラ、ＣＡＲＤコントローラ、ＵＳＢコントローラ等を備えるバックエンジン内部の回路の他、撮像回路やバックエンジンに繋がった周辺デバイス等が含まれる。

デバイスドライバ層１０４を設けることでハードウェアが抽象化されるため、ハードウェアが変わっても、デバイスドライバを変更するだけで上位のプログラムは、そのまま動かすことができる。

但し、上位層のプログラムから下位層のプログラムを呼び出すＡＰＩは、標準化する必要がある。以上のことを踏まえた上で、電子カメラ１のソフトウェアについて説明する。

＜電子カメラ１のソフトウェアについて＞
電子カメラ１は、フロントエンジン１２を新たに備えているが、従来の電子カメラのソフトウェアとの共通化を図るため、このフロントエンジン１２を抽象化することを既に説明した。

図８は、仮想撮像回路を説明する図である。具体的には、図８に示す通り、フロントエンジン１２とそれに繋がった撮像回路を合わせて仮想的な撮像回路として抽象化する。つまり、フロントエンジン１２の出力撮像インターフェース(SIFo1とSIFo2)は、撮像回路が画像データを出力するためのインターフェースと同じものである。これにより、仮想的な撮像回路という抽象化が実現する。この抽象化を行うことにより、図８の左側の回路は、右側の回路のように見える。換言すると、図８の左側の回路と右側の回路とは、等価回路として扱うことができる。これ以降は、仮想的な撮像回路のことを「仮想撮像回路」、従来の電子カメラで使われる撮像回路（図１０参照）のことを「普通撮像回路」、電子カメラ１のフロントエンジン１２に繋がっている撮像回路（図８の左側）を「高速撮像回路」と呼んで区別する。

抽象化とは、図８に示す高速撮像回路１１ａとフロントエンジン１２とを一体化して仮想的な仮想撮像回路３０と見なすことであるが、この仮想撮像回路３０が普通撮像回路（例えば、図１０に示す撮像回路５２）と同じように動作させることが重要である。これにより、従来の電子カメラのソフトウェアがそのまま利用できるからである。これが抽象化の目的である。

普通撮像回路は、バックエンジン１３が直接受信できるピクセルレートの画像データを出力する。一方、仮想撮像回路３０から出力される画像データは、ピクセルレートが低減されており、バックエンジン１３で直接受信することができるので、機能上の類似性は備えている。

フロントエンジン１２が２つの出力撮像インターフェース(SIFo1とSIFo2)を備えていることに対応して仮想撮像回路３０も画像データ出力用のインターフェースを２つ持つが、普通撮像回路の方は、インターフェースが１つなのでその点が大きな違いとなっている。

但し、ソフトウェア的な観点から見ると、インターフェースの数が異なる点は、特に問題にならない。この違いは、デバイスドライバ層１０４で遮蔽されて上位層のプログラムには、見えないからである。重要なのは機能上の違いである。その違いとは、仮想撮像回路３０は、２つの異なる画像データを同時に出力できる点であり、これは、既に説明したフロントエンジン１２の動作に対応している。図８の右側の仮想撮像回路３０から外に向かう実線の矢印からは、ライブビューの画像データが出力される。また、点線の矢印からは、静止画データや記録用の動画データが出力される。

つまり、ライブビューを行いながら撮影された静止画データを出力したり、ライブビューを行いながら記録用の動画データを出力したりする並列動作ができる。

一方、普通撮像回路から２つの異なる画像データを出力する場合、シーケンシャル動作となる。普通撮像回路の場合、１つの画像データ出力モードが終わってから別の画像データ出力モードに移るが、仮想撮像回路３０の場合、１つの画像データ出力モードを動作させたまま別の画像データ出力モードを動作させることができるので、制御のシーケンスが異なっている。

図８の右側の回路と図１０の回路とは、見かけ上同じであるものの、制御のシーケンスが異なっているので、電子カメラ１と電子カメラ５０とではソフトウェアが若干異なる。

しかし、仮想撮像回路３０という抽象化によって上位層のソフトウェアは、かなり共通化される。つまり、仮想撮像回路３０を動かすのに従来とほぼ同じＡＰＩが使えることになり、上位層のプログラムは、このＡＰＩを呼び出すことによって画像の撮影を行うことができる。上述したように若干の変更は必要なものの、ほぼ同じＡＰＩを用いて作成することができるため、上位層のプログラムは、従来の電子カメラの上位層のプログラムを適宜用いることができる。

図８の右側の回路において、バックエンジン１３から仮想撮像回路３０に向かう矢印は、仮想撮像回路３０を動かすための仮想制御信号である。この仮想制御信号も抽象化の一部であって上述したＡＰＩを用いて制御される。仮想撮像回路３０という抽象化を行った結果、バックエンジン１３側のソフトウェアは、図９の左側のようになる。

図９は、電子カメラ１のソフトウェアの構造の一例を示す図である。図９の左側のデバイスドライバ層１０４には、ソフトウェアインターフェースの一種である仮想撮像ドライバ１０４ｄがあって、これが図８の右側の仮想撮像回路３０を動作させる。この仮想撮像ドライバ１０４ｄは、上述したＡＰＩを用いて上位層のプログラムから呼び出されるが、その下のハードウェア層１０５には撮像回路がないため、実際の処理は、図７に示す撮像ドライバ１０４ｃとは異なる。つまり、仮想撮像ドライバ１０４ｄは、更にその下にある通信ドライバ１０４ｅを呼び出し、この通信ドライバ１０４ｅが撮像に関わるコマンドとパラメータをフロントエンジン１２に送信する。

上述したＡＰＩは、上位層のプログラムから呼び出されるので、その引数も上位層の情報が少数渡されるだけである。そのため、フロントエンジン１２に送られるパラメータも少量になって通信のオーバーヘッドが抑えられる。

図９の左側のハードウェア層１０５には、通信Interface１０５ｄがあり、通信にはこのインターフェースが使われる。仮想撮像回路３０からは、画像データが出力されるのでバックエンジン１３内部の画像処理回路１３ｂは、通信Interface１０５ｄから送られた情報を受信して処理しなければならず、上位層のプログラムが仮想撮像ドライバのＡＰＩを呼び出す時には、図９に示す左側の画像処理ドライバ１０４ｂのＡＰＩも併せて呼び出す必要がある。仮想撮像回路３０の２つのインターフェースは、この画像処理ドライバ１０４ｂが吸収するので上位のＡＰＩからは見えない。

図９の左側のデバイスドライバ層１０４を見ると、図７のデバイスドライバ層１０４と同様の構成になっており、電子カメラ１のソフトウェアを従来の電子カメラと共通化する目標がかなり達成されていることが分かる。

続いて、図９の右側に示されたフロントエンジン１２側のソフトウェアについて説明する。フロントエンジン１２側のソフトウェアもバックエンジン１３側と同じように階層化されている。フロントエンジン１２側のソフトウェアは、アプリケーション層２０１、ミドルウェア層２０２、カーネル層２０３、デバイスドライバ層２０４及びハードウェア層２０５を有する。

アプリケーション層２０１は、静止画撮影２０１ａ、動画撮影２０１ｂ及びライブビュー２０１ｃを有する。ミドルウェア層２０２は、ミドルウェア２０２ａ及びライブラリ２０２ｂを有する。カーネル層２０３は、ＲＴＯＳ２０３ａを有する。デバイスドライバ層２０４は、画像処理ドライバ２０４ａ、通信ドライバ２０４ｂ及び撮像ドライバ２０４ｃを有する。ハードウェア層２０５は、フロントエンジン２０５ａ、通信Interface２０５ｂ及び撮像回路２０５ｃを有する。

一番下層のハードウェア層２０５の通信Interface２０５ｂは、バックエンジン１３から送られた情報を受信する。これは物理層の見方であって、この情報をその上のデバイスドライバ層２０４にある通信ドライバ２０４ｂが受信するのが論理層の見方になる。

フロントエンジン１２がレスポンスを返す時には、逆方向に情報が送信される。ハードウェア層２０５にある撮像回路２０５ｃとは、高速撮像回路１１ａのことであり、この高速撮像回路１１ａからは高ピクセルレートの画像データが出力される。

高速撮像回路１１ａは、その上のデバイスドライバ層２０４の撮像ドライバ２０４ｃによって駆動される。ハードウェア層２０５の残り１つは、フロントエンジン１２内部ブロックをまとめて表したものであり、これらのブロックは何れも高速撮像回路１１ａから出力された画像データの処理に関わる。

これらのブロックは、１つ上のデバイスドライバ層２０４にある画像処理ドライバ２０４ａによって駆動される。その上のソフトウェアもバックエンジン１３側と同様の構成となっているが、その中でアプリケーション層２０１のプログラムについて補足説明する。

フロントエンジン１２側には、静止画撮影２０１ａ、動画撮影２０１ｂ及びライブビュー（LiveView）２０１ｃ等のアプリケーションプログラムが記載されている。これらのアプリケーションプログラムは、バックエンジン１３側のアプリケーションプログラムに対応するコマンドを解釈するだけのプログラムである。静止画撮影２０１ａ、動画撮影２０１ｂ及びライブビュー２０１ｃの３つのアプリケーションプログラムは、電子カメラの基本動作モードであり、これらのアプリケーションプログラムは、アプリケーション層２０１で決定されるが、その情報はアプリケーション層２０１よりも下位層にも伝えられる必要がある。

その理由は、動作モードによって画像データの処理内容やデータの経路が変わるからである。そこで、バックエンジン１３から受信したコマンドとパラメータを先ずアプリケーションプログラムに渡してそのコマンドを解釈する。これにより、動作モードが確定したら一緒に受信したパラメータを引数にして上述したＡＰＩを呼び出し、モードに応じた動作を行わせる。これにより、フロントエンジン１２側のソフトウェアもバックエンジン１３側と同様な階層構造となる。

しかし、フロントエンジン１２側の階層構造は、一例であって、更に単純な階層構造であっても良い。また、フロントエンジン１２側の機能は限られているので、汎用のライブラリの使用を少なくしても良い。

一方、フロントエンジン１２側では、ライブビューを行いながら静止画データをバックエンジン１３に送信したり、仮想撮像回路３０から出力された画像データを、ＤＲＡＭ１４内のＲＡＷ1バッファ１４ｂに記憶しながら別のＲＡＷ1バッファ（不図示）から読み出した画像データをバックエンジン１３に送信したりするような並列処理を行う。そのため、フロントエンジン１２側にもＲＴＯＳ２０３ａを導入してマルチタスク処理を行う必要がある。インターフェースが２つあるために仮想撮像回路３０の動作は、普通撮像回路と少し異なると述べたが、その他に違いとして、特に静止画撮影の場合について説明する。

先ず、普通撮像回路と高速撮像回路１１ａの動作は、（i）被写体を露光して撮像センサに信号電荷を蓄積する、（ii）蓄積された電荷信号をデジタルデータに変換して各々の撮像回路から出力する、の２つから成っている。

電子カメラ５０における静止画撮影では、条件（ii）で普通撮像回路（図１０の撮像回路５２）から出力された静止画データがバックエンジン５１で受信され、次いでプリプロセス回路でプリプロセスが施されてRAWバッファ５３ｄに記憶されるという動作が行われる。

一方、図８に示す通り、仮想撮像回路３０の動作も、（I）被写体を露光してデジタルの静止画データを生成する、（II）(生成された静止画データを高速撮像回路１１ａから出力する、という２つの条件に分けることができる。

電子カメラ１における静止画撮影では、仮想撮像回路３０が条件（I）と条件（II）との動作を順次行っており、条件（II）の場合、仮想撮像回路３０から出力された静止画データが従来の電子カメラと同様、バックエンジン１３側で受信されて処理される。仮想撮像回路３０の動作は、高速撮像回路１１ａとフロントエンジン１２の動作から成るので、条件（I）と条件（II）とがそれらの何の動作に対応しているのかについて説明する。

高速撮像回路１１ａの動作は、条件（i）と条件（ii）とから成るが、フロントエンジン１２の動作は、（a）高速撮像回路１１ａから出力された静止画データをＲＡＷ1バッファ１４ｂに記憶する、（b）ＲＡＷ1バッファ１４ｂに記憶された静止画データを読み出してバックエンジン１３に送信する、の２つの条件から成っている。

このうち、条件（ii）と、条件（a）とは、並列動作なので、高速撮像回路１１ａとフロントエンジン１２とが連動しているが、条件（i）の方は、高速撮像回路１１ａの単独の動作になる。条件（b）の動作は、フロントエンジン１２とバックエンジン１３とが連動しているものの高速撮像回路１１ａの動作とは独立しており、この時は、送信された静止画データにプリプロセスを施してＲＡＷ2バッファ１５ｃに記憶する動作がバックエンジン１３側で並行して行われる。フロントエンジン１２の条件（b）の動作は、普通撮像回路の条件（ii）の動作や、仮想撮像回路３０の条件（II）の動作に対応すると考えるのが自然である。

すると、仮想撮像回路３０の条件（I）の動作は「高速撮像回路１１ａの動作（条件（i））＋高速撮像回路１１ａの動作（条件（ii））＋フロントエンジン１２の動作（条件（a））」に対応させるのが好ましい。

つまり、高速撮像回路１１ａによる被写体の露光からＲＡＷ1バッファ１４ｂに静止画データが記憶されるまでの動作が仮想撮像回路３０の条件（I）の動作に対応し、ＲＡＷ1バッファ１４ｂに記憶された静止画データを読み出してバックエンジン１３に送信する動作が仮想撮像回路３０の条件（II）の動作に対応すると考える。仮想撮像回路３０の２つの動作を上述したように対応させた場合、仮想撮像回路３０の条件（I）の動作と普通撮像回路（例えば、撮像回路５２）の条件（i）の動作が同じであり、仮想撮像回路３０の条件（II）の動作と普通撮像回路の条件（ii）の動作が同じであると考えることができるか否かを検討する。

これらの動作が同等であれば静止画撮影のソフトウェアも従来の電子カメラがそのまま使えることになる。しかし、２つの撮像回路（普通撮像回路、仮想撮像回路）の動作には違いがある。フロントエンジン１２側には、ＲＡＷ1バッファ１４ｂが幾つも設けられているので、撮影した静止画データをそこに蓄積していく動作を行うことができる(ＲＡＷバッファ連写)。

一方、それと並行して先に撮影された静止画データをＲＡＷ1バッファ１４ｂから読み出してバックエンジン１３に送信する動作が行われる。

前者(ＲＡＷバッファ連写)は、条件（I）の動作であるが、これは仮想撮像回路３０の「露光動作」と考えることができる。後者は、条件（II）の動作であるが、これは仮想撮像回路３０の「静止画データの出力動作」と考えることができる。普通撮像回路の露光動作である条件（i）と、静止画データの出力動作である条件（ii）とは不可分な動作であるが、仮想撮像回路３０の条件（I）と条件（II）の動作には違いがある。不可分とは、撮影された静止画データを撮像回路から出力するまでは、次の静止画の露光を開始することができない意味である。条件（i）と条件（ii）の動作が不可分であることは、高速撮像回路１１ａも同じである。

一方、仮想撮像回路３０の場合、電子カメラ１では、撮影した静止画データを出力する前に、次の静止画の露光を始めることができる特徴がある。つまり、撮影した静止画データを仮想撮像回路３０の中に溜めておくことができる。これは、ＲＡＷ1バッファ１４ｂを幾つも持っているために生じた特性である。撮影した静止画データを仮想撮像回路３０から出力した後で次の静止画の露光を始めるとした場合、ＲＡＷ1バッファ１４ｂは、１つでも構わないことになり、それを幾つも設ける理由がなくなる。従って、電子カメラ１では、ＲＡＷ1バッファ１４ｂを幾つも設けることで静止画データの出力動作に依存しない高速な連写が可能になる。

但し、空いているＲＡＷ1バッファ１４ｂが無くなった時には、次の露光を始めてはならない。仮想撮像回路３０という抽象化を行うとバックエンジン１３側の上位層のプログラムからはＲＡＷ1バッファ１４ｂが見えないため、仮想撮像回路３０では「State1」の状態を設ける。これにより、仮想撮像回路３０では、ＲＡＷ1バッファ１４ｂが空いていない時には、State1をＢＵＳＹに設定し、ＲＡＷ1バッファ１４ｂが空いた時には、State1をREADYに設定し、この情報を利用する。

このState1の状態は、仮想撮像ドライバ１０４ｄから上位層のプログラムに伝えられる。静止画撮影を行うプログラムは上述したＡＰＩを呼び出して仮想撮像ドライバ１０４ｄからState1の状態を取得し、これがBUSYの時には、仮想撮像回路３０は、READYになるまで待ちState1がREADYになったら露光を始める。

一方、撮影した静止画データを仮想撮像回路３０から出力する場合にも似たような事情がある。つまり、ＲＡＷ1バッファ１４ｂが空の時には、仮想撮像回路３０は、静止画データを出力することができない。そこで仮想撮像回路３０では、もう１つ「State2」の状態を設ける。これにより、仮想撮像回路３０では、ＲＡＷ1バッファ１４ｂに静止画データが記憶されている時には、State2をREADYに設定し、ＲＡＷ1バッファ１４ｂが空の時は、State2をBUSYに設定し、この情報を利用する。

このState2の状態も仮想撮像ドライバ１０４ｄから取得される。バックエンジン１３側のＲＡＷ2バッファ１５ｃが空いていない時には、仮想撮像回路３０は、静止画データを出力することができないので、その状態もチェックしなければならない。State1やState2の状態は、仮想撮像ドライバ１０４ｄが通信ドライバ１０４ｅを介してフロントエンジン１２側から取得するが、ＲＡＷ2バッファ１５ｃの状態は、バックエンジン１３側で取得される。

画像撮影用のソフトウエアの一つである静止画撮影のプログラムは、先ず、ＲＡＷ2バッファ１５ｃの状態をチェックし、それが空いている時には、上述したＡＰＩを呼び出して仮想撮像ドライバ１０４ｄからState2の状態を取得する。State2の状態がBUSYの時には、静止画撮影のプログラムは、READYになるまで待ちState2がREADYになったら静止画データの出力を開始する。尚、いわゆる処理の終了を定期的にチェックするＡＰＩ(ポーリング)の代わりに割り込みを利用して次の露光開始のタイミングや、次の静止画データ出力のタイミングを知る方がプログラムの中断が減るので効率が上がる。

つまり、仮想撮像回路３０のState1やState2の状態がREADYになる度に割り込みが発生し、次の露光や静止画データ出力が可能になったことを仮想撮像ドライバ１０４ｄから静止画撮影のプログラムに伝える。

但し、State2割り込みは、単独ではなくＲＡＷ2バッファ１５ｃ（図３参照）の状態とのAND（論理積）で発生するようにしておく。割り込みが発生した時には、静止画撮影プログラムが上述したＡＰＩを呼び出して仮想撮像回路３０に露光や静止画データの出力を行わせるが、上述したようにこれらの２つは独立した動作であるため、そのＡＰＩも別々に用意する必要がある。

つまり、静止画撮影のプログラムは、発生した割り込みに応じてそれぞれのＡＰＩを呼び出す。一方、普通撮像回路の場合には、これらの２つが不可分(一体的)な動作であるため、静止画撮影のプログラムは、１つのＡＰＩで呼び出すことができる。仮想撮像回路３０の場合には、State1がREADYであれば露光を行うことができ、State2がREADYでＲＡＷ2バッファ１５ｃが空いていると静止画データを出力することができる。ここで、この２つの動作の進み方はどちらの方が速いかが問題となる。

仮想撮像回路３０の露光動作では、撮影した静止画データをＲＡＷ1バッファ１４ｂに記憶するまでの動作が行われ、静止画データの出力動作では、この静止画データをＲＡＷ1バッファ１４ｂから読み出してバックエンジン１３に送信する動作が行われる。

後者の静止画データの出力動作では、ピクセルレートの低減が行われるため、その出力動作の進み方の方が遅れる傾向がある。バックエンジン１３側の処理が遅いと、この遅れは更に大きくなる。そのため、ＲＡＷ2バッファ１５ｃを複数設けて静止画データの出力が滞らないようにしているものの、バックエンジン１３側には、他のバッファメモリ(YCbCr1，YCbCr2，JPEG等)も設けられているので限界がある。

つまり、ＲＡＷバッファ連写の場合、撮影された静止画データが仮想撮像回路３０の中に複数残っている状態が発生する。この状態で露光を行う場合も静止画データを出力する場合もそれぞれコマ番号を指定する必要がある。コマ番号を指定しないと撮影順序を取り違えてしまう恐れがあるからである。そこで、上述した２つのＡＰＩにもそれぞれコマ番号という引数を設けることにする。静止画撮影において、仮想撮像回路３０の２つの機能(動作)を呼び出すＡＰＩ関数としては以下のようなものが考えられる。
露光動作 ： SensorExposure(n，・・・) ----- （３−１）
静止画データの出力動作 ： StillImageDataOut(m，・・・) ----- （３−２）
SensorExposure( )という関数の括弧内の「n」は露光(撮影)時のコマ番号を指定するための引数である。それ以外の引数は「・・・」で表されているが、ここには、露光時間や撮像回路の感度等が入る。

一方、StillImageDataOut( )という関数の括弧内の「m」は仮想撮像回路３０から静止画データを出力する時のコマ番号を指定する引数である。最後に露光(撮影)されたコマ番号を「Nmax」とすれば常に「m≦Nmax」となる。露光時のコマ番号nの初期値は「0」であり、静止画撮影プログラムは露光を開始する前にnを「1」増やしてから露光動作のＡＰＩ関数を呼び出す。

従って、露光時のコマ番号nは、「1→2→3→・・・」というように単純に1ずつ増えていく。露光時のコマ番号nは、仮想撮像回路３０の中に送られ撮影後その中に蓄積されている静止画データとセットで管理される。この管理は、フロントエンジン１２側のプログラムで行われる。これにより、仮想撮像回路３０内に蓄積されている静止画データがそれぞれ何コマ目に撮影されたものなのか常に知ることができる。静止画撮影プログラムは、露光時のコマ番号nを管理して撮影したコマ数が分かるようにする。

一方、静止画データ出力時のコマ番号mの初期値も「０」であるが、こちらの方は、仮想撮像回路３０内に残っている静止画データのどれでも出力することもできるので自由度がある。

しかし、通常、撮影した順に静止画データを出力していくので、静止画撮影のプログラムは、出力を開始する前にmを「１」増やしてから静止画データの出力動作のＡＰＩ関数を呼び出す。従って、静止画データ出力時のコマ番号mも「1→2→3→・・・」というように単純に１ずつ増えていく。このコマ番号mも仮想撮像回路３０の中に送られて内部に残っている静止画データのコマ番号nと比較され、それらのコマ番号が一致した静止画データが選択されて仮想撮像回路３０より出力される。

フロントエンジン１２側のプログラムは、バックエンジン１３から受信した静止画データ出力コマンドに対するレスポンスの中に出力した静止画データのコマ番号(m＝n)を入れて返信する。レスポンスのコマ番号は、先ず、バックエンジン１３側の通信ドライバ１０４ｅで受信され、次いで、その上の仮想撮像ドライバ１０４ｄを介して静止画撮像プログラムに伝えられる。この静止画撮影プログラムがコマ番号をやり取りすることによって、コマ番号を正しく把握しつつ撮影された静止画データを処理していくことができる。

静止画撮影プログラムは、静止画データ出力時のコマ番号mを管理してどの静止画データが出力されたのか分かるようにする。静止画撮影プログラムは、露光時のコマ番号nと静止画データ出力時のコマ番号mの両方を管理することにより、何コマ目の静止画データが未だ仮想撮像回路３０内に残っているのか常に知ることができる。

ところで、「撮影した順に仮想撮像回路３０から静止画データを出力する」と先に述べたが、StillImageDataOut( )のようなＡＰＩを用いると仮想撮像回路３０内に残っているどの静止画データを出力することもできる。

つまり、StillImageDataOut( )のようなＡＰＩは、撮影順とは異なる順序で仮想撮像回路３０から静止画データを出力する動作もできる。電子カメラの製品の仕様次第ではあるが、この動作によって、電子カメラに新しい特徴を持たせることができる。

具体的には、ＲＡＷバッファ連写を行っている時に、突然再生ボタン(PLAYボタン)が押された場合には、再生モードに移る設定にする。この場合、撮影された静止画のどれから再生していくのが適切かと言えば、静止画の再生モードでは最後に撮影された(最新の)静止画からコマ番号を遡って再生していくのが好ましい。

すると、中断された連写の最後に撮影された静止画データを先に出力して再生することになるが、StillImageDataOut( )のようなＡＰＩ関数であれば、コマ番号mを指定して静止画データを出力することができるので目的の再生が実現される。

尚、StillImageDataOut( )の引数は、コマ番号m以外、必要なものがあれば適宜追加しても良い。（３−１）の露光動作及び（３−２）の静止画データの出力動作のＡＰＩを用意することにより電子カメラ１は多様な動作を行うことができる。

ところで、従来の電子カメラの静止画撮影では、普通撮像回路の露光動作と、静止画データの出力動作が不可分(一体的)に行われるため１つのＡＰＩで呼び出されることを先に述べた。

そこで、静止画撮影時の普通撮像回路の動作を見ていくことにする。この普通撮像回路の動作は、例えば、以下の２つの条件に分類される。
［１］露光動作が終わると自動的に静止画データの出力が始まるもの
［２］露光動作開始時と静止画データ出力開始時にそれぞれ別の操作が必要なもの
条件［１］のタイプは、２つの動作が文字通り不可分であり１つのＡＰＩで呼び出すしかない。一方、条件［２］のタイプは、２つの動作が別々の操作によって起こるので不可分とは別の意味になる。

つまり、撮影(露光)した静止画データを出力するまでは、次の露光を始めないというシステム的な意味の不可分性である。上位層の静止画撮影プログラムからは、この２つが１つの動作に見えても良いので、１つのＡＰＩで呼び出しているが、そのＡＰＩによって呼び出される撮像ドライバ１０４ｃ（図７参照）の中では、２つのシーケンシャルな動作に分かれている。つまり、条件［２］のタイプの２つの動作は、撮像ドライバ１０４ｃの中で分かれて実行されており、静止画撮像プログラムから見えないだけである。

しかし、２つの動作に分かれているのなら静止画撮影プログラムのＡＰＩからそれらを呼び出しても良い。つまり、（３−１）の露光動作及び（３−２）の静止画データの出力動作のＡＰＩが利用できることになるが、それは、普通撮像回路を仮想撮像回路３０のように眺めることを意味する。そのような見方をする場合には、仮想撮像回路３０内のＲＡＷ1バッファ１４ｂの数が１つと考えなければならない。ＲＡＷ1バッファ１４ｂが１つであれば、そこに記憶された静止画データを出力しないと次の露光が始められない不可分性が再現される。

また、仮想撮像回路３０のState1とState2との２つの状態が普通撮像回路にもそのまま適用される。つまり、普通撮像回路内にある１つの仮想的なＲＡＷ1バッファが空いている時には、State1がREADYでState2がBUSY、そこに撮影された静止画データが記憶されている時はState1がBUSYでState2がREADYになる。

これらの状態によって割り込みが発生するようにすれば、普通撮像回路の露光や静止画データ出力のタイミングが分かるので、この割り込みを利用して連写を続けていくことができる。このState1とState2の状態は、図７の撮像ドライバ１０４ｃから上位層の静止画撮影プログラムに伝えられる。普通撮像回路の場合、露光動作終了から静止画データの出力動作開始まで時間を置いてはならない(電荷信号が劣化するため)。

従って、静止画撮影プログラムは、上述した（３−１）の露光動作及び（３−２）の静止画データの出力動作のＡＰＩを続けて呼び出すようにする。その場合には、静止画撮影プログラムは、２つコマ番号を一致(m＝n)させなければならない。ＲＡＷ1バッファ１４ｂが１つしかないので、これは当然のことである。この点に注意すれば従来の電子カメラでも（３）のＡＰＩを用いて静止画の撮影を行うことができる。続いて、条件［１］のタイプの普通撮像回路に移るが、こちらは２つのＡＰＩに分けることはできず、１つのＡＰＩでその機能(動作)を呼び出すしかない。

しかし、仮想撮像回路３０と普通撮像回路の機能(動作)を呼び出すＡＰＩを条件［１］のタイプのＡＰＩに合わせることはできる。先ず、露光時のコマ番号nと静止画データ出力時のコマ番号mの他に、露光動作を表す「exp_op」と静止画データの出力動作を表す「dout_op」という合計４つの引数を導入する。「exp_op」や「dout_op」の「op」は「operation」を意味する。「exp_op」と「dout_op」は「１」と「０」の値を取るが、「１」は「動作状態」を表し「０」は「非動作状態」を表している。更に静止画撮影プログラムから呼ばれるＡＰＩ関数として以下のものを１つだけ用意する。
SendorDrive(exp_op，n，dout_op，m，・・・) ----- （４）
条件［１］のタイプの普通撮像回路の場合には、静止画撮影プログラムが上述した引数を以下のように設定してこのＡＰＩ関数を呼び出す。

条件［１］のタイプの普通撮像回路 ：SendorDrive(1，n，1，n，・・・) ----- （５）
ここで、露光動作と静止画データの出力動作の２つが不可分に行われるので、（５）のＡＰＩ関数のように１回のＡＰＩコールで良いことになる。このＡＰＩ関数によって図７に示す撮像ドライバ１０４ｃが呼び出され、その中で先ず露光動作が行われ、それが終了すると自動的に静止画データの出力動作が行われる。

続いて、条件［２］のタイプの普通撮像回路であるが、これも（５）のＡＰＩ関数をそのまま利用することができる。但し、この場合、撮像ドライバ１０４ｃの中で露光動作と静止画データの出力動作が分かれて実行される。撮像ドライバ１０４ｃは、普通撮像回路を操作して先ず露光動作を行い、それが終わると別の操作を行って静止画データの出力を行う。静止画撮影プログラムからは、これらが１つの動作に見えるので、普通撮像回路のタイプ応じて撮像ドライバ１０４ｃを用意する必要がある。

しかし、条件［２］のタイプの場合には、静止画撮影プログラムから（４）のＡＰＩ関数を２回呼び出すことによってこの２つの動作を行わせることもできる。この場合には、以下の（６−１）、（６−２）の順に呼び出す。

条件［２］のタイプの普通撮像回路 ：
SendorDrive(1，n，0，0，・・・) ----- （６−１）
SendorDrive(0，0，1，n，・・・) ----- （６−２）
ここで、（６−１）のＡＰＩ関数は、１回目のＡＰＩコールであるが引数の値より露光動作であることが分かる。（６−２）のＡＰＩ関数は、２回目のＡＰＩコールであるが、その引数の値から静止画データの出力動作を呼び出したことが分かる。（６−１）のＡＰＩ関数は、静止画撮影プログラムからも２つの動作に見えるが、露光時のコマ番号と静止画データ出力時のコマ番号が共に「n」で一致しているので不可分な動作になっていることが分かる。つまり、２つの動作を表す引数を導入することにより１つのＡＰＩ関数で２つの動作を呼び出すことができる。従って、（６−１）及び（６−２）のＡＰＩ関数を見れば、仮想撮像回路３０の２つの動作を呼び出すのにこのＡＰＩ関数をどのように使えば良いか容易に分かる。それは以下のようになる。

仮想撮像回路３０の露光動作 ： SendorDrive(1，n，0，0，・・・)
仮想撮像回路３０の静止画データの出力動作 ： SendorDrive(0，0，1，m，・・・)
仮想撮像回路３０の２つの動作は、独立した動作なので露光時のコマ番号は「n」、静止画データ出力時のコマ番号は「m」のように別々の値が設定されている。この設定をすれば、静止画撮影の場合に使われるＡＰＩを電子カメラ５０と電子カメラ１、２で或る程度共通化することができる。

しかし、（４）のＡＰＩは、無理に合わせたようなところがあるので使い難いことが想定される。そこで、使い難い場合には、引数や関数名を見直して使い易いＡＰＩを用意することが好ましい。即ち、重要な点は、ＡＰＩを一致させることではない。ＡＰＩは、或る程度まとまった処理(マクロ的機能)を行う関数であるが、これらのＡＰＩを幾つか組み合わせることで、大きなアプリケーションプログラムの機能が実現されている。つまり、適切なＡＰＩを幾つも用意することが重要になってくる。

また、ＡＰＩの標準化を進めることで、それらが他の機種でも利用できるようになるメリットも出てくる(ソフトウェアの部品化・共通化)。つまり、仮想撮像回路３０という抽象化は、ソフトウェア的に見るとＡＰＩを導入したことになる。

上述したようなＡＰＩ関数を呼び出すだけで仮想撮像回路３０が目的の動作をするので、静止画撮影プログラムは、フロントエンジン１２の複雑な動きを知らなくてもその機能が利用できるようになっている。

仮想撮像回路３０という抽象化によって静止画撮影プログラムが容易に作成できることをこれまで説明してきたが、この抽象化を行った場合、ライブビューや動画撮影の動作がどのようになるか簡単に見ていくことにする。

ライブビューは、静止画撮影モードと動画撮影モードとの２つの画像撮影モードで動作している。画像撮影の場合には、撮影時に設定されている撮影モードでカメラが起動し、ライブビューを行うプログラムが先ず動作してライブビューが始まる。画像の撮影は、レリーズ釦１８が全押しされた時に行われ、それまではライブビューの動作が続く。ライブビューの間は被写体の生画像(スルー画)をＬＣＤパネル１７に表示しており、ユーザはこれを見て撮影時の構図を決めたりシャッタチャンスを知ったりする。

また、ライブビューの間、適宜３Ａ検波が行われており、そこで抽出されたAE評価値やAWB評価値を用いてスルー画の明るさや色が調整される。静止画撮影モードの場合には、AE撮影のための測光演算も行われる。レリーズ釦１８が全押しされると撮影モードに応じてそれぞれの撮影動作に入るが、全押しより先に半押しが行われているのでその時に被写体への焦点調整(AF)が行われる。

この焦点調整(AF)は、AF評価値を利用して行われる。つまり、ライブビューのプログラムの中からは、スルー画データ出力、スルー画表示、輝度調整、WB調整(AWBアルゴリズムを含む)、焦点調整(AF)等を行う幾つものプログラムが呼び出されている。

これらのプログラムもＡＰＩから呼び出される(割り込みを契機に呼び出されるものもある)。その中で仮想撮像回路３０が関係するのは、スルー画データの出力である。ライブビューのプログラムは、スルー画データを出力するためのＡＰＩを呼び出すが、これは、専用のＡＰＩであっても良い。

このＡＰＩから更に仮想撮像ドライバ１０４ｄと画像処理ドライバ１０４ｂが呼び出される（図９の左側）。以下では、フロントエンジン１２の第１の画像データ送信路に対応する仮想撮像回路３０のインターフェースのことを「第１のインターフェース」、第２の画像データ送信路に対応するインターフェースのことを「第２のインターフェース」と呼ぶことにする。仮想撮像ドライバ１０４ｄは、第１のインターフェースからスルー画用の画像データが出力されるように仮想撮像回路３０を設定する。

一方、画像処理ドライバ１０４ｂは、スルー画用の画像データが図５の第１のポストプロセス回路１３ｊで処理されるように画像処理回路を設定する。この場合、画像処理ドライバ１０４ｂは、画像処理回路の設定を先に行う。これにより、仮想撮像回路３０の第１のインターフェース(第１の出力撮像インターフェース１２ｃから第２の入力撮像インターフェース１３ａに向かう実線の矢印：図５参照)からスルー画用の画像データが出力されると、それが、第１のポストプロセス回路１３ｊで処理されて作成されたスルー画のYCbCrデータが、図５のYCbCr1バッファ１５ｆに記憶される。

このスルー画のYCbCrデータは、図２と同じ経路でＬＣＤコントローラ１３ｄに送られＬＣＤパネル１７に表示される。YCbCr1バッファ１５ｆは、複数(３つの場合が多い)あって、先に出力されたスルー画のYCbCrデータをＬＣＤパネル１７に表示している間に次のYCbCrデータを別のYCbCr1バッファ１５ｆに記憶しており、これらのYCbCr1バッファ１５ｆを切り換えながらスルー画の表示を続ける。

上述したプログラムの中でスルー画表示に関わるプログラムは、適宜このYCbCr1バッファ１５ｆの切り換えを行わなければならない。仮想撮像回路３０から出力されたスルー画用の画像データは、図５の３Ａ検波回路１３ｈにも送られ３Ａの評価値が抽出される。その中のAE評価値とAWB評価値を用いてスルー画の輝度調整とWB調整が適宜行われる。上述したプログラムは呼び出される度にこれらの処理を行う。

またこのAE評価値から静止画撮影用の測光演算も行われる。レリーズ釦１８の半押しが検出された時には、焦点調整(AF)プログラムが呼び出され、AF評価値を基に被写体に焦点を合わせる。半押しだけで全押しが行われなかった場合、焦点調整(AF)の終了後もライブビューを続ける。

半押し後に全押しが行われた場合、画像の撮影に進むが、これ以降は、撮影モードによって動作が異なっている。先ず簡単な動画撮影モードの場合から説明する。動画撮影の場合にはライブビューを続けたまま、図８に示す仮想撮像回路３０から記録用の動画データを出力する。

つまり、仮想撮像回路３０の第１のインターフェースからスルー画用の画像データを出力したまま、第２のインターフェース(第２の出力撮像インターフェース１２ｋから第２の入力撮像インターフェース１３ｋに向かう点線の矢印：図５参照)から記録用の動画データを出力する。基となる１つの画像データを仮想撮像回路３０の内部で分けて２つのインターフェースから出力するだけなので、この制御は容易である。全押し後は、ライブビューのプログラムを実行したまま、先ず動画撮影プログラムが呼び出され、その動画撮影プログラムの中で記録用の動画データを出力するためのＡＰＩが呼び出される。

このＡＰＩから更に仮想撮像ドライバ１０４ｄと画像処理ドライバ１０４ｂが呼び出される。仮想撮像ドライバは１０４ｄ、仮想撮像回路３０の第２のインターフェースから記録用の動画データを出力するように設定する。

一方、画像処理ドライバ１０４ｂは、そのデータが図５の第２のプリプロセス回路１３ｍと第２のポストプロセス回路１３ｐで処理されるように設定する。この場合も画像処理回路を先に設定する。仮想撮像回路３０の第２のインターフェースがスルー画用の画像データが出力されると、それが第２のプリプロセス回路１３ｍと第２のポストプロセス回路１３ｐで処理されて作成された記録用のYCbCrデータが図５のYCbCr2バッファ１５ｇに記憶される。

この記録用のYCbCrデータは、不図示の動画コーデック(H.264等)に送られて圧縮されるが、これ以降の処理は仮想撮像回路３０に関係がないので説明を省略する。動画撮影の場合、仮想撮像回路３０から２つの異なる画像データを同時に出力しながら処理が行われている。画像データの中で記録用の動画データの方が一般に解像度は高い。尚、動画撮影中は被写体に焦点を合わせ続ける必要があり、上述した焦点調整(AF)プログラムは、AF評価値を基に焦点調整(AF)の処理を続ける。

続いて、ライブビューと静止画撮影の動作が並列に行われる場合について説明する。これには、２つの場合が考えられる。通常の静止画撮影では、焦点調整(AF)が終了するとライブビューを停止して静止画撮影の動作に入るが、ライブビューを続けたまま静止画の撮影を行う動作が第１の場合である。

第１の場合、ライブビュー中の或るフレームを取りだして静止画として記録する動作になる。高速撮像回路１１ａは、フル解像度の画像データをライブビューのフレームレートで出力することもできるので、ライブビューを続けたまま解像度の高い静止画を撮影することができる。

この場合の仮想撮像回路３０の動作は、動画撮影の場合に似ている。但し、撮影された静止画データが間欠的に仮想撮像回路３０から出力される点は、動画撮影の場合と異なる。ライブビュー中にレリーズ釦１８が全押しされると焦点調整(AF)終了直後のフレームが静止画として取り出されるが、その静止画データは、通常の静止画撮影の場合と同じように仮想撮像回路３０の内部に蓄積される。この処理は、仮想撮像回路３０の露光動作に対応するので既に説明したＡＰＩ関数を用いて行うことができる。撮影された静止画データは、続いて仮想撮像回路から出力することになるが、この静止画データの出力動作も既に説明したＡＰＩ関数を用いて行うことができる。ライブビューが続いている以外は、通常の静止画撮影の動作と同じであることが分かる。

続いて、第２の場合について説明するがこれは既に述べたことである。つまり、既に述べたＲＡＷバッファ連写が行われてそれが中断または終了した時に、仮想撮像回路３０の中に蓄積された静止画データの出力が終わらないうちにライブビューを再開する場合である。ＲＡＷバッファ連写が行われている間はライブビューが行われない。撮影された静止画データは、仮想撮像回路の第２のインターフェースから出力されているが、第１のインターフェースが空いているので、そこからライブビューの画像データを並行して出力することができる。

この場合のライブビューの動作は、上述した説明と同じである。この再開されたライブビューの間にレリーズ釦１８が全押しされた場合、再び静止画撮影の動作に入る。これは通常の静止画撮影と同じ動作である。仮想撮像回路３０のState1がREADYであれば静止画の撮影を行うことができるので、既に説明したＡＰＩを呼び出して静止画の露光を行う。これ以降は、これまでに説明したことと同じなので省略する。つまり、ライブビューや動画撮影の場合も仮想撮像回路３０のＡＰＩを用いて処理することができる。

以上より、第４実施形態では、ソフトウェアの共通化と再利用とが容易となり、汎用性の高いカメラシステムを構築することができる。

１、２・・・電子カメラ、１１・・・撮像回路、１２・・・フロントエンジン、１３・・・バックエンジン

Claims (5)

1. 被写体を撮像して画像データを出力する撮像部と、
   前記撮像部と電気的に接続することにより前記画像データを受信する第１の入力撮像インターフェース、受信した前記画像データの容量に応じて該画像データのピクセルレートを下げるピクセルレート低減手段、及び前記ピクセルレートの低減された画像データを出力する出力撮像インターフェースを有するフロントエンジンと、
   前記出力撮像インターフェースと電気的に接続することにより前記ピクセルレートの低減された画像データを受信する第２の入力撮像インターフェース、受信した前記ピクセルレートの低減された画像データに画像処理を施す画像処理手段、及び撮影シーケンスを制御する撮影シーケンス制御手段を有するバックエンジンと、を備え、
   前記撮影シーケンス制御手段は、前記フロントエンジンに前記撮影シーケンスのコマンドを送信し、
   前記フロントエンジンは、前記コマンドを受信して、前記撮像部の撮像と前記画像データの読み出しとの少なくとも一方の動作を制御することを特徴とする電子カメラ。
2. 請求項１に記載の電子カメラにおいて、
   前記フロントエンジンを抽象化し、前記撮像部と合わせて仮想的な撮像手段として動作させるソフトウェアインターフェースと、前記撮影シーケンス制御手段上で実行される画像撮影用ソフトウェアとをさらに備え、
   前記画像撮影用ソフトウェアは、前記ソフトウェアインターフェースを呼び出すことにより、前記仮想的な撮像手段を制御して画像の撮影を行うことを特徴とする電子カメラ。
3. 請求項２に記載の電子カメラにおいて、
   前記ソフトウェアインターフェースは、前記仮想的な撮像手段に前記被写体の撮像を行わせる第１のＡＰＩ（Application Programming Interface）と、前記撮像により取得された前記画像データを前記仮想的な撮像手段に出力させる第２のＡＰＩとを有し、
   前記画像撮影用ソフトウェアは、前記第１のＡＰＩと前記第２のＡＰＩとを順次呼び出すことにより画像の撮影を行うことを特徴とする電子カメラ。
4. 請求項３に記載の電子カメラにおいて、
   前記フロントエンジンは、前記画像データを記憶する記憶手段を有し、
   前記第１のＡＰＩは、前記仮想的な撮像手段による前記被写体の撮像から、前記フロントエンジンの記憶手段に画像データを記憶するまでの動作を行い、
   前記第２のＡＰＩは、前記記憶手段に記憶された画像データを前記バックエンジンに出力するまでの動作を行うことを特徴とする電子カメラ。
5. 請求項４に記載の電子カメラにおいて、
   前記画像撮影用ソフトウェアは、前記第１のＡＰＩを続けて呼び出して連写を行い、
   前記第２のＡＰＩは、前記連写によって前記フロントエンジンの前記記憶手段に蓄積された複数の画像データを、撮像順とは異なる順序で出力させて前記バックエンジンに処理させることを特徴とする電子カメラ。
   

Images