Req - Images in (RAW) YUV 422, 411, 420 - (Last Tu.12.06.05)

[vhelp]

corrections: Tue Dec 12, 2005.pm (evening)

revised: Tue Dec 06, 2005.pm (very late)
revised: Mon Dec 05, 2005.pm (very late)
revised: Thu Nov 10, 2005.pm (very late)
Last Updated: Tue Oct 25, 2005.PM ...

Below are images I have produced currently, with a tool I am developing
for image processing.

raw yuv images in I420 4:2:0 sample format:
** Note, the YUV planes, in this order Y/U/V
** Now, these images are based off internet pic D/L's

aeon_flux.1.1024x668.i420.uv.rar
aeon_flux.2.1024x668.i420.uv.rar
harry.potter.3.650x434.i420.uv.rar
harry.potter.4.650x434.i420.uv.rar
king.kong.5.1024x510.i420.uv.rar
king.kong.6.1024x510.i420.uv.rar
starwars3.7.1000x436.i420.uv.rar
starwars3.8.1000x436.i420.uv.rar


12.12.05 - ** please note, these are not i420 format, which means that I
labled and commented them wrong this way too. The correct format for these
raw yuv images in this group below, are YV12. I will fix this mess with a
newer line up of yv12 images, soon.

raw yuv images in YV12 4:2:0 sample format:
** Note, the YUV planes, in this order Y/V/U
** This time, images are based off a dvd source

inc.1.yuv420_i420.720x480.rar
inc.2.yuv420_i420.720x480.rar
inc.3.yuv420_i420.720x480.rar
inc.4.yuv420_i420.720x480.rar
inc.5.yuv420_i420.720x480.rar
inc.6.yuv420_i420.720x480.rar


raw yuv images in UYVY 4:2:2 sample format:

uyvy.352x240.ire.0.0.commercial.soup.rar
uyvy.352x240.ire0.0.commercial.rar
uyvy.352x240.ire0.0.fox61.rar
uyvy.352x240.ire0.0.movie1.rar
uyvy.352x240.ire0.0.sitc.sara1.rar


raw yuv images in YUY2 4:2:2 sample format: (same as YUYV)

yuy2.352x240.ire0.0.commercial.listerine.rar
yuy2.352x240.ire0.0.commercial.progressive.flowers .rar
yuy2.352x240.ire0.0.commercial.wendys.rar
yuy2.352x240.ire0.0.outer.limits.rar
yuy2.352x240.ire0.0.sitc.sara2.rar

I am working on an image programming project, (various color conversion
formulas, and some ideas I have in my head, for example) So, I thought it
was best to start a thread topic in this forum, case I run into some
programming problems, like math and things.

The request ( is no longer needed ) ...

My Purpose or Goal at this time of this tool development:
(has changed direction a little)

1 - To Load in a raw yuv image, in 422, 411 or 420 format, from the storage
formats that are Planar and Packed based.

2 - Also, import RGB bitmap images (user loaded) and convert it to
a raw yuv color space, and further process to the other formats, etc.

3 - At some later date, provide features to analise the images in various ways,
and more, like Filters, etc.

The ordering of the above is not so important, as things can change according
to the tools direction

Thanks for your interests.

From the Video Workstation of,
-vhelp 3602

[edDV]

Because this request has something to do with a specialized
programming project that I am working on, (various color
conversion formulas, plus an idea I want to run some tests
through, that might help us out in some areas like DV.., I think)
So, I thought it was best to start a thread topic in this forum,
case I run into some programming problems, like math and things.

The request is simple ...

Does anyone know how I might be able to produce a RAW image in
YUV color space, and in 4:1:1 sampling, using any freeware apps
(mabe avisynth) or VirtualDUB ??

Or..

Can anyone *post* a few RAW images in YUV color space, and in
4:1:1 sampling ??

(in addition to the inch I'm asking for, maybe take a mile as
well, and as for other RAW "sampling" such as a RAW yuv2 in a
4:2:2 sampling)

