Re: omap3isp: wrong image after resizer with mt9v034 sensor
On Monday 01 October 2012 12:49:48 Enric Balletbò i Serra wrote: > 2012/10/1 Laurent Pinchart : > > On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: > >> 2012/9/28 Laurent Pinchart : > >> > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: > >> >> 2012/9/28 Laurent Pinchart : > >> >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > >> >> >> 2012/9/27 Laurent Pinchart : > >> >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra > > wrote: > > > > [snip] > > > >> >> >> >> 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-01.uyvy > >> >> >> >> img-01.pnm > >> >> >> >> > >> >> >> >> and the result is > >> >> >> >> > >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm > >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.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 ? > > > > Yes, but that's really a test application, it might not work out of the > > box. > > I'm getting following error > > # ./live > Device /dev/video6 opened: OMAP3 ISP resizer output (media). > viewfinder configured for 2011 1024x768 > AEWB: #win 10x7 start 6x0 size 74x68 inc 10x8 > Device /dev/video7 opened: omap_vout (). > 3 buffers requested. > Buffer 0 mapped at address 0xb6e16000. > Buffer 1 mapped at address 0xb6c96000. > Buffer 2 mapped at address 0xb6b16000. > 3 buffers requested. > Buffer 0 valid. > Buffer 1 valid. > Buffer 2 valid. > unable to retrieve AEWB event: Inappropriate ioctl for device (25). > unable to retrieve AEWB event: Inappropriate ioctl for device (25). > unable to retrieve AEWB event: Inappropriate ioctl for device (25). > ... > > and a blue screen appears on my monitor. Maybe I missed a patch ? Make sure you compile the application against the kernel version running on your system. You might also need to patch the omap_vout driver to support 1024x768 (modify VID_MAX_HEIGHT in drivers/media/video/omap/omap_voutdef.h). > >> (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 ? > > > > Just compile and run it :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
2012/10/1 Laurent Pinchart : > Hi Enric, > > On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: >> 2012/9/28 Laurent Pinchart : >> > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: >> >> 2012/9/28 Laurent Pinchart : >> >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> >> >> 2012/9/27 Laurent Pinchart : >> >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra > wrote: > > [snip] > >> >> >> >> 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-01.uyvy img-01.pnm >> >> >> >> >> >> >> >> and the result is >> >> >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.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 ? > > Yes, but that's really a test application, it might not work out of the box. > I'm getting following error # ./live Device /dev/video6 opened: OMAP3 ISP resizer output (media). viewfinder configured for 2011 1024x768 AEWB: #win 10x7 start 6x0 size 74x68 inc 10x8 Device /dev/video7 opened: omap_vout (). 3 buffers requested. Buffer 0 mapped at address 0xb6e16000. Buffer 1 mapped at address 0xb6c96000. Buffer 2 mapped at address 0xb6b16000. 3 buffers requested. Buffer 0 valid. Buffer 1 valid. Buffer 2 valid. unable to retrieve AEWB event: Inappropriate ioctl for device (25). unable to retrieve AEWB event: Inappropriate ioctl for device (25). unable to retrieve AEWB event: Inappropriate ioctl for device (25). ... and a blue screen appears on my monitor. Maybe I missed a patch ? >> (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 ? > > Just compile and run it :-) > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: > 2012/9/28 Laurent Pinchart : > > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: > >> 2012/9/28 Laurent Pinchart : > >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > >> >> 2012/9/27 Laurent Pinchart : > >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: [snip] > >> >> >> 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-01.uyvy img-01.pnm > >> >> >> > >> >> >> and the result is > >> >> >> > >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm > >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.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 ? Yes, but that's really a test application, it might not work out of the box. > (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 ? Just compile and run it :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/28 Laurent Pinchart : > Hi Enric, > > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: >> 2012/9/28 Laurent Pinchart : >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> >> 2012/9/27 Laurent Pinchart : >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: >> >> >> 2012/9/26 Laurent Pinchart : >> >> >> > 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-01.pnm >> >> >> >> >> >> >> >> Now the image was converted using : >> >> >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin >> >> >> >> img-01.pnm >> >> >> >> >> >> >> >> And the raw data can be found here: >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 >> >> >> .. 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 752x48
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: > 2012/9/28 Laurent Pinchart : > > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > >> 2012/9/27 Laurent Pinchart : > >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: > >> >> 2012/9/26 Laurent Pinchart : > >> >> > 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-01.pnm > >> >> >> > >> >> >> Now the image was converted using : > >> >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin > >> >> >> img-01.pnm > >> >> >> > >> >> >> And the raw data can be found here: > >> >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 > >> >> .. 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-01.uyvy img-01.pnm > >> >> > >> >> and the result is > >> >> > >> >> http://downloads.isee.biz/pub/files/patterns/img
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/28 Laurent Pinchart : > Hi Enric, > > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> 2012/9/27 Laurent Pinchart : >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: >> >> 2012/9/26 Laurent Pinchart : >> >> > 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-01.pnm >> >> >> >> >> >> Now the image was converted using : >> >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm >> >> >> >> >> >> And the raw data can be found here: >> >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 >> >> .. 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-01.uyvy img-01.pnm >> >> >> >> and the result is >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm >> >> http://downloads.isee.biz/pub/files/patterns/img-02.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 A
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > 2012/9/27 Laurent Pinchart : > > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: > >> 2012/9/26 Laurent Pinchart : > >> > 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-01.pnm > >> >> > >> >> Now the image was converted using : > >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm > >> >> > >> >> And the raw data can be found here: > >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 > >> .. 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. > >> 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-01.uyvy img-01.pnm > >> > >> and the result is > >> > >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm > >> http://downloads.isee.biz/pub/files/patterns/img-02.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
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/27 Laurent Pinchart : > Hi Enric, > > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: >> 2012/9/26 Laurent Pinchart : >> > 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-01.pnm >> >> >> >> Now the image was converted using : >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm >> >> >> >> And the raw data can be found here: >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 >> .. 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-01.uyvy img-01.pnm >> >> and the result is >> >> http://downloads.isee.biz/pub/files/patterns/img-02.pnm >> http://downloads.isee.biz/pub/files/patterns/img-02.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: > 2012/9/26 Laurent Pinchart : > > 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-01.pnm > >> > >> Now the image was converted using : > >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm > >> > >> And the raw data can be found here: > >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 > .. 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. > 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-01.uyvy img-01.pnm > > and the result is > > http://downloads.isee.biz/pub/files/patterns/img-02.pnm > http://downloads.isee.biz/pub/files/patterns/img-02.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/26 Laurent Pinchart : > Hi Enric, > > 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-01.pnm >> >> Now the image was converted using : >> >> ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm >> >> And the raw data can be found here: >> >> http://downloads.isee.biz/pub/files/patterns/img-01.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 4321 .. 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. 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-01.uyvy img-01.pnm and the result is http://downloads.isee.biz/pub/files/patterns/img-02.pnm http://downloads.isee.biz/pub/files/patterns/img-02.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 ... Regards, Enric -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, 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 ? > 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-01.pnm > > Now the image was converted using : > > ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm > > And the raw data can be found here: > > http://downloads.isee.biz/pub/files/patterns/img-01.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. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent 2012/9/25 Laurent Pinchart : > Hi Enric, > > On Tuesday 25 September 2012 13:23:20 Enric Balletbò i Serra wrote: >> 2012/9/25 Laurent Pinchart : >> > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: >> >> 2012/9/25 Laurent Pinchart : >> >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> >> >> 2012/9/24 Laurent Pinchart : >> >> >> > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: >> >> >> >> Hi everybody, >> >> >> >> >> >> >> >> I'm trying to add support for MT9V034 Aptina image sensor to >> >> >> >> current mainline, as a base of my current work I start using the >> >> >> >> latest omap3isp-next branch from Laurent's git tree [1]. The >> >> >> >> MT9V034 image sensor is very similar to MT9V032 sensor, so I >> >> >> >> modified current driver to accept MT9V034 sensor adding the chip >> >> >> >> ID. The driver recognizes the sensor and I'm able to capture some >> >> >> >> frames. >> >> >> >> >> >> >> >> I started capturing directly frames using the pipeline Sensor -> >> >> >> >> CCDC >> >> >> >> >> >> >> >> ./media-ctl -r >> >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC >> >> >> >> output":0[1]' >> >> >> >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' >> >> >> >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' >> >> >> >> >> >> >> >> # Test pattern >> >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> >> >> >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 >> >> >> >> >> >> >> >> --file=img-#.bin >> >> >> >> >> >> >> >> To convert to jpg I used bayer2rgb [2] program executing following >> >> >> >> command, >> >> >> >> >> >> >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin >> >> >> >> img-00.jpg >> >> >> >> >> >> >> >> And the result image looks like this >> >> >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jp >> >> >> >> g >> >> >> >> >> >> >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> >> >> >> >> Preview -> Resizer >> >> >> >> >> >> >> >> ./media-ctl -r >> >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' >> >> >> >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP >> >> >> >> resizer":0[1]' >> >> >> >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer >> >> >> >> output":0[1]' >> >> >> >> >> >> >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' >> >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' >> >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' >> >> >> >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' >> >> >> >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' >> >> >> >> >> >> >> >> # Set Test pattern >> >> >> >> >> >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> >> >> >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy >> >> >> >> /dev/video6 >> >> >> >> >> >> >> >> I used 'convert' program to pass from UYVY to jpg, >> >> >> >> >> >> >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg >> >> >> >> >> >> >> >> and the result image looks like this >> >> >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.j >> >> >> >> pg >> >> >> >> >> >> >> >> As you can see, the image is wrong and I'm not sure if the problem >> >> >> >> is from the sensor, from the previewer, from the resizer or from my >> >> >> >> conversion. Anyone have idea where should I look ? Or which is the >> >> >> >> source of the problem ? >> >> >> > >> >> >> > Could you please post the output of all the above media-ctl and >> >> >> > yavta runs, as well as the captured raw binary frame ? >> >> >> >> >> >> Of course, >> >> >> >> >> >> The log configuring the pipeline Sensor -> CCDC is >> >> >> >> >> >> http://pastebin.com/WX8ex5x2 >> >> >> >> >> >> and the raw image can be found >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-00.bin >> >> > >> >> > It looks like D9 and D8 have trouble keeping their high-level. Possible >> >> > reasons would be conflicts on the signal lines (with something actively >> >> > driving them to a low-level, a pull-down wouldn't have such an effect), >> >> > faulty cable/solder joints (but I doubt that), or sampling the data on >> >> > the wrong edge. >> >> >> >> In that case don't be the first image also wrong ? (the image that >> >> outputs from sensor /dev/video2) >> > >> > Yes, it should be, and >> > http://downloads.isee.biz/pub/files/patterns/img-00.bin is corrupted. >> > That's the image captured at the CCDC output, isn't it ? >> >> Yes it is. >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg >> > >> > How did you
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Tuesday 25 September 2012 13:23:20 Enric Balletbò i Serra wrote: > 2012/9/25 Laurent Pinchart : > > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: > >> 2012/9/25 Laurent Pinchart : > >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > >> >> 2012/9/24 Laurent Pinchart : > >> >> > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: > >> >> >> Hi everybody, > >> >> >> > >> >> >> I'm trying to add support for MT9V034 Aptina image sensor to > >> >> >> current mainline, as a base of my current work I start using the > >> >> >> latest omap3isp-next branch from Laurent's git tree [1]. The > >> >> >> MT9V034 image sensor is very similar to MT9V032 sensor, so I > >> >> >> modified current driver to accept MT9V034 sensor adding the chip > >> >> >> ID. The driver recognizes the sensor and I'm able to capture some > >> >> >> frames. > >> >> >> > >> >> >> I started capturing directly frames using the pipeline Sensor -> > >> >> >> CCDC > >> >> >> > >> >> >> ./media-ctl -r > >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC > >> >> >> output":0[1]' > >> >> >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' > >> >> >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' > >> >> >> > >> >> >> # Test pattern > >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> >> >> > >> >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 > >> >> >> > >> >> >> --file=img-#.bin > >> >> >> > >> >> >> To convert to jpg I used bayer2rgb [2] program executing following > >> >> >> command, > >> >> >> > >> >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin > >> >> >> img-00.jpg > >> >> >> > >> >> >> And the result image looks like this > >> >> >> > >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jp > >> >> >> g > >> >> >> > >> >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> > >> >> >> Preview -> Resizer > >> >> >> > >> >> >> ./media-ctl -r > >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > >> >> >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP > >> >> >> resizer":0[1]' > >> >> >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer > >> >> >> output":0[1]' > >> >> >> > >> >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' > >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' > >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' > >> >> >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' > >> >> >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' > >> >> >> > >> >> >> # Set Test pattern > >> >> >> > >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> >> >> > >> >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy > >> >> >> /dev/video6 > >> >> >> > >> >> >> I used 'convert' program to pass from UYVY to jpg, > >> >> >> > >> >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg > >> >> >> > >> >> >> and the result image looks like this > >> >> >> > >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.j > >> >> >> pg > >> >> >> > >> >> >> As you can see, the image is wrong and I'm not sure if the problem > >> >> >> is from the sensor, from the previewer, from the resizer or from my > >> >> >> conversion. Anyone have idea where should I look ? Or which is the > >> >> >> source of the problem ? > >> >> > > >> >> > Could you please post the output of all the above media-ctl and > >> >> > yavta runs, as well as the captured raw binary frame ? > >> >> > >> >> Of course, > >> >> > >> >> The log configuring the pipeline Sensor -> CCDC is > >> >> > >> >> http://pastebin.com/WX8ex5x2 > >> >> > >> >> and the raw image can be found > >> >> > >> >> http://downloads.isee.biz/pub/files/patterns/img-00.bin > >> > > >> > It looks like D9 and D8 have trouble keeping their high-level. Possible > >> > reasons would be conflicts on the signal lines (with something actively > >> > driving them to a low-level, a pull-down wouldn't have such an effect), > >> > faulty cable/solder joints (but I doubt that), or sampling the data on > >> > the wrong edge. > >> > >> In that case don't be the first image also wrong ? (the image that > >> outputs from sensor /dev/video2) > > > > Yes, it should be, and > > http://downloads.isee.biz/pub/files/patterns/img-00.bin is corrupted. > > That's the image captured at the CCDC output, isn't it ? > > Yes it is. > > >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg > > > > How did you capture that one ? > > This image is the img-00.bin (that you say is corrupted) converted > to RG
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/25 Laurent Pinchart : > Hi Enric, > > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: >> 2012/9/25 Laurent Pinchart : >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> >> 2012/9/24 Laurent Pinchart : >> >> > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: >> >> >> Hi everybody, >> >> >> >> >> >> I'm trying to add support for MT9V034 Aptina image sensor to current >> >> >> mainline, as a base of my current work I start using the latest >> >> >> omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image >> >> >> sensor is very similar to MT9V032 sensor, so I modified current driver >> >> >> to accept MT9V034 sensor adding the chip ID. The driver recognizes the >> >> >> sensor and I'm able to capture some frames. >> >> >> >> >> >> I started capturing directly frames using the pipeline Sensor -> CCDC >> >> >> >> >> >> ./media-ctl -r >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> >> >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' >> >> >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' >> >> >> >> >> >> # Test pattern >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 >> >> >> >> >> >> --file=img-#.bin >> >> >> >> >> >> To convert to jpg I used bayer2rgb [2] program executing following >> >> >> command, >> >> >> >> >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin >> >> >> img-00.jpg >> >> >> >> >> >> And the result image looks like this >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg >> >> >> >> >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> >> >> >> Preview -> Resizer >> >> >> >> >> >> ./media-ctl -r >> >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' >> >> >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' >> >> >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer >> >> >> output":0[1]' >> >> >> >> >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' >> >> >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' >> >> >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' >> >> >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' >> >> >> >> >> >> # Set Test pattern >> >> >> >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy >> >> >> /dev/video6 >> >> >> >> >> >> I used 'convert' program to pass from UYVY to jpg, >> >> >> >> >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg >> >> >> >> >> >> and the result image looks like this >> >> >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg >> >> >> >> >> >> As you can see, the image is wrong and I'm not sure if the problem is >> >> >> from the sensor, from the previewer, from the resizer or from my >> >> >> conversion. Anyone have idea where should I look ? Or which is the >> >> >> source of the problem ? >> >> > >> >> > Could you please post the output of all the above media-ctl and yavta >> >> > runs, as well as the captured raw binary frame ? >> >> >> >> Of course, >> >> >> >> The log configuring the pipeline Sensor -> CCDC is >> >> >> >> http://pastebin.com/WX8ex5x2 >> >> >> >> and the raw image can be found >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-00.bin >> > >> > It looks like D9 and D8 have trouble keeping their high-level. Possible >> > reasons would be conflicts on the signal lines (with something actively >> > driving them to a low-level, a pull-down wouldn't have such an effect), >> > faulty cable/solder joints (but I doubt that), or sampling the data on >> > the wrong edge. >> >> In that case don't be the first image also wrong ? (the image that >> outputs from sensor /dev/video2) > > Yes, it should be, and > http://downloads.isee.biz/pub/files/patterns/img-00.bin is corrupted. > That's the image captured at the CCDC output, isn't it ? Yes it is. > >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg > > How did you capture that one ? This image is the img-00.bin (that you say is corrupted) converted to RGB using bayer2rgb [2] program. So seems I'm using wrong tools to convert images. How you known that this file is corrupted ? Please, could you provide the tools that you use ? > >> I'll investigate a bit more following this line. >> >> > The last option should be easy to test, just change the struct >> > isp_v4l2_subdevs_group::bus::parallel::clk_pol field. >> >> I tested and seems this is not the problem
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: > 2012/9/25 Laurent Pinchart : > > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > >> 2012/9/24 Laurent Pinchart : > >> > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: > >> >> Hi everybody, > >> >> > >> >> I'm trying to add support for MT9V034 Aptina image sensor to current > >> >> mainline, as a base of my current work I start using the latest > >> >> omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image > >> >> sensor is very similar to MT9V032 sensor, so I modified current driver > >> >> to accept MT9V034 sensor adding the chip ID. The driver recognizes the > >> >> sensor and I'm able to capture some frames. > >> >> > >> >> I started capturing directly frames using the pipeline Sensor -> CCDC > >> >> > >> >> ./media-ctl -r > >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > >> >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' > >> >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' > >> >> > >> >> # Test pattern > >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> >> > >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 > >> >> > >> >> --file=img-#.bin > >> >> > >> >> To convert to jpg I used bayer2rgb [2] program executing following > >> >> command, > >> >> > >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin > >> >> img-00.jpg > >> >> > >> >> And the result image looks like this > >> >> > >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg > >> >> > >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> > >> >> Preview -> Resizer > >> >> > >> >> ./media-ctl -r > >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > >> >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' > >> >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer > >> >> output":0[1]' > >> >> > >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' > >> >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' > >> >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' > >> >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' > >> >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' > >> >> > >> >> # Set Test pattern > >> >> > >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> >> > >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy > >> >> /dev/video6 > >> >> > >> >> I used 'convert' program to pass from UYVY to jpg, > >> >> > >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg > >> >> > >> >> and the result image looks like this > >> >> > >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg > >> >> > >> >> As you can see, the image is wrong and I'm not sure if the problem is > >> >> from the sensor, from the previewer, from the resizer or from my > >> >> conversion. Anyone have idea where should I look ? Or which is the > >> >> source of the problem ? > >> > > >> > Could you please post the output of all the above media-ctl and yavta > >> > runs, as well as the captured raw binary frame ? > >> > >> Of course, > >> > >> The log configuring the pipeline Sensor -> CCDC is > >> > >> http://pastebin.com/WX8ex5x2 > >> > >> and the raw image can be found > >> > >> http://downloads.isee.biz/pub/files/patterns/img-00.bin > > > > It looks like D9 and D8 have trouble keeping their high-level. Possible > > reasons would be conflicts on the signal lines (with something actively > > driving them to a low-level, a pull-down wouldn't have such an effect), > > faulty cable/solder joints (but I doubt that), or sampling the data on > > the wrong edge. > > In that case don't be the first image also wrong ? (the image that > outputs from sensor /dev/video2) Yes, it should be, and http://downloads.isee.biz/pub/files/patterns/img-00.bin is corrupted. That's the image captured at the CCDC output, isn't it ? > http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg How did you capture that one ? > I'll investigate a bit more following this line. > > > The last option should be easy to test, just change the struct > > isp_v4l2_subdevs_group::bus::parallel::clk_pol field. > > I tested and seems this is not the problem. > > >> And the log configuring the pipeline Sensor -> CCDC -> Previewer -> > >> Resizer is http://pastebin.com/wh5ZJwne and the raw image can be found > >> > >> http://downloads.isee.biz/pub/files/patterns/img-00.uyvy > >> >> > >> >> [1] > >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/ > >> >> omap3isp-omap3isp-next > >> >> [2] https
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, Many thanks for your time. 2012/9/25 Laurent Pinchart : > Hi Enric, > > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> 2012/9/24 Laurent Pinchart : >> > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: >> >> Hi everybody, >> >> >> >> I'm trying to add support for MT9V034 Aptina image sensor to current >> >> mainline, as a base of my current work I start using the latest >> >> omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image >> >> sensor is very similar to MT9V032 sensor, so I modified current driver >> >> to accept MT9V034 sensor adding the chip ID. The driver recognizes the >> >> sensor and I'm able to capture some frames. >> >> >> >> I started capturing directly frames using the pipeline Sensor -> CCDC >> >> >> >> ./media-ctl -r >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' >> >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' >> >> >> >> # Test pattern >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 >> >> >> >> --file=img-#.bin >> >> >> >> To convert to jpg I used bayer2rgb [2] program executing following >> >> command, >> >> >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin img-00.jpg >> >> >> >> And the result image looks like this >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg >> >> >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> >> >> Preview -> Resizer >> >> >> >> ./media-ctl -r >> >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' >> >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' >> >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer >> >> output":0[1]' >> >> >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' >> >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' >> >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' >> >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' >> >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' >> >> >> >> # Set Test pattern >> >> >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy /dev/video6 >> >> >> >> I used 'convert' program to pass from UYVY to jpg, >> >> >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg >> >> >> >> and the result image looks like this >> >> >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg >> >> >> >> As you can see, the image is wrong and I'm not sure if the problem is >> >> from the sensor, from the previewer, from the resizer or from my >> >> conversion. Anyone have idea where should I look ? Or which is the >> >> source of the problem ? >> > >> > Could you please post the output of all the above media-ctl and yavta >> > runs, as well as the captured raw binary frame ? >> >> Of course, >> >> The log configuring the pipeline Sensor -> CCDC is >> http://pastebin.com/WX8ex5x2 >> and the raw image can be found >> http://downloads.isee.biz/pub/files/patterns/img-00.bin > > It looks like D9 and D8 have trouble keeping their high-level. Possible > reasons would be conflicts on the signal lines (with something actively > driving them to a low-level, a pull-down wouldn't have such an effect), faulty > cable/solder joints (but I doubt that), or sampling the data on the wrong > edge. In that case don't be the first image also wrong ? (the image that outputs from sensor /dev/video2) http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg I'll investigate a bit more following this line. > The last option should be easy to test, just change the struct > isp_v4l2_subdevs_group::bus::parallel::clk_pol field. I tested and seems this is not the problem. > >> And the log configuring the pipeline Sensor -> CCDC -> Previewer -> Resizer >> is http://pastebin.com/wh5ZJwne >> and the raw image can be found >> http://downloads.isee.biz/pub/files/patterns/img-00.uyvy >> >> >> [1] >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- >> >> omap3isp-next >> >> [2] https://github.com/jdthomas/bayer2rgb > > -- > Regards, > > Laurent Pinchart > Regards, Enric -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > 2012/9/24 Laurent Pinchart : > > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: > >> Hi everybody, > >> > >> I'm trying to add support for MT9V034 Aptina image sensor to current > >> mainline, as a base of my current work I start using the latest > >> omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image > >> sensor is very similar to MT9V032 sensor, so I modified current driver > >> to accept MT9V034 sensor adding the chip ID. The driver recognizes the > >> sensor and I'm able to capture some frames. > >> > >> I started capturing directly frames using the pipeline Sensor -> CCDC > >> > >> ./media-ctl -r > >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' > >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' > >> > >> # Test pattern > >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> > >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 > >> > >> --file=img-#.bin > >> > >> To convert to jpg I used bayer2rgb [2] program executing following > >> command, > >> > >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin img-00.jpg > >> > >> And the result image looks like this > >> > >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg > >> > >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> > >> Preview -> Resizer > >> > >> ./media-ctl -r > >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' > >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer > >> output":0[1]' > >> > >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' > >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' > >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' > >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' > >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' > >> > >> # Set Test pattern > >> > >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > >> > >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy /dev/video6 > >> > >> I used 'convert' program to pass from UYVY to jpg, > >> > >> $ convert -size 752x480 img-00.uyvy img-00.jpg > >> > >> and the result image looks like this > >> > >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg > >> > >> As you can see, the image is wrong and I'm not sure if the problem is > >> from the sensor, from the previewer, from the resizer or from my > >> conversion. Anyone have idea where should I look ? Or which is the > >> source of the problem ? > > > > Could you please post the output of all the above media-ctl and yavta > > runs, as well as the captured raw binary frame ? > > Of course, > > The log configuring the pipeline Sensor -> CCDC is > http://pastebin.com/WX8ex5x2 > and the raw image can be found > http://downloads.isee.biz/pub/files/patterns/img-00.bin It looks like D9 and D8 have trouble keeping their high-level. Possible reasons would be conflicts on the signal lines (with something actively driving them to a low-level, a pull-down wouldn't have such an effect), faulty cable/solder joints (but I doubt that), or sampling the data on the wrong edge. The last option should be easy to test, just change the struct isp_v4l2_subdevs_group::bus::parallel::clk_pol field. > And the log configuring the pipeline Sensor -> CCDC -> Previewer -> Resizer > is http://pastebin.com/wh5ZJwne > and the raw image can be found > http://downloads.isee.biz/pub/files/patterns/img-00.uyvy > > >> [1] > >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- > >> omap3isp-next > >> [2] https://github.com/jdthomas/bayer2rgb -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/24 Laurent Pinchart : > Hi Enric, > > On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: >> Hi everybody, >> >> I'm trying to add support for MT9V034 Aptina image sensor to current >> mainline, as a base of my current work I start using the latest >> omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image >> sensor is very similar to MT9V032 sensor, so I modified current driver >> to accept MT9V034 sensor adding the chip ID. The driver recognizes the >> sensor and I'm able to capture some frames. >> >> I started capturing directly frames using the pipeline Sensor -> CCDC >> >> ./media-ctl -r >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' >> ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' >> ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' >> >> # Test pattern >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 >> --file=img-#.bin >> >> To convert to jpg I used bayer2rgb [2] program executing following command, >> >> $ convert -size 752x480 GRBG_BAYER:./img-00.bin img-00.jpg >> >> And the result image looks like this >> >> http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg >> >> Seems good, so I tried to use following pipeline Sensor -> CCDC -> >> Preview -> Resizer >> >> ./media-ctl -r >> ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' >> ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' >> ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' >> ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' >> >> ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' >> ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' >> ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' >> ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' >> ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' >> >> # Set Test pattern >> >> ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 >> >> ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy /dev/video6 >> >> I used 'convert' program to pass from UYVY to jpg, >> >> $ convert -size 752x480 img-00.uyvy img-00.jpg >> >> and the result image looks like this >> >> http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg >> >> As you can see, the image is wrong and I'm not sure if the problem is >> from the sensor, from the previewer, from the resizer or from my >> conversion. Anyone have idea where should I look ? Or which is the >> source of the problem ? > > Could you please post the output of all the above media-ctl and yavta runs, as > well as the captured raw binary frame ? Of course, The log configuring the pipeline Sensor -> CCDC is http://pastebin.com/WX8ex5x2 and the raw image can be found http://downloads.isee.biz/pub/files/patterns/img-00.bin And the log configuring the pipeline Sensor -> CCDC -> Previewer -> Resizer is http://pastebin.com/wh5ZJwne and the raw image can be found http://downloads.isee.biz/pub/files/patterns/img-00.uyvy > >> [1] http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- >> omap3isp-next >> [2] https://github.com/jdthomas/bayer2rgb > > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric, On Monday 24 September 2012 10:33:42 Enric Balletbò i Serra wrote: > Hi everybody, > > I'm trying to add support for MT9V034 Aptina image sensor to current > mainline, as a base of my current work I start using the latest > omap3isp-next branch from Laurent's git tree [1]. The MT9V034 image > sensor is very similar to MT9V032 sensor, so I modified current driver > to accept MT9V034 sensor adding the chip ID. The driver recognizes the > sensor and I'm able to capture some frames. > > I started capturing directly frames using the pipeline Sensor -> CCDC > > ./media-ctl -r > ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > ./media-ctl -l '"OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' > ./media-ctl -f '"mt9v032 3-005c":0 [SGRBG10 752x480]' > ./media-ctl -f '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]' > > # Test pattern > ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > > # ./yavta -p -f SGRBG10 -s 752x480 -n 4 --capture=3 /dev/video2 > --file=img-#.bin > > To convert to jpg I used bayer2rgb [2] program executing following command, > > $ convert -size 752x480 GRBG_BAYER:./img-00.bin img-00.jpg > > And the result image looks like this > > http://downloads.isee.biz/pub/files/patterns/img-from-sensor.jpg > > Seems good, so I tried to use following pipeline Sensor -> CCDC -> > Preview -> Resizer > > ./media-ctl -r > ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]' > ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]' > ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]' > ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' > > ./media-ctl -V '"mt9v032 3-005c":0[SGRBG10 752x480]' > ./media-ctl -V '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]' > ./media-ctl -V '"OMAP3 ISP CCDC":2 [SGRBG10 752x480]' > ./media-ctl -V '"OMAP3 ISP preview":1 [UYVY 752x480]' > ./media-ctl -V '"OMAP3 ISP resizer":1 [UYVY 752x480]' > > # Set Test pattern > > ./yavta --set-control '0x00981901 1' /dev/v4l-subdev8 > > ./yavta -f UYVY -s 752x480 --capture=3 --file=img-#.uyvy /dev/video6 > > I used 'convert' program to pass from UYVY to jpg, > > $ convert -size 752x480 img-00.uyvy img-00.jpg > > and the result image looks like this > > http://downloads.isee.biz/pub/files/patterns/img-from-resizer.jpg > > As you can see, the image is wrong and I'm not sure if the problem is > from the sensor, from the previewer, from the resizer or from my > conversion. Anyone have idea where should I look ? Or which is the > source of the problem ? Could you please post the output of all the above media-ctl and yavta runs, as well as the captured raw binary frame ? > [1] http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- > omap3isp-next > [2] https://github.com/jdthomas/bayer2rgb -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
