### Table of Contents

# Color Correction Matrix

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

## Purpose

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:

## Support

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

**FPGA v.**.

`73`

## CCM

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\):

\[ \begin{bmatrix} R & G & B\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} R_0 \\ G_0 \\ B_0 \end{bmatrix} \]

Regular linear algebra rules apply, of course. The calculation itself (once expanded) looks like this:

\[ R = CCM_{00} * R_0 + CCM_{01} * G_0 + CCM_{02} * B_0 \\ G = CCM_{10} * R_0 + CCM_{11} * G_0 + CCM_{12} * B_0 \\ B = CCM_{20} * R_0 + CCM_{21} * G_0 + CCM_{22} * B_0 \]

## 3x3 -> 4x4

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.