Thanks for your assistance,
-vhelp 3602

So you are looking for an image without DV compression? Who has a RGB camera?

Check these links for reference and some original 4:2:2 digital betacam stills.

http://www.nattress.com/Chroma_Investigation/chromasampling.htm
http://www.nattress.com/
http://www.nattress.com/filmEffectsGNicerTests.htm
http://www.nattress.com/GreenScreen422Original.jpg

[edDV]

http://www.adamwilt.com/pix-gens.html#DVStressTest

[vhelp]

Thanks for your interest and response to my request.

I am Sorry for the confusion.. but I ment that I was looking for
an actual RAW image file to download (not a jpeg) .. but an actual
411 Sample image. No BMP header or anything.. just a string
of data to read in and process (convert) to RGB inside my app.

Thanks again.

-vhelp 3603

[borax]

You may try png2yuv or jpeg2yuv from the Mjpeg Tools. Both tools run with cygwin within windows too.

[vhelp]

gee.. this is getting to be a real pain.. trying to find some
raw samples on the internet. I was able to find a couple of
more, but they are in another format that my app will not open
properly.. gives me strange diagnals of the image, pending on
which format I choose.. ie, yv12 yv9 411 and yuy2

But, I think its because I have a different method of reading
in the raw sources.. ie, Planar vs. Packed.

Then, there is the different formats for each, pending on the
mfg's format style.. ie, Brooktree's 411 vs. Other.

Then, there is the question of Headers. Some tools/apps will
incorporate a Header or Leader.. ie, VirtualDUB does this when
your save your source (assuming you choose a 411 or yuy2 or
uyvy codec and save just one frame you get a Header or
something for the file because it is an AVI file.. where the image
or video frames are stored inside a "container". I did try to
hunt down through the test source (file was 128kb) but this did
not work. The image opens, and is readable, but there are bars
everything, or the image is shifted. Anyways. (I was hoping to use
vdub for this, but as it turns on [on accnt of Header] I can not)

Then, I was hoping that AVIsynth could write out RAW yuv files,
but that is not posible at this time. It can only read in RAW
yuv sources. So, it's half way there. Anyways, I'm still
researching other ideas.

In the mean time..

@ Borax

Thanks for your interest too.

Unfortuantely, I can't seem to get the results. I did go to that
web site, but they do not have those two apps you mentioned in
your previous response - thanks. So, I can't try them.

As a reminder, ..remember, I did say I wanted to try other
formats, in addition to the 411 I asked for.
(I revised my main post)

Maybe I'll post a few screen shot of the app at work to get an
idea of the problems (or success) I am having currently with reading
in RAW yuv files.

Anyways. Thanks for putting up with me guys.

-vhelp 3608

[vhelp]

Update to main post.

I made changes to my original post at top of this page, including the
subject title, to match my revised request, etc.

Thank you for your support,
-vhelp 3614

[borax]

You can download my dvdauthor windows binaries... There these appl. are included.

https://www.videohelp.com/~gfd/edcounter.php?file=download/dvdauthor_winbin.zip

[sinan]

Why you prepare an image.
for example for YUY2 format and obtain grey image :
//////////////////////////////////////////////////////////////////////////

unsigned char *index=NULL;
unsigned char *image=(unsigned char*) calloc(sizeof(unsigned char),2*w*h); //w:width, h: heigth of your display window)
for (int i=0;i<h;i++)
for (int j=0;j<2*w;j+=2)
{
index=image+i*j;
if ((j%k==0)(i%5!=0))
image[index]=0; //black
else
image[index]=255;//white
}
/* save image buffer function*/
///////////////////////////////////////////////////////////////////
if you change "if" statement you obtain differen images.
NOTE: This example only for YUY2 format. and I didn't compile it.
this image looks like:


| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

[vhelp]

Thanks sinan, borax and others for your interests and helpful
suggestions with my request

-vhelp 3615

[vhelp]

Just an update..

So far, I have not been able to find any raw yuv images, so that
I can use to gauge and compare against my programming emplementation
debugging.

However, fwiw.. I have continued my own endeavors in tooling up an app
that writes raw yuv images. I was hoping to use already-made yuv
images to be certain that I had the layout right. But that does
not seem to be working out that way.

Now, I am just concentrating on finishing up with getting as many
yuv formats tooled together to further my understanding/knowledge
and video endeavors I have in my plans.

I could use AVIsynth to read in my raw yuv images that my tool made,
but that seems to fail, as it crashs my system completely. Maybe
I will decide on a separate yuv tool that *reads in* only, raw yuv
images. hmm..

In the mean time, perhaps I will post a few raw yuv images (later) for
those curious, and/or want to test for themselves.. hmm.. that's an nice
idea. Maybe I will do that

Thank you all for your interest.

From the Video Workstation of,
-vhelp 3617

[junkmalle]

You could use Graphedit to open a BMP file, convert to various YUV formats (via directshow conversion filters), then dump the video to a binary file.

Nero ships with a color format converter that can convert 24 bit RGB to YUY2 and YV12. That works with GraphEdit.

[vhelp]

Thanks for your instest, junkmalle.

The thing is, my main goal (in this thread topic) is find some
raw yuv images, so that I can use them to comapare with my work.
That is, my process. If *other* tools out there can open my
raw yuv images, than I know that I am doing things correctly.

That is my goal

It would also be nice, if such work did not require *large*
applications, or complicated steps to obtain such things as,
creating the raw yuv images, and/or reading them. But, its
still a good thing too, because you can know your (mine) image
will be read. Anyways.

With that in mind, I was thinking that maybe publish or make
official, such a tool so that others can benefit. But, it won't be
complicated to setup. Just feed it an RGB image, and write out a
raw yuv image. That simple

The way I have it right now, is.. I have two separate apps that:

A) app 1, opens an RGB image and writes out an raw yuv image, and
B) app 2, opens an raw yuv image, and display it on screen.

