TDA4VM: The effect of decompanding on purple edge

Hi,

wang zhili said:

Does this mean that the purple edge have something to do with the decompanding setting or PWL?

Not exactly for that, but related to compressing the dynamic range.

wang zhili said:

I closed off the "WDR Enable"

Doing that saturates/compresses the dynamic range in that area around the light so that no color is present at the end.
In general, compressing the dynamic range in that intensity range will reduce the residual color.

There is sharp transition from dark to bright around the light which causes trouble to tone mapping and color processing.
Strong compression of the dynamic range at the bright side will make it easier for tone mapping and color processing, but it may cause other side effects for dynamic range at day time.

Hi Gang,

We found that where the purple edge appeared in yuv, there is an obvious drop of pixel values at the corresponding region in raw, does this mean that the purple edge is related to tone mapping?

Thanks.

Hi Gang,

There is no any changes on the purple edge after I modified the PWL setting in sensor and DCC CFA + WDR plugin, it looks like that the purple edge is not related to the PWL, which is conflict with the result that I set "WDR Enable" ON or OFF.

Do you think what may cause this difference?

Thanks.

wang zhili said:

the purple edge is related to tone mapping

Yes, it is related to local tone mapping.

The brightness transition is too sharp in Bayer pattern (pixel values change too fast within 2x2 pixel blocks).
Local tone mapping creates ripples while compressing the dynamic range of Bayer pattern.

wang zhili said:

There is no any changes on the purple edge after I modified the PWL setting in sensor and DCC CFA + WDR plugin

I am not sure what you mean by changing PWL.
If it is sensor companding knee points, then not much influence is expected.

To mitigate the problem, compress (distort) the bright side dynamic range (similar to disabling PWL) and tuning local tone mapping parameters may help.

Gang Hua said:

To mitigate the problem, compress (distort) the bright side dynamic range (similar to disabling PWL) and tuning local tone mapping parameters may help.

Do you have any advice on how to compress the bright side dynamic range and LTM? I have tied to change the parameters in GLBCE tab of CFA + WDR plugin, but I didn't see much obvious difference on the purple edge region.

Does the GLBCE compress the image data to more lower bits (less than 16bit)? How to understand the impact of PWL and GLBCE on images?

Hi Zhili,

I don't have any specific advice.
This is a topic typically handled by experienced imaging 3rd parties.

In general, adjusting the tone mapping asymmetry lookup table at night time would be the first thing I may try.
You may refer to the TRM for generating the asymmetry LUT.

Hi Gang,

The purple edge problem has been bothering us for a long time, except PWL (dynamic range compress) and tone mapping, what do you think we can try to solve or improve this problem?

Thanks.

Hi Zhili,

My understanding is that controlling global tone curve and tuning local tone mapping are possible options.

When you changed PWL settings, you are effective adjusting the global tone curve so that the area around the light is compressed heavily before local tone mapping, and therefore much less ripple is created by local tone mapping (GLBCE).

Adjusting local tone mapping parameters of asym and dp may result in compressing more on the bright side of the image to avoid the ripple effect.

Another possibility is to adjust GLBCE's spatial and intensity variance so that the local tone mapping behavior can be adjusted.

Hi Gang,

When I modify the PWL setting before, I modified the value of sensor companding register and the decompanging value in DCC, which are compatible with each other. As you said, PWL is a global tone curve. I can try to modify it to see whether it is effective for purple circle problem. In other words, can PWL in DCC be set differently from sensor companding?

Gang Hua said:

Adjusting local tone mapping parameters of asym and dp may result in compressing more on the bright side of the image to avoid the ripple effect.

What is he parameter of dp? I do not find this parameter in GLBCE tab.

Thanks.

wang zhili said:

I modified the value of sensor companding register and the decompanging value in DCC, which are compatible with each other.

I know that changing these sensor knee points may have some minor effects on the dark side if not done carefully.
I don't expected it to affect the bright side as long as the sensor raw image is in good quality.

wang zhili said:

As you said, PWL is a global tone curve.

I suppose this refers to the input image bit-depth and pre-compress gamma together as the global tone curve.
For example, your sensor is 24-bit WDR, and your actual scene may have only 18-bit DR.
Choosing a global tone curve with 24-bit or 18-bit will have different effects on the final tone mapping results.

wang zhili said:

What is he parameter of dp? I do not find this parameter in GLBCE tab.

You may find the details in TDA4 TRM VISS-GLBCE section.

Hi Gang,

I only changed the PWL settings in DCC (THR X and Y 0-15 in WDR tab) and didn't change the companding values in sensor, the result show that the purple circle can be improved a few, but when the digital gain increased, the effect will become opposite, there will be a new purple circle appear near the highlight region because the valve of raw increase. Can this new circle be solved by LTM? However, it had noting changed after I tuned GLBCE.

I found the dp valve in the "C-code for generating the Asymmetry LUT" in TRM, is this what you mean by dp parameter? I successfully modified the value to generate new asymmetry LUT, but have not yet tested the actual effect on purple circle.

Thanks.

wang zhili said:

didn't change the companding values in sensor, the result show that the purple circle can be improved

Yes, this effectively changes the global tone (but it also distorts the color at the very bright side).

wang zhili said:

there will be a new purple circle appear near the highlight region because the valve of raw increase. Can this new circle be solved by LTM?

It looks like that LTM causes ripples around these sharp transition, but I did not get any time to look into details.
Adjusting the global curve and asymmetry LUT should vary the LTM behavior.

wang zhili said:

I found the dp valve in the "C-code for generating the Asymmetry LUT"

Yes, that is the one.

There is no change on the purple circle after I updated the asymmetry lut that modified the parameter dp in C-code. And I didn't find any changes on the purple circle after modified the parameter in GLBCE. It seems that the GLBCE effect domain do not include the region of purple circle.

Hi Gang，

Do you have any other client's xml files of OX03C10 module can be share with us to compare? 

wang zhili said:

It seems that the GLBCE effect domain do not include the region of purple circle.

It looks like tone mapping (GLBCE) creates a ripple (undershoot) around the bright LED light because the contrast of the light and background is very large.
The ripple (undershoot) causes some purple color at the end.
That also happens for street lights at night giving a dark band around the center of the light as in below image.
The purple artifacts are worse in your shared image probably because the contrast in higher in your indoor scene.

I don't have much experience in tuning for this situation.
It looks like to me varying GLBCE parameters have more effects on the outer white halo than the inner dark/purple band.

Your manipulation of PWL at the top of this threads is similar to saturating the lights at decompanding.
Saturating the lights has more effects on the dark band because light is saturated and contrast is reduced before GLBCE (compare the picture below with saturation and the above on without saturation).

But, that requires managing the decompanding global tone curve dynamically and may have side effects on traffic lights if not done properly at runtime.

wang zhili said:

Do you have any other client's xml files of OX03C10 module can be share with us to compare?

We don't get or keep tuning results from customers unless someone shares their results on public forum.

Your indoor test with LED lights is worse than typically street views I have seen.

This cropped picture from output video below is a typical street light at night without doing special tuning of GLBCE parameters (it is not from any customers or X3C).

The dark band and white halo are visible but not as bad in purple color as your share results at the top.

BTW, I am out of office in July for personal reasons and my response will be delayed.

Gang Hua said:

without doing special tuning of GLBCE parameters

Does this mean that GLBCE parameters remain default?

I believe asymmetry is adjusted for every sensor.