TDA4VM: How to parse .bin file of H3A output?

Zs lei

Part Number: TDA4VM

Hi TI experts,

I used multi_cam app to capture and get .bin file of H3A output. I want to analyze this file to optimize my 2A algo. Could you help me to understand the data field definition? Please refer the .bin and H3A xml files I attached. The sensor output resolution is 1920x1280.

For my understanding,

1. The initial 64 bytes of this .bin file may be the header.

2. The data should be the mapping to RAWFE H3A AE/AWB Packet Format. I used Sum-Only Mode, so the data should be mapping to the format which is showed in TRM Table 6-5335 (page 5803-5804)

Please correct me if I was wrong and help explain the data definition of .bin file.

Thanks.

Best regards,

Zhishen

Fullscreen 2465.AR0233_viss_h3a_aewb_cfg.xml Download

<?xml version="1.0" encoding="utf-8"?>
<VISS_H3A_AEWB_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_aewb_cfg</dcc_name>
	<dcc_header>
		<camera_module_id>     233 </camera_module_id>
		<dcc_descriptor_id>   3 </dcc_descriptor_id>
		<algorithm_vendor_id>  1 </algorithm_vendor_id>
		<tunning_tool_version> 0 </tunning_tool_version>
	</dcc_header>
	<!--=======================================================================-->
    <typedef>
        <iss_h3a_grid_size type="struct">
		  <enable type="uint8"> </enable> <!-- enable h3a aewb-->
		  <mode type="uint8"> </mode> <!-- 0 = SUM_SQ, 1=MINMAX, 2=SUM_ONLY-->
          <v_start type="uint16"> </v_start> <!-- Paxel_0 Start Coordinate Y in Pixels -->
          <h_start type="uint16"> </h_start> <!-- Paxel_0 Start Coordinate H in Pixels -->
          <v_size type="uint8"> </v_size> <!-- Paxel Height in Pixels -->
          <h_size type="uint8"> </h_size> <!-- Paxel Width in Pixels -->
          <v_count type="uint8"> </v_count> <!-- number of vertical paxels -->
          <h_count type="uint8"> </h_count> <!-- number of horizontal paxels -->
          <v_skip type="uint8"> </v_skip> <!--   vertical subsampling factor (0-15) -->
          <h_skip type="uint8"> </h_skip> <!--  horizontal subsampling factor (0-15) -->
          <saturation_limit type="uint16"> </saturation_limit> <!--  saturation_limit (0-1023) -->
          <blk_win_numlines type="uint16"> </blk_win_numlines> <!--  Win Height for the single black line of windows (2-256)-->
          <blk_row_vpos type="uint16"> </blk_row_vpos> <!--  Vertical Position of Black Row -->
          <sum_shift type="uint8"> </sum_shift> <!--  Sum Shift (0-15) -->
          <ALaw_En type="uint8"> </ALaw_En> <!--  A Law Enable (0/1) -->
          <MedFilt_En type="uint8"> </MedFilt_En> <!--  Median Filter Enable (0/1) -->
		</iss_h3a_grid_size>
    </typedef>
	<!--=======================================================================-->
	
	<use_case val="1023">
		<n-space>
			<region0 class="0">
				<gain                      val="0" min="0" max="26132">  </gain>
				<exposure              val="1" min="0" max="10000000">  </exposure>
				<colortemperature val="2" min="0" max="10000">  </colortemperature>
			</region0>
		</n-space>
	    <parameter_package>
            <h3a_aewb_dcc type="iss_h3a_grid_size">
              {
			      1, //enable

			      2, //mode

			      2, //v_start
			      32, //h_start

			      64, //v_size
			      58, //h_size

                  16, // v_count
                  32, // h_count

			      8, //v_skip			      
				  8, //h_skip

			      1000, //saturation_limit

				  2, //blk_win_numlines
                  1278,     // blk_row_vpos:     u16

				  2, //sum_shift

				  0, //ALaw_En
				  0, //MedFilt_En
              }
            </h3a_aewb_dcc>
	    </parameter_package>
	</use_case>
	
	<!--=====================================================================-->
</VISS_H3A_AEWB_CFG>

D65_1368lux_6481K.zip

over 4 years ago

0 Gang Hua over 4 years ago

TI__Guru 60120 points

Hi Zhishen,

Yes, you are correct.

Please refer to the function "parse_h3a_out( )" in "imaging/kernels/arm/vx_aewb_target.c" for more details.

Best,
Gang

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

Thanks for your reply.