But, what I want to do, is add more functionality to the tool(s)
and make it more useful. Along the way, learn some things.
I would like to include the feature to write out to most common
formats such as: YUY2 YUVY DV411 UYVY etc. etc. etc.

The functionality I'm on about are those such as:

** Filtering; croping; resizing; color space conversion; etc.
** machanism for frameserving
** and finally, a codec design.. mainly for video archieving.

There you have it. My hopes and ideas, and more. But they will
only work if I have the process correct, hence my (this) thread topic

Again, thanks for your interests.

-vhelp 3618

[junkmalle]

The thing is, my main goal (in this thread topic) is find some
raw yuv images, so that I can use them to comapare with my work.
That is, my process. If *other* tools out there can open my
raw yuv images, than I know that I am doing things correctly.

Yes, I was giving you a way to indepentdently create some raw YUV image data for comparison.

For example, you can open a 24 bit RGB BMP file, send that to the Nero colorspace converter to convert to YUY2, the use the Dump filter to write the raw data to a file.

You'll have to find a 4:4:4 YUV filter yourself!

Maybe this one?:

http://www.leadtools.com/SDK/Multimedia/Direct-Show-Filters/Multimedia-DirectShow-YUV-Transform.htm

[vhelp]

>> You'll have to find a 4:4:4 YUV filter yourself!

Course, you know all this, but..

Well, in theory, I already have the 444 YUV, when my original source
is RGB based. In theory, that is. After all, most images off the
net are .jpg's and even the ones I may create from an AVI file are
not true RGB in the sense they have ALL the color information. Because
they originate from YUV, which could be from a DV411 (my dv devices)
or from whatever capture codec I used. However, if I were to use a
YUY2 (HUFFY) or UYVY (ATI) codec (for instance) then I would have a better
lossless type image to process (play with) for the time being.. my tool
defaults to UYVY422 format when reading/writing such raw yuv files.

Although I was expecting my method of processing to be very slow, it is
not.

The link you provided earlier requires my e-mail address. I have
declined that route because that would mean more spam mail for me.

Thank you for the suggestion though. Appreciated.

