Hi Laurent, 2012/9/27 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: > Hi Enric, > > 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 :-) > >> 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). > > -- > 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
