OMNIVISION Technologies, Inc.（オムニビジョン・テクノロジーズ） はじめに 第3回：RAWかYUVか？画質と処理負荷の境界線を見極める ■はじめにこんにちは。加賀デバイスのOMNIVISION Teamです。前回のコラムでは、センサから画像データを送る際の「帯域の壁」について、フレームレートやMIPI/DVPといった通信インターフェースの観点から解説しました。 今回は、その通信パイプの中を通る「データフォーマット」に焦点を当てます。 スペック表の『Output Format』にある「RAW」や「YUV」といった違いは、単なる拡張子の違いではありません。システム全体の処理負荷をどこが担うかを決める、アーキテクチャ設計における重要な分岐点なのです。 ■ センサの物理的構造とCFA（カラーフィルターアレイ）の多様性 スペック表の『Output Format』を理解するために、先に『CFA (Chroma)』の項目について説明します。イメージセンサの各画素(ピクセル)は、基本的には受光した光の強弱(輝度)しか判別できません。 この性質をそのまま活かしたのが「モノクロセンサ」です。色情報は得られませんが、全ての光をそのまま受け取るため感度が高く、解像感も非常にシャープになります。近赤外線（NIR）を用いたセンシングや、特定の波長のみを捉えるマシンビジョン用途で強力な威力を発揮します。 一方、私たちが普段目にするカラー画像を撮影するためには、画素の上に特定の色の光だけを通す「CFA（カラーフィルターアレイ）」を配置する必要があります。OMNIVISION社のスペック表の『CFA (Chroma)』という項目には、このフィルターの種類が記載されています。 最も標準的なのが「ベイヤー配列（RGB Bayer）」です。人間の目が緑色に敏感である特性に合わせ、R（赤）、G（緑）、B（青）のフィルターを1：2：1の割合で市松模様に配置したものです。さらに近年では、セキュリティカメラや車載用途向けに「RGB-IR配列」も普及しています。これはベイヤー配列の一部をIR（近赤外線）用の画素に置き換えたもので、昼間はカラー画像（RGB）を、夜間や暗所では赤外線画像（IR）を1つのセンサで取得できるため、機械的なIRカットフィルターの切り替え機構が不要になるというメリットがあります。 図１：各CFAのイメージ ■ 「RAWデータ」から「RGB画像」への変換（デモザイク処理とデータ量の増加） 前回の第2回コラムの終盤で、「RAWやYUVなど、出力フォーマットによって1画素あたりのデータの重さ（ビット長）が変わる」と予告していました。まさにOMNIVISION社の製品リストにある『Output Format』の項目がそれにあたります。 そもそも「RAWデータ」とは何かと言うと、先ほど説明したCFAの種類に関わらず、単純に「各画素がどれくらいの光を受光したか」を表す生データのことです。受け取った光の量が多ければ多いほど、データとしての数値も大きくなります。同項目の「8-bit RAW」や「12-bit RAW」といった表記は、このRAWデータの階調の豊かさ（ビット長）を示しています。8bit（256段階）よりも数字が大きいほど豊かな明暗を表現できますが、1画素あたりのデータ量が増えるため、システム全体の帯域を圧迫するというトレードオフが発生します。 では、このRAWデータをどのように画像として活用するのでしょうか。センサから出力されたベイヤー配列のRAWデータは、そのままではカラー画像としてモニターに表示できません。なぜなら、各画素が持っているデータはあくまで「R・G・Bのうち、いずれか1色の光をどれくらい受光できたか」という情報だけだからです。フルカラーの画像にするためには、周囲の画素の情報から足りない色を演算によって推測し、補完する必要があります。この処理を「デモザイク処理」と呼びます。 図2：デモザイク処理(RAW⇒RGB)のイメージ ここでシステム設計上、非常に警戒すべき事態が起こります。RAWデータの段階では1画素あたり1色の情報だったものが、デモザイク処理を経てRGB画像になると、1画素あたりR・G・Bの3色すべての情報を持つことになります。 つまり、8bit-RAWのデータがRGB画像になることで、1画素あたりのデータ量が24bitへと3倍に増加してしまうのです。前回(第2回)のコラムで解説した通り、データ量の増加は通信インターフェースの選定や後段デバイスの処理性能など、システム全体の構成に直結します。また、データ量の問題だけでなく、このデモザイク処理自体の演算負荷も決して軽いものではありません。特に、先ほど紹介したRGB-IR等の特殊なフィルタの場合は、通常のベイヤー配列に比べて色を推測・分離するアルゴリズムが複雑になるため、演算処理が重くなります。そのため、詳細は後述しますが、「このデモザイク処理をどこで行うか」という判断が、システム構成を決定づける非常に重要な要因となります。 なお、先ほど触れたモノクロセンサについては、カラー化(デモザイク処理)を行う必要がなく、取得した輝度データをそのまま画像として活用できるため、出力データはこのRAWフォーマットとして扱われることが一般的です。 ■ 人間の視覚特性を活かしたデータ圧縮技術「YUV 4:2:2」 データ量が大きく増加してしまうRGB画像の課題を解決するために使われるのが、『Output Format』のもう一つの選択肢である「YUV」というフォーマットです。 RGBが「赤（R）・緑（G）・青（B）」という光の三原色で色を表現するのに対し、YUVは国際規格で定められた特定の計算式を用いて、「Y（輝度＝明るさ）」と「U/V（色差＝色合い）」という要素に変換(色空間変換)して扱う方式です。UとVは同じ色差という言葉で表されますが、簡単にいうと、それぞれ青っぽさと赤っぽさを表しています。 ただ、Y・U・Vという3つのデータに変換しただけでは、結局RGBの時と同じく3つのパラメータなので全体のデータ量は変わりません。データ圧縮の鍵は、このYUV変換に加える「間引き」の処理にあります。「人間の目は明るさの変化には非常に敏感だが、色の変化には鈍感である」という視覚特性を利用して、輝度（Y）のデータはすべて残しつつ、色差（U/V）のデータを間引いて圧縮する技術を「クロマサブサンプリング」と呼びます。代表的な「YUV 4:2:2」では、水平方向の色情報を半分に間引くことで、人間の目には画質の劣化をほとんど感じさせずに、RGB画像と比較してデータ量を大幅に削減できます。 OMNIVISION社の製品リストにおいても『YUV422 8/10/12-bit』などの出力フォーマットが記載されています。例えば8bitベースのYUV4:2:2フォーマットを使用した場合、色情報が間引かれることで1画素あたりの平均データ量は16bitに抑えられます。これにより、24bitに増加したRGB画像と比較して効果的にデータ量を圧縮し、システムの伝送負荷を大きく下げることができるのです。ただし、それでもRAWデータと比較した場合データ量は増えてしまう点についてはご注意ください。 図3：YUV422変換のイメージ ■ 現場のシステム設計：画像処理（ISP）の分担をどうするか？ ここまでの処理(デモザイクやYUV変換など)を行う回路を「ISP（Image Signal Processor）」と呼びます。このISPを「どこに配置するか」が、センサ出力フォーマット選定の最大のポイントです。 ・YUV出力センサ（ISP内蔵型） センサ内部にISPを搭載し、YUVに変換されたデータを出力します。 –メリット： 後段のデバイス(SoCなど)の処理負荷が低く、システム構築が容易です。 –デメリット： センサ内で複雑な演算を行うためRAW出力センサと比べて一般的に消費電力が高く、発熱しやすくなります。熱は画像ノイズの原因となるため、暗所性能を極めたい場合には注意が必要です。また、一般的にRAWセンサと比較してセンサ自体のコストが高くなる傾向にあるほか、前述したように出力時点でのデータ量がRAWよりも大きくなるため、伝送インターフェースにかかるコストやハードルも上昇します。…