-vhelp 3619

[junkmalle]

Temporary anonymous email addresses:

http://www.mailinator.com/

[vhelp]

UPDATE..

I made some progress over the last few weeks. I've been pretty busy
with other day to day life goings. Anyways.

I have a few raw yuv formats that I have converted to and back
successfully.

For those curious or interested, I left some samples of RAW YUV pics
at the top of page one here. So, if you want to test or play around
with these, feel free to download them.

How they were produced:

** Source: TV, Channel WB11-20 (various programs) from my indoor anntenna
** Capture Device: ADVC-100 (dv YUV411 format)
** Converter Tool: no-name brand software I am currently developing

very short history regarding my knowledge of the process:

First, there are virtually no raw yuv images to be found on the internet,
based on my many google searches and requests on these forums for any.
In the end, I had to resort to doing my own in-house image creation, and hope
that I did them correctly. Thus..

Basically, I had to start from the ground up. I left various posts
requesting help in other threads, but in the end, I was pretty much left
to figure it all out for myself. Was upsetting at first, but I didn't let
that stop me. I forged ahead, and decided to just start at the botton,
and one by one, piece by piece, I was able to figure out how to take a RGB
image and convet it to YUV, and apply a sample step to the YUV image, resulting
in the final raw yuv images posted on page one of this topic.

The sampling performed on these images are:
** UYVY and
** YUY2 (same as YUYV)

And, in the process, I learned a few things.

For instance.. it doesn't matter (quality'wise) what pixel format layout is
used in the actual storage to HDD, just so long as you know how to read them
back in to your app, according to the format being used for the image. However,
there are standards to follow. I choose to follow such standards, in image
layout so that other apps/editors, etc will be able to open then successfully.

For instance, take my UYVY and YUY2 pics above. They both use different layouts,
but will produce exactly the same image, pixel for pixel. As long as the sampling
for these two formats [UYVY and YUY2] are used, ..still the same image in the end.

There are other sample formats that I want to learn and incorporate into
my knowledge (and tool) that will follow soon. For example, I would like
to next learn how to apply a 411 sample, and then a 420 sample.

As soon as I learn these formats and build them into my tool, I will post them up
here.

One more thing to note here..

Since I have suffered the long haul of this process, and finding no actual
raw yuv images, I will make an official place or home (perhaps here) to demo
some of these images, as a learning guide or something. This way, a google
search will turn up something meaningful for those future seekers, like myself,
who want to learn about YUV images, etc.

Remember, these are header-less images. Set your apps according to the
format; and resolution; being used. All images are at 352 x 240 pixels for
this demonstration.

Next time, I'll put my signature on future images I post.

Well, it's late. If I made any mistakes during this writing and I catch
them later, I'll make the necessary correction.

-vhelp 3636

[kabaju42]

You know, I found this place with google a couple of days ago, and I have some raw video I could give you, but the message board wouldn't let me post untill now. grrrr, oh well

Would you like me to give you the raw video data anyways? basicly the way it works is several images are put in a stream of data. If you know how big each frame is, you can extract any frame you want. In fact the data itself doesn't tell you a frame rate, you have to put it into whatever program you are using (or in my case, making). I have raw video in I420, YUV9, and RGB24. The pictures aren't exiting, just me moving my head in front of a cheap webcam, but it lets you play with video. All the video has the size of 176*144 (width*height).

I'm posing this because I need help figuring out how the YUV9 format works. I know it's planer, but there is a problem. The Y is sampled 8 bits per pixel. As far as I can tell the U and V planes have one pixel for every 16 Y pixels (again 8 bits/1 byte per pixel). That means the frame/picture of 176*144 pixels should be of size: 176*144+44*36+44*36=28512 bytes. The actual frame size is 28800 bytes. I have 288 bytes un acounted for. Can you or anyone help?

Also FYI, if you look for QCIF video on the internet that is raw video in I420 format in size 176*144 by deffinition. Each frame is of size 38016 bytes. You can find a lot of that, trust me. If you need more information I can help you.

