Differences

This shows you the differences between two versions of the page.

--- isp:ccm [2021/01/27 23:40] – [Pixel layout] Igor Yefmov
+++ isp:ccm [2023/09/12 23:07] (current) – [Support] Igor Yefmov
@@ Line 6: / Line 6: @@
 {{ :isp:color_correction_sample.jpg?direct&200 |}}
-===== Support =====
-SUB2r camera starts supporting CCM (a.k.a. CMX) with **FX3 v. ''58''** and **FPGA v. ''73''**.
-===== 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 [[https://math.stackexchange.com/questions/3957955/ccm-3x3-into-4x4-image-processing|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 [[https://docs.google.com/spreadsheets/d/1X1n5hVDLHd-Z6ZLEcwPZijU2WQZ40QAtt9Z-ExZlRG0/edit?usp=sharing | 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.
 ===== 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\). Note that the ordering of chroma components is \(BGR\):
+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} B & G & R\end{bmatrix}
+ \begin{bmatrix} R & G & B\end{bmatrix}
  =
  \begin{bmatrix}
@@ Line 31: / Line 20: @@
  \cdot
  \begin{bmatrix}
- B_0 \\
+ R_0 \\
  G_0 \\
- R_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 [[https://math.stackexchange.com/questions/3957955/ccm-3x3-into-4x4-image-processing|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 [[https://docs.google.com/spreadsheets/d/1X1n5hVDLHd-Z6ZLEcwPZijU2WQZ40QAtt9Z-ExZlRG0/edit?usp=sharing | 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.