Video Signal Measurement and Standardization

[Bill Ravens]

I agree, Shaun. My own turn as devil's advocate, though would follow up on your comment re: 8-bit, 10-bit, whatever. Clearly the convention for what is digi-black is shifting around when the encoded bitrate shifts. How to deal with this? It's still up to the DP, human imput needed? yet, it's gotta be detectable in the header, or something. Scopes that I've seen don't know the difference between REC 601 and REC 709.....that bothers me.

In the end of things, WHATEVER digi-black is defined as, it has to be played back at IRE 7.5 on an NTSC analog display screen. That's a gain setting. And digi-white falls out from the gamma curve. So, in the conversion to analog, a gamma curve is needed(slope or non-linear, take your pick). That's just another gain setting. If it's played back on an HDTV display, the gain settings change...I THINK it's that simple, but, I could be wrong...in fact probably am.

[Shaun Roemich]

Originally Posted by Bill Ravens

In the end of things, WHATEVER digi-black is defined as, it has to be played back at IRE 7.5 on an NTSC analog display screen.

So here's hoping that the LOGICAL response to the "banishment" of analog over the air broadcasting is a complete phasing out of analog gear, along the same lines as colour supplanting black and white...

And a follow up: correct me if I'm wrong but 7.5 IRE is only a requirement for NTSC TRANSMISSION, correct? You can safely pass 0 IRE over local analog connections, if I'm not mistaken. Does our "gift" from the regulators in February make 7.5 IRE essentially obsolete?

[Bill Ravens]

Originally Posted by Shaun Roemich

So here's hoping that the LOGICAL response to the "banishment" of analog over the air broadcasting is a complete phasing out of analog gear, along the same lines as colour supplanting black and white...

And a follow up: correct me if I'm wrong but 7.5 IRE is only a requirement for NTSC TRANSMISSION, correct? You can safely pass 0 IRE over local analog connections, if I'm not mistaken. Does our "gift" from the regulators in February make 7.5 IRE essentially obsolete?

I will bow to the East when NTSC is dead and buried. (maybe I should be bowing to the west, toward Japan)Unfortunately, I believe NTSC is more than a broadcast standard. I think American NTSC TV sets expect analog black to be at 7.5 IRE. If it's not, the TV will crush the shadows. Also, DVD players destined for sale in the USA ADD setup to playback. There are codecs that incorrectly add setup, resulting in a blown out image on a viewer that does not comply with NTSC standards, like most computer monitor screens. Just part of the reason I think a WFM is so important.

[Robert Wiejak]

Originally Posted by Shaun Roemich

...Does our "gift" from the regulators in February make 7.5 IRE essentially obsolete? ...

No. The date changes nothing and your output really depends on your target audience.

If you produce for TV then you still need to confirm to broadcast standards. If your target audience is computer display, projectors, etc. you can produce anything you like – anything your target can display. The ‘February 2009’ date you guys speak of, has nothing to do with NTSC or levels within. It only has to do with over the air method of transmitting the TV signal. The old analog (AM) transmitters OFF, new digital (ATSC) transmitters ON, that’s all. The output of the new DTV converter boxes will still be the same old analog NTSC signal and/or some modern variation of it. The same old method of transmitting analog TV (AM) will still be in use for years in cable. So nothing is changing.

If I may ask: Just out of curiosity, what is it that troubles you so much about ‘7.5 IRE’?

Rob

[Bill Ravens]

For myself, 7.5 IRE is a small annoyance by itself. Yet in my mind, it represents all the "problems" associated with rasterized image display, all the problems with the "funkiness" that is NTSC, including but not restricted to interlaced images, 60 fps, color standard confusion, and all those kinds of legacy issues. NTSC TV has defined the nature of motion images, whether it's over the air or not, since it was invented. It's archaic, archane and totally needless.....except that it sticks like a bad headcold. It means that production has to account for NTSC (USA), NTSC (ROW), PAL, 601/709, and now HDTV. Can't help but think how much easier things would be if there was only one or two standards, instead of half a dozen.

[Bob Grant]

Originally Posted by Bill Ravens

I will bow to the East when NTSC is dead and buried. (maybe I should be bowing to the west, toward Japan)Unfortunately, I believe NTSC is more than a broadcast standard. I think American NTSC TV sets expect analog black to be at 7.5 IRE. If it's not, the TV will crush the shadows. Also, DVD players destined for sale in the USA ADD setup to playback. There are codecs that incorrectly add setup, resulting in a blown out image on a viewer that does not comply with NTSC standards, like most computer monitor screens. Just part of the reason I think a WFM is so important.