[junkmalle]

I agree, YUV9 looks like it should have two planes of U and V at 1/4 resolution. So you would expect 176x144 in the Y plane, and 44x36 U and V planes. But it looks like the width of the U and V planes may be padded to 48. Maybe the width must be a multiple of 16?

[vhelp]

TGIF everyone

So far, I still haven't found the perfect tool that does it all in
viewing *all* raw yuv format images. So, I continue to pound away
at learning how everything (all these formats) are put together, and
in the process, carve them into a tool for working with such images.

The benefit for everyone might come those that use the tool as an
aid when studying such formats for image process education, etc.

Anyways..

Hay, although I did not specifically mention it, I was also including
those formats as well, YUV9 and YV12, as well as Y41P (planar) and Y411
(a packed) format.

These are also common formats floating around the discussions on the
internet in the things of video de-coders

I was looking at the Y411 format [YUV 411] because it looks interestingly
easy to do (I think) it's a packet format, looking like this,
when writing out to a file stream: U2 Y0 Y1 V2 Y2 Y3 .. .. ..

According to my current knowledge ...

The last time I saw YUV9 and YV12 I had recalled seeing yv12 having
more pixel (U/V) sample detail than YUV9, which is greater distance
in U/V chroma samples than YV12 format. You won't notice much loss
of detail (color info) when you convert to RGB bitmap for viewing,
but it's there, when you understand the U/V sampling machincs.

You could look at it like this, from greatest detail to least:

YUV444 -> YUV422 -> YUV411 -> YUV420
..or..
YUV -> YUY2 -> Y411 -> I420 -> YUV9

The Y411 vs. I420 [or, 411 vs. 420] is contraversal at best. Which
one has greatest (noticable) detail than the other. I don't think
that we may ever find out for sure, cause there will always be a
new argument supporting why the other is least or grestest

But, at this time in place of my understanding, I would believe that
the 411 is better detail than 420 does. But, I suspect that once I have
a grasp at the way *both* are put together, and once I can put them into
a subroutine and lay them out (compress/decompress) to bitmap for viewing
inside my tool, I will have a more accurate answer to which is greater
detail, or not. For now.., I don't know. I'm just going with my gut
instinct on this one. You may disagree

-vhelp 3637

[kabaju42]

TGIS now! ahh the joys of staying up past midnight for no real reason.

Well I'm not about to comment on which video format is best for whatever reason. Right now I'm working on a project where I want to take raw video from web-cams and plug them into a H.263 encoder. I420 is the easiest because that's basicly what the encoder looks for. YUV9 should be the next eaisiet since it's closely related, but since no one seems to know how it's put together it's pretty hard to work with.

For now I've just started working on a coverter for RGB24->I420. The concept is sure easy enough, but I've been working on making the code faster and faster. I want to be able to convert as fast as possible.

[vhelp]

Before I get into it here, I just want to note the whole purpose of
my interests in this process. To learn. To learn how it is all put
together. Speed, is not the important factor here. After all, you
want to know how it all works. If you start using foreing languages,
you loose sight of everything

But, after having learnt how its all put together, is another step up..

>> For now I've just started working on a coverter for RGB24->I420. The concept
>> is sure easy enough, but I've been working on making the code faster and faster.
>> I want to be able to convert as fast as possible.

I'm betting that you are talking c/c++/c# here. I'm Pascal/delphi.

But yes, I would like to make my code faster too. But I can't, because I
don't know any ASM, let a lone, MMX/SSE stuff. But code can be optimized
for a little speedier execution. I realize that for video work like
capturing, you need as fast as possible, like ASM (assembly) code.

Right now, my code is pretty slow. But thats ok, for the moment

But, I think that as long as you don't need to *see* the video doing its
thing, you can make do with code optimization in those places that can
benefit.

My next level of *speed* will be to search out routines (on the web)
that offer code snips in inline ASM for various subroutines.
( I recall many years ago, where this website had housed an arson of
code snips in inline ASM for delphi. They had put out a book, which
I did purchase, bt one day, I threw it out by mistake, ..long time ago.
I could kick myself )

