"The correct default behaviour is to clip those values."

One of many possible behaviours, which could be correct, – if reference white is where it is supposed to be – nowaday is to let superwhite untouched (if not meant for computer use where it is likely studio swing will be stretched to full swing, but even then you needn't clip them because it will happen anyway).

If not even tv-stations, receivers, dvd players, blu-ray players, HDMI, HD-SDI, LCD panel displays clip those values – why should I do?

There is a world of difference between mapping and amputating super whites. Only one of those could be called "correct," because the other typically looks like crap. Example to come.

Yes, and in many cases neither of this must be done mandatory.

Saw the broadcasting examples above? No clipping, no mapping. Also the devices mentioned above do neither, nor (in a digital area).

[I]"Because all that gear was analog and it drifted, plus the FCC had very specific technical standards to which the signal had to conform in order to be "broadcast legal." I come from the old analog days and it was a pain. "[/I]

Those standards exist so that everything "just worked", the people using the gear didn't have to be engineers and didn't have to think about all the technical stuff.

For sure it was a pain and the advent of digital video relieved all that pain.

That doesn't mean that we should abandon having standards and that the systems should no longer just work, quite the contrary I would have thought.

Now just because we have standards doesn't mean we should forever constrained by them. Even "back then" people did find creative ways to work by going outside the standards but there was always very obvious warnings that certain pieces of gear were not setup to the standard. For example we had one UVW 1800 with a big yellow and black label that said "SUPERBLACK".

Bob.

As true today as then, the real limitations are in the ability to mass deliver, not produce.
IOW, bits delivered != bits acquired.

I started using "SuperBlack" because it made for much cleaner luminance keys, initially, it drove the engineers crazy, "You can't do that!" It did kind of complicate things though, you had to keep track of what was recorded "SuperBlack" and what wasn't.

Yes, and footroom below reference black still is differently handled compared to headroom above reference white. Other than headroom, values below 16 will be mapped to darkest luminance possible on a correctly set LCD TV device.
So at least for a final product there is no use no more for footroom, even if there was before in various processes from camera shooting (where footroom helps for noise compensation) to postproduction (compositing) and tv calibration (use of PLUGE signal).

Musicvid said:

[I]"As true today as then, the real limitations are in the ability to mass deliver, not produce"[/I]

Absolutely true. As I only recently found out Vegas's internal audio pipeline doesn't clip until around +150dB. Even so for obvious reasons all the metering still shows clipping at 0dB and one would expect the rendered audio output to clip at 0dBFS.

When the transition was made from analogue to digital audio we were lucky, 16bits was more than enough to emulate what most analogue recording systems were capable of. In fact it really was overkill and it wasn't uncommon to use 12bit audio for digital tape recordings, my old TASCAM DAT supports 12bit/32KHz and I have a lot of tape recorded with that, perfectly fine for dialog.

Things were not that simple in the video world though. A clue is that when Sony took their Betacam format from analogue to digital the Digital Betacam VCRs recorded 10bit per channel Y'CbCr.

Then along came the consumer Digital 8 and DV/DVCAM which was 8bits per channel Y'CbCr which were for many good enough and certainly an improvement on VHS.

The next complication was digitally editing that digital video.
That required not simply getting the data into a computer but also converting from Y'CrCr to RGB so that software could work. With how SoFo decided to do this with Vegas there's two problems, not one.

1) The pipeline is only 8bits per channel and to convert from the very efficient Y'CbCr to RGB one really should have more than 8bits per channel, in other words one needs to be careful or fidelity will be lost. The normal way it was decided this should be done meant that Y' = 16 should map to 0,0,0 and Y' = 235 should map to 255,255,255. Arguably it would have been good to use a 10 bits per channel pipeline however that doesn't make sense with computers, it in reality would have been a 16 bits per channel pipeline. Some solutions went down this path. I see it as a pity that SCS has never offered such a pipeline instead opting to go directly to 32bit float.

2) Computer graphics and digital stills used "Computer RGB" because that's how the displays worked. Most of the nascent web video systems conformed to this. Vegas got it really confused but it's own graphics and text generators conforming to a different set of rules, that's very confusing.

2) is the thing most of us talk about because it's obvious but 1) is arguably more important if you're worried about image fidelity.

Bob.

just as an observation....

i don't know of a single household with a crt anymore - and i have just spent a couple of weeks shooting ww2 vets in both town and rural locations. not a single one had a crt, all had panels of one sort or another....

why in this day and age are we still concerned with crt vs lcd levels? why interlace (though i would hate to stop shooting it) when there's nothing displaying it anymore?

simple mind i know, but having read this thread i'm MORE confused than ever ;-(

Ushere,

In the US we are still concerned because the FCC and Networks require that broadcast signals be compatible. We still have to adhere to 4x3 boundaries for graphics and titles and video levels have to adhere to the 7.5 and 100 boundaries.

Although in some, blacks at 0 ire are allowed, but in most cases whites only up to 100 ire.

