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 2 of 2
FirstFirst 1 2
Results 31 to 55 of 55
Thread
  1. Member
    Join Date
    Nov 2005
    Location
    Germany
    Search Comp PM
    Hello everybody,

    I wrote a program that can display YUV 4:2:0. It can also show Y, U or V separately. That's what I have done so far.

    My next step is how to convert 444 -> 422 -> 411 ->420. The problem is I don't have any YUV 444 file. So I try to convert my YUV 420 file to 444.

    As far as I know, we have two choices:
    - YUV420 ->RGB -> YUV444
    - YUV420 ->YUV444

    I tried to extract Y, U and V component from 420 and put them in 444 format order. But it doesn't work. Could anybody tell me how to deal with this problem.

    Below are two websites that I got information from. Maybe they are useful for you :

    http://en.wikipedia.org/wiki/YUV_4:4:4
    http://www.fourcc.org/yuv.php
    Quote Quote  
  2. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Instead of trying to start with YUV 4:2:0 or 4:2:2 and working your way up, how about starting with RGB and work your way down?

    You can always create great quality stuff in Adobe AfterEffects and render a series of RGB stills. Then [CONCATENATE] them into a raw video file!?...

    Just a thought.

    Scott
    Quote Quote  
  3. Member
    Join Date
    Nov 2005
    Location
    Germany
    Search Comp PM
    A good news. I succeed with converting YUV420 to BMP. Now I have frames of bitmap files.

    Next step is converting those files to YUV444. Thanks for your advice.
    Quote Quote  
  4. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    UPDATE..

    RAW YUV images in 411 sampling - progress ...

    I was planning on posting some of these raw yuv images for D/L'ing,
    but I haven't found any external apps to use, in testing and viewing
    them. IOW, I cannot guarentee there success rate at this time.

    At the moment, I am now working on the 420 sampling process, and hope
    to have some available. These I can open in AVIsynth, via the revised
    plugin, rawsource - (available on doom9 forum) Unfortunately, rawsource
    does not work in 411 space. So testing w/ this plugin will not be
    possible, and so far, I am not aware of any tools that can open and
    display a 411 raw yuv image at this time. I'm not sure what the latest
    version is, but the one below was pulled from the thread you see also.

    ** DOOM9 Thread: YUV-Bitmap Import filter?
    ** FILE: rawsource_25_dll_20050921.zip

    If I get the 420 sampling working, I will try and post both sample
    formats, plus my newly developed YUV Tool, by TGIF.

    -vhelp 3660
    Quote Quote  
  5. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    UPDATE.. #3 - (new image additions.. YUV420 [ i420 ] )

    After a long two to three week battle with 420 color space and
    the i420 sample format, I have finally nipped it in the budd,
    again w/out any help or anyone's guidance. Oh well.

    (I had the U/V swapped in *this* format, when it should have
    been V/U -- got my colors all mixed up -- made everything blue)

    There were things I wanted to do, and include in this latest package,
    but time was not with me, and my eyes are waring me down at the
    moment.

    As for the YUV Tool, you'll have to wait till I have the 411
    nailed. As you may recall, I put it on hold on account of the
    lack of YUV411 viewing inability. (There are no tools out there
    that I am aware of that can view 411 raw yuv images -- if you know
    of any, please give a hollar, thanks)

    Later, I might start scupturing some filter features (maybe) as
    I have been slowly puffing up ideas, but I don't want to spoil
    the enthosiasm (spelling) I have so far. Until then..

    Keep an eye out for my signature, where I keep links and things.

    (see first page for *all* file D/L's)

    -vhelp 3670
    Quote Quote  
  6. Originally Posted by vhelp
    After a long two to three week battle with 420 color space and
    the i420 sample format, I have finally nipped it in the budd,
    again w/out any help or anyone's guidance.
    Could you post your source code or the specs for the different formats as you've determined them? You could save the next person a lot of trouble. Thanks!
    Quote Quote  
  7. Member
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    What was your problems with the colors? When I was converting RGB to YUV420, then I had problems where everything had a red tinge to it, but when I found the right formula, then everything worked fine.
    Quote Quote  
  8. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    What was your problems with the colors? When I was converting
    RGB toYUV420, then I had problems where everything had a red tinge to it,
    but when I found the right formula, then everything worked fine.
    My problem was with the U/V planes. They were not in the correct
    order. They were swapped around like this, U/V. But, then were
    suppose to be V/U (for this format) ..but, there is another variation,
    and other YUV tools *do* open them when I arrange the planes as U/V.

    Thus, it is a matter of *which* tool you use to open and view such
    raw images.

    So, if using AVIsynth on the i420 images I posted on the first page,
    the planes have to be, V/U ordered.. otherwise, for other tools, U/V
    ordered.

    My problem was this. I was using only *one* tool to test verify my
    results. And, because I had my planes in U/V order, the image would
    come out sort of blue. Sometimes other colors, depending on your
    image's total number of colors (or something like that)

    Because of this, I will post a few pic for U/V ordered planes, so that
    those who have other tools that read them this will, will receive the
    expected results. I will post those a bit later.

    Actually, I had it all right from the beginning, when I first embarked
    on this (in replacement of the 411 format) except for the wrong plane
    orders When I look back on it, it *was* rediculously easy to
    emplement though. But, I think that reason for that was on account of
    not going about it through common practices/methods.

    -vhelp 3672
    Quote Quote  
  9. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    UPDATE.. #4 - (new image additions.. YUV420 [ i420 ] )

    These images are rather large and in odd sizes.

    I decided to add another set because of the fact that the planes can
    be swapped around, and I hadn't realized that at first. In the previous
    i420 sample images in my last installment, had those planes in Y/V/U order.
    But, this time around, they are in Y/U/V order.

    Regarding the odd sizes <-mod4 and <-mod2 ...

    Those images you run across with outside i420 constraints, don't worry
    so much about the odd green or blue lines you might see on top or bottom
    of such images. This is normal for these home-made images I made w/ my tool,
    and are on account of the crude method I used to pad outside range for i420
    formats. They are not so important for these demos. And in real-world
    scenarios, one could easily crop/padd to work around such nonsense.

    REFERENCES:

    Also, you should be able to open these inside an AVIsynth script by using
    the plugin, rawsource() which can be found on doom9 web site. I posted
    the link above, in a previuos post, case you're looking for it.

    There is also another tool that can open these i420 format images.
    Look for a tool called, YuvFilePlayer.exe v1.1 rel 27.1.2005
    by Gary J. Dickson, on Google. It is pretty user configurable.

    Until I can finish creating an official YUV tool of my own to coinside with
    these yuv discussions, these should work perfectly well for my raw yuv images.


    In a manor of speaking, this topic is sort of turning out to be a
    Lab Exploration and Lesson. Anyways.. enjoy the image demonstrations.

    (please report any broken links, if you find any)

    From the Video Workstation of,
    -vhelp 3673
    Quote Quote  
  10. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    Evening everyone

    At this point in my development and because of the rather large mangled
    spagetti, pulling code snips would be a laborous chore at best. I am
    not one who practices good code grooming.

    But here's what I came up with, (basically) to solve my UV planes issues
    (i420 format) with those viewers (I mentioned in my previous post above)
    who are reading these raw yuv U/V data. And in addition, I've
    listed my order of process, if that helps others trying to acheive the
    conversion route.

    In pseudo-code language:

    procedure openBitmap();

    procedure RGB_YUV444();

    procedure YUV444_uyvy();
    procedure YUV444_yuy2();
    procedure YUV444_y411();
    procedure YUV444_i420();

    procedure writeYUV();
    begin

    // write out Y_Block
    write(f, Y_Block, yBlockSize);

    // write out U and V blocks
    if _uv then
    write(f, U_Block, UBlockSize);
    write(f, V_Block, VBlockSize);
    ..else
    write(f, V_Block, VBlockSize);
    write(f, U_Block, YBlockSize);

    end;


    As to the formatting of the various sampling ...

    They are (in so many words) rediculously easy to put together.

    (the secret is simple. Just follow the dots, if you get my drift)

    I can't tell you how many times I stared at my charts and grids
    all this year along, (day-dreaming of one day puting them all
    together - thank you, procrastination) before finally taking the
    plung and doing the actual work and making the various image formats.
    But, in order to realize the validity of your work (my work) you
    need to have the tools to bring the images to life.
    (see closing notes)

    What took me so long, was on account of finding these tools (or
    viewers) to verify my methods of processing these image formats.
    I searched and searched the internet for such tools, but could not
    find any, except for one or two. But even they are limited in their
    image formats for viewing. Currently today, I am still troubled by
    my inability to view certain formats. But I press onward.

    Course, my next step (after aquiring all the necessary tools to
    view *all* the yuv formats) is to *code* my own methods/routines
    to view these images, rather than relying on other tools.
    Then, (I'm sure) it won't be so "rediculously easy" to do

    (I'm thinking that the 420 formats will be the most difficult to
    accomplish, but we shall see, in the comming months ahead)

    My current understandings for the 420 OUTPUT recreation ...

    Mind you, this is off the top of my head.

    You have 4 [Yxx] values, and for every 4, you have a U and V
    that share these same pixels. But that they share (between) each row,
    (or steps) like this:

    (remembering that you have three planes to keep track of)

    line 1 - [y00][y01][y02][y03] ..
    line 1 - [u00][u02]
    line 1 - [v00][v02]

    Then, later in the final large image...

    ...LINE 1... . ...LINE 2...
    ([y00][y01]).u.([y10][y11])
    ([y00][y01]).v.([y10][y11])

    IOW, you have think each u/v pair as a single pixel, (to complete
    and image) but that requires 4 [Yxx] pixels to recreate the total
    image (per pixel) or, yyUyy.yyVyy = one pixel image

    Now, moving on in this project..

    I really want to work that 411 format because I have at least two
    image formats that I struggled with, and I feel that they work.
    But I haven't been able to find any viewers (nor plugins) that can
    read raw yuv411 images, and the closest I came to this, was with
    AVIsynth's plugin, rawsource() ..but it lacks the 411 format
    at this time.

    -vhelp 3675
    Quote Quote  
  11. I'm more interested in what you did in converting from 4:4:4 to 4:2:0 colorspace and vice versa. Did you avergage together 2x2 blocks of U and V values to go from 4:4:4 to 4:2:0?

    Code:
    Y1U1V1 Y2U2V2
    Y3U3V3 Y4U4V4
    
    Y1 Y2
    Y3 Y4
    (U1+U2+U3+U4)/4
    (V1+V2+V3+V4)/4
    Did you do some more sphistocated filtering (bicubic, lanczos, etc)?

    When going back to 4:4:4 do you duplicate the the U and V values for all four pixels? Or do you try to do some sort of interpolation?
    Quote Quote  
  12. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    I need to remind you, I am not an expert at this. Although I've had
    (some) knowledge in this area, this is my first time taking the plunge.
    So, please try not to quote me as if an expert. That would be unfair

    I'm more interested in what you did in converting from 4:4:4 to 4:2:0 colorspace and vice versa. Did you avergage together 2x2 blocks of U and V values to go from 4:4:4 to 4:2:0?
    No. Where did you get that from ?
    Why would I want to do that (average) inside this step, for no good ??
    (maybe if I was already *inside* a subsampling routine, there might be
    some weight to this - I think.. but I don't know for sure)

    IMO, and at this point in conversion, (rgb->yuv) all I would be doing is
    chainging the image detail. Anyways.

    Did you get a chance to verify my raw yuv images ??
    If you would like for me to create *other* images for you to run your
    own tests with, feel free to ask, and I'll create them. In the mean time.

    My thoughts on this averaging ...

    From my memory of reading, regarding upsampling (which I am not at, yet)
    this is when you make use of the "averaging" of pixels. (but I don't
    agree with this, probably on account of my misunderstanding of something)

    Anyways.

    As I was saying.. my understanding with "averaging" of pixels, was that
    it was to help with the upsampling to keep as much of *all* detail as
    possible. But I may be wrong on this. I'm basing this on memory.

    At least in the steps I took to process from rgb->yuv444->yv12 did not
    include any steps to average. It is absolutly unecessary, unless you
    are factoring in the chroma-bleeds (or whatever phenomina that people
    refer to this issue as) in the red (which I'm studying now)
    (didn't I include some images with some red in it? ..I thought I did)

    Thanks for your interest in my raw yuv image creation.

    Cheers,
    -vhelp 3677
    Quote Quote  
  13. So you're just subsampling the U and V components (nearest neighbor) to convert from 4:4:4 to 4:2:0? Something like:

    Code:
    four pixels of YUV 4:4:4
    
    Y1+U1+V1 Y2+U2+V2
    Y3+U3+V3 Y4+U4+V4
    
    converted to YUV 4:2:1
    
    Y1 Y2
    Y3 Y4
    U1
    V1
    Quote Quote  
  14. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    hmm.. I'm curious as to your great interst in my YUV project.

    If you don't mind my asking, ..Why ?

    Continuing on ...

    What I want to inlude as test, is learn the process of putting
    together the various YUV formats.

    (I am doing this from scratch, without any taint or commong practice
    found on the web or other. I stated this earlier in this topic, and
    I have my reasons. As such, you may not agree with my method/process,
    based on your own belief or experience, or whatever)

    As I was saying.. I need to know how to create the yaw yuv images first,
    before I start mucking about with other advance menovers.

    Then, my next step is to analize the results. (which I have started
    doing, here and there a little) And, in order to do this successfully,
    I have to have the tools to *view* them, so that I can guage my work
    for accuracy. I can't do this blindly. That is why I delayed sharing
    my 411 images. I have uyvy; yuy2; i420 formats, tested successfully,
    and available for D/L'ing and viewing (and running your own set of
    tests on them)

    Then, my next steps will be to use a stream or sequence of RGB origin,
    using the following receipe:

    ** obtain several RGB bitmaps
    ** conver them all to YUV images ea.
    ** process to given format.. ie, YV12 [ie, i420]
    ** review the results of the quality level for the entire sequence

    Later, I will add to my knowledge, by experimenting on more advance
    processes, such as the ones you question in your previous post..
    and more.

    -vhelp 3678
    Quote Quote  
  15. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    I hope you understand where I am at in this endeavor. I am not
    an expert.

    Getting back to your questions ...

    Code:
    four pixels of YUV 4:4:4 
    
    Y1+U1+V1 Y2+U2+V2 
    Y3+U3+V3 Y4+U4+V4 
    
    converted to YUV 4:2:1 
    
    Y1 Y2 
    Y3 Y4 
    U1 
    V1
    >> converted to YUV 4:2:1

    First, I want to say, no. I am not converting to 4:2:1 samples.
    I am converting (processing) to 4:2:0 samples.

    If I had, (ie, my images you seem to be basing on) then those would
    not work inside any 4:2:0 viewer. At most, you would get bad lines
    or funky colors.

    FWIW ...

    (I used AVIsynth plugin, rawsource() to view those that are V/U planes
    because this filter's method of processing the U/V planes are swapped)

    (I used YUV Viewer tool to view those that are U/V planes)

    Later on, I will be creating *my own* yuv tool to view. And from there,
    I will build upon it, other useful features. But until then..

    (be right back) ..

    -vhelp 3679
    Quote Quote  
  16. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    back to your question..

    Code:
    four pixels of YUV 4:4:4 
    
    Y1+U1+V1 Y2+U2+V2 
    Y3+U3+V3 Y4+U4+V4
    No. The way I see your layout above, ..is wrong to me



    Think in terms of grids. That was my approach. No more math.
    They are not only too confusing to visualize as well as to work
    out in understanding of the process completely, but are also too
    slow for my methods of process.

    Here is a 4x4 pixel bitmap, broken down into R/G/B components.

    [R00][R01][R02][R03] .. [G00][G01][G02][G03] .. [B00][B01][B02][B03]
    [R04][R05][R06][R07] .. [G04][G05][G06][G07] .. [B04][B05][B06][B07]
    [R08][R09][R10][R11] .. [G08][G09][G10][G11] .. [B08][B09][B10][B11]
    [R12][R13][R14][R15] .. [G12][G13][G14][G15] .. [B12][B13][B14][B15]



    And, when converted to YUV 4:4:4, would look like this.
    (fill in the rest of the Y/U/V components here)

    [Y00][Y01][Y02][Y03] .. [U00][U01][U02][U03] .. [V00][V01][V02][V03]
    ..
    ..


    This is the first level of the conversion process (rgb->yuv) and is
    a 4:4:4 color space, and whos sampling *too* yv12 has been decided
    upon, and is the next step in the process.

    Now, I would like you to process this into yv12 format.. remembering
    that this is to be in a 4:2:0 color space, and utilizes one of the
    fourCC signature format.. i.e., i420 is one favorite of many, and is
    Planar based. Don't forget, there is also Packed based. But you
    use whatever you think is best for this workshop.

    Then, show me what you got

    If you can turn up an image, rgb->yv12, and then decode/read it back
    in as a bitmap successfully, then you pass. Congradulations.

    Cheers,
    -vhelp 3680
    Quote Quote  
  17. Member
    Join Date
    Nov 2005
    Location
    Germany
    Search Comp PM
    I succeed converting from YUV 420 Planar to RGB and from RGB to YUV 420.
    All you need is the converting matrix. If you convert YUV to RGB then you have to limit the output values from 0 ->255
    Quote Quote  
  18. Member
    Join Date
    Nov 2005
    Location
    Germany
    Search Comp PM
    -------------------------------------------------------------------------------------
    Here is a 4x4 pixel bitmap, broken down into R/G/B components.

    [R00][R01][R02][R03] .. [G00][G01][G02][G03] .. [B00][B01][B02][B03]
    [R04][R05][R06][R07] .. [G04][G05][G06][G07] .. [B04][B05][B06][B07]
    [R08][R09][R10][R11] .. [G08][G09][G10][G11] .. [B08][B09][B10][B11]
    [R12][R13][R14][R15] .. [G12][G13][G14][G15] .. [B12][B13][B14][B15]



    And, when converted to YUV 4:4:4, would look like this.
    (fill in the rest of the Y/U/V components here)

    [Y00][Y01][Y02][Y03] .. [U00][U01][U02][U03] .. [V00][V01][V02][V03]
    ..
    ..
    ------------------------------------------------------------------------------------

    I think this is not the correct YUV444 format.
    Here is the correct one, the same as the one that junkmalle posted

    http://en.wikipedia.org/wiki/YUV_4:4:4
    Quote Quote  
  19. Originally Posted by vhelp
    And, when converted to YUV 4:4:4, would look like this.
    (fill in the rest of the Y/U/V components here)

    [Y00][Y01][Y02][Y03] .. [U00][U01][U02][U03] .. [V00][V01][V02][V03]
    ..
    ..


    This is the first level of the conversion process (rgb->yuv) and is a 4:4:4 color space, and whos sampling *too* yv12 has been decided upon, and is the next step in the process.
    That "next step" is what I've been asking about.

    Using your internal format to represent a 2x2 pixel image in YUV 4:4:4:

    Code:
    Y00 Y01 .. U00 U01 .. V00 V01
    Y10 Y11 .. U10 U11 .. V10 V11
    To convert to 4:2:0 format you need to reduce this to:

    Code:
    Y00 Y01 .. U00 .. V00
    Y10 Y11
    How are you reducing the Y and U planes to 1/2 (each dimension) resolution? Are you just picking one of the four values? Are you averaging together the 2x2 groups of values to make a single value? Something more sophisticated? Have you found a document that specifies it should be done a particular way?
    Quote Quote  
  20. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    Evening everyone

    First, a personal note to all participating on this topic..

    Not that its a problem, but that we *are* trying to explaine our
    xyz's from different points of view. We are not wrong, but we seem
    to be talking about several diffenet points or aspects, though we are
    all on one subject Ok.



    Y1U1V1 Y2U2V2
    Y3U3V3 Y4U4V4

    Y1 Y2
    Y3 Y4
    (U1+U2+U3+U4)/4
    (V1+V2+V3+V4)/4

    >> Did you do some more sphistocated filtering (bicubic, lanczos, etc)?

    No. I am not resizing my images (least not the ones I posted on page one)
    (filtering is my next stage - ie, chroma bleeds and other phenominas)



    >> When going back to 4:4:4 do you duplicate the the U and V values for all
    >> four pixels? Or do you try to do some sort of interpolation?


    The answer is no. But only because I am not "decoding" the i420 image
    internally. I am not decoding i420 images at all. (not at this time)

    AVIsynth's plugin, rawsource() and the YUV Viewer tool (mentioned
    previously) are doing the decoding, (if you are basing your observations
    and questions from these tools) -- If you have an issue with the nature
    of the decoding, perhaps you should address your questions to the aurthors
    of those tools. I am only the creator of the raw images.. that is all

    Regarding your averaging points above. I am not at that level in my
    raw yuv image creations. The reason for this is on account of the fact
    that I am not sub-sampling to and from one sub-sample to another. I am
    simply going direct, which seems to be the logical approach.. from this
    point, RGB->YUV420.i420 format.

    How I get there, method'wise, should not matter. As long as the
    decoder reads and processes them, is what counts. And if such tools
    succeed, then we know what we are doing

    But, I suspect that maybe you are doing it wrong (in your thinking)
    It seems some of you are thinking that the proper way to go about
    creating a single format.. [ie, i420] is to go about like this:

    RGB->YUV444->YUV422->YUV420.i420

    (this is leaving me the impression the there are TWO sub-sampling
    passes)

    That is not how (at least not to me) you are suppose to process. You
    can, but its extra work, *and* reduces your image detail (chroma)
    further.. because you are first sampling from 444 to 422, which takes
    away certain U/V pixels. Then, you are again, sub-sampling down to
    420, which takes away *again* some more U/V pixels, (assuming that one
    does not incorporate 'duplicating' in the right place, U/V chroma for
    the sub-sampling methods. I am assuming that this is not the case here,
    or interpolation, which is the same to mean, 'duplicate'.

    If you are designing an image for i420 (YV12 format) then the proper
    way (as I see it) of processing is:

    source[RGB]->YUV444->YUV420.i420

    (this is the way I have been doing them - one pass)

    And the reason for the YUV444 is because you need an original YUV
    format to start from, so that you can do the further processing of
    reducing (sub-sampling) from it, certain components (U/V) etc.

    (YV12 seems to be used 'generically' throughout many discussions. I am
    simply using i420 as the final image format, in this discussions)

    Although I am not in this situation yet with any of my raw images posted
    on page one, processing a sub-sampling from an already 'sample' position
    is another story. And I will deal with it, when I get to that point
    in my on-going yuv development -- my yuv tool.

    (some more boring stuff follow, in my next post) ...

    -vhelp 3681
    Quote Quote  
  21. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    no - How are you reducing the Y and U planes to 1/2 (each dimension) resolution?
    no - Are you just picking one of the four values?
    no - Are you averaging together the 2x2 groups of values to make a single value?
    no - Something more sophisticated?
    The Y's are not reduced. They are the same, as with all the other
    formats based on a 4:n:n sampling, though some are samples at different
    points..

    [ie, yuy2 uses 2-Y's per chroma pair, but we process 4-Y's to complete
    the 'sample' using 2 chroma pairs = 4 macro pixles, or 2-Y's/chroma
    pair = 2 macro pixels]

    Example: A - YUY2 format

    (these are two Y's with 1 chroma pair = 2 macro pixels)

    Code:
    ..00 ..01 ..02 ..03 ..04 -> stream .. -> .. ->
    [y00][u00][y01][v00]..

    Example: B - RAW 411 format, (one of several forms)

    (these are four Y's with 1 chroma pair, and to complete the 411 image,
    you would process the whole 'width' of chroma pairs for each line,
    per 4-Y's. Using my sub-sampling calculator.. given a width of 8 pixels
    would require 2 chroms pairs to complete each line's width)

    Code:
    ..00 ..01 ..02 ..03 ..04 ..05 ..06 ..07 ..08 ..09 ..10 ..11 ->
    [y00][y01][y02][y03][u00][v00][y04][y05][y06][y07][u01][v01]..

    ..continuing my responses to your questions..

    again, no averaging is done on these images (nor my method, yet)
    (see my notes in next post on averaging)

    And no, I am not averaging 2x2 pixles.

    In this demo version of the i420 raw images, no sophisitcatedness
    going on. But that may change elsewhere in the chain of events.

    Have you found a document that specifies it should be done a
    particular way?
    Yes, and no. But, I can't recall the URL link. I'll see if I
    can find it again. But I don't think it is necessary. The images
    I have on page one here, is proof enough that I have this format
    nailed down.

    (some more last minute boring stuff follows, in my next post) ...

    -vhelp 3682
    Quote Quote  
  22. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    Ok. I did a little further studying and researching on this item
    of confusion here.. "averaging"

    The whole purpose of this averaging was designed for when you need
    to upsample from various "sub-sampling" formats, one to another,
    and/or back. The advantage of this is suppose to (in theory) help
    eleviate the side-effects (ie, chroma bleeds) from this bouncing around
    from one sub-sample format to another, and/or back. I am basing this on
    my latest research that I finished up on today.

    For this purpose, and only, is averaging of certain pixles (Y/U/V) to
    minimize certain side-effects that results from the decoding of the
    chroma components (the Y component also plays in the issue, but it is
    not the single cause - the U/V's are)

    Now I have to get back to my work.

    Cheers,
    -vhelp 3683
    Quote Quote  
  23. Originally Posted by vhelp
    no - How are you reducing the Y and U planes to 1/2 (each dimension) resolution?
    no - Are you just picking one of the four values?
    no - Are you averaging together the 2x2 groups of values to make a single value?
    no - Something more sophisticated?
    The Y's are not reduced. They are the same, as with all the other
    formats based on a 4:n:n sampling, though some are samples at different
    points..
    Obviously that was a typo on my part. I meant how are you reducing the U and V planes?

    Originally Posted by vhelp
    again, no averaging is done on these images (nor my method, yet)
    (see my notes in next post on averaging)

    And no, I am not averaging 2x2 pixles.

    In this demo version of the i420 raw images, no sophisitcatedness going on. But that may change elsewhere in the chain of events.
    Starting with a 4:4:4 YUV image you have four Y's, four U's, and four V's for every four pixels. When you convert to 4:2:0 format you still have four Y's but only 1 U and 1 V. All I'm asking is how you get rid of three U's and three V's? It sounds like you are just arbitrarily keeping one U and one V, and throwing away the others.
    Quote Quote  
  24. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    >> It sounds like you are just arbitrarily keeping one U and one V, and
    throwing away the others.


    Yes. And that isn't a bad thing.
    (I noted this several times -- oh well) :P

    -vhelp 3684
    Quote Quote  
  25. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    @ all those who are following with interest..

    First, I found an error. Not exactly an error, but close to it.
    More like a misslabeling of image format. I did not realize my
    first installment of raw yuv images for i420 were in fact, YV12
    format, hence the v/u chroma order of these raw yuv images.

    Also, AVIsynth's plugin, rawsource() does handle both formats
    i420 and yv12, as they are the same, with the exception that the other
    has it's chroma planes are swapped.

    Because of this, and because of the filenames being labeled incorrectly
    in my i420 first release, I will re-introduce new raw yuv images in YV12
    format, and of course, proper naming/commenting, etc. The .rar files
    are commented with mention of the format being i420 by mistake.

    On another note..

    fwiw, I have been doing some research (lots of reading) on this
    'averaging' step. I am not entirely sold on the necessisity of
    usage inside a sampling step ( specially when the source files is
    source[RGB]->YUV444->YUV420.YV12 ) But, I will consider plans to
    emplement as a feature/option, to sample sources with [average=on/off]
    and experiment with different values or averaging methods, with
    some depicture of differences between such processed images of
    before and after.

    The way I see it, there are different aspects or purposes in using
    'averaging' inside a sampling step. And, I am theorizing, based on
    my research/thinking/ideas that there may be certain methods of
    'averaging' that may work better in some cases than others.

    Also, I am working on revising my yuv tool to bring as WYSIWYG
    yuv sampling real-time, for easier visualization of the process,
    and for educationsl purposes.

    As an example of what I am on about, below is a taste of what I
    have been invisioning of this YUV endeavor, since I started on it
    back in April/2005 this year.

    In it's prehistoric first stage, it is a part of my yuv tool that I
    am slowly working on. I have plans to emplement this sort of real-time
    viewing for all the sub-sampling formats. So, I am hoping to be able to
    accomplish this with no trouble. But we shall see.

    In the mean time, I continue to have lots of ideas that I want to implement
    into this tool, and I can't seem to stop them from flowing. Oh well.
    Anyways. But this is all I'll share with you regarding the tool,
    for now

    WYSIWYG real-time view of sub-sampling positions -- an idea



    Until then, see you next time, when I U/L new raw yuv image in
    YV12 format, and with/without 'averaging' applied. (I have to
    first emplement it into the yuv tool, and I'm not sure just how
    easy it will be. I'll think about it tomorrow)

    -vhelp 3685
    Quote Quote  



Similar Threads