Straighten me out once and for all on video levels in Vegas

[bigass]

I could’ve sworn I’d achieved certainty on this in the past, but I find myself questioning my understanding of the absolute proper way to handle video levels in Vegas. I’m hoping you can follow what I say I do, and tell me if it goes off the rails somewhere in a way that’ll lead to poor results.

As I understand it, anything rendered out of Vegas should have the video content within the 16-235 ‘studio’ levels range. Levels below 16 or above 235 will be clipped. That applies regardless of what format we’re rendering to — an intermediate, a MP4, whatever. If it’s being put through Vegas’ render engine, it needs to be within those limits or risk clipping.

So, I set my Vegas scopes up to Studio RGB. I make sure every clip is between 0-100 on the waveform. When I work on NTSC captures, I see levels on the waveform that are below 100, but I tell myself that’s blacker than black, from cropping, head noise, VBI, etc., and that I need to make sure the blacks in the video are at the 0 line and the brightest highlights are at 100.

To do this, every clip is checked, and if necessary treated to a Levels plugin with Computer->Studio as a starting point, and finer adjustments if needed.

Alternately, I understand I can go the other way and ensure all material is full-range, then put a Levels plugin on the master.

When I render an intermediate with careful attention to 16-235 levels only to import it in the next project and find that it’s taking up full 0-255, I just go ahead and slap the plugin on again to bring it to 16-235. I think that’s where the doubt is creeping in. It just feels like I’ve done something wrong there.

So, what’s your take? Am I doing this right or have I shot myself in the foot along the way?

FWIW, currently on Vegas 17 and have been using Vegas since …. version 8? 9?

[poisondeathray]

1) Read up on the "Glenn Chan" articles on studio vs. computer RGB for vegas . It should be required reading for any more-than-casual user of vegas

2) The "whatever" format matters . Very important. Different formats get different treatment in vegas for import and export.



Short version:

Vegas only works in RGB internally. All YUV imported formats get converted to RGB

"Studio RGB" in vegas means Y 16-235 gets "mapped" to RGB 16-235 (or 0-255 to 0-255) .

"Computer RGB" means Y 16-235 gets "mapped" to RGB 0-255 . Not only are the "endpoints" changed, the contrast has changed (the slope of the curve)

Most YUV standard formats such as native camera formats, get "studio RGB" treatment in vegas. eg. If you used AVC and reimported AVC, it should be the same - 0-100 would be 0-100 in the waveform, because studio RGB conversion is used at every step

Almost all YUV "lossless" intermedates (e.g. lagarith in yuv mode, huffyuv in yuv mode, ut video in yuv mode...etc..) get Computer RGB treatment on import. (The exception is magicyuv with the full range box checked).



eg.

Let's say you had a (A) YUV video in AVC/MP4, it's normal range (black to white reference level is Y 16-235) ie. it's a "normal" video. You convert it (B) a lossless UT video YUV version of the same thing. It's identical in other programs

If you import (A) and (B) into vegas -
(A) would show 0-100 in the studio RGB waveform, but (B) would show a shifted curve (slope of the curve, thus contrast are different), and show levels <0 and >100. (A) is getting studio range RGB treatment , but (B) is getting computer range RGB treatment

[bigass]

Roger that, poisondeathray. The Glenn Chan stuff is what I last read, some years ago, that finally convinced me to pick a workflow and stick with it -- and at the time, I was pretty sure he was saying that this is what ought to happen -- either make all your clips conform to 0-100 on the Vegas 'studio' histogram before rendering, or make them all full RGB and put the RGB->Studio filter on the master at render time. I chose the former.

So, let's say I capture NTSC to Magicyuv (full-range not box unchecked, rec601) in Virtualdub, tweaking brightness and contrast in the proc amp section to keep all the video within range ...

I bring that into Vegas and fine-tune the levels so the video's blacks are at 0 and highlights at 100 ... still some superblacks below the 0 line. Sprinkle in noise reduction or other TLC.

I render that back out to Magicyuv and it's ready for whatever next program (Handbrake, Hybrid, etc.) to smoosh it down to h264.

Or, I render that out to AVC/MP4.

Does that all look kosher? Have I botched something or made something unnecessarily complicated? Or oversimplified something that needs more complexity?

[poisondeathray]

So, let's say I capture NTSC to Magicyuv (full-range not box unchecked, rec601) in Virtualdub, tweaking brightness and contrast in the proc amp section to keep all the video within range ...

I bring that into Vegas and fine-tune the levels so the video's blacks are at 0 and highlights at 100 ... still some superblacks below the 0 line. Sprinkle in noise reduction or other TLC.

I render that back out to Magicyuv and it's ready for whatever next program (Handbrake, Hybrid, etc.) to smoosh it down to h264.

Or, I render that out to AVC/MP4.

Does that all look kosher? Have I botched something or made something unnecessarily complicated? Or oversimplified something that needs more complexity?

If you use magicyuv in YUV mode (full range unchecked) (in vdub, and export in vegas) it will be as if you used an asset that gets computer RGB treatment. ie. On import the levels will <0,>100.

So if you adjusted levels 0-100, that will be converted to studio RGB levels. ie . RGB 16-235. If you export with magicyuv, vegas will export magicyuv as RGB in that case.

So it depends on the other program, how it converts RGB to YUV. The levels will be "wrong" in 99% of other programs, because they will be expecting computer range RGB (RGB 0-255). You'd have to use a full range conversion to YUV to get it to the proper levels. Otherwise a standard conversion would put Y at ~ 30-220 instead of 16-235.

99% Other programs "expect" computer range RGB (0-255). Vegas is in the <1% that uses studio range range

If , before you export, use a studio to computer range RGB preset, it should fix things, but all those conversions are not lossless. Each time you manipulate things , you introduce banding, rounding errors

[bigass]

Tell ya what. Here's the thing that got me uptight about 16-235 in the first place: http://web.archive.org/web/20190501094000/http://www.jazzythedog.com/testing/dnxhd/Hd-guide.aspx
I don't know how much of it is still true, but at the time, it was said that Youtube, Vimeo, and most PC players do a level expansion on playback, so if we want to ensure that it's expanding 16-235 to 0-255 and not expanding 0-255 to .... math .... then we need to ensure that what we render is 16-235.

I've printed out the Glenn Chan article and will study it at my nearest convenience. I'm glad to hear so far that I probably haven't ruined anything.

[poisondeathray]

but at the time, it was said that Youtube, Vimeo, and most PC players do a level expansion on playback, so if we want to ensure that it's expanding 16-235 to 0-255 and not expanding 0-255 to .... math .... then we need to ensure that what we render is 16-235.

This is still correct . Y 16-235 normally gets expanded to RGB 0-255 on computer playback for display purposes. ie. Computer range RGB. Black to white in RGB is 0-255

Remember, vegas works in RGB. When you have the scopes set to "studio RGB", that means "0-100" is RGB 16-235. That's studio range RGB, not computer RGB. Notice Nowhere is there YUV mentioned. Note that vegas handles different export formats, differently as well. In the earlier magicyuv export example, it exports RGB at studio range. RGB 16-235. In order to convert back to YUV, you have to tell the other program to use "full range equations" or "PC matrix" . YUV 0-255 <=> RGB 0-255. Thus the magicyuv RGB at 16-235, becomes Y at 16-235, which is "standard". It's actually not a perfect reversal, there is an offset that needs to be applied for true studio RGB reversal

Most of the operations in vegas are "fixable", with the studio to computer RGB preset or vice-versa (computer to studio RGB) . This is the most simple way of doing things, and it reverses more accurately (in case you forget the offset) . So if you're using studio RGB, just apply a studio to computer RGB preset before exporting an RGB intermediate. That's it. That will expand the RGB range from 16-235 to 0-255, which 99% of other programs know how to deal with - computer RGB

But the more times you adjust something, the more quality loss and rounding errors. If you expand and compress the range a few times, or don't "reverse" the studio /computer RGB conversion correctly, it can be slightly off - that can introduce banding, and slightly off colors - It might not make much of a difference for a VHS source. But it might be more noticable on clean HD or UHD material, eg. that might matter more if have corporate clients. e.g. their logo might be slightly off color . The point is, try to plan your workflow so you aren't going back and forth with studio to computer and computer to studio more times than you have to. If you're set on studio range RGB worfklow in vegas, it would make more sense to import magicyuv at full range (which means it gets studio RGB treatment)

If you're ever in doubt, just run some colorbars or similar patterns end to end

[bigass]

I sat down with the Glenn Chan article and chewed through it. Sounds like I'm most of the way there in terms of understanding. I'll keep it on my desk as a reference going forward.

In doing the reading on this, I see Vegas 18 did a full re-do of all this, with full-range 8-bit, smarter processing of range flags in files, etc. I'm still on 17, so I'll save a fuller understanding for later. But it sounds promising.

Thanks for your patience and attention to detail, poisondeathray.

[rgr]

Is Glenn Chan's article still valid on Vegas 18 or does this version already correctly interpret levels?
I'll be:
1. Import files from the camera and process in Vegas 18.
2. Exported to VirtualDub with UT 4: 2: 0 RGBA codec (to avoid RGB-> YUV conversion as Vegas works internally in RGB).
3. Finally save in H.264 YUV using VirtualDub (or maybe it's better to save in RGB).

[poisondeathray]

Is Glenn Chan's article still valid on Vegas 18 or does this version already correctly interpret levels?
I'll be:
1. Import files from the camera and process in Vegas 18.
2. Exported to VirtualDub with UT 4: 2: 0 RGBA codec (to avoid RGB-> YUV conversion as Vegas works internally in RGB).
3. Finally save in H.264 YUV using VirtualDub (or maybe it's better to save in RGB).

UT 4:2:0 is YV12 , not RGB(A)

If you use the "8 bit full range" settings in vegas 18, it acts like computer RGB for native camera formats. The "legacy" setting acts like studio RGB for native camera formats.

You can use either, and still have studio/computer RGB presets to adjust

Do some short tests for your intended workflow, eg. test some colorbars end to end if you want to be sure

You can use voukoder to render out of vegas; no need for vdub or intermediates

[rgr]

Sorry, it should be:
2. I'm exporting to Virtualdub with UT RGB (to avoid RGB-> YUV conversion as Vegas and Virtualdub work internally in RGB).

(I render in Virtualdub because I need to use its filters. I only use Vegas for editing.)

The source footage is from the YI camera:
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
mdhd_Duration : 221332
Codec configuration box : avcC

[smartel]

if you filter inside virtualdub i suggest JPSDR VirtualDub's filters

https://github.com/jpsdr/Filtres_JPSDR/releases/tag/20220222

with RGBconvert for first filter for RGBA32 (add the filters you choose)
and RGBconvert again at the end for YUY2 (YUYV) output
and use the cineform codec (10 bit codec) to export

You won't have any Levels AND Banding issues in Vegas because the codec is in 10 bits

I often use VD with AutoYUY2 too ..