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.

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

@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

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

The quick answer is, "Sometimes."

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

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.

@Musicvid

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

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?

Do any render codecs change levels?

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.

;?)

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. :)

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

;?)

@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

...assuming he is invested in the outcome.

@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 @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?

@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.

@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.

Thank you @JN-

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

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

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

@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.