• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 103 subscribers
  • Views 416 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM62A7: DCC profile generation tool for AM6xA ISP

peng qiang
Prodigy 250 points
Part Number: AM62A7

Hi TI experts

We plan to use SDK 9.2, but during testing, we found that using the latest script from that website（git.ti.com/.../default_DCC_profile_gen, the generated dcc_2a_wdr. bin and dccvis_wdr. bin did not light up properly.The results are shown in the following figure：

Let me describe the operational steps：

1.download imaging-main.zip

2.Edit x3c configuration file

x3c_properties.txt 
SENSOR_ID 233
PRJ_DIR ../X3C
SENSOR_NAME x3c
SENSOR_DCC_NAME SENSOR_OX3C

SENSOR_WIDTH 1920
SENSOR_HEIGHT 1280

# 0=RGGB;  1=GRBG;  2=GBRG;  3=BGGR,  4=MONO,
#10=RGGI, 11=GRIG, 12=BGGI, 13=GBIG, 14=GIRG, 15=IGGR, 16=GIBG, 17=IGGB														   
COLOR_PATTERN 3

#sensor mode :0 for linear, 1 for WDR
WDR_MODE 1

# BIT_DEPTH may be 12, 10, or 8 for linear mode
BIT_DEPTH 12

#raw sensor image BIT_DEPTH
WDR_BIT_DEPTH 24

#WDR decompanding knee points
WDR_KNEE_X 0,1023,1279,1535,2303,2559,2943,3071,3327,3455,3519,3647,3775,3903,3999,4095
WDR_KNEE_Y 0,1023,2047,4095,16383,24575,49151,65535,131071,196607,262143,524287,1048575,2097151,4194303,16777215

#Sensor black level to subtract before decompanding (for linear sensors only and some Sony WDR sensors)
BLACK_PRE  0

# Sensor black level to subtract after decompanding (for most WDR sensors and all linear sensors)
BLACK_POST  0

# GAMMA value for compressing 20/24-bit WDR raw to 16-bit ISP internal
# typically around 50 (0.5) for 24-bit WDR sensors and 70 (0.7) for 20-bit sensors
GAMMA_PRE 60

# LSB location for H3A input bit range (from bit-H3A_INPUT_LSB to bit-H3A_INPUT_LSB+9) 
H3A_INPUT_LSB 0

3.Then enter  sensor driver folder and run the "generate_dcc.sh" script from there.At this point, there is a problem of not being able to produce the image

4.I will put the XML file for DCC3.0 generated image quality debugging into sensor driver folder and run the "generate_dcc.sh" script.

5.At this point, there is an issue: Uable to init TIOVX module.As shown in the following figure.

