TDA4VM: Tuning of AE-related issues

Hi Ying,

Ying.li said:

However, there is overexposure when there is sunlight outdoors, as shown in the figure below.

Could you please share the sensor image raw image and YUV output in this case?

Ying.li said:

I attempted to debug the exposure and gain settings in the AE algorithm and found that both the exposure and gain were already at their minimum values.

What are those values?

Hi Gang，

I also started this thread. Since you didn't reply to me at that time, I created another thread. Let's communicate here from now on.(+) TDA4VM: Consultation on AE-related issues - Processors forum - Processors - TI E2E support forums

1. The first image in the above picture and the pictures below were not taken on the same day. To summarize, when the WDR Gamma is set to 50%, the indoor brightness is normal, but the outdoor sky, clouds, etc. will be overexposed. When the WDR Gamma is set to 70%, there will be no overexposure outdoors, but the indoor area will be very dark. All the above images are YUV images, and I saved them by taking screenshots. The following are raw and yuv images.

x3c.rar

2. The following are my AE parameters, which I believe are correct.

3. Why are the YUV images extracted darker than those displayed on the monitor?

Thanks.

Hi YL,

Ying.li said:

Let's communicate here from now on

Ok, I will close the other thread.

Ying.li said:

To summarize, when the WDR Gamma is set to 50%, the indoor brightness is normal, but the outdoor sky, clouds, etc. will be overexposed.

This might happen if the raw image is very bright and GLBCE settings are extreme.

Ying.li said:

All the above images are YUV images, and I saved them by taking screenshots. The following are raw and yuv images.

Could you please add the raw image for the outdoor scene along with the companding knee points?

Ying.li said:

3. Why are the YUV images extracted darker than those displayed on the monitor?

The YUV image is sent to DSS for display on TDA4 EVM.
There might be difference in your YUV viewer.

Hi,

1. These are the raw image and YUV image taken outdoors. The raw image is not overexposed, but the YUV image is overexposed.

x3c raw.rar

2. Additionally, if it's a problem with the GLBCE settings, why is there no change in the image no matter which parameter I adjust as shown in the figure below?

Thanks!

I use DCC software to capture images and the LDC plugin to view YUV images. Both indoor and outdoor YUV images appear dark.

Ying.li said:

1. These are the raw image and YUV image taken outdoors. The raw image is not overexposed, but the YUV image is overexposed.

These raw images look OK to me and YUV images should not be saturated normally.
There might be something wrong in your VISS settings.

Do you have this problem with the xml files generated by the python script?

Ying.li said:

2. Additionally, if it's a problem with the GLBCE settings, why is there no change in the image no matter which parameter I adjust as shown in the figure below?

YUV output image should change significantly when you modify the asymmetry value.
5 may be extreme (which I would avoid to use typically).
10 ~ 30 are typical.

Ying.li said:

I use DCC software to capture images and the LDC plugin to view YUV images.

I am not actually sure if the YUV viewer in tuning tool is standard.
The VISS YUV output is in full-swing encoding and it should match the DSS settings.

Hi,

1. Here is my Python script. The XML file generated by the Python script resulted in the initial image being very dark, as shown in the figure below. 

Later, I replaced cfa_dcc.xml, and the outdoor scene became overexposed, as shown in the figure. 

Then I found an error when running generate_dcc.sh build, so I copied lut_cfa_16to12_g0o5_global.txt over, only to find that the image became dark again.

 7563.x3c.rar

I don't know what the problem is; I can only describe the phenomena to you.

2. I used the extreme asymmetry values and the CFA column from the real-time tuning, but I really couldn't see any changes.

This is an XML file generated by the DCC tuning tool.

CFA+WDR.rar

Hi YL,

Ying.li said:

1. Here is my Python script.

Your configuration file looks OK to me mostly.

Why do you use 233 as DCC ID?
That is already used by the AR0233 driver.

Could you please confirm the SDK version you use?

Ying.li said:

The XML file generated by the Python script resulted in the initial image being very dark

This is not expected once you have proper sensor exposure with correct AE settings.
You should try larger values of H3A_INPUT_LSB (typically between 2 to 6) to see if you can brighter output.

We have used the python script in this way for a few sensors including OX03F and did not see very dark output.
I would suggest that you start with just the python script and get the similar behavior first before going to tuning tool if you are not familiar with ISP details.

