@atom12, funny thing is, when i first started to try and figure this problem out, first thing i did was check the Track Properties for a button to set the background Black 0 instead of transparent! ... expecting it to simply 'be there'.. but no...

That would indeed fix the blacks. A big improvement. However whites need sorting too without having to insert Sony Levels in the video master buss, which of course would work but its not ideal.

Renders should simply default to 16-235 'output' (nothing to do with what cameras or graphics are coming into Vegas).. I really cannot think why it does it otherwise. Maybe someone can explain why it does it this way.

Paul.

"Maybe someone can explain why it does it this way."

Because Vegas is also a compositor.
The default background isn't absolute black, it's nothing i.e. 100% transparent, it has to be, because that's how it works in any compositor. Unfortunately unlike After Effects Vegas doesn't have an option to display the standard checkerboard that denotes transparency. Of course not too many codecs support transparency so when rendering to those Vegas is forced to render transparency against absolute black which makes perfect sense, if it used "legal" black the result would be wrong.

Part of the problem also is users keep on forgetting that the fade envelopes control event transparency, sure on the monitor it looks like a fade to black but it isn't. Vegas does have a fade to colour envelope which does give the correct outcome if you can be bothered to set it up correctly.

Bob.

Well that makes sense Bob. And yes because its a compositor and not just an editor, it needs transparency for that.
But i still think when it comes to final rendering out, it should be 16-235. I know its not a definiate reason but it is the way the other NLEs do it (i tested pp5 only).
Its such a pain to have to mess with levels FX, dragging a black media event across the track nonsense. Yes it works, no argument, but why the hastle? And reading various posts, most people dont even know how to set it up correctly. Its causing quite a bit of confusion as you can see above. I wonder how many Vegas projects got rendered out in the wild but show with too much contrast!
Anyway, thats my 2p's.

Paul.

"Its causing quite a bit of confusion as you can see above."

Indeed. You want more confusion?
What happens when I nest a project, I oftenly do that and I expect transparency to flow from the child to the parent.

What Vegas needs to do is to introduce the concept of a "sequence" that defines how media is to be handled. We have that but only half done with Project Properties.

Bob.

I agree, Vegas should handle all this correctly however it is not a trivial task.
Right now the onus is on the user to handle the complexity.

A lot of the complexity is unnecessary. You almost always want to convert everything to either computer RGB or studio RGB. Vegas should do this for the user, but it does not. I do not believe that this is that difficult for Vegas to do. Remember... every other NLE on the market does it for you, even iMovie.

Of course once you solve the simple problems, then you will realize that there are other nasty problems that are more difficult to deal with. These problems have always been there. It's just that Vegas hasn't really tried to deal with these problems and/or people don't notice these problems.

1- When you convert from 8-Bit Y'CbCr to 8-bit studio RGB or computer RGB, you will have rounding error. 8 bits isn't really enough in some rare cases as you could have banding problems.

2- 8-bit studio RGB can't really handle all the illegal values that some cameras shoot.

3- 32-bit floating point math is slow. 32-bit floating point math is slower than 32-bit integer math (which is kind of 4 times slower than 8-bit). But 32-bit floating point does solve the problem of 8 bits not being good enough. It also allows for certain things like linear light processing (though that has its own issues).
*GPU acceleration helps... but not all Vegas users will have a compatible GPU.
(This is an area where Vegas has gotten better.)

4- Vegas' FX have to be manually set to be appropriate for studio RGB or computer RGB. They do not automatically pick it up. The onus is on the user to manually set the FX for the appropriate color space.
Some effects and compositing modes are not written to handle studio RGB levels. A lot of FX like curves do not come with presets to handle studio RGB.

5- (easy problem) Vegas' scopes have to be manually set for studio/computer RGB.
5b- Vegas' scopes are poorly designed. If you check the 7.5 IRE setting, there is no 7.5 IRE line on the scopes. The least confusing approach would be to highlight illegal values in red (I would prefer this), or make the scopes look like how a hardware scope would look.

6- The whole concept of not re-compressing DV/HDV is problematic. If you have 2 very long clips with a small cross dissolve in between... the right thing to do is to render both the very long clips. Otherwise you have a jump between 1st generation --> 2nd generation of compression.
If you are working with 8-bit studio or computer RGB, converting to these color spaces can result in clipping which can make the 1st->2nd generation noticeable.

Bob? I've got Transparency coming from a Nest into a Parent? The Nest has Text and a Chroma Key sample. Both retain Transparency in the Parent veg.

