[M4IF Technotes] layout of YUV files

[Stefan A. Goor]

Hi Everyone,
I have a problem that's been baffling me for a few days.
I'm trying read the YUV reference clips such as akiyo_qcif.yuv etc in terms
of Y U and V components (or more accuractely Y Cr Cb, so I'm told) and
convert them to RGB format.  I know there are tools available to do this but
I am specifically coding in java and would like to be able to control
exactly what is going on in terms of pixels.
Basically the problem occurs when I do the conversion.  My understanding is
that these files are planar YUV format (i.e. YYYYYYY....UUUU....VVVV) and
not interlaced (i.e. YUYVYU...... etc).  Taking into account that all the
frames are QCIF, the format is 4:2:0 and each Y U or V component is 1 byte,
I assume that reading the first 25344 (176x144) bytes is the Y component,
the next 6776 (88x77) bytes are U and the next 6776 bytes are the V
component and so on and so forth for each frame.
I separated the components out into individual files and used Paintshop to
display these as raw greyscale images and it seems to coincide with what I
understood but as you can see from the pictures on
http://www.netsoc.ucd.ie/~stefg/Qs/Question.html.  The U and V files are the
same size as the Y component because I scaled them up a factor of 4 to
convert them to QCIF size i.e.
a b ..   =		a a b b ..
c d ..		a a b b ..
. .			c c d d ..
. .			c c d d ..
			. . . .
			. . . .
Having this data, I tried to convert it to RGB using the following equations
that I found on many websites so I'm guessing they're correct:
int R_value = (int)((1.164 * (Y_value - 16)) + (1.596 * (V_value - 128)));
int G_value = (int)((1.164 * (Y_value - 16)) - (0.813 * (V_value - 128)) -
(0.391 * (U_value - 128)));
int B_value = (int)((1.164 * (Y_value - 16)) + (2.018 * (U_value - 128)));
and after each conversion any errors must be corrected using code such as:
if(value<0)
	value = 0;
else if (value>255)
	value = 255;
But as you can the result (http://www.netsoc.ucd.ie/~stefg/Qs/Question.html)
that I got from the conversion was just random garbage.
As a result, I'm wondering is yuv data layed out in files with the first
byte representing the top left corner pixel and the next byte the next pixel
to the right etc?
Does any one have any ideas, what went wrong? Are any of my assumption
wrong?
Sorry about the long-winded email, but I just wanted to state the problem
clearly,
Thanks for you help,
Stefan