Ying.li said:

Then I found an error when running generate_dcc.sh build

You probably only copied the xml file and missed the included text LUT file.

Ying.li said:

2. I used the extreme asymmetry values and the CFA column from the real-time tuning, but I really couldn't see any changes.

I typically update the xml files, run "./generate_dcc.sh", and recompile to make sure all settings are effective for camera apps.

Hi Gang,

Gang Hua said:

Why do you use 233 as DCC ID?
That is already used by the AR0233 driver.

Could you please confirm the SDK version you use?

I configured the ID of x3c by referring to other x3c ID configurations on the forum, but neglected the ID of AR0233. I have now changed the ID of x3c to 310. My SDK version is Edge AI 09-02-00-05.

Gang Hua said:

This is not expected once you have proper sensor exposure with correct AE settings.
You should try larger values of H3A_INPUT_LSB (typically between 2 to 6) to see if you can brighter output

Then I'll first use the Python script to debug the image. Below are the images output after I changed H3A_INPUT_LSB to 0 and 6 respectively. And I can see that the exposure and gain is being calculated continuously.

H3A_INPUT_LSB.rar

Sorry to trouble you again, and thank you very much.

Hi Ying,

Ying.li said:

My SDK version is Edge AI 09-02-00-05.

This might be an old version for the python code.

Please use the latest python code from git.
https://git.ti.com/cgit/processor-sdk/imaging/tree/tools/default_DCC_profile_gen?h=main

Ying.li said:

And I can see that the exposure and gain is being calculated continuously.

Please use this good default for the AE settings as in below link while you are trying larger values of H3A_INPUT_LSB.

https://git.ti.com/cgit/processor-sdk/imaging/tree/sensor_drv/src/imx390/iss_sensor_imx390.c?h=main#n634

After you find some good LSB value and GLBCE tuning, then you may adjust the AE target slightly away from the default.

Hi Gang,

I downloaded the latest Python code as you suggested, and generated the ox03c10_properties.txt file under imaging/tools/default_DCC_profile_gen/configs; its content is the same as shown in the screenshot above. Then, I executed the command 

python3 ctt_def_xml_gen.py ../configs/ox03c10_properties.txt in the scripts directory,

cd sensor_drv/src/ox03c10_new/dcc_xmls/wdr. 

./generate_dcc.sh,

cd sensor_drv/src/ox03c10_new/dcc_bin/

ls dcc_2a_wdr.bin, dcc_ldc_wdr.bin, dcc_viss_wdr.bin,  OX03C10-UB953_D3 ,

I transferred the bin files to the development board and tested the video stream, but the phenomenon is consistent with before. Could you please check my steps?

ox03c10_new.rar

Ying.li said:

I transferred the bin files to the development board and tested the video stream, but the phenomenon is consistent with before.

Hi YL,

There should be no issue with the python output xml files if you have correct configuration file as input.

I don't see any saturation issue with your previously shared raw image and xml files.

Please confirm if the bin files are really taking effect with your Linux driver.

https://www.ti.com/lit/pdf/sprad86

Hi,

I've found the reason why my initial images are very dark. It's because of the WDR decompanding knee points in the Python script. If only the first few X, Y values are filled in, the image brightness is normal; but if all the WDR decompanding knee points are filled in, the YUV images become very dark. 

I think the WDR decompanding knee points I filled in are correct. The following compressed package contains the x3c information provided by the manufacturer. Could you please tell me how to fill them in the Python script?

TRAC_OX03C10_PLL_formula_and_default_setting.rar

Thank you again.

Hi YL,

I don't see anything wrong with the knee points in the configuration file.
It is comma separated without any spaces.

As long as you have proper exposure in sensor and GBLCE parameters, output should be fine.
The raw image you shared previously gives good VISS output.

To have correct sensor exposure, both H3A_INPUT_LSB and AE must be set up properly.

Hi,

Parsing:	[ox03c10_cfa_dcc.xml]
error reading file lut_cfa_16to12_g0o5_global.txt
Error at line: 59                                                       [FAIL!]

Hi Ying,

Ying.li said:

I know the output raw images look good

I see that the output YUV (not raw) looks good with the xml files.

Ying.li said:

I tested the images when the asymmetry value was set to 5 and 30 respectively, but there seemed to be no difference.

