mt9p031 shows purple coloured capture

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

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

[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