• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 786 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

PROCESSOR-SDK-DRA8X-TDA4X: RAWFE H3A block tuning

Zs lei
Intellectual 660 points

Part Number: PROCESSOR-SDK-DRA8X-TDA4X

Hi TI experts,

I have some questions related to AE/AWB engine of RAWFE H3A.

1. h3a_merge function in Vx_aewb_target.c

Could you help answer my questions below?

static void h3a_merge(
        h3a_aewb_paxel_data_t  *p_in,
        int                     sz_h,
        int                     sz_v,
        int                     pix_in_pax, //Z:
        int                     T_low,
        int                     T_high,
        h3a_aewb_paxel_data_t  *p_out)
{
    int th1 = pix_in_pax * T_low; //Z: what is implication and purpose to define th1 and th2?
    int th2 = pix_in_pax * T_high;
    int k;
    for (k = 0; k < sz_v * sz_h; k++)
    {
        if (p_in[k].green >= th1 && p_in[k].green <= th2) //Z: what the case is? Is it to use green to conclude if too dark and bright? 
        {
            p_out[k] = p_in[k];
        }
        else
        {
            p_out[k].red = (p_out[k].red * 7) >> 3; //Z: Why convert origin value with this formula? How do you define this formula?
            p_out[k].green = (p_out[k].green * 7) >> 3;
            p_out[k].blue = (p_out[k].blue * 7) >> 3;
        }
    }
}

2. parse_h3a_out function in Vx_aewb_target.c

There are code as below,

 h3a_data[j * n_col + i].red  = (sum_r + (n_pix>>1)) / n_pix;
 h3a_data[j * n_col + i].blue = (sum_b + (n_pix>>1)) / n_pix;
 h3a_data[j * n_col + i].green = ((sum_gr + sum_gb + n_pix + 1 )>>1) / n_pix; //bug_fix: rounding

Why add 'n_pix>>1' for either red and blue?

For green, why add 1 after 'sum_gr + sum_gb + n_pix'? Why right shift after '(sum_gr + sum_gb + n_pix + 1 )'?

3. write_h3a_image function in App_single_cam_main.c

Write_h3a_image can write h3a data to file. Which h3a data is writen to file? Original h3a data or after processed by h3a_merge?

The h3a data in this file is same as TI_AE_do function h3a data input (h3a_aewb_paxel_data_t * h3a_data)?

I attached one h3a file as example. Corresponding xml file is also attached.

Recently I'm modifying AEC algorithm to fit 3-exp WDR usage. Your feedback is very appreciated.

Thanks.

Best regards,

Zhishen