Most of my code are wrapped around equations, ie * / + etc. These are
what's slowing down my methods.. plus my "proper use" may not be most
effective style writing.

The way I have my methods layed out ..

** A - obtain RGB image
** B - convert it to YUV444 color space
** C - apply a sample format
** D - write out contents to a file

..where B and C are what takes the longest to execute/process.
For now, I am ok with the tipicle speed that I have getting

-vhelp 3640

[kabaju42]

Threw it out by mistake, ouch. I guess thats what happens in life.

I actually wasn't really thinking of inline assembly. I suppose I could try it, I've had an introductory course in assembly before, but not enough for really in deep programmine. That's just another story about a lot of wireing (blah). You are about right about my programming though. I'm an electrical engineering student and am acostumed to programming in C/C++. I've never really bothered looking into C#, something about not wanting to limit myself to one platform.

Anyways, back to the story. I'm not doing in depth optimizing, just trying differnt things. For example, most RGB->YUV conversion algorithms reqires mulitplying by floating point numbers. x86 hardware (pentium class) isn't really made for that kind of work. Microsoft give a formula where you muliply by integers and that works much faster.

The other methods I'm going to look into involve the fact that I420 has color planes that are a different size than RGB and the Y plane. Is it faster to put the UV conversion in the same loop or a differnt loop than the Y conversion? Can I get away with not looking at all the pixels for the UV conversion, or do I need to average them to maintain the "best" or even acceptable picture. They're simple methods that you can implement in any language, no worries about changing languages.

[vhelp]

Evening everyone.

>> Microsoft give a formula where you muliply by integers and that works much faster.

Interesting how you brought that up, cause I know I have an integer formula
somewhere's, that I collected from the internet when I was scawering for
any and all kinds of RGB/YUV conversions.

I think that I did try it, but my results were not the same. I'm not sure,
cause it was a while back, in my earlier days of first steps in YUV territory.
Anyways.. I'll have to look for those formulas and try again.

In my yuv tool, I have an "output stats" that outputs a listing of all methods
exicution times. I'll find time to insert such formulas into this process.

But, the yuv tool I'm developing is basiclaly for learning. That's the most
important thing, in the yuv tool's current stage -- though things do change
over time. I mentioned that earlier.


>> Can I get away with not looking at all the pixels for the UV conversion, or do
>> I need to average them to maintain the "best" or even acceptable picture. They're
>> simple methods that you can implement in any language, no worries about changing
>> languages.

My understanding is like this..

It is better NOT to average the pixels, because you will alter the "originality"
of the source by doing this. That is why you are best to start from the top,
and work your way down, when RGB->YUV conversioning. I know I touched on it
somewhere on this forum, but.. this is how one should go about tackling a YUV
conversion process, in this order (IMHO) at this time:

BAD:
YUV444 -> YUV422 -> YUV411 -> YUV420

GOOD:
YUV444 -> (YUV422 or YUV411 or YUV420)

So, if you want to work in 420 you'll have problems maintaining pixel detail
when you consider "originality" as your target. In other words, you don't
want to work with a starting soure that is 420 (unless that is all you have
at the time) ..then you have to consider other methods of format conversions..
i.e., from 420 to 422 etc. for instance, and then back.

I know it sounds crazy, but my gut tells me that you are probably better
off converting from an RGB grid (theory) if your source is 420, and start
at the top, using a YUV444 base. Then, make that your YUV444 -> YUV420,
and NOT go the route of YUV444 -> YUV422 -> YUV420 -- is bad, IMHO.

It's bad because you are first converting to YUV444, then to YUV422, which
is working from the pixels that were left over from the YUV444 -> YUV422
and then to YUV422 -> YUV420 as the final formated pixels. So, lets say
that you start with a YUV444 set of pixels, and you take out some pixles
to make a YUV422. Then, you take the YUV422 who's pixles were already
removed during the YUV444 -> YUV422 conversion, and expect to remove yet
some more pixles to make your final YUV420 formated pixels.

