"Fades go to 0, not 0 IRE."

Fades need compositing math which again strongly needs the value zero to create total transparency. Any fade on any digital system works exactly same way. But this isn't the black you mean. The zero black you see and use then is another step behind and it's also needed if a system is build like Vegas.

The moment you modify the level processing you start breaking the system. Vegas does not need modified level processing but it would benefit from giving some other features (e.g. internal preview and generated media) more options which are adapted to the given level processing.

Around in circles Marco, been here.

Paul.

Yes.

Did I already click the like-button for the Easy Preview Button? Oh, yes I did. :D

PPro, Avid, FCP and Edius simply have none of these issues.
Exactly!!!

It's a much more sensible way of doing things. And honestly for Vegas to fix things it's kind of trivial. The problem is extremely straight-forward... there is only one right way of doing things... the only possible issue is rounding error. Because Vegas laid the groundwork for 32-bit processing, they simply need to make a few tweaks to how 32-bit is implemented. Anybody who cares about rounding error can simply switch to 32-bit processing.

If users take their case to SCS they need to define correctly what they want fixed
For the love of god, please ask for Vegas to handle levels automatically... in a manner similar to every other NLE on the market.

This manual wrangling of levels is madness. Please do not ask for more of it. If you think it is a good idea, you need to try iMovie or Windows Movie Maker or any other NLE... like paul_w says, they simply have none of these issues!

Yes, like Bob correctly said the way PPro (I tested with CS6) and Vegas Pro decodes and processes video in regard of levels is EXACTLY same.
They are not the same.

Drop a HDV clip into a Vegas timeline.

Change the project to 32-bit floating point. Toggle between Full range and the other setting. Notice how the HDV clip decodes to either computer RGB or studio RGB... it depends on the project settings.

"Btw, the feature you want sort of exists already. You can use the Windows Secondary Display as a preview device and check the "studio RGB" box in its settings."

Yes! Absolutely! Precisely! That and Only That! Nothing Else! And Nothing More!! That's all I want! (Besides Batman's Maserati)!!

At the inevitable risk of repeating myself, I would be really pleased with a WYSIWYG preview option (such as we already have in the external preview), without adding any filters to the bus pipeline!

I personally would find automatic source manipulation confusing and distracting because I already know what to expect and what to look for. I actually enjoy working with this stuff. Others probably don't care about any of that; just how it will look in a player.

Put your JPEG alongside some DSLR footage. "Automatic leveling" sees the "RGB24" still and internally converts to Studio RGB. So far, so good. Now, it looks at DSLR, which is always flagged 601 (Canon) or 709 (Nikon). "Aha, no correction needed," it says, so it does nothing. But wait. No DSLR actually shoots 601/709 luminance levels. In fact, most of them shoot full 0-255!

So now we have an RGB still altered to 16-235 right next to a YUV clip that is really 0-255. How automatic is that?? Or should I say how confusing is that??

I'm picking up on a bit of urban myth surrounding what "other editors" (usually unnamed) do. In fact, they can apply a stock shift or do nothing, based on the source flags, nothing else I've been shown. Jerry just confirmed this in a round of private emails. When the source levels do not square with the source flags, which is most of the time, the result is worse than doing nothing imo.

Premiere does not scan actual shooting levels, by anything I've been shown. If it could it would still be wrong. (Remember that overcast day? It's an important metaphor). Source luminance levels rarely square with their source flags these days. So getting "some" of it right just isn't helpful to me. That's what I meant by "Until all camcorders and videographers get it right . . ."

Give me a WYSIWG preview and I'll do the rest myself. But don't mess with my internal levels. I really do understand exactly what I'm asking for. I'm asking for an internal preview switch that works the same as the external preview switch. Nothing else and nothing more.

Did I "know" this thread would get derailed over collateral issues? Given our collective history, I honestly don't know how it couldn't. Grazie probably summed it up best.
"Arrrhhgg!! . . . . "

Any more votes on the original question?
Tally so far:
+ 11
- 0
Other 1

I don't think you will get any -1's. Why would anyone suggest not having a new button? What objection could there be? If a new button was presented and someone didn't want it, they would simply not click it?

