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

mt9p031 shows purple coloured capture

[Andrei Andreyanau]

Hi, Laurent,
I have an issue with the mt9p031 camera. The kernel version I use
uses soc camera framework as well as camera does. And I have
the following thing which appears randomly while capturing the
image using gstreamer. When I start the capture for the first time, it
shows the correct image (live stream). When I stop and start it again
it may show the image in purple (it can appear on the third or fourth
time). Or it can show the correct image every time I start the capture.
Do you have any idea why it appears so?

Thanks in advance,
Andrei Andreyanau

Re: mt9p031 shows purple coloured capture

[Guennadi Liakhovetski]

On Thu, 16 May 2013, Andrei Andreyanau wrote:

> Hi, Laurent,
> I have an issue with the mt9p031 camera. The kernel version I use
> uses soc camera framework as well as camera does. And I have
> the following thing which appears randomly while capturing the
> image using gstreamer. When I start the capture for the first time, it
> shows the correct image (live stream). When I stop and start it again
> it may show the image in purple (it can appear on the third or fourth
> time). Or it can show the correct image every time I start the capture.
> Do you have any idea why it appears so?

Wrong clock or *sync polarity selection? Which leads to random 
start-of-frame misplacement?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: mt9p031 shows purple coloured capture

[Andrei Andreyanau]

Hi, Guennadi,

On 05/16/2013 10:46 PM, Guennadi Liakhovetski wrote:
> On Thu, 16 May 2013, Andrei Andreyanau wrote:
>
>> Hi, Laurent,
>> I have an issue with the mt9p031 camera. The kernel version I use
>> uses soc camera framework as well as camera does. And I have
>> the following thing which appears randomly while capturing the
>> image using gstreamer. When I start the capture for the first time, it
>> shows the correct image (live stream). When I stop and start it again
>> it may show the image in purple (it can appear on the third or fourth
>> time). Or it can show the correct image every time I start the capture.
>> Do you have any idea why it appears so?
> 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.

Anyway, I found one solution that lead me to this:
I have a correct image on the LCD display, connected via HDMI, I have a
correct
video stream that was captured into the file, but I get the purple-coloured
live stream on the display, connected via LVDS port on the board (for now -
every time I capture the stream from the camera sensor).
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.
What do you think?

By the way, this register is not used in the latest kernel.

Regards,
Andrei

Re: mt9p031 shows purple coloured capture

[Andrei Andreyanau]

Hi, Chris,

No, I didn't try this, but I'll try. Also I was thinking that this issue
appears because
the bus width is not 12 bits as needed by the datasheet, but 10 bits (as
it is limited
by the hardware) so I was thinking that it may cause this issue to appear.


Regards,
Andrei

On 05/16/2013 05:39 PM, Chris MacGregor wrote:
> Hi.  IIRC, I had this problem as well.  I think I "solved" it by 
> noticing that other users were simply skipping the first 3 frames. That 
> seems to consistently avoid the issue for me.  Have you tried that?
>
>      Chris
>
> On 05/16/2013 06:05 AM, Andrei Andreyanau wrote:
>> Hi, Laurent,
>> I have an issue with the mt9p031 camera. The kernel version I use
>> uses soc camera framework as well as camera does. And I have
>> the following thing which appears randomly while capturing the
>> image using gstreamer. When I start the capture for the first time, it
>> shows the correct image (live stream). When I stop and start it again
>> it may show the image in purple (it can appear on the third or fourth
>> time). Or it can show the correct image every time I start the capture.
>> Do you have any idea why it appears so?
>>
>> Thanks in advance,
>> Andrei Andreyanau
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>