I would rather expend on execution time, and go this route:

YUV420 -> RGB -> YUV444 -> YUV420 is prob better, IMO.

But, the problem is with the speed of exicution. So, some smart users
developed other methods, such as Interpolating, and Pixel Averaging. I
think that theory has it that it will look the same. But, come on..

..averaging will look the same ?? ..I don't know. But, until evidence
say otherwise.. I can't see the hurt in using this as a method, if it
works in your favor, speed'wise. I'm sure there may be methods for
maintaining pixel detail when converting from one format to another,
and back. But, at this time in place, it is not yet time, hehe.

So, there is more to this, but I am still learning this YUV terretory, and
I am learning it from the ground up, without taint from others, teaching
me otherwise, the same practice that they learned by skipping ahead and
missing the finer meanings of things to understand. (Plus, previously, when
I did ask for assistance, some came, but left all too quickly, bailing
out on me in the end) So, instead, I rather start from the bottom (as I have
demonstrated) and see all this as if through the eyes of a child, inacently..
so to speak. If something is wrong, I am bound to find it and/or figure it
out, and correct it.

Currently, I am working on a 411 sampling method, to add in my yuv tool. I
already have a 422 (YUY2 and UYVY format stream) and now I want to have a
411 to add to a format stream.

Then, I will continiue my learning, with 420 sampling stream. And, by the time
I am finshed, I should have capability to make 444, 422, 411, and 420 images,
using common (basic) standard format image streams. All these may end up
being used in yet another on-going (DCT) project (on hold) and a few others.

-vhelp 3643

[kabaju42]

Okay, I'm going to need you to explain to me the convention of what YUV444/YUV420/YUV420/... means. I thought I knew, but 420 proves that I did not.

I'm not sure what you ment by taking the method of converting YUV444 -> YUV422 -> YUV420. I simply want to take whatever format and convert straight to I420. Yes logically it would make sense to go RGB->YUV444->whatever, but it's faster to make the formula go directly where you want.

As for the formula, here is the one I found to be best:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddraw/html/_dxce_c...uv_and_rgb.asp

[vhelp]

Please remember, I'm also a newbie to this stuff. I am learning
as I go.. and I go pretty slow. So, if you are in a hurry, then
I can not help.. as you are jumping past me in my endeavors.

My learning speed is, 444 then 422 then 411 then 420 sampling.
And, as you already know, I am knowledged of 444 and 422 so far


>> I'm not sure what you ment by taking the method of converting YUV444 -> YUV422 -> YUV420. I simply want to take whatever format and convert straight to I420.

I wouldn't worry too much about this route. I was sharing with you, my feeling
about the correct way. I could be wrong.. but I don't think so.

Basically, what I was saying, is that it would be better to convert from a
YUV444 straight to YUV420 if 420 is your final destination.

>> Yes logically it would make sense to go RGB->YUV444->whatever, but it's faster
>> to make the formula go directly where you want.

Yes. It is faster to go directly. I agree. Again, I'm sort of new at this,
and as such, I am bound to make slight errors here and there.

But, going directly, from a "point of origin" is the question here. And
your origin seems to be from a 420 sampling, or I420.

Say your source is already 420 [YUV "I420" 4:2:0] ...

( The "I420" is just a format name for the "stream type" to house the
actual pixels layout inside the file. There are other formats for the
420 sampling. I would choose one that is easier for you to understand
and build. )

If you want to do any filtering and keep it at 420, then there is no
need to convert to RGB, 422 or 444 or whatever, unless your filtering
requires RGB or the method(s) you know of (or are researching) is a
better one, or you want to try -- whatever.

If the filtering you are planning on, is designed for 420, then just do
it inside that sampling (using grids for each component, Y/U/V)

(I'm thinking that you are puzzled somewhere, and need guidance as to where
to start - but I don't know for sure, I'm just getting that sense of feeling
that you are in that stage)

Anyways.

