Color Space YUV vs RGB
Pat
fogging my brain. There are rules and exceptions to rules. Let me throw out
some rules for clarification:
(1) MPEG-2 always uses YUV color space.
(2) DV Camcorders always record in YUV Color Space, but there could be a few
exceptions.
(3) RGB is needed because computer monitors and many video applications (ie.
Video Editors) only use RGB Color Space.
(4) Its possible to completely process DV in the YUV Color Space, if you
stay away from the pitfalls of RGB conversion. Many applications only use
RGB (eg. Video Editors, Virtual DUB), but others like AVI Synth have the
option tolet you stay in YUV Color Space. Also, CCE and other MPEG encoders
accept YUV as input, with no RGB to convert.
(5) Its possible to archive an AVI file, by writing it to a Camcorder's
MiniDV tape, that is either RGB or YUV Color Space.
(6) DV Capture programs (eg SCENALYZER) often transfer a MiniDV tape's
contents to an AVI file AS_IS so the Color Space will be whatever it is on
the tape.
(7) An AVI file will always have a FOURCC code assigned to it and the
contents is what the code states:
DV VIDEO: http://makeashorterlink.com/?D267516E5
YUV VIDEO: http://makeashorterlink.com/?Z177126E5
OTHER VIDEO SUBTYPES: http://makeashorterlink.com/?T287616E5
That's Seven, I'll stop there!
RGBaker
Not sure you couldn't use RGB colour space for MPEG2, but don't see that you
would want to ...
> (2) DV Camcorders always record in YUV Color Space, but there could be a
few
> exceptions.
I think here there are no exceptions -- YUV colour space is what DV is.
> (3) RGB is needed because computer monitors and many video applications
(ie.
> Video Editors) only use RGB Color Space.
The more clever NLE apps (video editors) will work in YUV colour space if so
configured ...
> (4) Its possible to completely process DV in the YUV Color Space, if you
> stay away from the pitfalls of RGB conversion. Many applications only use
> RGB (eg. Video Editors, Virtual DUB), but others like AVI Synth have the
> option tolet you stay in YUV Color Space. Also, CCE and other MPEG
encoders
> accept YUV as input, with no RGB to convert.
See above
> (5) Its possible to archive an AVI file, by writing it to a Camcorder's
> MiniDV tape, that is either RGB or YUV Color Space.
DV is YUV, so you can't archive to DV as RGB
> (6) DV Capture programs (eg SCENALYZER) often transfer a MiniDV tape's
> contents to an AVI file AS_IS so the Color Space will be whatever it is on
> the tape.
Firewire or DV capture programs by definition transfer DV tapes to an avi
file as is ... conversion to RGB, if configured to happen, happens only
during an interim processing stage, and then only for material being
manipulated, and only while being manipulated (work space, as it were) ...
the final step of encoding to DV (necessary for it to be DV, so to speak) by
necessity requires a YUV result.
> (7) An AVI file will always have a FOURCC code assigned to it and the
> contents is what the code states:
>
> DV VIDEO: http://makeashorterlink.com/?D267516E5
>
> YUV VIDEO: http://makeashorterlink.com/?Z177126E5
>
> OTHER VIDEO SUBTYPES: http://makeashorterlink.com/?T287616E5
Though all true, I'm not clear on the relevance -- the description of YUV
video & other video is not DV.
GB
Richard Crowley
> (3) RGB is needed because computer monitors and many
> video applications (ie. Video Editors) only use RGB Color Space.
Perhaps you should clarify what you mean by "is needed".
"is needed" for what?
For storage? - "DV storage" is YUV by definition. Period.
For transmission? - DV/Firewire transmission is likewise YUV.
For processing? - software can be written to process in any transform
For display? - The only place where RGB is really "required".
I can't think of ANY color display technology that does NOT use RGB.
Counter-examples, anyone?
Wilbert Dijkhof
Richard Crowley wrote:
>
> "Pat" wrote ...
> > (3) RGB is needed because computer monitors and many
> > video applications (ie. Video Editors) only use RGB Color Space.
>
> Perhaps you should clarify what you mean by "is needed".
> "is needed" for what?
> For storage? - "DV storage" is YUV by definition. Period.
> For transmission? - DV/Firewire transmission is likewise YUV.
> For processing? - software can be written to process in any transform
> For display? - The only place where RGB is really "required".
Processing: Most video editors require RGB input (except AviSynth
which can also handle YUY2/YV12).
To the OP, the rest of your points are correct.
Wilbert
Simon Walters
"Pat" <Hotp...@hotmail.com> wrote in message news:yF69b.2764
> (5) Its possible to archive an AVI file, by writing it to a Camcorder's
> MiniDV tape, that is either RGB or YUV Color Space.
Don't think so - DV isn't/can't be RGB AFAIK.
regards
Simon
Simon Walters
"Wilbert Dijkhof" <w.j.d...@tue.nl> wrote in message
news:3F65AC0C...@tue.nl...
> To the OP, the rest of your points are correct.
What about no 5?
regards
Simon
Pat
"RGBaker" <g...@bakerfilms.com> wrote in message
news:6P79b.442$hF3.2...@news20.bellglobal.com...
> > (1) MPEG-2 always uses YUV color space.
so
> configured ...
I believe Vegas 4 only processes in the RGB domain. What about Avid Express?
Adobe Premiere?
Pat
"Richard Crowley" <rcro...@xprt.net> wrote in message
news:vmaa53t...@corp.supernews.com...
> "Pat" wrote ...
> > (3) RGB is needed because computer monitors and many
> > video applications (ie. Video Editors) only use RGB Color Space.
>
> Perhaps you should clarify what you mean by "is needed".
> "is needed" for what?
> For storage? - "DV storage" is YUV by definition. Period.
> For transmission? - DV/Firewire transmission is likewise YUV.
> For processing? - software can be written to process in any transform
> For display? - The only place where RGB is really "required".
Several tutorials claim that Conversions between YUV and RGB cause slight
detail loss and the colors are NOT ideally mappable. Since YUV is the source
input from a digital camcorder, wouldn't it be advantageous if no RGB ever
entered the processing chain and its YUV from input through output. NO RGB.
If you accept what I just said, then you have to hunt down where RGB is
needed in your project, find a workable substitute, and avoid conversion. In
my case, Vegas 4 needs to use RGB for processing edits, et al. I understand
that Sony is investigating a future release that stays in the YUV Color
Domain. However, AVI Synth offers some options that can work completely in
YUY2 Color Space. They can even do cross fades and other editing type
functions, but an NLE ultimately is more powerful for most functions and its
why I use one.
I am just testing my opinion here and appreciate your replies. Am I being
too anal about this YUV to RGB conversion thing?
RGBaker
> I believe Vegas 4 only processes in the RGB domain. What about Avid
Express?
> Adobe Premiere?
Avid & Premiere Pro both work in YUV -- earlier versions of Premiere work in
YUV if the appropriate (Canopus, MainConcept) codec is installed.
GB
Pat
news:mlm9b.11040$Ls2.97...@news-text.cableinet.net...
Simon,
I captured a MiniDV to a file using Scenalyzer. Then I did it again using
Vegas 4, which essentially keeps your video until you render it out as an
AVI. Both these files have the VIDS DVSD in the AVI header.
Would you say that these AVI files are YUV or RGB Color Space?
RGBaker
> I captured a MiniDV to a file using Scenalyzer. Then I did it again using
> Vegas 4, which essentially keeps your video until you render it out as an
> AVI. Both these files have the VIDS DVSD in the AVI header.
>
> Would you say that these AVI files are YUV or RGB Color Space?
The files are YUV colour space. If you use a codec capable of working
entirely in YUV colour space (MainConcept, Canopus, Premiere Pro, Avid) then
your material never spends even a moment in RGB colour space ... if you work
with a codec that doesn't support YUV colour space than those parts of your
clips that have an effect or transition applied will be 'worked on' in RGB
colour space and then encodec to YUV colour space.
The issue is probably minor, but all the better codecs have ensured YUV
colour space only for some years now.
The issue of what software you use to accomplish the transfer is a red
herring -- the codec is only applied when some effect or transition is
rendered, and at that point the codec named in the header will be called,
unless your software can be 'tricked' into calling another (which is how the
MainConcept codec works). Alternately, there is software that will modify
which codec is named in the header ... but point of fact, no codec is
actually used during the transfer so it doesn't matter whether you transfer
with ScLive, Premiere, MovieMaker or whatever.
GB
RGBaker
> I am just testing my opinion here and appreciate your replies. Am I being
> too anal about this YUV to RGB conversion thing?
You could switch to Premiere Pro, Avid or Canopus, or you could find out
whether the MainConcept codec can be used in your NLE software.
GB
AnthonyR
allows the faster realtime processing, that would not have been possible if
everything needed to be converted to RGB and back again on the fly.
That is a bonus also, less converting equals less processing needed by cpu.
AnthonyR.
"RGBaker" <g...@bakerfilms.com> wrote in message
news:Ezs9b.1418$Ie5.2...@news20.bellglobal.com...
HighPeaksVideo
>my case, Vegas 4 needs to use RGB for processing edits, et al. I understand
>that Sony is investigating a future release that stays in the YUV Color
>Domain.
Where did you hear this about Vegas becoming a YUV program? A Sofo tech once
said on the user forum that it would require a full rewrite of the code.
That aside, Vegas does one heck of job going from YUV to RGB and back. Does
cause slower rendering though. Plus side is that all your RGB computer
graphics have a clean conversion to YUV. That would still hold true if they
made it a YUV program, because they have figured out a high quality color space
conversion.
BTW, the Video Toaster is also a full YUV in software and hardware.
Craig H.
Richard Crowley
> Several tutorials claim that Conversions between YUV
> and RGB cause slight detail loss and the colors are
> NOT ideally mappable.
RGB is lossless and the conversion process between
RGB<->YUV is lossless in either direction. It is a rather
simple matrix arithmetic equation. It is the bandwidth-
limiting of the U and V signals in YUV that causes any
losses.
> Since YUV is the source input from a digital camcorder,
> wouldn't it be advantageous if no RGB ever entered the
> processing chain and its YUV from input through output.
> NO RGB.
To the contrary, it would be far better to keep the signal in
RGB from end to end. Indeed this is what more professional
formats/equipment do.
The only downside I percieve to YUV-RGB-processing-YUV
is increased processing time due to conversion. I don't think
any quality degradation is significant in real-world terms.
> I am just testing my opinion here and appreciate your replies.
> Am I being too anal about this YUV to RGB conversion thing?
Its an amusing academic discussion, but it certainly isn't
clear to me why you seem to be so hung up about it. If you
had to write image procesing software you would certainly see
that it is far more straightforward to work in RGB-space.
(Which is why most SW is written that way.)
Wilbert Dijkhof
Richard Crowley wrote:
>
> "Pat" wrote...
> > Several tutorials claim that Conversions between YUV
> > and RGB cause slight detail loss and the colors are
> > NOT ideally mappable.
>
> RGB is lossless and the conversion process between
> RGB<->YUV is lossless in either direction. It is a rather
> simple matrix arithmetic equation. It is the bandwidth-
> limiting of the U and V signals in YUV that causes any
> losses.
>
> > Since YUV is the source input from a digital camcorder,
> > wouldn't it be advantageous if no RGB ever entered the
> > processing chain and its YUV from input through output.
> > NO RGB.
>
> To the contrary, it would be far better to keep the signal in
> RGB from end to end. Indeed this is what more professional
> formats/equipment do.
Why is that (btw source is YUV, and target probably also)?
What's the advantage of converting YUV to RGB, and do the
processing in RGB?
> The only downside I percieve to YUV-RGB-processing-YUV
> is increased processing time due to conversion. I don't think
> any quality degradation is significant in real-world terms.
>
> > I am just testing my opinion here and appreciate your replies.
> > Am I being too anal about this YUV to RGB conversion thing?
>
> Its an amusing academic discussion, but it certainly isn't
> clear to me why you seem to be so hung up about it. If you
> had to write image procesing software you would certainly see
> that it is far more straightforward to work in RGB-space.
> (Which is why most SW is written that way.)
No, it's not. You gain much processing time if you do the
processing in YUV.
Wilbert
RGBaker
> To the contrary, it would be far better to keep the signal in
> RGB from end to end. Indeed this is what more professional
> formats/equipment do.
The formats that record to RGB are few and far between -- and well beyond
the scope of 'desktop' video. YUV is what the vast majority of all
professional formats use.
> Its an amusing academic discussion, but it certainly isn't
> clear to me why you seem to be so hung up about it. If you
> had to write image procesing software you would certainly see
> that it is far more straightforward to work in RGB-space.
> (Which is why most SW is written that way.)
And the fact that it is a compromise is why all the 'better' choices have
preserved YUV through out, and why even those that historically worked in
RGB are now making every effort to move to YUV. If indeed you had a format
that recorded in RGB, this would be a backwards excercise, but DV, DVCam,
DVCPro, DVCPro50, Digital-S -- to name but a few -- all record natively in
YUV.
GB
Richard Crowley
> > To the contrary, it would be far better to keep the signal in
> > RGB from end to end. Indeed this is what more professional
> > formats/equipment do.
"Wilbert Dijkhof" <w.j.d...@tue.nl> wrote ...
> Why is that (btw source is YUV, and target probably also)?
> What's the advantage of converting YUV to RGB, and do the
> processing in RGB?
I thought this was just an abstract, academic discussion.
Trying to apply it to real-world equipment, particularly low-
end, consumer equipment is silly and pointless. Of course
DV gets converted from RGB to YUV at a very early stage
in its life-cycle and there is no amount of Usenet
> > Its an amusing academic discussion, but it certainly isn't
> > clear to me why you seem to be so hung up about it. If you
> > had to write image procesing software you would certainly see
> > that it is far more straightforward to work in RGB-space.
> > (Which is why most SW is written that way.)
>
> No, it's not. You gain much processing time if you do the
> processing in YUV.
"Straightforward" and "fast" are completely different variables.
I haven't written a million lines of code yet, but I'm in the
100s of thousands. There are many other examples in real
life of the "straightforward" way not necessarily being the
fastest. That comes with experience and spurred by competition
(which is what is happening with video processing application
software these days.)
Richard Crowley
> > RGB from end to end. Indeed this is what more professional
> > formats/equipment do.
"RGBaker" wrote ...
> The formats that record to RGB are few and far between --
> and well beyond the scope of 'desktop' video. YUV is what
> the vast majority of all professional formats use.
>
> > Its an amusing academic discussion, but it certainly isn't
> > clear to me why you seem to be so hung up about it. If you
> > had to write image procesing software you would certainly see
> > that it is far more straightforward to work in RGB-space.
> > (Which is why most SW is written that way.)
>
> And the fact that it is a compromise is why all the 'better'
> choices have preserved YUV through out, and why even
> those that historically worked in RGB are now making every
> effort to move to YUV. If indeed you had a format that
> recorded in RGB, this would be a backwards excercise,
> but DV, DVCam, DVCPro, DVCPro50, Digital-S -- to name
> but a few -- all record natively in YUV.
We are having different discussions here. My impression that
the OP was discussing the theoretical advantages/disadvantages
of RGB vs. YUV.
It should be obvious to everyone that in the real (DV, et.al.)
world, RGB is transformed to YUV, and U and V are bandwidth-
limited at a very early (and inaccessible) stage and there is
nothing you can do about it (the bandwidth limiting) at any
subsequent point/time.
Any conversion to/from any other transform (RGB or any
other) is undesirable, for processing delay if for no other reason.
However, because Y, U, and V are each arbitrary combinations
of R, G, and B, it makes handling more complex. i.e. not as
straightforward as dealing with them as "clean" R, G, and B.
Because of the availability of ever faster processing horsepower,
we can do lots of things that were undesirable just a few months
ago.
This is why I can't understand why the OP even started this
discussion. It has no practical value in the real world as Mr.
Baker and others keep pointing out.
Richard Crowley
> > To the contrary, it would be far better to keep the signal in
> > RGB from end to end. Indeed this is what more professional
> > formats/equipment do.
"Wilbert Dijkhof" <w.j.d...@tue.nl> wrote ...
> Why is that (btw source is YUV, and target probably also)?
> What's the advantage of converting YUV to RGB, and do the
> processing in RGB?
I thought this was just an abstract, academic discussion.
Trying to apply it to real-world equipment, particularly low-
end, consumer equipment is silly and pointless. Of course
DV gets converted from RGB to YUV at a very early stage
in its life-cycle and there is no amount of Usenet discussion
will change that fact of life.
> > Its an amusing academic discussion, but it certainly isn't
> > clear to me why you seem to be so hung up about it. If you
> > had to write image procesing software you would certainly see
> > that it is far more straightforward to work in RGB-space.
> > (Which is why most SW is written that way.)
>
Wilbert Dijkhof
Richard Crowley wrote:
>
> > Richard Crowley wrote:
> > > To the contrary, it would be far better to keep the signal in
> > > RGB from end to end. Indeed this is what more professional
> > > formats/equipment do.
>
> "Wilbert Dijkhof" <w.j.d...@tue.nl> wrote ...
> > Why is that (btw source is YUV, and target probably also)?
> > What's the advantage of converting YUV to RGB, and do the
> > processing in RGB?
>
> I thought this was just an abstract, academic discussion.
"To the contrary, it would be far better to keep the signal in
RGB from end to end. Indeed this is what more professional
formats/equipment do."
Looks like a practical statement to me :) But, perhaps I
don't understand what you are trying to say ...
I thought the OP was asking about the practical advantages /
disavantages of "converting to" and "processing in RGB".
> Trying to apply it to real-world equipment, particularly low-
> end, consumer equipment is silly and pointless. Of course
Trying to apply what?
> > > Its an amusing academic discussion, but it certainly isn't
> > > clear to me why you seem to be so hung up about it. If you
> > > had to write image procesing software you would certainly see
> > > that it is far more straightforward to work in RGB-space.
> > > (Which is why most SW is written that way.)
> >
> > No, it's not. You gain much processing time if you do the
> > processing in YUV.
>
> "Straightforward" and "fast" are completely different variables.
> I haven't written a million lines of code yet, but I'm in the
> 100s of thousands. There are many other examples in real
> life of the "straightforward" way not necessarily being the
> fastest. That comes with experience and spurred by competition
> (which is what is happening with video processing application
> software these days.)
Sorry for the confusion. I wasn't commenting about the
straightforward part (on which I agree with you). It was a
comment about the "(...) academic discussion" claim,
because it has also practical issues.
Wilbert
Richard Crowley
> > Trying to apply it to real-world equipment, particularly low-
> > end, consumer equipment is silly and pointless. Of course
"Wilbert Dijkhof" wrote ...
> Trying to apply what?
The notion that conversion from YUV to RGB has any benefit.
I have to quote one of my favorite lines from one of my favorite
TV shows "Sports Night" where Casey McCall says to Dan
Rydell: "The length of this conversation has greatly exceeded
my interest in it."
Pat
"HighPeaksVideo" <highpea...@aol.com> wrote in message
news:20030915223308...@mb-m29.aol.com...
> >In
> >my case, Vegas 4 needs to use RGB for processing edits, et al. I
understand
> >that Sony is investigating a future release that stays in the YUV Color
> >Domain.
>
> Where did you hear this about Vegas becoming a YUV program? A Sofo tech
once
> said on the user forum that it would require a full rewrite of the code.
I read a reference while browsing messages on Creative Cow. Nothing official
yeat.
Pat
> "Pat" wrote...
> RGB is lossless and the conversion process between
> RGB<->YUV is lossless in either direction. It is a rather
> simple matrix arithmetic equation. It is the bandwidth-
> limiting of the U and V signals in YUV that causes any
> losses.
http://www.fourcc.org/fccyvrgb.htm
> To the contrary, it would be far better to keep the signal in
> RGB from end to end. Indeed this is what more professional
> formats/equipment do.
>
> The only downside I percieve to YUV-RGB-processing-YUV
> is increased processing time due to conversion. I don't think
> any quality degradation is significant in real-world terms.
I find that comment interesting but from a user point of view, doing editing
and small projects, wouldn't it be more accurate to work completely in the
domain of the final Color Space. It seems to cut against the whole AVISynth
effort of recasting itself as a YUY2 processing engine.
> Its an amusing academic discussion, but it certainly isn't
> clear to me why you seem to be so hung up about it. If you
> had to write image procesing software you would certainly see
> that it is far more straightforward to work in RGB-space.
> (Which is why most SW is written that way.)
I might have read one too many DOOM9 posts by purists. <g>
Pat
4 has a very good proprietary Codec that is completely internal to Vegas.
Thanks!
"RGBaker" <g...@bakerfilms.com> wrote in message
news:Ezs9b.1418$Ie5.2...@news20.bellglobal.com...
>
David McCall
in RGB, that can not be reproduced in YUV because of the
reduced color space.
OK, so it is obvious that the conversion from RGB to YUV will
loose some of it's color fidelity. This certainly could apply to
graphics and animations that were produced in the computer
and had ben stored in a RGB format.
The question would be; Is there a noticable loos when the
source is YUV and the output is YUV, but there is an RGB
step in the middle. It might make sense that the colors that
are lost in the conversion RGB to YUV, might not have existed
in the first place, so you wouldn't be able to loose them.
The above has no scientific basis. It's just a guess.
David
RGBaker
> in RGB, that can not be reproduced in YUV because of the
> reduced color space.
It is my understanding of the math involved that in the conversion from RGB
to YUV some values need to be rounded or coaxed to a YUV value -- this is
worrisome when the segment involved needs to cut clean with adjacent
material -- a lower thirds super for instance -- though clearly less
significant if the material will not have to cut 'with itself'. There was
an interesting thread on this some years ago when a codec author presented a
typical conversion formula and proved that the rounding process would
introduce every increasing errors with each render -- sorry to say I neither
preserved the comments, nor grasped the maths well enough to represent them
here.
I was however convinced, and invested in a Canopus system (and so their
codec) the next day. There are an increasing number of YUV options for DV
production today, so with careful consideration the preferred option is easy
enough to obtain.
GB
Richard Crowley
> It is my understanding of the math involved that in the
> conversion from RGB to YUV some values need to be
> rounded or coaxed to a YUV value
The transform (in either direction) appears to be
straightforward. To wit...
Transform from RGB to YUV:
Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
U = -0.1687 * R - 0.3313 * G + 0.5000 * B
V = 0.5000 * R - 0.4187 * G - 0.0813 * B
Transform from YUV to RGB:
R = Y + 0.00000 * U + 1.40200 * V
G = Y - 0.34414 * U - 0.71417 * V
B = Y + 1.77200 * U + 0.00000 * V
Consumer "YUV" limits the BANDWIDTH of the U and V
signals. This has the effect of making the color information
"softer" or lower resolution. This is why DV[25] can get
away with 4:1:1 sampling (Y:U:V)
I've never seen any discussion that the RGB to YUV
transform affects the color GAMUT (range of colors that
can be reproduced).
References
http://astronomy.swin.edu.au/~pbourke/colour/convert/
http://www.nbb.cornell.edu/neurobio/land/OldStudentProjects/cs490-95to96/tcliu/wav.html
+ many other sources on the www
RGBaker
> "RGBaker" wrote ...
> > It is my understanding of the math involved that in the
> > conversion from RGB to YUV some values need to be
> > rounded or coaxed to a YUV value
>
> The transform (in either direction) appears to be
> straightforward. To wit...
>
> Transform from RGB to YUV:
> Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
> U = -0.1687 * R - 0.3313 * G + 0.5000 * B
> V = 0.5000 * R - 0.4187 * G - 0.0813 * B
>
> Transform from YUV to RGB:
> R = Y + 0.00000 * U + 1.40200 * V
> G = Y - 0.34414 * U - 0.71417 * V
> B = Y + 1.77200 * U + 0.00000 * V
A google search that adds 'problems' to the YUV to RGB transform turns up
any number of references to truncation and rounding errors. It strikes me
that actual application of the formulas you've kindly presented will quickly
indicate that results will not be whole numbers .... 'straightforward' does
not mean 'no rounding required'. A couple of the many hundreds of documents
on the web that discuss this are referenced below:
http://www.ee.cityu.edu.hk/~ISCE2000/003.doc
http://www.avisynth.org/index.php?page=Section+3%3A+Filters%2C+plugins+and+colorspaces
http://www.poynton.com/PDFs/Merging_RGB_and_422.pdf
and Craig Birkmaier makes some convincing points on coversion in this
thread:
http://visarts.ucsd.edu/grad/lab/dv-craigb.html
If your skills extend to refuting the documents above, then you are dueling
with an unarmed man as I am limited to accepting these arguments at face
value, and can do little more than judge the implied credentials of the
source. I remain convinced that RGB to YUV conversion is not lossless given
the limited number of bits associated with the converted values.
Cheers,
GB
David McCall
--
"Richard Crowley" <rcro...@xprt.net> wrote in message news:vmegrp7...@corp.supernews.com...
> "RGBaker" wrote ...
> > It is my understanding of the math involved that in the
> > conversion from RGB to YUV some values need to be
> > rounded or coaxed to a YUV value
>
> The transform (in either direction) appears to be
> straightforward. To wit...
>
> Transform from RGB to YUV:
> Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
> U = -0.1687 * R - 0.3313 * G + 0.5000 * B
> V = 0.5000 * R - 0.4187 * G - 0.0813 * B
>
> Transform from YUV to RGB:
> R = Y + 0.00000 * U + 1.40200 * V
> G = Y - 0.34414 * U - 0.71417 * V
> B = Y + 1.77200 * U + 0.00000 * V
>
> Consumer "YUV" limits the BANDWIDTH of the U and V
> signals. This has the effect of making the color information
> "softer" or lower resolution. This is why DV[25] can get
> away with 4:1:1 sampling (Y:U:V)
>
> I've never seen any discussion that the RGB to YUV
> transform affects the color GAMUT (range of colors that
> can be reproduced).
>
Good data for the matamatically inclined. Thanks
I was basing the color loss based on a picture I saw that showed
the diference between RGB and YUV color space. I think a
similar thing happens in print when you go from RGB to CYMK.
David
Dan Maas
> RGB<->YUV is lossless in either direction. It is a rather
> simple matrix arithmetic equation.
This is incorrect, at least if you are talking about 8
bits-per-component color. RGB<->YUV (really Y'CbCr) is not a
one-to-one mapping in 8 bits; some RGB values are mapped to one Y'CbCr
value, and vice versa. So if you take a Y'CbCr frame and convert it to
RGB and back, you will definitely NOT return to the exact original
frame - you will introduce a small amount of banding.
If you use 10-bit Y'CbCr this is much less of a problem.
Always remember Y'CbCr is just a simple lossy compression scheme.
Video cameras and TVs are all RGB internally. They convert to a
luma/chroma representation on the wire so that chroma bandwidth can be
decimated. Although, you have to keep in mind that Y'CbCr also
contains remnants of analog video processing, like the "headroom"
darker than black (Y 0-15) and whiter than white (Y 236-254).
Regards,
Dan
Johan Stäck
> (7) An AVI file will always have a FOURCC code assigned to it and the
> contents is what the code states:
For DV, this statement is (IMO) not fully correct. In reality, you can find
DV AVI files with different fourcc codes (eg msdv, CDVC)
The content of these files is the same: Raw DV frames taken directly from
the DV video camera, but the fourcc codes are different.
This fact leads to a common misunderstanding that one can se often and it
often goes something like:
"I have captured DV using the so-and-so DV codec, and now.....".
But no codec is involved in DV capture. However the capturing program has to
make a decision to write a fourcc code in the AVI file it creates,
and different programs obviously make different decisions.
/Johan
jas...@deletethispacbell.net
wrote:
>> > To the contrary, it would be far better to keep the signal in
>> > RGB from end to end. Indeed this is what more professional
>> > formats/equipment do.
>
So the ideal would be:
1. If the ultimate purpose of the project is TV, use a YUV codec.
2. If the project is for a computer RGB monitor, use an RGB codec.
Right?
On a practical subject, suppose I have camcorder (YUV ) files and want to
superimpose Photoshop titles or other graphics. Do I make the Photoshop
files in RGB or can I create them in a YUV colorspace?
JoeA
--
Self-government requires self-discipline.
Richard Crowley
> > > It is my understanding of the math involved that in the
> > > conversion from RGB to YUV some values need to be
> > > rounded or coaxed to a YUV value
Richard Crowley wrote...
> > The transform (in either direction) appears to be
> > straightforward. To wit...
> >
> > Transform from RGB to YUV:
> > Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
> > U = -0.1687 * R - 0.3313 * G + 0.5000 * B
> > V = 0.5000 * R - 0.4187 * G - 0.0813 * B
> >
> > Transform from YUV to RGB:
> > R = Y + 0.00000 * U + 1.40200 * V
> > G = Y - 0.34414 * U - 0.71417 * V
> > B = Y + 1.77200 * U + 0.00000 * V
"RGBaker" wrote ...
> A google search that adds 'problems' to the YUV to RGB
> transform turns up any number of references to truncation
> and rounding errors. It strikes me that actual application of
> the formulas you've kindly presented will quickly indicate that
> results will not be whole numbers
Nothing in real life (including the original images we shoot
video of, or the sound we record) produces whole numbers.
[Note that the two classes of numbers used in software are
called "integer" and "real"] Our video starts being quantitized
("rounded") practically from the moment the photons touch
the imaging chip.
> .... 'straightforward' does not mean 'no rounding required'.
> A couple of the many hundreds of documents on the web
> that discuss this are referenced below:
Again, the difference between discussing the THEORY of
RGB<->YUV conversion and the PRACTICE of how it is
implemented, particularly in inexpensive consumer, 8-bit
equipment. We need to be more clear whether we are
talking theory or practice, and if the latter, which
particular equipment (or software) we are discussing.
In the absense of Make/Model numbers, (or even bit-depth),
I can only assume that we are discussing THEORY as the
alternative has no meaning.
If we want to discuss real-world practice, then we
must specify at least the bit-depth of the storage (and
processing for lots of equipment that has wider computing
facilities) of the equipment/software.
RGBaker
> Again, the difference between discussing the THEORY of
> RGB<->YUV conversion and the PRACTICE of how it is
> implemented, particularly in inexpensive consumer, 8-bit
> equipment. We need to be more clear whether we are
> talking theory or practice, and if the latter, which
> particular equipment (or software) we are discussing.
> In the absense of Make/Model numbers, (or even bit-depth),
> I can only assume that we are discussing THEORY as the
> alternative has no meaning.
And yet even 'in theory' the sites I referenced above didn't need Make/Model
numbers.
The simple truth is YUV codecs are the preferred codec for DV production,
both in theory & in practice.
GB
Richard Crowley
> And yet even 'in theory' the sites I referenced above
> didn't need Make/Model numbers.
Then they made assumptions (stated or unstated) about
the precision of the arithmetic. Otherwise "rounding" and
"truncation" have no meaning, do they? This is why we
are seeing equipment with 16-, 20-, 24-bit DSP thanks to
higher-precision chips at lower prices.
> The simple truth is YUV codecs are the preferred codec
> for DV production, both in theory & in practice.
My apologies if anyone thought I disagreed with that statement.
The whole discussion seemed a bit silly to me from the start
(as I stated previously.)
Ed Anson
> "RGBaker" wrote ...
>
>
> The transform (in either direction) appears to be
> straightforward. To wit...
The transformation is fairly simple, but there's a catch (see below).
>
> Transform from RGB to YUV:
> Y = 0.2990 * R + 0.5870 * G + 0.1140 * B
> U = -0.1687 * R - 0.3313 * G + 0.5000 * B
> V = 0.5000 * R - 0.4187 * G - 0.0813 * B
>
> Transform from YUV to RGB:
> R = Y + 0.00000 * U + 1.40200 * V
> G = Y - 0.34414 * U - 0.71417 * V
> B = Y + 1.77200 * U + 0.00000 * V
To complete the transformations, you need to limit the output values to
the valid range.
>
> Consumer "YUV" limits the BANDWIDTH of the U and V
> signals. This has the effect of making the color information
> "softer" or lower resolution. This is why DV[25] can get
> away with 4:1:1 sampling (Y:U:V)
NTSC also limits the bandwidth of Y, U and V. DV also limits it, as part
of the compression process.
>
> I've never seen any discussion that the RGB to YUV
> transform affects the color GAMUT (range of colors that
> can be reproduced).
To see the gamut differences, you only have to do the arithmetic. When
you consider the fact that each color space is defined over a specific
range of values (e.g., 0.0 - 1.0 or 0 - 255 depending on how you look at
it) it is easy to choose values in either color space that map outside
the other.
When you also take into account that not all combinations of Y,U and V
are valid, the gamut differences are significant. A standard
chromaticity diagram shows that the NTSC (YUV) gamut is a limited subset
of the RGB gamut.
In practice, it is best to perform all manipulations (filters,
transitions, etc.) in the YUV color space in order to avoid gamut
problems as well as roundoff errors. Some things (e.g., color
correction) are actually simpler (as well as more accurate) in YUV
space. Of course, if you need to mix a YUV image with an RGB image,
conversion is unavoidable. The best NLEs (e.g. FCP) minimize such
conversions.
>
> References
> http://astronomy.swin.edu.au/~pbourke/colour/convert/
> http://www.nbb.cornell.edu/neurobio/land/OldStudentProjects/cs490-95to96/tcliu/wav.html
> + many other sources on the www
Reference: Video Demystified: A Handbook for the Digital Engineer, by
Keith Jack. pp. 16, 30.
>
>
Richard Crowley
> To see the gamut differences, you only have to do the arithmetic. When
> you consider the fact that each color space is defined over a specific
> range of values (e.g., 0.0 - 1.0 or 0 - 255 depending on how you look at
> it) it is easy to choose values in either color space that map outside
> the other.
Aren't the legal values of R, G, and B already limited by
NTSC definition? I can't make legal SMPTE bars with
full-scale 0--1 values of RGB.
Ed Anson
I suppose you could say that, if you interpret RGB as being limited to
the YUV gamut as translated to RGB. But then it gets really messy
defining the "legal" subset of RGB. And then there is the problem that
some transformations that are very reasonable in RGB space result in
"illegal" values -- that is, values that don't map back to legal YUV values.
But (as you said) this is all academic. Most (if not all) professional
NLEs operate in YUV space whenever practical. They do so partly to
improve speed and partly to improve accuracy. That's good enough for me.
FLY135
<jas...@DELETETHISpacbell.net> wrote in message
news:o50fmvkqa2gbehcjt...@4ax.com...
> On Tue, 16 Sep 2003 06:57:35 -0700, "Richard Crowley" <rcro...@xprt.net>
> wrote:
>
> >> > To the contrary, it would be far better to keep the signal in
> >> > RGB from end to end. Indeed this is what more professional
> >> > formats/equipment do.
> >
> So the ideal would be:
>
> 1. If the ultimate purpose of the project is TV, use a YUV codec.
> 2. If the project is for a computer RGB monitor, use an RGB codec.
> Right?
No, not really. As you might have already gathered from this thread... The
final output of many codec's decompression stage (especially MPEG, MJPEG,
and DV) is YUV. The necessary input to the compression stage of these same
codecs is YUV. It doesn't matter whether your MPEG or DV file is to be
played on a computer or a TV.
Any RGB processing in the computer is probably determined by the
application. Any advatages or disadvantages for using RGB in the editing
process is probably application dependent as well. I really wouldn't be too
concerned about it. If you are given a choice then try a few tests and see
if you can tell the difference.
Simon Walters
"Pat" <Hotp...@hotmail.com> wrote in message news:Uls9b.4792
> I captured a MiniDV to a file using Scenalyzer. Then I did it again using
> Vegas 4, which essentially keeps your video until you render it out as an
> AVI. Both these files have the VIDS DVSD in the AVI header.
>
> Would you say that these AVI files are YUV or RGB Color Space?
YUV
regards
Simon
Pat
news:fhqab.1418$A44.12...@news-text.cableinet.net...
I kind of wonder why they don't use the appropriate YUV code in the AVI
header. OK, the DV came across Firewire and stored as its native YUV format,
but you would think the FOURCC code would be one of the YUV codes that
Microsoft has doped out.