Not that I live in NTSC land however I think I can safely say, yes USA TVs do expect 7.5 setup on their composite inputs. Digital transmission would most likely not have setup, the same as DV doesn't. It's the responsibility of any D<>A converters to add/remove the setup. My ADVC-300 has a switch for this purpose, On if I was to deal with analog tapes from the USA, Off if they came from Japan. That said it would appear that some of the early A<>D converters did not do this. Levels are not the only area of confusion either. Some of the early systems used a different number of pixels and field order.

The issue here really is that at acquistion anything that will fit into the available number of bits can and is used. Broadcast standards exist for broadcasting, so everything conforms to the one standard and for obvious reasons. If you want to hand a tape to a broadcaster to put to air it needs to conform to their standards, if it doesn't and they're serious about their sound and images they'll likely reject it. Internally broadcasters tend to shoot vision and record sound to their standards, especially for ENG. This caused me some degree of confusion at first as their tapes seemed to have low audio levels etc. However their thinking is valid. They might need to take a tape straight from a camera and play it to air. We're not working under those constraints and the full range of digital values is at the disposal of our cameras.
Certainly a cheap portable HD/SD SDI waveform monitor should find a market. If it was reasonably priced I'd buy one for use with my EX1 as the built in histogram is less than useless although I can generally get by with the zebras they tend to get in the way of the other functions the camera's monitor gets used for. So yes, I'm as interested as Bill in such an instrument but I know it will not be a solution to all the issues he raised initially.

When I'm handed a DV or HDV tape I always check it with my NLE's scopes so I know what I'm dealing with. I check anything of dubious parentage on a CRT as well. More than once I've had media with the wrong field order or files with mixed field order. Based on what my scopes read I deal with it as need be to preserve all of the dynamic range that was recorded. Depending on what the deliverable format is then I may need to adjust vision levels to suit. I notice there's a lot of interest in using the latest digital still cameras to shoot moving images. I'll bet they're not conforming to any SMPTE standard, at a guess they'll likely record the same way as they record till images, using all the available bits.

[Bill Ravens]

Hey...


MERRY CHRISTMAS, everyone.

[Robert Wiejak]

Originally Posted by Bill Ravens

...For myself, 7.5 IRE is a small annoyance by itself...
...It means that production has to account for NTSC (USA), NTSC (ROW), PAL, 601/709, and now HDTV. Can't help but think how much easier things would be if there was only one or two standards, instead of half a dozen...

I don’t agree with you there. I think you are a bit overwhelmed with all these different standards for no reason at all.

If for luma (value Y) you only stick with these two numbers: 16 and 235 (for 8 bit coding), you will be 99% broadcast compliant in NTSC, PAL, SECAM lands and HDTV. There is no need to differentiate for what standard you are producing. The big confusion and I mean the BIG CONFUSION, is in a way different standards interpret these two values. Let me explain:

ITU-R BT.601 - ‘Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratio’.
ITU-R BT.709 - ‘Parameter values for HDTV standards for production and international programme exchange’.

These two documents as you know, define all parameters for encoding of all SD and HDTV television standards. Aside from the numbers of lines and method for encoding color, these two standards also define minimum and maximum values for parameters like Y, U and V, the bread and butter of video signal. Guess what!? Across all these different standards, the limits are all the same for 8 bit coding.

Quote from ‘601 (just the relevant parts):
http://www.zabcia.ca/pics/601-1.gif

These 625/50 and 525/60 systems, effectively are describing NTSC, PAL and SECAM.

Quote from ‘709 (just the relevant parts):
http://www.zabcia.ca/pics/709-1.gif

Same as above, the table describes parameters for all forms of HDTV.

So if according to ‘601 and ‘709 the limits for Y, U, and V are identical across NTSC, PAL, SECAM and HDTV, then why the confusion?

For different reasons, each system (NTSC, PAL, SECAM and HDTV) looks at the same numbers and reads them differently.

From the tables above we know that black is defined as Y at value 16 and white as Y at value 235 no matter what system.
In USA and Canada we have NTSC and we use IRE scale here. Due to the way some test signals were designed (SMPTE bars) the IRE scale start at Y = 0 (0IRE) (this is to accommodate PLUGE). So if Y at 235 is 100IRE then Y at 16 is 7.5IRE.
In PAL and SECAM land they don’t use IRE units and they don’t have black setup, they use percent of Full Scale. The scale there starts at Y = 16. Therefore black (Y=16) is 0%FS and white (Y=235) is 100%FS.
As you can see there is no way of getting away from these two number no matter what system you work with. But, I can also see how one would confuse the two different methods of reading the same values:

       |   Y    |  IRE  |  %FS  |
---------------------------------
Black  |   16   |  7.5  |    0  |
White  |  235   |  100  |  100  |

IRE = NTSC
%FS = PAL, SECAM, NTSC(JP)

The same values are true for HDTV signals. The only exception is when using 10 bit coding. Then the black is at 64 (16*4=64) and the white is at 940 (235*4=940).
So no matter what system you produce for, as long as you stick to 16 and 235 limits, you have nothing to worry about.

