Vegas Pro Levels, Last and Final # 1

john_dennis wrote on 4/29/2020, 11:57 PM

I've been part of discussions about this subject for so long that I've recently begun giving one word answers when the uninitiated Vegas user becomes irate that he/she has to think about it. To atone for my sins, I decided to create the following projects that run on Vegas Pro 14 and up.  Download all projects and assets from here: 

Download Link Here:

https://drive.google.com/file/d/193FRYiw_21_WTsTz__zHKgwdrLFLowJU/view?usp=sharing


In this package are five Vegas Pro projects as follows:

  • Levels Starter - 14 Up.veg

This project contains a transparent .PSD file with vertical bars that are 
000,000,000     011,011,011     016,016,016
a transparent area that exposes 50% of the area center screen for your media to show through when placed on a track below.
235,235,235     240,240,240     255,255,255

  • Add Your Media, Render without fX.veg

This project is set up with no fX so that the user can render it to any output type and the effects on the color bars and the video will be exposed. Use the Waveform and/or Histogram to view with the Preview set to Best (Full).  

  • Computer to Studio RGB Levels fx on Output Buss

As the name suggests, the levels are adjusted by one fX that operates on all the video on the timeline.

  • Adjust Levels with Color Curves.veg

This project wrangles the generated media into Studio RGB (16-235) range with Color Curve fX on the individual clips. The included video that came from a Sony RX10IV (16-255) is brought into the Studio RGB safe range with a Color Curve on the clip. 

  • Play This in Your Player.veg

This project brings all the rendered files from the other projects together so the user can render for upload to YoutTube or do further analysis in her player.


With the correct levels for the output wrapper and codec one should see a distinct difference between 000 and 016 as well as 016 and 018. One should also see a distinct difference between 235 and 255. Less so between 234 and 235.  Like this:

You may view the last project on YouTube here:

Big Note!
Only the section with the Levels / Computer to Studio RGB filter applied and the section with Color Curves applied at the clip level will expose the differences in the blacks below 016 and the whites above 235.

Change Log:
2020-04-30 Changed the values of the color bars below 016 and above 235 to make the differences more apparent. 

Updated files to reflect color bar changes.


Added ReadMe.TXT and ReadMe.rtf to the file package.

Comments

john_dennis wrote on 4/30/2020, 12:23 AM

Oh, I'll anticipate one comment that's very true and sure to come. "Setting the levels is not color grading."

This video shows no material effect on levels for a 360 degree Rotate Hue from 3 seconds to 9 seconds.

I appreciate those who have made that distinction in the past. You know who you are.

Musicvid wrote on 4/30/2020, 3:09 AM

Our hotshot graders should stick with gamma, or at least locked curve endpoints pre- leveling (yes, that goes last), as their grading tool of choice, because of the parallel postulate that grading is also not color correcting, either.

Grading is not a windshield wiper, but a rubber band stretched between two nails, for the visually-referenced. Can't wait to try your project as a training tool, and see if it makes a dent in the armor. ITU-R colors are not a Vegas conspiracy.

wwjd wrote on 4/30/2020, 8:07 AM

I need to first admit, the way I work, I am not having a problem with levels... but I understand the "annoyance" it causes people. (I understand 0-255, and 16-235 gold ol standard, and camera 255 etc, and adding levels on tracks or master, and I use COLOR LAB instead because it is better in every way)

Maybe the question is better as "Do the render choices CHANGE which levels they finally output?" Because the render no longer matches what was seen in the preview - or is it always on the playback PLAYER itself?

I've tested about 6 of the common Windows players and most do okay, some a slight difference than others.

Also, why CAN'T it render the levels as seen in preview?

and I'm aware youtube does make a wreck of things

Musicvid wrote on 4/30/2020, 8:56 AM

@wwjd 

Stick your rendered video back on the timeline, open the histogram, and you will have your answer. Also, a rough indication of lossiness can be inferred from the relative amount of luminance "slop," especially in the shadows

wwjd wrote on 4/30/2020, 10:14 AM

Im not having the problem, so not going to bother. just thought there was a quick yes or no answer

Musicvid wrote on 4/30/2020, 10:48 AM

