VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 55
Thread
  1. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  2. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by vhelp
    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
    Recommends: Kiva.org - Loans that change lives.
    http://www.kiva.org/about
    Quote Quote  
  3. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Recommends: Kiva.org - Loans that change lives.
    http://www.kiva.org/about
    Quote Quote  
  4. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  5. You may try png2yuv or jpeg2yuv from the Mjpeg Tools. Both tools run with cygwin within windows too.
    Quote Quote  
  6. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  7. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  8. You can download my dvdauthor windows binaries... There these appl. are included.

    https://www.videohelp.com/~gfd/edcounter.php?file=download/dvdauthor_winbin.zip
    Quote Quote  
  9. Member
    Join Date
    Aug 2005
    Location
    Turkey
    Search Comp PM
    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:


    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
    Sinan
    Quote Quote  
  10. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    Thanks sinan, borax and others for your interests and helpful
    suggestions with my request

    -vhelp 3615
    Quote Quote  
  11. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  12. 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.
    Quote Quote  
  13. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  14. Originally Posted by vhelp
    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
    Quote Quote  
  15. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    >> 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
    Quote Quote  
  16. Temporary anonymous email addresses:

    http://www.mailinator.com/
    Quote Quote  
  17. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  18. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  19. 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?
    Quote Quote  
  20. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  21. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  22. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  23. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  24. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  25. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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
    Quote Quote  
  26. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    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
    Quote Quote  
  27. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by vhelp
    (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.
    Quote Quote  
  28. 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
    Quote Quote  
  29. Member edDV's Avatar
    Join Date
    Mar 2004
    Location
    Northern California, USA
    Search Comp PM
    Originally Posted by junkmalle
    ...

    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.
    Recommends: Kiva.org - Loans that change lives.
    http://www.kiva.org/about
    Quote Quote  
  30. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  



Similar Threads