Re: Need help in converting YUV to RGB using OV7620

On Friday, in article
<OYadnX5MYI2oDFrenZ2dnUVZ_sWdnZ2d@xxxxxxxxxxxx>
k2skate2003@xxxxxxxxx "nuky8181" wrote:

>Hi,
>
>I have read a few post about OV7620 and I cant find one that is related to
>my problem. Hope you guys can give me some advise on converting the YUV
>data obtained from OV7620 to RGB format.

Look for past posts on "Omnivision OV7640" around June 2004, there was lots
of discussion then about this.

>I am using the OV7620 in its default mode thus I am only getting 16bit YUV
>data. This is the first time I am using camera chip and from the data
>***, the following is what I have understood. Pls correct me if I am
>wrong.

First step on something like this FORGET colour, see if you can create the
correct Y image for a monochrome image. Once you have that you know you
have the correct clocking arrangement on data and you are getting all
the data.

THEN consider doing colour conversion.

>YUV data is obtained in the following way
>clk 1 Y0 U0
>clk 2 Y1 V1
>clk 3 Y2 U2 etc

No, the format is best described spatially as

Y Y Y Y
U U
V V

In other words

Y0 Y1 Y2 Y3
U0 U1
V0 V1

You cannot work out true RGB until 2nd Y and V has been acquired, so you
get a 1 pixel delay to start with.

>The format is 4:2:2 format thus to get RGB I need to do the following
>Example,
>To get RGB for 1st pixel, Y0 U0 and V1 is used in the computation
>to get RGB for 2nd pixel, Y1 U0 and V1 is used

For third pixel onwards you may have to use in your nomenclatue

RGB2 = Y2 U2 and V1
or Y2 U2 and V3

Part of your problem may be how you are indexing the U/V data and ending
up with 2 U samples or 2 V samples being used.

>The formula given in the data *** to get YUV was as followed
>Y=0.59G +0.31R + 0.11B
>U/Cr = 0.713(R-Y)
>V/Cb = 0.594(B-r)

That is how they are generated internally from the filter matrix on the
sensor as if it was a true RGB source conversion from

Y = 0.299R' + 0.587G' + 0.114B'
Cb = -0.172R' - 0.339G' + 0.511B' + 128
Cr = 0.511R' - 0.428G' + 0.083B' + 128

>I used matlab to get the conversion from YUV to RGB in the following
>R = Y + 1.4025[U-128]
>G = 0.983*Y + 0.7369[U-128] - 0.3306[V-128]
>B = Y - 1.773[V-128]

I don't know how you calculated that and whether you RGB has been
gamma corrected or not but those figures are plain wrong.

For YUV to gamma corrected RGB is (assumes U and V are SIGNED values)

R' = Y + 1.140V
G' = Y - 0.395U - 0,581V
B' = Y + 2.032U

That is true for PAL/NTSC/SECAM

For 601 standard YCbCr to RGB gamma corrected the standard equations
are
R' = Y + 1.371(Cr - 128)
G' = Y - 0.698(Cr - 128) - 0,336(Cb - 128)
B' = Y + 1.732(Cb - 128)

That is for 16-235(240) range signals, the multipliers are larger for 0-255
range data for a start Y becomes 1,164(Y - 16), with all sorts of extra
saturation, under/overflow logic as well.

The differences are not even explained by a typo in the message.

>The 128 was include to shift U and V from the range 16 - 240 to
>-112 - 112.

I would check that you are using true signed variables for the conversion
and ensure with test data you

>What I did was get the YUV data using DSPIC30F6012 and transfer it to
>visual basic and use the RGB formula obtain above to get RGB but I never
>seem to get it. the result is always a green image regardless the colour
>of the image taken.

Green images usually suggest that you have data shorts/opens or incorrect
clocking of data. It more than anything suggests to me that either there is
NO U/V data as (green is mainly Y component) or your U/V data port has lost
a high order bit (one or more of D5 to D7).

>I have check that there is no data corruption during transfer and is now
>really stuck. I have also tried other forumla found in other website where
>one of which is microsoft msdn. Still, no avil.

How have you checked the data transfer?
Have you checked for shorts/opens from pins to pins, all the way through?

If one or more of D5 to D7 is permanently high or low your results will be
skewed.

Have you taken images of a FLAT colour at saturation to check you data
conversion, or as another poster has suggested fed a colour bars data
set into your algorithm.

>I would really appreciate if anyone could help me out here.

The best resource by far for understanding video formats and colour
space conversion is

Video Demystified (4th edition or later)
Keith Jack
Publisher Newnes
ISBN 0-7506-7822-4

--
Paul Carpenter | paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate

.