The quick answer is, "Sometimes."

But I am still interested in your education, not instant gratification.

Musicvid wrote on 4/30/2020, 11:00 AM

In this package are five Vegas Pro projects as follows:

Levels Starter - 14 Up.veg

This project contains a transparent .PSD file with vertical bars that are 
000,000,000     016,016,016     018,018,018
a transparent area that exposes 50% of the area center screen for your media to show through when placed on a track below.
234,234,234     235,235,235     255,255,255

Add Your Media, Render without fX.veg

This project is set up with no fX so that the user can render it to any output type and the effects on the color bars and the video will be exposed. Use the Waveform and/or Histogram to view with the Preview set to Best (Full).  
Computer to Studio RGB Levels fx on Output Buss.veg
This project adds a Computer to Studio RGB Levels filter to the Vegas Pro output buss.

Computer to Studio RGB Levels fx on Output Buss

As the name suggests, the levels are adjusted by one fX that operates on all the video on the timeline.

Adjust Levels with Color Curves.veg

This project wrangles the generated media into Studio RGB (16-235) range with Color Curve fX on the individual clips. The included video that came from a Sony RX10IV (16-255) is brought into the Studio RGB safe range with a Color Curve on the clip. 

Play This in Your Player.veg

This project brings all the rendered files from the other projects together so the user can render for upload to YoutTube or do further analysis in her player.


With the correct levels for the output wrapper and codec one should see a distinct difference between 000 and 016 as well as 016 and 018. One should also see a distinct difference between 235 and 255. Less so between 234 and 235.

I added this text to a Readme and added it to the root folder to aid me.

john_dennis wrote on 4/30/2020, 11:30 AM

@Musicvid

Good idea. I'll add the Read Me to the download files and update the link soon.

wwjd wrote on 4/30/2020, 6:21 PM

The quick answer is, "Sometimes."

But I am still interested in your education, not instant gratification.

maybe there is a list of which render codecs change levels?

Musicvid wrote on 4/30/2020, 8:10 PM

Yes, a half-dozen or more, including intermediates. And many more player metadata flags. Indeed, I undertook just such a compilation in ~2010. Except at that time, internet delivery was a mashup of Flash, MOV, WMV, AVI, and even MCI in a variety of embedded and local players. Updating those results today would be a relative tiptoe through the tulips.

So in the interest of fostering continuing ownership of one's inquiries, sans entitlements, I think @wwjd is the perfect candidate to do the testing, data collection, compilation, and presentation of updated results, indexed by actual and apparent output via encoding and/or flags, and presented in a logical style.

As an educator, this spring especially, I keep hearing a certain phrase running over and over in my head: "A mind is a terrible thing to waste." Let us know if you need help with testing protocal or quantitative best practices, and I promise you that widespread fame and recognition will be yours, on this forum.

I have the histos open all the time, so my interest is less in which, but how codecs are wrangling I/O levels. Do keep us informed of your progress and feel free to ask questions.

;?)

wwjd wrote on 5/1/2020, 7:40 AM

naw. Magix makes the product. they should test, and sort render codecs into two sections: alters levels, and as is levels. I got a day job. :)

Musicvid wrote on 5/1/2020, 8:41 AM

naw. Magix makes the product. they should test, and sort render codecs into two sections: alters levels, and as is levels. I got a day job. :)

So do they

;?)

JN- wrote on 5/1/2020, 10:35 AM

@wwjd @EricLNZ I had a read-made selection of source and rendered out clips from doing the render quality comparison tests, so I used those. Nothing very scientific here or very exact, but looking for a big change from say full range to not full range, or visa versa.

This is the table of files, some intermediates, that I used.

The source file was made from about 10 discrete sources, and I could select 3 positions on it that were full range, full range and a 16-255 position.

The result was that all of the rendered output clips matched the above "Levels". Remember, nothing exact here, but fairly obviously similar.

There was one obvious exception and that was the Xavc-L. It got squeezed, so a smaller dynamic range.

I believe that this solved an inconsistency that I had previously noticed in the Xavc-L results. Unlike the other codecs, it's quality results varied a lot depending on which column you sorted on, but the other codecs mostly were much more in line, with very little variation irrespective of which column was used for sorting.

