* omap3isp: wrong image after resizer with mt9v034 sensor
@ 2012-09-24 8:33 Enric Balletbò i Serra
2012-09-24 12:39 ` Laurent Pinchart
0 siblings, 1 reply; 17+ messages in thread
From: Enric Balletbò i Serra @ 2012-09-24 8:33 UTC (permalink / raw)
To: linux-media, Laurent Pinchart
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-000000.bin img-000000.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-000000.uyvy img-000000.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 ?
Any help would be appreciated. Thanks in advance,
Enric
[1] http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-omap3isp-next
[2] https://github.com/jdthomas/bayer2rgb
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-24 8:33 omap3isp: wrong image after resizer with mt9v034 sensor Enric Balletbò i Serra @ 2012-09-24 12:39 ` Laurent Pinchart 2012-09-24 13:49 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-24 12:39 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media 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-000000.bin img-000000.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-000000.uyvy img-000000.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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-24 12:39 ` Laurent Pinchart @ 2012-09-24 13:49 ` Enric Balletbò i Serra 2012-09-25 0:43 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-24 13:49 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > 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-000000.bin img-000000.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-000000.uyvy img-000000.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-000000.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-000000.uyvy > >> [1] http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- >> omap3isp-next >> [2] https://github.com/jdthomas/bayer2rgb > > -- > Regards, > > Laurent Pinchart > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-24 13:49 ` Enric Balletbò i Serra @ 2012-09-25 0:43 ` Laurent Pinchart 2012-09-25 7:44 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-25 0:43 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > 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-000000.bin img-000000.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-000000.uyvy img-000000.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-000000.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-000000.uyvy > > >> [1] > >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- > >> omap3isp-next > >> [2] https://github.com/jdthomas/bayer2rgb -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-25 0:43 ` Laurent Pinchart @ 2012-09-25 7:44 ` Enric Balletbò i Serra 2012-09-25 10:52 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-25 7:44 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, Many thanks for your time. 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > Hi Enric, > > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> > 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-000000.bin img-000000.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-000000.uyvy img-000000.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-000000.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-000000.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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-25 7:44 ` Enric Balletbò i Serra @ 2012-09-25 10:52 ` Laurent Pinchart 2012-09-25 11:23 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-25 10:52 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: > 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > >> 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> > 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-000000.bin > >> >> img-000000.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-000000.uyvy img-000000.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-000000.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-000000.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-000000.uyvy > >> >> > >> >> [1] > >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/ > >> >> omap3isp-omap3isp-next > >> >> [2] https://github.com/jdthomas/bayer2rgb -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-25 10:52 ` Laurent Pinchart @ 2012-09-25 11:23 ` Enric Balletbò i Serra 2012-09-25 11:31 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-25 11:23 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > Hi Enric, > > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: >> 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> >> 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> > 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-000000.bin >> >> >> img-000000.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-000000.uyvy img-000000.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-000000.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-000000.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-000000.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. >> >> >> 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-000000.uyvy >> >> >> >> >> >> [1] >> >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/ >> >> >> omap3isp-omap3isp-next >> >> >> [2] https://github.com/jdthomas/bayer2rgb > > -- > Regards, > > Laurent Pinchart > I really appreciate your help. Many thanks for your time. Regards, Enric ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-25 11:23 ` Enric Balletbò i Serra @ 2012-09-25 11:31 ` Laurent Pinchart 2012-09-26 7:57 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-25 11:31 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Tuesday 25 September 2012 13:23:20 Enric Balletbò i Serra wrote: > 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: > >> 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: > >> >> 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> >> > 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-000000.bin > >> >> >> img-000000.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-000000.uyvy img-000000.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-000000.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-000000.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-000000.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'm using raw2rgbpnm (https://gitorious.org/raw2rgbpnm). If you look at the binary file in a hex editor you'll see that the MSBs are corrupted, instead of being stable in the 01 and 02 regions (pixels 256-511 and 512-752 on each line, so bytes 512-1023 and 1024-1503) they oscillate between 00 and 01, and 00 and 02 respectively. > >> 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-000000.uyvy > >> >> >> > >> >> >> [1] > >> >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/ > >> >> >> omap3isp-omap3isp-next > >> >> >> [2] https://github.com/jdthomas/bayer2rgb -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-25 11:31 ` Laurent Pinchart @ 2012-09-26 7:57 ` Enric Balletbò i Serra 2012-09-26 8:49 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-26 7:57 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > Hi Enric, > > On Tuesday 25 September 2012 13:23:20 Enric Balletbò i Serra wrote: >> 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> > On Tuesday 25 September 2012 09:44:42 Enric Balletbò i Serra wrote: >> >> 2012/9/25 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> > On Monday 24 September 2012 15:49:01 Enric Balletbò i Serra wrote: >> >> >> 2012/9/24 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> >> > 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-000000.bin >> >> >> >> img-000000.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-000000.uyvy img-000000.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-000000.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-000000.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-000000.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'm using raw2rgbpnm (https://gitorious.org/raw2rgbpnm). If you look at the > binary file in a hex editor you'll see that the MSBs are corrupted, instead of > being stable in the 01 and 02 regions (pixels 256-511 and 512-752 on each > line, so bytes 512-1023 and 1024-1503) they oscillate between 00 and 01, and > 00 and 02 respectively. Thanks for the explanation, I really appreciate it. > >> >> I'll investigate a bit more following this line. 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. 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. >> >> >> >> > 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-000000.uyvy >> >> >> >> >> >> >> >> [1] >> >> >> >> http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/ >> >> >> >> omap3isp-omap3isp-next >> >> >> >> [2] https://github.com/jdthomas/bayer2rgb > > -- > Regards, > > Laurent Pinchart > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-26 7:57 ` Enric Balletbò i Serra @ 2012-09-26 8:49 ` Laurent Pinchart 2012-09-26 14:15 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-26 8:49 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media 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-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. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-26 8:49 ` Laurent Pinchart @ 2012-09-26 14:15 ` Enric Balletbò i Serra 2012-09-27 11:19 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-26 14:15 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, 2012/9/26 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > 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-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. 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 ... Regards, Enric ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-26 14:15 ` Enric Balletbò i Serra @ 2012-09-27 11:19 ` Laurent Pinchart [not found] ` <CAFqH_5245L5XqEGy=fpR8VNd9EHwUMZFO=p2NoLF4g4J3K0hCg@mail.gmail.com> 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-27 11:19 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: > 2012/9/26 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > 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. > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAFqH_5245L5XqEGy=fpR8VNd9EHwUMZFO=p2NoLF4g4J3K0hCg@mail.gmail.com>]
* Re: omap3isp: wrong image after resizer with mt9v034 sensor [not found] ` <CAFqH_5245L5XqEGy=fpR8VNd9EHwUMZFO=p2NoLF4g4J3K0hCg@mail.gmail.com> @ 2012-09-27 23:32 ` Laurent Pinchart [not found] ` <CAFqH_52g8nTTDQDJEzx9E9sC5GoQML7bV-hxjA8q4Q2TcDOTYg@mail.gmail.com> 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-09-27 23:32 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > 2012/9/27 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: > >> 2012/9/26 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> > 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. > >> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAFqH_52g8nTTDQDJEzx9E9sC5GoQML7bV-hxjA8q4Q2TcDOTYg@mail.gmail.com>]
[parent not found: <1378805.eK71Lgs3H4@avalon>]
* Re: omap3isp: wrong image after resizer with mt9v034 sensor [not found] ` <1378805.eK71Lgs3H4@avalon> @ 2012-09-28 15:32 ` Enric Balletbò i Serra 2012-10-01 10:25 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-09-28 15:32 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media Hi Laurent, 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > Hi Enric, > > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> >> 2012/9/27 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> > On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: >> >> >> 2012/9/26 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> >> > 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-09-28 15:32 ` Enric Balletbò i Serra @ 2012-10-01 10:25 ` Laurent Pinchart 2012-10-01 10:49 ` Enric Balletbò i Serra 0 siblings, 1 reply; 17+ messages in thread From: Laurent Pinchart @ 2012-10-01 10:25 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media Hi Enric, On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: > 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: > >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > >> >> 2012/9/27 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> >> > 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-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 ? 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-10-01 10:25 ` Laurent Pinchart @ 2012-10-01 10:49 ` Enric Balletbò i Serra 2012-10-01 11:03 ` Laurent Pinchart 0 siblings, 1 reply; 17+ messages in thread From: Enric Balletbò i Serra @ 2012-10-01 10:49 UTC (permalink / raw) To: Laurent Pinchart; +Cc: linux-media 2012/10/1 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > Hi Enric, > > On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: >> >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: >> >> >> 2012/9/27 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: >> >> >> > 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-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 ? > > 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: omap3isp: wrong image after resizer with mt9v034 sensor 2012-10-01 10:49 ` Enric Balletbò i Serra @ 2012-10-01 11:03 ` Laurent Pinchart 0 siblings, 0 replies; 17+ messages in thread From: Laurent Pinchart @ 2012-10-01 11:03 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: linux-media On Monday 01 October 2012 12:49:48 Enric Balletbò i Serra wrote: > 2012/10/1 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > > On Friday 28 September 2012 17:32:36 Enric Balletbò i Serra wrote: > >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> > On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote: > >> >> 2012/9/28 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> >> > On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: > >> >> >> 2012/9/27 Laurent Pinchart <laurent.pinchart@ideasonboard.com>: > >> >> >> > 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-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 ? > > > > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-10-01 11:02 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-24 8:33 omap3isp: wrong image after resizer with mt9v034 sensor Enric Balletbò i Serra
2012-09-24 12:39 ` Laurent Pinchart
2012-09-24 13:49 ` Enric Balletbò i Serra
2012-09-25 0:43 ` Laurent Pinchart
2012-09-25 7:44 ` Enric Balletbò i Serra
2012-09-25 10:52 ` Laurent Pinchart
2012-09-25 11:23 ` Enric Balletbò i Serra
2012-09-25 11:31 ` Laurent Pinchart
2012-09-26 7:57 ` Enric Balletbò i Serra
2012-09-26 8:49 ` Laurent Pinchart
2012-09-26 14:15 ` Enric Balletbò i Serra
2012-09-27 11:19 ` Laurent Pinchart
[not found] ` <CAFqH_5245L5XqEGy=fpR8VNd9EHwUMZFO=p2NoLF4g4J3K0hCg@mail.gmail.com>
2012-09-27 23:32 ` Laurent Pinchart
[not found] ` <CAFqH_52g8nTTDQDJEzx9E9sC5GoQML7bV-hxjA8q4Q2TcDOTYg@mail.gmail.com>
[not found] ` <1378805.eK71Lgs3H4@avalon>
2012-09-28 15:32 ` Enric Balletbò i Serra
2012-10-01 10:25 ` Laurent Pinchart
2012-10-01 10:49 ` Enric Balletbò i Serra
2012-10-01 11:03 ` Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).