xml_h3a_bin.zip

  • 0
    TI__Mastermind 24525 points

    Hello Zhishen,

    h3a_merge function is not currently doing anything. It is meant to be used in future when ISP gives 3 H3A images from long, short and very short exposures. In that case the three H3A images will have to be merged to create a single HDR H3A image. This is similar to how HDR merge happens using thresholds on full resolution image.

    >>For green, why add 1 after 'sum_gr + sum_gb + n_pix'? Why right shift after '(sum_gr + sum_gb + n_pix + 1 )'?

    This is because in Bayer pattern there are 2x green pixels compared to red and blue. That is why an extra division by 2 is needed to get the correct green mean.

    Write_h3a_image can write h3a data to file. Which h3a data is writen to file? Original h3a data or after processed by h3a_merge?

    Original, unprocessed h3a buffer generated by ISP gets written to file.

    Regards,

    Mayank

  • 0 in reply to Mayank Mangla
    Intellectual 660 points

    Hi Mayank,

    Thanks for your reply.

    Question2

     h3a_data[j * n_col + i].red  = (sum_r + (n_pix>>1)) / n_pix;
     h3a_data[j * n_col + i].blue = (sum_b + (n_pix>>1)) / n_pix;
     h3a_data[j * n_col + i].green = ((sum_gr + sum_gb + n_pix + 1 )>>1) / n_pix; //bug_fix: rounding

    The fomulars above are used to calculate mean value for each channel. H3A block can store both saturated and unsaturated pixels sum for each channel. 

    For r and b, why sum needs to add (n_pix>>1)? Why it's devided by n_pix? n_pix is pixel quantity of each window (paxel).

    For g, it's devided by 2 as you mentioned that average gr and gb. Why add 'n_pix+1' to sum gr and gb? Why it's devided by n_pix?

    Additional question about H3A,.

    The frame data will pass through a LUT block before inputing to H3A block. If I disable this LUT in dcc file, what the bitwidth is for H3A input data? 16bit?

    If enable it, what the bitwidth is for H3A input data? 10bit?

     

    Thanks.

    Best regards,

    Zhishen

  • 0 in reply to Zs lei
    TI__Mastermind 24525 points

    + (n_pix>>1) is done to get round instead of truncation when red/green/blue sum is divided by n_pix.

    H3A input bitwidth is 16, but H3A can read only 10 bits. LUT maps 16bit to 10bits.

  • 0 in reply to Mayank Mangla
    Intellectual 660 points

    Hi Mayank,

    Let's continue to discuss H3A topics. You mentioned 'H3A can read only 10bits'. It's HW constraint or SW is designed to process 10bits?

    Attachment is H3A data captured with single camera demo app. I disabled LUT in xml file. It seems H3A data I captured is 16bit. Is it possible that I modify function parse_h3a_out to fit 16bit data?

    Thanks.

    Best regards,

    Zhishenh3a_0000.zip

    Fullscreen 5314.AR0233_h3a_mux_luts_dcc.xml Download 
    <?xml version="1.0" encoding="utf-8"?>
<VISS_H3A_MUX_LUTS_CFG xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <!--this is comment-->
    <dcc_name>viss_h3a_mux_luts_cfg</dcc_name>
    <dcc_header>
        <camera_module_id>     233 </camera_module_id>
        <dcc_descriptor_id>    2 </dcc_descriptor_id>
        <algorithm_vendor_id>  1 </algorithm_vendor_id>
        <tunning_tool_version> 0 </tunning_tool_version>
    </dcc_header>
    <!--=======================================================================-->
    <typedef>
        <iss_h3a_mux_luts type="struct">
            <enable type="uint16"> </enable> <!-- enable -->
            <num_luts type="uint16"> </num_luts> <!-- number of LUTs (0 ~ 3) -->
            <h3a_mux_luts type="uint16[3][639]"> </h3a_mux_luts> <!-- H3A LUTs -->
        </iss_h3a_mux_luts>
    </typedef>
    <!--=======================================================================-->
    
    <use_case val="1023">
        <n-space>
            <region0 class="0">
                <gain             val="0" min="0" max="10240">  </gain>
                <exposure         val="1" min="0" max="10000000">  </exposure>
                <colortemperature val="2" min="0" max="10000">  </colortemperature>
            </region0>
        </n-space>
        <parameter_package>
            <iss_h3a_mux_luts_cfg type="iss_h3a_mux_luts">
            {
                0, //enable
                1, //number of LUTs
                {
                    {#include "AR0233_lut_h3a_16to10_g0.70_global.txt"},
                    {#include "AR0233_lut_h3a_16to10_g0.70_global.txt"},
                    {#include "AR0233_lut_h3a_16to10_g0.70_global.txt"}
                },
            }
            </iss_h3a_mux_luts_cfg>
        </parameter_package>
    </use_case>
    
    <!--=====================================================================-->
</VISS_H3A_MUX_LUTS_CFG>

  • 0 in reply to Zs lei
    TI__Mastermind 24525 points

    Hello Zhishen,

    H3A hardware can operate only on 10-bit data. If the input is 16-bit, H3A has to be configured to pick a bit range i.e. [0-9] or [2-11] etc.

    This is not to be confused with H3A output. The output is a sum of pixel values in a window. The sum is 16-bit. This is what gets processed by the function parse_h3a.