UPDATE: See my next post. This XAVC-Long levels change appears only for UHD, not FHD

 

 

Last changed by JN- on 5/1/2020, 2:13 PM, changed a total of 3 times.

---------------------------------------------

VFR2CFR, Variable frame rate to Constant frame rate etc

Benchmarking thread

Codec Render Quality tables

---------------------------------------------

PC ... Corsair case, own build ...

CPU .. i9 9900K, iGpu UHD 630

Memory .. 32GB DDR4

Graphics card .. MSI RTX 2080 ti

Graphics driver .. latest studio

PSU .. Corsair 850i

Mboard .. Asus Z390 Code

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..32 GB DDR4, was previously 16 GB

Graphics card .. Nvidia GTX 1070

Graphics driver .. latest studio

Musicvid wrote on 5/1/2020, 10:54 AM

...assuming he is invested in the outcome.

john_dennis wrote on 5/1/2020, 11:25 AM

@JN-

I ran XAVC-L round trip with Render to New Track in the project "Add Your Media, Render without fX.veg". I would characterize what I observed in the scopes as rendering differences more than a profound levels shift with the exception of the 000 black bar. What's up with that?

wwjd wrote on 5/1/2020, 1:37 PM

@wwjd @EricLNZ I had a read-made selection of source and rendered out clips from doing the render quality comparison tests, so I used those. Nothing very scientific here or very exact, but looking for a big change from say full range to not full range, or visa versa.

This is the table of files, some intermediates, that I used.

The source file was made from about 10 discrete sources, and I could select 3 positions on it that were full range, full range and a 16-255 position.

The result was that all of the rendered output clips matched the above "Levels". Remember, nothing exact here, but fairly obviously similar.

There was one obvious exception and that was the Xavc-L. It got squeezed, so a smaller dynamic range.

I believe that this solved an inconsistency that I had previously noticed in the Xavc-L results. Unlike the other codecs, it's quality results varied a lot depending on which column you sorted on, but the other codecs mostly were much more in line, with very little variation irrespective of which column was used for sorting.

 

 

so, the S SIM column reflects the chnage in LEVELS rendered? Higher is more accurate, lower may raise or lower blacks innappropriately?

JN- wrote on 5/1/2020, 2:00 PM

@EricLNZ @Musicvid @wwjd

Here's what's happening.

As to XAVC-L and the anomaly, it doesn't happen if you use FHD (see above OP's post re: FHD being ok) and using Xavc-s or Xavc-L, but it does happens with Xavc-Long if you use UHD. The example table I posted is only UHD. All of the other samples I tested were also UHD for checking out for a levels change..

On the example I used when rendered out to Xavc-Long UHD the 2 full range points were squeezed, brought in at both ends to about 7-249, 11-240. The ~16-255 point was changed to ~16-237.

So Xavc-Long when rendering to UHD from UHD in this case doesn't squeeze in further than 16, and I'm guessing here that neither will it reduce from 255 any lower than 235.

WWJD If you look at the Xavc-L item you can see that it's position in the table would change a lot more than any other item, if you selected a different column to sort on. I knew about this when I put up the table but couldn't do anything about it. It's just different, inconsistent. That may be caused by the levels change, no other codec varied as much across all of the different columns, i.e. PSNR, MSE SSIM.

What I mean by that is that if you didn't choose the HO SSIM column to sort on, and used a different column, the results for the codecs order/position relative to each other would be broadely similar, but NOT for the Xavc-L codec, it will vary wildly in its position depending on which column you choose to sort on.

 

 

Last changed by JN- on 5/1/2020, 2:27 PM, changed a total of 6 times.

---------------------------------------------

VFR2CFR, Variable frame rate to Constant frame rate etc

Benchmarking thread

Codec Render Quality tables

---------------------------------------------

PC ... Corsair case, own build ...

CPU .. i9 9900K, iGpu UHD 630

Memory .. 32GB DDR4

Graphics card .. MSI RTX 2080 ti

Graphics driver .. latest studio

PSU .. Corsair 850i

Mboard .. Asus Z390 Code

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..32 GB DDR4, was previously 16 GB

