Re: mt9p031 shows purple coloured capture

Re: mt9p031 shows purple coloured capture

[Florian Neuhaus]

Hi Andrei,

Your post helped me a lot!
My environment:
beagleboard-xm
mt9p031 @96Mhz (adapted power-supply)
linux-omap 3.7.10
omap3isp-live

I have two similiar issues with the mt9p031, that has probably the same cause:

If I use omap3isp-live to capture a stream on my beagleboard, the first time I start the app,
the picture has always a green taint. The second time I start the app, the picture is good. As the camera is reset by a gpio upon device open, probably the CCDC or previewer is not 
initialized correctly?
@Laurent: As I am unable to test it with another cam, does this also happen with your hardware
or is it a problem specific to the mt9p031?

The second problem is similiar to your problem:
omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I am doing the following:
1. Streaming video, picture looks good on the second start
2. Taking a snapshot: The video stream will turn off, the isp-pipe reconfigured. Then the stream
will be turned back on and the captured image will be written to memory.
3. The captured image will now be displayed, but the image is corrupted: Wrong colors and cut in half: https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg
4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad.
5. Additional problem: The CCDC can't be stopped properly (omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks up completely.

> So I used the register 0x0B (Restart), bit 0 (abandon the current frame and
> restart from the first row) set to 1 each time the function s_stream is called.

The finding so far: If I do a frame-restart (the register 0x0b on mt9p031) upon stream-on, the CCDC can be stopped properly and the snapshot looks pretty good. BUT the colors are still messed up. If I then switch to streaming again, the colors sometimes turn to good but sometimes the picture is purple tainted.
@Andrei: What have you done to get good colors? 

>> Wrong clock or *sync polarity selection? Which leads to random
>> start-of-frame misplacement?
>> 
> Do you mean pixel clock polarity? If so, I checked it - with it being inverted -
> the image capture goes well (purple color also appears from time to time),
> but in the case it is not inverted I see a noise on the screen.

Inverted the pixel-clock on the mt9p031 side (register 0x0a, bit 15)? I inverted the clock, but then the streaming had a purple taint.

Regards,
Florian

Re: mt9p031 shows purple coloured capture

[Laurent Pinchart]

Hi Florian,

On Tuesday 11 June 2013 10:01:31 Florian Neuhaus wrote:
> Hi Andrei,
> 
> Your post helped me a lot!
> My environment:
> beagleboard-xm
> mt9p031 @96Mhz (adapted power-supply)
> linux-omap 3.7.10
> omap3isp-live
> 
> I have two similiar issues with the mt9p031, that has probably the same
> cause:
> 
> If I use omap3isp-live to capture a stream on my beagleboard, the first time
> I start the app, the picture has always a green taint. The second time I
> start the app, the picture is good. As the camera is reset by a gpio upon
> device open, probably the CCDC or previewer is not initialized correctly?
> @Laurent: As I am unable to test it with another cam, does this also happen
> with your hardware or is it a problem specific to the mt9p031?

Last time I've tested my MT9P031 sensor with the Beagleboard-xM there was no 
such issue.

> The second problem is similiar to your problem:
> omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I am
> doing the following:
> 1. Streaming video, picture looks good on the second start
> 2. Taking a snapshot: The video stream will turn off, the isp-pipe
> reconfigured. Then the stream will be turned back on and the captured image
> will be written to memory.
> 3. The captured image will now be displayed, but the image is corrupted:
> Wrong colors and cut in half:
> https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg
> 4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad.
> 5. Additional problem: The CCDC can't be stopped properly (omap3isp
> omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks up
> completely.
>
> > So I used the register 0x0B (Restart), bit 0 (abandon the current frame
> > and restart from the first row) set to 1 each time the function s_stream
> > is called.
>
> The finding so far: If I do a frame-restart (the register 0x0b on mt9p031)
> upon stream-on, the CCDC can be stopped properly and the snapshot looks
> pretty good. BUT the colors are still messed up. If I then switch to
> streaming again, the colors sometimes turn to good but sometimes the picture
> is purple tainted. @Andrei: What have you done to get good colors?
> 
> >> Wrong clock or *sync polarity selection? Which leads to random
> >> start-of-frame misplacement?
> > 
> > Do you mean pixel clock polarity? If so, I checked it - with it being
> > inverted - the image capture goes well (purple color also appears from
> > time to time), but in the case it is not inverted I see a noise on the
> > screen.
> 
> Inverted the pixel-clock on the mt9p031 side (register 0x0a, bit 15)? I
> inverted the clock, but then the streaming had a purple taint.

