dm355 AEW statistics for image sensor

I don't know if your problem got solved, but I am sincerely seeking some help here with the H3A module.

I feel that the black-window data is interfering with the regular-row data in my case. The accumulator values that I am getting far exceed the expected maximum (1023 * number of pixel per color-channel per subsample). I was wondering if you have experienced such a thing in the past.

I would appreciate any related ideas.

Unfortuneately my problem has still not been solved. I raised the issue with Ti support and never got a reply. I then went to my local FAE to elevate the issue and I was told that I needed to double check my data paths to make sure that they were aligned correctly. If one of the processing blocks were shifted then it could saturate the aew stats hardware. 

I haven't gone through our setup since this reply - and while it has some merit, I'm skeptical ... I've spent a lot of time trying to align everything - and I can't see a scenerio that would only effect the aew block.

if you have any questions feel free to ask, I've been through this so many times... maybe I'll see the answer by working out the issues you are having.

The only caveat is that I'm going to be at ESC boston next week so my availability will be limited until Thursday. 

If anyone else is going to ESC - feel free to stop by booth 222, we will be there both show days demostrating our designs. 

 Steve Berry - Gravity Performance

Couple of questions:

I was wondering if your talk about data-paths was in context of software. If yes, how do you think the processing blocks can get shifted. At the moment, I am trying to use AEW right after I capture an image using the CCDC controller. IPIPE and JPEG encoding are next in the chain.

Would you have any other recommendation as far as the ordering is concerned?

Thanks.

It seems there is a document called "VPFE Programmers Reference Guide" that as the information missing in the datasheet.
I have the same problem here on a DM365 :

Some zone have a statistic much higher than the theoretical maximum, others get 0, and others get -1.
I assumed the results for a zone where packed as four integers, one for each bayer color.

I don't know how to configure the black window, since there is no indication about it in the datasheet in my possession.
May be we could post our settings here ?

Here is my code. Currently i am testing it on a 2048*1536 picture.
I use 9 windows (3x3), each windows is 256x256, and I use a vertical and horizontal skip of 2.

void aewb_cfg_init(struct aew_configuration * cfg, int w, int h)
{
    int width, height;

    cfg->alaw_enable = H3A_AEW_DISABLE;
    cfg->out_format = AEW_OUT_SUM_ONLY;
    cfg->sum_shift = 0;
    cfg->saturation_limit = 0x3FF;
    cfg->hmf_config.enable = H3A_AEW_DISABLE;

    /* try to use 3x3 256x256 windows */
    width = 256;
    while(width * HORZ_WINDOW_CNT > w) {
        width--;
    }

    height = 256;
    while(height * VERT_WINDOW_CNT > h) {
        height--;
    }

    cfg->window_config.width = width;
    cfg->window_config.height = height;
    cfg->window_config.hz_start = (w - HORZ_WINDOW_CNT*width)/2;
    cfg->window_config.vt_start = (h - VERT_WINDOW_CNT*height)/2;
    cfg->window_config.hz_cnt = HORZ_WINDOW_CNT;
    cfg->window_config.vt_cnt = VERT_WINDOW_CNT;
    cfg->window_config.hz_line_incr = 2;
    cfg->window_config.vt_line_incr = 2;
    cfg->blackwindow_config.height = 2;
}

Steve et all,

Not sure if you are aware, bu there are more robust AEW documents which require an NDA.  These hardware blocks can be quite complex, and hece broad market support is primarily via the driver binaries and docs provided via DVSDK; for customers that may need to dig deeper and understand the inner workings of these blocks, there are additional docs requiring an NDA (and possibly some training, though not sure about this).  You will need to work with your local sales representative to get access to these docs: http://focus.ti.com/general/docs/salesrep/salesrep.tsp?DCMP=TIHomeTracking&HQS=Other+OT+home_b_salesrep

I am sorry to hear so many of our customers are having problems interpreting this data; personally, I do not know much about AEW/H3A blocks myself.  But hopefully I can help point you in the right direction.

Hi Juan,

I have the document you are referring to - I needed that just to interpret the format of the AEW data which didn't appear anywhere else. This might have changed with the newer releases of SDK's, but we don't have the time to port to them.

Juan,

I also have the more robust VPFE reference. Maybe the document has changed since we last retrieved it.

I would contact the sales representative for possible updates, since the proper working of AEW is quite essential for the project I am working on. It would be great if you could refer me to one of your colleagues at TI, who is well-versed in AEW hardware and its usage.

Thanks,

Karan

Karan - no I was referring to the setup of the CCDC and the IPIPE. You have to tell the CCDC which pins your sensor is on and an error there can shift your image data. Also in the IPIPE there are several places where you have to tell the hardware what bits are valid. An error in any of these settings could cause the AEW to receive data that will over flow the accumulators. Or at least that is the theory that Ti asked me to look into.

Hi Steve,

