RTOS/TDA3XEVM: Image deterioration in HDMI input / output

Hi Kenshow,

One reason could be the the CSC coefficients used in the DSS pipeline. I think the default CSC is for BT601, but if the input uses BT709 coefficients, there could be changes. Can you try changing it?

Rgds,
Brijesh

Hi Brijesh,

Thanks for your reply.
How can I change it specifically?

Regards,
Kenshow

Hi Kenshow,

You need to change gDssCprCoeff in PROCESSOR_SDK_VISION_03_03_00_00\ti_components\drivers\pdk_01_09_00_17\packages\ti\drv\vps\src\vpslib\hal\src\vpshal_dssDispcOvlyTda3xx.c and recompile.

Regards,
Rishabh

Hi Kenshow,

You could find the CSC coefficients for BT709 on the internet. But before that, i would suggest you figure out what is the coefficients used in the source? does the image provided to the display has brightness issue or it is introduced in the dss pipeline? Do you do any conversion in the capture pipeline?

Regards,
Brijesh

Hi Rishabh and Brijesh

How should I convert from decimal point value to integer value?

The structure in vpshal_dssDispcOvlyTda3xx.c is following:
/* Coefficients for BT601-5 RGB to YUV conversion */
static const VpsHal_DssDispcCprCoeff gDssCprCoeff = {
DSS_VP_CONFIG_CPR_CPRDIS, DSS_VP_CONFIG_COLORCONVENABLE_COLSPCDIS,
77, 150, 29,
-((Int16) 44), -((Int16) 87), 131,
131, -((Int16) 110), -((Int16) 21)};

And, the coefficients of BT601 and BT709 are:
BT601:
Y'= 0.299*R' + 0.587*G' + 0.114*B'
Cb=-0.169*R' - 0.331*G' + 0.500*B'
Cr= 0.500*R' - 0.419*G' - 0.081*B'
BT709:
Y'= 0.2215*R' + 0.7154*G' + 0.0721*B'
Cb=-0.1145*R' - 0.3855*G' + 0.5000*B'
Cr= 0.5016*R' - 0.4556*G' - 0.0459*B'

I'd like to establish HDMI loopback with EVM.

Regards,
Kenshow

Kenshow,

Multiply this fractional number with 256 and use integer portion of the result.

Rgds,
Brijesh

Hi Brijesh and Rishabh,

I changed the table of DSS, but It was not improved. it was same output images.
Is Usecase of HDMI (Framecopy) used RGB to YUV conversion in DSS?
Is it used the conversion anywhere else?

Regards,
Kenshow

Hi Kenshow,

Please check the HDMI settings. It might also be doing color conversion. 

Rgds,

Brijesh

Hi Brijesh,

As there are many settings in the SDK, please tell me specific files and functions.

Regards,
Kenshow

Hi Kenshow,

Since you are using only capture and display components, there is not many components involved in this pipeline.
We need to go in each component and figure out who is changing brightness.
So can we start with the capture? Can you dump capture output and check if it looks correct?
If it is correct, can you try changing DSS CSC settings? Please there are two CSCs, one is in Video pipelines and other in VENC. Please check if both of them are configured for BT709 or as required for the captured image.
Then check the HDMI, is HDMI configured for BT709 or BT601 CSC stream?

Rgds,
Brijesh

Hi Brijesh,

>So can we start with the capture? Can you dump capture output and check if it looks correct?
OK, I'll try them. In order to investigate easily, could you tell me how to make the simplicity setting like copying with 1080p RGB with Framecopy sample?

Regards,
Kenshow

Hi Kenshow,

I meant you could dump captured frame from VIP and view it offline to check if brightness is correct.

Rgds,
Brijesh

Hi Brijesh,

I checked frame buffer in DSP from VIP. Compared to HDMI input, the contrast slightly drops, but it is better than the output. Therefore, it seems that there is a problem on the output side.

Regards,
Kenshow

Hi Kenshow,

I think you had already tried changing CSC coefficients in pipe, correct?
If yes, just keep BT709 CSC coefficients. The next check is in HDMI, can you try resetting bit4 in register 0x0A in Sii9022A?

Rgds,
Brijesh

Hi Brijesh,

Thanks a lots for your advice.

I think that this is a problem of the TI driver for the TDA3xEVM.
Please tell me which program on the driver you want to change. I do not know how to change on the PDK even if advised of H/W setting.
And, changing gDssCprCoeff in the vpshal_dssDispcOvlyTda3xx.c file you pointed out previously is not used for HDMI output.

Best regards,
Kenshow

Hi Kenshow,

Let first rule out external HDMI transmitter, Can i request you to use Capture_dsswb to capture frames being sent out of TDA3x SoC and compare with the received frame.

You could probably refer usecase "vip_single_cam_view_dsswb" to use DSS WB.

Regards,

Sujith

Hi Sujith-san,

I found that DSS CSC setting is gVidCscCoeff structure in vpshal_dssDispcPipeTda3xx.c. Can you provide the coefficient for bt709 or any other to solve the issue?

HDMI display of usecase "vip_single_cam_view_dsswb also was the same phenomenon.
Please let me know how to check wb image in usecase "vip_single_cam_view_dsswb". Which buffer's pointer as wb image should I check?

Best Regards,
Kenhsow

Hi Kenhsow-san,

Can you please try with
{54, 183, 184,
-((Int16) 25), -((Int16) 85), 111,
157, -((Int16) 143), -((Int16) 14)};

