#NTSC true reds
21 messages in this thread
Someone asked me this question, and I couldn't answer it…
"If a really saturated red isn't NTSC "legal", how come you see all these
apparently vibrant reds on TV?"
In order to get a true vibrant red in 3DS, I'd have to turn NTSC color correct
"off", and crank up the saturation … if I do that, I get chroma crawl all
over the place. So how DO those really red reds come about on TV (including
animated ads). ??
The values of a red can be assigned as high as 255,0,0 in RGB and this would
most likely result in an illegal color when recorded to analog video tape. A
red with a value of 220,0,0 is theoretically legal in analog video. In CCIR601
recording (D-1 digital) using 10 bit sampling the color space can go to
255,0,0 and be legal. Really vibrant colors can result using a variety of
techniques in video without exceeding the legal values. Some of these
techniques are: developing the color value using proper monitoring equipment
so the red vector can be pushed to the limit. Recording the video in a
component mode to prevent the chroma "bleed" you refered to. Finally using a
good component monitor capable of displaying saturated colors without bleed.
Always remember that when you put a composite link in your video chain you will
have this bleed which will be exagerated with fully saturated colors. Illegal
colors can also distort the image as well. Finally, video noise is a factor in
the quality of the color you have. I always felt the targa+ was quite the
noisy framebuffer in Y/C output. It's RGB output is much better. This chroma
noise will dirty up a clean color.
Don, excellent description of legal colors. Your comments on so many video
signal issues have been very helpful. Thanks, Jeffrey
Thanks Don and David –
I've never noticed "bleed" from the RGB output of my Targa+, and it's not even
that bad when it's set to NTSC, viewed on my usual monitor — but when it runs
through my "worst case tester" – a cheesy consumer portable TV, or to VHS, it's
purely awful … and most of our stuff will be viewed on classroom TV's of
completely unpredictable quality. We recently (finally) put some stuff from
the MAX system to a "good" quality VHS deck – it was amazingly clean overall
.. but there were crawly patches on a saturated reddish-brown object.
Refresh me on the guidlines for saturation? If I put a dash of green in the
red, (a la GY), what would be the max saturation I ought to be able to use?
(The master will be from the MAX to beta).
Gayle
>>a cheesy consumer portable TV, or to VHS, it's purely awful
You can take a gourmet dinner and serve it in a garbage can and it will look
like garbage. All you can do is keep the signal as pure and clean, read legal,
at your control. Adding other color ingredients always helps to reduce the
intensity of the color. I seldom use pure colors myself. In the end, however,
I find using the vectorscope and a good monitor can put you on the edge of
legality and appearance. Without these I suggest not exceeding 210 on any RGB
value, 220 if you like to push things.
<You can take a gourmet dinner and serve it in a garbage can…>
Well, consider this a "budget gourmet" dinner – and it most likely _will_ be
served in a garbage can. :-(. But given that, checking on the crummy TV has
protected me from lavishing too much love on gorgeously detailed or bumpy
texture maps – the detail is not going to show, and the bumps, in motion, are
going to produce some nausea. I'd rather know how bad it's going to look, and
try to focus on aspects that will be effective even with a poor signal (clean
motion, at least, I _hope_).
I will earnestly strive to keep my RGBs from crossing that 220 line in the
sand. Thanks for the input.
Gayle,
Did you want a specific value for RED? It occurred to me we'd all but got down
to that, as things go what else is new? <g>
John
<what else is new>
Nothing much except we (finally) have some output from the MAX, and I'm really
amazed at how good it is, even under "worst case" conditions.
BTW I did DL your TPANEL.zip, but haven't had time to look yet.
Gayle,
>> I'm really amazed at how good it is, even under "worst case" conditions.
Glad to hear its up and running. Its an enviable system no doubt and has
several advantages over the PVR as a solution. The PVR has its strengths as
well and being newer technology has some advantages. I don't know if that was
the lead in to this comment but I'd be happy to debate the pro and con's of
each, suffice it to say, it looks like I'll end up with the best of both
worlds. I've learned not to get to wedded to hardware, the technology changes
and prices drop. Software is more personal and there are definite advantages to
staying with what you know, provided you choose wisely to start with, which
isn't always easy. (In case you wondered. <g>)
I'll be interested to hear your comments on Tpanel.zip. But I wanted it to be
your option on whether to mention it or not.
Regards,
John
Don,
I don't like to disagree with you especially in this context, but D1 outputs 8
bit not 10 bit, and second off the max level in D1 is 220,0,0 when RGB is
converted to YUV. 10 bit is only useful in maintaining digital integrity
machine to machine but output is always at 8 bit in accordance with CCIR 601
specs. (Which is why the PVR can potentially have better output than D1 as it
outputs in 10 bit.) FWIW D2 is even worse as it has a maximum or 140. In fact
of the 16 million colors available in 24 bit RGB 40% are illegal when converted
to 24 bit YUV.
More often than not lowering the saturation level will produce better results.
The safest way to determine whether an RGB value is legal or not is to
calculate its luminance and saturation against the limits for the composite
signal.
If anyone's interested I do have a formula.
John
>>I don't like to disagree with you especially in this context, but D1 outputs
8 bit not 10 bit, and second off the max level in D1 is 220,0,0 when RGB is
converted to YUV. 10 bit is only useful in maintaining digital integrity
machine to machine but output is always at 8 bit in accordance with CCIR 601
specs.<<
I agree until the final phrase: "in accordance with CCIR601 specs" According
to one source CCIR601 actually allows for up to 10 bits of data in the spec.
You are correct, however in that this does you no good unless your recorder
works in 10 bit, which the Sony DVR-2100 does not. Another source confirms
your point that CCIR601 only supports 8 bit.
My study of this CCIR601 is recent since the PVR publication and I started to
read up on it. BTW the source on the 10 bit issue is from Michael Grotticelli,
managing editor of Videography magazine. The confirmation of your 8 bit
limitation comes from handbook of video terms under "CCIR601"
Thank you for this clarification, or that I / we need to further research this.
>>The safest way to determine whether an RGB value is legal or not is to
calculate its luminance and saturation against the limits for the composite
signal.<<
This I do disagree with you on. In my opinion the safest way to determine
whether the colors are NTSC legal or not is to use the method recognized by the
enforcer of the regulation. I believe the safest way is the use of a
calibrated vectorscope. I made note of your formula, however, and find it
academicly interesting.
>> BTW my source on the 10 bit issue is from Michael Grotticelli <<
Strike another one for the Moguls of the media. <g> Of course it is possible
that the 10 bit relationship was misunderstood.
The CCIR 601 spec is an international specification. What they did was combine
NTSC and PAL. I get won't into all the complications but YUV is identical to
PAL color space which is 8 bit.
All D1 machines output 8 bit, even the newest Diskus outputs in 8 bit even
though like the PVR it processes input at 10 bit. All 8 bit machines process in
16 bit internally as two values are obtained for each pixel part of the
encoding process, which is also inaccurately being referred to 2x's sampling.
>> According to one source CCIR 601 actually allows for up to 10 bits of data
in the spec. <<
You'll note that I specifically said output. Internal processing could be done
at any bit level, but of course the higher you go the more data you're pushing
where ultimately you're still outputting 8 bit. 10 bit is a reasonable
compromise to maintain digital integrity machine to machine, like in
multi-layering with machines that have that capability.
The older DDR's like the A65 use 8 bit, the newer ones like the Diskus use 10
bit but as I said its only useful with other 10 bit device otherwise both
machines will process it at 8 bit like when multi-layering, and final output is
8 bit. Until they change the spec its always going to be 8 bit output.
FWIW, the formula is dead on accurate for translating RGB values to NTSC
composite, where you know the pixels RGB value, (what can complicate this is
that RGB values in the materials library are raw RGB values ungamma corrected,
so you'd have to use something like PhotoShop to read the individual rendered
pixel to obtain its specific value. The RGB value must fall between 0 to 1.0
(video RGB) as opposed to 0 – 255 (which means our RGB values have to be
converted where 255 = 1 as a max value.)
Maximum excursion of (Y + saturation) must be between 0 and 1 with minimum
excursion (Y – saturation) must be greater than -0.25
Its easier to eyeball it with a Vectorscope, but not more accurate. But as most
of us know in a production environment few people are going to take the time to
sit down and sample each pixel, <g> especially now that there are
programs/plug-ins that will do that also, though I don't like to use them
except as a reference and comparison of the values I'm using. For instance
PhotoShop has got a good one that will adjust for NTSC, but unless you want to
process every frame which I don't its better as a comparison. FWIW I've found
the Video Color Check to work quite well in the render dialog box but I'm also
careful not to push it, you kind of develop a knack for it.
BTW this formula is the one the "enforcer of the regulation" uses. <g>
John
>>BTW this formula is the one the "enforcer of the regulation" uses. <g>
FCC?
I don't know that for a fact but if you say so it doesn't surprise me.
However, originally, I meant "enforcer" as the chief broadcast engineers at the
TV stations, particularly those veteran chief engineers that have a tremendous
condescending attitude toward everything in the industry. Like the one that
rejected my 30 second spot two weeks ago for being off by one scan line of text
height in my CG as measured by his WFM. The spec goes by percentage of active
picture height and he interpreted this to the number of scan lines. These same
BE's are the ones using a VS to enforce the regs not pixel mathematical
interpolation. That's who I originally meant as the enforcers. ;^|
>> That's who I originally meant as the enforcers… <<
I gotcha, usually if I can get it past the editor my worries are over. <g> But
also consider that not ever animator has WFM and VS. And the fact is if that
pixel is within limits it _will_ pass you scope. Check it out, maybe I'll make
a believer out of you yet. <g>
John
Maybe a waveform and vectorscope would help in color determination.
Ryan @ IMI
>>Maybe a waveform and vectorscope would help in color determination.
I believe that is what I was trying to say when I said: In the end, however, I
find using the vectorscope and a good monitor can put you on the edge of
legality and appearance.
Sorry, been offline for a while.
When using the waveform – keep everything around 90-95% – the images coming out
of your computer are usually hotter than that already on tape.
Ryan @IMI
Gayle, I'm no guru but to get reds looking deep and not crawl there are a
couple of things you can try. First off, try adding a little green into your
red – I got this from GaryY. Also, you do need to turn the saturation down to
avoid the crawl, since doing this washes out the red you can turn the
brightness down also to make the red appear deeper. Also, it helps to have a
vectorscope handy to see if you're safe or not. I hope someone else can offer
better advice, as I'd like it myself.
DM
David,
>> I hope someone else can offer better advice… <<
That's pretty good if you have to eyeball it, there is a formula for checking
RGB against composite and since you asked I'll pass it along.
Composite RGB
Y (.299 .587 .144) R I (.596 -.274 -.322) G Q (.211 -.523 .312) B
_________ Saturation = V 2 2 That's supposed to
represent the square root
I + Q of I squared plus Q squared. Not a perfect
medium to express this formulas.
Maybe R5 will allow you to create or have custom palettes so that any color
used within the palette will be NTSC or YUV safe… wish list item.
John
John, Thanks much for the formula but C$ messed it up good and me, having no
idea how it's supposed to read, can't interpret it. Really, though if you think
it's useful, I'd like to really see it. Thanks again.
DM
David,
Don't sweat it, a WFM/VS works just fine.
John