Hello,
There are many "standard" resolutions defined in the IPNC_RDK. There is also a macro for FVID2_STD_CUSTOM.
How is this custom resolution defined and used throughout the usecases and drivers?
Thanks,
Mechi
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.
Hello,
There are many "standard" resolutions defined in the IPNC_RDK. There is also a macro for FVID2_STD_CUSTOM.
How is this custom resolution defined and used throughout the usecases and drivers?
Thanks,
Mechi
Hi Brijesh,
I made the correct changes in issdrv_mt9j003Api.c and issdrv_mt9j003_config.h. My new resolution "masquerades" as the "default" 1080p. Everywhere that 1920x1080 is in the code (for width and height) I substituted 1200x1200 (binning from 2400x2400) - in the links, usecase, and iss driver.
But this is not a very nice solution. There were many, many substitutions. I was asking if there's somewhere that I can define my custom resolution including WIDTH and HEIGHT and it would be recognized throughout the IPNC RDK?
Thanks,
Mechi
I haven't figured out how to attach files.
The changes are in the following files:
ipnc_rdk/ipnc_mcfw/demos/mcfw_api_demos/multich_usecase/ti_mcfw_ipcbits.c
ipnc_rdk/ipnc_mcfw/demos/mcfw_api_demos/multich_usecase/ti_mcfw_ipnc_main.c
ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_m3vpss/camera/cameraLink_drv.c
ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_m3vpss/capture/captureLink_drv.c
ipnc_rdk/ipnc_mcfw/mcfw/src_bios6/links_m3vpss/system/system_m3vpss.c
ipnc_rdk/ipnc_mcfw/mcfw/src_linux/links/ipcBitsOut/ipcBitsOutLink_tsk.c
ipnc_rdk/ipnc_mcfw/mcfw/src_linux/mcfw_api/usecases/multich_tristream_fullfeature.c
ipnc_rdk/ipnc_mcfw/mcfw/src_linux/mcfw_api/ti_vdis.c
ti_tools/iss_03_80_00_00/packages/ti/psp/devices/mt9j003/src/issdrv_mt9j003Api.c
ti_tools/iss_03_80_00_00/packages/ti/psp/devices/mt9j003/issdrv_mt9j003_config.h
ti_tools/iss_03_80_00_00/packages/ti/psp/iss/drivers/capture/src/issdrv_captureApi.c
ti_tools/iss_03_80_00_00/packages/ti/psp/iss/drivers/capture/src/issdrv_capturePriv.h
The actual sensor settings are in issdrv_mt9j003_config.h.
Registers are set in order to get an ROI of 2400x2400 centered in the middle of the sensor for our fish-eye lens and then binning to yield 1200x1200 is as follows:
// default - was 1080p30fps - changed to 1200x1200 - 20fps
UInt32 SensorConfigScript[69][3] = {
{0x030A, 2, 0x00},
{100, 0, 100},
{0x030A, 2, 0x01},
{100, 0, 100},
{0x0100, 2, 0x00},
{100, 0, 100},
{0x0300, 2, 0x3},
{0x0302, 2, 0x1},
{0x0304, 2, 0x1},
{0x0306, 2, 32}, //48}, // pll multiplier
{0x0308, 2, 0x0C},
{0x030A, 2, 0x01}, // op_sys_clk_divider
{100, 0, 100},
{0x0104, 2, 0x01},
{0x3064, 2, 0x805},
{0x3016, 2, 0x121},
{0x0344, 2, 840}, //0x012},
{0x0348, 2, 3239}, //0xF13},
{0x0346, 2, 50}, //0x8},
{0x034A, 2, 2449}, //0x879},
{0x3040, 2, 0x28C3}, // low power + summing
{0x0400, 2, 0x0002},
{0x0404, 2, 0x0010},
{0x034C, 2, 1200}, //0x782},
{0x034E, 2, 1200}, //0x43A},
{0x0342, 2, 2200}, //0x0881},
{0x0340, 2, 1832}, //0x04c9},
{0x0202, 2, 1575}, //1212}, // coarse integration
{0x3014, 2, 0x0603},
{0x3010, 2, 0x009C},
{0x3018, 2, 0x0000},
{0x30D4, 2, 0xB080},
{0x306E, 2, 0x90B0},
{0x3E00, 2, 0x0010},
{0x3070, 2, 0x0000}, // 2}, //test pattern
{0x31C6, 2, 0x8400},
{0x3E00, 2, 0x0010},
{0x3EDC, 2, 0xD8E4},
{0x3178, 2, 0x70}, //0x0070},
{0x3170, 2, 0x00E5},
{0x3ECC, 2, 0x0FE4},
{0x316C, 2, 0x0429},
{0x3174, 2, 0x8000},
{0x3E40, 2, 0xDC05},
{0x3E42, 2, 0x6E22},
{0x3E44, 2, 0xDC22},
{0x3E46, 2, 0xFF00},
{0x3ED4, 2, 0xF998},
{0x3ED6, 2, 0x9789},
{0x3EDE, 2, 0xE438},
{0x3EE0, 2, 0xA43F},
{0x3EE2, 2, 0xA4BF},
{0x3EEC, 2, 0x1C21},
{0x3056, 2, 0x1040},
{0x3058, 2, 0x1040},
{0x305A, 2, 0x1040},
{0x305C, 2, 0x1040},
{0x301A, 2, 0x0010},
{0x3064, 2, 0x0805},
{0x301E, 2, 0x00A8},
{0x0400, 2, 0x0000},
{0x306E, 2, 0x9080},
{0x31AE, 2, 0x0304},
{0x301A, 2, 0x001C},
{0x0104, 2, 0x00},
{0x0120, 2, 0x00},
{0x305e, 2, 0x1040},
{0x0202, 2, 1175}, //1175}, // coarse integration - why twice??
{10, 0, 0}
};
I would be interested if there's a way to specify this resolution, and register settings would yield it.
More important, though, is the ability to specify a custom resolution and it should be recognized throughout the IPNC_RDK. The changes that I had to make in the files above were basically just changing 1920x1080 to 1200x1200.
Thanks,
Mechi
Hi,
Sorry,I oversaw your reply you have already listed the modified files.
Can you pl. send us the files you modified?
You can click on the 'Use rich formatting' button after clicking on Reply button and then insert the files by clicking on the 'Insert/Edit Media' button.
regards,
Anand
I tried to attach a zip with all of the changed files.
As I've mentioned, I had to disable the SALDRE since it didn't work well with this resolution.
Another thing, even though I defined everywhere that I'm working with 1200x1200, the AEC seems to "think" that there's much black and therefore, when filming outside, the whole frame is totally saturated.
I hope you'll be able to help with this,
Thanks,
Mechi
Hi,
It looks like you have replaced all the instances of 1920 with 1200 in the mcfw code, but the only valid changes are in the following files:
All the other instances are used either for HDMI display or limit values.
Regarding the AE for 1200x1200 case, can you pl. use the following values in the 'Iss_Mt9j003UpdateExpGain()' fn in ..\ti_tools\iss_03_80_00_00\packages\ti\psp\devices\mt9j003\src\issdrv_mt9j003Api.c file to calculate the sensor integration time?
For 1200x1200 resolution, pixel clock = (10 * 32)/3 = 106 MHz and line_length_pck = 2200
PixelClock = 106; // MT9J_003_PIXEL_CLOCK;
LineLength = 2200;
regards,
Anand
Hi,
The pixel clock is computed as follows:
Pixel clock = (Master clock * pll_multiplier)/(pre_pll_clk_div * vt_pix_clk_div * vt_sys_clk_div);
And the line_lenth_pck (0x342) is the no of pixel clocks per line.
So the row tme = line_lenth_pck/Pixel clock.
The exposure time which is output by the AE algorithm is in terms of usec which you need to map to the no of lines (exposureTime/row time) of the sensor.
The max width is used for allocating the bit stream buffers in ipc bits out link so if you want to save on the memory you can go and change the value to 1200 otherwise there is no other side effect.
Can you pl. disable SALDRE and observe the video in out door light?
Can you send me the video clip where it becomes bright pink?
regards,
Anand
Hello Anand,
I really appreciate your explanations.
I went back to the original tri-stream full-feature usecase, 1920x1080. I did a NAND-scrub and burned the UBI_FileSystem, uImage, and uBoot files. Without SALDRE and also with SALDRE, here is the a frame captured from the camera. Attached is also a frame from my smartPhone - so you can see the way colors should be. TI's 2A engine - AutoExposure was set with average brightness at 60. AutoWhiteBalance gives worse colors, so it was disabled.
Our camera will have to work in bright sunlight, dusk, rain, etc. We must be able to work with all types of lighting conditions.
Here's the "real" colors:
Hi Anand'
I think I may have figured out why this "pink" problem occurs.
I wasn't using the original uImage when I took the previous pictures. I replaced with the original uImage, and the pictures were closer to the real color.
Then I put on the fish-eye lens that I will be using for the final camera, and without changing to the 1200x1200 driver, I got pictures with much pink. I think that since the camera "sees" alot of black on the sides of the actual picture, it tries to compensate and therefore the gains are raised - causing the pink. It would be nice to be able to define an ROI for the AEWB... But when I use my driver of 1200x1200, still I get the pink - which means that the AEWB is still taking into account all of the black surrounding area.
Below is from my smartPhone - the "real" colors (though the sky should be a bit bluer):
Here's the picture using the fish-eye lens with default usecase 1920x1080. I tried with/without SALDRE and lowering the brightness, which didn't help - since it's trying to compensate for the black areas.
Using the new driver that I defined 1200x1200 (and sent you the files) with the following change:
0x342 = 1300
and PixelClock = 106; // MT9J_003_PIXEL_CLOCK;
LineLength = 2200;
I thought that since the driver is 1200x1200, the black areas are much smaller and the picture would be better.
Video clip has 2 scenes which are shown in attached pictures.
Hi,
First can you make sure you get the 1080p use case working w.r.t AEWB?
I have tested the 1080p use case with Fish eye lens in the outdoor condition and AEWB is working fine.
Pl. find the snapshot attached.
I remember you mentioned the following files:
\ti_tools\iss_03_80_00_00\packages\ti\psp\iss\drivers\alg\2A\src\issdrv_algTIaewb.c
\ti_tools\iss_03_80_00_00\packages\ti\psp\iss\alg\aewb\ti2a\fd\inc\alg_ti_flicker_detect.h
\ti_tools\iss_03_80_00_00\packages\ti\psp\iss\alg\aewb\ti2a\ae\src\ae_ti.c
Did you make any changes in these files.
Also for 1080p you have to use PixelClock = 160; and LineLength = 2177;
You may run the pre built binaries from the IPNC RDK ver 3.8 release.
regards,
Anand
Hi,
I have tried 1200x1200 resolution on my side.
Pl. find my patch attached.
Refer to the 'Files_modified.txt' file for the list of files modified to support 1200x1200 resolution.
regards,
Anand
I have a few logs in which the AEWB data is printed. I will upload them.
When I covered up the sky in the picture, the bottom half of the picture is mostly OK.
The 3 attached logs are as follows:
2. changed brightness from 128 to 68
3. covered half of frame - as seen in picture above
Hello Anand,
I did exactly what you suggested (burning the original, default usecase into the NAND) and the results are in the post from Dec 29, 2014 11:57 AM. I did a NAND scrub and put in the original filesystem. I did it again yesterday with the same results.
The SALDRE gives me black/white screens overlaying the original frames - how is this to be stopped? It happened in the default usecase on the NAND.
I'm continuing in the thread about AEWB/SALDRE for custom resolutions - since the title question "How to define a new resolution" was basically answered in Anand's code that he sent.
I'm having an interesting problem of "motion lines" in the RAW frame.
Please see post http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/409837
Can this be related to the custom resolution of 1200x1200?
Are these lines coming from the SALDRE or some sort of DMVA code?
Thanks,
Mechi