Video Levels (Vegas vs. Premiere)


royfphoto wrote on 9/14/2013, 4:59 AM
Ok, for years I have faithfully used the scopes and secondary monitor set to 16-235. Ready to try the "edit in 0-255 then add levels approach". Does it add considerably to render times? Best applied by the button on top of Video Preview window?
Marc S wrote on 9/14/2013, 12:15 PM
royfphoto: Are you shooting with a camera that records 0-255 like a Canon DSLR? If not you will have to stretch out your video levels to compensate. Not a good idea in my opinion.
musicvid10 wrote on 9/14/2013, 1:06 PM
Ready to try the "edit in 0-255 then add levels approach".
It isn't the ideal approach if you would first have to expand timeline levels to 0-255, and then clamp them later. Some math is involved in that case if you wish to keep levels filters from negating. That's about the only drawback to my method.

Does it add considerably to render times?
Assuming there are other filters / fx already in the project, it's not a lot more time.

"Best applied by the button on top of Video Preview window? "
Yes, and as the very last item in the chain.

Let us know your impressions after doing it the "other way" for so long.
Laurence wrote on 9/14/2013, 1:26 PM
For a long time I thought my D5100 was shooting in 0-255 because that's how it showed up in Vegas. It wasn't until I saw a difference in levels pre and post ProDad Mercalli and tracked down the problem to how Vegas was reading levels that I realized that the Nikon was actually doing proper 16-235 levels and that Vegas was stretching them. There was a big discussion of this related to Mercalli a while back.

How do I know for sure? Simple. MOV clips from either my Nikon D5100 or Panasonic GH3 import onto a Vegas timeline at 0-255. They also play back from VLC at 0-255. They play back from WMP at 16-235 and import into Premier or Photoshop at 16-235 as well. The culprit is VFW which programs like Vegas, VLC and VirtualDub are using.

Certain codecs which will play back with both VFW and Directshow engines have different level ranges depending upon which of these engines is used.

My next question was when there was a difference, which one was correct, the VFW or Directshow levels. To test this I tried some over exposed footage. If the Directshow reading was correct, overexposed footage would have some whites between 235 and 255 which would be clipped in a VFW program like Vegas but salvageable in a Directshow program like Premiere. Since I didn't have Premiere I used Photoshop which reads video with the same Directshow engine. Sure enough, Vegas was clipping whites that Photoshop could salvage.

I may well be alone in this, but I am as certain I am correct now as I was when I was explaining this in the Mercalli threads. VFW stretches the levels of certain codecs. Not all, just some. Levels are stretched on MOVs from my Nikon D5100 and Panasonic GH3. AVCHD from my GH3 looks the same with both VFW and DirectShow. That is why I use AVCHD from this camera with Vegas even though the bitrate is lower and the audio is data compressed.

It's not just MOV formats either. GoPro video is also level stretched. I get around this by running it through ProDAD ProDrenalin which like Mercalli writes it's processed footage in a format that looks the same through either VFW or Directshow engines. There is absolutely no situation I have yet run into where the GoPro footage doesn't benefit from ProDrenalin's combination of stabilizing and defisheying anyway so this doesn't really bother me.

When you run into a video format that has stretched level ranges, it's easy enough to fix. You just put in a cRGB to sRGB color correction filter. There are two issues with this that bother me however. One is that you lose some data in over or under exposed areas that is just clipped when VFW stretches the levels. On a Directshow based program like Photoshop, some of these are salvageable.

The other problem I have is that a cRGB to sRGB correction introduces very subtle banding issues unless you set your pixel format to 32 bits. 32 bits takes orders of magnitude longer to render though, so I would rather not have to always use it.

Like I was saying, on the Mercalli thread, there was a lot of disagreement about whether or not my assessment of the way Vegas and VFW handles levels, but I am absolutely certain that I am correct. I have looked at it every which way and done oodles of experiments which confirm it. Believe me, I don't take expressing such a major limitation with software that I use and love lightly. Ask me about religion or politics or whether the US should do military strikes on Syria and I will tell you that I am not 100% positive of my positions. But if the subject is levels in Directshow and VFW programs like Sony Vegas and I can give you an answer with absolute certainty. Yes, Vegas stretches the levels with certain common video formats. It stretches the levels on these formats because that's how VFW handles them.
set wrote on 9/14/2013, 7:06 PM
Hi Laurence, thanks for your insight!
That's good to know what is happening 'behind the user-interface'.
Sometimes, seriously, I thought that there are wizard or whatever conversion things in Premiere as well and I think Vegas can see the media 'as it is', and thought Nikon is shooting 0-255.

When I read this, I remember the article of how Mac handles AVCHD codec, and a lot of times, DUE TO THIS, AVCHD was BLAMED as Poor Codec!
Very similar issue :

Instead of Level, I put Curve with little Knee adjustment alike to keep it contrast but still under safe zone. I also make special track for Nikon only when I combine them with HDV / AVCHD materials.
NEX-VG20 & D5100 combination.
D800 OpenCL render test - add color curve adjustment (build 714 bad rendering issue when using CPU)

I think that's the only solution we can think about right now.
farss wrote on 9/14/2013, 9:00 PM
I doubt we'll ever see this being fixed by SCS with the 8 bit pipeline if for no reason other than it'd cause major grief with old projects.

What SCS could do, that'd have no affect on existing projects, is enhance the presets at least. "Black" and "White" could have a name change to "Super Black" and "Super White" and legal black and white become "Black" and "White".

Grazie wrote on 9/15/2013, 12:03 AM
I've been reading this crucially important thread and have been quietly thinking the following. Would this assist? Presently, we have VP tell us when Project should match Media being imported. How about VP tell us what Level the Media being imported is and then we'd know and can make adjustments.


VidMus wrote on 9/15/2013, 12:50 AM
" How about VP tell us what Level the Media being imported is and then we'd know and can make adjustments."

Considering parts of the above discussion, how do we know if what Vegas tells us is accurate?

Grazie wrote on 9/15/2013, 1:03 AM
Wouldn't that now be for SONY to confirm or deny?There needs to be some closure on this. Or shall we all keep spinning around and around? I'm for the former. My suggestion is to move towards, as I say, closure.


musicvid10 wrote on 9/15/2013, 9:08 AM
AFAIK, the only AVC/h264 implementation that uses VFW framework is x264vfw. It's in an antiquated AVI wrapper that does not natively support vbr audio and uses a hack for basic b-frame support, not supporting b-pyramid at all afaik.

In a typical Windows system, AVC/MP4/MOV "might" open with Quicktime, ffmpeg, DirectShow, libav, flash, or something else depending on the player, and Quicktime or Sony mp4 in Vegas for editing. Note that decoding for playback of transport streams and full inflation for editing are two completely separate decoding functions. Video drivers and settings, in some cases (Nvidia), can play an insidious role as well, because they can alter DirectShow player levels, but not ffmpeg, for instance.

The fact that different libraries "can" open the same file with different display levels is usually a result of what flags they are reading / interpreting in the file. No library actually scans the file, and such results would be even more unreliable (an overcast day, for instance).

If Laurence will upload like AVCHD and MOV samples from the GH3, also which libraries are giving which results on his system, we can try them with various players and editing library versions on our own machines and help determine what they truly are. Then "possibly" we can dig into the file headers with a utility and determine why this is happening.
VidMus wrote on 9/15/2013, 9:53 AM
As far as Vegas is concerned if I go to Media Generators and select 'White Porches' and put it on the timeline it will be from 16 to 235 on the waveform monitor with the setting of 'Studio RGB' (16 to 235) checked. Parts of it of course will be in between those.

That waveform monitor setting simply tells it to display 16 at 0% IRE and 235 at 100% IRE. Anything above or below is illegal. Place the 'PLUGE and Porches' on the timeline and you will see that the bright part is 235 but the lowest part of the PLUGE is a little below the line. It is supposed to be.

The preview should not show the black properly however if you use a second display for the video and have the setting to convert from sRGB to cRGB then it will display properly. Computer monitors are not designed for sRGB and that is why the incorrect view on the preview.

One should ALWAYS use a second monitor for NLE work!!!

With the above waveform settings you can then tell what your videos are.

Works fine with my Sony cameras.

With my television experience over the years I very much prefer the waveform monitor over the histogram.
essami wrote on 9/15/2013, 11:38 AM
I've advocated for this to be changed in Vegas for years now. Just looking at this thread and similar ones popping up all the time tells me it still creates loads of confusion. I switched from Vegas to Premiere recently and this is one of the best things in it. No need to mess with the levels and question if you're seeing what you'll be outputting, simple and fast. LOVE IT!
marts wrote on 9/15/2013, 1:51 PM
"Computer monitors are not designed for sRGB and that is why the incorrect view on the preview."

Hopefully the users will not get confused with the sRGB term used here for "Studio RGB", as this acronym is commonly used in computing where it stands for "standard RGB".
All computer monitors are designed for sRGB (for "standard RGB" not the "studio RGB"):
NormanPCN wrote on 9/15/2013, 10:03 PM
Yes that always make me do a double take since I come from the photography world where we deal with many defined standardized color spaces. sRGB, Adobe RGB, ProPhoto RGB, etc.

Studio RGB is not actually a color space. Just a designation of 16-235 numeric range in 8-bit format.