That seems suggesting the settings in xml files are not effective on your side at all.
Typically, the difference between 5 and 30 is obvious.
What if you change asymmetry to 180?

Hi Gang,

1. Does this error have any impact? Can you help me test it?

Ying.li said:

1. If I use the complete knee points, the output YUV image is dark. So I replaced ox03c10_cfa_dcc.xml, but encountered the following error. Then I added lut_cfa_16to12_g0o5_global.txt, and the output YUV image turned black again. Could you please tell me how to solve this problem? Thanks.

2. I've tested many values, but there's really no change in the image effect. Could it be that this function in the code isn't enabled, or is there a bug somewhere?

Gang Hua said:

What if you change asymmetry to 180?

Thank you very much.

Ying.li said:

1. Does this error have any impact? Can you help me test it?

The XML files may include other files such as LUTs.
You would need to copy those LUT files along with the xml files.

Ying.li said:

2. I've tested many values, but there's really no change in the image effect. Could it be that this function in the code isn't enabled, or is there a bug somewhere?

Please check if GLBCE is enabled in your gstreamer pipeline.

Copying Chau Le  for her comments regarding enabling GLBCE.

Hi,

Looking forward to hearing from you.

Hi Ying,

You may share your gstreamer pipeline for Chau Le  to review.

Hi Gang,

Thank you very much for your help and Chau Le's assistance. Now GLBCE is working properly.

However, this has not successfully resolved the severe overexposure issue. Below are the currently captured raw images and YUV images, along with the current GLBCE configuration. I have adjusted the GLBCE Strength and asymmetry values multiple times, but still cannot fix the severe outdoor overexposure problem.What do you think I need to do for further optimization?

Just to add a side note: Currently, there are still three issues with the ISP. One is the AE problem, another is the trade-off between EE and NSF4, and the third is the purple tint in the image. Since my foundation in ISP debugging is relatively weak, I really hope you can help me as much as possible. This issue has been going on for more than a week, and if it drags on any longer, I won't be able to explain it to my supervisor. Thank you very much.

1732.image.rar

Ying.li said:

However, this has not successfully resolved the severe overexposure issue. Below are the currently captured raw images and YUV images, along with the current GLBCE configuration. I have adjusted the GLBCE Strength and asymmetry values multiple times, but still cannot fix the severe outdoor overexposure problem.What do you think I need to do for further optimization?

Hi Ying,

It does not look like an optimization issue.
I don't see any saturation with GLBCE and your shared "ox03c10_1920x1280_Date_04-08-2025_Time_09-16-55.raw".
It should look somewhat similar to below in terms of tone mapping.


YUV should not saturate with any reasonable GLBCE settings.
There seems something wrong in your gstreamer configuration.
I would recommend testing with gstreamer in file to file manner (from raw to yuv) to make sure you have the basic gstreamer pipeline working properly.
You may start with the basic python script settings to get correct WDR tone mapping performance first.

Chau Le may share some sample gstreamer pipeline if you don't have it from the app note.

Ying.li said:

Since my foundation in ISP debugging is relatively weak, I really hope you can help me as much as possible. This issue has been going on for more than a week, and if it drags on any longer, I won't be able to explain it to my supervisor.

Hi Ying,

I am sorry to hear that you are under the pressure of project schedule.
Image quality tuning is iterative and time consuming and it requires a lot of background knowledge and expertise.
If you have little tuning experience, it is impossible to get image quality reasonably tuned within just a few months because of the long learning curve and required tuning effort.
It might be better to work with an imaging 3rd party for tuning if your team does not have past TDA4 ISP tuning experience.

Currently, NSF4 is too strong (removing too much image details) and EE cannot enhance the sharpness.

Hi Gang，

After adding "wdr-enabled=true", I went through the debugging methods you've told me over the past few days again, and now the AE issue should be resolved. The results indoors and outdoors are both good.

Thank you for your help over the past few days.

Hi,

Thank you for your suggestions. However, since our project is in the pre-research stage, we shouldn't be looking for third-party companies to assist us at present.

Ying.li said:

However, since our project is in the pre-research stage, we shouldn't be looking for third-party companies to assist us at present.

Understand and thank you for providing the background!

Hi Gang,

There's nothing unclear about it, and I think it's very useful.

 1. I'd like to ask that after debugging AE, I re-captured images to optimize AWB, but a strobing phenomenon occurred. How should I solve this? 

