This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

TDA3MV: How DPC_LUT can be generated?

Mastermind 18705 points

Replies: 8

Views: 211

Part Number: TDA3MV

Dear Champs,

My customer is still looking for the details how they can generate DPC_LUT used in DPC of TDA3 ISP.

When I asked details on DPC of TDA3 ISP, I got an answer to check IpipeSetDpcLutConfig() function in below previous e2e.

https://e2e.ti.com/support/processors/f/791/p/829550/3068389#3068389

But, my customer could not understand what is DPC_LUT exactly and how they can get it.

Could you please provide details how customer can get DPC_LUT? should it be provided by sensor manufacturer? or should customer generate it for each sensor?

Thanks and Best Regards,

SI.

  • Hi SI,

    >> But, my customer could not understand what is DPC_LUT exactly and how they can get it.

    Details of DPC can be found in "7.3.3.5.4.1 ISS ISP IPIPE LUT Defect Pixel Correction (LUT DPC)" of TDA3 TRM.

    >> Could you please provide details how customer can get DPC_LUT? should it be provided by sensor manufacturer? or should customer generate it for each sensor?

    The table may be provided by sensor manufacturer or generated by a customer.
    The table will be different for each sensor, since bad pixels in each sensor are different.

    The LUT-DPC is typically used for correcting bad pixels (always white or black).
    For example, you may use very low sensor exposure under no light to detect white pixels and then put them into a table.

    Best,
    Gang

  • In reply to Gang Hua:

    Hi Gang,

    Thanks for your immediate response.

    Is it possible to provide details for DPC_table?

    When I checked '//ti_components/drivers/pdk_01_10_03_07/packages/ti/drv/vps/examples/iss/m2mWdr/src/M2mIspWdr_main.c', it seemed 'yee_table' was used for DPC table and the pointer of 'yee_table' was input to lutAddr for DPC. is this right?

    When I checked yee_table in the 'ipipeif_lut.h', I found same values were repeated for a while and could not match it with "7.3.3.5.4.1 ISS ISP IPIPE LUT Defect Pixel Correction (LUT DPC)" of TDA3 TRM.

    Could you please help on my understanding?

    in TDA3 TRM,

    But, I found same values were repeated in yee_table of vision sdk.

    uint32_t yee_table[] = {
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000000,
    0x00000004,
    0x00000004,
    0x00000004,
    0x00000004,
    0x00000004,
    0x00000004,
    0x00000008,
    0x00000008,
    0x00000008,
    0x00000008,
    0x00000008,
    0x0000000C,
    0x0000000C,

    Thanks and Best Regards,

    SI.

  • In reply to Sung-IL:

    Hi SI,

    Yes, Table 7-638 is the correct format you need.
    The LUT must be prepared in that format.

    As you stated in your question, the reference for configuring LUT DPC is "IpipeSetDpcLutConfig( )" in "/ti_components/drivers/pdk_01_10_03_07/packages/ti/drv/vps/src/vpslib/hal/src/vpshal_issipipe.c".

    "yee_table" is for a completely different block and it is not for LUT DPC.
    If you have any questions about "M2mIspWdr_main.c", please post that part of code.

    Best,

    Gang

  • In reply to Gang Hua:

    Hi Gang,

    Thanks for your response.

    When I checked the Vision-SDK, it seemed there is no application example for DPC showing how it works, right? 

    Is it possible to provide some examples how DPC works or LUT DPC example?

    Thanks and Best Regards,

    SI.

  • In reply to Sung-IL:

    Hi SI,

    I am not familiar with examples in SDK, but this "M2mIspWdr_main.c" you mentioned is an example using DPC (I am looking at an older version of pdk_01_09_06).
    It already configures the OTF-DPC which is preferred by most customers over LUT-DPC because it does not require per sensor calibration.

        if (TRUE == gAppObj.enableDpc)
        {
            /* Initialize the configuration to zero */
            BspUtils_memset(&appObj->ipipeCtrl,
                            0x0,
                            sizeof (appObj->ipipeCtrl));
            BspUtils_memset(&appObj->dpcOtfCfg,
                            0x0,
                            sizeof (appObj->dpcOtfCfg));
    
            appObj->ipipeCtrl.module = VPS_ISS_IPIPE_MODULE_DPC_OTF;
            appObj->ipipeCtrl.dpcOtf = &appObj->dpcOtfCfg;
    
            status = Fvid2_control(
                appObj->p1Cfg.drvHandle,
                VPS_ISS_IPIPE_IOCTL_GET_CONFIG,
                &appObj->ipipeCtrl,
                NULL);
    
            if (FVID2_SOK != status)
            {
                BspOsal_printf("ISSM2MWdrApp: IPIPE GetConfig Failed\r\n");
    
                return -1;
            }
    
            appObj->dpcOtfCfg.enableOtfDpc = TRUE;
            appObj->dpcOtfCfg.method       = VPS_ISS_IPIPE_DPC_OTF_METHOD_1;;
            appObj->dpcOtfCfg.dThr         = 0x0u;
            appObj->dpcOtfCfg.grThr        = 0x1u;
            appObj->dpcOtfCfg.gbThr        = 0x0u;
            appObj->dpcOtfCfg.bThr         = 800u;
            appObj->dpcOtfCfg.rCor         = 0x0u;
            appObj->dpcOtfCfg.grCor        = 0x1u;
            appObj->dpcOtfCfg.gbCor        = 0x0u;
            appObj->dpcOtfCfg.bCor         = 1023u;
            appObj->dpcOtfCfg.shiftValue   = 0x2u;
    
            status = Fvid2_control(
                appObj->p1Cfg.drvHandle,
                VPS_ISS_IPIPE_IOCTL_SET_CONFIG,
                &appObj->ipipeCtrl,
                NULL);
    
            if (FVID2_SOK != status)
            {
                BspOsal_printf("ISSM2MWdrApp: IPIPE SetConfig Failed\r\n");
    
                return -1;
            }
        }
    

    For LUT-DPC, data structures are already defined.

        vpsissIpipeDpcLutConfig_t     dpcLutCfg;
    ...
        UInt32                        dpcLutSize;
        UInt32                        dpcLut[1024u];

    You would need to replace the above code for configuring OTF-DPC with your code for LUT-DPC by populating "dpcLutCfg", "dpcLutSize", and "dpcLut" properly.

    Best,

    Gang

  • In reply to Gang Hua:

    Hi Gang,

    Could you please explain how customer can build LUT DPC?

    when we assumed there is a 'Defect Pixel' at (1200, 600) position of 1920x1080 FHD image sensor, how the position packed to LUT DPC?

    0x4B0 for 1200, 0x258 for 600 were packed into the table(0~25bit), right? eg. packed to xxx4B04B0(xxx = Correction Method).

    Is there any example table showing Defect Information Packing for LUT DPC?

    And, they want to know details how they can run LUT DPC, and could you please check if my understanding is right?

    In my understanding, it seemed Defect table address was set to 'IPIPE_DPC_LUT_ADR' in the 'IpipeSetDpcLutConfig()' function of 'vpshal_issipipe.c'.

    (<VSDK_DIR>/ti_components/drivers/pdk_01_10_03_07/packages/ti/drv/vps/src/vpslib/hal/src/vpshal_issipipe.c)

    ~~~~~~~

    regVal = HW_RD_REG32(instObj->baseAddress + IPIPE_DPC_LUT_ADR);

    regVal &= ~((UInt32)IPIPE_DPC_LUT_ADR_MASK);

    regVal |= IPIPE_DPC_LUT_ADR_MASK & cfg->lutAddr;

    HW_WR_REG32(instObj->baseAddress + IPIPE_DPC_LUT_ADR, regVal));

    ~~~~~~

    And after this, LUT DPC can be run using FVid2_control() funciton as you mentioned in above("M2mIspWdr_main.c").

    ~~~~~

        status = Fvid2_control(
            appObj->p1Cfg.drvHandle,
            VPS_ISS_IPIPE_IOCTL_SET_CONFIG,
            &appObj->ipipeCtrl,
            NULL);

    ~~~~~~

    Is my understanding right?

    Thanks and Best Regards,

    SI.

  • In reply to Sung-IL:

    Hi SI,

    The packing is explained in "7.3.3.5.4.1 ISS ISP IPIPE LUT Defect Pixel Correction (LUT DPC)" in TRM where you found and posted "Table 7-638" above.
    Please follow that section carefully in preparing your LUT.

    Your packing example is correct except that the final value of packing must follow "Table 7-638": "(xxx << 26) + (600<<13) + 1200".

    Please note that right below "Table 7-683": "The information must be listed from left to right and from the top to bottom".
    This means the order of bad pixels in the LUT is in raster scan order (which is the order pixels coming from sensor; also same as 2D array element order in C language).
    For example, these locations are listed in the right order: (h=1200, v=600), (h=1250, v=600), (h=1, v=601), (h=1200, v=601).

    I don't see anything really wrong in your understanding.
    DPC is part of the ISP and we configure DPC by writing to the register interface of ISP.
    Then, when ISP processes an image, it will use our settings.

    Although I am not an expert in the driver, I see in the code posted above from "M2mIspWdr_main.c" for configuring "appObj->dpcOtfCfg" is where you can modify to configure all the elements of (1) "appObj->dpcLutCfg", (2) "appObj->dpcLutSize", and (3) "appObj->dpcLut[1024]".
    Then, "Fvid2_control( )" shall invoke the underlying API like "IpipeSetDpcLutConfig" automatically.

    If I remember correctly, with "a finite number of entries", the maximum number of bad pixels allowed is 128 (not 256 or 1024).
    The option of "an infinite number of entries" is supported by H/W, but may not be supported by S/W SDK.
    I will get the driver experts to confirm.

    Best,

    Gang

  • In reply to Gang Hua:

    Hi SI,

    The maximum number of bad pixels is limited to 128, i.e., "appObj->dpcLutSize <= 128".

    Best,
    Gang

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.