farss wrote on 9/16/2013, 6:45 AM
Grazie said:
[I]"Would this assist? Presently, we have VP tell us when Project should match Media being imported. How about VP tell us what Level the Media being imported is and then we'd know and can make adjustments."[/I]

I like this idea although maybe have it as another parameter in the Media Pool?
That way if we're mixing different media types in the one project....

JasonATL wrote on 9/16/2013, 9:51 AM
I was "bitten" by this last night on a project that I needed to turn around quickly.

I'm migrating to Premiere Pro. I had been color grading a project in Resolve and was using PPro to render the different delivered formats (for film festival submissions): HD for Vimeo, a freakishly small (size and bitrate) video for, and an NTSC DVD. The lackluster performance of Vegas on this front had me using PPro and Media Encoder.

The "bitten" part occurred when I output a DNxHD 10-bit 4:2:2 file from Resolve. At video levels, it imports into Vegas fine and all levels are correct (read: legal). But, PPro assumed illegal levels from this file and squeezed the range of the video. Back to Resolve to render out a full range (not video levels) version that PPro then adjusted so that (super) black is legal black (something I would have had to do manually in Vegas - but I would have known to do it by either knowing what file I created or looking at the scopes).

I never had a problem with the way Vegas handled it. I have to admit that I actually liked that it didn't do anything heavy-handed to the incoming video automatically. Sure, I had to be careful and set the levels properly myself. But, that is what a professional should do. A carpenter knows that 2x4 dimensional lumber is not 2" by 4". It is annoying the PPro tries to step in front of a pro to adjust the levels of the file (especially without scanning the file first).

Now, if Vegas would just scale and encode low bitrate video with good results (oh, and not crash), I'd stick with Vegas. Alas...
musicvid10 wrote on 9/16/2013, 10:19 AM
"But, PPro assumed illegal levels from this file and squeezed the range of the video."
In DNxHD, you can set the decoder flag for either "RGB" or "709." This presumably tells Premier to set levels preemptively, or leave them alone. 709 Is the usual setting.

"Now, if Vegas would just scale and encode low bitrate video with good results"
Handbrake is especially robust at scaling and encoding in lower bitrates and resolutions, and accepts DNxHD (even10 bit) as a source. Output is of course, 8 bit 4:2:0 x264, but libwscale in Handbrake is extremely good at minimizing banding. Something to consider.
JasonATL wrote on 9/16/2013, 3:02 PM
musicvid10 - Thank you. So, it seems like Resolve might not be setting the Rec 709 flag? Otherwise, PPro would have known it was video levels?

Yes, I have used the Vegas->Handbrake solution for a few years (or seems like it) now, thanks to all the good work of those of you who put the workflow together.

However, it is hard to justify that workflow when PPro/Media Encoder offer such a nice solution. I "export" (aka "Render" in Vegas parlance) the same project from PPro under all the settings I want, which it hands of to Media Endoder. The output is beautiful. I even took its DVD renders straight into DVDA 6 to make a DVD (since I needed it quickly and I knew DVDA). DVDA didn't have to rerender anything.

Had I used Vegas->Handbrake, it could have been done and, as you point out, Handbrake's low bitrate output is good. But it would have added another intermediate render in this case (I had some editing to do after Resolve).
musicvid10 wrote on 9/16/2013, 8:32 PM
I assume Resolve will expose the internal DNxHD settings?
If Premiere doesn't honor the flag, that seems unusual.
A second intermediate from Premiere to Handbrake won't lose quality, but of course it will take more time.

markymarkNY wrote on 1/27/2014, 1:12 PM
Not quite sure I'm getting all of this levels stuff. I just got a GH3 but haven't gotten to the point yet of editing video. I have been using Vegas for years on other projects but now it seems like I may have an issue?

If I understand correctly, when I edit the GH3 mov files directly in Vegas, it will end up clipping away the extreme black and white? What if I first import the .mov files directly into Davinci Resolve for color correction then export as one of the Sony MXF intermediates for work in Vegas, would that solve the problem? The imported clips would have the colors adjusted accordingly by Resolve, then I can trim with Vegas and destabilize with Mercalli prior to delivery.

Is this a suitable workflow or am I missing something?

musicvid10 wrote on 1/27/2014, 1:56 PM
I'm sure you can adjust the luminance in Resolve instead of Vegas if you wish.
Marc S wrote on 1/27/2014, 9:16 PM

Best thing to do is bring it into Vegas and take a look at your waveform monitor. Make the the scope settings have 7.5 IRE (unchecked) and studio RGB (checked). If your blacks fall below 0 IRE than you have the issue. Just adjust using the sony levels effect. There is a preset that's listed as "computer RGB to Studio RGB". This will get you in the ballpark but I would still try to adjust to eye using a calibrated monitor (or something in the ballpark).