If you have the NDA docs and still require assistance with AEW block you should probrably work with your local FAE to identify the right expert within TI to help you resolve this issue.  It does not hurt to post here as well, but I imagine most of the folks here (including myself) are not very familiar with this particular hardware block or the NDA docs.  I just want to make sure you are aware of the support channels available to you and how to make use of them.

Steve - I can take a look at CCDC. But looking into IPIPE for resolving discrepancies with AEW data doesn't make sense to me. I look at this whole process as divided into two halves: exposure-stage and encoding-stage. Capturing of image as well as statistics using CCDC and AEW takes place in the exposure stage. IPIPE comes much later, and AEW statistics will come regardless of whether IPIPE is being used or not. Don't you think so, or did guys at TI think otherwise?

Karan Batra said:

I would contact the sales representative for possible updates, since the proper working of AEW is quite essential for the project I am working on. It would be great if you could refer me to one of your colleagues at TI, who is well-versed in AEW hardware and its usage.

Steve,

Have you tried going thru your local FAE to identify the TI expert on AEW?  I will try to identify the proper person on my end as well, but at minimum I would like to touch base with your local FAE (??) so that we are not duplicating effort and are providing a consistent message back to you.

Bandini,

I tried your configuration for the AEW driver. Some basic math suggests that all accumulators (assuming each pixel is 10-bit) would saturate to the possible maximum of 0xFFFF (accumulators are 16-bit), which is what happened when I experimented with your configuration. Are you sending 8 bit or 10 bit into the AEW block?

Here is the math that I work out before I tried this configuration. If each window is 256x256 and vertical and horizontal skip are both 2, then the number of sub-sampled 2x2 blocks would be way too larger (128 * 128 = 16384 in this case). This is surely going to saturate all accumulators (16384 * 1023 = 16760832) and the data wouldn't even be useful.

Let me know if this analysis clicks with yours.

Karan

I knew the result was 16 bytes long, but I assumed it was  4 32 bit integer.
With appropriate shifting (128 x 128 gives a 14 bit shift) I finally obtain some valuable results.
However,  I still have the following issue : I have nine windows (3x3) and if we start with windows 0, then :

statistics for windows 3 and 7 are zero.

the windows seems to be misplaced. I did an autoexposure algorithm on windows for (central window in
a 3x3 scheme) and it seems the data for this window comes from what I would expect to be window 3.

  0  |  1  |  2
-----|-----|-----
  3  |  4  |  5 
-----|-----|-----
  6 |  7  |  8

There must be something going on here with the black window, but since nobody will tell us on this forum,
I will have to wait for my TI contact to do his job...

Bandini,

Each window contributes to 18 bytes in the buffer returned by the driver. The macro WINDOW_SIZE in AEW driver-code confirms that. Every entity in this 18-byte chunk is 2-byte long. So we have a total of 9 entities. The point where you might be going wrong is that you are not considering saturator-accumulators. There are 4 subsample-accumulators, 4 saturator-accumulators, and 1 unsaturated block-counter. You can look at this example in DVSDK - $(DVSDK_ROOT)/$(PSP_VERSION)/examples/dm355/h3a/aew_example.txt.

So there are 8 16-bit integers and not "4 32 bit integers" if we don't consider the unsaturated block-counter for the moment.

~ Karan

Ok, I've finally made some progress with this problem. 

It seems that because I hooked my sensor up LSB justified instead of MSB - the stats engine was not getting all of my input data bits (the high order bits were not being counted). I had to fix this with a kernel mod - its one of the registers that you can't change from an application - its hard coded in the AEW driver.

I don't have the exact register name in front of me, but I'll post my change later on - perhaps it will help some of you. 

Essentially I had to tell the H3A to use bits 13:2 instead of where my sensor is attached 11:0. Even though this works, I don't really understand why, unless there is some sign extension going on in the hardware.

Even after finally getting a linear response from the sensor, the parameters to the H3A seemed to also be pretty picky. Some horizontal and vertical window counts only gave me garbage (a constant!) but others worked just fine.

that far ive seen in register definitions you can shift down incoming sensor values - or in other words select up to 10 consecutive bits from the incoming data.

there is further indication of some a-law converter (logarithmic down scaling, e.g. from 10 bits to 8 bits).

as it comes to window data decoding from the driver provided buffers so far ive only seen samples that deal with exactly 8 windows.

this probably represents sort of a gap in the unit and driver test suite. software things that got never tested might only work up to some degree.

if the data sheet would be more detailed on that topic then we would probably understand why it wont work for you.

hi, Karan

Assume each window is 256X256 and vertical and horizontal skip are both 2,

then there are 16384 sub-sampling 2X2 block ,would you like to tell me how the

Sub Sample Accum[0], Sub Sample Accum[1], Sub Sample Accum[2], Sub Sample Accum[3] are gotten

in the AE/AWB packet format ? Is accumulate the four pixels of 2X2 block or only one pixel of 2X2 block in the window?

Thank you for your reply.

Do you have the VPFE document? This document explains how the accumulators work.

TI requires you to sign an NDA to receive this document.

-Karan