omap3isp: wrong image after resizer with mt9v034 sensor

omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[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-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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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
>

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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
>

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[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 ?

> 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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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
>

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Enric Balletbò i Serra]

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
>

Re: omap3isp: wrong image after resizer with mt9v034 sensor

[Laurent Pinchart]

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