Hi Laurent, 2012/9/28 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: > Hi Enric, > > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: >> 2012/9/28 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> >> 2012/9/27 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: >> >> >> 2012/9/26 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: >> >> >> > On Wednesday 26 September 2012 09:57:53 Enric Balletbò i Serra >> >> >> > wrote: >> >> >> > >> >> >> > [snip] >> >> >> > >> >> >> >> You had reason. Checking the data lines of the camera bus with an >> >> >> >> oscilloscope I see I had a problem, exactly in D8 /D9 data lines. >> >> >> > >> >> >> > I'm curious, how have you fixed that ? >> >> >> >> >> >> The board had a pull-down 4k7 resistor which I removed in these lines >> >> >> (D8/D9). The board is prepared to accept sensors from 8 to 12 bits, >> >> >> lines from D8 to D12 have a pull-down resistor to tie down the line by >> >> >> default. >> >> >> >> >> >> With the oscilloscope I saw that D8/D9 had problems to go to high >> >> >> level like you said, then I checked the schematic and I saw these >> >> >> resistors. >> >> >> >> >> >> >> Now I can capture images but the color is still wrong, see the >> >> >> >> following >> >> >> >> image captured with pipeline SENSOR -> CCDC OUTPUT >> >> >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-000001.pnm >> >> >> >> >> >> >> >> Now the image was converted using : >> >> >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-000001.bin >> >> >> >> img-000001.pnm >> >> >> >> >> >> >> >> And the raw data can be found here: >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-000001.bin >> >> >> >> >> >> >> >> Any idea where I can look ? Thanks. >> >> >> > >> >> >> > Your sensors produces BGGR data if I'm not mistaken, not GRBG. >> >> >> > raw2rgbpnm doesn't support BGGR (yet), but the OMAP3 ISP preview >> >> >> > engine >> >> >> > can convert that to YUV since v3.5. Just make your sensor driver >> >> >> > expose >> >> >> > the right media bus format and configure the pipeline accordingly. >> >> >> >> >> >> The datasheet (p.10,11) says that the Pixel Color Pattern is as >> >> >> follows. >> >> >> >> >> >> <------------------------ direction >> >> >> n 4 3 2 1 >> >> >> .. GB GB GB GB >> >> >> .. RG RG RG RG >> >> >> >> >> >> So seems you're right, if the first byte is on the right the sensor >> >> >> produces BGGR. But for some reason the mt9v032 driver uses GRBG data. >> >> > >> >> > You can change the Bayer pattern by moving the crop rectangle. That how >> >> > the mt9v032 driver ensures a GRBG pattern even though the first active >> >> > pixel in the sensor array is a blue one. As the MT9V034 first active >> >> > pixel >> >> > is located at different coordinates you will have to modify the crop >> >> > rectangle computation logic to get GRBG. >> >> >> >> Please, could you explain how to do this ? I'm a newbie into image >> >> sensors world :-) >> > >> > Let's assume the following Bayer pattern (left to right and top to bottom >> > direction). >> > >> > | 1 2 3 4 5 6 7 8 ... >> > >> > ---------------------- >> > 1| G R G R G R G R ... >> > 2| B G B G B G B G ... >> > 3| G R G R G R G R ... >> > 4| B G B G B G B G ... >> > 5| G R G R G R G R ... >> > 6| B G B G B G B G ... >> > 7| G R G R G R G R ... >> > 8| B G B G B G B G ... >> > .| ................... >> > >> > If you crop the (1,1)/4x4 rectangle from that sensor you will get >> > >> > | 1 2 3 4 >> > >> > ---------- >> > 1| G R G R >> > 2| B G B G >> > 3| G R G R >> > 4| B G B G >> > >> > which is clearly a GRBG pattern. If you crop the (2,1)/4x4 rectangle you >> > will get >> > >> > | 2 3 4 5 >> > >> > ---------- >> > 1| R G R G >> > 2| G B G B >> > 3| R G R G >> > 4| G B G B >> > >> > which is now a RGGB pattern. The pattern you get out of your sensor thus >> > depends on the crop rectangle position. >> >> Many thanks for the explanation. I'm learning a lot with your explanations >> :-) >> >> >> Maybe is related with following lines which writes register 0x0D Read >> >> >> Mode (p.26,27) and presumably flips row or column bytes (not sure >> >> >> about this I need to check) >> >> >> >> >> >> 334 /* Configure the window size and row/column bin */ >> >> >> 335 hratio = DIV_ROUND_CLOSEST(crop->width, format->width); >> >> >> 336 vratio = DIV_ROUND_CLOSEST(crop->height, format->height); >> >> >> 337 >> >> >> 338 ret = mt9v032_write(client, MT9V032_READ_MODE, >> >> >> 339 (hratio - 1) << >> >> >> MT9V032_READ_MODE_ROW_BIN_SHIFT | >> >> >> 340 (vratio - 1) << >> >> >> MT9V032_READ_MODE_COLUMN_BIN_SHIFT); >> >> >> >> >> >> Nonetheless, I changed the driver to configure for BGGR pattern. Using >> >> >> the Sensor->CCDC->Preview->Resizer pipeline I captured the data with >> >> >> yavta and converted using raw2rgbpnm program. >> >> >> >> >> >> ./raw2rgbpnm -s 752x480 -f UYVY img-000001.uyvy img-000001.pnm >> >> >> >> >> >> and the result is >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-000002.pnm >> >> >> http://downloads.isee.biz/pub/files/patterns/img-000002.bin >> >> >> >> >> >> The image looks better than older, not perfect, but better. The image >> >> >> is only a bit yellowish. Could be this a hardware issue ? We are close >> >> >> to ... >> >> > >> >> > It's like a white balance issue. The OMAP3 ISP hardware doesn't perform >> >> > automatic white balance, you will need to implement an AWB algorithm in >> >> > software. You can have a look at the omap3-isp-live project for sample >> >> > code (http://git.ideasonboard.org/omap3-isp-live.git). >> >> So you think the sensor is set well now ? > > I think so, yes. > >> The hardware can produce this issue ? Do you know if this algorithm is >> implemented in gstreamer ? > > I don't know, but if it is the implementation will be software-based, and will > thus be slow. The OMAP3 ISP can compute AWB-related statistics in hardware and > can apply per-color gains to the image. The only software you then need will > retrieve the statistics, compute the gains from them and apply the gains. > That's what the sample code in omap3-isp-live does. This should at some point > be integrated as a libv4l plugin. > So I can use your software to test if it's a white balance issue ? (as the omap3-isp-live has this support if I understood). I'll try this, do you can provide some tips on how use the omap3-isp-live ? Thanks again. > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
