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.

Linux/TDA2PXEVM: LDC of ISS SIMCOP is not working in default lut file in vision sdk

Part Number: TDA2PXEVM

Tool/software: Linux

Hi,

I'm evaluating LDC feature of iss simcop.
I think that simcop ldc link is working but there are some problem in lut itself or managing its parameters such as offset, downScaleFactor.

* usecase: hlos iss_isp_simcop_display (modified to support ldc feature)
* Camera: single ch OV2775 TIDA1130 Sensor on Fusion Platform (1920x1080)
*  LDC lut header file: vision_sdk\apps\src\rtos\iss\src\sensor\iss_tables\iss_tables_ldc_lut_1920x1080.h (vision sdk default)

Please find the following display images with different ldcCfg->lutCfg.downScaleFactor. When lut data was filled with 0xff or 0x00 instead of default, the output image pattern was similiar.

■  bypasLdc = TRUE (regardless of bypassVtnf or lutCfg.downScaleFactor)

■  bypasLdc = FALSE,  lutCfg.downScaleFactor = 0

■  bypasLdc = FALSE,  lutCfg.downScaleFactor = 1

■  bypasLdc = FALSE,  lutCfg.downScaleFactor = 2

■  bypasLdc = FALSE,  lutCfg.downScaleFactor = 3

■  bypasLdc = FALSE,  lutCfg.downScaleFactor = 6 or 7

  • It seems like you have not generated the LUT for the number of pixels in the image. Therefore, these artifacts are expected. Please generate the correct LUT for your image.

  • If the default 1920x1080 lut file is ok, How to calculate lutCfg.address and lutCfg.lineOffset?
    I can't find its meaning in TRM or any other documents.

    vision_sdk\apps\src\rtos\iss\src\common\iss_utils.c

     /* Using LDC Lut table of 1920x1080 size with 4x down scaling factor
     Using LDC table from the offset ((1920x1080) - (1280x720))/2 */
     ldcCfg->lutCfg.address = (UInt32)&gChainsCommonIssLdcTable_1920x1080
     [
     (ISS_UTILS_MESH_TABLE_PITCH(1920,
     (1 <<VPS_ISS_LDC_LUT_DOWN_SCALE_FACTOR_4)) * 15) + 320
     ];

     ldcCfg->lutCfg.lineOffset = ISS_UTILS_MESH_TABLE_PITCH(1920,
          (1U << ldcCfg->lutCfg.downScaleFactor));

    #define ISS_UTILS_MESH_TABLE_PITCH(w, r) ((((((w)/(r))+1) + 15U) & ~15U) * (4U))

  • Hi Kim,

    lut address is the address of the physical memory where it is stored, the same address we need to configure in the LDC module.
    For the line offset, you could above equation in macro. It uses Lut down scaling factor and image width to calculate line offset.

    Rgds,
    Brijesh
  • Hi Brijesh,
    Thanks for your reply.

    As related ticket e2e.ti.com/.../662696, mesh table is the relative position of each pixel.
    If mesh table is all filled with 0x00, there will be no ldc effect?

    Thanks.
  • Hi Kim,

    Yes, that should be be behavior.

    Regards,
    Sujith
  • Hi Sujith,
    Thanks for your reply.

    If there are similar noisy patterns nevertheless changing mesh table to all 0x00.
    What's the possible causes for it? Incorrect input image format, or any other ldc parameters?

    Thanks.
  • Hi Kim,

    Can you dump the LDC LUTs from CCS/M4 and check if the LUT is indeed null mapping.

    Regards,
    Sujith
  • Hi Sujith,
    Thanks for your reply.

    The value of memory dump of LUT was not 0x00.
    Output image was good after changing memory to 0x00 manually.

    I assume the address was overwritten after initializing as below and it was updated at each camera frame.

    // IssUtils_InitSimcopConfig() @ vision_sdk\apps\src\rtos\iss\src\common\iss_utils.c
    ldcCfg->lutCfg.address = (UInt32)&gChainsCommonIssLdcTable_1920x1080[0];

    Can you tell me how to setup LUT address in vision sdk especially for hlos usecase?

    Thanks.
  • Hi Kim,

    Okay, thanks for the confirmation. Can you close this thread.
    There is no direct support for updating the LDC LUT's from HLOS side but we can help to implement it.
    Please start a new thread for same.

    Regards,
    Sujith
  • Hi Sujith,

    Thanks for your support. It was very helpful to find the cause.
    New thread is opened.


    e2e.ti.com/.../718409