(58)【調査した分野】(Int.Cl.,DB名)
前記ブロックの前記輝度ヒストグラムが複数のビンに分割され、前記ブロックの各画素がその輝度値に基づいて1つのビンに分配され、かつ前記暗領域が、最初のビンから低ビンしきい値を有する1つのビンまでのビンを含み、前記飽和領域が、高ビンしきい値を有する1つのビンから最後のビンまでのビンを含む請求項3に記載の自動ホワイトバランス補償方法。
ブロックは、該ブロックの輝度ヒストグラムの暗領域の画素数がブロック輝度しきい値よりも大きい場合に、第2のタイプとしてラベリングされる請求項1から4のいずれか1項に記載の自動ホワイトバランス補償方法。
ブロックは、該ブロックの輝度平均値が低輝度平均しきい値から高輝度平均しきい値までの間にある場合に、前記第1のタイプとしてラベリングされる請求項1から5のいずれか1項に記載の自動ホワイトバランス補償方法。
前記処理ユニットが、前記フレーム0の前記第1のタイプのブロックの画素を入力と見なして統計計算に採用し、計算結果に基づいて前記フレーム0のRチャネルおよびBチャネル画素のゲインを調整する請求項12に記載の自動ホワイトバランス補償装置。
前記ブロックの前記輝度ヒストグラムが複数のビンに分割され、前記ブロックの各画素がその輝度値に基づいて1つのビンに分配され、かつ前記暗領域が最初のビンから低ビンしきい値を有する1つのビンまでのビンを含み、前記飽和領域が、高ビンしきい値を有する1つのビンから最後のビンまでのビンを含む請求項14に記載の自動ホワイトバランス補償装置。
ブロックは、該ブロックの輝度ヒストグラムの暗領域の画素数がブロック輝度しきい値よりも大きい場合に、第2のタイプとしてラベリングされる請求項12から15のいずれか1項に記載の自動ホワイトバランス補償装置。
ブロックは、該ブロックの輝度平均値が低輝度平均しきい値から高輝度平均しきい値までの間にある場合に、前記第1のタイプとしてラベリングされる請求項12から16のいずれか1項に記載の自動ホワイトバランス補償装置。
前記処理ユニットが、フレーム2を取得し、第3のタイプとしてラベリングされたブロックである前記フレーム0の第3のタイプのブロックの位置と同じ位置における前記フレーム2のブロックを入力として前記フレーム2に第3のAWB補償を施し、前記補償されたフレーム2を前記補償されたフレーム0と前記補償されたフレーム1との合成結果と合成する請求項12から17のいずれか1項に記載の自動ホワイトバランス補償装置。
【発明を実施するための形態】
【0008】
以下の記載は、本発明を実施するのに最良であると考えられる形態である。この記載は本発明の基本的な原理を説明する目的でなされたものであって、限定の意味で解されてはならない。本発明の範囲は、添付の特許請求の範囲を参照することにより決定されるべきである。
【0009】
本発明の実施形態について、図面を参照しつつ説明するが、本発明は、以下の実施形態に限定されるものではなく、その範囲は、特許請求の範囲の記載に基づいて定められる。さらに、“含む(comprises)”、“含んでいる(comprising)”、“含む(includes)”および/または“含んでいる(including)”といった用語は、本明細書で用いられるときに、記述した特徴(features)、整数、工程、動作、要素、および/またはコンポーネントの存在を明示するが、1つまたはそれ以上のその他の特徴、整数、工程、動作、要素、コンポーネント、および/またはこれらの群の存在または追加を排除するものではないということが理解されるであろう。
【0010】
図1は、本発明の一実施形態に係るコンピュータ装置の構成を示す概略図である。本実施形態に係るコンピュータ装置は、デスクトップ型コンピュータ、ノートブック型コンピュータ、タブレットPC(パーソナルコンピュータ)、携帯電話、デジタルカメラ、デジタルレコーダー、またはその他のデバイスによって実現可能であり、これらは少なくとも処理ユニット110を含む。処理ユニット110は、多種の方式、例えばマイクロコードまたはソフトウェア命令によりプログラムされて本明細書に記載の機能を実行する専用ハードウェアまたは汎用ハードウェア(例えば単一の処理機、並列計算が可能な複数の処理機もしくはグラフィック処理ユニット、またはその他)として実現され得る。処理ユニット110は、カメラモジュールコントローラ170を介し、カメラモジュール190を制御して複数のLDR(ローダイナミックレンジ)フレームをキャプチャし、フレームバッファー130にLDRフレームを保存することができる。カメラモジュール190は、赤、緑および青色の形式で画像を検出するためのイメージセンサ、例えばCMOS(相補型金属酸化物半導体)またはCCD(電荷結合素子)センサと、イメージセンサから感知データ(sensed data)を収集する読み出し電子回路と、を含み得る。処理ユニット110は、フレームバッファー130から少なくとも3つのLDRフレームを得ることができる。本実施形態において、3つのLDRフレームは12ビットのフレームである。1つのLDRフレームは、最適化された露光設定の下でAE(自動露光)アルゴリズムによりキャプチャされたもので、以下これをフレーム0と称する。フレーム0をキャプチャするための露光設定には、シャッタースピード、アナログゲインおよびデジタルゲインが含まれ、これらはフレームバッファー130または揮発性メモリ140に保存されるという点に留意すべきである。揮発性メモリ140、例えばDRAM(ダイナミックランダムアクセスメモリ)は、ランタイム変数、データテーブルなどのような、実行において必要なデータを保存するために用いられる。別のLDRフレームは低露光フレームであり、以下これをフレーム1と称する。また別のLDRフレームは高露光フレームであり、以下これをフレーム2と称する。処理ユニット110は、HDRM(ハイダイナミックレンジマージング)アルゴリズムを用いてHDR(ハイダイナミックレンジ)フレームを生成することによりフレーム0から2を合成すると共に、生成されたHDRフレームをフレームバッファー150に保存する。本実施形態では、出力HDRフレームは18ビットのフレームである。
【0011】
図2は、本発明の一実施形態に係る、処理ユニットによって実行されるAWB(自動ホワイトバランス)補償方法を説明するフローチャートである。プロセスはフレーム0の取得から始まる(ステップS210)。その後、フレーム0が複数のブロックに分割され(ステップS220)、フレーム0の各ブロックのブロック統計情報が得られ(ステップS230)、フレーム0の各ブロックがそのブロック統計情報に基づいて1のタイプとしてラベリングされる(ステップS240)。処理ユニット110は、第1のタイプとしてラベリングされたブロックであるフレーム0の第1のタイプのブロックを入力としてフレーム0に第1のAWB補償を施す(ステップS250)。本実施形態において、ブロックのタイプには、ノーマル露光、ノーマル露光よりも露光量が小さい低露光、および、ノーマル露光よりも露光量が大きい高露光が含まれる。フレーム0はLDRのノーマル露光フレームのであるため、ノーマル露光タイプとしてラベリングされたブロックを入力として、フレーム0に第1のAWB補償が施される。AWB補償は通常Gチャネルを維持し、計算結果に応じてRチャネルおよびBチャネルの画素のゲインを調整する。本実施形態において、処理ユニット110は、第1のタイプ(例えばノーマル露光)としてラベリングされたフレーム0の全てのブロックの統計を計算し、かつ計算結果に基づいてフレーム0の全ての画素のRチャネルおよびBチャネルのゲインを調整する。AWB補償の詳細な計算は、どのアルゴリズムが用いられるかによって決まる。よく用いられるAWBアルゴリズムとしては、灰色仮説(gray world assumption)、完全反射仮説(perfect reflector assumption)、色温度推定(color temperature estimation)などがある。灰色仮説を例にとると、処理ユニット110は、第1のタイプ(例えばノーマル露光)としてラベリングされたブロックのR、G、およびBチャネルの画素値を累積して、フレーム0のRおよびBチャネルを調整するためのゲインを得る。これにより、調整後にR、BおよびGチャネルの画素値の累積が等しくなるようになる。
【0012】
さらに、フレーム1が取得される(ステップS260)。本実施形態において、フレーム1はLDR低露光フレームである。第2のタイプとしてラベリングされたブロックであるフレーム0の第2のタイプのブロックの位置と同じ位置におけるフレーム1のブロックを入力として、フレーム1に第2のAWB補償が施される(ステップS270)。本実施形態において、ブロックは、例えば低露光タイプとしてラベリングされる。補償されたフレーム0が補償されたフレーム1と合成される(ステップS280)。本発明が提供するAWB補償をHDR画像生成に適用することにより、合成されたHDRフレームの異なる部分にそれぞれ異なるAWB補償、例えば前述した第1および第2のAWB補償が行われる。つまり、各部分が、その輝度値に基づいて特定の程度のAWBにより補償される。輝度値のそれぞれ異なる複数の部分は通常それぞれ異なる色温度を有するため、異なる色温度の部分にそれぞれ異なるAWB補償を適用することによって、色の偏りがより正確に補償され、実際により近い色が再現され得るようになる。
【0013】
図3は、本発明の一実施形態に係る、処理ユニット110によって実行されるHDR画像の合成におけるAWB補償の方法を説明するフローチャートである。プロセスはフレームバッファー130からフレーム0を取得することから始まる(ステップS311)。次に、処理ユニット110がフレーム0の各ブロックの統計情報を得る(ステップS313)。詳細には、フレーム0がm×nのブロックに分割され得る。各ブロックは例えば32×32画素を含む。そして各画素の輝度値が計算される。各画素の輝度値は次の式(1)を用いて計算することができる。
【0014】
[数1]
V=0.3×R+0.6×G+0.1×B (1)
式(1)では、Rは赤色値を表し、Gは緑色値を表し、Bは青色値を表し、Vは輝度値を表す。処理ユニット110は各ブロックの平均輝度AveLumおよび輝度ヒストグラムを計算する。
図5は、本発明の一実施形態に係るブロックの輝度ヒストグラムの概略図である。本実施形態では、例として0から4095までの範囲の12ビットの輝度値を挙げているが、本発明はこれに限定されることはない。ヒストグラムは、例えば16個のビンに分割され、ビン8の最小輝度値V8は2047.5(=4095/2)に設定される。ビン7の最小輝度値V7およびビン9のV9は次の式(2)および(3)を用いて計算することができる。
【0015】
[数2]
V7=4095×r (2)
[数3]
V9=4095×(1−r) (3)
式(2)および(3)において、rは0から0.5の間の任意の値であり得る。rが0.25に設定されていると仮定すると、V7は1023.75、V9は3071.25である。0からV7までの輝度値は、7個のビン(Bin0〜Bin6)に均等に分割され、V9から4095までの輝度値は7個のビン(Bin9〜Bin15)に均等に分割される。8個目のビン(Bin7)の輝度値はV7からV8までであり、9個目のビン(Bin8)の輝度値はV8からV9までである。各ブロックについて、処理ユニット110は、その輝度値に基づいて各画素を対応するビンに分配すると共に、各ビンに画素がいくつ存在するかをカウントする。ヒストグラムを生成するための例示的な疑似コードは次の通りである。
【0016】
LowThr = 4096 >> 2; // LowThr = maximum_12bits * 0.25
HighThr = 4096 - LowThr;
valuePerBin = (LowThr / (blockBinNum/ 2 - 1)); // blockBinNum = 16
//for each block
for(byIdx = 0; byIdx < block_cnt_y; byIdx ++) {
for(bxIdx = 0; bxIdx < block_cnt_x; bxIdx ++) {
lum = image->y[pxlIdx];
sum += lum;
if (lum < LowThr) { // (Bin 0~6)
bin = ((unsigned short)(lum * (((blockBinNum >> 1) - 1) << 2)) >> 12); }
else if (lum < (maximum_12bits + 1) / 2) { // (Bin 7)
Bin = ( blockEntryNum / 2 - 1); }
else if (lum < HighThr) { // (Bin 8)
Bin = ( blockEntryNum / 2); }
else { // (Bin 9~15)
tmpLum = lum - HighThr;
tmpBin = ((unsigned short)(tmpLum * (((blockBinNum >> 1) - 1) << 2)) >> 12);
if (tmpBin >= ((blockBinNum >> 1) -1)){
bin = blockBinNum - 1;}
else {
bin = (blockBinNum >> 1) + 1 + tmpBin;} }
bestExpBlockInfor[curLumSumIdx].block_hist[Bin]++; }
bestExpBlockInfor[curLumSumIdx].block_averVal = sum / block_size; }
ここで、bestExpBlockInforは構造体アレイであり、各構造体は、輝度平均値block_averValと、Bin0からBin15の画素数block_hist[Bin]とを含む1つのブロックの統計情報を保存する。
【0017】
続いて、処理ユニット110は、ブロックの輝度平均値およびヒストグラムを分析することにより得られた統計情報に基づいて、各ブロックが低露光タイプ、ノーマル露光タイプ、または高露光タイプであると識別する(ステップS315)。詳細には、1つのブロックのヒストグラム内の低ビンしきい値および高ビンしきい値が計算される。低ビンしきい値および高ビンしきい値は次の式(4)および(5)を用いて計算することができる。
【0018】
[数4]
threBinLow≒(BinNum/2−1)/r×0.18 (4)
[数5]
threBinHigh≒BinNum−(BinNum/2−1)/r×0.18 (5)
式(4)および(5)において、threBinLowは低ビンしきい値を表し、threBinHighは高ビンしきい値を表し、BinNumはブロックのヒストグラム内のビンの総数を表し、例えばBinNum=16であり、かつrは0から5までの任意の値であり得る。rが0.25に設定されていると仮定すると、低ビンしきい値は5であり、高ビンしきい値は11である。各ブロックについて、Bin0からBin5までにある画素は暗領域に属し、一方、Bin11からBin15までにある画素は飽和領域に属する。各ブロックについて、暗領域の画素数を表すpixNumLowはBin0からBin5まで累積され、飽和領域の画素数を表すpixNumLowはBin11からBin15まで累積される。処理ユニット110は、下記の判断によって、ブロックのタイプが低露光、ノーマル露光、または高露光のいずれであるかを識別する。ブロックは、暗領域の画素数pixNumLowがブロック輝度しきい値blocklumthresよりも大きくなく、かつ飽和領域の画素数pixNumHighがブロック輝度しきい値blocklumthresよりも大きくない場合に、第1のタイプ(ノーマル露光)としてラベリングされる。ブロックは、暗領域の画素数pixNumLowがブロック輝度しきい値blocklumthresよりも大きい場合、第2のタイプ(低露光)としてラベリングされる。ブロックは、飽和領域の画素数pixNumHighがブロック輝度しきい値blocklumthresよりも大きい場合に、第3のタイプ(高露光)としてラベリングされる。本実施形態において、ブロック輝度しきい値はブロック内の画素の総数に関連し、例えばblocklumthres=blocksize*ratioである。別の実施形態では、処理ユニット110は、低輝度平均しきい値AveLumLow(例えば256)および高輝度平均しきい値(例えば3840)をさらに提供する。ブロックは、そのブロックの輝度平均値AveLumが低輝度平均しきい値AveLumLow以下である場合に、第2のタイプ(低露光)としてラベリングされる。ブロックは、そのブロックの輝度平均値AveLumが高輝度平均しきい値AveLumHigh以上である場合に、第3のタイプ(高露光)としてラベリングされる。ブロックは、第2のタイプまたは第3のタイプとしてラベリングされなかった場合に、第1のタイプ(ノーマル露光)としてラベリングされる。各ブロックのタイプを識別するための例示的な疑似コードは次のとおりである。
【0019】
ThrgridL = 5; // lowlight bin threshold, thrBlockBinL = ((binNum >> 1) - 1) * 0.18 / ratio;
for (x = 0; x < block _cnt_x; x++) {
for (y = 0; y < block_cnt_y; y++) {
curblockIdx = y * block _cnt_x + x;//block index
while (i <= ThrblockL) {
j = binNum - i;
blockcntltmp += bestExpBlockInfor[curgIdx]. block_hist[i] ; // accumulate from low to high
blockcnthtmp += bestExpBlockInfor[curgIdx].block_hist[j];// accumulate from high to low
i++; }
curBlockAve = m_pBestExpBlockInfor[curgIdx].block_averVal;
b_AveLumMin = (maximum_12bits + 1) >> 4; //average low threshold
b_AveLumMax = (maximum_12bits + 1) - g_KAveLumMin; //average high threshold
ThrblockCnt = blockSize * 0.18;//histogram threshold
//block label is defined by average and histogram of the block
isUnder = ((Gridcntltmp > thrBlockCnt) && (g_KAveLumMin >= curBlockAve));
isOver = ((Gridcnthtmp > thrBlockCnt) && (g_KAveLumMax <= curBlockAve));
if (isUnder && isOver) { // is over and is under
blockLabel[curblockIdx] = NORMAL; }// NORMAL = 1
else if (isUnder) { // is under
blockLabel[curblockIdx] = LOW; } // LOW = 0
else if (isOver) { //is over
blockLabel[curblockIdx] = HIGH; } // HIGH = 2
else { // is not over and not under
blockLabel[curblockIdx] = NORMAL;}}}
ここで、blockLabelはアレイであり、このアレイにおいて、各セルは例えば低露光“LOW”、ノーマル露光“NORMAL”および高露光“HIGH”のようなブロックの1のタイプを保存している。なお、暗領域または飽和領域の画素数およびブロックの輝度平均値AveLumの両方を考慮に入れるような設計にすることもできる。例えば、ブロックは、暗領域の画素数pixNumLowがブロック輝度しきい値blocklumthresよりも大きく、かつ輝度平均値AveLumが低輝度平均しきい値AveLumLow以下である場合に、第2のタイプ(低露光)としてラベリングされる。ブロックは、飽和領域の画素数pixNumHighがブロック輝度しきい値blocklumthresよりも大きく、かつ輝度平均値AveLumが高輝度平均しきい値AveLumHigh以上である場合に、第3のタイプ(高露光)としてラベリングされる。ブロックは、低露光タイプまたは高露光タイプとしてラベリングされなかった場合、第1のタイプ(ノーマル露光)としてラベリングされる。
【0020】
続いて、処理ユニット110は、そのブロックのタイプに基づいて、各ブロックの重み(ブロックの重みともいう)を設定し(ステップS317)、フレーム0の各画素の重み(画素の重みともいう)を計算する(ステップS319)。ステップS317において、詳細には、ブロックが低露光タイプとしてラベリングされている場合、ブロックの重みは0に設定され、ブロックがノーマル露光タイプとしてラベリングされている場合、ブロックの重みは1に設定され、ブロックが高露光タイプとしてラベリングされている場合、ブロックの重みは2に設定される。ステップS319において、詳細には、ブロックの境界およびコーナー部分に位置する画素を除き、処理ユニット110は、4個の隣接するブロックの重みおよび画素から4個の隣接するブロックの中心までの距離に基づいて、フレーム0の各画素の重みを計算する。
図7は、本発明の一実施形態に係る4個の隣接するブロックを示す概略図である。隣接するブロックW
UL、W
UR、W
LLおよびW
LRの4個の中心点により矩形が形成され、この矩形は4個の縁辺E1からE4を含む。各画素の重みW
pは次の式(6)を用いて計算することができる。
【0021】
[数6]
W
p=D1×D2×W
UL+D1×D4×W
UR+D3×D2×W
LL+D3×D4×W
LR (6)
ここで、W
ULは上左側のブロックに関するブロックの重みを表し、W
URは上右側のブロックに関するブロックの重みを表し、W
LLは下左側のブロックに関するブロックの重みを表し、W
LRは下右側のブロックに関するブロックの重みを表し、D1は画素pから下縁辺E1までの距離を表し、D2は画素pから右縁辺E2までの距離を表し、D3は画素pから上縁辺E3までの距離を表し、D4は画素pから左縁辺E4までの距離を表す。ステップS319で計算されたフレーム0の各画素の重みは、フレーム0とフレーム1との合成プロセスにおいて用いられることとなる。詳細は後述する。
【0022】
再度
図3を参照する。フレーム0の各ブロックのタイプがラベリングされた(ステップS315)後、第1のAWB補償がフレーム0の各ブロックに施される(ステップS331)。
図4は、本発明の一実施形態に係るベイヤーパターン(Bayer pattern)の概略図である。奇数行に交互に配されたR(赤色)およびGr(緑色)画素と、偶数行に交互に配されたGb(緑色)およびB(青色)画素とを有するベイヤーパターン410が形成される。各ブロックのR画素をまとめてRチャネルと称し、各ブロックのGr画素およびGb画素をまとめてGチャネルと称し、各ブロックのB画素をまとめてBチャネルと称する。ステップS331において、詳細に述べると、第1のAWB補償では、第1のタイプ(例えばノーマル露光)としてラベリングされたフレーム0のブロックが入力として見なされ、フレーム0の全てのブロックが調整される。第1のAWB補償ではGチャネルは維持され、計算結果に基づいてフレーム0のRチャネルおよびBチャネルの画素のゲインが調整される。本実施形態において、処理ユニット110は、第1のタイプ(例えばノーマル露光)としてラベリングされたフレーム0のすべてブロックの画素を計算し、計算結果に基づいてフレーム0のすべての画素のRチャネルおよびBチャネルのゲインを調整する。
【0023】
フレーム0に対するAWB補償が完了したら、処理ユニット110はフレーム0の統計情報を得る(ステップS351およびS333)。本実施形態において、ステップS311で処理ユニット110はRGBの色空間をHSV(Hue,Saturation,Value)のそれに変換し得る。詳細には、ステップS351およびS333において、処理ユニット110はフレーム0の輝度ヒストグラムを計算する。
図6は、本発明の一実施形態に係るフレーム0の輝度ヒストグラムの概略図である。暗領域の輝度値(Bin0)は0からC1までであり、一方、飽和領域の輝度値(Bin3)はC3からC4である。本実施形態では、0から4095までの12ビットの輝度値を例とし、C1=511、C3=3583およびC4=4095としているが、本発明はこれに限定されることはない。フレーム0全体について、処理ユニット110は、各領域にいくつの画素が存在するかをカウントし、かつ暗領域に含まれる第1の画素数(暗画素数とも称する)の、飽和領域に含まれる第2の画素数(飽和画素数とも称する)に対する、shiftRatioと示される比値を計算する。この比値は次の式(7)を用いて計算することができる。
【0024】
[数7]
shiftRatio=pixelNumBin0/pixelNumBin3
(7)
式(7)において、pixelNumBin0は暗領域の第1の画素数を表し、pixelNumBin3は飽和領域の第2の画素数を表す。次に、処理ユニット110は、第1の画素数の第2の画素数に対する比値に基づいて、拡張倍数(expansion multiplier)exp_timesを計算する。暗画素数の飽和画素数に対する比値が8未満である場合、拡張倍数exp_timesを計算するのに式(8)を用いることができる。暗画素数の飽和画素数に対する比値が8以上である場合、拡張倍数exp_timesを計算するのに式(9)を用いることができる。
【0025】
[数8]
exp_times=a×shiftRatio×shiftRatio+b×
shiftRatio+c (8)
[数9]
exp_times=d×shiftRatio×shiftRatio+e×
shiftRatio+f (9)
式(8)および(9)において、a、b、c、d、eおよびfは浮動小数点数である。続いて、処理ユニット110は、フレーム0の統計情報から導き出された比値shiftRatioおよびフレーム0の露光設定に基づいて、フレーム1を処理するのに必要な第1の露光パラメータを計算し(ステップS353)、かつフレーム2を処理するのに必要な第2の露光パラメータを計算する(ステップS335)。露光設定には、シャッタースピード(shtと示される)、アナログゲイン(agと示される)およびデジタルゲイン(dgと示される)が含まれる。露光設定は、例えば、sht、agおよびdgの乗積である。第1の露光パラメータPara1および第2の露光パラメータPara2は次の式(10)および(11)を用いて計算することができる。
【0026】
[数10]
Para1=sht×ag×dg×exp_times/expValue (10)
[数11]
Para2=sht×ag×dg×exp_times (11)
式(10)および(11)において、expValueは、第2の露光パラメータの第1の露光パラメータに対する比値である固定拡張値(fixed expansion value)を表す。12ビットのLDRフレームを拡張および合成して18ビットのHDRフレームを生成する本実施形態において、expValueは、64である。
【0027】
第2の露光パラメータPara2を計算した(ステップS335)後、処理ユニット110はフレーム0をHDR空間に拡張する(ステップS337)。ステップS337において、フレーム0の第1の拡張因子を計算するのに用いられる例示的な疑似コードは次のとおりである。
【0028】
curveMapValNormal = curveTable_AVR[0] x sht x ag x dg + curveTable_AVR[1];
curveMapValHigh = curveTable_AVR[0] x Para2 + curveTable_AVR[1];
slope_Normal = curveMapValHigh / curveMapValNormal;
ここで、slope_Normalは、フレーム0の第1の拡張因子を表す。curveTable_AVR[0]は、カメラモジュール190のイメージセンサに関連する校正された傾き(calibrated slope)である。curveTable_AVR[1]は、カメラモジュール190のイメージセンサに関連する校正されたy切片である。sht×ag×dgは、フレーム0の露光設定を表す(ただし、shtはフレーム0のシャッタースピードを表し、agはフレーム0のアナログゲインを表し、dgはフレーム0のデジタルゲインを表す)。Para2は、式(11)を用いて算出された第2の露光パラメータを表す。処理ユニット110は、フレーム0における各画素のHSV値に第1の拡張因子slope_Normalを乗じて、フレーム0をHDR空間に拡張する。
【0029】
第1の露光パラメータPara1を計算した(ステップS353)後、処理ユニット110は、算出された第1の露光パラメータPara1によって表される露光設定に基づき、低露光フレーム(フレーム1と称する)を撮影して、それをフレームバッファー130に保存するようカメラモジュールコントローラ170に指示し、かつ第2のAWB補償を用い、フレーム0の第2のタイプのブロックの位置と同じ位置におけるフレーム1のブロックを入力と見なし、フレーム1の各ブロックを調整する(ステップS356)。ここで、フレーム0の第2のタイプのブロックは第2のタイプ(例えば低露光)としてラベリングされたブロックである。本実施形態において、フレーム0の第2のタイプ(例えば低露光)のブロックの位置と同じ位置におけるフレーム1のブロックの画素は、統計計算の入力として見なされ、計算結果に基づいて、フレーム1の全ての画素のRチャネルおよびBチャネルゲインが調整される。第2のAWB補償の詳細な計算は、どのアルゴリズムが用いられるかによって決まる。さらに、第2の露光パラメータPara2を計算した(ステップS335)後、処理ユニット110は、算出された第2の露光パラメータPara2により表される露光設定に基づき高露光フレーム(フレーム2と称する)を撮影して、それをフレームバッファー130に保存するようカメラモジュールコントローラ170に指示し、かつ第3のAWB補償を用い、フレーム0の第3のタイプのブロックの位置と同じ位置におけるフレーム2のブロックを入力とみなし、フレーム2の各ブロックを調整する(ステップS336)。ここで、フレーム0の第3のタイプのブロックは、第3のタイプ(例えば高露光)としてラベリングされたブロックである。本実施形態では、フレーム0の第3のタイプのブロックの位置と同じ位置におけるフレーム2のブロックの画素は統計計算の入力と見なされ、かつ計算結果に基づいて、フレーム2の全ての画素のRチャネルおよびBチャネルゲインが調整される。第3のAWB補償の詳細な計算は、どのアルゴリズムが用いられるかによって決まる。本実施形態において、第1、第2および第3のAWD補償は、それぞれフレーム0、1および2の全てのブロックに適用されるという点に留意されたい。なお、AWBの統計計算に採用されるブロック(つまり、第1、第2および第3のタイプとしてラベリングされたブロック)のみが、フレーム4を出力するための次の合成に採用される場合、AWB補償は、これらのブロックだけに適用されてもよい。対応するAWB補償が全てのブロックに施されるので、境界を滑らかにすることができる。
【0030】
本実施形態では、第1の露光パラメータPara1の計算(ステップS353)および第2の露光パラメータPara2の計算(ステップS335)の後、処理ユニット110はフレーム1をHDR空間に拡張する(ステップS357)。ステップS357において、フレーム1の第2の拡張因子を計算するのに用いられる例示的な疑似コードは次のとおりである。
【0031】
curveMapValLow = curveTable_AVR[0] x Para1 + curveTable_AVR[1];
curveMapValHigh = curveTable_AVR[0] x Para2 + curveTable_AVR[1];
slope_Low = curveMapValHigh / curveMapValLow;
ここで、slope_Lowはフレーム1の第2の拡張因子を表し、curveTable_AVR[0]はカメラモジュール190のイメージセンサに関連する校正された傾きであり、curveTable_AVR[1]はカメラモジュール190のイメージセンサに関連する校正されたy切片であり、Para1は式(10)によりステップS353で算出された第1の露光パラメータを表し、Para2は式(11)によりステップS335で算出された第2の露光パラメータを表す。処理ユニット110は、フレーム1における各画素のHSV値に第2の拡張因子slope_Lowを乗じて、フレーム1をHDR空間に拡張する。
【0032】
ステップS359において、拡張されたフレーム0、拡張されたフレーム1およびステップS311で得られたフレーム2が補償される。詳細には、処理ユニット110は、第1の露光補償法を用いて、拡張されたフレーム0の飽和画素および暗画素を補償する。詳細には、第1の露光補償法は、拡張されたフレーム0の暗画素(例えば輝度値が0から128 x slope_Normalのもの)を検出し、拡張されたフレーム0の検出された暗画素の輝度値を、同じ位置におけるフレーム2の輝度画素値に置き換える。第1の露光補償法はさらに、拡張されたフレーム0の飽和画素(例えば輝度値が3967 x slope_Normalから4095までのもの)を検出し、拡張されたフレーム0の検出された飽和画素の輝度値を、同じ位置におけるフレーム1の輝度画素値に置き換える。さらに、処理ユニット110は、第2の露光補償法を用い、拡張されたフレーム1の暗画素を補償する。詳細には、第2の露光補償法は、拡張されたフレーム1の暗画素(例えば輝度値が0から128 x slope_Lowのもの)を検出し、拡張されたフレーム1の検出された暗画素の輝度値を、同じ位置におけるフレーム0の輝度画素値に置き換える。さらに、処理ユニット110は、第3の露光補償法を用い、フレーム2の飽和画素を補償する。詳細には、第3の露光補償法は、フレーム2の飽和画素(例えば輝度値が3967から4095までのもの)を検出し、フレーム2の検出された飽和画素の輝度値を、同じ位置におけるフレーム0の輝度画素値に置き換える。
【0033】
フレーム0および1をHDR空間に拡張するための上記ステップS337およびS357、ならびにフレーム0、1および2の画素を補償するためのステップS359は、AWB補償に必ずしも必要ではないという点に留意されたい。処理ユニット110は、ステップS319で計算されたフレーム0に含まれる各画素に対応する画素の重みに基づいて、補償されたフレーム0を補償されたフレーム1と合成させることによってフレーム3を生成し、フレームバッファー150にフレーム3を保存する(ステップS371)。詳細には、ステップS371において、フレーム0に含まれる画素に対応する画素の重みがしきい値(例えば64)以下である場合、処理ユニット110は、フレーム0のこの画素のHSV値を、同じ位置における補償されたフレーム1のHSV値と合成させて、同じ位置におけるフレーム3のHSV値を生成する。フレーム0に含まれる画素に対応する画素の重みがしきい値よりも大きい場合、処理ユニット110は直接、フレーム0のこの画素のHSV値を、同じ位置におけるフレーム3のHSV値と見なす。補償されたフレーム0と補償されたフレーム1との画像合成のための例示的な疑似コードは次のとおりである。
【0034】
if ((1 == frameNum) && (pixelweight[index1] <= 64)) { // when input frame is frame 1, reference frame is frame 0
weightRef = pixelweight[index1];
weightIn = 1.0 - weightRef;
outPixH = inputImg->HDRdata[index + 0] * weightIn + refImg->HDRdata[index + 0] * weightRef; // H channel fusion
dst->HDRdata[index] = outPixH;
outPixS = inputImg->HDRdata[index + 1] * weightIn + refImg->HDRdata[index + 1] * weightRef; // S channel fusion
dst ->HDRdata[index + 1] = outPixS;
outPixV = inputImg->HDRdata[index + 2] * weightIn + refImg->HDRdata[index + 2] * weightRef; // V channel fusion
dst ->HDRdata[index + 2] = outPixV; }
else if ((1 == frameNum) && (pixelweight[index1] > 64)) {
outPixH = refImg->HDRdata[index + 0]; // H channel from reference frame(frame 0)
dst ->HDRdata[index] = outPixH;
outPixS = refImg->HDRdata[index + 1]; // S channel from reference frame(frame 0)
dst ->HDRdata[index + 1] = outPixS;
outPixV = refImg->HDRdata[index + 2]; // V channel from reference frame(frame 0)
dst ->HDRdata[index + 2] = outPixV; }
ここで、pixelweight[index1]は(index1)個目の画素の重みを表し、inputImgは補償されたフレーム1を表し、refImgは補償されたフレーム0を表し、dstはフレーム3を表す。
【0035】
処理ユニット110は、ステップS319で算出されたフレーム0に含まれる各画素に対応する画素の重みに基づいて、フレーム3を補償されたフレーム2と合成させることによりフレーム4を生成し、フレームバッファー150にフレーム4を保存する(ステップS373)。フレーム4は最終的なHDRフレームである。ステップS373において、詳細には、フレーム0に含まれる画素に対応する画素の重みがしきい値よりも大きい場合、処理ユニット110は、フレーム3のこの画素のHSV値を、同じ位置における補償されたフレーム2のHSV値と合成して、同じ位置におけるフレーム4のHSV値を生成する。フレーム0に含まれる画素に対応する画素の重みがしきい値よりも大きくない場合、処理ユニット110は直接、フレーム3のこの画素のHSV値を、同じ位置におけるフレーム4のHSV値と見なす。フレーム3と補償されたフレーム2との画像合成のための例示的な疑似コードは次の通りである。
【0036】
if ((2 == frameNum) && (pixelweight[index1] > 1.0)) { //input frame is frame 2,ref frame is fusion result of frame 0, 1
weightIn = pixelweight[index1] - 1;
weightRef = 1.0 - weightIn;
outPixH = inputImg->HDRdata[index + 0] * weightIn + refImg->HDRdata[index + 0] * weightRef;
dst ->HDRdata[index] = outPixH;
outPixS = inputImg->HDRdata[index + 1] * weightIn + refImg->HDRdata[index + 1] * weightRef;
dst ->HDRdata[index + 1] = outPixS;
outPixV = inputImg->HDRdata[index + 2] * weightIn + refImg->HDRdata[index + 2] * weightRef;
dst ->HDRdata[index + 2] = outPixV; }
else {
outPixH = refImg->HDRdata[index + 0];
dst ->HDRdata[index] = outPixH;
outPixS = refImg->HDRdata[index + 1];
dst ->HDRdata[index + 1] = outPixS;
outPixV = refImg->HDRdata[index + 2];
dst ->HDRdata[index + 2] = outPixV; }
ここで、pixelweight[index1]は、(index1)個目の画素の重みを表す。inputImgは、補償されたフレーム2を表す。refImgは、フレーム3を表す。dstは、フレーム4を表す。
【0037】
図1には特定の構成要素を備えるように実施形態が示されているが、本発明の精神を逸脱することなく、より優れたパフォーマンスを達成するために追加の構成要素が含まれていてもよいという点に留意すべきである。また、
図2および
図3に示された処理の流れでは、特定の順序で実行されると理解される複数の工程を含んでいるが、これらのプロセスは、対応する各図に示す工程よりも多いまたは少ない工程を含んでいてもよく、それらは連続的に(serially)、または例えば並列プロセッサまたはマルチスレッディング環境を利用し並行して(in parallel)、実行可能なものである。
【0038】
本発明を例により、好ましい実施形態の観点から説明したが、本発明はこれら開示された実施形態に限定されることはないと理解されるべきである。むしろ、当業者がなし得る種々の変更および類似の構成を含む。従って、添付の特許請求の範囲に記載の発明の範囲は、そのような全ての変更や類似の構成を包含するように最も広義に解釈されるべきである。
【0039】
関連出願の相互参照
本出願は、2015年3月17日に出願された中華人民共和国特許出願第201510117455.6号の利益を主張し、その全体が本明細書において援用される。