Would be better to ask "Would this feature be useful for you and likely to use it".
That would get my -1. Because i don't need it. External monitors do this anyway. Which is the way i work.

Paul.

"Would be better to ask "Would this feature be useful for you and likely to use it".

+1
Paul, Despite appearances resulting from my advocacy in this thread, I agree with you 100%. I said in the other thread I "might" have use for such a feature at the very end of my workflow. However, I suspect there are many other good visual-spatial editors on the Pro forum who would put this to work right away, and use it practically full time.

I like sitting on my living room couch with my laptop, so attaching a second monitor is impractical. Using my primary monitor as a secondary is unpleasant, for reasons we all should be familiar with (lower preview frame rate, no realtime access to the timeline). Loop-and-tweak is easily my favorite working mode.

I work a lot with Vegas Movie Studio users, who don't have scopes (nor usually the wherewithal to use them). I have worked diligently with younger, visually creative editors (wwjd and ice come to mind) to help them get their creative content from Vegas to the internet in the best shape possible. That's why we did the tutorial, based on the way the preview works now. For the majority of these creative editors, player emulation is very important, and internal mixed-source leveling not as much. They'll make that the way they want it, and who's a techie like me to judge? The reason for my revitalized advocacy now was inspired by Grazie's ember-stirring inquiry. If that amounts to tunnel vision on my part, I plead guilty as charged. As a step up the learning curve, this would be a valuable tool for the people I just mentioned (and possibly for Sony's marketing also) . Much more useful than the "Make Movie" option in VMS, over which I've already offended a couple of soccer moms. It is possible to improve on one part of the workflow without either dumbing down or overcomplicating the rest of it.

As you pointed out above, levels will have the potential to spill over the 709 "cliff'" and clip in the player (purposefully), unless Vegas applies a Studio RGB filter to everything, regardless of how it is flagged (or not flagged). Or we can level on the timeline, source-by-source, as I enjoy doing. People needing these hard-clamped levels for broadcast compliance (a different but parallel situation) should probably just follow the tutorial (edit to suit, then slap a Studio RGB or Broadcast levels filter on the output), with the added step of placing a 16-16-16 safety track at the bottom. I have customized project "templates" that do just that. That is the only approach I can conjure up that is truly "WYSIWYG and Failsafe."

Personally, I prefer to see the full range of available values for each source in my preview first, and then player emulation second. Thanks for sharing your thoughts.

>I like sitting on my living room couch with my laptop, so attaching a second monitor is impractical.

