Understanding SPH and SLV preview engine parameters

Hi,

Your understanding is correct. You should be able to get the colors right by changing the SPH and SLV as you mentioned.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Hi Anshuman,

thank you for your reply.

I am not able to get right colors changing SPH and SLV. I have right colors only performing a color inversion in RGB blending, inverting R and B color, but I don't know why!. Then I have analyzed raw data from my sensor, verifying that effectively RGB patterns is B G B G B G.... for the first line and G R G R G R...... for the second line and so on. Pixel colors position are right. The colors obtained are dependent not only from SPH and SLV, but also from CFA, white balance, black adjustment, RGG to RGB blending and RGB to YCbCr conversion.CFA coefficient are those of example application. Then I would verify each single stage of color processing work. To do it, I must undersand how is working in detail white balance, to isolate single color pixel and verify it to other stage. I have studied pag. 76 of SPRU964A (my company has subscribed Ti's NDA), but it is not sufficient. In general terms white balance is a calibration of a gain for every color to obtain white color when I get image from a white object. For example for red color, R' = Gr * R, where R is color from cfa interpolation, R' is final red color (after wb processing..) and Gr is white balance gain for red. About SPRU964A I can not understand exact calculation performed by Da Vinci white balance stage. I need to know how each parameter acts in white balance stage. Another question is if white balance position parameters are refered to first pixel defined by SPH and SLV parameters, or from another pixel.

Can you explain me these arguments?

Regards,

Fabrizio Beltrandi

Hi,

 There are many parameters which can change the color.

1. SLH, SLV: This selects the starting pixel processed in ISP.

2. COLPTN: This defines the color of the starting pixel (ISP knows color of each pixel using this info)

3. YCPOS: The order of Y Cb Cr in memory (output of ISP)

4. CFA: The parameters are color order sensitive (If you have any sample param, then it works only on a particular starting color setting. Please match COLPTN with your example and change SLH and SLV to make COLPTN is proper)

5. RGB2RGB, WB, RGB2YCbCr: If default values are used, then the output color is not changed.

Regards,

Sang-Yong 

Hi,

Thank You for your response.

1) Is COLPTN active only for black level compensation or for CFA processing (and others)  too?

2) Is field CP0LPC0 of COLPTN register ( line 0 and pixel counter 0) regarding to starting pixel processed in ISP (specified by SPH and SLV) or  is it regarding starting pixel acquired from my color sensor ( for example If SPH = 2 and SLV = 3, first pixel processed in ISP is not first pixel acquired) ?

I think that is the most important point, because I have some doubt about setting of these registers: if I have understand, I must set SPH and SLV  to match first RED pixel. Then I must set COLPTN according to SPH and SLV values, but I don't know if fields of COLPTN register are starting from first color sensor pixel or SPH and SLV pixel.

Regards,

Fabrizio

1) In fact, you are right. It only works for CCDC function (sorry for making confusion).

2) Based on doc, we support only Red start case in Preview engine and I assume all other settings (we provide) are based on this. If so, the only way we can control is changing SPH and SLV. If you don't use proper Preview engine param, then it is different story.

If you can capture Raw data, then you can confirm your CCDC setting can provide Red first or not.

regards,

Sang-Yong

Hi,

when I capture raw data preview engine is bypassed, and I see pixel according to sensor architecture. I see B G B G (first line)... and G R G R (second line).... and so on. In this mode CCDC don't provide Red first, but Blu first I think that is normal, because SPH = 0 and SLV0 = 0 in CCDC settings, then I am acquiring every pixel of my cmos sensor. If I am right, when I capture raw data bypassing preview, I can not verify setting of SPH and SLV in Preview engine register, then it is not important if first pixel acquired (defined from CCDC registers) is red or not. It is important that starting pixel processed in preview is RED, and this is defined by SPH and SLV in preview register, knowing what is first pixel color acquired (in my situatation is blue). Can you confirm this? I would know exact expression of white balance computation, because I think this is the only manner to isolate one color at time, and verify my Ipipe path, if you have not another suggestion.

Regards,

Fabrizio

Hi,

 Do you have problem if you lose 1 row and column?

 The document I saw said the starting color needs to be Red.

I believe it doesn't need to be Red, but it would be difficult (also you might not have enough info.) for you to find all the proper register values to support Blue start.

Regards,

Sang-Yong

Hi,

It is not a problem lose a few rows and columns. In my case, because EPH must be greather or equal 2, I must program EPH = 3 and SLV = 1 in HORX_INFO of Preview, loosing the first three columns and the first line. But this is not a problem. Programming in this manner the register of preview I have an effect that is like an inversion of color, and I not understand. I have verified cfa coefficient too, and they seem to be right.  Because it is not possible view data out from cfa interpolation ( if there is a manner I will be very happy....), to debug problem I need to know in deep how white balance work, to isolate single color and control the IPIPE path of data. I have not other idea.

Regards,

Fabrizio

About WBGain and WBSel, Preview engine itself is color blind (it means it doesn't know whether the first pixel is Red or other colors).

So, you can define Coef0~3 in your way.

For example, you can define Coef0 is Red gain, Coef1 is Green Gain on Red line, Coef2 is Green on Blue line, Coef3 is Blue gain.

After that you put the gain on the color by controlling WBSel. The ISP is flexible than ISP in DM3xx and we can support more than Bayer pattern input. For example, this can support the sensor has R G B R G B in one line.

But as you use Bayer format, your setting should be two by two pattern repeated.

Also, we expect the first pixel is Red

Line0, Pixel0 is Red, so in my definition above, I put Coef0 (as I want Red gain is applied to Red pixel/position).

Line0, Pixel1 is Gr (Green on Red line)

Line0, Pixel 2 is Red (since the data is G R G R G R ....)

....

Line1, Pixel0 is Gb (Green on Blue line)

....

Therefore your setting for WBSel would be

Field: 3 2 3 2 1 0 1 0 3 2 3 2 1 0 1 0

Hex: EE44EE44

------

By the way, CFA setting needs to be changed if you don't use Red start and this would be big. So I recommend Red start.

regards,

Sang-Yong

Hi,

If I am right, Line 0, Pixel 0 and Coeff 0 are rferred to first pixel processed by ISP, defined by EPH and SLV in preview register's HORZ_INFO and VERTINFO, regardless setting of CCDC register's HORZ_INFO and VERT_INFO. Am I correct?

regards,

Fabrizio

I should mention this earlier (I was confused also as this is different from DM3xx ISP).

HORZ_INFO and VERT_INFO are used in Preview engine, and they do another triming on trimed data from CCDC.

As Preview engine uses filters you'd better gives some numbers to avoid potential boundary artifact. You may find this info from "Image Cropping  by Preview Functions" table in TRM. By applying the number as multiple of 2, you can avoid color shift.

Coeff0 is not necessarily applied to Line0 and Pixel0. The position is determined by WBSEL.