Please explain?

Cheers

G

"Bob? I've got Transparency coming from a Nest into a Parent? The Nest has Text and a Chroma Key sample. Both retain Transparency in the Parent veg."

Nothing to explain, that's what Vegas does, that was my point.
However if as requested Vegas applies automatically a bottom track of legal black then you lose that.

Bob.

You've used an example of how Vegas DOES/should work - the trannie via Nests - but that is NOT how Vegas treats Black?

I'm lost here . . . .

G

"but that is NOT how Vegas treats Black?"

Currently when Vegas renders 100% transparency to a codec that does not support transparency it uses absolute black as the "bottom track". That means blacks are not consistant and for most puposes any transparent areas are at illegal levels.

The fix is to remember to place a bottom track of legal black.


To avoid having to do this some users are asking for Vegas to automatically place a track of legal black as the bottom track.

My point is that if Vegas does this is it will prevent transparency from being rendered to codecs that do support it plus when nested transparency will be lost.

Bob.

"...You want more confusion?" from farss.
No!! hehe i want less!

The whole idea of placing a legal black track on the time line is just a 'band aid' to get the right output levels, i for one am not suggesting this IS a proper fix. Its not.
Like i suggested a while back, this levels process should be done at render time - ie in the video main buss only, so all transparency tracks stay as is. But when we render out, its legal 16-235. Thats all i want really. Same as the other NLEs. Its not that hard to do, simply placing AAV on the main buss with 16-235 output levels preset does exactly this. Thats my point. And if i wanted 0-255 out, i'd switch it off (but i have never needed to do that, not ever).

Paul.

recap, What I am reading from this thread so far:

1) there's a LOT of confusion about this
2) there are multiple ways this could be addressed
3) black track media and Levels FX on main buss is a work around only, not a fix
4) its been a problem with Vegas for years..
5) it is more complex than at first sight, transparency events for comps and embedded projects etc.
6) it should be improved! i think we all agree in that fundamental point.

Paul.

Ah, this is starting to come back to . . . . . ugh . . I feel sick.

I remember futzing about with the MINIMUM amount of a BG to give/tell my DVDA STB that there WAS Pillars around a 4:3 to reveal a rather nice border . . whatever . . . but this was a magic number around 41 or 48 in terms of Levels. It was as if the STB was being given the info it needed.

T'was a total mare!

G

Paul,
you're mixing up two issues there.

If I place video with legal black on the T/L then it most certainly renders out legal black. Of course if I place an image from a DSC on the T/L which uses a different colour space then it gets rendered out exactly as it was.

In fact what should happen is way more complex and as Glenn Chan has rightly pointed out then a whole raft of other issues also need to be addressed. Because of the dictates of compositing which Vegas supports video from a typical camera should have it's blacks mapped to 0, not left at 16. Otherwise black + black will not equal black.


The other issue is related to transparency and AAV Lab simply seems to cure the problem but it has a bug in it, it fails to pass through the alpha channel data and seems to totally ignore it.

To even further compound your thoughts, the industry standard way of rendering something with transparency in things that don't support it is to use superblack. We used to have a BetaSP VCR with a warning label on it, "Modded for Superblack"


Me thinks a big problem here is a lot of users are seduced by Vegas's simplicity. Under the hood it is way more capable and complex than it appears.

Bob.

Me thinks a big problem here is a lot of users are seduced by Vegas's simplicity.
Ah, so it's the Users naivety in not understanding and not being aware of these things. I take your point.

Under the hood it is way more capable and complex than it appears.So, a solution would be to make this process more . . ahem . . transparent? Or to put ALL Vegas Users through a vigorous Training Program before they are let loose on Vegas.

Cheers

G

"Ah, so it's the Users naivety in not understanding and not being aware of these things"

I wouldn't blame it on the users,
It looks simple and it is enticingly easy to get up and running doing something.
Tha'ts probably a great thing. My mistake was not to really get to understand Vegas fully for years and even now I'm still plumbing new things and ways to use it.

"Or to put ALL Vegas Users through a vigorous Training Program before they are let loose on Vegas."

Somehow I don't see that as happening. On the other hand we do seem to keep having the same conversation at regular intervals. How we fix this I really haven't a clue. Clearly Vegas isn't going to change dramatically, there's too much history by now and as Glenn has explained a lot of work would be required.
Everything anyone needs to know about Vegas is in the manual but that's all well and good if you already know an aweful lot of the background theory and the language.

When I look at what Vegas can do I see:

1) Non Linear Editing
2) 2.5D compositing
3) Audio Multitracking Mixing.

To the best of my knowledge no other single application exists that covers such a broad scope. Sure anyone of them in greater depth but not the scope.

There is one that covers 1) and 2) for around $50K and the recommendation is a 4 week or so intense training course.


Bob.

Paul,

Placing AAV on the Video Buss for a nested Veg does not work. The veg no longer has transparency if you need it - or at least it has but has the same effect as when you place it on a top track event, it ruins any lower track. Fine if you do not require full transparency for the nested veg.

As far as I am concerned that trick only works if you use it for the final render.

Willem.

Paul, the problem with "rendering everything out at studio levels (16-235)" is that Vegas will have to make a guess/assumption about the colorspace of the source footage. I don't see how it can do this, since users are inputting video shot at studio levels, computer levels, and more, often with undershoot and overshoot.

Now that I understand this stuff better, I actually see it as an advantage that the Vegas preview window uses computer levels, because I can see differences in levels of footage between 0-16 and 235-255. For the final studio levels preview I look at my secondary monitor. In a way this is more "pro" than if you're just presented with clipped whites and black in a studio levels view, especially if you're inputing footage at computer levels (e.g. dSLRs). But I'd love to see a prominent toggle next to the preview window, to preview at either studio or computer levels. It's rubbish to have to add an fx to do that and then remember to take it off before render.

I want to keep my blacks = 0 for compositing in my projects but when I render out select profile sample 4:2:2 = 601 or RGB.

"My mistake was not to really get to understand Vegas fully for years and even now I'm still plumbing new things and ways to use it.".. farss
Not your fault Bob and in my opinion, Vegas should not be this way. Should be in line with existing methods.

"As far as I am concerned that trick only works if you use it for the final render".. Willem
Agreed. Im only using it on the *final* render, thats the only place its needed in this case.

"I actually see it as an advantage that the Vegas preview window uses computer levels, because I can see differences in levels of footage between 0-16 and 235-255".. Nick Hope
Yes good point, i see that too.

Well, at least my opening first post saying 'its probably simply knowing what to do' was off the mark! Yes i know the work arounds now thanks to everyone on this thread, thats all very clear now. BUT - i dont like the solution!

Paul.

"I want to keep my blacks = 0 for compositing in my projects but when I render out select profile sample 4:2:2 = 601 or RGB. " -Rory

sounds like you're rendering to some YUV (016-235) format*... use an RGB (000-255) format instead.

*if you use a YUV codec, when u bring the file into Vegas (or any NLE/compositor), it will want black to be 016, not 000... but with Vegas there are numerous exceptions; Glenn Chan documented some of these adventures here
http://www.glennchan.info/articles/articles.html

Paul, the problem with "rendering everything out at studio levels (16-235)" is that Vegas will have to make a guess/assumption about the colorspace of the source footage. I don't see how it can do this, since users are inputting video shot at studio levels, computer levels, and more, often with undershoot and overshoot.
It can by figuring out what codec the footage is using. (If you get properties on a clip, it will tell you what codec is being used.) This is how every other NLE on the market works.

Almost all cameras will record illegal values / superwhites. However, the proper behaviour is for these values to be clipped... unless the user decides to bring these values into legal range. The whole issue is a mess and there is no simple solution... all NLEs have this problem. What the camera manufacturers should do in the first place is to avoid shooting superwhites... it causes more problems than it solves.

But I'd love to see a prominent toggle next to the preview window, to preview at either studio or computer levels. It's rubbish to have to add an fx to do that and then remember to take it off before render.
I think that Vegas should default to whatever the standard is. And it should default to not showing illegal values. This would make Vegas much easier to use as people will see a "correct" image right off the bat. I don't think users should be able to dive into Vegas and get good results without having to know which codecs expect studio RGB and which codecs expect computer RGB. (The real answer is to look a table with all this information; such a table DOES NOT EXIST in the Vegas manual.)

Maybe you could allow people to look at an incorrect preview to look at the superwhites and the superblacks... but this feature may be more dangerous than helpful. (No broadcast monitor by the way has such a feature... unless you want to be the crazy person that mis-calibrates a CRT.) Kind of like the half-moon icon that lets you preview without any FX. Maybe if you had to click-and-hold a button then you could see illegal levels... and once you let go of the button you couldn't see them anymore.

Maybe if you had to click-and-hold a button then you could see illegal levels... and once you let go of the button you couldn't see them anymore.Great idea Glenn!

G