+1 for this reason (which I wasn't considering).

/jerry

+1 for me. I hate to bring this down to the lowest denomination, but I've always just accepted that what I see on the internal preview is wrong, and used a TV to correct colour/brightness. If it's so simple to correct the internal preview, why is it 'wrong' in the first place? Just a journeyman's question.

yes vote yes button

Put your JPEG alongside some DSLR footage. "Automatic leveling" sees the "RGB24" still and internally converts to Studio RGB. So far, so good. Now, it looks at DSLR, which is always flagged 601 (Canon) or 709 (Nikon). "Aha, no correction needed," it says, so it does nothing. But wait. No DSLR actually shoots 601/709 luminance levels. In fact, most of them shoot full 0-255!
Those cameras do not follow standards and are one of the odd exceptions.

There may be some programs out there that will actually make an exception for footage for those cameras and fix their levels... though I am not 100% sure about this myself as I've never worked with such footage.

So now we have an RGB still altered to 16-235 right next to a YUV clip that is really 0-255. How automatic is that?? Or should I say how confusing is that??
It's inherently confusing because the cameras do something non-standard/wrong. Now if Vegas were to preserve the DSLR's "wrongness"... that would not be confusing to me because (IMO) Vegas would be following standards.

EDIT: Apparently Canon DSLRs flag their footage as full range, so it is possible for video editing programs to correctly pick up on that and to make the appropriate levels conversion.
EDIT: related... http://prolost.com/blog/tag/hdslr?currentPage=9

I'm picking up on a bit of urban myth surrounding what "other editors" (usually unnamed) do.
It's not an urban myth. I've worked with Final Cut Pro (not X), Mistika (a little bit), After Effects (not a NLE), and the old iMovie. Those programs simply don't have these issues.

Premiere does not scan actual shooting levels, by anything I've been shown.
Why would you want to do that? A video program should assume that the footage has standard levels for its format. That would be the spirit of the standards.

player emulation
For the umpteenth time... you keep spreading the idea that Vimeo/Youtube expand studio RGB levels to computer RGB. This is not true. Here's how you prove it to yourself:
a- Render your project to MPEG2/HDV in a 8-bit project. Upload that to Youtube.
b- Render your project to Windows Media in a 8-bit project. Upload that to Youtube. This result will be different than a.
c- Render your project to MPEG2/HDV in a 32-bit project with Full Range. Upload that to Youtube. This result will be different than (a) if you have still images in the project.
(This is because Youtube expects properly encoded video files. To make a proper video file in Vegas, you need to pander to whatever the codec you are exporting to in Vegas expects. Sometimes it is studio RGB, sometimes it is computer RGB.)

Not to be combative here, but I am sick and tired of this stuff. There are endless discussions where people unintentionally spread misinformation. Why???!?!?!

Look... there is a simple solution to all of this. Just look at other NLEs. They just work. The message boards for other NLEs almost never talk about levels. Vegas should move in that direction. Yes, I feel strongly about this. This has been going on for years... originally I thought that Vegas' developers would come to their senses and eventually fix the mess. That didn't happen. Originally, I also thought that people would understand what's going on (e.g. I have an article on my website that provides all the correct answers). It has become apparent to me that this stuff is too hard even for advanced Vegas users.

Anyways... this discussion is starting to go nowhere. I am going to bow out.

GlennChan said:
"This has been going on for years... originally I thought that Vegas' developers would come to their senses and eventually fix the mess. That didn't happen. Originally, I also thought that people would understand what's going on (e.g. I have an article on my website that provides all the correct answers). It has become apparent to me that this stuff is too hard even for advanced Vegas users."

There's a couple of issues though with trying to "fix" Vegas.

1) We're now at Version 12. The potential for a lot howling from how everything would change when it was fixed is obvious.

2) Fixing it as a NLE is possible, obviously if Adobe etc can do it SCS could.
Problem I see here is Vegas isn't just a NLE, it is also a compositing application.
I would suggest there's good reasons why Apple and Adobe have separate composition application to their NLEs, trying to combine both in the one app is not a trivial task. I can see problems that revolve around the levels issue.

Bob.

You could just throw in a legacy mode to retain the old behaviour. That way old projects won't be affected.

Problem I see here is Vegas isn't just a NLE, it is also a compositing application.
I think that it would help if you dealt with the weird interaction between compositing math and studio RGB levels.
If I remember correctly, the compositing math for things like multiply/overlay assume black at 0.
If you convert everything to studio RGB, then black is at 16.

You'd have to figure out some solution to that.

And then if you want to allow users to seamlessly switch between 8-bit and 32-bit, then you'd have to figure out how to deal with 8-bit studio RGB having black at 16 while 32-bit floating point has black at ______.

I would advocate an approach where 0 always means black in the user interfaces for filters. You pick colors based on 0 being black and 1.0/255 being white. Always. This would be different than how Vegas currently does things, where 16 is either dark grey or black.
I can see how that would take extra work to convert almost every FX to handle that. (Color curves would probably need a button to map superwhites to legal range... or you'd do that in another plug-in if curves itself is completely unable to do it.)

I would suggest there's good reasons why Apple and Adobe have separate composition application to their NLEs
This is why I love Vegas... because everything is integrated into one program. Having to switch between programs is very tedious.

That's the brilliance of Vegas. You have all these programs rolled up into one. It's very good for one-man army type productions where one person is doing the rough edit, color, audio, compositing, etc.

Glenn,

1. In doing research for the video, I began surveying hundreds of makes and models of video-capable acquisition devices on the internet by 2010 sales (over 300 million), and concluded that conservatively, at least 80% do not even get it close to right. Apparently, 75% shoot 0-255 in YUV containers, 5% (mainly HDV and AVCHD) shoot 16-255, and generously 10% shoot in RGB containers (mostly Chinese toys), with 10% undetermined. This includes every maker of camcorder, hybrid, DSLR, point-and-shoot, pocket cam, and cell phone for which I could dig up sales figures. I spent a couple of weeks doing the research, cross-checking, and came away with the compelling impression that the only "odd exceptions" are the ones whose acquisition levels actually square with their source flags. You see, the days when it was either DV or HDV have long since passed.

The results of Nick Hope's poll on this very forum indicate even less conservative numbers, or 88% noncompliant levels among those responding, which included, remarkably, only one phone.
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=795690

2. Any video program that "assume[s] that the footage has standard levels for its format" and then makes blind adjustments for the user based on those standards is going to make mistakes, and lots of them. There is no magic in any other program. And no, they don't scan levels, because it doesn't work.

3. On January 28, 2011, Nick Hope pointed out to me that the levels conversion might be taking place in the system's Flash Player, and not as a result of Youtube's processing. I was of the opposite opinion, because the Quicktime 32 libs in my version (8.0c) were giving me entirely different results than his version 10. Since investigating this with a flurry of emails and files sent back and forth, I came to the conclusion that he was right. So the notion that I am uninformed, spreading misinformation, or otherwise negligent is simply incorrect. I am unwilling to change any of my posts leading up to that revelation, because many others have taken the same path to realization independently, and so there is some value to preserving the historical progression of thought. Since then, I have been misread and misquoted a couple of times, and I have no control over that. However, If you or anyone can find an instance in the last 22 months where I have said the player is not doing the conversion, I will gladly change it, because I believe now it would be incorrect. So your phrase "keep spreading the idea" is entirely incorrect and a disservice to me and the entire history of this project, including the others here who have worked so hard on it.

I'm not bowing out. My respect for you, your knowledge, and your research remains undiminished, and I refer to them often. You see, Glenn, I really try to withhold judgment. My best of the holiday season.

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=804364
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=794449
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=794449
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=768095
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=756050
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=756050
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=723735
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=706938
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=683045
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=676693

1a- It's nice that Nick Hope is trying to figure things out but there's something you need to watch out for regarding his results.

What you see in Vegas is entirely dependent on the codecs being used. For example, the Sony DV codec decodes to studio RGB levels. The Microsoft DV codec decodes to computer RGB levels. What see you see in Vegas depends on what DV codec is being used (Vegas defaults to its own DV codec, unless you are using a really old version of Vegas when the Sony DV codec didn't exist).

Similarly, HDV depends on the project settings.

If you rely on Vegas and its scopes... you will be chasing your tail.
*You should not assume that Vegas is correct.
*You really should not assume that Vegas' scopes are correct.

According to Nick Hope's thread at
www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=795690
Most/all DV/HDV cameras have 16-255 (RGB? Y'CbCr?) levels.

My objection is this: it is not strictly true. Go into Vegas' settings and make it use the Microsoft DV codec (you need to restart Vegas). You will see that DV decodes differently (to computer RGB) and that your levels are now different. Or take HDV footage and use a 32-bit floating point Vegas project with Full Range levels.

Maybe I am nitpicking... but I feel that these details and exceptions are important to note.

1b- Almost all video cameras record superwhites / illegal values above white level. (This is a dumb practice, but that's a different story.) Presumably, the camera designers expect highlight information to be clipped in post. In my book, it is "correct"/ok if you clip this information.

Any video program that "assume[s] that the footage has standard levels for its format" and then makes blind adjustments for the user based on those standards is going to make mistakes, and lots of them.
Well... they don't.

For example, in Final Cut Pro... you drop in a JPEG and a video clip. Suppose the video clip has superwhites in it. They ultimately get clipped off when you view your video on Youtube. In my book, this is correct.
If you want to preserve superwhites in FCP, you can do that too.

It just works.

-------------------------------------------------------------
The use of the words YUV and luminance

see "YUV and luminance harmful - Charles Poynton"
http://www.poynton.com/PDFs/YUV_and_luminance_harmful.pdf

This has zero relevance to Vegas users and is a nitpick, but I lean towards Charles Poynton's opinion on this one. People should stop saying YUV when they really mean Y'CbCr (I know that one of Vegas' codecs is called "Sony YUV"... this is wrong).
Similarly, there is a difference between luminance and luma.

None of this really matters though for video editors.

You see, the days when it was either DV or HDV have long since passed.
I feel old... lol.

-------------------------------------------------------------
Here's my take on things:

- Standards exist for a reason. If we don't follow them, it leads to messes like the current situation with Vegas.
For example, Vegas doesn't always display video correctly. It doesn't always transcode between formats correctly.

Youtube, Vimeo, etc. follow standards. Vegas, in my book, does not. It offends me when people suggest that Vegas is doing things correctly and other programs/parties are not (when in reality, Vegas or incorrect usage of Vegas is to blame).
When people have the misconception that Vegas is doing things correctly... it usually leads to more misconceptions.

- Yes, most DV/HDV cameras record superwhites. Arguably, this does not follow standards. (I would argue that it is a dumb practice and that the camera manufacturers screwed up.)
This does not mean that Vegas isn't messed up.

- Yes there are cameras out there that record full-range Y'CbCr (where the image spans 0-255 Y'). I have no idea what the camera designers were thinking, but it is wrong and the codecs should fix this mistake if they can reliably spot it based on flags in the footage. (I believe this is what FCP does now; I do not speak from experience.)

- I really want other people to understand that there is a better way.

I apologize in advance for being curmudgeon-ey.

The word is curmudgeonly, and I know because I've been there.
;?)

If I can take the tools as they exist at this slice in time, and create an original method or suggestion that will make it better for me and one other person, then I am gratified. To that end, I work really hard (but don't always succeed) at reserving judgment, on both the tools and their carpenters. Gustav Stickley was one of the most roundly criticized furniture makers of the last century.

That's all it is for me.

Nick has been a great friend and grounded partner, even if we do take turns tilting at windmills occasionally. It would seem that's how we learn.
Between him, me, and Jerry, we've had remarkable success at pinning down differences between codecs, players, software versions, browsers, and even video drivers.

It's easier to type YUV than Y'CbCr. Luma is gamma-centric, Luminance is not, which for us remaining mortals (and Vegas RGB), makes it easier to quantify.
Sometimes it makes more sense just to let the dime drop.
Best.

I think another problem here is that Y'=255 does not necessarily have to mean that is white, unless you have your camera setup correctly and pointed a good (read expensive) chart then you might not know what it should represent.

DSC Labs had a quizz at NAB a few years back. A series of black swatches on a board and you were invited to answer which one was "video black". That quite got me thinking.

Taking a sample of many cameras and simply noting on 'scopes where the luma values lie in itself can be very confusing, all you find out is what the camera "records" which may well not be what the camera "shoots". To the best of my knowledge there's only been one person here who has plumbed the depths of what one camera (EX1) shoots and that was Serena.

The whole "reading scopes" thing can be further confounded by Detail in the camera pushing edges right to the limit, Vegas does this as well.

In addition so far we're only talking about the luma component. B&W is attractive but most of us most of the time shoot colour and throwing how that into the pipeline seems to me an even more bewildering topic. Shooting with my EX1 in Cinegamma4 I can get it looking pretty 99.9% of the time with Vegas, I doubt it's right but it looks pretty good. On the other hand I've had several issues with colours from JPEGs going ugly between PS and Vegas. Thankfully not purple...yet :)

Bob.

Oh, and Bob,
Let us not forget the 1-bit rendering shift.
It actually shows and can be measured on some of my stepwedge tests.

OK, moving on.
More votes? The original topic can still be read at the top of this thread.
Tally to date:
+ 14
- 0
Other 1

Could you make that button detent and bump the counter by 1?

h*e*l*l, John, I couldn't even get the text skew right.

Almost all video cameras record superwhites / illegal values above white level. (This is a dumb practice, but that's a different story.) Presumably, the camera designers expect highlight information to be clipped in post. In my book, it is "correct"/ok if you clip this information.

But it's wonderful that Vegas allows us to rescue those superwhites. It's absolutely key to my workflow now. Lots of the shots in my manta ray video were transformed when I mapped 255 to 235. The highlights are still blown out, but nowhere near as much. I'd hate it if the ability to do that in Vegas was taken away. Isn't that what would happen if Vegas were to "handle levels conversions automatically"?

Nick,

+1