For "parse_h3a_out( )", the following part,

if ((cur_addr - h3a_buf) % 32 == 16)
        {
            cur_addr += 16;
        }

Could you help explain the implication?

The h3A mode is Sum-Only. How to access Saturator Accum []? How to access Unsaturated count?

Thanks.

Best regards,

Zhishen

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi Zhishen,

That is for skipping the 0 padding in H3A data packet.

Please refer to the table 5335 "H3A AE/AWB Packet Format for Sum-Only Mode" you copied above for the details of the data packet.

Best,
Gang

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

I analyzed .bin file to verify Table 6-5335. I still have some questions. The attachment is the HEX show of .bin file.

The started 64 bytes may be 'header' of this .bin file. Are there details of the 'header'?
According to Table 6-5335, 1 window occupies 32 bytes. From snapshot of .bin file, I think window0 is from address 0x40 to 0x4f which occupy 16 bytes. Is there conflict?
Please refer to the snapshot. My understanding is that window0 to 8 data is from address 0x40 to 0xbf. Unsaturated block count for window0 to window8 is 0xc0 to 0xcf. Please correct me if I was wrong.

Thanks.

Best regards,

Zhishen

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi Zhishen,

H3A H/W follows the packet format table exactly and does not generate any header.
I have not heard about any issue with H3A bin files captured on TDA4 EVM via single or multi cam app in the past 2 years.

Do you get the bin file in a different way or use an old version of PSDK?

Best,
Gang

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

Please refer to the zip file I attached before. You can find the bin file I captured with multi camera app. The PSDK I used is 7.1.

Best regards,

Zhishen

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi ZS,

That makes sense.
Multi-cam camera app must have added a header of 64 bytes while saving to files.
You may ignore those 64 byes completely.
If you use the single-cam app, there is no header at all.

H3A H/W output does not have any header.
If you have any doubts about H3A output buffer content, please refer to the "parse_h3a_out( )" function in "vx_aewb_target.c" under "imaging".

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

Could you help check my question 2 and 3?

Best regards

Zhishen

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi ZS,

You are correct on both; so I don't need to correct anything.

Please follow the content of Table 6-5335.

(2) 4 rows of 32-bit words = 16 bytes

(3) 8 windows x 16 bytes/window = 128 bytes

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

Please refer to Table 6-5335 again. In the left side, VISS_RAWFE_H3A_AEWBUFST is the started address in SDRAM for H3A buffer, right? Windows 0 data start from here. Windows1 data start VISS_RAWFE_H3A_AEWBUFST+32bytes. Therefore, I thought single window occupy 32 bytes. But it seems like a conflict to the bin file I showed. E.g., from sanpshot, window0 data is from 0x40 to 0x4f and window1 data is from 0x50 to 0x5f which are 16 bytes. That is what I confused.

A further question is based on the one above. I assume 16 bytes per window so 8x16+16=144 bytes per 8-window. My H3A setting is:

16, // v_count
32, // h_count

Therefore, valid H3A data is [(32x16)/8] x144 = 9216 bytes

Back to .bin file, valid data is from 0x40 to 0x2680 so it occupies 9792 bytes. They are different. Could you help check it?

Thanks.

Best regards,

Zhishen

Fullscreen 3005.AR0233_viss_h3a_aewb_cfg.xml Download