-- 
Regards,

Laurent Pinchart

AW: mt9p031 shows purple coloured capture

[Florian Neuhaus]

Hi Laurent,

Laurent Pinchart wrote on 2013-06-18:

>> If I use omap3isp-live to capture a stream on my beagleboard, the first
>> time I start the app, the picture has always a green taint. The second
>> time I start the app, the picture is good. As the camera is reset by a
>> gpio upon device open, probably the CCDC or previewer is not
>> initialized correctly? @Laurent: As I am unable to test it with another
>> cam, does this also happen with your hardware or is it a problem
>> specific to the mt9p031?
> 
> Last time I've tested my MT9P031 sensor with the Beagleboard-xM there
> was no such issue.
If I test it with yavta, it works also from the very first start. So there
must be an issue in my (adapted) omap3-isp-live.

> 
>> The second problem is similiar to your problem:
>> omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I
>> am doing the following:
>> 1. Streaming video, picture looks good on the second start 2. Taking a
>> snapshot: The video stream will turn off, the isp-pipe reconfigured.
>> Then the stream will be turned back on and the captured image will be
>> written to memory.
>> 3. The captured image will now be displayed, but the image is corrupted:
>> Wrong colors and cut in half:
>> https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg
>> 4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad.
>> 5. Additional problem: The CCDC can't be stopped properly (omap3isp
>> omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks
>> up completely.
>> 
>>> So I used the register 0x0B (Restart), bit 0 (abandon the current
>>> frame and restart from the first row) set to 1 each time the
>>> function s_stream is called.
>> 
>> The finding so far: If I do a frame-restart (the register 0x0b on
>> mt9p031) upon stream-on, the CCDC can be stopped properly and the
>> snapshot looks pretty good. BUT the colors are still messed up. If I
>> then switch to streaming again, the colors sometimes turn to good but
>> sometimes the picture is purple tainted. @Andrei: What have you done to
>> get good colors?
The color problem goes away nearly completely, if I do a power-off and 
on in the mt9p031_s_stream function. It then happens only 
1 out of 10 times. At least an improvement ;)
I have the feeling, that the CCDC doesn't get all data on a stream restart
and that causes a buffer corruption. Probably the sensor doesn't
start outputting from the beginning (even with a frame restart).
Any ideas on this?

Regards,
Florian

Re: AW: mt9p031 shows purple coloured capture

[Laurent Pinchart]

Hi Florian,

On Friday 21 June 2013 15:23:53 Florian Neuhaus wrote:
> Laurent Pinchart wrote on 2013-06-18:
> >> If I use omap3isp-live to capture a stream on my beagleboard, the first
> >> time I start the app, the picture has always a green taint. The second
> >> time I start the app, the picture is good. As the camera is reset by a
> >> gpio upon device open, probably the CCDC or previewer is not
> >> initialized correctly? @Laurent: As I am unable to test it with another
> >> cam, does this also happen with your hardware or is it a problem
> >> specific to the mt9p031?
> > 
> > Last time I've tested my MT9P031 sensor with the Beagleboard-xM there
> > was no such issue.
> 
> If I test it with yavta, it works also from the very first start. So there
> must be an issue in my (adapted) omap3-isp-live.

Have you tested the unmodified omap3-is-live ?