In other words, setup your grids each, for the Y/U/V and do your filters,
i.e., your said you wanted to do U/V filtering. So, inside your U/V grids,
you do your filtering. Then, when you are finished, and if required, put
back the pieces again, into the 420 sampling layout.

Now, I doubt that there are anyone actually doing any filtering inside
a 420 sampling. My guess is that they are UPsampling to 422 to do any
futher image processing.

My belief is this ...

One other reason why (that I can think of or theory here) users will
UPsample a given format.. ( ie, 420 ) to a 422 sample, is because it is
sometimes easier to work with that type of layout stucture. 420 is a
pretty messy layout to work in with filter processes.

So, what I believe is done, is that the 420 gets UPsampled to 422 by
means of Averaging to make duplicates. But, the better method, IMO,
is to just duplicate when UPsampling to 422 for instance. This is my
best guess at what is prefered to approach during the filtering stage.

( At this time, I do not have knowledge of how to take 420 and UPsample
straight to 422 yet -- that *may* come at a later date. You could however,
go the route of 420 -> RGB -> YUV444 -> YUV422, if you want to (or your
filtering methods require) go that route. Otherwise, just do a conversion
this way, 420 -> RGB -> YUV444, and process your image, then from this
convert from the YUV444 -> YUV420 )


I hope I have helped in some way. With a little luck, I should have
a working model for "Y41P" [4:1:1 sampling] to add to my YUV Tool by
tomorrow or so.. hopefully by friday, so that I can demonstrate
more pics (raw yuv) here.. and then move on to 420 sampling.

( if you've seen some of my raw yuv samples above, you might have
noticed how noisy they are. Thanks to my indoor antenna for that.
I doubt that there are any filters out there that can remove those
noise in my pic. But, I had some ideas to help eliminate them. But
I'm not there at that stage yet. )


Last, I will look into the link you posted regarding the "integer
math" method at the MS site.

-vhelp 3644

[kabaju42]

(I'm thinking that you are puzzled somewhere, and need guidance as to where
to start - but I don't know for sure, I'm just getting that sense of feeling
that you are in that stage)

I'm thinking that we are confusing each other, and doing an extreamly good job of it.

Lets start with one simple part. I understand the theory behind RGB and YUV. I understand how, when you work with YUV, the chromessance planes (UV) may or may not be sampled as frequently as the lumenecence plane (Y). I have seen the convention of decribing this as YUV444, YUV420, YUV422 but I do not understand what each of the numbers mean. Will you please help me with this one thing for now.

[junkmalle]

4:4:4 means that for every four Y samples there are four U and four V samples. One example:

YUV YUV YUV YUV...

4:2:2 means that for every four Y samples there are two U and two V samples. They layout can vary but one example is:

YUYVYUYV...

4:2:0 is a little misleading. It doesn't mean that for every four Y samples there are two U and no V samples, or two V and no U samples. It means that the there is one U and one V for every four Y. But it's not the way DV 4:1:1 is layed out, it's usually a planar format with the U and V planes at 1/2 resolution in both dimensions. So a 720x480 image has a 720x480 Y plane, and 360x240 U and V planes.

In other words, 4:4:4 and 4:2:2 refer to the ratio of the Y:U:V components. But 4:2:0 breaks the convetion. Calling it 4:1:1 (which is the actual ratio) would be confusing because of DV uses that to describe it's linear format.

In case you haven't seen it, a good reference is:

http://www.fourcc.org/yuv.php

[edDV]

...

In case you haven't seen it, a good reference is:

http://www.fourcc.org/yuv.php

I agree, it would be much easier to respond to @vhelp issues if he links the questions to what we see on fourcc or another reference site.

[kabaju42]

Thank you, that does clarify the notation. I thought that the numbers refered to a ratio of each sampling, but then I work mainly with I420/YUV420 and it just doesn't make sense to say there is no sampling of the V plane. Again thank you for the clarification.

Also I agree that fourcc.org is deffinantly the best place to go for info. I've gone there many times, but for some reason I just wasn't able to get that small bit of info there.