The PBS Technical Operations

http://www-tc.pbs.org/producers/TOS_2007_Submission_8_20_07.pdf


Austrailian ABC network

http://www.abc.net.au/tv/independent/doc/ABC_Delivery_Specs_Aug_2011.pdf

NBC specs

https://nbcusales.my.salesforce.com/sfc/p/70000000Ix7F/a/7000000090sX/9ORBBBks5dZ9nPmTnWGq69AEqOUCZAPgS9ZikaJ2j.g=

"i don't know of a single household with a crt anymore..."

I still have my Samsung 27" HD CRT and my Sony 19" SD CRT. Both weigh a TON but still work fine.

I also have a 32" LCD.

The current waveform monitor was designed the way it is so that old techs like me could transition from the analog world to digital and computers.

All SCS really needs to do is keep the core of the software for it, make the settings for 16 to 235 (no 7.5) and change the display to show 0 to 255. With these settings there is no need for the confusion of the other settings. Where 0 currently is, make that 16. Where 100 currently is, make that 235. Below 16 and above 235 are overshoot areas.

Without any of the auto-stuff, one can clearly see what their levels actually are and correct them accordingly. They can opt for an auto or manual fix. Whatever meets their needs.

SCS can still provide an option for what there is now for those who want/need it.

That old tech is a waste of electricity.

There is a world of difference between mapping and amputating super whites. Only one of those could be called "correct," because the other typically looks like crap. Example to come.

So here's where I am coming from.

Suppose you have a broadcast master that is played back over SDI (or firewire) and ingested into Vegas. The broadcast master will have black at Y' = 16 and white at Y' = 235. Multiply by 4 if we're talking about SDI.
This is the standard. Everybody should obey it.

The default should be to (A) obey standards and (B) not alter the signal.
If Vegas automatically applied some sort of video legalizer algorithm to every project, then sure it would make most camera footage look better. But this would alter footage that is perfectly fine and doesn't need adulteration, such as material from a broadcast master.
So by default, no broadcast safe filter or video legalizer stuff. The user can opt-in for that stuff.

2- In a broadcast environment, video will usually/always be run through a video legalizer to deal with the illegal values coming from cameras.

in reality would have been a 16 bits per channel pipeline. Some solutions went down this path. I see it as a pity that SCS has never offered such a pipeline instead opting to go directly to 32bit float.

I think that SCS made the right choice in avoiding a 16-bit pipeline. There are things that you can't do with 16-bit that you can do with 32-bit (e.g. optically correct compositing, HDR, etc.). And 16-bit isn't really faster if your plug-ins are converting the values to 32-bit internally. There is overhead in converting between integer and floating point numbers.

Anyways... I don't think it's a big deal.

Without any of the auto-stuff, one can clearly see what their levels actually are and correct them accordingly.

I want everything to come in correctly in the first place. (Which is how things in most other NLEs work.)