For colors (chroma) there are different considerations, so I won’t even go there.

But, there is one more thing worth mentioning about HDTV. If you look at section 5.7 ('709), you will notice that the video data in HDTV can span from 1 to 254 and there are two ‘reserved’ values 0 and 255 – they are reserved for timing reference. I don’t know how or where they are being used, but I would avoid these values at all cost.


Merry Christmas

Rob

[Bill Ravens]

Thanx, Rob. You and I understand, it would seem. Unfortunately, there's a LOT of people out in the production world who don't. What I get are files that don't comply because of confusion about these issues. To add to the complications, some codec software writers don't get it, either. And therein lies the crux of my dissatisfaction. Some codecs will remap to 16-235, while others map to 0-255. ALL codecs should allow the user to pick, if I were king. Problem is, most codecs have no operating guides to describe how and when they remap or pass thru. Some cameras generate superwhites. I suppose it's because the maker wants to squeeze as much data as he can into 256 bits, I don't know. And then, there's the issue of video for the web, which isn't NTSC, at all, with RGB 0-255. And, as you point out, 10 bit will add a whole new dimension to the confusion for them.

With all these permutations, NLE scopes show the timeline color mapping. NLE's aren't smart enough enough to show waveforms AFTER rendering, altho' they could be made smart, they aren't. What has the editor gotten after a render? It depends on what codec was rendered to, and how the codec is designed to remap values.

[Shaun Roemich]

Originally Posted by Bill Ravens

With all these permutations, NLE scopes show the timeline color mapping. NLE's aren't smart enough enough to show waveforms AFTER rendering, altho' they could be made smart, they aren't. What has the editor gotten after a render? It depends on what codec was rendered to, and how the codec is designed to remap values.

I suppose you are talking about an EXPORT render here? The WF/VS in my NLE SHOULD be showing me the values that will be created as part of my render file created to display my sequence in realtime (ie. ProRes material captured, edited on a ProRes timeline, colour corrected and rendered to ProResfor output via an I/O card should maintain the integrity of the values the scopes indicate AT LEAST until the video hits the output stage of the card (which may have gamma lookup tables or 8 to 10 bit converters or other"magic" going on)).

BTW, this is a GREAT discussion!

PS. I am one of those editors who works with my NLE's WF/VS open during colour correction and fine tunes before final output. Glad to see I'm not the only one...

[Bill Ravens]

sorry, I use "render" and "export" somewhat interchangeably. I am talking about exporting. as a practical example of what I'm saying, bring a smpte colorbar pattern into your NLE. Be sure to include pluge. Export the colorbars and pluge to both Windows Media and something like an MPEG2 file. Import both the WMV and the MPEG2 back into your NLE. Look at the waveform and vectorscope for all three. Are they identical? Have the luma values been shifted? what about the color values? if you have an eyedropper tool in your NLE, measure the color bars for each. are they all the same?

[Ron Cooper]

Just for my cent's worth. I don't go into the detail most of you guys do but I think you hit it on the head Bob with Standards.

I have an expensive and very useful Sony DVD recorder with firewire input, which is just a few years old now, but if I feed it directly from say, the timeline in premiere 6.5, (I wish I could do this in Vegas), it often produced overloaded sound, even when I did an audio calibration line-up in Prem. In anolgue parlance I would call it input overload. In digital it is disgusting !

Obviously there are some different standards here as I had not encountered it with other devices such as cameras etc.

As usual, Sony were quite useless as they never admitted to anything wrong with their product other than to blame Adobe !

As I am now aware of the problem, I make sure my levels are lower than normal to overcome this problem.
Standards, what are THEY !

RonC.

[Bill Ravens]

Originally Posted by Shaun Roemich

I suppose you are talking about an EXPORT render here? The WF/VS in my NLE SHOULD be showing me the values that will be created as part of my render file created to display my sequence in realtime (ie. ProRes material captured, edited on a ProRes timeline, colour corrected and rendered to ProResfor output via an I/O card should maintain the integrity of the values the scopes indicate AT LEAST until the video hits the output stage of the card (which may have gamma lookup tables or 8 to 10 bit converters or other"magic" going on)).

BTW, this is a GREAT discussion!

PS. I am one of those editors who works with my NLE's WF/VS open during colour correction and fine tunes before final output. Glad to see I'm not the only one...

Unfortunately, I have yet to encounter an NLE with a built in set of scopes that "scope" the post-export image. If they did, half of my consternation would be solved.

And, a resounding YES! How can anyone do cc without scopes? Without them, it's russian roulette. I am quite fond of adjusting the gamma curve slope. Doing this, it is very very easy to exceed broadcast standard limitations, even if the gamma curve endpoints are fixed at legal values. Without a scope, you just can't see that.