Need help in converting YUV to RGB using OV7620

On 13/01/2006 the venerable nuky8181 etched in runes:

Why not set the OV7620 to output RGB data then you don't have to do the conversion.

If you do want to use Y, Cb & Cr, then run a simple test using 100% RGB colour bars as dummy data that will quickly tell you if your formulae are correct.

R G B Y Cr Cb White 255 255 255 235 128 128 Yellow 255 255 0 210 146 16 Cyan 0 255 255 170 16 166 Green 0 255 0 145 34 54 Magenta 255 0 255 106 222 202 Red 255 0 0 81 240 90 Blue 0 0 255 41 110 240 Black 0 0 0 16 128 128

--
John B

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

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.

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.

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.

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

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

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).

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.

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 | snipped-for-privacy@pcserviceselectronics.co.uk PC Services GNU H8 & mailing list info For those web sites you hate

conversion.

colour bars as dummy data

Thanks John,

May I know which forumla u base on to get the value? cos i tried a few cant get the value.

the

You mentioned the way u get RGB2, would like to double check with again. Just to illustrate abit more cos I dont really understand the RGB section. Suppost the following, Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 U0 U1 U2 U3 V0 V1 V2 V3

Can I do the following, RGB1 = Y0 U0 V0 RGB2 = Y1 U0 V0 RGB3 = Y2 U1 V1 RGB4 = Y3 U1 V1

Point noted. Will do a check on this. Thanks.

Hm... I did not do any gamma correction but basically I just convert th formula given in the datasheet to matrics and then did a inverse matric to get the formula.

0-255

Thanks for the two formula before. Will give it a try after the U and issue. I notice that in the Data sheet the following sentence Y = 0.59G + 0.31R + 0.11B U = R-Y V = B-Y

or

Y = 0.59G + 0.31R + 0.11B Cr = 0.713(R-Y) Cb = 0.564(B-Y)

It sort of give me the impression that Cr = U and V = Cb but i found i

that Cr = V and U = Cb. May I know which is the correc one?

conversion

never

colour

incorrect

is

lost

I have check for shorts and open. I believe I am not getting the wrong data due to the clocking becase I manage to get Y data correctly and can display grey scale image but still checking if I am getting all U or V.

now

where

through?

be

My friend prompted that data sent from the camera to the laptop could be lost so I transfer fix data and what I did is indeed what I send.

My algorithm did not manage to get what John say suggested. Even the two formula you gave manage to get the value he has given.

Thanks for the advice given Paul.

On 16/01/2006 the venerable nuky8181 etched in runes:

Assuming R, G & B all have range 0->255, Y has range 16->235 and Cr & Cb have range 16->240, the following are the conversions:

Y = (((65 * R) + (129 * G) + (25 * B)) / 256) + 16; Cr = (((112 * R) - (94 * G) - (18 * B)) / 256) + 128; Cb = (((-38 * R) - (74 * G) + (112 * B)) / 256) + 128;

--
John B

Hi,

Anyone can tell me if I am getting the wrong U and V data?

I have check that there is signal coming our from the UV port of th OV7620 using oscilloscope.

My micro controller operating freq is 20Mhz while the OV7620 is returnin PCLK at 5Mhz. Thus, if I am to read in thy Y or UV data continuously, should be able to read in 4 identical data for either Y or UV for eac PCLK.

I have verify this by reading in data from the digital port and check tha everydata is repeated 4 times. Thus somehow, i am quite convince that I a getting the correct data but I amd still unable convert it into RG value.

May I know if anyone have ever tried reading in the YUV data and manage t convert it to RGB data? Is it possible to just show me that section of th code?

Regards, Linus

I would love to know how you expect the microcrontroller to gurantee grabbing every single data point as I doubt you are doing what you think you are doing.

Firstly you have NOT checked that your microcontroller can accept data at 10MHz for UV data! On these devices Y data is clocked out at 5MHz on ONE clock edge, whilst UV is clocked out at 10MHz by using the rising edge for one of the data bytes and falling edge for the next byte. There is a register in the OV7620 for setting which edge clocks U or V so read the datasheet.

Unless you have taken the UV data to ports on the microcontroller that work either on BOTH edges of the PCLK signal or to two ports that can be configured one on rising edge the other on falling edge, it won't work.

Similarly the microcontroller must really be able to get the data in by clocking the data in from an EXTERNAL clock to drive the data capture NOT the microcontroller. Then there is the Y data at 5MHz can you really get your 20MHz microcontroller to clock in 15MHz of continuous data as

16/24 bit data.

Have you really checked what happens to the data on BOTH edges of PCLK? I doubt it. You have not checked the integrity of the data against a known colour pattern object, to check the data is correct.

Due to the data transmission structure most people use some form of PLD/FPGA to clock the data into memory for the processor to deal with. On cheap camera modules they use an ASIC to convert the data into something like JPEG format and transmit the JPEG data as a stream of data.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate