Color Correction Matrix

A.k.a. “CCM” or “CMX”

Why do the color correction at all? A picture is worth a thousand words so here's a visual to demonstrate the original (left) and color-corrected (right) values. Click to enlarge:

SUB2r camera starts supporting CCM (a.k.a. CMX) with FX3 v. 58 and FPGA v. 73.

Color Correction Matrix is often used as an “add-on” matrix during YUV→RGB conversion. In our case, since the de-bayering and RGB→YUV conversions happen literally on opposite sides of the imaging pipeline, we only use the portion of the corrections designed to compensate for the sensor's cross-talk, converting post-debayer values \(R_0, G_0, B_0\) into \(R, G, B\). Note that the ordering of chroma components is \(BGR\):

\[ \begin{bmatrix} B & G & R\end{bmatrix} = \begin{bmatrix} CCM_{00} & CCM_{01} & CCM_{02} \\ CCM_{10} & CCM_{11} & CCM_{12} \\ CCM_{20} & CCM_{21} & CCM_{22} \\ \end{bmatrix} \cdot \begin{bmatrix} B_0 \\ G_0 \\ R_0 \end{bmatrix} \]

Industry papers on CCM use a \(3\times3\) matrix yet we tried to do a full \(4\times4\) so there was a need to find a way to convert from one to another (and also from an RGGB into BGGR ordering). Here's an article on Math StackExchange on that subject.

And if you'd like to play with the values in an Excel-like environment - here's a link to Google Sheets for your enjoyment.

After some research and a bit of math crunching it turned out that such an approach is invalid. Primarily because it ignores a very important step - de-bayering, which affects the result in a critical manner.

Therefore we go with the “standard” approach of using a \(3\times3\) matrix in \(RGB\) space.