(第1実施形態)
以下、図面に基づいて本発明の実施の形態を詳細に説明する。尚、本発明の実施の形態の内容の理解を容易にするため、本発明の一実施形態の電子カメラ1の基本的な構成を説明した後、比較例として、フロントエンジンを用いない電子カメラ50(従来型の電子カメラ)の構成及び動作について説明する。特に、電子カメラ50では、画像の撮影における基本的な処理や画像データの流れについて説明する。これらの説明を踏まえた上で、電子カメラ1の詳細な構成及び動作について説明する。これにより、電子カメラ1と電子カメラ50との差異点を明確にする。
<電子カメラ1の構成>
図1は、第1実施形態の電子カメラの構成例を示すブロック図である。電子カメラ1は、撮影光学系10と、撮像回路11と、フロントエンジン12と、バックエンジン13と、DRAM(Dynamic Random Access Memory)14と、DRAM15と、Flash−ROM(Read Only Memory)16(図では「Flash」と表記する。)と、LCD(Liquid Crystal Display)パネル17と、レリーズ釦18と、コネクタC1と、コネクタC2とを備える。
電子カメラ1は、フロントエンジン12及びバックエンジン13を中心に撮像回路11を始めとする周辺ハードウェアから成る。フロントエンジン12とバックエンジン13とは、それぞれ1つのLSI(SoC:System on Chip)として実装される。尚、「フロントエンジン」と「バックエンジン」とは、特許文献1で使われた名称であるが、以下の説明においてもこの名称をそのまま用いる。但し、同じ名称を用いていてもフロントエンジン12とバックエンジン13の内部構成は、特許文献1と大きく異なる。特許文献1と違って、本実施形態のバックエンジン13は、それ1つでも画像処理の行える最小限のカメラシステムを構成することができ、機能的にはメインエンジンと呼ぶべきものである。
撮影光学系10は、焦点距離を調整するズームレンズと、撮像回路11内の撮像センサの受光面での結像位置を調整するフォーカスレンズとを含む複数のレンズ群で構成されている。尚、簡単のため、図1では、撮影光学系10を1枚のレンズとして図示する。
撮像回路11は、撮像センサ(CMOS(Complementary Metal Oxide Semiconductor)センサ、またはCCD(Charge Coupled Device)センサ)の他にTG(Timing Generator)センサやAFE(Analog Front End)等から成る。尚、撮像回路11は、TGとAFEとを内蔵したCMOSセンサを採用しても良い。
画像の撮影時には、先ず、撮影光学系10によって被写体の光学像(被写体像)が撮像センサ上に形成される。次いで、この被写体像が撮像センサによって光電変換(露光)され、最後にデジタルの画像データとなって撮像回路11から出力される。撮像センサの受光面には、例えばBayer配列のカラーフィルタ(CFA:Color Filter Array)が設けられている。この場合、Bayer配列からなるカラーのデジタルの画像データが撮像回路11から出力される。露光や画像データの出力といった撮像回路11の制御は、少数の制御信号や、シリアル通信ポートによって行われる。
フロントエンジン12は、高ピクセルレートの撮像センサが出力する画像データをバックエンジン13で処理するための素子である。フロントエンジン12は、高ピクセルレートの撮像センサが出力する画像データを一旦受信し、そのピクセルレートを低減してからバックエンジン13に送信する。
バックエンジン13は、電子カメラ1の殆どの機能を担う最も重要な素子である。ここで、撮像回路11からフロントエンジン12に向かう矢印の部分は、撮像回路11から出力された画像データが流れることを示しており、実際には、(超)高速のインターフェースで繋がる。
一方、フロントエンジン12からバックエンジン13に向かう矢印の部分には、ピクセルレートの低減された画像データが流れるが、ここには、フロントエンジン12の他に一般的な撮像センサを含む撮像回路11も繋がる。図中のフロントエンジン12から撮像回路11に向かう矢印は、この撮像回路11を制御するためのシリアル通信ポートや制御信号を表す。
更に、図1には、フロントエンジン12とバックエンジン13とを繋ぐ幅広の白矢印もあるが、この白矢印は、フロントエンジン12とバックエンジン13との間の通信インターフェースを表しており、例えば、単純なシリアル通信インターフェースでも良い。尚、フロントエンジン12及びバックエンジン13の内部構成の詳細については、図2、図5で詳しく説明する。
DRAM14は、フロントエンジン12と接続しており、例えば、高ピクセルレートの撮像センサが出力する画像データを一時的に記憶する。DRAM15は、バックエンジン13と接続しており、電子カメラ1の様々な処理において画像データを一時的に記憶する他、プログラムで使用する変数の記憶やスタック等に使用される。
Flash−ROM16には、例えば、電子カメラ1における画像の撮影、画像の再生、PC(パーソナルコンピュータ)等への画像の転送といったカメラの機能を実行するプログラム(カメラファームウェア)が記憶される。また、Flash-ROM16には、電子カメラ1の各種調整データやユーザ設定情報等も記憶される。
LCDパネル17は、例えば液晶表示媒体により構成される。LCDパネル17は、画像やGraphicデータ(文字やアイコン等)を表示する。レリーズ釦18は、半押し操作(撮影前におけるオートフォーカス(AF)や自動露出(AE)等の撮影準備の動作開始)と全押し操作(本画像を取得するための撮影の動作開始)との指示入力とを受け付ける。コネクタC1は、着脱自在のUSB(Universal Serial Bus)メモリU1を接続するための接続端子である。コネクタC2は、着脱自在のカード型の不揮発性のメモリカードM1を接続するための接続端子である。図1では、コネクタC1に接続された後のUSBメモリU1と、コネクタC2に接続された後のメモリカードM1を示している。
<電子カメラ50の構成>
次に、比較例として、電子カメラ50の構成について説明する。
図10は、電子カメラ50のブロック図の一例を示す図である。電子カメラ50では、1つのバックエンジン51を中心に撮像回路52を始めとする周辺ハードウェアから成る。尚、バックエンジン51は、バックエンジン13と同様、1つのLSIとして実装される。
電子カメラ50は、撮影光学系55、撮像回路52、バックエンジン51、DRAM53、Flash−ROM54、LCDパネル57、レリーズ釦56、コネクタC3、コネクタC4及びバス51rを備える。
撮影光学系55は、図1に示す撮影光学系10と同様の構成である。撮像回路52は、撮像回路11と同様の構成であるが、高ピクセルレートの画像データを出力しない点が異なる。LCDパネル57、レリーズ釦56は、図1に示すLCDパネル17、レリーズ釦18と同様の構成である。コネクタC3は、メモリカードM2を接続するための接続端子であり、コネクタC4は、着脱自在のUSBメモリU2を接続するための接続端子である。図10では、コネクタC3に接続された後のメモリカードM2を示している。
従来のバックエンジン51は、電子カメラ50の殆どの機能を担う最も重要な素子であり、撮像回路52から出力された画像データに画像処理を施す画像処理回路51a(図では「画像処理」と表記する。)、電子カメラ全般の動作をコントロールするCPU(Central Processing Unit)51b、静止画の圧縮を行うJPEGコーデック51c(図では「JPEG」と表記する。)、画像やGraphicデータをLCDパネル57に表示するLCDコントローラ51d、PC等のホスト機器へ画像データを転送するUSBコントローラ51e(図では「USB」と表記する。)、DRAM53へのデータ読み書きを行うDRAMコントローラ51f(図では「DRAMC」と表記する。)、Flash-ROM54へのデータ読み書きを行うStaticメモリコントローラ51g(図では「SMC」と表記する。)、周辺デバイスとの間でデータや信号をやり取りするSIO(Serial Input/Output)&PIO(Parallel Input/Output)51h、メモリカードM2へのデータ読み書きを行うCARDコントローラ51i等を内部に含む(図10参照)。
尚、画像処理回路51a、CPU51b、JPEGコーデック51c、LCDコントローラ51d、USBコントローラ51e、DRAMコントローラ51f、Staticメモリコントローラ51g、及びSIO&PIO51hは、バス51rを介して互いに接続されている。
また、図示されてはいないがバックエンジン51には、その他として、いわゆるH.264等の動画コーデック、画像データの転送を行うDMAコントローラ(DMAC)、割り込みコントローラ、A/D変換器、タイマー等も含まれる(バックエンジン13も同様とする)。画像の撮影、画像の再生、PC等への画像の転送といった電子カメラ50の機能は、CPU51bが実行するプログラム(カメラファームウェア)として実装され、そのプログラムは、Flash-ROM54に記憶される。Flash-ROM54には、電子カメラ50の各種調整データやユーザ設定情報等も記憶される。DRAM53は、電子カメラ50の様々な処理において画像データを一時的に記憶する他、プログラムで使用する変数の記憶やスタック等に使用される。
図10では、これらの制御信号や通信ポートがバックエンジン51内から撮像回路52に向かう1本の矢印で表されており、バックエンジン51は、これらを駆使して撮像回路52を制御し画像の撮影を行う。撮像回路52から出力された画像データは、バックエンジン51の画像処理回路51aに入って様々な画像処理が施される。ここで、この画像処理は、一般にプリプロセス(Pre-Process)とポストプロセス(Post-Process)の2つに大きく分けられる。撮影時の画像処理がこの2つの処理に明確に分かれる場合があるからである。
プリプロセスは、撮像センサのバラツキ等を補正する処理が主体であり、特許文献1でフロントエンジンの信号処理手段が行っている補正処理に対応する。具体的には、プリプロセスは、欠陥画素補正(DPC:Defect Pixel Correction)、OB(Optical Black)クランプ、シェーディング補正、感度補正等の処理を行う。プリプロセスには、その他にノイズ除去や一部のレンズ収差を補正する処理が含まれたりする。
これらの補正処理とは別にプリプロセスは、3種類の評価値を抽出する3A検波の機能も持つ。この3A検波の機能は、AE(Automatic Exposure)、AF(Automatic Focusing)、AWB(Automatic White Balance)のための各評価値を抽出するものである。電子カメラ50は、各評価値に基づいて、自動露出(AE)、自動焦点調整(AF)、自動ホワイトバランス調整(AWB)の制御を行う。
一方、ポストプロセスは、カラー処理が主体であり、特許文献1でバックエンジンが行っているYCC変換/解像度変換の処理に対応する。その意味から、カラープロセス(Color Process)と称しても良い。具体的には、ポストプロセスは、WB調整、色補間、色空間変換、γ補正、YCC変換、偽色除去、エッジ強調、解像度変換等の処理を行う。
プリプロセスが施された後でも画像データは、未だ1色/pixelのBayer配列データであるが、ポストプロセスが施された後では、3色/pixelのYCbCrデータに変わっている。このYCbCrデータは、表示や印刷に利用できる画像データである。JPEG(静止画)やH.264(動画)等の画像圧縮でもこのYCbCrデータが利用される。
画像処理回路51aは、プリプロセスを行うプリプロセス回路とポストプロセスを行うポストプロセス回路(不図示)から成る。ここで、画像処理の動作には、このプリプロセス回路とポストプロセス回路とを直結して2つの処理を一体的に行う1ステップ処理と、プリプロセスの施された1フレーム分の画像データを一旦DRAM53に記憶し、次いで、その画像データをDRAM53から読み出してポストプロセスを施すという2ステップ処理の2つがある。これらの動作を行う画像処理回路51aの内部構成と、その画像データの流れを図11に示す。
図11は、バックエンジン51の画像処理回路51aの構成例を示すブロック図である。撮像回路52から出力された画像データを受信するため、画像処理回路51aの前には、入力撮像インターフェース(SIFi)51j(図では「SIFi」と表記する。)が設けられている。「SIFi」は「Sensor InterFace」と「Input」の文字を組み合わせたものである。撮像回路52側には、不図示の出力撮像インターフェースがあり、この出力撮像インターフェースから出力された画像データを入力撮像インターフェース51jが受信する構図になる。
入力撮像インターフェース51jは、入力信号から有効画素領域やOB領域のデータを取り出すための処理を行い、それらのデータを後方の画像処理回路51aに送っている。画像処理回路51aは、先頭にプリプロセス回路51k(図では「PreProc」と表記する。)が置かれており、プリプロセス回路51kの後方には、2つの入力データの一方選択して出力するセレクタ(Sel)51m(図では「Sel」と表記する。)が置かれ、セレクタ51mの後方には、ポストプロセス回路(PostProc)51n(図では「PostProc」と表記する。)が置かれる構造をしている。
プリプロセス回路51kの出力は、2つあり、第1の出力がセレクタ51mの第1の入力に繋がり、第2の出力がDRAM53に繋がる(正確には、図10に示すDRAMC51fの入力ポートに繋がる)。一方、セレクタ51mの第2の入力は、DRAM53に繋がり(正確にはDRAMC51fの出力ポートに繋がる)、このセレクタ51mの出力が、ポストプロセス回路51nの入力に繋がり、最後にポストプロセス回路51nの出力がDRAM53に繋がる(正確にはDRAMC51fの入力ポートに繋がる)。
画像処理回路51aが1ステップ処理を実行する場合には、プリプロセス回路51kの第1の出力から出力される画像データがセレクタ51mによって選択され、その画像データがポストプロセス回路51nに直接入力されるように設定される。入力撮像インターフェース51jから送られてきた画像データは、プリプロセス回路51kに入って先ずプリプロセスが施され、次いで、その画像データ(Bayer)は、プリプロセス回路51kから出力されてセレクタ51mを通り、更にポストプロセス回路51nに入ってポストプロセスが施される。
ポストプロセスが施された画像データ(YCbCr)は、ポストプロセス回路51nから出力されてDRAM53上に設けられたYCbCrバッファ53aに記憶される(図11参照)。
一方、2ステップ処理を行う場合には、入力撮像インターフェース51jから送られてきた画像データは、セレクタ51mの第2の入力データが選択されてポストプロセス回路51nに入るように設定される。この設定の場合には、DRAM53から読み出された画像データは、ポストプロセス回路51nに入力され、ポストプロセスが施される。
2ステップ処理の全体の動作は、以下のようになる。先ず、入力撮像インターフェース51jから送られてきた画像データがプリプロセス回路51kに入力され、プリプロセスが施される。そして、プリプロセスが施された画像データ(Bayer)は、プリプロセス回路51kの第2の出力から出力されて一旦DRAM53上に設けられたRAWバッファ53dに記憶される(図11参照)。これが1ステップ目の処理である。RAWデータを記録する機能を持つ電子カメラ50の場合には、このRAWバッファ53dに記憶されたBayerデータを記録するのが普通である。
次いで、プリプロセスが施されたBayerデータは、RAWバッファ53dから読み出されてセレクタ51mを通り、更にポストプロセス回路51nに入ってポストプロセスが施される。ポストプロセスが施されたYCbCrデータは、ポストプロセス回路51nから出力されてDRAM53上に設けられたYCbCrバッファ53aに記憶される(図11参照)。これが2ステップ目の処理である。
画像処理の動作が、この様に2種類あるのは、処理結果であるYCbCrデータの横サイズに起因する。大まかに言うとYCbCrデータの横サイズが予め設定した値より小さい場合、画像処理回路51aは、1ステップ処理、横サイズが大きい場合(予め設定した値以上)、2ステップ処理を行うことになる。この画像処理の動作は、撮影時の電子カメラ50の撮影動作にも関係が深いので、次に、図10に示す電子カメラ50の撮影動作について説明する。
<電子カメラ50の撮影動作>
本実施形態では、ライブビューを重視しているため、電子カメラ50におけるライブビューを利用した撮影動作を例に挙げて説明する。
画像の撮影時(撮影モード)には、電子カメラ50が先ずライブビューの動作に入る。ライブビューの動作では、撮像回路52を連続出力モードに設定し、30fpsや60fpsのフレームレートで撮像(露光)と画像データの出力を繰り返す。ライブビューでは、撮影者が被写体の生映像をLCDパネル57で見ながら撮影の構図を決めたり、自動露出(AE)のための測光演算や自動焦点調整(AF)を電子カメラ50側で行ったりする。
電子カメラ内蔵のLCDパネル57は、VGA(640×480)程度のものが多く、LCDパネル57に表示する生映像(スルー画像)のYCbCrデータもその程度で済む。スルー画像は、記録画像よりも画像サイズが小さいので、ライブビューでは、1ステップ処理を用いる。具体的には、ライブビューでは、撮像回路52から連続的(例えば30fps或いは60fps)に出力された画像データを画像処理回路51aに入力し、その画像処理回路51aは、1ステップ処理を行ってスルー画のYCbCrデータを生成する。このスルー画のデータは、一旦DRAM53上のYCbCrバッファ53aに記憶され、次いで、スルー画のデータが読み出されてLCDコントローラ51dに送られLCDパネル57に表示される。この動作を毎フレーム繰り返すことで被写体の生映像を見ることができる。この時の画像データの流れを図12に示す。
<電子カメラ50の画像データの流れ>
図12は、電子カメラ50におけるライブビュー動作時の画像データの流れを示す図である。図12では、プリプロセス回路51kとポストプロセス回路51nを1つにまとめて画像処理回路51aとして表しているが、その内部は、図11のようになっている。
ライブビュー中、プリプロセス回路51kは、適宜3A検波を行って3Aバッファ53bから3A評価値を抽出する。
図12では、この3A評価値がDRAM53上の3Aバッファ53bに記憶されている。3A評価値は、プリプロセス回路51k内の3A検波回路から出力されるので、少し詳しく描くと図11のようになる。プリプロセス回路51kは、この3A評価値に基づいて輝度調整(AE)や、焦点調整(AF)や、ホワイトバランス調整(AWB)を行う。これによってスルー画の明るさと色が適切に保たれる。
測光演算では、静止画撮影の露光条件も計算される。尚、3A評価値の中でデータ量の少ないものは、その検波回路内のSRAM(Static Random Access Memory)に記憶する方がCPU51bからの読み出しが速くなって有利である。プリプロセスでは、欠陥画素補正が行われるが、この欠陥画素の位置(アドレス)を記憶した欠陥画素テーブル53cがDRAM53上に置かれる。プリプロセス回路51k内の欠陥画素補正回路(不図示)は、この欠陥画素テーブル53cの情報を読み出し、その位置の画素が到着したらその周囲の画素から計算された補正値に置き換える処理を行う。
このデータの流れを図11と図12に示す。1ステップ処理では、ポストプロセスまで一気に処理されるため、スルー画のYCbCrデータが生成される際のレイテンシが小さい。これにより撮影時のレリーズタイムラグが短縮されるメリットが生まれる。また、1ステップ処理では、画像処理の中間データをDRAM53に記憶することもないのでDRAM53のアクセスが少なく、その分、DRAM53の帯域を余り占有しないで済むメリットもある。このライブビューの動作は、静止画撮影モードの場合も、動画撮影モードの場合も余り変わらない。ライブビュー中にレリーズ釦56が全押しされるとその時の撮影モードに応じて静止画撮影や動画撮影の動作に移る。
<静止画撮影の動作>
次に、電子カメラ50の静止画撮影の動作について説明する。図10に示すレリーズ釦56が全押しされた時には、その前に半押しが検出されるので焦点調整(AF)が先に行われ、それが完了すると静止画の撮影動作に移るステップを経る。静止画撮影動作に移ると直前に行われた測光演算を基に被写体の自動露出(AE)が行われる。目標の露光量に達すると露光が終了し、次いで、撮影された静止画の画像データ(以下「静止画データ」という。)が撮像回路52から出力される。
図13は、電子カメラ50における静止画撮影時の画像データの流れを示す図である。この画像データは、図13に示す通り、バックエンジン51の入力撮像インターフェース51jで受信され、次いで、画像処理回路51aに入る。撮影された静止画は、一般的に解像度がスルー画等の動画と比較して大きいので、画像処理回路51aは、2ステップ処理を実行する。その理由を以下に説明する。ポストプロセスは、2次元的なフィルタ処理を幾つも含むが、1枚の画像をプログレシブ走査によって処理していくには、それぞれのフィルタ回路が垂直タップ数分のラインメモリを持たなければならず、回路規模が増大する問題があった。
中には、タップ数の多いフィルタ回路もあり、それが図11に示すポストプロセス回路51nの肥大化を加速させている。スルー画に比べて1枚の巨大な画像(例えば50Mの容量)を1回で処理するには、その画像の横サイズ分の記憶容量を持つラインメモリが必要であるが、そのような大容量のラインメモリをフィルタ回路毎にそのタップ数分だけ持つことは困難になっている。
そこで、回路規模を抑えるには、(A)フィルタ回路の数やタップ数を減らす、(B)ラインメモリ1本当たりの記憶容量を減らす等の方法が考えられる。条件(A)の方法は、画質に影響し、条件(B)の方法は、1回で処理できる画像の大きさに影響する。画質を重視するのであれば、ラインメモリの記憶容量を減らすことになるが、その場合には、高解像度の画像をどのように処理するかが問題となる。この点については、第2実施形態の電子カメラ2の説明の際、後述する。
<静止画の画像処理の詳細について>
次に、図13を基に静止画の画像処理をもう少し具体的に説明する。撮像回路52から出力された画像データは、バックエンジン51の入力撮像インターフェース51jで受信され、次いで、画像処理回路51aに送られてプリプロセスが施され、更に画像処理回路51aから出力されて一旦図中のRAWバッファ53dに記憶される。この時、画像処理回路51aは、ライブビューと同様に欠陥画素テーブル53cの情報が読み出す。
但し、撮像回路52から出力される画素数がライブビューと静止画撮影とで異なる場合には、画像処理回路51aは、欠陥画素のアドレスも変わってくるので2つのテーブルを用意しておき使い分ける。図13中、撮像回路52から出て入力撮像インターフェース51jを通り、次いで、画像処理回路51aを経由してRAWバッファ53dに向かう矢印が、静止画データの流れを表し、欠陥画素テーブル53cから画像処理回路51aに向かう矢印の方が欠陥画素情報の流れを表す。この部分をもう少し詳しく示したものが図11である。
図11に示す通り、静止画データは、「撮像回路52→入力撮像インターフェース51j→プリプロセス回路51k→RAWバッファ53d」と流れ、欠陥画素情報は「欠陥画素テーブル53c→プリプロセス回路51k」と流れる。これが1ステップ目の処理である。
続く2ステップ目では、ポストプロセス回路51nは、短冊分割に基づいて、ポストプロセスを実行する。ここで、短冊分割について説明する。
図15は、静止画の短冊分割の処理の一例を説明する図である。図15に示す方法により、ポストプロセス回路51nは、大きな画像も処理することができる。つまり、ポストプロセス回路51nは、1枚の大きな画像を図の中の(1)、(2)、(3)のように横サイズの小さな短冊状の部分画像に分割し、この短冊画像を1つずつ処理してDRAM53上で繋ぎ合わせ1枚の画像31を完成させる。
短冊画像は、横サイズが小さいのでフィルタ回路のラインメモリも小容量で済む。1本のラインメモリの記憶容量から処理可能な短冊画像の横サイズが決まるので、ポストプロセス回路51nは、それを基に元の画像を何個の短冊画像に分割するかを決定する。解像度の大きな画像であれば分割される短冊画像の数も増える。1枚の画像の横サイズが1本のラインメモリの記憶容量以下であれば、ポストプロセス回路51nは、短冊分割せずに処理することができる。図中の実線及び点線の矢印は、各短冊画像の画素データの走査順を表している。上述したフィルタ回路では横(水平)方向のフィルタ処理も行われるので、短冊画像の境界部では、ポストプロセス回路51nは、全フィルタ回路の水平タップの合計分だけ画素が重なるように分割する。
図15では、この重なり部分を示す帯び32、33を明示的にそれぞれ表している。全てのフィルタ処理が済むと境界部では、両方の短冊画像からそれぞれ水平タップ数の半分ずつ画素が減るので、処理後の短冊画像は、境界部で良く合って繋がることになる。図中の縦の点線は、短冊画像の繋ぎ目を表している。この重なり部分ではDRAM53から画素のデータが二重(2回)に読み読み出されるため、短冊画像の横サイズを小さくし過ぎると重なり部分が増大してデータの読み出し回数が増え効率が低下する弊害が出る。この短冊分割処理は、ポストプロセスだけで、プリプロセスの方は通常1フレームの画像全体を1回で処理している。
すなわち、ポストプロセス回路51nは、プリプロセスの施されたBayerデータをRAWバッファ53d上で幾つかの短冊画像に分割し、それらを1つずつ読み出し画像処理回路51aに入力してポストプロセスを施し、ポストプロセスの施されたYCbCrデータをYCbCrバッファ53aに記憶する。この処理を全ての短冊画像について実行すると、YCbCrバッファ53a上では、画像処理が完了して1つに繋がった画像が出来上がる。
図13において、RAWバッファ53dから画像処理回路51aを経由してYCbCrバッファ53aに向かう矢印がこの時の画像データの流れを表す。これをもう少し詳しく示したものが図11である。
図11に示す通り、各短冊画像のBayerデータは、「RAWバッファ53d→セレクタ51m→ポストプロセス回路51n→YCbCrバッファ53a」と流れる。これが2ステップ目の処理である。
図13では、DRAM53上にYCbCrバッファ53aが3つ設けられているが、これはポストプロセスで3つの異なるサイズの画像を作成するからである。1つ目は、主たる記録画像である大サイズの主画像、2つ目は、撮影結果確認用の中サイズの表示用画像(フリーズ画)、3つ目は、検索用の小サイズのサムネイル(縮小画像)で、これらは全てYCbCrデータの画像である。ポストプロセス回路51nがこれら3つの画像を並列に作成して出力する機能があると、1回の処理で全ての画像が生成されるので処理時間が短縮される。
そのような機能が無い場合には、シーケンシャルに作成するので時間が掛かる。ポストプロセスでは、一般に短冊分割が行われるので更に低速となる。静止画は、一般に解像度がスルー画に比べて大きいため短冊分割でポストプロセスを実行する必要があり、それがプリプロセスとポストプロセスを分けて行う2ステップ処理の一因になっている。
一方、スルー画は、解像度が静止画に比べて小さいのでライブビューでは、プリプロセスとポストプロセスを一体的に行う1ステップ処理が用いられるが、その時には補助的な処理が必要なこともあるので説明しておく。ライブビューの時に撮像回路52から出力される画像データは、必ずしも横サイズ(横画素数)が小さいわけではない。撮像センサで画素加算や間引きが行われる場合、出力される画素数も減るが、その場合でも画像の横サイズは、大きいことが多い。
そのため、ライブビューの際に撮像回路52から横サイズの大きな画像データが出力されると上述したフィルタ回路のラインメモリの記憶容量が超えることがあり、バックエンジン51では、図11に示すプリプロセス回路51kから出力された画像データを直接ポストプロセス回路51nに入力してポストプロセスを施すという1ステップ処理ができないことになる。
しかし、ライブビューの場合には、最終的に生成されるスルー画のYCbCrデータの画像サイズが小さいという理由で、1ステップ処理ができなくなる問題が回避される。短冊分割を行うのは、大きな画像サイズのままポストプロセスを施すためであるが、ライブビューの場合には、小さな画像サイズのスルー画を生成するだけなのでポストプロセスの前に横方向の縮小を行っても構わない。
つまり、バックエンジン51では、ポストプロセス回路51nの前に横方向の画像縮小回路(不図示)を設け、これで短冊分割が不要になるまで横サイズを縮小してから画像データをポストプロセス回路51nに入力する。ポストプロセス回路51nは、短冊分割なしで目標サイズのスルー画像を生成しなければならないので、内部のフィルタ回路は、そのサイズに対応できるだけのラインメモリを持つ必要がある。スルー画のサイズがVGA(640×480)であればその程度のラインメモリを持つことは困難ではない。
尚、ライブビューの際、必要以上のライン数の画像データが撮像回路52から出力されるのであれば、バックエンジン51では、横方向の画像縮小回路の他に縦(垂直)方向の画像縮小回路(不図示)を設けると良い。これにより、バックエンジン51では、不要な画像データをポストプロセス回路51nに流さないで済む。この画像縮小処理は、プリプロセスやポストプロセスにおいて本質的なものではなく、1ステップ処理を行うために設けられた補助的な処理である。
図11において、バックエンジン51では、この画像縮小回路を独立に設けても良いが、予めプリプロセス回路51kかポストプロセス回路51nの適切な場所に入れておくこともできる。例えば、プリプロセス回路51kの最後か、ポストプロセス回路51nの先頭に入れておく。ライブビューの時には、ポストプロセス回路51nは、この画像縮小回路を「実行」に設定して1ステップ処理を行い、静止画撮影の時には、ポストプロセス回路51nは、この画像縮小回路を「バイパス」に設定して2ステップ処理を行う。これにより、ポストプロセス回路51nは、それぞれの動作に適した画像処理を行うことができる。
尚、2ステップ処理は、短冊分割でポストプロセスを実行するためであるが、それとは別にもう1つ、2ステップ処理を行う理由がある。それは、最適な自動ホワイトバランス調整(AWB)を行うためである。ポストプロセスにはWB調整も含まれているが、それを実行するには、WBゲイン(WB:White Balance)を設定する必要がある。ポストプロセス回路51nは、AWB評価値を基にWBアルゴリズムを実行してWBゲインを決定するが、これを何時行うかという問題がある。ライブビュー動作時のWBゲインをそのまま使うこともできるが、撮影した静止画の実データに基づいていないという欠点がある。ポストプロセス回路51nは、より適切なAWB調整を行うため、その静止画データから抽出したAWB評価値を基にWBゲインを決定する必要がある。
ここで、3A検波は、プリプロセス回路51kで行われるので、撮像回路52から出力された静止画データにプリプロセスを施す際AWB評価値を抽出する。図13では、このAWB評価値がDRAM53上のAWBバッファ53fに記憶されている。画像処理回路51aから出てAWBバッファ53fに向かう矢印が、このAWB評価値の流れを表す。
尚、静止画の撮影は、完了しているのでAE評価値とAF評価値の抽出は不要である。この部分をもう少し詳しく示したものが図11であり、AWB評価値は「プリプロセス回路51k→AWBバッファ(図中の3Aバッファの1つ)53f」と流れる。このAWB評価値を基にAWBアルゴリズムが実行されWBゲインが決まる。このWBゲインを図11のポストプロセス回路51nに設定し、次いで、ポストプロセス回路51nは、図中のRAWバッファ53dからプリプロセスの施されたBayerデータを読み出して、ポストプロセスを施す。
つまり、撮影された静止画データの画像処理は、「(プリプロセス/AWB検波)→AWBアルゴリズム実行→WBゲイン設定→ポストプロセス」の順に行われるため、2ステップ処理が必要となる。以上が、静止画の画像処理の内容である。
<静止画撮影時の画像処理について>
次に、静止画撮影時の画像処理について更に説明を続ける。画像処理では、3種類(3つ)の画像(主画像、フリーズ画、サムネイル)が作成されるので、静止画撮影後、撮影結果が確認できるように先ずフリーズ画がLCDパネル57に表示される。
具体的には、図10に示すCPU51bの指示により、不図示のDMAコントローラ(DMAC)は、図13のYCbCrバッファ53aの1つからフリーズ画を読み出し、それを図中のLCDコントローラ51dに送ってLCDパネル57に表示させる。図13では、YCbCrバッファ53aから出てLCDコントローラ51dを経由し、LCDパネル57に向かう矢印がこのフリーズ画の流れを表す。Exif(Exchangeable Image File Format)/DCF規格では、JPEG圧縮された主画像とサムネイルを記録するので、フリーズ画の表示と並行してこれら2つの画像をJPEG圧縮する。フリーズ画を一緒に記録しておくと再生が高速に行われるので、JPEGコーデック51cは、フリーズ画もJPEG圧縮しておくことにする。
最近CIPA(Camera & Imaging Products Association)で規格化されたマルチピクチャフォーマット(MPF)では、主画像とサムネイルの他にフリーズ画に相当する「モニタ表示用画像」が記録できるのでそれを利用しても良い。DMAコントローラ(DMAC)は、YCbCrバッファ53aから画像データ(YCbCr)を読み出し、それを図中のJPEGコーデック51cに入力し、JPEGコーデック51cから出力される圧縮データをDRAM53上のJPEGバッファ53e(図では「JPEG」と表記する)に記憶していく。図13では、YCbCrバッファ53aから出てJPEGコーデック51cを通り、JPEGバッファ53eに向かう矢印が、この時のデータの流れを表す。
DMAコントローラ(DMAC)は、この処理を3つの画像について順次実行する。DMAコントローラ(DMAC)は、3つの画像のJPEG圧縮データをフォーマットに従ってタグ情報と共に1つのJPEGバッファ53e上に配置し、Exif/DCFのファイルやMPFのファイルのファイルイメージを形成していく。このファイルイメージが完成したら、次に、CARDコントローラ51iは、そのデータをメモリカードM1に記録する。つまり、DMAコントローラ(DMAC)は、JPEGバッファ53eからこのファイルイメージを読み出し、それを図中のCARDコントローラ51iに入力してメモリカードM2に記録していく。図13では、JPEGバッファ53eから出てCARDコントローラ51iを通り、メモリカードM2に向かう矢印が、この時のデータの流れを表す。これが終わると静止画のファイルがメモリカードM2に保存され撮影が終了する。
以上は、1枚の静止画を撮影する場合(単写)の処理であるが、単純にこれを繰り返しても高速な連写とはならない。撮影した静止画がメモリカードM2に記録されるまで、撮像回路52は、次の撮影に入らないからである。
静止画撮影の動作は、(I)露光/画像データ出力/プリプロセス、(II)ポストプロセス、(III)フリーズ画表示/JPEG圧縮、(IV)メモリカードM2への記録からなる4つの処理に大別されるが、これらを並列に実行すれば高速に連写を行うことができる。(I)の処理では、撮像回路52とプリプロセス回路51kとが使われ、(II)の処理では、ポストプロセス回路51nが使われ、(III)の処理では、LCDコントローラ51dとLCDパネル57とJPEGコーデック51cが使われ、(IV)の処理では、CARDコントローラ51iとメモリカードM2が使われるが、それぞれの処理で使われるリソースは競合していないことが分かる。
従って、バックエンジン51は、これらの処理を並列に実行することができる。並列処理が行われるには更に条件(A)、(B)があって、具体的には、(A)処理前のデータ(ソース・データ)が用意されていること、(B)処理後のデータを記憶するバッファメモリが空いていることの2つである。
例えば、RAWバッファ53dからプリプロセスの施されたBayerデータを読み出してポストプロセスを施している間は、RAWバッファ53dが空いていないので、次のコマの静止画を撮影してプリプロセスの施されたBayerデータをそこに記憶することはできない。同じく、バックエンジン51では、YCbCrバッファ53aから主画像を読み出してJPEG圧縮を施している間、YCbCrバッファ53aが空いていないので、次のコマの主画像を作成してそこに記憶することはできない。
逆に、前のコマの処理が早く終了してバッファメモリが空いていても、次のコマのソース・データが用意されていない時には、バックエンジン51では、その処理を実行することができない。つまり、バックエンジン51では、条件(A)、(B)が満たされている間、4つの処理(I)〜(IV)を並列に実行し、満たされない条件が出てきた時には、それに対応する処理を停止する動作になる。これらの条件ができるだけ満たされるようにするには、図13のRAWバッファ53d、YCbCrバッファ53a、JPEGバッファ53eをそれぞれ2つ用意すると良い。
つまり、バックエンジン51では、JPEGバッファ53eに記憶された1コマ目のファイルイメージを読み出してメモリカードM2に記録しつつ、それと並行してYCbCrバッファ53aに記憶された2コマ目の3つの画像(主画像、フリーズ画及びサムネイル)をJPEG圧縮して別のJPEGバッファ53eに記憶する。それと並行して、バックエンジン51では、RAWバッファ53dに記憶され3コマ目のBayerデータにポストプロセスを施して別のYCbCrバッファ53aに記憶し、それと並行して4コマ目の静止画データにプリプロセスを施して別のRAWバッファ53dに記憶する並列処理が可能になる。
上記の(I)及び(II)の処理は、RAWバッファ53d、上記の(II)及び(III)の処理は、YCbCrバッファ53a、上記の(III)及び(IV)の処理はJPEGバッファ53eをそれぞれ共有しているので、これらを並列に実行する時には、バックエンジン51では、各処理が必ず異なるバッファを使用するよう排他制御を行う。1コマの処理が終わる度に各処理が2つバッファを入れ換えるようにすれば、この並列処理(連写)を継続して続けることができる。
ここで、4つの処理(I)〜(IV)が並列に実行されている時には、バッファメモリに空きがなく、何れかの処理が早く終了しても次のコマの処理に入ることはできない。一方、上述した4つの処理(I)〜(IV)の処理時間が極端に異なる場合、バックエンジン51では、早く終了した処理が他の処理が終わるのを待つので効率的な並列処理ができない。
従って、処理時間ができるだけ近接するように工夫する。例えばポストプロセスで3つの画像を並列に作成するとか、JPEGコーデック51cを2つ持って符号量制御(Bit Rate Control)に掛かる時間を短縮するとか等の工夫を行う。多くの場合、RAWバッファ53dとYCbCrバッファ53aとを2つずつ設けると共に、JPEGバッファ53eは、例えば5つ設ける。JPEGバッファ53eには、圧縮されたデータが記憶されるので容量が少なく、それを少し多目に設けることは比較的容易である。
尚、メモリカードM2は、着脱式であるため、書込速度の遅いメモリカードが使用された時には、連写のコマ速に影響する。JPEGバッファ53eの数が多いと前のコマの記録が終わるのを待たずに次のコマの圧縮データをそこに蓄積していくことができる。そのため、低速のメモリカードが使われた場合でも高速な連写が或る程度長く続けられる。例えば、上述した数のバッファメモリが設けられていると、以下のコマ数だけは高速な連写ができる。
高速連写のコマ数 = 2+2+5+α = 9+α ------- (1)
(1)式の中の「9」はバッファメモリの総数であり、これらのバッファメモリが満杯になるまでは必ず高速連写ができることを示している。
一方、(1)式の中の「α」は、バッファメモリが満杯になるまでに書き込みが終了しているコマ数を表す。このαは、メモリカードM2の書込速度に依存して変わる。これらのバッファメモリが満杯になった後もメモリカードM2の書込速度に応じたコマ速で連写は続けられるが、バッファメモリが満杯になる前のコマ速よりも当然遅くなっている。高速連写の中にはプリプロセスが施されただけの画像データをひたすらRAWバッファ53dに蓄積していくものもあり、撮像回路52からの画像データ出力が極めて速い場合に利用される。
この場合、RAWバッファ53dを多数設けることになるが、RAWバッファ53dは、記憶容量が大きいため記憶容量の大きなDRAMが必要になりコストアップに繋がる。電子カメラ50では、バッファメモリの数を増やすことでそれらが満杯になるまで高速な連写は行えるが、それ以降は、バッファメモリに蓄積された画像データを処理しながら撮影を行うのでコマ速は遅くなる。連写のコマ速が突然遅くなる場合、一旦、電子カメラ50は、ライブビューの動作に戻り、焦点調整(AF)や測光演算(AE)や構図合わせをやり直すことも有益である。ライブビューに入っている時間は長くないので速やかに開始される必要がある。
しかし、図11に示す画像処理回路51aの構成では、速やかに開始することが困難である。図中のポストプロセス回路51nは、RAWバッファ53dに記憶されているBayerデータにポストプロセスを施すため使われている。RAWバッファ53dの数が多い時には、ポストプロセス回路51nが空くまでに時間が掛かるため、直ぐライブビューに入ることはできない。そこで、電子カメラ50の動作に対応するため、図14の画像処理回路51aを用いる。
図14は、バックエンジン51の画像処理回路51aの他の形態を示すブロック図である。図14では、第1のポストプロセス回路(PostProc1)51p(図では「PostProc1」と表記する。)と、第2のポストプロセス回路(PostProc2)51q(図では「PostProc2」と表記する。)とが設けられており、丁度、図11の画像処理回路51aのポストプロセス回路51nが、第1のポストプロセス回路51pと第2のポストプロセス回路51qとに置き換わっている。第1のポストプロセス回路51pの入力は、プリプロセス回路51kの第1の出力に常時接続されており、ライブビューの動作時のみ、この第1のポストプロセス回路51pが使われる。
一方、第2のポストプロセス回路51qの方は、撮影した静止画データの処理に使われる。ライブビューの時には、撮像回路52から出力された画像データが先ず入力撮像インターフェース51jで受信される。次いで、画像データは、プリプロセス回路51kに送られてプリプロセスが施され、更にプリプロセス回路51kの第1の出力から出力されて第1のポストプロセス回路51pに入り、そこでポストプロセスが施されてスルー画のYCbCrデータに変換される。最後にそのデータが第1のポストプロセス回路51pから出力されてDRAM53上の第1のYCbCrバッファ(YCbCr1)53gに記憶される。
一方、静止画撮影時には、バックエンジン51では、図14中のセレクタ51mの第2の入力データが選択されて第2のポストプロセス回路51qに入力されるように設定すると共に、プリプロセス回路51kの第1の出力と第1のポストプロセス回路51pを非動作状態に設定する。撮像回路52から出力された画像データは、入力撮像インターフェース51jで受信され、次いで、プリプロセス回路51kに送られてプリプロセスが施される。更に、画像データは、プリプロセス回路51kの第2の出力から出力されて一旦DRAM53上のRAWバッファ53dに記憶される。
この時、プリプロセス回路51kの第1の出力と第1のポストプロセス回路51pとは、非動作状態に設定されているので、バックエンジン51内では、無駄な電力消費がない。これが1ステップ目である。次いで、プリプロセスの施されたBayerデータがRAWバッファ53dから読み出されてセレクタ51mを通り、更に第2のポストプロセス回路51qに入ってポストプロセスが施される。
図14に示す通り、ポストプロセスの施されたYCbCrデータは、第2のポストプロセス回路51qから出力されてDRAM53上に設けられた第2のYCbCrバッファ(YCbCr2)53h(図では「YCbCr2」と表記する。)に記憶される。短冊分割が必要となる大きな画像の場合、ポストプロセス回路51nは、短冊分割でポストプロセスを実行する。これが2ステップ目である。つまり、ライブビューと静止画撮影のポストプロセスでは使用するリソースが全く異なるので、図14の画像処理回路51aを使えば、連写の途中でライブビューに戻って直ぐにそれを開始する動作が可能になる。以上が静止画撮影時の画像処理の全貌である。
<動画撮影時の画像処理>
次に、動画撮影時の画像処理についても簡単に説明する。動画撮影のユーザインターフェース(GUI)は、ライブビューに似ているが、その裏で動画フレームの圧縮処理(H.264等)とメモリカードへの記録が行われている点が異なる。つまり、表示用の画像(スルー画)と記録用の画像との2つがあり、最近はHD(High Definition)動画の記録も珍しくないので、この2つの画像は異なることが多い。例えば、LCDパネル57への表示(ライブビュー)は、VGA(640×480)のサイズで行い、記録はHD(720/1080ライン)のサイズで行うような場合であり、記録用の画像の方一般にスルー画に比べて解像度が大きい。2つの異なるサイズの画像を作成する場合、図14の画像処理回路は有用である。
つまり、バックエンジン51では、図14に示す通り、ライブビューの画像(スルー画)を第1のポストプロセス回路51pで作成し、記録用の画像を第2のポストプロセス回路51qで作成する。動画撮影時は、バックエンジン51では、図14中のセレクタ51mの第1の入力データが選択されて第2のポストプロセス回路51qに入力されるように設定する。この設定をした場合、プリプロセスが施されてプリプロセス回路51kの第1の出力から出力されたBayerデータが第1のポストプロセス回路51pと、第2のポストプロセス回路51qとの両方に入って2つのサイズの画像が並列に作成される。
この時には、最終的に作成された2つのYCbCrデータは、それぞれ、YCbCr1バッファ53g、YCbCr2バッファ53hに記憶されるだけなので、DRAM53へのアクセスが少なくてその帯域を余り占有しないメリットを有する。特にHDの動画をH.264圧縮して記録する場合、DRAM53へのアクセスが多いので、このメリットは有効である。記録用の動画データをプリプロセス回路51kから第2のポストプロセス回路51qに直接流しているため短冊分割することはできず、第2のポストプロセス回路51qは、入力された画像データから少なくともフルHD(1920×1080)の画像(YCbCr)を直接作成するだけの機能を持たなければならない。
これは、第2のポストプロセス回路51qに含まれるフィルタ回路が記憶容量の大きなラインメモリを持つことを意味するが、今のところ動画のサイズにはフルHDという上限があるのでそれが可能になっている。コストは、多少上がるもののライブビューの画像(スルー画)と記録用の画像の間にレイテンシがなくて扱い易い。電子カメラ50には、この他に記録した静止画や動画を再生したり、記録した動画や静止画データをPC等のホスト機器に転送したりする機能もあるが、これらは本発明に直接関係しないので説明は省略する。
ここで、図11や図14の画像処理回路51aを持つバックエンジン51を使用することで、図10に示す基本的な電子カメラ50は構成されるが、画像処理回路51aやJPEGコーデック51cやCPU51b等の処理能力を高めることと、DRAM53の帯域を十分大きく取ることにより、バックエンジン51だけで高性能の電子カメラを実現することができる。
しかし、近年、それだけでは対応できないことも起こりつつある。最近ではCCDセンサに代わってCMOSセンサが多く使われるようになったが、例えば10M画素を超えるフルサイズの画像を60fps以上の高フレームレートで読み出すようなCMOSセンサも技術的には実現可能になっている。撮像回路52から出力された画像データは、先ず、バックエンジンの51入力撮像インターフェース51jで受信され、次いで、それは画像処理回路51a内のプリプロセス回路51kに直接入力されるが、その時には、ピクセルレートが問題になる。例えば、高速なCMOSセンサを含む撮像回路52から出力される画像データのピクセルレート(pixel/sec:pps)は以下のようになる。
ピクセルレート= 10Mpixel/frame×60frame/sec =600Mpixel/sec ----- (2)
つまり、「600Mpps」の高ピクセルレートの画像データがプリプロセス回路51kを流れることになるが、高ピクセルレートの画像データを画像処理回路51aに流すことは困難である(通常は200Mpps程度)。(2)式のピクセルレートは、1V期間(Vsyncの周期)中のブランキング期間も画像データが出力されるとした平均的なピクセルレートであり、実際はブランキング期間を除いたもっと短い時間に有効データ(10M画素)が全て出力されるのでピクセルレートは600Mppsより高くなる。高ピクセルレートの撮像センサは、高速に画像データを出力するため一般的な撮像センサよりも高速な出力インターフェースを備える。つまり、そのインターフェースは通常より伝送クロックの周波数が高く、しかも多数の画素のデータを並列に出力するためデータライン数も多い。
従って、一般的な撮像センサを想定するバックエンジンに超高速の撮像センサを含む撮像回路を直接接続することはできないし、高ピクセルレートの画像データをプリプロセス回路に流すことはできない問題があった。高ピクセルレートの撮像センサの開発の意義としては、多画素でフルサイズの画像を(超)高速に連写する用途の他に、ローリングシャッタに起因する動く被写体の画像の歪みを軽減するという技術的な理由がある。CMOSセンサの電子シャッタは、今のところ全画素が同じタイミングで露光されるグローバルシャッタではなく、ライン読み出しのローリングシャッタが用いられている。そのため、動きの速い被写体の場合、撮影された画像が歪む欠点があった。
この歪みは、有効画素の読み出し時間を短縮することで軽減されるため、高ピクセルレートの撮像センサが考えられたものと思われる。動きによる画像の歪みを無くすのであればメカニカルシャッタを使えば良いのであるが、今度は60fpsのような(超)高速な連写ができない問題があった。
そこで、本実施形態の電子カメラ1は、フロントエンジン12を追加的に利用することにより高ピクセルレートの撮像センサが出力する画像データをバックエンジン13で処理できるようにした。フロントエンジン12は、上述した通り、高ピクセルレートの撮像センサが出力する画像データを一旦受信し、そのピクセルレートを低減してからバックエンジン13に送信する点を特徴とする。すなわち、一般的な撮像センサを使用する場合には、フロントエンジン12が不要な電子カメラを構成し、高ピクセルレートの撮像センサを使用する場合には、フロントエンジン12を追加的に利用して電子カメラを構成するように、スケーラブルで柔軟なカメラシステムが実現される。以下、電子カメラ1の詳細な構成について説明する。
<電子カメラ1の詳細な構成>
図2は、フロントエンジン12及びバックエンジン13の内部構成を説明する図である。また、図2では、電子カメラ1におけるライブビュー動作時の画像データの流れを示している。
ここで、フロントエンジン12を設けるに当たっては、(A)バックエンジン13の既存の信号をできるだけ利用すること(コストの増加を抑える)、(B)ライブビューの時には、スルー画が作成されるまでのレイテンシができるだけ短いこと(レリーズタイムラグを短縮する)、(C)撮影した静止画データを高解像のままバックエンジンに送信すること、(D)バックエンジン13が持っている機能をできるだけ活かすこと、(E)画像撮影の制御(シーケンス)が複雑にならないこと、といった点に配慮している。
図2に示す通り、フロントエンジン12は、入力撮像インターフェース(SIFi)12a(図では「SIFi」と表記する。)、画像縮小回路(Resize1)12b(図では「Resize1」と表記する。)、出力撮像インターフェース(SIFo)12c(図では「SIFo」と表記する。)、SIO12d、DRAMC12e、CPU12f及びバス12pを備える。
尚、入力撮像インターフェース12a、画像縮小回路12b、出力撮像インターフェース12c、SIO12d、DRAMC12e及びCPU12fは、バス12pを介して互いに接続されている。
また、バックエンジン13は、入力撮像インターフェース(SIFi)13a(図では「SIFi」と表記する。)、画像処理回路13b、JPEGコーデック13c、LCDコントローラ13d、CPU13e、DRAMC13f、CARDコントローラ13g及びバス13qを備える。
尚、入力撮像インターフェース13a、画像処理回路13b、JPEGコーデック13c、LCDコントローラ13d、CPU13e、DRAMC13f及びCARDコントローラ13gは、バス13qを介して互いに接続されている。フロントエンジン12及びバックエンジン13の内部の詳細は、順次説明して行く。
図1、図2に示す通り、上記の(A)は、フロントエンジン12から出力される画像データをバックエンジン13の入力撮像インターフェース13aが受信することで達成される。これは、上記の(B)を達成する上でも都合が良い。一方、上記の(C)は、フロントエンジン12がDRAM14(ローカルメモリ)を備えることで達成される。上記の(D)は、入力撮像インターフェース13aが画像データを受信して画像処理を施すことにより達成される。
フロントエンジン12が出力するピクセルレートの低減された画像データは、バックエンジン13の入力撮像インターフェース13aが受信するので、フロントエンジン12は、バックエンジン13に直接繋がる撮像回路11と同じ出力撮像インターフェースを持たなければならない。
つまり、インターフェース的には、バックエンジン13の前に撮像回路11が繋がっているように見える。これは、(E)を達成する上で都合が良い。フロントエンジン12は、撮像回路11から出力される高ピクセルレートの画像データを受信するための入力撮像インターフェース12aも備えている。これらの入力撮像インターフェース12a、13aは、Vsync信号で始まる1フレーム期間の中に、Hsync信号で始まるライン並びの画素データを伝送クロックに載せて送る形式のインターフェースである。つまり、先頭の幾つかのラインと最後の幾つかのラインとが有効画素を含まない垂直ブランキング期間において、その間に有効画素を含むラインが配置される。更に有効画素を含むラインでは、先頭の幾つかの画素と最後の幾つかの画素が有効画素を含まない水平ブランキング期間において、その間に有効画素が隙間なく並べられ伝送クロックに載って画素データが転送される。
従って、これらの入力撮像インターフェース12a、13aは、フロントエンジン12のDRAM14に記憶された画像データを読み出してバックエンジン13のDRAM15に記憶させる転送を行うので、特許文献1に記載のインターフェース(RAW−I/F)とは異なるものである。ここで、CCDセンサは、一般的に、CMOSセンサよりも低速読み出しなのでその撮像回路のデータ出力は各bitが分かれたパラレルインターフェースが多い。
一方、CMOSセンサは、一般的にCCDセンサよりも高速読み出しなのでパラレルインターフェースでは、bit間のいわゆるSkew(歪み)を合わせるのが困難であり、その撮像回路のデータ出力は、各bitをシリアルに伝送するシリアルインターフェースが多い。
シリアルインターフェースの場合には、CMOSセンサは、データと伝送クロックがそれぞれ正極と負極である1対の信号から成り、更に伝送クロックの立ち上がりと立ち下がりの両方でデータの各bitを伝送するDDR(Double Data Rate)動作を行う。この正負1対のデータ伝送路のことを一般に「Lane」と呼んでいる。
VsyncやHsyncの信号は、データの中に埋め込まれた同期コードとして伝送されることが多い。DDR動作を行っているものの伝送クロックの周波数は、ピクセル周波数の「bit数/2」倍必要である。例えば各画素のデータが「12bit」の場合、伝送クロックの周波数がピクセル周波数の6倍になる。より高速に画像データを出力する場合には、Laneの数を増やすが、その場合には、Lane数分の画素が並列に撮像回路から出力される。特別に高速なCMOSセンサでなくてもBayer配列の場合、Laneが2つありR/GrラインのRとGr、それにGb/BラインのGbとBの画素がそれぞれ別のLaneから出力されることが一般的に多い。
つまり、1つのライン上の2色の画素は色分離されて2つの異なるLaneから出力される。従って、高速に画像データを出力するには、この2つのLaneをベースにそれを2倍(4-Lane)、3倍(6-Lane)、4倍(8-Lane)というようにLaneを増やしていく。高ピクセルレートの画像データを出力する撮像回路は、このLane数が多く、且つ伝送クロックの周波数も高い。
フロントエンジン12は、そのような高ピクセルレートの画像データを受信する。一方、フロントエンジン12とバックエンジン13とは、出力撮像インターフェース12cと入力撮像インターフェース13aで繋がっている。この構成は、ライブビューの際に都合が良い。
つまり、この構成によれば、低レイテンシでスルー画を作成する上記の(B)が達成されるからである。具体的には、フロントエンジン12の内部回路とバックエンジン13の画像処理回路13bとを直結して1つの大きなパイプラインとして動作させる。
ライブビューの時には、図1の撮像回路11から出力された画像データが、フロントエンジン12の内部回路を通ってバックエンジン13に送られるが、その際、ピクセルレートの低減された画像データがフロントエンジン12から出力されなければならない。この画像データは、フロントエンジン12の内部回路に留まってから出力されるので、撮像回路11から入力された画像データを同じ画素数のまま低速で出力していては自身のパイプラインが溢れてしまう。
幸いにもライブビューの時には、フロントエンジン12は、VGA(640×480)程度のスルー画を作成するだけなので、そのフロントエンジン12内で画像を適当なサイズまで縮小しても構わない。撮像回路11から送られてくる画像データのピクセルレートは一定なので、フロントエンジン12は、そのフロントエンジン12内でその画像を縮小すればピクセルレートは低減されることになる。
そこで、フロントエンジン12は、ピクセルレート低減手段として先ず画像縮小回路12bを備える。ライブビューの時には、フロントエンジン12は、撮像回路11から受信した画像データをこの画像縮小回路12bで縮小し、バックエンジン13が受信できるまでピクセルレートを低減してから出力する。
この時の画像データの流れを図2に示す。撮像回路11から出力された画像データを受信するため、フロントエンジン12では、そのフロントエンジン12内の先頭に入力撮像インターフェース12aが置かれており、次いで、その後方に画像縮小回路12bが置かれ、更にその後方には、出力撮像インターフェース12cが置かれる構造をしている。
ここで、「SIFo」は、「Sensor InterFace」と「Output」の文字を組み合わせたものである。撮像回路11から出力された画像データは、先ずフロントエンジン12の入力撮像インターフェース12aで受信され、次いで、画像縮小回路12bに送られて縮小され、更に出力撮像インターフェース12cに送られ、そこからバックエンジン13に向けて出力される。
画像縮小回路12bでは、横方向の縮小の他、必要に応じて縦方向の縮小も行いバックエンジン13が受信できるまでピクセルレートを低減する。ピクセルレートが低減されてフロントエンジン12の出力撮像インターフェース12cから出力された画像データは、次いで、バックエンジン13の入力撮像インターフェース13aで受信され、更に画像処理回路13bに入ってプリプロセスとポストプロセスが施される。尚、このバックエンジン13におけるプリプロセスとポストプロセスとの処理は、従来の電子カメラ50と変わりがないので説明を省略する。
図2において、撮像回路11から出てフロントエンジン12内の入力撮像インターフェース12aと画像縮小回路12bと出力撮像インターフェース12cとを貫き、更にバックエンジン13の入力撮像インターフェース13aと画像処理回路13bを通ってDRAM15上のYCbCrバッファ15aに至る矢印が、ライブビューにおける画像データの流れを表しており、最終的に作成されたスルー画のYCbCrデータは、このYCbCrバッファ15aに記憶される。
次いで、このYCbCrデータが読み出されてLCDコントローラ13dに送られLCDパネル17に表示される。
一方、ライブビューの間、バックエンジン13では、測光演算/輝度調整(AE)や焦点調整(AF)やホワイトバランス調整(AWB)の処理も行うので、バックエンジン13内の画像処理回路13bは、適宜3A評価値を抽出してDRAM15上の3Aバッファ15bに記憶する。これらのデータの流れをも併せて図2に示すが、これらは基本的に従来の電子カメラ50(図12参照)と同じである。
但し、図2では、欠陥画素テーブル14aがバックエンジン13のDRAM15上に置かれていない点が従来と異なる。これは、フロントエンジン12で画像の縮小が行われるためである。画像の縮小では、一般的にLPF(ローパスフィルタ)処理と間引きとが行われるが、撮像回路11から出力された画像データには、欠陥画素のデータも含まれているのでそのままLPF処理を施すのは不適切である。
そこで、本実施形態では、フロントエンジン12にも欠陥画素補正回路(DPC:Defect Pixel Correction)を設ける。この欠陥画素補正回路は、画像縮小回路12bの前に置く必要があり、本実施形態では、後々の都合のため入力撮像インターフェース12aの中に欠陥画素補正回路(不図示)を設けている。
フロントエンジン12には、DRAM14が接続されており欠陥画素テーブル14aはこのDRAM14上に置かれる。ライブビューの時には、この欠陥画素テーブル14aの情報が読み出されて入力撮像インターフェース12aに送られ、撮像回路11から受信した画像データに含まれる欠陥画素のデータを内部の欠陥画素補正回路で補正する。このデータの流れも図2に示す。
撮像回路11から出力された画像データは、フロントエンジン12を経由してバックエンジン13に入るので、従来の電子カメラ50よりもレイテンシは増えるものの、それは高々ラインレベルのレイテンシである。従って、「メモリtoメモリ」の転送を行っている特許文献1の電子カメラのようなフレームレベルのレイテンシは発生せず、本実施形態では、上述の(B)が達成されている。
尚、フロントエンジン12には、CPU12fも含まれており、フロントエンジン12内の処理や撮像回路11の駆動は全てこのCPU12fが制御する。
一方、図1でレリーズ釦18がバックエンジン13に接続されていることからも分かるように、画像の撮影を始めとするカメラ全般の動作はバックエンジン13内のCPU13eが制御する。
従って、フロントエンジン12もバックエンジン13の制御下に置かれており、フロントエンジン12のCPU12fは、バックエンジン13のCPU12eから画像の撮影に必要なコマンドを受けて、そのコマンドの処理を行いそのレスポンスを返す動作を行う。フロントエンジン12側の細部の処理は、CPU12fが行うので、その分バックエンジン13のCPU13eの負荷が減り、電子カメラ1全体の制御がスムーズに行われるメリットがある。
その場合には、フロントエンジン12側の処理で必要になる多数のパラメータ類を予めフロントエンジン12のDRAM14に記憶させておき、バックエンジン13のCPU13eは、露光時間や画像サイズや処理モードといった少数のパラメータだけをコマンドと共にフロントエンジン12のCPU12fに送ると通信のオーバーヘッドが少なくて済む。
図2には、フロントエンジン12のCPU12fとバックエンジン13のCPU13eとの間に双方向の矢印が描かれているが、これは、上述したコマンドや少数のパラメータやレスポンスの流れを表す。この通信は、通信インターフェース(幅広の白矢印)を介して行われる。
バックエンジン13のCPU13eは、コマンドの実行に必要な少数のパラメータだけを送信するが、これは通信のオーバーヘッドを減らす他フロントエンジン12を抽象化する役割も持つ。つまり、本実施形態では、フロントエンジン12のハードウェア構成やその細かな動きを考慮しないで済む。そのため、バックエンジン13のCPU13eが実行するプログラムをフロントエンジン12に依存しない形で作成することができる。
フロントエンジン12内の処理及び撮像回路11の駆動は、フロントエンジン12のCPU12fが実行するプログラムによって制御される。バックエンジン13側のプログラム(アプリケーション)は、上位のAPI(Application Program Interface)を呼び出してその機能を利用する。これは、プログラムの移植性や再利用を高めることになり、ひいては従来の電子カメラのプログラムとの共通化にも繋がる。これを進めることで上述した(E)が達成される。
フロントエンジン12側のプログラムは、フロントエンジン12に接続された不図示のFlashメモリに記憶しておくこともできるが、通信インターフェースを介してバックエンジン13からフロントエンジン12側のDRAM14にダウンロードしても良い。これにより、Flashメモリがバックエンジン13側の1つで済むためコストアップが抑えられる。
後者の場合には、先ず、バックエンジン13のCPU13eが起動してバックエンジン13側の初期化を行う。次いで、フロントエンジン12のCPU12fが実行するプログラムをFlashメモリ16(図1参照)から読み出し、そのプログラムを通信インターフェースを介してフロントエンジン12のDRAM14にダウンロードする。最後に、フロントエンジン12のCPU12fが、そのプログラムを実行するシーケンスになるのでシステムの起動が少し遅くなる。
また、バックエンジン13側からプログラムをダウンロードする場合には、フロントエンジン12は、上述した多数のパラメータ類もDRAM14に一緒にダウンロードしておく。ここまでソフトウェアの視点から2種類のエンジンの動きについて説明したが、ライブビューの動作をソフトウェアの視点から再度説明しておく。
<ライブビューの動作>
図2に示す通り、先ず、バックエンジン13のCPU13eは、画像処理回路13bをライブビューの処理モードに設定し、次いで、入力撮像インターフェース13aを有効(Active)に設定し、最後にライブビューコマンドをフロントエンジン12のCPU12fに送信する。
コマンドの実行に必要なパラメータとしては、撮像回路11の露光時間(電子シャッタタイム)、撮像回路11の出力モード番号(画素数とフレームレート)、画像縮小回路12bの縮小率等であるが、撮像回路11の出力モードが決まるとバックエンジン13が受信できるピクセルレートまで低減するための縮小率が自動的に決まる。
そこで、撮像回路11の出力モードと画像の縮小率との組み合わせを決め、フロントエンジン12側でそのテーブルを持つことにすれば縮小率のパラメータは不要になる。画像の縮小率が決まると画像縮小回路のフィルタ係数も決まるので、そのテーブルも併せて持つことにすればフィルタ係数をコマンドと共に送る必要もない。これらのテーブルも起動時に欠陥画素テーブル14aと共にフロントエンジン12のDRAM14にダウンロードしておく。
結局、本実施形態では、フロントエンジン12のハードウェアに依存するパラメータをコマンドと一緒に送る必要はなく、上述した抽象化が達成されていることが分かる。必要なパラメータは、撮像回路11の駆動に関わるものだけであり、この抽象化されたAPIを用いるとフロントエンジン12と撮像回路11の全体が1つの仮想的な撮像回路として扱うことができる(詳細は、図8に示す仮想撮像回路の説明の際、後述する)。
従って、本実施形態では、バックエンジン13からそれらの機能を利用することが容易になり、従来の電子カメラのソフトウェアとの共通化も図れる。これは、ソフトウェアの再利用の観点から好ましい。つまり、実際の電子カメラでは完全な共通化が困難な場合であっても、僅かな修正により他のカメラでも動くプログラムが得られるのは大きなメリットである。
フロントエンジン12のCPU12fは、上述したコマンドとパラメータを受信するとそれに基づきフロントエンジン12の内部回路と撮像回路11を作動させる。具体的には、フロントエンジン12のCPU12fは、デバイスドライバを呼び出してライブビューの処理を行わせ、ピクセルレートの低減されたライブビューの画像データをバックエンジン13に送信する。
従来の電子カメラ50では、図10に示す通り、撮像回路52がバックエンジン51に直接繋がっているため、撮像ドライバもバックエンジン51に実装されており、抽象化されたAPIは最終的にその撮像ドライバを呼び出すことになる。
一方、フロントエンジン12を有する本実施形態の電子カメラ1の場合、そのAPIが後述する仮想撮像ドライバ(図9参照)を呼び出すことになる。実際には、この仮想撮像ドライバが更に通信ドライバを呼び出して上述したコマンドとパラメータをフロントエンジン12に送信し、フロントエンジン12のCPU12fは、そのコマンドを受けて仮想撮像ドライバ及び通信ドライバを呼び出し最終的にライブビューの動作を行う。
以上より、本実施形態の電子カメラ1では、上述した(C)、(D)に加え、(A)、(B)、(E)も達成することができる。尚、ライブビュー中に被写体の明るさが変化した場合(例えば日陰に入った等)、バックエンジン13のCPU13eは、露光時間を変更するコマンドと新しい露光時間(電子シャッタタイム)をフロントエンジン12のCPU12fに送信する。
<電子カメラ1における静止画撮影の動作>
次に、電子カメラ1の静止画撮影動作について、図1、図3を参照して説明する。
図3は、静止画撮影時の画像データの流れを示す図である。ライブビューの最中に図1に示すレリーズ釦18が全押しされると、電子カメラ1は焦点調整(AF)を行ってから被写体の露光に進む。そして、3A検波は、バックエンジン13で行われるのでこの焦点調整(AF)と測光演算(AE)もバックエンジン13のCPU13eで行われる。ここまでの処理は、従来の電子カメラ50と変わりはないが、その後の露光と画像データ出力は、フロントエンジン12が存在するため動作が異なる。バックエンジン13のCPU13eは、先ず、画像処理回路を静止画の処理モードに設定し、次いで、入力撮像インターフェース12aを有効(Active)に設定し、最後に静止画撮影コマンドをフロントエンジン12のCPU12fに送信する。
コマンドと共に送信するパラメータは、撮像回路11の露光時間(電子シャッタタイム)と撮像回路11の出力モード番号(フル解像度)等である。静止画撮影は基本的に1-Shot動作なので、連写の場合にはこれらを繰り返し送信する。
実際には、バックエンジン13側では、この通信を上述したAPIから行う。このAPIから仮想撮像ドライバが呼び出され、その仮想撮像ドライバから更に通信ドライバが呼び出される。そして、フロントエンジン12のCPU12fにコマンドとパラメータが送られる。フロントエンジン12のCPU12fがこれらの情報を受信するとフロントエンジン12の内部回路と撮像回路11とを作動させて静止画の撮影を行う。
CPU12fは、それらのデバイスドライバを呼び出して先ず撮像回路11に露光を行わせ、次いで撮像回路11から静止画データを出力させる。更に、CPU13eは、フロントエンジン12にそのピクセルレートを低減させ、最後に、CPU12fは、ピクセルレートの低減された静止画データを出力撮像インターフェース12cからバックエンジン13に向けて出力させる。
ここで、仮想撮像ドライバを設けることで静止画撮影の動作においてもAPIから上層では、従来の電子カメラと同じソフトウェアが利用できる。
ところで、静止画データのピクセルレートをどのように低減するかという問題が残っている。静止画データを高解像のままバックエンジン13に送信する(C)の条件があるため、ライブビューの時のようにその画像を縮小する方法は使えない。
基本的には、撮影時の解像度(フル解像度)のままバックエンジン13に送信しなければならない。これは、フロントエンジン12にメモリ(DRAM)14を設けることで達成される。つまり、フロントエンジン12では、撮像回路11から出力された静止画データを一旦このDRAM14に記憶し、その静止画データを記憶時よりも低速で読み出すことでピクセルレートの低減された静止画データをバックエンジン13に送信することができる。
つまり、フロントエンジン12は、別のピクセルレート低減手段としてローカルメモリ(DRAM)を備えても良い。フロントエンジン12のDRAM14は、プログラムやパラメータの記憶に利用することを先に述べたが、それは副次的な使い方であり主たる用途は静止画データを一時的に記憶することである。
<静止画撮影時の画像データの流れ>
次に、静止画撮影時の画像データの流れについて説明する。撮影された静止画データは、撮像回路11から出力されて先ずフロントエンジン12の入力撮像インターフェース12aで受信される。次いで、その静止画データは、内部の欠陥画素補正回路(不図示)で欠陥画素のデータが補正され、更に入力撮像インターフェース12aから出力されてフロントエンジン12のDRAM14上に設けられたRAW1バッファ14bに一旦記憶される。
この時は、同じDRAM14から欠陥画素テーブル14aの情報が読み出されて欠陥画素補正回路に入力される。しかし、フロントエンジン12は、ピクセルレートを低減するだけでも良いので、欠陥画素補正を行わずに静止画データをバックエンジン13に送り、バックエンジン13の画像処理回路(プリプロセス回路)に含まれているに欠陥画素補正回路で補正しても構わない。
しかし、バックエンジン13は、ライブビューと静止画撮影とで統一した処理が行えないので制御が複雑になる欠点がある。そのため、静止画撮影時も欠陥画素補正については、フロントエンジン12側で行っている。続いて、フロントエンジン12側では、RAW1バッファ14bから静止画データを読み出し、それをフロントエンジン12の出力撮像インターフェース12cに入力してそこからバックエンジン13に向けて出力する。
この時には、出力撮像インターフェース12cからピクセルレートの低減された静止画データが出力される。DRAM14に記憶された静止画データを「低速」で読み出すと先に述べたが、これは結果的にバックエンジン13側で読み出し可能程度に低速で読み出されることを意味する。
ここで、図3に示す通り、フロントエンジン12の出力撮像インターフェース12cは、バックエンジン13の入力撮像インターフェース13aに合った伝送速度(伝送クロック)で画像データを送信する。そのため、フロントエンジン12のCPU12fがこの出力撮像インターフェース12cの送信動作に合わせて静止画データをRAW1バッファ14bから読み出すと、結果的に、画像データは、低速で読み出されたことになる。
出力撮像インターフェース12cからの送信とRAW1バッファ14bからの読み出しは、一般に非同期である。そのため、フロントエンジン12のCPU12fがRAW1バッファ14bから入力されるデータをそのまま送信していては、バックエンジン13に送られる静止画データに隙間が生じてしまう(歯抜け状になる)。
これは、入出力撮像インターフェース12aのフォーマットとして許されないことであり、そのためフロントエンジン12の出力撮像インターフェース12cは、ラインバッファを持たなければならない。
つまり、出力撮像インターフェース12cは、静止画データを一旦このラインメモリに記憶し、1ライン分の画素のデータが蓄積されたらそれを伝送クロックに載せて隙間なく送信する。このラインバッファを少なくとも2つ設けると送信している間に次のラインのデータが用意されるのでデータの送信がスムーズになる。ライブビューの場合もこれと同様であり、画像縮小回路12bから出力された静止画データは、一旦このラインバッファに記憶してからバックエンジン13に向けて送信される。フロントエンジン12の出力撮像インターフェース12cから出力された静止画データは、この後バックエンジン13に入って画像処理が施される。
この静止画データは、先ず、バックエンジン13の入力撮像インターフェース13aで受信され、次いで、画像処理回路13bに送られて内部のプリプロセス回路(PreProc)でプリプロセスが施される。欠陥画素補正は、予めフロントエンジン12で行われているので、バックエンジン13のプリプロセス回路では残りの処理が施される。
プリプロセスの施された静止画データ(Bayer)は、プリプロセス回路から出力されてバックエンジン13のDRAM15上に設けられたRAW2バッファ15cに一旦記憶される。画像処理回路13b内のプリプロセス回路では、AWB検波も行っており、この時、抽出されたAWB評価値が同じDRAM15上に設けられたAWBバッファ15dに記憶される。ここまでが静止画の画像処理の1ステップ目(プリプロセス)であり、この時のデータの流れを図3に示す。
バックエンジン13のCPU13eは、このAWB評価値を基にAWBアルゴリズムを実行してWBゲインを求め、そのWBゲインを画像処理回路13b内のポストプロセス回路(PostProc)に設定する。次いで、画像処理回路13b内のポストプロセス回路は、画像処理の2ステップ目(ポストプロセス)を実行する。静止画は、一般に巨大なので、ポストプロセス回路は、2ステップ目は、短冊分割で実行する。
ポストプロセス回路は、プリプロセスの施された静止画データ(Bayer)をRAW2バッファ15c上で幾つかの短冊画像に分割し、それらを1つずつ読み出し画像処理回路内のポストプロセス回路に入力してポストプロセスを施し、ポストプロセスの施されたYCbCrデータをDRAM15上のYCbCrバッファ15aに記憶していく。ポストプロセス回路は、この処理を全ての短冊画像について実行すると、YCbCrバッファ15a上には画像処理が済んで1つに繋がった画像が出来上がっている。
2ステップ目では、主画像、表示用画像(フリーズ画)、サムネイルの3つが作成されてそれぞれのYCbCrバッファ15aに記憶される。以上が2ステップ目(プリプロセス)であり、この時のデータの流れも図3に示す。この後は、CPU13eの指示により、撮影結果を確認するため先ずフリーズ画をLCDパネル17に表示させる。具体的には、CPU13eの指示により、DMAコントローラは、YCbCrバッファ15aの1つからフリーズ画を読み出し、それをLCDコントローラ13dに送ってLCDパネル17に表示させる。
一方、CPU13eの指示により、JPEGコーデック13cは、それと並行して上述した3つの画像をJPEG圧縮する。DMAコントローラは、YCbCrバッファ15aから画像データ(YCbCr)を読み出し、それをJPEGコーデック13cに入力し、JPEGコーデック13cから出力された圧縮データをDRAM15上のJPEGバッファ15eに記憶していく。
以上の処理を順次実行して、JPEGコーデック13cは、3つの画像を圧縮する。CPU13eの指示により、CARDコントローラ13gは、3つの画像のJPEG圧縮データをタグ情報と共に1つのJPEGバッファ15e上に配置し、Exif/DCFのファイルやMPFのファイルのファイルイメージを形成していく。CARDコントローラ13gは、このファイルイメージが完成したら各々の画像をメモリカードM1に記録する。
更に、DMAコントローラは、JPEGバッファ15eからこのファイルイメージを読み出し、それをCARDコントローラ13gに入力してメモリカードに記録していく。この記録が終わると静止画のファイルがメモリカード20上に保存されて撮影が完了する。これらの処理におけるデータの流れも併せて図3に示す。フロントエンジン12側のDRAM14は、静止画のピクセルレートを低減するために設けられたが、ピクセルレートを低減するだけならRAW1バッファ14bは1つあれば良いので、DRAM14の記憶領域は、空きが生じて無駄になる。
そこで、この記憶領域を別の目的にも利用する。このDRAM14は、プログラムの記憶やそのプログラムのワークメモリ(変数やスタックの領域)にも使用されるので、それらを除いた記憶領域にRAW1バッファ14bを幾つも割り当てる。これで撮像回路11から出力された静止画データをRAW1バッファ14bに蓄積していく高速な連写(以下、「RAWバッファ連写」という。)行うことができる。
RAW1バッファ14bに静止画データを記憶するのと並行して、出力撮像インターフェース12cは、先に撮影したコマのデータを別のRAW1バッファ14bから読み出しバックエンジン13に送って処理すると長く連写を続けることができる。撮像回路11から出力される画像データは、高ピクセルレートなので、フロントエンジン12のDRAM14は広帯域でなければならない。更にバックエンジン13側のRAW2バッファ15cを複数設けておくと、後段の処理が低速でも画像データの送信が停滞しないので連写が長く続けられる。
全てのバッファメモリ(RAW1、RAW2、YCbCr、JPEG)が満杯になるか、どこかの画像データの流れが停滞し、それが前方に及んでRAW1バッファ14bが満杯になると高速な連写は一旦停止する。
それ以降は、蓄積された静止画データが処理されてRAW1バッファ14bが1つ空く度に撮影が行われる動作になるので、連写のコマ速は遅くなる。これは、従来のカメラと同様であるが、連写のコマ速は遅くなる場合には、一旦ライブビューに戻って焦点調整(AF)や測光演算(AE)や構図合わせをやり直すことも有益である。
以上より、本実施形態の電子カメラ1は、低ピクセルレートの場合には、そのままの画像データをバックエンジン13側に転送するので、バックエンジン13だけでも画像処理の行える最小限のカメラシステムを構成することができる。更に、バックエンジン13が受信できないような高ピクセルレートの撮像センサを使用する場合、フロントエンジン12の画像縮小回路12bは、バックエンジン13が受信できるまでピクセルレートを低減できる。つまり、フロントエンジン12を追加的に利用して対応するというスケーラブルな電子カメラを提供できる。
(第2実施形態)
次に、第2実施形態について説明する。ここで、電子カメラ50の場合、撮像回路52から出力される画像データが高ピクセルレートでないため、ライブビューを行いながらその中の或るフレームを静止画として記録してもその解像度は余り高くない。ライブビューのような高フレームレートで画像データを出力するには画素数を落とさなければならないからである。
そこで、第2実施形態の電子カメラでは、高ピクセルレートの画像データを受信した場合、ライブビューを行いながらその中の或るフレームをフル解像度の静止画として記録する手段を提供する。尚、第1実施形態の電子カメラ1の構成(図1〜図3参照)では、このような手段を提供することが困難である。その理由は、ライブビューの画像データと静止画データの2つを並行してフロントエンジン12からバックエンジン13に送信しなければならないのであるが、図1〜図3に示した2つのエンジン間には、画像データの送信路が1つしかないからである。そこで、第2実施形態の電子カメラでは、画像データの送信路を2つ有するエンジンを用いることにする。
尚、第1実施形態と第2実施形態とでは、図1に示す同じ構成要素については同じ符号を付し、ここでは、相違点について主に説明する。
図4は、第2実施形態の電子カメラの構成例を示すブロック図である。図中のフロントエンジン12からバックエンジン13に向かう実線の矢印は第1の画像データ送信路を表し、同様の点線の矢印は第2の画像データ送信路を表している。実線の矢印の始点には、フロントエンジン12の第1の出力撮像インターフェース12cがあり、実線の矢印の終点には、バックエンジン13の第1の入力撮像インターフェース13aがあって、これらを繋ぐ信号ラインが第1の画像データ送信路になる。
一方、点線の矢印の始点には、フロントエンジン12の第2の出力撮像インターフェース12kがあり、点線の矢印の終点には、バックエンジン13の第2の入力撮像インターフェース13kがあって、これらを繋ぐ信号ラインが第2の画像データ送信路になる。
第1の画像データ送信路には、相対的に低解像度の画像データが流れ、第2の画像データ送信路には、相対的に高解像度の画像データが流れるという風に使い分けられる。具体的には、第1の画像データ送信路には、ライブビューの画像データを流し、第2の画像データ送信路には、静止画データや記録用の動画データを流す。
この使い分けは固定的であって良い。これらの画像データ送信路に流れる画像データは、バックエンジン13が受信できるようにピクセルレートが低減されていなければならない。フロントエンジン12は、このピクセルレートの低減を行う。2つの画像データを並行して送信するため、フロントエンジン12は、複数のピクセルレート低減手段を持つ。
そして、バックエンジン13は、これらの2つの画像データを受信して処理する。2つの画像データを並行して送受信するため新たなフロントエンジン12とバックエンジン13とは、内部構成が電子カメラ1(図2、図3参照)、電子カメラ50(図14参照)と異なる。以下、第2実施形態のフロントエンジン12とバックエンジン13の内部構成及び画像データの流れについて説明をする。
<フロントエンジン12の内部構成例>
図5は、電子カメラ2のフロントエンジン12及びバックエンジン13の内部構成例を説明する図である。図5では、画像データの流れを示している。そこで、画像データの流れに沿って各々のエンジンの内部構成例を説明する。
撮像回路11から出力された、ピクセルレートの低減が必要な高ピクセルレートの画像データは、先ず、フロントエンジン12の入力撮像インターフェース12aに受信され、次いで、欠陥画素補正回路(DPC:Defect Pixel Correction)で欠陥画素のデータが補正される。フロントエンジン12のDRAM14上には、欠陥画素の位置(アドレス)を記憶した欠陥画素テーブルが置かれており、DPCブロック12gは、このテーブルの情報を読み出して補正を行う。
図2と図3では、簡略化のためDPCブロック12gを入力撮像インターフェース12aに含めたが、図5では分かり易くするためこの2つを分けて表した。図5のフロントエンジン12内部の左端の点線枠が図2や図3の入力撮像インターフェース12aに対応する。欠陥画素補正の施された画像データは、3つのピクセルレート低減手段に送られる。その中で第1のピクセルレート低減手段と第2のピクセルレート低減手段は、画像縮小回路を有し、第3のピクセルレート低減手段は、メモリを有する。
図5中の第1の画像縮小回路12bは、第1のピクセルレート低減手段に、第2の画像縮小回路(Resize2)12i(図では「Resize2」と表記する。)は、第2のピクセルレート低減手段に、メモリ(DRAM:RAW1バッファ14b)は、第3のピクセルレート低減手段にそれぞれ対応している。
図5では、第2の画像縮小回路12iの後に2入力のセレクタ(Sel)12j(図では「Sel」と表記する。)が置かれており、セレクタ12jの第1の入力には第2の画像縮小回路12iの出力が繋がり、第2の入力には、RAW1バッファ14bの出力(DRAMCの出力ポート)が繋がる。更に、このセレクタ12jの出力は、第2の出力撮像インターフェース(SIFo2)12k(図では「SIFo2」と表記する。)に繋がる。
図2や図3の画像データの流れと比較すると、図5のフロントエンジン12内部の左端の点線枠内は、図2や図3の入力撮像インターフェース12aに対応する。また、図5のフロントエンジン12内部の右端の点線枠内は、図2や図3の出力撮像インターフェース12cに対応する。また、図5の第2の画像縮小回路12iは、図2や図3の画像縮小回路12bに対応する。また、図5の点線枠内のブロックは、図2や図3の対応するブロックを使用することによって同様の構成にすることができる。
一方、図5の第1の画像縮小回路12b以降のブロックは新たに設けられたものである。図2は、ライブビュー動作時の画像データの流れであるが動画撮影の場合もこれと同じ流れになる。図2では、ライブビューの場合も動画撮影の場合も同じ画像縮小回路12bを用いてピクセルレートを低減し、同じ出力撮像インターフェース12cから画像データを出力している。動画撮影時は、フロントエンジン12から出力された画像データがバックエンジン13の画像処理回路13b内部で2つに分かれ、第1のポストプロセス回路(PostProc1)13j(図では「PostProc1」と表記する。)で表示用のスルー画(YCbCr)が作成され、第2のポストプロセス回路(PostProc2)13p(図では「PostProc2」と表記する。)では、記録用の動画像(YCbCr)が作成される。画像データの送信路が1つの場合、ライブビューと動画撮影の画像データの流れは以上のようになる。
しかし、図5のように画像データの送信路が2つある場合、ライブビューの画像データの流れが変わってくる。具体的には、入力撮像インターフェース12aは、ライブビューの画像データを第1の画像縮小回路12bの方に流している。第1の画像縮小回路12bの後には、第1のプリプロセス回路(PreProc1)12h(図では「PreProc1」と表記する。)が置かれており、その後に第1の出力撮像インターフェース(SIFo1)12c(図では「SIFo1」と表記する。)が置かれる構造をしているが、これは新設されたデータ経路である。
ライブビューの画像データは、常に「第1の画像縮小回路12b→第1のプリプロセス回路12h→第1の出力撮像インターフェース12c」と流れる。これは動画撮影の場合も変わりがない。一方、記録用の動画データの方は「第2の画像縮小回路12i→セレクタ12j→第2の出力撮像インターフェース12k」と流れる。また、静止画データは「RAW1バッファ14b→セレクタ12j→第2の出力撮像インターフェース12k」と流れる。
つまり、静止画データと記録用の動画データとは、第2の画像データ送信路(点線の矢印)を通ってバックエンジン13に送信されるが、ライブビューの画像データの方は、常に第1の画像データ送信路(実線の矢印)を通ってバックエンジン13に送信される。第2の画像データ送信路は、図2や図3にあるものと基本的に同じなので、違いはライブビューの画像データが新設された第1の画像データ送信路の方を通って送信されている点である。
画像データ送信路が1つの場合、動画撮影時に送られてくる記録用の動画データをバックエンジン13がライブビュー(スルー画表示)にも利用していたが、画像データ送信路が2つの場合、ライブビュー用の動画データと記録用の動画データが同時に送られてくるので、バックエンジン13では、それらを別々に処理することになる。
動画撮影時には、記録用の動画データ1つで足りるので無駄にも思われるが、電子カメラ2では、静止画撮影時も動画撮影時もライブビューの画像データを同じ送信路で送ることができるので処理が統一されるメリットがある。つまり、電子カメラ2では、画像データの送信路を2つ設けたために、図14に示すバックエンジン51の構成から図5に示すバックエンジン13の構成に変更している。
<バックエンジン13の内部構成例>
次に、バックエンジン13の構成例について図5を用いて説明する。フロントエンジン12の第2の出力撮像インターフェース12kから出力された画像データを受信するために、バックエンジン13には、第2の入力撮像インターフェース(SIFi2)13k(図では「SIFi2」と表記する。)が設けられている。第2の入力撮像インターフェース13kの後には、第2のプリプロセス回路(PreProc2)13m(図では「PreProc2」と表記する。)が置かれ、その後には、2系統の入力の第2セレクタ(Sel)13n(図では「Sel」と表記する。)が置かれ、更にその後に第2のポストプロセス回路13pが置かれる構成になっている。
第2のプリプロセス回路13mの出力は、第1の出力がこの第2セレクタ13nの第1の入力に繋がり、第2の出力はバックエンジン13のDRAM15上に設けられたRAW2バッファ15cの入力(DRAMCの入力ポート)に繋がっている。
一方、第2セレクタ13nの第2の入力には、同じRAW2バッファ15cの出力(DRAMCの出力ポート)が繋がっており、更にこの第2セレクタ13nの出力が第2のポストプロセス回路13pの入力に繋がり、最後に第2のポストプロセス回路13pの出力がDRAM15上に設けられたYCbCr2バッファ15gの入力(DRAMCの出力ポート)に繋がる。
図5における第2の入力撮像インターフェース13kから第2のポストプロセス回路13pに至る回路は、図14における入力撮像インターフェース51jから第2のポストプロセス回路51qに至る回路と構成が同じであり、図5の回路は、図14の回路を用いることによって構成できる。
静止画撮影の場合、バックエンジン13では、第2のプリプロセス回路13mの第2の出力から出力された静止画データがRAW2バッファ15cに送られるようにすると共に、そのRAW2バッファ15cから読み出された静止画データが第2セレクタ13nの第2の入力から入力されて第2のポストプロセス回路13pに送られるように設定する。
撮影された静止画データは、フロントエンジン12の第2の出力撮像インターフェース12kから出力されてバックエンジン13の第2の入力撮像インターフェース13kで受信される。次いで、静止画データは、第2のプリプロセス回路13mに送られてプリプロセスが施され、更に、第2のプリプロセス回路13mの第2の出力から出力されて一旦RAW2バッファ15cに記憶される。
第2のプリプロセス回路13mでは、AWB検波も行われており、この時抽出されたAWB評価値が図5のAWBバッファ15dに記憶される。ここまでが静止画の画像処理の1ステップ目(プリプロセス)である。バックエンジン13のCPU13e(図2参照)は、このAWB評価値を基にAWBアルゴリズムを実行してWBゲインを求め、そのWBゲインを第2のポストプロセス回路13pに設定する。
次いで、第2のポストプロセス回路13pは、画像処理の2ステップ目(ポストプロセス)を実行する。2ステップ目の処理は、一般に短冊分割で実行される。第2のポストプロセス回路13pは、先ず、プリプロセスの施された静止画データ(Bayer)をRAW2バッファ15c上で幾つかの短冊画像に分割する。続いて、第2のポストプロセス回路13pは、それらを1つずつ読み出してポストプロセスを施す。更に、第2のポストプロセス回路13pは、ポストプロセスの施されたYCbCrデータを図5のYCbCr2バッファ15gに記憶していく。従って、第2のポストプロセス回路13pが、2ステップ目の処理を全ての短冊画像について実行すると、YCbCr2バッファ15g上には画像処理が済んで1つに繋がった画像が出来上がっている。
2ステップ目では、主画像,表示用画像(フリーズ画)及びサムネイルの3つが作成されてそれぞれのYCbCr2バッファ15gに記憶される。以上が静止画の画像処理の2ステップ目(プリプロセス)であるが、これらの静止画データの流れは、第2の画像データ送信路を通る点を除くと基本的に図3と変わりがない。静止画撮影におけるこれ以降の処理は以前に説明した通りなので省略する。
一方、動画撮影の場合には、記録用の動画データが第2のプリプロセス回路13mの第1の出力から出力されるようにすると共に、そのデータが第2セレクタ13nの第1の入力から入力されて第2のポストプロセス回路13pに送られるように設定する。
記録用の動画データは、フロントエンジン12の第2の出力撮像インターフェース12kから出力されてバックエンジン13の第2の入力撮像インターフェース13kで受信される。次いで、記録用の動画データは、第2のプリプロセス回路13mに送られてプリプロセスが施され、更に第2のプリプロセス回路13mの第1の出力から出力されて第2セレクタ13nの第1の入力に入力され、そこから第2のポストプロセス回路13pに送られてポストプロセスが施される。そして、記録用の動画データは、最後に第2のポストプロセス回路13pから出力されて一旦図5のYCbCr2バッファ15gに記憶される。
この記録用の動画データ(YCbCr)は、不図示の動画コーデック(H.264等)で圧縮された後、メモリカードM1に記録されるが詳細は省略する。動画撮影中、第2のプリプロセス回路13mは、一般に被写体が動くので常に焦点調整(AF)を行う必要があり、AF検波回路でAF評価値を抽出しつつそれを用いて焦点調整(AF)を継続して行う。動画撮影中、第2のプリプロセス回路13mは、被写体の明るさとホワイトバランスも適切に保つ必要があり、AE検波回路(AE評価値)とAWB検波回路(AWB評価値)とを適宜稼働させてそれらの調整を行う。尚、3A検波については、後述するライブビュー用の3A検波回路の説明で詳しく述べる。
ここで、記録用の動画データの流れは、第2の画像データ送信路を通る点を除くと基本的に図2と変わりがない。要するに静止画データと記録用の動画データとの流れは、画像データ送信路が2つの場合も1つの場合も同じであり、画像データ送信路を2つ有する図5のフロントエンジン12とバックエンジン13とは、図14におけるプリプロセス回路51kから第2のポストプロセス回路51qに至る回路を上手く利用するように構成されていることが分かる。
つまり、図5の2つのエンジンも図2や図3や図14に示したエンジンをベースに作られている。これは以下に説明するライブビューの場合にも当てはまる。
<ライブビューの画像データの流れについて>
次に、ライブビューの画像データの流れについて説明する。既に説明した通り、ライブビューの画像データは、新設された第1の画像データ送信路を通ってフロントエンジン12からバックエンジン13に送信される。フロントエンジン12がライブビューのために新設されたブロックを含むように、バックエンジン13にもライブビューのために新設されたブロックがある。
これらのブロックは、図14における第1のポストプロセス回路51pを有効に利用するために新設された。図5に示す通り、バックエンジン13の先頭には第1の入力撮像インターフェース(SIFi1)13a(図では「SIFi1」と表記する。)が置かれており、その後に2系統の入力の第1セレクタ(Sel)13iが置かれ、更にその後に第1のポストプロセス回路13jが置かれる構成となっている。バックエンジン13に新設されたブロックは、第1の入力撮像インターフェース13aと第1セレクタ13iの2つである。第1の入力撮像インターフェース13aの出力は、第1セレクタ13iの第1の入力に繋がっており、一方、第2のプリプロセス回路13mの第1の出力が同じ第1セレクタ13iの第2の入力に繋がり、更にそのセレクタの出力が第1のポストプロセス回路13jの入力に繋がっている。
フロントエンジン12を使用する場合、第1の入力撮像インターフェース13aから出力されたライブビューの画像データが、常に第1のポストプロセス回路13jに送られるように第1セレクタ13iを設定する。
一方、バックエンジン13の第2の入力撮像インターフェース13kに撮像回路11を直接接続する場合、第2のプリプロセス回路13mから出力されたライブビューの画像データが第1のポストプロセス回路13jに送られるように第1セレクタ13iを設定する。これは、図14におけるプリプロセス回路51kから第1のポストプロセス回路51pに至るデータ経路に対応している。この場合、第1の入力撮像インターフェース13aは、使われない。
つまり、バックエンジン13内の第1セレクタ13iは、フロントエンジン12から送信されるライブビューの画像データを使うか、或いは、バックエンジン13の第2の入力撮像インターフェース13kに直接接続された撮像回路11から出力されるライブビューの画像データを使うか選択するためのものである。これによって、入力撮像インターフェースを2つ(SIFi1とSIFi2)持つバックエンジンが従来の電子カメラでも使える。
ライブビューの場合、フロントエンジン12の第1の出力撮像インターフェース12cから出力された画像データがバックエンジン13の第1の入力撮像インターフェース13aで受信される。次いで、その画像データは、第1セレクタ13iの第1の入力に入力され、そこから第1のポストプロセス回路13jに送られてポストプロセスが施され、最後に第1のポストプロセス回路13jから出力されて図5のYCbCr1バッファ15fに記憶される。
このライブビュー用のYCbCrデータ(スルー画)は、YCbCr1バッファ15fから読み出され、LCDコントローラ(不図示)に送られてLCDパネル17(図4参照)に表示される。動画撮影の場合、ライブビューの画像データが第1の画像データ送信路から送信されるのと並行して、記録用の動画データが第2の画像データから送信されることを既に述べた。
一方、静止画撮影の場合、フロントエンジン12では、撮影された静止画データを第2の画像データ送信路から送信するのと並行して、ライブビューの画像データを第1の画像データ送信路から送信することができる。これにより、先に述べた電子カメラの特性が全て実現されると共に、上述した(D)の条件も満たされることになる。
ライブビューの場合、他にも考慮しなければならないことがある。先ず、ライブビューの画像データは、バックエンジン13でプリプロセスだけが施される点である。ライブビューの画像データは、その前にプリプロセスが施されなければならない。
バックエンジン13には、第2のプリプロセス回路13mもあるが、これは静止画データや記録用の動画データの処理に使われているためライブビューの画像データのプリプロセスには使えない。ライブビュー用のプリプロセス回路が別に必要となる。フロントエンジン12内の第1のプリプロセス回路12hは、そのためのもので、第1の画像データ送信路と共に新設された。
第1のプリプロセス回路12hがフロントエンジン12にあるのでバックエンジン13のコスト上昇が抑えられ、このバックエンジン13を従来の電子カメラで利用する場合にも都合が良い。
次に考慮しなければならないことは、3A検波である。第2のプリプロセス回路13mは、静止画データや記録用の動画データを処理しているため、その中に設けられた3A検波回路(不図示)を使うことはできない。
動画撮影の場合、バックエンジン13では、第2のプリプロセス回路13m内蔵の3A検波回路を使って記録用の動画データから3A評価値を抽出することもできる。しかし、静止画データを処理している場合、バックエンジン13では、画像データが異なるのでその3A検波回路をそのまま用いることはできない。
従って、ライブビュー用の3A検波回路が別に必要となるが、これをフロントエンジン12の第1のプリプロセス回路12h内に設けると、3Aのソフトウェア処理をバックエンジン13で行うのが困難になる。3Aの評価値がフロントエンジン12側に存在するため、これをバックエンジン13側のソフトウェアが利用すると、処理が遅くなってしまう。3A処理のソフトウェアをフロントエンジン12側に実装することもできるが、従来とは大幅にシステムが変わるのでソフトウェア共通化が難しい問題がある。
そこで、電子カメラ2では、バックエンジン13側にライブビュー用の3A検波回路を設けることにするが、単純に増設したのでは、バックエンジン13のコストが上昇して従来の電子カメラで使う際に不利となる。即ち、第2実施形態では、バックエンジン13の第2のプリプロセス回路13m内にある3A検波回路を外部に出し、それをライブビューの場合にも使えるようにする。動画撮影の場合には特に問題はないが、静止画撮影の場合には、その3A検波回路を静止画データのために使えない問題が起こる。
しかし、静止画データ処理では、3A検波回路がフルに使われておらず、必要となるのは、AWB検波回路だけである。そこで、第2実施形態では、3A検波回路を第2のプリプロセス回路13mの外に出すと共に、その第2のプリプロセス回路13mにはAWB検波回路だけを追加する。
これにより、バックエンジン13でライブビューの画像データから3A評価値を抽出すると共に、静止画データをバックエンジン13の第2のプリプロセス回路13mで処理しつつ、そこからAWB評価値を抽出することができる。
図5において、第2のプリプロセス回路13mの上部にある「3A検波」のブロックが3A検波回路13hを表す。フロントエンジン12から送信されたライブビューの画像データが第1の入力撮像インターフェース13aから入力される場合も、バックエンジン13の第2の入力撮像インターフェース13kに直接接続された撮像回路11からライブビューの画像データが入力される場合も、この3A検波回路13hが使えなければならないので、図5のようにバックエンジン13内の第1セレクタ13iの出力をこの3A検波回路13hの入力に接続する。
この3A検波回路13hの出力は、図5の3Aバッファ15bの入力(DRAMCの入力ポート)に繋がっており、抽出された3A評価値は、この3Aバッファ15bに記憶される。
一方、第2のプリプロセス回路13m内に追加されたAWB検波回路の出力は、図5のAWBバッファ15dの入力(DRAMCの入力ポート)に繋がっており、抽出されたAWB評価値は、このAWBバッファ15dに記憶される。これらの評価値を利用することによりバックエンジン13側のソフトウェアで3Aの処理を行うことができる。第2の画像データ送信路は、静止画データや記録用の動画データが流れるので相対的に高解像度の画像用であり、第1の画像データ送信路は、ライブビューの画像データが流れるので相対的に低解像度の画像用である。動画撮影における記録用の動画データとライブビューの画像データとは、フレームレート(fps)が同じであるが、解像度は前者の方が高いので2つの画像データ送信路に流れる画像データのピクセルレートには差が生じることになる。第2の画像データ送信路に流れる画像データの方が一般にピクセルレートが高い。
そこで、2つの画像データ送信路の性能に差を持たせてコストを抑えることができる。第1の画像データ送信路の伝送クロック周波数を低くしたり、そのデータラインのLane数を少なくしたりして第2の画像データ送信路よりも低コストなものにする。
以上より、電子カメラ2では、第2実施形態の電子カメラ2では、高ピクセルレートの画像データを受信した場合、例えば、ライブビューを行いながらその中の或るフレームをフル解像度の静止画として記録できる。これにより、電子カメラ2では、2つのエンジンのコストを抑えることができる。
(第3実施形態)
次に、第3実施形態について説明する。ここで、上記の実施形態では、フロントエンジン12を用いた場合、そのDRAM14上に多数のRAW1バッファ14bを設けることができ、それによって高速な静止画の連写を長く続けることができると先に説明した。静止画は、一般に解像度が高いため1コマのRAW1バッファ14bでも記憶容量が大きく、それを多数設けることはコスト的に容易ではない。
しかし、撮影した静止画データを一旦圧縮してRAW1バッファ14bに記憶するのであれば、1コマ当たりのデータ量が減るのでより多くのRAW1バッファ14bを設けることができる。そこで、第3実施形態の電子カメラでは、フロントエンジン12に画像圧縮回路を設けることにする。フロントエンジン12のRAW1バッファ14bに記憶される静止画データは元データであるため、上述した画像圧縮は全く歪みのないLossless圧縮か、或いは目立たない程度の歪みしか発生しないNearly Lossless圧縮である必要がある。
尚、第2実施形態と第3実施形態とでは、同じ構成要素については同じ符号を付し、ここでは、相違点について主に説明する。
図6は、第3実施形態の電子カメラのフロントエンジン12及びバックエンジン13の構成例を示すブロック図である。尚、第3実施形態では、図4に示す電子カメラ2を用いて説明する。ここで、図5と図6との構成上の違いは、フロントエンジン12に画像圧縮回路12m(図では「圧縮」と表記する。)と画像伸長回路12n(図では「伸長」と表記する。)とを新たに設けた点である。
図6によれば、欠陥画素補正回路(DPC)の出力が画像圧縮回路12mの入力に繋がり、その画像圧縮回路12mの出力がDRAM上のRAW1バッファ14bの入力(DRAMCの入力ポート)に繋がっている。
欠陥画素補正回路(DPC)から出力された静止画データは、この画像圧縮回路12mで圧縮され、その圧縮されたデータが画像圧縮回路12mから出力されて図中のRAW1バッファ14bに一旦記憶される。画像圧縮では、一般に画素間の相関を利用して圧縮を行うので欠陥画素のデータが含まれていると処理できないが、図6では、先に欠陥画素補正が行われるので問題はない。画像圧縮回路12mは、撮像回路11から出力された高ピクセルレートの静止画データをリアルタイムで圧縮しなければならないので、内部に画像圧縮コアを複数設けて並列に処理する等して、このリアルタイム圧縮を実現する。
リアルタイム処理は、図6の第1の画像縮小回路12bと第2の画像縮小回路12iでも行われており、複数の画素の平均を取る等してリアルタイムでピクセルレートを低減する。
一方、図6の第1プリプロセス回路(PreProc1)12hは、ピクセルレートの低減された画像データを処理するので通常のパイプライン回路で良い。圧縮したデータをRAW1バッファ14bに記憶しているので、DRAM14のアクセス回数が減り、結果としてDRAM14の帯域占有が減るメリットも生まれる。画像圧縮回路12mを備えることで同じDRAM14により多くのRAW1バッファ14bを設けることはできる。
しかし、次に、そこに記憶された静止画データをどのようにしてバックエンジン13に渡すかという課題に直面する。圧縮された静止画データをそのまま送信しても、バックエンジン13は、処理することができない。
そこで、第3実施形態では、フロントエンジン12に画像伸長回路12nを設け、圧縮された静止画データをこれで伸長してからバックエンジン13に送信することにする。
つまり、第3実施形態では、伸長された静止画データを送信するので、これまでのバックエンジン13がそのまま使えることと、追加される画像圧縮回路12m及び画像伸長回路12nがフロントエンジン12側に集約されているので、バックエンジン13のコストが抑えられる2つのメリットがある。
図6のフロントエンジン12は、上述した通り、画像圧縮回路12mと共に画像伸長回路12nを備えている。画像伸長回路12nの入力には、RAW1バッファ14bの出力(DRAMCの出力ポート)が繋がり、その画像伸長回路12nの出力は、図中のセレクタ12jの第2の入力に繋がっている。静止画の圧縮データは、先ずRAW1バッファ14bから読み出されて画像伸長回路12nに送られ、次いで、その圧縮データが伸長されて画像伸長回路12nから出力され、更にセレクタ12jを通って第2の出力撮像インターフェース12kに送られ、最後にその第2の入力撮像インターフェース12kからバックエンジン13に送信される。
伸長後の静止画データは、元の量に戻っている(増える)が、第2の画像データ送信路の送信レートに合わせて伸長が行われるので予定通りピクセルレートは低減される。
尚、図5と図6において、フロントエンジン12内の第1のプリプロセス回路12h、バックエンジン13の内の第1のポストプロセス回路13jとは、合わせて1つの画像処理回路(画像処理回路G1:点線の枠内参照)を構成している。尚、図では「画像処理」と表記する。
また、バックエンジン13内の第2のプリプロセス回路13mと第2のポストプロセス回路13pとは、合わせて1つの画像処理回路(画像処理回路G2:点線の枠内参照)を構成している。尚、図では「画像処理」と表記する。
つまり、バックエンジン13は、低解像度用の第1の入力撮像インターフェース13aが受信した第1の画像データを画像処理回路G1により画像処理を施すと共に、高解像度用の第2の入力撮像インターフェース13kが受信した第2の画像データを画像処理回路G2により画像処理を施す。したがって、バックエンジン13では、第1の画像データと第2の画像データとを独立に画像処理することができる。
以上が2つの画像データ送信路を備えたフロントエンジン12とバックエンジン13における画像データの流れの全貌である。
続いて、フロントエンジン12のDRAM14上にRAW1バッファ14bを多数設けた時の連写について補足説明する。図3を用いて静止画撮影における画像データの流れを説明した時には、電子カメラ1では、静止画データがRAW1バッファ14bに記憶された後、静止画データを無条件に読み出してバックエンジン13に送信するような記載をしたが、実際は、バックエンジン13側のRAW2バッファ15cが空いていないと送信することはできない。
一方、RAW1バッファ14bが空いていない時は、撮像回路11から静止画データを出力することができない。露光終了後に画像データを長く撮像回路11(撮像センサ)内に留めておくことはできないので、RAW1バッファ14bが空いていない時は露光を始めるべきではない。
つまり、フロントエンジン12は、撮影した静止画データを勝手にバックエンジン13に送信してはならず、また、フロントエンジン12も勝手に静止画の撮影を開始してはならない。
画像の撮影のシーケンスは、バックエンジン13側のCPU13eにより撮影シーケンス制御手段として制御されているので、RAW1バッファ14bに静止画データが記憶されており、且つRAW2バッファ15cが空いている時だけフロントエンジン12からバックエンジン13にデータ送信コマンドを発行し、また、RAW1バッファ14bが空いている時だけフロントエンジン12からバックエンジン13に静止画撮影コマンドを送信する。
つまり、静止画撮影時は、フロントエンジン12がRAW1バッファ14bとRAW2バッファ15cの状態を確認した上でコマンドを発行するが、このうちRAW1バッファ14bの状態を確認する時には、バックエンジン13とフロントエンジン12間の通信が発生する。この場合、撮影シーケンス制御手段は、撮影時において、フロントエンジン12に撮影シーケンスのコマンドを送信する。そして、フロントエンジン12は、コマンドを受信して、撮像回路11の撮像と画像データの読み出しとの少なくとも一方の動作を制御する。これにより、バックエンジン13側で撮影のシーケンスを制御するため、フロントエンジン12側では、高ピクセルレートの撮像センサとの通信制御に特化することができる。すなわち、バックエンジン13側では汎用のバックエンジンを採用できる。
一方、バックエンジン13に撮像回路を直接接続している従来の電子カメラの場合、高ピクセルレートの画像データを受信しないことを前提としているため、RAW2バッファが空いていれば静止画の撮影が開始できるという違いがある。
以上より、第3実施形態の電子カメラ2によれば、伸長された静止画データを送信するので、これまでのバックエンジン13がそのまま使える。また、電子カメラ2によれば、追加される画像圧縮回路12m及び画像伸長回路12nがフロントエンジン12側に集約されているので、バックエンジン13のコストを抑えることができる。従って、電子カメラ2によれば、汎用性の高いカメラシステムを構築することができる。
(第4実施形態)
次に、第4実施形態について説明する。第4実施形態では、上述したコマンドについてより詳細に説明するため、ソフトウェアの視点から静止画の撮影を考察する。目的はソフトウェアの共通化と再利用である。先ず、比較例として、バックエンジンだけを持つ(フロントエンジンを必要としない)従来の電子カメラのソフトウェア(ファームウェア)を説明する。
図7は、従来の電子カメラで利用されるソフトウェアの構造の一例を示す図である。図7において、ソフトウェアは、アプリケーション層101、ミドルウェア層102、カーネル層103、デバイスドライバ層104及びハードウェア層105を有する。
最上位層は、アプリケーション層101であり、その製品固有の機能を実現するプログラムで構成される。
図7には、電子カメラの主な機能を実現するアプリケーションプログラムが載っており、これらのプログラムは、その下位にあるプログラムを呼び出すことによって目的の機能を実現する。つまり、下位のプログラムを呼び出すためのAPIが用意されている。APIとしては、例えば、静止画撮影101a、動画撮影101b、ライブビュー101c、画像再生101d、画像通信101e、カメラ設定101fが用意されている。これらのAPIを標準化しておくことでそのアプリケーションプログラム別の電子カメラで利用することができる。アプリケーション層101の下はミドルウェア層102であり汎用的なライブラリソフトもここに含めている。ミドルウェア層102としては、例えば、ミドルウェア102a及びライブラリ102bを有する。
カーネル層103は、RTOS(Real Time Operating System)103aを有する。また、デバイスドライバ層104は、その他の周辺ドライバ104a、画像処理ドライバ104b、撮像ドライバ104cを有する。ハードウェア層105は、ハードウェア制御用のソフトウェアとして、その他の周辺ハードウェア105a、バックエンジン105b、撮像回路105cを有する
ここで、ライブラリ102bには、ソフトウェアベンダから購入するものもある。ミドルウェア層102は、複数のアプリケーションプログラムが利用するような共通性の高いプログラムで構成されるが、重要なことはハードウェアの詳細構造に依存しないようなプログラムにすることである。例えば、画像のサイズを変更する解像度変換(変倍)等は、画像の撮影でも画像の再生でも利用されるが、その処理は、バックエンジン13内の画像処理回路(ポストプロセス回路)13b(図3参照)で実行される。
しかし、ミドルウェア層102のプログラムは、ポストプロセス回路を直接動かすことはせず、一例として、変倍前の画像データが記憶されたバッファメモリのアドレス、変倍前の画像サイズ、変倍前の画像から解像度変換対象の画素を切り出すための座標値と切り出しサイズ、変倍後の画像データを記憶するバッファメモリのアドレス、変倍後の画像サイズ(または倍率)等の引数を指定して下位のプログラムを呼び出す。
例えば、解像度変換の機能を呼び出すAPIでは、その解像度変換の機能の処理を何に行わせるかは指定していない。つまり、解像度変換を行うハードウェアに依存しないようにAPIが構成されている(抽象化)。実際にポストプロセス回路を起動させるのは、このAPIによって呼び出されたプログラムである。
具体的には、デバイスドライバ層104のプログラムである画像処理ドライバ104bがポストプロセス回路を起動させる。ミドルウェア層102の下は、カーネル層103であり、RTOS103aが置かれている。上述した通り、電子カメラでは、複数の処理が並列に実行されるが、これらの処理を行うプログラムをRTOS103aのタスクとすることで並列処理が実現される。カーネル層103の下は、デバイスドライバ層104であり、その下のハードウェア層105に含まれる色々なハードウェアを動かすプログラムが置かれる。
ハードウェア層105には、画像処理回路(プリプロセス回路、ポストプロセス回路)、JPEGコーデック、LCDコントローラ、CARDコントローラ、USBコントローラ等を備えるバックエンジン内部の回路の他、撮像回路やバックエンジンに繋がった周辺デバイス等が含まれる。
デバイスドライバ層104を設けることでハードウェアが抽象化されるため、ハードウェアが変わっても、デバイスドライバを変更するだけで上位のプログラムは、そのまま動かすことができる。
但し、上位層のプログラムから下位層のプログラムを呼び出すAPIは、標準化する必要がある。以上のことを踏まえた上で、電子カメラ1のソフトウェアについて説明する。
<電子カメラ1のソフトウェアについて>
電子カメラ1は、フロントエンジン12を新たに備えているが、従来の電子カメラのソフトウェアとの共通化を図るため、このフロントエンジン12を抽象化することを既に説明した。
図8は、仮想撮像回路を説明する図である。具体的には、図8に示す通り、フロントエンジン12とそれに繋がった撮像回路を合わせて仮想的な撮像回路として抽象化する。つまり、フロントエンジン12の出力撮像インターフェース(SIFo1とSIFo2)は、撮像回路が画像データを出力するためのインターフェースと同じものである。これにより、仮想的な撮像回路という抽象化が実現する。この抽象化を行うことにより、図8の左側の回路は、右側の回路のように見える。換言すると、図8の左側の回路と右側の回路とは、等価回路として扱うことができる。これ以降は、仮想的な撮像回路のことを「仮想撮像回路」、従来の電子カメラで使われる撮像回路(図10参照)のことを「普通撮像回路」、電子カメラ1のフロントエンジン12に繋がっている撮像回路(図8の左側)を「高速撮像回路」と呼んで区別する。
抽象化とは、図8に示す高速撮像回路11aとフロントエンジン12とを一体化して仮想的な仮想撮像回路30と見なすことであるが、この仮想撮像回路30が普通撮像回路(例えば、図10に示す撮像回路52)と同じように動作させることが重要である。これにより、従来の電子カメラのソフトウェアがそのまま利用できるからである。これが抽象化の目的である。
普通撮像回路は、バックエンジン13が直接受信できるピクセルレートの画像データを出力する。一方、仮想撮像回路30から出力される画像データは、ピクセルレートが低減されており、バックエンジン13で直接受信することができるので、機能上の類似性は備えている。
フロントエンジン12が2つの出力撮像インターフェース(SIFo1とSIFo2)を備えていることに対応して仮想撮像回路30も画像データ出力用のインターフェースを2つ持つが、普通撮像回路の方は、インターフェースが1つなのでその点が大きな違いとなっている。
但し、ソフトウェア的な観点から見ると、インターフェースの数が異なる点は、特に問題にならない。この違いは、デバイスドライバ層104で遮蔽されて上位層のプログラムには、見えないからである。重要なのは機能上の違いである。その違いとは、仮想撮像回路30は、2つの異なる画像データを同時に出力できる点であり、これは、既に説明したフロントエンジン12の動作に対応している。図8の右側の仮想撮像回路30から外に向かう実線の矢印からは、ライブビューの画像データが出力される。また、点線の矢印からは、静止画データや記録用の動画データが出力される。
つまり、ライブビューを行いながら撮影された静止画データを出力したり、ライブビューを行いながら記録用の動画データを出力したりする並列動作ができる。
一方、普通撮像回路から2つの異なる画像データを出力する場合、シーケンシャル動作となる。普通撮像回路の場合、1つの画像データ出力モードが終わってから別の画像データ出力モードに移るが、仮想撮像回路30の場合、1つの画像データ出力モードを動作させたまま別の画像データ出力モードを動作させることができるので、制御のシーケンスが異なっている。
図8の右側の回路と図10の回路とは、見かけ上同じであるものの、制御のシーケンスが異なっているので、電子カメラ1と電子カメラ50とではソフトウェアが若干異なる。
しかし、仮想撮像回路30という抽象化によって上位層のソフトウェアは、かなり共通化される。つまり、仮想撮像回路30を動かすのに従来とほぼ同じAPIが使えることになり、上位層のプログラムは、このAPIを呼び出すことによって画像の撮影を行うことができる。上述したように若干の変更は必要なものの、ほぼ同じAPIを用いて作成することができるため、上位層のプログラムは、従来の電子カメラの上位層のプログラムを適宜用いることができる。
図8の右側の回路において、バックエンジン13から仮想撮像回路30に向かう矢印は、仮想撮像回路30を動かすための仮想制御信号である。この仮想制御信号も抽象化の一部であって上述したAPIを用いて制御される。仮想撮像回路30という抽象化を行った結果、バックエンジン13側のソフトウェアは、図9の左側のようになる。
図9は、電子カメラ1のソフトウェアの構造の一例を示す図である。図9の左側のデバイスドライバ層104には、ソフトウェアインターフェースの一種である仮想撮像ドライバ104dがあって、これが図8の右側の仮想撮像回路30を動作させる。この仮想撮像ドライバ104dは、上述したAPIを用いて上位層のプログラムから呼び出されるが、その下のハードウェア層105には撮像回路がないため、実際の処理は、図7に示す撮像ドライバ104cとは異なる。つまり、仮想撮像ドライバ104dは、更にその下にある通信ドライバ104eを呼び出し、この通信ドライバ104eが撮像に関わるコマンドとパラメータをフロントエンジン12に送信する。
上述したAPIは、上位層のプログラムから呼び出されるので、その引数も上位層の情報が少数渡されるだけである。そのため、フロントエンジン12に送られるパラメータも少量になって通信のオーバーヘッドが抑えられる。
図9の左側のハードウェア層105には、通信Interface105dがあり、通信にはこのインターフェースが使われる。仮想撮像回路30からは、画像データが出力されるのでバックエンジン13内部の画像処理回路13bは、通信Interface105dから送られた情報を受信して処理しなければならず、上位層のプログラムが仮想撮像ドライバのAPIを呼び出す時には、図9に示す左側の画像処理ドライバ104bのAPIも併せて呼び出す必要がある。仮想撮像回路30の2つのインターフェースは、この画像処理ドライバ104bが吸収するので上位のAPIからは見えない。
図9の左側のデバイスドライバ層104を見ると、図7のデバイスドライバ層104と同様の構成になっており、電子カメラ1のソフトウェアを従来の電子カメラと共通化する目標がかなり達成されていることが分かる。
続いて、図9の右側に示されたフロントエンジン12側のソフトウェアについて説明する。フロントエンジン12側のソフトウェアもバックエンジン13側と同じように階層化されている。フロントエンジン12側のソフトウェアは、アプリケーション層201、ミドルウェア層202、カーネル層203、デバイスドライバ層204及びハードウェア層205を有する。
アプリケーション層201は、静止画撮影201a、動画撮影201b及びライブビュー201cを有する。ミドルウェア層202は、ミドルウェア202a及びライブラリ202bを有する。カーネル層203は、RTOS203aを有する。デバイスドライバ層204は、画像処理ドライバ204a、通信ドライバ204b及び撮像ドライバ204cを有する。ハードウェア層205は、フロントエンジン205a、通信Interface205b及び撮像回路205cを有する。
一番下層のハードウェア層205の通信Interface205bは、バックエンジン13から送られた情報を受信する。これは物理層の見方であって、この情報をその上のデバイスドライバ層204にある通信ドライバ204bが受信するのが論理層の見方になる。
フロントエンジン12がレスポンスを返す時には、逆方向に情報が送信される。ハードウェア層205にある撮像回路205cとは、高速撮像回路11aのことであり、この高速撮像回路11aからは高ピクセルレートの画像データが出力される。
高速撮像回路11aは、その上のデバイスドライバ層204の撮像ドライバ204cによって駆動される。ハードウェア層205の残り1つは、フロントエンジン12内部ブロックをまとめて表したものであり、これらのブロックは何れも高速撮像回路11aから出力された画像データの処理に関わる。
これらのブロックは、1つ上のデバイスドライバ層204にある画像処理ドライバ204aによって駆動される。その上のソフトウェアもバックエンジン13側と同様の構成となっているが、その中でアプリケーション層201のプログラムについて補足説明する。
フロントエンジン12側には、静止画撮影201a、動画撮影201b及びライブビュー(LiveView)201c等のアプリケーションプログラムが記載されている。これらのアプリケーションプログラムは、バックエンジン13側のアプリケーションプログラムに対応するコマンドを解釈するだけのプログラムである。静止画撮影201a、動画撮影201b及びライブビュー201cの3つのアプリケーションプログラムは、電子カメラの基本動作モードであり、これらのアプリケーションプログラムは、アプリケーション層201で決定されるが、その情報はアプリケーション層201よりも下位層にも伝えられる必要がある。
その理由は、動作モードによって画像データの処理内容やデータの経路が変わるからである。そこで、バックエンジン13から受信したコマンドとパラメータを先ずアプリケーションプログラムに渡してそのコマンドを解釈する。これにより、動作モードが確定したら一緒に受信したパラメータを引数にして上述したAPIを呼び出し、モードに応じた動作を行わせる。これにより、フロントエンジン12側のソフトウェアもバックエンジン13側と同様な階層構造となる。
しかし、フロントエンジン12側の階層構造は、一例であって、更に単純な階層構造であっても良い。また、フロントエンジン12側の機能は限られているので、汎用のライブラリの使用を少なくしても良い。
一方、フロントエンジン12側では、ライブビューを行いながら静止画データをバックエンジン13に送信したり、仮想撮像回路30から出力された画像データを、DRAM14内のRAW1バッファ14bに記憶しながら別のRAW1バッファ(不図示)から読み出した画像データをバックエンジン13に送信したりするような並列処理を行う。そのため、フロントエンジン12側にもRTOS203aを導入してマルチタスク処理を行う必要がある。インターフェースが2つあるために仮想撮像回路30の動作は、普通撮像回路と少し異なると述べたが、その他に違いとして、特に静止画撮影の場合について説明する。
先ず、普通撮像回路と高速撮像回路11aの動作は、(i)被写体を露光して撮像センサに信号電荷を蓄積する、(ii)蓄積された電荷信号をデジタルデータに変換して各々の撮像回路から出力する、の2つから成っている。
電子カメラ50における静止画撮影では、条件(ii)で普通撮像回路(図10の撮像回路52)から出力された静止画データがバックエンジン51で受信され、次いでプリプロセス回路でプリプロセスが施されてRAWバッファ53dに記憶されるという動作が行われる。
一方、図8に示す通り、仮想撮像回路30の動作も、(I)被写体を露光してデジタルの静止画データを生成する、(II)(生成された静止画データを高速撮像回路11aから出力する、という2つの条件に分けることができる。
電子カメラ1における静止画撮影では、仮想撮像回路30が条件(I)と条件(II)との動作を順次行っており、条件(II)の場合、仮想撮像回路30から出力された静止画データが従来の電子カメラと同様、バックエンジン13側で受信されて処理される。仮想撮像回路30の動作は、高速撮像回路11aとフロントエンジン12の動作から成るので、条件(I)と条件(II)とがそれらの何の動作に対応しているのかについて説明する。
高速撮像回路11aの動作は、条件(i)と条件(ii)とから成るが、フロントエンジン12の動作は、(a)高速撮像回路11aから出力された静止画データをRAW1バッファ14bに記憶する、(b)RAW1バッファ14bに記憶された静止画データを読み出してバックエンジン13に送信する、の2つの条件から成っている。
このうち、条件(ii)と、条件(a)とは、並列動作なので、高速撮像回路11aとフロントエンジン12とが連動しているが、条件(i)の方は、高速撮像回路11aの単独の動作になる。条件(b)の動作は、フロントエンジン12とバックエンジン13とが連動しているものの高速撮像回路11aの動作とは独立しており、この時は、送信された静止画データにプリプロセスを施してRAW2バッファ15cに記憶する動作がバックエンジン13側で並行して行われる。フロントエンジン12の条件(b)の動作は、普通撮像回路の条件(ii)の動作や、仮想撮像回路30の条件(II)の動作に対応すると考えるのが自然である。
すると、仮想撮像回路30の条件(I)の動作は「高速撮像回路11aの動作(条件(i))+高速撮像回路11aの動作(条件(ii))+フロントエンジン12の動作(条件(a))」に対応させるのが好ましい。
つまり、高速撮像回路11aによる被写体の露光からRAW1バッファ14bに静止画データが記憶されるまでの動作が仮想撮像回路30の条件(I)の動作に対応し、RAW1バッファ14bに記憶された静止画データを読み出してバックエンジン13に送信する動作が仮想撮像回路30の条件(II)の動作に対応すると考える。仮想撮像回路30の2つの動作を上述したように対応させた場合、仮想撮像回路30の条件(I)の動作と普通撮像回路(例えば、撮像回路52)の条件(i)の動作が同じであり、仮想撮像回路30の条件(II)の動作と普通撮像回路の条件(ii)の動作が同じであると考えることができるか否かを検討する。
これらの動作が同等であれば静止画撮影のソフトウェアも従来の電子カメラがそのまま使えることになる。しかし、2つの撮像回路(普通撮像回路、仮想撮像回路)の動作には違いがある。フロントエンジン12側には、RAW1バッファ14bが幾つも設けられているので、撮影した静止画データをそこに蓄積していく動作を行うことができる(RAWバッファ連写)。
一方、それと並行して先に撮影された静止画データをRAW1バッファ14bから読み出してバックエンジン13に送信する動作が行われる。
前者(RAWバッファ連写)は、条件(I)の動作であるが、これは仮想撮像回路30の「露光動作」と考えることができる。後者は、条件(II)の動作であるが、これは仮想撮像回路30の「静止画データの出力動作」と考えることができる。普通撮像回路の露光動作である条件(i)と、静止画データの出力動作である条件(ii)とは不可分な動作であるが、仮想撮像回路30の条件(I)と条件(II)の動作には違いがある。不可分とは、撮影された静止画データを撮像回路から出力するまでは、次の静止画の露光を開始することができない意味である。条件(i)と条件(ii)の動作が不可分であることは、高速撮像回路11aも同じである。
一方、仮想撮像回路30の場合、電子カメラ1では、撮影した静止画データを出力する前に、次の静止画の露光を始めることができる特徴がある。つまり、撮影した静止画データを仮想撮像回路30の中に溜めておくことができる。これは、RAW1バッファ14bを幾つも持っているために生じた特性である。撮影した静止画データを仮想撮像回路30から出力した後で次の静止画の露光を始めるとした場合、RAW1バッファ14bは、1つでも構わないことになり、それを幾つも設ける理由がなくなる。従って、電子カメラ1では、RAW1バッファ14bを幾つも設けることで静止画データの出力動作に依存しない高速な連写が可能になる。
但し、空いているRAW1バッファ14bが無くなった時には、次の露光を始めてはならない。仮想撮像回路30という抽象化を行うとバックエンジン13側の上位層のプログラムからはRAW1バッファ14bが見えないため、仮想撮像回路30では「State1」の状態を設ける。これにより、仮想撮像回路30では、RAW1バッファ14bが空いていない時には、State1をBUSYに設定し、RAW1バッファ14bが空いた時には、State1をREADYに設定し、この情報を利用する。
このState1の状態は、仮想撮像ドライバ104dから上位層のプログラムに伝えられる。静止画撮影を行うプログラムは上述したAPIを呼び出して仮想撮像ドライバ104dからState1の状態を取得し、これがBUSYの時には、仮想撮像回路30は、READYになるまで待ちState1がREADYになったら露光を始める。
一方、撮影した静止画データを仮想撮像回路30から出力する場合にも似たような事情がある。つまり、RAW1バッファ14bが空の時には、仮想撮像回路30は、静止画データを出力することができない。そこで仮想撮像回路30では、もう1つ「State2」の状態を設ける。これにより、仮想撮像回路30では、RAW1バッファ14bに静止画データが記憶されている時には、State2をREADYに設定し、RAW1バッファ14bが空の時は、State2をBUSYに設定し、この情報を利用する。
このState2の状態も仮想撮像ドライバ104dから取得される。バックエンジン13側のRAW2バッファ15cが空いていない時には、仮想撮像回路30は、静止画データを出力することができないので、その状態もチェックしなければならない。State1やState2の状態は、仮想撮像ドライバ104dが通信ドライバ104eを介してフロントエンジン12側から取得するが、RAW2バッファ15cの状態は、バックエンジン13側で取得される。
画像撮影用のソフトウエアの一つである静止画撮影のプログラムは、先ず、RAW2バッファ15cの状態をチェックし、それが空いている時には、上述したAPIを呼び出して仮想撮像ドライバ104dからState2の状態を取得する。State2の状態がBUSYの時には、静止画撮影のプログラムは、READYになるまで待ちState2がREADYになったら静止画データの出力を開始する。尚、いわゆる処理の終了を定期的にチェックするAPI(ポーリング)の代わりに割り込みを利用して次の露光開始のタイミングや、次の静止画データ出力のタイミングを知る方がプログラムの中断が減るので効率が上がる。
つまり、仮想撮像回路30のState1やState2の状態がREADYになる度に割り込みが発生し、次の露光や静止画データ出力が可能になったことを仮想撮像ドライバ104dから静止画撮影のプログラムに伝える。
但し、State2割り込みは、単独ではなくRAW2バッファ15c(図3参照)の状態とのAND(論理積)で発生するようにしておく。割り込みが発生した時には、静止画撮影プログラムが上述したAPIを呼び出して仮想撮像回路30に露光や静止画データの出力を行わせるが、上述したようにこれらの2つは独立した動作であるため、そのAPIも別々に用意する必要がある。
つまり、静止画撮影のプログラムは、発生した割り込みに応じてそれぞれのAPIを呼び出す。一方、普通撮像回路の場合には、これらの2つが不可分(一体的)な動作であるため、静止画撮影のプログラムは、1つのAPIで呼び出すことができる。仮想撮像回路30の場合には、State1がREADYであれば露光を行うことができ、State2がREADYでRAW2バッファ15cが空いていると静止画データを出力することができる。ここで、この2つの動作の進み方はどちらの方が速いかが問題となる。
仮想撮像回路30の露光動作では、撮影した静止画データをRAW1バッファ14bに記憶するまでの動作が行われ、静止画データの出力動作では、この静止画データをRAW1バッファ14bから読み出してバックエンジン13に送信する動作が行われる。
後者の静止画データの出力動作では、ピクセルレートの低減が行われるため、その出力動作の進み方の方が遅れる傾向がある。バックエンジン13側の処理が遅いと、この遅れは更に大きくなる。そのため、RAW2バッファ15cを複数設けて静止画データの出力が滞らないようにしているものの、バックエンジン13側には、他のバッファメモリ(YCbCr1,YCbCr2,JPEG等)も設けられているので限界がある。
つまり、RAWバッファ連写の場合、撮影された静止画データが仮想撮像回路30の中に複数残っている状態が発生する。この状態で露光を行う場合も静止画データを出力する場合もそれぞれコマ番号を指定する必要がある。コマ番号を指定しないと撮影順序を取り違えてしまう恐れがあるからである。そこで、上述した2つのAPIにもそれぞれコマ番号という引数を設けることにする。静止画撮影において、仮想撮像回路30の2つの機能(動作)を呼び出すAPI関数としては以下のようなものが考えられる。
露光動作 : SensorExposure(n,・・・) ----- (3−1)
静止画データの出力動作 : StillImageDataOut(m,・・・) ----- (3−2)
SensorExposure( )という関数の括弧内の「n」は露光(撮影)時のコマ番号を指定するための引数である。それ以外の引数は「・・・」で表されているが、ここには、露光時間や撮像回路の感度等が入る。
一方、StillImageDataOut( )という関数の括弧内の「m」は仮想撮像回路30から静止画データを出力する時のコマ番号を指定する引数である。最後に露光(撮影)されたコマ番号を「Nmax」とすれば常に「m≦Nmax」となる。露光時のコマ番号nの初期値は「0」であり、静止画撮影プログラムは露光を開始する前にnを「1」増やしてから露光動作のAPI関数を呼び出す。
従って、露光時のコマ番号nは、「1→2→3→・・・」というように単純に1ずつ増えていく。露光時のコマ番号nは、仮想撮像回路30の中に送られ撮影後その中に蓄積されている静止画データとセットで管理される。この管理は、フロントエンジン12側のプログラムで行われる。これにより、仮想撮像回路30内に蓄積されている静止画データがそれぞれ何コマ目に撮影されたものなのか常に知ることができる。静止画撮影プログラムは、露光時のコマ番号nを管理して撮影したコマ数が分かるようにする。
一方、静止画データ出力時のコマ番号mの初期値も「0」であるが、こちらの方は、仮想撮像回路30内に残っている静止画データのどれでも出力することもできるので自由度がある。
しかし、通常、撮影した順に静止画データを出力していくので、静止画撮影のプログラムは、出力を開始する前にmを「1」増やしてから静止画データの出力動作のAPI関数を呼び出す。従って、静止画データ出力時のコマ番号mも「1→2→3→・・・」というように単純に1ずつ増えていく。このコマ番号mも仮想撮像回路30の中に送られて内部に残っている静止画データのコマ番号nと比較され、それらのコマ番号が一致した静止画データが選択されて仮想撮像回路30より出力される。
フロントエンジン12側のプログラムは、バックエンジン13から受信した静止画データ出力コマンドに対するレスポンスの中に出力した静止画データのコマ番号(m=n)を入れて返信する。レスポンスのコマ番号は、先ず、バックエンジン13側の通信ドライバ104eで受信され、次いで、その上の仮想撮像ドライバ104dを介して静止画撮像プログラムに伝えられる。この静止画撮影プログラムがコマ番号をやり取りすることによって、コマ番号を正しく把握しつつ撮影された静止画データを処理していくことができる。
静止画撮影プログラムは、静止画データ出力時のコマ番号mを管理してどの静止画データが出力されたのか分かるようにする。静止画撮影プログラムは、露光時のコマ番号nと静止画データ出力時のコマ番号mの両方を管理することにより、何コマ目の静止画データが未だ仮想撮像回路30内に残っているのか常に知ることができる。
ところで、「撮影した順に仮想撮像回路30から静止画データを出力する」と先に述べたが、StillImageDataOut( )のようなAPIを用いると仮想撮像回路30内に残っているどの静止画データを出力することもできる。
つまり、StillImageDataOut( )のようなAPIは、撮影順とは異なる順序で仮想撮像回路30から静止画データを出力する動作もできる。電子カメラの製品の仕様次第ではあるが、この動作によって、電子カメラに新しい特徴を持たせることができる。
具体的には、RAWバッファ連写を行っている時に、突然再生ボタン(PLAYボタン)が押された場合には、再生モードに移る設定にする。この場合、撮影された静止画のどれから再生していくのが適切かと言えば、静止画の再生モードでは最後に撮影された(最新の)静止画からコマ番号を遡って再生していくのが好ましい。
すると、中断された連写の最後に撮影された静止画データを先に出力して再生することになるが、StillImageDataOut( )のようなAPI関数であれば、コマ番号mを指定して静止画データを出力することができるので目的の再生が実現される。
尚、StillImageDataOut( )の引数は、コマ番号m以外、必要なものがあれば適宜追加しても良い。(3−1)の露光動作及び(3−2)の静止画データの出力動作のAPIを用意することにより電子カメラ1は多様な動作を行うことができる。
ところで、従来の電子カメラの静止画撮影では、普通撮像回路の露光動作と、静止画データの出力動作が不可分(一体的)に行われるため1つのAPIで呼び出されることを先に述べた。
そこで、静止画撮影時の普通撮像回路の動作を見ていくことにする。この普通撮像回路の動作は、例えば、以下の2つの条件に分類される。
[1]露光動作が終わると自動的に静止画データの出力が始まるもの
[2]露光動作開始時と静止画データ出力開始時にそれぞれ別の操作が必要なもの
条件[1]のタイプは、2つの動作が文字通り不可分であり1つのAPIで呼び出すしかない。一方、条件[2]のタイプは、2つの動作が別々の操作によって起こるので不可分とは別の意味になる。
つまり、撮影(露光)した静止画データを出力するまでは、次の露光を始めないというシステム的な意味の不可分性である。上位層の静止画撮影プログラムからは、この2つが1つの動作に見えても良いので、1つのAPIで呼び出しているが、そのAPIによって呼び出される撮像ドライバ104c(図7参照)の中では、2つのシーケンシャルな動作に分かれている。つまり、条件[2]のタイプの2つの動作は、撮像ドライバ104cの中で分かれて実行されており、静止画撮像プログラムから見えないだけである。
しかし、2つの動作に分かれているのなら静止画撮影プログラムのAPIからそれらを呼び出しても良い。つまり、(3−1)の露光動作及び(3−2)の静止画データの出力動作のAPIが利用できることになるが、それは、普通撮像回路を仮想撮像回路30のように眺めることを意味する。そのような見方をする場合には、仮想撮像回路30内のRAW1バッファ14bの数が1つと考えなければならない。RAW1バッファ14bが1つであれば、そこに記憶された静止画データを出力しないと次の露光が始められない不可分性が再現される。
また、仮想撮像回路30のState1とState2との2つの状態が普通撮像回路にもそのまま適用される。つまり、普通撮像回路内にある1つの仮想的なRAW1バッファが空いている時には、State1がREADYでState2がBUSY、そこに撮影された静止画データが記憶されている時はState1がBUSYでState2がREADYになる。
これらの状態によって割り込みが発生するようにすれば、普通撮像回路の露光や静止画データ出力のタイミングが分かるので、この割り込みを利用して連写を続けていくことができる。このState1とState2の状態は、図7の撮像ドライバ104cから上位層の静止画撮影プログラムに伝えられる。普通撮像回路の場合、露光動作終了から静止画データの出力動作開始まで時間を置いてはならない(電荷信号が劣化するため)。
従って、静止画撮影プログラムは、上述した(3−1)の露光動作及び(3−2)の静止画データの出力動作のAPIを続けて呼び出すようにする。その場合には、静止画撮影プログラムは、2つコマ番号を一致(m=n)させなければならない。RAW1バッファ14bが1つしかないので、これは当然のことである。この点に注意すれば従来の電子カメラでも(3)のAPIを用いて静止画の撮影を行うことができる。続いて、条件[1]のタイプの普通撮像回路に移るが、こちらは2つのAPIに分けることはできず、1つのAPIでその機能(動作)を呼び出すしかない。
しかし、仮想撮像回路30と普通撮像回路の機能(動作)を呼び出すAPIを条件[1]のタイプのAPIに合わせることはできる。先ず、露光時のコマ番号nと静止画データ出力時のコマ番号mの他に、露光動作を表す「exp_op」と静止画データの出力動作を表す「dout_op」という合計4つの引数を導入する。「exp_op」や「dout_op」の「op」は「operation」を意味する。「exp_op」と「dout_op」は「1」と「0」の値を取るが、「1」は「動作状態」を表し「0」は「非動作状態」を表している。更に静止画撮影プログラムから呼ばれるAPI関数として以下のものを1つだけ用意する。
SendorDrive(exp_op,n,dout_op,m,・・・) ----- (4)
条件[1]のタイプの普通撮像回路の場合には、静止画撮影プログラムが上述した引数を以下のように設定してこのAPI関数を呼び出す。
条件[1]のタイプの普通撮像回路 :SendorDrive(1,n,1,n,・・・) ----- (5)
ここで、露光動作と静止画データの出力動作の2つが不可分に行われるので、(5)のAPI関数のように1回のAPIコールで良いことになる。このAPI関数によって図7に示す撮像ドライバ104cが呼び出され、その中で先ず露光動作が行われ、それが終了すると自動的に静止画データの出力動作が行われる。
続いて、条件[2]のタイプの普通撮像回路であるが、これも(5)のAPI関数をそのまま利用することができる。但し、この場合、撮像ドライバ104cの中で露光動作と静止画データの出力動作が分かれて実行される。撮像ドライバ104cは、普通撮像回路を操作して先ず露光動作を行い、それが終わると別の操作を行って静止画データの出力を行う。静止画撮影プログラムからは、これらが1つの動作に見えるので、普通撮像回路のタイプ応じて撮像ドライバ104cを用意する必要がある。
しかし、条件[2]のタイプの場合には、静止画撮影プログラムから(4)のAPI関数を2回呼び出すことによってこの2つの動作を行わせることもできる。この場合には、以下の(6−1)、(6−2)の順に呼び出す。
条件[2]のタイプの普通撮像回路 :
SendorDrive(1,n,0,0,・・・) ----- (6−1)
SendorDrive(0,0,1,n,・・・) ----- (6−2)
ここで、(6−1)のAPI関数は、1回目のAPIコールであるが引数の値より露光動作であることが分かる。(6−2)のAPI関数は、2回目のAPIコールであるが、その引数の値から静止画データの出力動作を呼び出したことが分かる。(6−1)のAPI関数は、静止画撮影プログラムからも2つの動作に見えるが、露光時のコマ番号と静止画データ出力時のコマ番号が共に「n」で一致しているので不可分な動作になっていることが分かる。つまり、2つの動作を表す引数を導入することにより1つのAPI関数で2つの動作を呼び出すことができる。従って、(6−1)及び(6−2)のAPI関数を見れば、仮想撮像回路30の2つの動作を呼び出すのにこのAPI関数をどのように使えば良いか容易に分かる。それは以下のようになる。
仮想撮像回路30の露光動作 : SendorDrive(1,n,0,0,・・・)
仮想撮像回路30の静止画データの出力動作 : SendorDrive(0,0,1,m,・・・)
仮想撮像回路30の2つの動作は、独立した動作なので露光時のコマ番号は「n」、静止画データ出力時のコマ番号は「m」のように別々の値が設定されている。この設定をすれば、静止画撮影の場合に使われるAPIを電子カメラ50と電子カメラ1、2で或る程度共通化することができる。
しかし、(4)のAPIは、無理に合わせたようなところがあるので使い難いことが想定される。そこで、使い難い場合には、引数や関数名を見直して使い易いAPIを用意することが好ましい。即ち、重要な点は、APIを一致させることではない。APIは、或る程度まとまった処理(マクロ的機能)を行う関数であるが、これらのAPIを幾つか組み合わせることで、大きなアプリケーションプログラムの機能が実現されている。つまり、適切なAPIを幾つも用意することが重要になってくる。
また、APIの標準化を進めることで、それらが他の機種でも利用できるようになるメリットも出てくる(ソフトウェアの部品化・共通化)。つまり、仮想撮像回路30という抽象化は、ソフトウェア的に見るとAPIを導入したことになる。
上述したようなAPI関数を呼び出すだけで仮想撮像回路30が目的の動作をするので、静止画撮影プログラムは、フロントエンジン12の複雑な動きを知らなくてもその機能が利用できるようになっている。
仮想撮像回路30という抽象化によって静止画撮影プログラムが容易に作成できることをこれまで説明してきたが、この抽象化を行った場合、ライブビューや動画撮影の動作がどのようになるか簡単に見ていくことにする。
ライブビューは、静止画撮影モードと動画撮影モードとの2つの画像撮影モードで動作している。画像撮影の場合には、撮影時に設定されている撮影モードでカメラが起動し、ライブビューを行うプログラムが先ず動作してライブビューが始まる。画像の撮影は、レリーズ釦18が全押しされた時に行われ、それまではライブビューの動作が続く。ライブビューの間は被写体の生画像(スルー画)をLCDパネル17に表示しており、ユーザはこれを見て撮影時の構図を決めたりシャッタチャンスを知ったりする。
また、ライブビューの間、適宜3A検波が行われており、そこで抽出されたAE評価値やAWB評価値を用いてスルー画の明るさや色が調整される。静止画撮影モードの場合には、AE撮影のための測光演算も行われる。レリーズ釦18が全押しされると撮影モードに応じてそれぞれの撮影動作に入るが、全押しより先に半押しが行われているのでその時に被写体への焦点調整(AF)が行われる。
この焦点調整(AF)は、AF評価値を利用して行われる。つまり、ライブビューのプログラムの中からは、スルー画データ出力、スルー画表示、輝度調整、WB調整(AWBアルゴリズムを含む)、焦点調整(AF)等を行う幾つものプログラムが呼び出されている。
これらのプログラムもAPIから呼び出される(割り込みを契機に呼び出されるものもある)。その中で仮想撮像回路30が関係するのは、スルー画データの出力である。ライブビューのプログラムは、スルー画データを出力するためのAPIを呼び出すが、これは、専用のAPIであっても良い。
このAPIから更に仮想撮像ドライバ104dと画像処理ドライバ104bが呼び出される(図9の左側)。以下では、フロントエンジン12の第1の画像データ送信路に対応する仮想撮像回路30のインターフェースのことを「第1のインターフェース」、第2の画像データ送信路に対応するインターフェースのことを「第2のインターフェース」と呼ぶことにする。仮想撮像ドライバ104dは、第1のインターフェースからスルー画用の画像データが出力されるように仮想撮像回路30を設定する。
一方、画像処理ドライバ104bは、スルー画用の画像データが図5の第1のポストプロセス回路13jで処理されるように画像処理回路を設定する。この場合、画像処理ドライバ104bは、画像処理回路の設定を先に行う。これにより、仮想撮像回路30の第1のインターフェース(第1の出力撮像インターフェース12cから第2の入力撮像インターフェース13aに向かう実線の矢印:図5参照)からスルー画用の画像データが出力されると、それが、第1のポストプロセス回路13jで処理されて作成されたスルー画のYCbCrデータが、図5のYCbCr1バッファ15fに記憶される。
このスルー画のYCbCrデータは、図2と同じ経路でLCDコントローラ13dに送られLCDパネル17に表示される。YCbCr1バッファ15fは、複数(3つの場合が多い)あって、先に出力されたスルー画のYCbCrデータをLCDパネル17に表示している間に次のYCbCrデータを別のYCbCr1バッファ15fに記憶しており、これらのYCbCr1バッファ15fを切り換えながらスルー画の表示を続ける。
上述したプログラムの中でスルー画表示に関わるプログラムは、適宜このYCbCr1バッファ15fの切り換えを行わなければならない。仮想撮像回路30から出力されたスルー画用の画像データは、図5の3A検波回路13hにも送られ3Aの評価値が抽出される。その中のAE評価値とAWB評価値を用いてスルー画の輝度調整とWB調整が適宜行われる。上述したプログラムは呼び出される度にこれらの処理を行う。
またこのAE評価値から静止画撮影用の測光演算も行われる。レリーズ釦18の半押しが検出された時には、焦点調整(AF)プログラムが呼び出され、AF評価値を基に被写体に焦点を合わせる。半押しだけで全押しが行われなかった場合、焦点調整(AF)の終了後もライブビューを続ける。
半押し後に全押しが行われた場合、画像の撮影に進むが、これ以降は、撮影モードによって動作が異なっている。先ず簡単な動画撮影モードの場合から説明する。動画撮影の場合にはライブビューを続けたまま、図8に示す仮想撮像回路30から記録用の動画データを出力する。
つまり、仮想撮像回路30の第1のインターフェースからスルー画用の画像データを出力したまま、第2のインターフェース(第2の出力撮像インターフェース12kから第2の入力撮像インターフェース13kに向かう点線の矢印:図5参照)から記録用の動画データを出力する。基となる1つの画像データを仮想撮像回路30の内部で分けて2つのインターフェースから出力するだけなので、この制御は容易である。全押し後は、ライブビューのプログラムを実行したまま、先ず動画撮影プログラムが呼び出され、その動画撮影プログラムの中で記録用の動画データを出力するためのAPIが呼び出される。
このAPIから更に仮想撮像ドライバ104dと画像処理ドライバ104bが呼び出される。仮想撮像ドライバは104d、仮想撮像回路30の第2のインターフェースから記録用の動画データを出力するように設定する。
一方、画像処理ドライバ104bは、そのデータが図5の第2のプリプロセス回路13mと第2のポストプロセス回路13pで処理されるように設定する。この場合も画像処理回路を先に設定する。仮想撮像回路30の第2のインターフェースがスルー画用の画像データが出力されると、それが第2のプリプロセス回路13mと第2のポストプロセス回路13pで処理されて作成された記録用のYCbCrデータが図5のYCbCr2バッファ15gに記憶される。
この記録用のYCbCrデータは、不図示の動画コーデック(H.264等)に送られて圧縮されるが、これ以降の処理は仮想撮像回路30に関係がないので説明を省略する。動画撮影の場合、仮想撮像回路30から2つの異なる画像データを同時に出力しながら処理が行われている。画像データの中で記録用の動画データの方が一般に解像度は高い。尚、動画撮影中は被写体に焦点を合わせ続ける必要があり、上述した焦点調整(AF)プログラムは、AF評価値を基に焦点調整(AF)の処理を続ける。
続いて、ライブビューと静止画撮影の動作が並列に行われる場合について説明する。これには、2つの場合が考えられる。通常の静止画撮影では、焦点調整(AF)が終了するとライブビューを停止して静止画撮影の動作に入るが、ライブビューを続けたまま静止画の撮影を行う動作が第1の場合である。
第1の場合、ライブビュー中の或るフレームを取りだして静止画として記録する動作になる。高速撮像回路11aは、フル解像度の画像データをライブビューのフレームレートで出力することもできるので、ライブビューを続けたまま解像度の高い静止画を撮影することができる。
この場合の仮想撮像回路30の動作は、動画撮影の場合に似ている。但し、撮影された静止画データが間欠的に仮想撮像回路30から出力される点は、動画撮影の場合と異なる。ライブビュー中にレリーズ釦18が全押しされると焦点調整(AF)終了直後のフレームが静止画として取り出されるが、その静止画データは、通常の静止画撮影の場合と同じように仮想撮像回路30の内部に蓄積される。この処理は、仮想撮像回路30の露光動作に対応するので既に説明したAPI関数を用いて行うことができる。撮影された静止画データは、続いて仮想撮像回路から出力することになるが、この静止画データの出力動作も既に説明したAPI関数を用いて行うことができる。ライブビューが続いている以外は、通常の静止画撮影の動作と同じであることが分かる。
続いて、第2の場合について説明するがこれは既に述べたことである。つまり、既に述べたRAWバッファ連写が行われてそれが中断または終了した時に、仮想撮像回路30の中に蓄積された静止画データの出力が終わらないうちにライブビューを再開する場合である。RAWバッファ連写が行われている間はライブビューが行われない。撮影された静止画データは、仮想撮像回路の第2のインターフェースから出力されているが、第1のインターフェースが空いているので、そこからライブビューの画像データを並行して出力することができる。
この場合のライブビューの動作は、上述した説明と同じである。この再開されたライブビューの間にレリーズ釦18が全押しされた場合、再び静止画撮影の動作に入る。これは通常の静止画撮影と同じ動作である。仮想撮像回路30のState1がREADYであれば静止画の撮影を行うことができるので、既に説明したAPIを呼び出して静止画の露光を行う。これ以降は、これまでに説明したことと同じなので省略する。つまり、ライブビューや動画撮影の場合も仮想撮像回路30のAPIを用いて処理することができる。
以上より、第4実施形態では、ソフトウェアの共通化と再利用とが容易となり、汎用性の高いカメラシステムを構築することができる。