TDA4VM: Questions about strange data range of H3A ouput

Lu Zhang

Part Number: TDA4VM

Hi TI experts,

Now I am doing some work about parsing H3A data to optimize and develop our AE AWB and multi-gamma algorithms. But I am confused about how to parse the H3A data from VISS node according to codes marked in red in "vx_aewb_target.c", as the following figures show:

After I calculate the value of "p_h3a[k].red/ green/ blue" which also mean H3A data after normalized, the value range is [0, 68], in stead of [0, 255]. Because I think the accumulative sum of all pixels value in each window is stored as uint16_t, the maximum of data is 65535. In our using case, if the pix_in_pax is equal to 957 , the H3A range is equal to [0, 68] according to codes from function "h3a_normalize()" in "vx_aewb_target.c".

So could TI experts correct me if I am wrong?

Besides, I do not know what is the meaning of the following codes in function "parse_h3a_out" in "vx_aewb_target.c".

if ((cur_addr - h3a_buf) % 32 == 16)

{

cur_addr += 16;

}

Thanks a lot.

over 1 year ago

0 Gang Hua over 1 year ago

TI__Guru 58930 points

Hi Lu,

Lu Zhang said:
In our using case, if the pix_in_pax is equal to 957 , the H3A range is equal to [0, 68]

You may refer to the TDA4 TRM for H3A details.

Yes, the normalization will reduce the range if you have many pixels in a single window.

For your own AE, you don't have to do the normalization and you may send to number of pixels to your AE as an input parameters.

Lu Zhang said:
Besides, I do not know what is the meaning of the following codes in function "parse_h3a_out" in "vx_aewb_target.c".

That is because of the H3A output data packaging.
You may refer to TDA4 TRM for the details.

0 Lu Zhang over 1 year ago in reply to Gang Hua

Prodigy 60 points

Hi Gang,

Thanks for your reply.

According to what you said, the data range of average luminance of each window depends on the number of pixels in each window. So is that true that the data range is changing and it is exact to calculate AE results using accumulative sum of each window instead of average luminance of each window? And H3A data is 10 bits (max is 1023) and accumulative sum is 16 bits (max is 65535). So if we want to keep each h3a data is 10 bits, the max number of pixels in each window must be less than 64. But actually, it is hard to keep the number less than 64.

I printed log to get the parameter "pix_in_pax", which is equal to 957 in our using case and the number of windows is 32 x 16. But to be honest, I do not know how to calculate to get "pix_in_pax".

Thanks a lot.

0 Gang Hua over 1 year ago in reply to Lu Zhang

TI__Guru 58930 points

Hi Lu,

Please refer to TRM H3A section for details.
Input to H3A is 10-bit pixels and H3A outputs are 16-bit sums after programmable down-shift.
You may also decide how many pixels to add together in each window with programmable skipping.

0 Lu Zhang over 1 year ago in reply to Gang Hua

Prodigy 60 points

Hi Gang,

Gang Hua said:
For your own AE, you don't have to do the normalization and you may send to number of pixels to your AE as an input parameters.

I read the codes and TRM according to what you said, but I think if we use the accumulative sum as luminance statistics for AE, the maximum is still 65535 stored in uint16_t and h3a data is 10 bits. So I think it also has the risk of overflow for the accumulative sum of all pixels with no skipping in each window. Could you please correct me if my thoughts are wrong?

Besides, I find that the bit depth of luminance statistics in AE is 8 bit, and before AE the bit depth of h3a data is always 10 bits. I do not know which codes of SDK can implement this process.

Thanks a lot.

0 Gang Hua over 1 year ago in reply to Lu Zhang

TI__Guru 58930 points

Lu Zhang said:
Could you please correct me if my thoughts are wrong?

Yes, there is a chance of overflow if there are too many bright pixels.

Lu Zhang said:
I find that the bit depth of luminance statistics in AE is 8 bit, and before AE the bit depth of h3a data is always 10 bits.

I am not sure which "luminance statistics in AE" you are referring to.
Anyway, 8-bit is the scale chosen at TI for AE code interface.
For your own AE, you may choose your scale freely.

Lu Zhang said:
I do not know which codes of SDK can implement this process.

I am not sure if understand this question correctly.
H3A outputs sums after a down-shift in H/W (you can find details in TRM).
S/W may scale or normalize H3A output before AE for simplicity.

You are not subject to those limitations while designing your own AE.

0 Lu Zhang over 1 year ago in reply to Gang Hua

Prodigy 60 points

Hi Gang,

Thanks for your reply.

Gang Hua said:
I am not sure which "luminance statistics in AE" you are referring to.
Anyway, 8-bit is the scale chosen at TI for AE code interface.
For your own AE, you may choose your scale freely.

I got what you mean. But I am still confused that it is true that h3a data stores 10-bit rggb data in 16-bit accumulative sum, but in TI 's AE algorithm, target brightness, luminance range, R/G/B gains set in "TI_AE_do" and luminance data in YUV format n 8 bits from 0 to 255 are calculated to change AE results. So could you please tell me how to understand the change of bits from 10 bits to 8 bits?

Thanks a lot.

0 Gang Hua over 1 year ago in reply to Lu Zhang

TI__Guru 58930 points

Lu Zhang said:
but in TI 's AE algorithm, target brightness, luminance range, R/G/B gains set in "TI_AE_do" and luminance data in YUV format n 8 bits from 0 to 255 are calculated to change AE results.

I suppose your question of 8-bit is about the target brightness in 8-bit scale.

It was an arbitrary decision for AE interface many years ago.
Somehow, it was decided to be in an 8-bit scale for average brightness for user input.
All calculation in AE would treat user input as in the 8-bit scale.

    p_ae_dynPrms->targetBrightnessRange.min = DEFAULT_TARGET_BRIGHTNESS_MIN;
    p_ae_dynPrms->targetBrightnessRange.max = DEFAULT_TARGET_BRIGHTNESS_MAX;
    p_ae_dynPrms->targetBrightness = DEFAULT_TARGET_BRIGHTNESS;
    p_ae_dynPrms->threshold = DEFAULT_TARGET_THRESHOLD;
    p_ae_dynPrms->exposureTimeStepSize = DEFAULT_EXPOSURE_TIME;
    p_ae_dynPrms->enableBlc = DEFAULT_ENABLE_BLC;

Lu Zhang said:
I am still confused that it is true that h3a data stores 10-bit rggb data in 16-bit accumulative sum

H3A input is 10-bit RGGB and H3A output is 16-bit sum with skipping and down-shift.
Please refer to TRM for H3A details.

Processors

Processors forum

TDA4VM: Questions about strange data range of H3A ouput