TDA4AL-Q1: brightlight region detail loss issue

Hi Taylar,

Taylar Huang said:

Sony sensor tell us WDR_24bit raw still has some visible detail in brightlight region, however the detail was loss after TI ISP processed.

Please share your raw and yuv images so that we can see the issue.

Taylar Huang said:

J2's brightlight detail is for reference, we want to get the same detail like it

You might have missed uploading this image.

Taylar Huang said:

WDR_yuv.jpg -> after TI ISP processed

"jpg" image may have some amount of compression loss.
Please share the original yuv file.

brightlight_detail_loss.zip

Sorry, I just uploaded the attached file.

Hi Taylar,

What are the companding knee points for "WDR_12bit.raw"?

Hi Gang Hua,

# WDR decompanding knee points (comma separated without spaces in between)
WDR_KNEE_X 0,938,1851,2396,3251,4095
WDR_KNEE_Y 0,3132,105740,387380,3818601,16777215

Hi Taylar,

Taylar Huang said:

. Sony sensor tell us WDR_24bit raw still has some visible detail in brightlight region,

I suppose by visible details you are referring to the LED beads in the J2 picture as below.

Those are visible in sensor raw image, but they are partially saturated, i.e., all G pixels are saturated to 24-bit max and a small portion of R/B pixels may be ~23 bits.

After white balance gains (red gain ~2.5x and blue gain = ~1.75x in linear domain) are applied in ISP, all R/G/B are saturated to 24-bit max.
That is why your YUV image show solid white.

For partially saturated raw pixels, the safe way of processing is to saturate all R/G/B pixels to avoid false color.

Hi Gang Hua,

"For partially saturated raw pixels, the safe way of processing is to saturate all R/G/B pixels to avoid false color."

"To saturate all R/G/B to avoid false color" still can't resolve the over-exposure issue, is it correct?

We'd like to know if there is any way to resolve detail loss in bright region, such as adjusting PWL knee point, modifying ISP tuning paramter.

Hi Taylar,

Taylar Huang said:

"To saturate all R/G/B to avoid false color" still can't resolve the over-exposure issue, is it correct?

In the shared raw image, the loss of details is due to saturation.
There is only a small amount of details available in raw sensor image (i.e., only a small portion of R/B pixels are not saturated in raw image).
But, the requirement of AWB would remove those remaining small amount of details.
That is the cause of the difference you observed in sensor raw image and VPAC output YUV.

Taylar Huang said:

We'd like to know if there is any way to resolve detail loss in bright region, such as adjusting PWL knee point, modifying ISP tuning paramter.

One practical measure of the loss of details at highlight is to check if Green pixels are saturated (since G pixels are brighter than R/B pixels).
In this particular case of the LED lights, since all G pixels are already saturated in sensor raw image, there is no way to recover the details in ISP.

In general, highlights have to be below the sensor 24-bit range to be retained in YUV output.

Hi Gang Hua,

About you mentioned "In this particular case of the LED lights, since all G pixels are already saturated in sensor raw image, there is no way to recover the details in ISP." So, you think this issue should be resolved by Sony sensor side, is it correct?

Taylar Huang said:

So, you think this issue should be resolved by Sony sensor side, is it correct?

It looks like the dynamic range of scene exceeds the sensor exposure.
If you would like to keep the lights unsaturated, you would have to lower the sensor exposure.
Then the dark areas of the scene will become darker and you would have to either keep them invisible or use stronger tone mapping parameters.

We ever tried to reduce the exposure from 128x_11msec to 16x_11msec, but the halo still exists even though some detail could be seen at the center of light source. 

...

compare_16x_V.S._128x.rar

Taylar Huang said:

but the halo still exists even though some detail could be seen at the center of light source.

I suppose the halo is physically present in raw sensor image at both exposure.
I am not sure if it can be reduced by sensor settings or it is purely optical.

The details in the LED lights are as expected.

Hi Gang Hua,

We have two questions as below:

(1) To clarify the the over-exposure issue, we'd like to know if we can get the raw image from node1/node2/node3?

node1: we want to get 24bit raw which is after PWL decompanding by TI and compare with 24 bit raw at sensor side before PWL companding.

node2: we want to get 16bit nonlinear raw to check how much detail loss comparing with 24bit raw after PWL decompanding

node3: we also want to get 12bit raw at CFAI stage to check the detail

(2) About the process from node1 to node2, there it Non-Linear LUT to compress 24bit to 16bit with one gamma curve. May I know how it works? We want to evaluate the detail loss at this stage.

Thanks

Taylar

Hi Taylar,

Taylar Huang said:

(1) To clarify the the over-exposure issue, we'd like to know if we can get the raw image from node1/node2/node3?

Please refer to our discussion on the other e2e thread:  RE: TDA4AL-Q1: How Does the Shift Block Handle Bit/Byte Ordering After Decompanding? 

BTW, there is no output at node-1 as "PWL" is not used at all.
"LUT" takes the 12-bit sensor input and convert it to 16-bit output including both decompanding and re-compression.

Taylar Huang said:

(2) About the process from node1 to node2, there it Non-Linear LUT to compress 24bit to 16bit with one gamma curve. May I know how it works? We want to evaluate the detail loss at this stage.

In the default mode by s/w, it is a simple 128-entry look-up-table with step size of 32.
H/W-wise, its step size is variable and programmable.

Please refer to the VPAC-VISS-RAWFE section in TDA4 TRM for details.

Dear Gang Hua,

Thanks for your sharing information. We also want to know about node3 (from U16 to U12). We don't want to do the compression from U16 to U12. We want to use U16 from GLBCE->CFAI->CC->EE-> U16 output. Do you think it is feasible or not?

Hi Taylar,

Taylar Huang said:

We don't want to do the compression from U16 to U12. We want to use U16 from GLBCE->CFAI->CC->EE-> U16 output.

CC input is limited to 12-bit.
So, you won't be able to get U16 input through CC.