Graphics card .. Nvidia GTX 1070

Graphics driver .. latest studio

JN- wrote on 5/1/2020, 2:22 PM

@wwjd

"so, the S SIM column reflects the change in LEVELS rendered? Higher is more accurate, lower may raise or lower blacks innappropriately?"

The SSIM columns only gives an indication of codec quality, higher is better.  But I think that the levels change in the UHD render is giving an oddball result for Xavc-long.

 

Last changed by JN- on 5/1/2020, 2:22 PM, changed a total of 1 times.

---------------------------------------------

VFR2CFR, Variable frame rate to Constant frame rate etc

Benchmarking thread

Codec Render Quality tables

---------------------------------------------

PC ... Corsair case, own build ...

CPU .. i9 9900K, iGpu UHD 630

Memory .. 32GB DDR4

Graphics card .. MSI RTX 2080 ti

Graphics driver .. latest studio

PSU .. Corsair 850i

Mboard .. Asus Z390 Code

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..32 GB DDR4, was previously 16 GB

Graphics card .. Nvidia GTX 1070

Graphics driver .. latest studio

Musicvid wrote on 5/1/2020, 2:23 PM

Thank you @JN-

Is this using an 8 bit or 32 bit project format?

JN- wrote on 5/1/2020, 2:28 PM

@Musicvid Is using an 8 bit project format. The UHD source is 10 bit, the FHD source is 8 bit.

Last changed by JN- on 5/1/2020, 2:31 PM, changed a total of 2 times.

---------------------------------------------

VFR2CFR, Variable frame rate to Constant frame rate etc

Benchmarking thread

Codec Render Quality tables

---------------------------------------------

PC ... Corsair case, own build ...

CPU .. i9 9900K, iGpu UHD 630

Memory .. 32GB DDR4

Graphics card .. MSI RTX 2080 ti

Graphics driver .. latest studio

PSU .. Corsair 850i

Mboard .. Asus Z390 Code

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..32 GB DDR4, was previously 16 GB

Graphics card .. Nvidia GTX 1070

Graphics driver .. latest studio

JN- wrote on 5/1/2020, 2:44 PM

@Musicvid I changed project properties to 32 bit pixel format, the result was the same.

---------------------------------------------

VFR2CFR, Variable frame rate to Constant frame rate etc

Benchmarking thread

Codec Render Quality tables

---------------------------------------------

PC ... Corsair case, own build ...

CPU .. i9 9900K, iGpu UHD 630

Memory .. 32GB DDR4

Graphics card .. MSI RTX 2080 ti

Graphics driver .. latest studio

PSU .. Corsair 850i

Mboard .. Asus Z390 Code

 

Laptop ... (Acer Predator G9-793-77AC)

CPU .. i7-6700HQ Skylake-H

Memory ..32 GB DDR4, was previously 16 GB

Graphics card .. Nvidia GTX 1070

Graphics driver .. latest studio

wwjd wrote on 5/1/2020, 2:50 PM

@EricLNZ @Musicvid @wwjd

Here's what's happening.

On the example I used when rendered out to Xavc-Long UHD the 2 full range points were squeezed, brought in at both ends to about 7-249, 11-240. The ~16-255 point was changed to ~16-237.

 

 

thanks for all this. Are the levels changes noted above, listed in your graph in some way? I'm not seeing it.

Marco. wrote on 5/1/2020, 3:09 PM

In the video attached you'll see a quick go-trough of how levels are mapped when a video is being rendered with Vegas Pro (8 bit project).

I used all the given render formats of Vegas and for some of them (like AVI) a small choice of common codecs. You can see the format/codec used on top of the event headers while the timeline cursor jumps from event to event (each representing a particular render cycle) each second. It starts with a linear 0-255 reference grey scale.

If any mapping other than 1:1 is to be seen in different players, it either could be caused by how the player handles a certain video file format or of how the player handles the given or missing meta data.
The proof of which system is or is not mapping 1:1 is to check for banding in a histogram view. There is no banding when viewing the clips in Vegas Pro so I assume it really is a 1:1 mapping there – with one very exception: WMV (noticeable banding there).