You could simply put a brealpoint in WB driver and save the frame with saveraw command from scripting console.

Regards,
Sujith

Hi Sujith-san,

Your coefficient is RGB to YUV, isn't it?
I would like to know the value of the parameter for YUV to RGB in DSS. The structure is as follow:

/**
* struct Vps_DssCscCoeff
* \brief Params for CSC Coefficients for YUV to RGB color conversion.
*/
typedef struct
{
Int16 ry;
/**< RY Coefficient Encoded signed value */
Int16 rcr;
/**< RCr Coefficient Encoded signed value */
Int16 rcb;
/**< RCb Coefficient Encoded signed value */
Int16 gy;
/**< GY Coefficient Encoded signed value */
Int16 gcr;
/**< GCr Coefficient Encoded signed value */
Int16 gcb;
/**< GCb Coefficient Encoded signed value */
Int16 by;
/**< BY Coefficient Encoded signed value */
Int16 bcr;
/**< BCr Coefficient Encoded signed value */
Int16 bcb;
/**< BCb Coefficient Encoded signed value */
Int16 roff;
/**< R offset Encoded signed value */
Int16 goff;
/**< G offset Encoded signed value */
Int16 boff;
/**< B offset Encoded signed value */
} Vps_DssCscCoeff;

Best Regards,
Kenshow

Hi Sujith-san,

I have additional information on this issue.
I was able to check the image of DSS WB. It was already a degraded image. Therefore, I think that it is caused by CSC (YUV to RGB) of DISPC Video Pipeline.

Best Regards,
Kenshow

Hi Kenshow,

But what is the output format from write back pipeline? If it is YUV, then RGB will further be converted to YUV in write back pipeline.
could you please make sure that the output format in write back pipeline is RGB888 and then check the output?

Rgds,
Brijesh

Hi Brijesh,

Output format from write back pipeline is RGB888. It is already a degraded image.
Therefore, I am doubting CSC(YUV to RGB) of VID in DSS and need the paramater to improve the image.

Best Regards,
Kenshow

Hi Keshow,

Can you change the YUV to RGB matrix to

{256, 0, 327},
{256, -53, -97},
{256, 542, 0}

Regards,
Brijesh

Hi Brijesh,

I confirmed it in the following matrix order, but your matrix got worse than the original.

{Ry, Rcb, Rcr}
{Gy, Gcb, Gcr}
{By, Bcb, Bcr}

Best Regards,
Kenshow

Hi Brijesh,

I would like to confirm the offset values of RGB in this matrix.

Int16 roff;
/**< R offset Encoded signed value */
Int16 goff;
/**< G offset Encoded signed value */
Int16 boff;
/**< B offset Encoded signed value */

The default program is set -((Int16) 256), -((Int16) 2048), -((Int16) 2048). Are they correct in case of SDK usecase demos?

Best Regards,
Kenshow

Kenshow,


As explained in the figure 9.28 in the TDA3x TRM, when the output is in limited range, the offset must be set to 256, 2048 and 2048.
One question, have you tried full range output? In this case, offsets and coefficients both will be different. can you give it a try?
Also can you first check if the coefficients are set in full range or limited range? Both the coefficients are given at the top of the file. If it is set to full range already, can you try setting offset0 to 0?

Rgds,
Brijesh

Hi Brijesh,

How do I know that full range output or not? Is it FULLRENGE bit?
DISPC_VIP_ATTRIBUTES[11] FULLRENGE bit is 0x1 at the default.

What is offset0? Is it "Int16 roff;" in the structure "gVidCscCoeff"?

I tried following matrix in the structure "gVidCscCoeff". That's the best result I've ever tried.

256, 359, 0,
256, -((Int16) 183), -((Int16) 87),
256, 0, 454,
0, -((Int16) 2048), -((Int16) 2048)

However, I don't know this is correct or not.

Best Regard,
Kenshow

Hi Kenshow,

Yes, please make sure that the fullrange bit is set and roff set to 0.
Now can you try BT709 coefficients with this? keep the offsets same and just change the coefficients. Please make sure that the order is correct for coefficient. the structure might be using difference order.

Rgds,
Brijesh

Hi Brijesh,

>Now can you try BT709 coefficients with this? keep the offsets same and just change the coefficients

Does this mean that I will check with your matrix below?

{256, 327, 0},
{256, -97,- 53},
{256, 0, 542 },
{0, -2048, -2048)}

Best Regards,
Kenshow

I think it is correct.

Rgds,
Brijesh

Hi Brijesh,

I checked your recommendation matrix with offset(0,-2024-2048). It was better but not the best image. G is increased and R&B are decreased a little bit.

It was the best that only the offset was changed from default SDK.
I am thinking that RTM Figure 9-31 means offset(0,-2024-2048).

Therefore, with these Demo's usecase, It is just that the offset was wrong, isn't it?

Best Regards,
Kenshow

Hi Kenshow,

Yes, that's correct, offset seems to be wrong.
Could you please tell how much is the increase in G and decrease in R&B? Is it small small enough to ignore?

Regards,
Brijesh

Hi Brijesh,

I show RGB color values as follows:

0) EVM input RGB color
Color A: 112,84,72
Color B: 194,121,53

1) Modified offset from original SDK (Best, small enough to ignore)
Color A: 112, 82, 71
Color B: 196, 119, 51

2) Your recommendation(Better, but can not ignore)
Color A: 110, 88, 67
Color B: 190, 132, 35

Best Regards,
Kenshow