Doesn't work properly for me.

Full level mode clips the shadows/highlights and they can't be recovered in that mode (by changing gain/lift). Here is a sample directly from my camera:

https://mega.nz/file/SkskWCpD#pQ0bMf1eTAxS6rAwij0dudPl_Z_uYrQrVdvZfUtoW3A

32 bit floating (gain 1.00):

8 bit full (gain 0.93). Top left still clipped. Highlights cannot be recovered:

Works for me with my gopro 8, iphone 11, and jpgs!

@jim-helpert

As mentioned in the other discussion, if using the 8 bit full level option leads to clipped levels then there's something wrong with your source clip's meta data. In this case the source clip's levels already exceeds the limited levels but either has no appropriate meta data or wrong meta data.

Edit:
Just checked your source clip. It's what I said above. This is a Y'CbCr video with no color range meta data. Such a Y'CbCr clip should not exceed the standard levels. Vegas Pro 18 processes this clip correctly but it's up to you to correct the false/missing meta data which then would restore the highlights (which you can do via the file properties window).

This is your source video inside an 8 bit full level project, meta data set correctly and a curve fx applied:

@Marco. "applies a studio levels to computer levels transformation"

Do you mean that the "levels" fx will be applied to the clip or that the changes will be applied "magically" such that we have no control over them after the fact?

iPhone photos vegas is still ignoring the ICC flag. (colors will be just a tad off) (workaround to save .jpg as .png and then import to vegas.

But not the biggest issue. Still loving the new fix.

https://www.vegascreativesoftware.info/us/forum/vegas-changing-colors-of-my-photos-with-levels-fix--120727/

"Do you mean that the "levels" fx will be applied to the clip or that the changes will be applied "magically" such that we have no control over them after the fact?"

In VP18 it works same way as in Avid, Premiere, HitFilm and other NLE. There's no FX plug-in applied but the input data is transformed before it is passed into the project pipeline. You can still control whether this transformation should be applied or not via the clip properties settings. Or you could set the project property to the legacy 8 bit mode if desired. It's an option.

@LongIslander

This new option is for the luma range only, it does not touch the color space specs.

I feel like the lonely foot soldier trapped for decades on a jungle island, and still fighting the same battles against invisible adversaries. Is someone now telling me the war is over? I'm not sure I know how to live that way...

But it's what everyone wants, to be "like" Premiere. We have gone from from needing to learn the model from the ground-up, to needing to learn when deus ex machina is being cruelly tricked by the Law of GIGO. And there will be many traps. Progress indeed makes strange turns along the way...

I feel like the lonely foot soldier trapped for decades on a jungle island, and still fighting the same battles against invisible adversaries. Is someone now telling me the war is over? I'm not sure I know how to live that way...

But it's what everyone wants to be "like" Premiere. We have gone from from needing to learn the model from the ground-up, to needing to learn when deus ex machina it is making a mistake by the Law of GIGO. And there will be many. Progress indeed makes strange turns along the way...

@Musicvid I was waiting for your comment 😁.   Gonna make this software so much easier to use for newbies and keep the new threads down to a minimum. 👍. Less workflow. Im loving it already.

We'll see about the new threads. As a compulsive metadata peeker, I foresee many opportunities...

I think soon at least some amongst us will see how confusing such a semi-auto level adaption could be. Jim's first experience already proofed that. And this is because of either missing meta data or the false use of meta data. We've already been there many times.

This might take a while to understand, but once you get the idea, you will know how to deal with this.

I think soon at least some amongst us will see how confusing such a semi-auto level adaption could be. Jim's first experience already proofed that. And this is because of either missing meta data or the false use of meta data. We've already been there many times.

The two most obvious poster children for this approach are already well known:

1. The ubiquitous VUI flag, another Apple contrivance that has not been adopted by MPEG-LA, to my knowledge. yuv420p is YUV Limited Range, while yuvj420p is Full Range YUV. "Some" phones write them, and "some" software recognizes them. If that is the only metadata that distinguishes levels in a particular file, the auto correction applied may be wrong, and quite frequently is.
2. The equally notorious "16-255 YUV" produced by many point-and-shoot models, for which there is no metadata flag or stock preset. In this case, one must override whatever correction is being applied, and lower the whites, but not raise the blacks. Best solution I have found is a custom LUT, such as the one I wrote to fix @john_dennis material.

• https://www.vegascreativesoftware.info/us/forum/does-your-camera-shoot-16-255-try-this-free-3d-lut--121652/

I predict our gurus will spend almost as much time explaining this as we did trying to demystify everything that has led up to it.

https://www.vegascreativesoftware.info/us/forum/pc-to-tv-levels-a-comedy-of-errors--107325/

This is great news and should reduce forum traffic significantly as most users won't have to think about what levels their footage is anymore. At long, long last!

I had suggested the developers create a hybrid flag for 16-255 (or a custom one) but until then people shooting with superwhites have to be aware of it (and change to full levels and then bring down blacks) or keep details out of the brightest highlights.

Anyone who doesn't like this can revert to 8-bit video levels and enjoy the standard workarounds we came to know and love.

@jim-helpert

Edit:
Just checked your source clip. It's what I said above. This is a Y'CbCr video with no color range meta data. Such a Y'CbCr clip should not exceed the standard levels. Vegas Pro 18 processes this clip correctly but it's up to you to correct the false/missing meta data which then would restore the highlights (which you can do via the file properties window).

This is your source video inside an 8 bit full level project, meta data set correctly and a curve fx applied:

Thanks. Manually correcting the color range to full for all clips worked.

I think it would be better if Vegas 18 assumed full range instead of limited when meta data is not set to avoid lost highlights/shadows.

I think it would be better if Vegas 18 assumed full range instead of limited when meta data is not set to avoid lost highlights/shadows.

Agreed. Since 2011.

The failsafe default is qualitatively better than the riskier one at a blind intersection, I theorized then. Do you always run the stop sign or always put on the brakes? Time will tell.

@jim-helpert

I think it would be better if Vegas 18 assumed full range instead of limited when meta data is not set to avoid lost highlights/shadows.

I would like to see this implemented too.

Just so everyone can see the options we are talking about for unflagged source, here are the two "worst case" scenarios (the one on the left uses "failsafe" levels):

Okay so help me out guys, When i am using Sony XDCAM HD422 mxf files to edit for television. And I start rendering the final project to the same codec (Sony HD422), is there something I need to do to get the old fasion good result?

Nope.

But, just in case, I'd render 2-3 sec. region first, to see if everything's as it should. :)

Nope.

But, just in case, I'd render 2-3 sec. region first, to see if everything's as it should. :)

Thanks! I will test this.