Suppose somebody using another NLE exports footage from a broadcast master in multiple formats.
If you bring stuff into Vegas, you realize that the same footage may be coming in with different levels.
JPEGs and still image sequences decode to computer RGB.
Most "video" formats decode to studio RGB. (Assuming you aren't in 32-bit floating point mode, which is another can of worms.)

A computer can automate all of this nonsense for me. Users save time, avoid errors, and don't lose ANY flexibility. The downside is that the programmers will have to put in some work.

2- Superwhites have to be manually dealt with no matter what system you go with or what NLE you use.

"In a broadcast environment, video will usually/always be run through a video legalizer to deal with the illegal values coming from cameras."

This is a relict from the past and it is slowly vanishing. Many broadcasters don't use legalizers no more.

For studio program creation the OCP operators use presets which still limits peak black and white to a certain amount. There are different presets in use and they reach from 0–100 % to -3–109 %. Two BBC presets are rather common now which reach eather from 0–103 % or from -1–105 %. See the broadcast examples I linked in a posting above. They demonstrate how loosely handled signal limiting is meanwhile and we are going the route to no more signal limiting at all (for broadcasting).
This is the studio OCP for the studio camera adjustment, not the system used before transmitting. After the signal passed the studio or signals coming from the editing suites, in many cases no more limiting happens. If an editor feeds footroom and headroom, meanwhile it is likely it will be transmitted.

Also take a look at Poynton's blog entry "Legalizers should be outlawed". Here is a quote from Poynton:

"In acquisition, post/DI, recording, mastering, transmission, and consumer display there is no longer any need to limit the coding of 8-bit video signals to the range 16 to 235 (or 10-bit signals to the range 64 to 940); apart from avoiding all-zeros and all-ones codes across HD-SDI interfaces, there are no “legal” requirements to limit range. The recent HD studio display standard (BT.1886) is unequivocal that the 10-bit signal is expected to continue along the standard 2.4-gamma curve past reference white all the way up to peak white, with no interruption or clipping.".

(Sorry, I know I recur. And it's likely it won't be the last time … :D)

.

The ABC paper allows peak tolerances up to 104 %.

NBC specs refer to reference levels, not to peak levels.

But I'm amazed the PBS really still holding on hard limiting to 0–100 % (thanks for sharing the link to the papers) as all over the world broadcasters started to support wider tolerances or even abandon limiting.

So again we see there is not the one and only truth about "correct" level handling.

.

"Two BBC presets are rather common now which reach eather from 0–103 % or from -1–105 %."

I do not know a whole lot about the BBC and what they require but here in non BBC land if I let the video exceed 100% then those portions of the video are lost. I have seen this with a test pattern. Below 16 is also lost. So I either use the Sony Levels to squish it into the correct range or the details below 16 and above 235 will be lost. In my case and cameras, above 235 only because my cameras shoot at 16 to 255. I see this on my CRT and LCD TV's. Even on my external monitor.

In another post it was stated something like the video should be correct in the first place. I 100% agree but someone needs to tell Sony that their consumer cameras (The ones that I can afford) are not doing it correctly in the first place by going from 16 to 255. Even on my external monitor (low budget) that expects 16 to 235 I have difficulty seeing if the image is too much on the high side but I have learned some ways to work around this. At least on the little camera display there are zebra stripes to give me a good hint but even those are not always reliable. There is a long explanation for that I will not include here.

For me, it is quite simple. I used the NTSC test pattern in Vegas and put it on the timeline. I set the waveform monitor such that the brightest whites are at 100% and the blacks (except for the lowest part of the PLUGE) is at 0%. The lowest part of the PLUGE goes a little below 0% like it is supposed to.

With the exception of the overshoot from the sharpness filter, all of the video is from 16 (0%) to 235 (100%) on my final videos.

Not to toot my own horn, I get complement after complement after complement from those who view my videos as to how clear and professional they are. Note: I am still my own worst critic but I am so glad that those who view my videos say how great they are.

The final results and complements says to me that I must be on the right track no matter what anyone here says about it.

I got tired of spending hours trying to squeeze out the last drop of the lowest bit rate with the intermediate stuff and then HandBrake, so I simply render to MP4 (for the internet) with the Sony thing at 5,000,000 bps and send it on its way. I use the DVD Arch settings for DVD and send that on its way.

As long as THEY love my work and videos, why should I rack my brain messing with all of this stuff? NO THANKS! I will continue to do what I know that works for me!

[I]"The ABC paper allows peak tolerances up to 104 %"[/I]

I think you'll find that's for "composite" levels, not luma which is limited to 100%.

The Vegas Waveform monitor will display either as will the hardware scope so you need to be a bit careful.

[I]"But I'm amazed the PBS really still holding on hard limiting to 0–100 % (thanks for sharing the link to the papers) as all over the world broadcasters started to support wider tolerances or even abandon limiting."[/I]

I cannot speak for every broadcaster but some such as our ABC seem to have just got fed up with people who cannot be bothered to get it right. So if you get it wrong it'll go through a "sheriff" and like the sheriffs of the Wild West you mightn't like what he does to your content.

These standards apply not only to what you submit to a broadcaster but also to what they broadcast. One of our commercial broadcasters decided to get creative with what they broadcast recently and got a "show cause" letter from our regulatory body.

Bob.

"if I let the video exceed 100% then those portions of the video are lost."

Please further describe your surroundings where this happens.

I'm well aware there are cases where this happens. And I also see maybe the US broadcasters are more strict than others (just analyzed some SD program stuff from CNN and this really was hard limited to 16–235).

On the other hand there are many cases where no limiting happens and none is required. I already posted this link to a test signal PNG with text at value 254 on a background at value 244. This is used encoded to MP4 H.264, authored to Video-DVD and to Blu-ray-disc. It should have been tested on video equipment connected via HDMI (no computer, no analog components) to a LCD panel TV device. It run through more than 30 systems now and none of them clipped the signal but clearly displayed the text. And this is what is expected behaviour due to HDMI-Specs, BT. 709 and EBU Tech. 3320.

.

Quoted from that paper:

"Maximum video levels of program material with reference to line up signals shall be 700 mV plus an operational tolerance of + 28mV (up to 104%) for luminance (Y)"

And here again a quote from EBU Rec. 103 which is the paper for "Tolerances on "Illegal" colours in television":

"Tolerances on colour gamut"

As already mentioned, in practice there are even wider tolerances used by many broadcasters.

.

Marco. said, " I already posted this link to a test signal PNG with text at value 254 on a background at value 244."

Here is what happens when I render as is.

http://vimeo.com/95399657

And here is what happens when I use Sony levels to lower the video level down to 100%

http://vimeo.com/95400220

Maybe things are different in your part of the world, but here in the USA, this is the way things are and I have to edit my videos for the way things are here.

Imagine an auto setting trying to figure what you need and what I need. What a huge mess it could create!