> >> The second problem is similiar to your problem:
> >> omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I
> >> am doing the following:
> >> 1. Streaming video, picture looks good on the second start 2. Taking a
> >> snapshot: The video stream will turn off, the isp-pipe reconfigured.
> >> Then the stream will be turned back on and the captured image will be
> >> written to memory.
> >> 3. The captured image will now be displayed, but the image is corrupted:
> >> Wrong colors and cut in half:
> >> https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg
> >> 4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad.
> >> 5. Additional problem: The CCDC can't be stopped properly (omap3isp
> >> omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks
> >> up completely.
> >> 
> >>> So I used the register 0x0B (Restart), bit 0 (abandon the current
> >>> frame and restart from the first row) set to 1 each time the
> >>> function s_stream is called.
> >> 
> >> The finding so far: If I do a frame-restart (the register 0x0b on
> >> mt9p031) upon stream-on, the CCDC can be stopped properly and the
> >> snapshot looks pretty good. BUT the colors are still messed up. If I
> >> then switch to streaming again, the colors sometimes turn to good but
> >> sometimes the picture is purple tainted. @Andrei: What have you done to
> >> get good colors?
> 
> The color problem goes away nearly completely, if I do a power-off and on in
> the mt9p031_s_stream function. It then happens only 1 out of 10 times. At
> least an improvement ;)
> I have the feeling, that the CCDC doesn't get all data on a stream restart
> and that causes a buffer corruption. Probably the sensor doesn't start
> outputting from the beginning (even with a frame restart).
> Any ideas on this?

-- 
Regards,

Laurent Pinchart

AW: AW: mt9p031 shows purple coloured capture

[Florian Neuhaus]

Hi Laurent,

Laurent Pinchart wrote on 2013-06-22:

>>>> If I use omap3isp-live to capture a stream on my beagleboard, the
>>>> first time I start the app, the picture has always a green taint.
>>>> The second time I start the app, the picture is good. As the camera
>>>> is reset by a gpio upon device open, probably the CCDC or previewer
>>>> is not initialized correctly? @Laurent: As I am unable to test it
>>>> with another cam, does this also happen with your hardware or is it
>>>> a problem specific to the mt9p031?
>>> 
>>> Last time I've tested my MT9P031 sensor with the Beagleboard-xM
>>> there was no such issue.
>> 
>> If I test it with yavta, it works also from the very first start. So
>> there must be an issue in my (adapted) omap3-isp-live.
> 
> Have you tested the unmodified omap3-is-live ?
I did today and indeed, with the unmodified app there is no
green taint on the first start. I have now tracked down the issue
to my implemented rotation on the video-out:

diff --git a/videoout.c b/videoout.c
index 51bed8b..627363a 100644
--- a/videoout.c
+++ b/videoout.c
@@ -76,6 +76,14 @@ struct videoout *vo_init(const char *devname,
 		goto error;
 	}
 
+	/* setup the rotation here, we have to do it BEFORE
+	 * setting the format. */
+	ret = v4l2_set_control(vo->dev, V4L2_CID_ROTATE, &rotation);
+	if (ret < 0){
+		perror("Failed to setup rotation\n");
+		goto error;
+	}
+
 	pixfmt.pixelformat = format->pixelformat;
 	pixfmt.width = format->width;
 	pixfmt.height = format->height;

I do a rotation by 90 or 270 degrees. So there seems to be an issue with
the vrfb-rotation in omap_vout?
I am already rotating the omapfb - is this a problem?
omapfb.rotate=1 omapfb.vrfb=y
Another possibility to rotate the captured stream?

>> The color problem goes away nearly completely, if I do a power-off and
>> on in the mt9p031_s_stream function. It then happens only 1 out of 10
>> times. At least an improvement ;) I have the feeling, that the CCDC
>> doesn't get all data on a stream restart and that causes a buffer
>> corruption. Probably the sensor doesn't start outputting from the
>> beginning (even with a frame restart).
>> Any ideas on this?

Probably this issue is in relation with omap_vout as well.
I will do more tests.

Regards,
Florian