View Profile
View Forum Posts
Private Message
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
+ Reply to Thread
Results 31 to 55 of 55
-
-
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 -
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. -
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 -
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 -
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!Originally Posted by vhelp
-
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.
-
My problem was with the U/V planes. They were not in the correctWhat 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.
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 -
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 -
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 -
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?
Did you do some more sphistocated filtering (bicubic, lanczos, etc)?Code:Y1U1V1 Y2U2V2 Y3U3V3 Y4U4V4 Y1 Y2 Y3 Y4 (U1+U2+U3+U4)/4 (V1+V2+V3+V4)/4
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? -
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
No. Where did you get that from ?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?
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 -
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
-
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 -
I hope you understand where I am at in this endeavor. I am not
an expert.
Getting back to your questions ...
>> converted to YUV 4:2:1Code: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
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 -
back to your question..
No. The way I see your layout above, ..is wrong to meCode:four pixels of YUV 4:4:4 Y1+U1+V1 Y2+U2+V2 Y3+U3+V3 Y4+U4+V4
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 -
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 -
-------------------------------------------------------------------------------------
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 -
That "next step" is what I've been asking about.Originally Posted by vhelp
Using your internal format to represent a 2x2 pixel image in YUV 4:4:4:
To convert to 4:2:0 format you need to reduce this to:Code:Y00 Y01 .. U00 U01 .. V00 V01 Y10 Y11 .. U10 U11 .. V10 V11
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?Code:Y00 Y01 .. U00 .. V00 Y10 Y11
-
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 -
The Y's are not reduced. They are the same, as with all the otherno - 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?
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.
Yes, and no. But, I can't recall the URL link. I'll see if IHave you found a document that specifies it should be done a
particular way?
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 -
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 -
Obviously that was a typo on my part. I meant how are you reducing the U and V planes?Originally Posted by vhelp
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.Originally Posted by vhelp -
>> 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 -
@ 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
Similar Threads
-
muxing raw h264 with raw g711 to mp4 continer
By niror in forum Newbie / General discussionsReplies: 5Last Post: 23rd Aug 2011, 11:25 -
yuv 420 Progressive Videos
By niranjan in forum Video ConversionReplies: 2Last Post: 30th Jun 2011, 01:09 -
MXF XDCAM HD 422 loses stereophony?
By elmuz in forum Video ConversionReplies: 0Last Post: 2nd May 2011, 05:29 -
ProRes 422 (LT) 4.29GB wont open
By RenderFi in forum MacReplies: 8Last Post: 11th Dec 2010, 09:54 -
1.067 to 1.422 ????
By paulwilko in forum Newbie / General discussionsReplies: 7Last Post: 15th Aug 2008, 13:24