#NTSC color bars
18 messages in this thread
John and all,
I'm trying to lay off some color bars to my PAR as a point of reference
for some local video dudes. A while back I just copied your NTSCBARS.TGA to
the PAR, and apparently it scoped just a bit off on one or more of the colors.
I'm really not sure what the readings were, but they were pretty good. They
still suggested I generate my own.
Anyway, I decided to try to render my own .TGA to the PAR based on your
NTSCCB.PRJ file. I noticed that the color values were kind of varied in
regards to luminance, some were at about 30, some were at about 60, etc.
Shouldn't I be putting out fully saturated colors, set at luminance=128? Or
should I be toning down the saturation to about 210, as that's what I usually
max my materials out at for video? Or should I just render your .prj file,
knowing it should be right?
Thanks for the library file! 🙂
Paul S.
Paul –
There are serveral color bar patterns included with the PAR as STL files. Have
you taken a look at these, yet? Might save you some time building your own.
— James — Choreo Motion —
>> There are serveral color bar patterns included with the PAR as STL files. <<
Ah, there they are, in a seperate directory on the 3.5" disk. 🙂 I guess
I just installed the root directory for the PAR previously, not the entire
disk. Thanks!
Still kind of curious about what the HLS values should be for the test
pattern colors, and/or if a scope is necessary.
Paul S.
<<There are serveral color bar patterns included with the PAR as STL files.
Have you taken a look at these, yet? Might save you some time building your
own.>>
Does this apply to a very recent upgrade? I purchased the PAR about 4 weeks
ago and upon reading your post, checked the floppy that the PAR software came
on. There seem to be no directories other than the root and that only contains
4 file (install.exe , a zip file, a readme file and the pkunzip.exe) I also
checked the file list in the zip file…..nothing. Could you tell me where I
can obtain the color bar patterns?
Kim
Worlds Away Productions
Paul,
I'm not sure how the Bars could have Scoped off unless it was relative to the
work you were outputting, which means your work was "hot". The PAR does have a
set of BARs with it, and I would use those. If your work is coming out "hot"
you've got to start looking at your luminance levels etc. in your lighting. I
never go above 180 on lights, I usually turn ambient off or bring it way
down… you colors shouldn't read above 210 on Luminance on HLS. Video is
rather restricting, compared with print etc. Having a good NTSC monitor helps
alot, if its calibrated correctly.
John
Actually, I think the off colors might have been under-saturated. If I
remember correctly, the scope's readout looked kind of like a star, and I think
the questionable colors didn't peak out as far as the others. I'm not sure.
I've been using more moderate HLS levels for my materials, and rarely go
over 180 for lights too. You said don't go over 210 for luminance, and I've
been using 210 as my typical cut-off for saturation, with about 235 as my
cut-off for luminance. I assume your 210 luminance value applies to white
also? It seems difficult to get a "clean" looking white with these lower
luminance levels, they appear too gray… I don't have a scope or a high end
NTSC monitor. 🙁
Paul S.
Paul,
>> It seems difficult to get a "clean" looking white white these lower
luminance levels… <<
Take a look at some SMPTE color bars and look at white and 100% white. The
white I'm suggesting is white although its not as intense as 100% white.
Depending on how much of the screen is 100% white, you may or may not get
complaints, that partially depends on whether its broadcast and the editor
you're working with. 235 is the Max RGB value you can use in component. In the
digital relm there is only 220 discrete levels for contrast without causing
banding. There are several ways to handle it, one of which is to have an
algorithm interpolate the pixel values to bring them within range. I choose to
lower my luminance level and work from 7.5 IRE black as my baseline. Then
during the conversion from RGB to YUV I'm staying within the discrete range of
possible pixel values with no interpolation. 210 is close to white, where 220
would be 100% white.
John
BTW I haven't heard anything on the Targa drivers yet. Its a rough go for
Truevision, the parent company seems to be rather myopic.
Do you tend to follow an upper limit for the luminance value of the
specular component of materials too? Or the saturation levels of the ambient
component of materials? These two questions puzzle me too. I've been playing
it pretty safe, but wonder if there is a general guideline you've discovered.
Paul S.
>> Do you tend to follow an upper limiet for the luminance value of the
specular component… <<
Not really, within the context I've outlined its not really
necessary. Basically your lighting is going to provide the
"clamping" value and you may wish to use specular components to
provide intensity or as a means by which you can create hi-lights
etc. There is a margin that's built in to provide headroom just for
this kind of thing, where you would use this for "razzle dazzle",
explosions etc.
>> Saturation of the ambient component… <<
This is not typically a problem either for the same reason.
As an aside, I recently did a Red and Gold flying logo which has a few
inherent problems. The client came to me with a Pixar Typestry
rendered font and wanted to duplicate it for animation. I was able to
provide a better gold (more reflective and brighter) and a richer
red, which was then keyed over video successfully without any special
attention being required. An interesting point is that reflective
materails are not typical materials when it comes to lighting except
with regard to the specular component and neither had a problem with
over saturation or specular luminance.
Without a WFM/VS there are no guarantees as I can't predict what
someone might do following these guidelines. Obviously if you push
the specular component on a large scale you'll have the same problems
as if you attempted to do the same with the diffuse component, but in
the context of their normal size relationship its a fairly safe bet.
Being an analog signal and especially with component where the
"components" are seperate you've got more flexibility than when its
working in the composite domain. Provided that it falls within
component guidelines, the composite output will be NTSC legal. One
other point is that certain colors work better than others. There's
no hard and fast rule but NTSC among its other fine characteristics
is a weighted color system, the reason is to provide accurate
fleshtones; the hardest to reproduce, so that wieghting is also a
factor.
I hope this helps. I don't think you can go too far wrong as long as the
overall composition reflects some balance. Which in your case I would expect it
would.
John
I'm going to see if I can't convert some formula's into a script or
something so that for a given RGB value you'll know its relationship
in NTSC and YUV color space. Kinda like a calculator. That way you
know whichever color you choose will fall within the correct color
space and there won't be a problem. This could be pretty handy all
around. I hope I can get to it soon.
>> I hope this helps. I don't think you can go too far wrong as long as the
overall composition reflects some balance. <<
Yes it helps, thanks for the info. Good to hear about your success with
red and gold with 3DS.
>> I'm going to see if I can't convert some formula's into a script
or something so that for a given RGB value you'll know its
relationship in NTSC and YUV color space. Kinda like a calculator.
That way you know whichever color you choose will fall within the
correct color space and there won't be a problem. …This could be
pretty handy all around. <<
Sounds like an interesting project, useful too. I admire you and
Don for your expertise in the world of video.
>> Sounds like an interesting project… <<
It already is, as I realised I'll need to take into account "gamma"
correction which really throws a curve into things. (literally <g>)
Probably why my numbers seem so conservative to you in the first
place. I use a "gamma" of 1.8, so you can factor that into your
perspective. The conversion formulas I have, assume a neutral gamma
or a linear RGB. So I need to figure out how to influence the value
correctly over the curve of the gamma affected values. Hopefully
there's an influence formula for gamma which is readily available. I
knew it looked too simple to begin with. <g>
>> I use a "gamma" of 1.8, so you can factor that into your perspective. <<
Me too, unless I know from the start it's going to VHS only, in
which case I go linear (1.0) because that's what my gamma screen
looks best at via composite out of my PAR or Targa+.
I remember seeing you post this formula a while back… I
understand very little of it, mainly because I'm not sure of all of
the terms indicated by the letters, and just general video term
ignorance. <g>
>> Gamma correction does affect the "apparent" brightness of an image
but does not increase the brightness. Instead, it would seem that the
apparent brightness is due to a desaturation of the darker and
lighter pixel values, rather than actually increasing the luminance
bandwidth. This is an important point as it has a direct bearing on
whether the formula works with gamma corrected pixel values. <<
This is very interesting!
>> And hopefully soon I'll be able to find some more time to write a program
which will make it a little easier to use. <<
Great! When you have even more time <g>, I really think you should write
a book, or several chapters at least, in which you cover 3DS and video. It
seems to me to be one of the major areas of 3DS training which has been
overlooked. I'm sure there are a lot of people like me with no formal training
in video, who are currently working on industrial level projects, trying to
cope with NTSC peculiarities.
Thanks, as always, for the info. By the way, I just received Bones Pro
yesterday. I can see why you were so excited about Smooth. A *very* nice tool
to have!
Paul S.
Just for general info YIQ is the composite variation of YUV, SVHS etc.
They are all encoding schemes for getting hue sarturation and
luminance recorded or output. Although composite really isn't encoded
per se. like YUV and SVHS where the signals are split which helps
improve the output.
This formula route has forced me to dig into how its affecting the
image and looking back over some of the previous threads on this
subject, there's a lot of inconsitency in what its actually doing.
And I think I've uncovered the reason though it was rather evident to
begin with. "The answer is stareing you in the face… great but
what's the question?". <g> That's how it felt once I realised why
there were all this contradictions.
What makes it difficult to give an accurate depiction of what's going
on is the NTSC color weighting system, and that being an analog
signal, the effect gamma has is "cascading" as I mentioned
previously.
Looking at a Waveform and Vectoscope can be misleading because you can't
identify the individual pixels readily. So while it may look like its
desaturating the colors and the luminance is not raising above a certain point,
the net effect may be quite different altogether. Which in many cases if not
most it is. So sorry for the confusion on this point. Its odd that you can be
looking at something and see the opposite of what you should be seeing,
especially when it is counter-intuitive but there it is.
In terms of 3DS the effect of gamma on the image is uniform in a logrithmic
sense. Which makes sense.
I started realising all this when I re-considered how I've used the formula
which is after the fact. After an image has been rendered it is an easy matter
to pick a pixel and run it through the formula and its dead on accurate. I
think I eluded to that before but it was thinking about pre-calculating a
pixel's value with gamma that confused the issue.
Trying to devise a system to pre-calculate the value of a pixel or a particular
color in a scene is more challenging. I don't have the exact formula that's
being used, and but I'll ask if I can get it.
FWIW I use QFX which has a densimometer and will give you a reading
for any pixel you select. So its easy to render the image and check
it against the formula.
If I can nail it down I'll proceed with some kind of program to
calculate it, if not, the formula does work if you use it against a
rendered image which has already had gamma applied.
Sorry about that but it will provide you with an accurate solution
should you choose to use it. You don't really need to know what YIQ
are just plug the numbers in, Y is typically luminance, I and Q are
the color weighting for NTSC. Then you just compare it with the
minimum and maximum allowed tolerance. Its a bit of pain but it does
provide you with a totally accurate way of checking without a WFM/VS
setup.
P.S. I like the book idea, once I get this nailed down I'll consider
persueing it. This gamma thing has been elusive and while haveing a
handle on it is one thing, being able to relate how it applies in a
video sense can get really messy.
Paul,
I thought rather than delay while I find the time to put this together, I would
provide the formula courtesy of Abekas courtesy of the FCC, so that you could
utilise it as needed now.
One factor which has eluded me is that 3DS uses HLS at 0 – 255 where several
other programs use HLS as 0 – 1.
In this case RGB is calculated at 0 – 1 as opposed to 3DS and most other
animation packages which use 0 – 255 for 256 discrete values.
This is the YIQ or composite Matrice:
Y | 0.299 0.587 0.144 | R I = | 0.596 -0.274 -0.322 | G Q | 0.211
-0.523 0.312 | B
Saturation = The square root of I sqrd + Q sqrd.
For RGB values in the range of 0.0 to 1.0 which means you need to convert your
256 RGB value to a corresponding ratio to 1.0
Maximum excursion of (Y + saturation) must be less than or equal to 1.0 Minimum
excursion of (Y + saturation) must be greater than -0.25
The color space is normally limited to the 75% luminance (100% saturated) color
bars with a 100% white. This keeps the signal within the limits of +100% -16
IRE units.
In television, "gamma" measurement relates light input to voltage
output, or voltage input to light output. The effects of a series of
processes combine (cascade). Thus a camera tube having a low gamma
(vidicon 0.65) relates to a color picture tube (around 2.2 for an
NTSC monitor) to produce an overall gamma of 1.43 (0.65 x 2.2), which
can be electronically corrected (0.7) for overall unity (1.43 x 0.7)
gamma.
Basically what's outlined here is how to produce a "linear" signal
from a low gamma camera, which then gets translated to an NTSC
monitor which by its nature projects a gamma value of 2.2. In this
example we're modifying the gamma characteristics of the video camera
so that the output is compensated for the picture tube which is 2.2
the calculated value per NTSC specifications.
Theoretically a frame buffer should provide a linear gamma of 1.0 on the output
side in composite. Of the three I've checked the Targa, the Ill Pro and the PAR
all ouput a gamma of neutral at 1.00 and slightly modified at 1.2 in stock
configuration. Which leaves gamma adjustment values between 1.8 and 2.2 Gamma
correction does affect the "apparent" brightness of an image but does not
increase the brightness. Instead, it would seem that the apparent brightness is
due to a desaturation of the darker and lighter pixel values, rather than
actually increasing the luminance bandwidth. This is an important point as it
has a direct bearing on whether the formula works with gamma corrected pixel
values.
From what I can tell looking at WFM/VS it does appear that there is a
broadening of luminance over a wider range of pixels rather than an increase in
luminance. Which would indicate that the formula is accurate regardless of
whether gamma is applied or not. I believe Jack P alluded to this point in a
discussion with Don L. quite awhile back. As I recall there was some confusion
on this point but it does make sense at least from what I can see.
So if you find it useful great. I doubt there is any inherent flaw in using it
as a similar formula is used for checking Abekas YUV transfers and the Abekas
expects images to be gamma corrected and so far none have failed that met the
formula's parameters.
More than you probably really wanted to know, but as the issue was raised and
in appreciation for your interest, I felt a thorough follow up was in order.
If nothing else it should give you some fail safe parameters to work with.
And hopefully soon I'll be able to find some more time to write a program which
will make it a little easier to use.
John
Paul:
Unless someone pulled my original uploads on the color bars the ones in the
library were originally intended for use with the targa+ board. I also
submitted a "NTSCCB.prj file that you could render. This file was produced
with release 2.01 I believe. The output was checked with a vectorscope from
the targa+ output.
If you have a PAR, I believe it comes with some software testpatterns that have
a set of bars75 and a set of SMPTE bars.
Generally speaking you should always record your bars from a device that will
also be outputting the program signal to be meaningful. In this case it would
be your PAR. If you record BARS from a house test generator and then hook up a
PAR device with a long feed line the colors just may be quite off (line length
phase shift). IF you use the PAR to generate the bars you will see the problem
and correct it at the recorder Proc amp/TBC prior to recording.
Thanks for the info, Don. I guess it's been a while since I dl'd the file
from the library, I thought it had been John's.
I copied the NTSCCB.TGA you uploaded to my PAR and the scope said all but
one or two of the colors were good, and the ones that weren't were really
close. I was just wondering if there was a method I should be using to create
my own test pattern from your NTSCBARS.PRJ file for every project, but it
sounds like that's not going to be helpful. I wish I had a scope myself.
Thanks for the uploads. 🙂
Paul S.
Since you apparently can gain access to a scope you should check out
the bars that come with the PAR. Then you could use these as the
default colors and just be sure your lines are short (less than 10
feet) and use the PAR bars as reference. As I said earlier the bars
I up loaded were meant for the targa+.