2. Additionally, during the AE calculation process, there are occasionally purple frames, and the light color also tends to be purple. How can this be improved? This phenomenon disappears once AE stabilizes.

Thanks!

Hi Ying,

Ying.li said:

There's nothing unclear about it, and I think it's very useful.

Thanks for the confirmation!

I was wondering if any documentation issue caused your trouble in enabling sensor WDR and GLBCE.

Ying.li said:

 1. I'd like to ask that after debugging AE, I re-captured images to optimize AWB, but a strobing phenomenon occurred. How should I solve this? 

You may check if AE output (sensor exposure time & gain) is stable or oscillating.

There could be some AC flickering and/or sensor driver issues in programming proper exposure time and gain.

Hi Gang,

Ying.li said:

2. Additionally, during the AE calculation process, there are occasionally purple frames, and the light color also tends to be purple. How can this be improved? This phenomenon disappears once AE stabilizes.

What could be the cause of this problem?

Hi,

If I might offer a suggestion, it’s that there currently isn’t any documentation noting that enabling GLBCE requires setting "wdr-enabled=true" in the GStreamer pipeline. Later on, I found that both the darkness of the initial YUV images generated by the original Python script and the outdoor exposure issues were successfully resolved once this setting was added.

Hi Ying,

Ying.li said:

there currently isn’t any documentation noting that enabling GLBCE requires setting "wdr-enabled=true" in the GStreamer pipeline.

Thanks for the confirmation!

We have noticed that as well.
That gstreamer option was added after the current documentation.

Ying.li said:

What could be the cause of this problem?

I cannot tell for sure.

It could be caused by extreme AWB gain values (i.e., very large red gains) or broken sensor raw image frames from sensor driver issues.

Hi,

Okay, thank you. I have one more question: when the video stream is just started, due to unstable exposure in AE, black frames or purple frames appear during the exposure adjustment process. How should this be resolved?

Hi Ying,

Ying.li said:

when the video stream is just started, due to unstable exposure in AE, black frames or purple frames appear during the exposure adjustment process. How should this be resolved?

Sensor should start with default exposure settings good for the target application.

Typically, AE won't be unstable at startup.
It only adjust exposure frame by frame, e.g., getting brighter or darker.
Purple frames could be a driver bug or s/w issue.

Hi Gang,

1. The image generated by my Python script is shown below. It has an overall purple tint, and the light also appears purple. Could there be an issue here?

2. As can be seen from the raw image, the light—before going through the ISP—is white and looks normal. However, in the YUV image processed by the ISP, the light has turned purple. This doesn’t seem to be a driver bug or software issue.

Hi Ying,

Ying.li said:

The image generated by my Python script is shown below.

What do you mean by "generated by my Python script"?

Do you missing the attachment?

Hi,

I'll redescribe the phenomenon.

1. The original image generated by "python3 ctt_def_xml_gen.py ../configs/ox03c10_properties.txt" is shown below. The indoor area has an overall purple tint, and the lights also look purple, while the outdoor area appears normal. Could this be an issue?

2. As can be seen from the raw image, the light—before being processed by the ISP—is white and normal. However, in the YUV image processed by the ISP, the light has turned purple. This doesn’t seem to be a driver bug or software issue.

3. Should I start a new thread to discuss this issue?

8461.x3c.rar

Ying.li said:

The original image generated by "python3 ctt_def_xml_gen.py ../configs/ox03c10_properties.txt" is shown below. The indoor area has an overall purple tint, and the lights also look purple, while the outdoor area appears normal. Could this be an issue?

I guess you mean using the initial tuning from the python script.

The python script does not include AWB calibration (it only gives a dummy/null one).
So, AWB could be wrong in many cases.

Ying.li said:

2. As can be seen from the raw image, the light—before being processed by the ISP—is white and normal. However, in the YUV image processed by the ISP, the light has turned purple. This doesn’t seem to be a driver bug or software issue.

Those is the raw image are not white.
It is just a false impression because of the WDR companding.

Ying.li said:

 Should I start a new thread to discuss this issue?

Yes, please if it is different topic.

Hi Ying,

It seems that you have opened a new thread for AWB below.

 TDA4VM: Inquiry about the issue of lights turning purple 

Do you still have any further question for this thread?

Hi Gang,

It's working fine now. Thank you for your help.

Thanks for the confirmation!

I will close this thread.