TDA4VH-Q1: Image Greenish Tint Issue

Part Number: TDA4VH-Q1

Tool/software:

Hello Colleagues,

We were testing our camera pipeline and ISP performance using the IMX390 camera and encountered a greenish tint issue in the image. There are four different images in the shared zip file, representing two different scenes (I can provide more images for further investigation if needed). One pair of images was captured with a camera featuring a built-in ISP, which appears normal (not green). The other pair was captured with a camera without a built-in ISP, where we used the ISP binaries provided in the IMX390 SDK.

In general we have observed that the greenish tint issue occurs on walls, asphalt or grey regions. It is also important to note that it occurs everywhere not just around peripherals or center. Do you have any comments or suggestions on this issue? What could be the root cause of such problem?

Greenish Tint Issue.zip

Thanks in advance.

  • Hi Kaan,

    we have observed that the greenish tint issue occurs on walls, asphalt or grey regions.

    It looks like the blue channel AWB gain is weaker than expected.

    Do you have any comments or suggestions on this issue? What could be the root cause of such problem?

    In general, I would expect AWB to work properly under this kind of day time road driving conditions.
    Such AWB failure is typically caused by AWB calibration.

    If AWB fails consistently under similar conditions, we would need to inspect your AWB calibration against the raw sensor images under the failing scene.

  • Hello Gang,

    Thank you for your feedback. 

    Previously as I mentioned, we were using the ISP binaries from SDK. Since we are using LI IMX390 camera but not D3, I wanted to re-calibrate AWB, and observed very similar output. Interestingly, when we lower the shutter time due to overexposed regions, the amount of green tint reduced considerably. However, it is not fixed completely. In order to further enhance this AWB calibration do we need to put additional resources to AWB calibration plugin capturing the color checker chart under the sun and shade? Is my understanding correct?

  • Hi Kaan,

    Interestingly, when we lower the shutter time due to overexposed regions, the amount of green tint reduced considerably.

    If it is at the same scene, it is possibly due to  either a mismatch between AWB calibration and scene lighting or in proper H3A settings.

    In order to further enhance this AWB calibration do we need to put additional resources to AWB calibration plugin capturing the color checker chart under the sun and shade? Is my understanding correct?

    That may not help.

    If you share a raw image (with knee points, pedestal) at the failing scene and the AWB/H3A xml files, I can take a look to decide if there is any issue with AWB/H3A settings.

  • Hi Gang,

    I am sharing the raw and yuv images for the same scene, especially the green tint occurs in the upper left and bottom right regions. Also please find the xmls and knee pts in the attachments. The pre and post pedestals are 0.

    h3a and awb xmls.zipknee pts and images.zip

    Thanks 

  • Hi Gang,

    In addition to all of these, we also found some color related settings in the IMX390 registers, which was provided by the sdk 10. 

    We found that the AE_SENSRATIO_... registers (0x34C0 - 0x34CE) are all set to 0x40 corresponding to a gain of "1" while the OTP_SENSRATIOEN bit (0x3053/bit-7) is set to"0" and "pixel value switching" method is chosen for HDR compositing regions. Might this be the reason for false colouring we observe in some regions of our images?

    Thanks 

  • Hi Kaan,

    please find the xmls and knee pts in the attachments.

    Thanks for sharing!

    Overall, your AWB calibration matches the street scene in the raw image fairly well.

    especially the green tint occurs in the upper left and bottom right regions.

    I am not sure where you are referring to exactly.
    There are some lens flare/glare on the right side and reflection of the building on the left side is different from other areas.
    Neither seems related to AWB.

    AWB applies global gains for white balancing.
    In such a complex scene, different places in the view may have different light sources and AWB can only make a reasonable tradeoff globally.

  • We found that the AE_SENSRATIO_... registers (0x34C0 - 0x34CE) are all set to 0x40 corresponding to a gain of "1" while the OTP_SENSRATIOEN bit (0x3053/bit-7) is set to"0" and "pixel value switching" method is chosen for HDR compositing regions.

    I believe our IMX390 driver used the sensor register settings originally provided by Sony.
    I am not aware of what optimization Sony might have done previously for that.

    As I understand, Sony typically need to do calibration for each camera/sensor/lens model to have the best HDR performance.
    e.g., I can see in your YUV image, some cloud in the sky shows up as pink, which is one type of color artifacts due to sensor calibration.
    You may check with Sony about what calibration can be done.

  • Hi Gang, 

    Thanks for checking it out.

    I am not sure where you are referring to exactly.
    There are some lens flare/glare on the right side and reflection of the building on the left side is different from other areas.
    Neither seems related to AWB.

    Exactly, this is where I wanted to point out.

    In such a complex scene, different places in the view may have different light sources and AWB can only make a reasonable tradeoff globally.

    However, what I couldn't understand is that, we have exactly same camera (imager and lens) with built in ISP and on that we don't face with this green tint issue. I was wondering, could it be because of the amount of knee pts which is limited to 4 due to HWA. If we would use LUT based AWB, would that make any difference?

    In addition what could be the other possible reasons to be considered and fixed? 

    Thank you for your valuable support.

  • I believe our IMX390 driver used the sensor register settings originally provided by Sony.
    I am not aware of what optimization Sony might have done previously for that.

    As I understand, Sony typically need to do calibration for each camera/sensor/lens model to have the best HDR performance.
    e.g., I can see in your YUV image, some cloud in the sky shows up as pink, which is one type of color artifacts due to sensor calibration.
    You may check with Sony about what calibration can be done.

    Thanks a lot, we will.

  • Hi Kaan,

    I was wondering, could it be because of the amount of knee pts which is limited to 4 due to HWA. If we would use LUT based AWB, would that make any difference?

    Yes, knee points may possibly cause some amount of color error (typically small amount green/pink tint).
    It can be typically observed in lab test with gray background.
    Using more knee points can typically reduce/remove this kind of color error.

    In this complex scene, I cannot tell if the green tint is present in the original scene.
    The companded raw image shows different color from other similar places in the scenes.

    However, what I couldn't understand is that, we have exactly same camera (imager and lens) with built in ISP and on that we don't face with this green tint issue.

    If you know the knee points used, you may try that on TDA4 to see if they can help.

  • Hi Gang,

    Using more knee points can typically reduce/remove this kind of color error.

    Thanks a lot for your support. I have one last question. I remember from a previous discussion of ours that "The number of knee points is limited in H/W to 4 and most sensors nowadays use more knee points than that. So, we don't normally use the PWL." (Please see the LINK for the previous discussion. So how can we use more knee pts as you suggested?

    Thanks

  • Hi Kaan,

     So how can we use more knee pts as you suggested?

    RAWFE has a both PWL and a LUT block.

    So, we typically use the LUT block for doing the conversion.
    That is done in both the tuning tool and the python script -- https://git.ti.com/cgit/processor-sdk/imaging/tree/tools/default_DCC_profile_gen/scripts/dccxml_decompand.py?h=main

    For simplicity, we typically set the sensor 12-bit knee points to multiple of 32 to avoid any LUT error from the LUT step size.


    That has been considered in the IMX728 driver for sensor knee points.

    https://git.ti.com/cgit/processor-sdk/imaging/tree/sensor_drv/src/imx728/imx728_ub971_sensor_config_wdr.h?h=main#n7779