<?xml version="1.0" encoding="utf-8"?>
<VISS_H3A_AEWB_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_aewb_cfg</dcc_name>
	<dcc_header>
		<camera_module_id>     233 </camera_module_id>
		<dcc_descriptor_id>   3 </dcc_descriptor_id>
		<algorithm_vendor_id>  1 </algorithm_vendor_id>
		<tunning_tool_version> 0 </tunning_tool_version>
	</dcc_header>
	<!--=======================================================================-->
    <typedef>
        <iss_h3a_grid_size type="struct">
		  <enable type="uint8"> </enable> <!-- enable h3a aewb-->
		  <mode type="uint8"> </mode> <!-- 0 = SUM_SQ, 1=MINMAX, 2=SUM_ONLY-->
          <v_start type="uint16"> </v_start> <!-- Paxel_0 Start Coordinate Y in Pixels -->
          <h_start type="uint16"> </h_start> <!-- Paxel_0 Start Coordinate H in Pixels -->
          <v_size type="uint8"> </v_size> <!-- Paxel Height in Pixels -->
          <h_size type="uint8"> </h_size> <!-- Paxel Width in Pixels -->
          <v_count type="uint8"> </v_count> <!-- number of vertical paxels -->
          <h_count type="uint8"> </h_count> <!-- number of horizontal paxels -->
          <v_skip type="uint8"> </v_skip> <!--   vertical subsampling factor (0-15) -->
          <h_skip type="uint8"> </h_skip> <!--  horizontal subsampling factor (0-15) -->
          <saturation_limit type="uint16"> </saturation_limit> <!--  saturation_limit (0-1023) -->
          <blk_win_numlines type="uint16"> </blk_win_numlines> <!--  Win Height for the single black line of windows (2-256)-->
          <blk_row_vpos type="uint16"> </blk_row_vpos> <!--  Vertical Position of Black Row -->
          <sum_shift type="uint8"> </sum_shift> <!--  Sum Shift (0-15) -->
          <ALaw_En type="uint8"> </ALaw_En> <!--  A Law Enable (0/1) -->
          <MedFilt_En type="uint8"> </MedFilt_En> <!--  Median Filter Enable (0/1) -->
		</iss_h3a_grid_size>
    </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>
            <h3a_aewb_dcc type="iss_h3a_grid_size">
              {
			      1, //enable

			      2, //mode

			      2, //v_start
			      32, //h_start

			      64, //v_size
			      58, //h_size

                  16, // v_count
                  32, // h_count

			      8, //v_skip			      
				  8, //h_skip

			      1000, //saturation_limit

				  2, //blk_win_numlines
                  1278,     // blk_row_vpos:     u16

				  2, //sum_shift

				  0, //ALaw_En
				  0, //MedFilt_En
              }
            </h3a_aewb_dcc>
	    </parameter_package>
	</use_case>
	
	<!--=====================================================================-->
</VISS_H3A_AEWB_CFG>

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi ZS,

>> Windows1 data start VISS_RAWFE_H3A_AEWBUFST+32bytes

The "+32" looks like copy/paste error since in the other 2 modes each window has 32 bytes.
Please focus on the contents of the table on the right side: there are 4 rows of 32-bit words --> 16 bytes.
The parser code in PSDK makes this clear as well.

>> Therefore, valid H3A data is [(32x16)/8] x144 = 9216 bytes

Again, please follow the table and parser code.
We discussed above that there are extra 0 padding included in the data.
Therefore, the actual size is larger than 9216.

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

I checked my bin file again.

For "parse_h3a_out( )", the following part,

if ((cur_addr - h3a_buf) % 32 == 16)
        {
            cur_addr += 16;
        }

I cannot match 0 padding in my bin file. From address 0x40 to 0x2680, there are not continunous '00' padding. Besides some padding in header, the next one is after 0x2680 (valid data is from 0x40 to 0x2680). Could you help check it if code had bug?

For the difference between actual valid data size (9792 bytes) and calculating value (9216 bytes), I think it may make sense.

[(9792-9216)/144]*8=32

32 is same as H_count. Therefore, valid data size of this bin file is for 32 (H)x17(V) which equals to 9792 bytes

[(32x17)/8]*144=9792 bytes

Best regards,

Zhishen

+1 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi ZS,

Don't worry; the code is correct and has been used and tested for more than 15 years by thousands of customers.
The relevant information for customers is the parser code output of R/G/G/B sums.

You are correct that there are 32 (8x) windows on each row, so there is no 0 padding in between.
There are 16 rows of data for normal windows that you actually use and 1 additional row of black windows at the end (see 6.10.4.3.4.6.6.2).
The black row is only useful for very old sensors from more than 15 years ago, but H/W still require additional buffer size for output.
So, the parser code ignores the black row completely.

I am curious about what you would really need from our support.
We try to provide high level abstraction for users in order to shield them from irrelevant complexity.
The parser code is where you can get all the meaningful H3A output information without worrying about low level H/W details.
Do you need to do something special such as safety review?

0 Zs lei over 4 years ago in reply to Gang Hua

Intellectual 660 points

Hi Gang,

Thanks for your explanation.

I have expressed my purpose while I was asking this question. I want to analyze this file to optimize my 2A algo. I have an idea to make a tool to analyze and tune 2A performance. Parsing H3A output is one function of it.

Best regards,

Zhishen

0 Gang Hua over 4 years ago in reply to Zs lei

TI__Guru 60120 points

Hi ZS,

No worries then; you can ignore all low level details such as padding and black row.

The parser code is correct for you to use and for 2A you only need the RGGB sums from the parser code.

Processors

Processors forum

TDA4VM: How to parse .bin file of H3A output?