May I ask how to solve this problem?

  • 0
    TI__Guru 52895 points

    Hello Peng Qiang,

    peng qiang said:

    3.Then enter  sensor driver folder and run the "generate_dcc.sh" script from there.At this point, there is a problem of not being able to produce the image

    The PRJ_DIR folder must be under imaging/sensor_srv/src, for example, ../../../sensor_drv/src/X3C.

    peng qiang said:
    5.At this point, there is an issue: Uable to init TIOVX module.As shown in the following figure.

    Would you mind sharing your complete GStreamer pipeline?

    In addition, have you validated receiving raw data from the sensor using yavta or v4l2 utility?

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Prodigy 250 points

    Hi jianzhong

    Jianzhong Xu said:
    The PRJ_DIR folder must be under imaging/sensor_srv/src, for example, ../../../sensor_drv/src/X3C.

    After trying to modify the directory location, the screen is still pitch black.

    Jianzhong Xu said:
    Would you mind sharing your complete GStreamer pipeline?

    gst-launch-1.0 \

    v4l2src device=/dev/video3 io-mode=5 ! \
    video/x-bayer, width=1920, height=1280, format=bggr12, framerate=60/1 ! \
    tiovxisp sensor-name=SENSOR_OX3C \
    dcc-isp-file=/opt/edgeai-gst-apps/firmwarebuilder_output/pengqiang/dcc_viss_wdr.bin \
    sink_0::dcc_2a_file=/opt/edgeai-gst-apps/firmwarebuilder_output/pengqiang/dcc_2a_wdr.bin sink_0::device=/dev/v4l-subdev2 format-msb=11 \
    sink_0::pool-size=2 src::pool-size=2 ! \
    tiovxldc dcc-file=/opt/edgeai-gst-apps/firmwarebuilder_output/pengqiang/dcc_ldc_wdr.bin sensor-name=SENSOR_OX3C \
    sink::pool-size=2 src::pool-size=2 ! \
    video/x-raw, format=NV12, width=1920, height=1280,framerate=60/1 ! queue ! \
    kmssink driver-name=tidss async=false sync=false

    Jianzhong Xu said:
    In addition, have you validated receiving raw data from the sensor using yavta or v4l2 utility?

    On the left is the result when the wdR_mode parameter is 1 in the configuration file, and on the right is the result of 0. This means that using different bins and the same gst pipeline has different effects.

  • 0
    Prodigy 230 points

    Hi Jianzhong,

    Please allow me to add some more details.

    The "unable to init TIOVX module" was seen before, mostly happened when files compiled from firmware builder are not used together(libtivision_app.so.x.x and tispl.bin). As the detail suggests, it should be API mismatch or something similiar.

    As for SDK9.2, my experience is that with original file system untouched and dcc_xxx.bin from previous build, the TIOVX module error above will occur. In Peng Qiang's latest reply , the picture in the right captured when running gstreamer with dcc.bin from the SDK9.2. I simply followed the instruction in this link and generated the bins in the linear subdir. The configuration file in use is basically the same as the one in Peng Qiang's initial post, with WDR_MODE = 0 as the only difference.

    My first assumption is that in the dcc_xxx.bin there are some API calls that are mismatched. Maybe it would be better to identify the key problems, i.e. differences in utility APIs. Is there any file that lists the modifications in the new SDK?

    The second thing is that when generating xmls with the python scripts, numpy will get involved if WDR_MODE = 1. Could the black screen problem be caused by the difference in python verison and/or numpy version?

    Regards

    Huang Jingjie

  • 0 in reply to jingjie.huang
    TI__Guru 52915 points
    jingjie.huang said:
    The second thing is that when generating xmls with the python scripts, numpy will get involved if WDR_MODE = 1. Could the black screen problem be caused by the difference in python verison and/or numpy version?

    If you have numpy installed, the output xml files should be OK.

    The difference between 0 and 1 is about WDR decompanding.

    Do you see anything if you point the camera to a bright scene?

  • 0 in reply to Gang Hua
    Prodigy 230 points

    Hi Gang,

    I tried pointing the flashlight of my cell phone to the camra, there was a small but bright round showing in the video stream.

    So this could be a data processing issue. Please further discuss the detail with Peng Qiang. Thank you !

    Regards,

    Huang Jingjie

  • 0 in reply to Gang Hua
    Prodigy 250 points

    Hi Gang

    jingjie.huang said:
    I tried pointing the flashlight of my cell phone to the camra, there was a small but bright round showing in the video stream.

    The current situation seems to be caused by not enabling the glbce function.

    We set sensor_wdr_enable to 1.But without any effect, the picture is still very dark.

    May I ask if there are any other parameters in SDK 9.2 that affect image quality?

  • 0 in reply to Gang Hua
    Prodigy 250 points

    Hi Gang 

    peng qiang said:
    At this point, there is an issue: Uable to init TIOVX module.As shown in the following figure.

    Replace the XML file in the SDK 9.2 script with the XML file generated by DCC3.0.
    The generated dcc_2a_wdr. bin and dccvis_wdr. bin have the issues shown in the above figure.

    Is it caused by a mismatch between the XML generated by DCC3.0 and SDK 9.2?

  • 0 in reply to peng qiang
    TI__Guru 52915 points

    peng qiang said:

    We set sensor_wdr_enable to 1.But without any effect, the picture is still very dark.

    May I ask if there are any other parameters in SDK 9.2 that affect image quality?

    The tiovx interface should be the same as before.
    I am not sure of any recent changes.

    In a previous thread about 9.0, there was the same question about WDR.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1296549/processor-sdk-am62a-the-video-screen-is-too-dark-and-the-bayer-format-is-incorrect/4921426?tisearch=e2e-sitesearch&keymatch=sensor_wdr_enabled#4921426

    Jianzhong may comment on if there is any recent changes on gstreamer for enabling WDR.

  • +1 in reply to peng qiang
    TI__Guru 52915 points
    peng qiang said:
    Is it caused by a mismatch between the XML generated by DCC3.0 and SDK 9.2?

    There might be some issue with very old version of XML files, but I don't recall anything for 3.0.

    Do you see any difference in the data structures in the header of any XML file?

  • 0 in reply to Gang Hua
    Prodigy 250 points

    Hi Gang

    I'm not sure if this difference will cause an error. (On the left is DCC3.0, and on the right is SDK 9.2 by default)

    There are many similar differences.

  • 0 in reply to peng qiang
    TI__Guru 52915 points

    Hi Peng,

    peng qiang said:
    On the left is DCC3.0, and on the right is SDK 9.2 by default

    Those differences should not really matter.

    Are you able to locate a particular xml file causing the error?

  • 0 in reply to Gang Hua
    Prodigy 250 points

    Hi Gang

    0647.case.zip

    Among them, x3c is an automatically generated XML file in 9.2, and x3c_ele is an XML file generated in 3.0.

    I cannot locate which files are causing the problem by comparing their differences.

  • +1 in reply to peng qiang
    TI__Guru 52915 points

    Hi Peng,

    peng qiang said:
    I cannot locate which files are causing the problem by comparing their differences.

    It looks like you used a specially made rgb2rgb xml file which is not supported by DCC.

    Please merge your pervious changes under "imaging/algo/dcc/" to support that.