4.11. デベイヤー処理¶
RAWベイヤーフレームは、ピクセルごとに1つのカラーチャネルしか保持していません。これを通常の3チャネルRGB画像に変換するには、各ピクセルで欠けている2つのチャネルを、近くにある適切なカラーのピクセルから補間して埋める必要があります。この補間処理が デベイヤー処理(デモザイク処理とも呼ばれます)です。いくつかのアルゴリズム系統が主流となっています。
4.11.1. スーパーピクセル¶
最も負荷の低い手法は、2x2のベイヤータイル(赤セル1つ、青セル1つ、緑セル2つ)をまとめて1つの出力ピクセルに集約します:
赤チャネルは赤セルの値となります;
青チャネルは青セルの値となります;
緑チャネルは2つの緑セルの平均値となります。
各2x2入力タイルが1つの出力ピクセルになるため、完成した画像はセンサーの幅と高さがそれぞれ半分になり、ピクセル数は4分の1になります。スーパーピクセルは高速で補間アーティファクトが発生しませんが、解像度の犠牲が大きいため最後の手段であり、ほとんど使われません。
4.11.2. バイリニア¶
バイリニア 補間は、値をコピーしたり集約したりするのではなく、適切なカラーの最も近いピクセルを平均します。中心ピクセルがどのカラーを記録しているかによって平均の取り方が異なります。なぜなら、4つのケースでは欠けているチャネルが3x3近傍に異なる形で分布するからです。
赤緑行の緑ピクセル。 欠けている赤の値は左右の2つの赤の隣接ピクセルを平均し、欠けている青は上下の2つの青の隣接ピクセルを平均します。
欠けている赤は水平方向の赤の隣接ピクセルから得られ、欠けている青は垂直方向の青の隣接ピクセルから得られます。¶
緑青行の緑ピクセル。 赤と青を入れ替えた同じ形状です。欠けている赤の値は上下の2つの赤の隣接ピクセルを平均し、欠けている青は左右の2つの青の隣接ピクセルを平均します。
欠けている赤は垂直方向の赤の隣接ピクセルから得られ、欠けている青は水平方向の青の隣接ピクセルから得られます。¶
赤ピクセル。 欠けている緑の値は上下左右の4つの緑の隣接ピクセルを平均します。欠けている青は4つの対角の青の隣接ピクセルを平均します。
欠けている緑は4つの上下左右の緑の隣接ピクセルから得られ、欠けている青は4つの対角の青の隣接ピクセルから得られます。¶
青ピクセル。 赤のケースの鏡像です。欠けている緑は4つの上下左右の緑の隣接ピクセルを平均し、欠けている赤は4つの対角の赤の隣接ピクセルを平均します。
欠けている緑は4つの上下左右の緑の隣接ピクセルから得られ、欠けている赤は4つの対角の赤の隣接ピクセルから得られます。¶
バイリニアはセンサーの解像度を完全に維持し、ほとんどの用途で十分に滑らかですが、それでもエッジでアーティファクトが現れます。2つのカラー間の鋭い遷移は特定の向きでピクセルグリッドを横切り、エッジをまたいで平均を取るとわずかに緩やかになります。カラーエッジと輝度エッジが正確に揃わない箇所では、出力にかすかな色付きのフリンジが現れます。
4.11.3. バイリニアを超えて¶
バイリニアより優れたデベイヤーアルゴリズムが数多く存在します。バイリニアの同色隣接ピクセルの小さな十字よりも大きな近傍を使い、より慎重に選んだ係数でサンプルに重み付けするものもあります。また、局所的なエッジの方向を検出し、その方向に沿って補間を偏らせることで、ピクセルグリッドを横切るエッジが緩やかにならず鋭いまま保たれるようにするものもあります。いずれの手法も、バイリニアが残す色付きフリンジとエッジの緩やかさを軽減しますが、その代償としてピクセルごとの演算量が増え、シリコン(あるいはMCU側の計算量)も増えます。
特定のOpenMV Camで利用できるデベイヤー品質はプラットフォーム固有です。それは、そのカメラのセンサーとMCUが何を提供するかに依存します。
4.11.4. デベイヤー処理が実行される場所¶
イメージシグナルプロセッサ(ISP)は、センサーチップ自体またはMCU側にあり、ほとんどの場合、各フレームがイメージングパイプラインを離れる前にデベイヤー処理を行います。ユーザーコードは、RAWモザイクに一切触れることなく、完成した3チャネルRGB画像を受け取ります。
ISPは、RAWベイヤーフレームをそのまま変更せずに通過させるように指示することもできます。RAWベイヤーはデベイヤー済み画像よりもメモリを消費しません(ピクセルあたり3バイトではなく1バイト)。これは、フレーム保存がボトルネックになっている場合、オフライン処理のためにキャプチャする場合、またはプロジェクトでソフトウェアによるカスタムデベイヤーアルゴリズムを適用したい場合に役立ちます。