If I put the Levels effect after Channel Blend, 8-bit scope looks identical to 32-bit. But if I put Levels before Channel Blend, 8-bit scope looks wonky.

I'll try 8-bit now too, but so far the most consistent result is with Resolve rendered QuickTime Uncompressed YUV with levels set to Full. Not identical to the camera footage, but close enough.

By levels what are you doing? Shouldn't manual levels fixes (e.g. studio to computer RGB, computer to studio) should be last in the chain or channel blend will partially undo them?

For reference, how 8-bit full works: https://www.vegascreativesoftware.info/us/forum/vp18-notes-on-the-8-bit-full-level-option--122749/?page=1

I think you are overthinking identical- use your scopes for comparisons. For what purpose are you rendering uncompressed YUV? Compression is normal for delivering video. You can use intermediate formats like ProRes for sending to compositing software.

Really though this camera is only capable of pretty compromised 8-bit footage so just putting it in a bigger bucket isn't going to make the quality any better.

That's what I'm doing. Channel Blend (601 -> 709) then Levels (Studio RGB to Computer RGB). In 32-bit the order didn't matter, but in 8-bit putting Levels last gives better results.

I got my PhD in over-thinking so no arguments there! But at least in audio, it is better to compress something twice, than three times. Here, the camera is compressing, Vegas (if not rendered uncompressed) is compressing, and YouTube is compressing. So making the second stage (i.e. Vegas) uncompressed should give noticeably better results.

@ScrapyardFilms

It turns out that both VLC and Vegas are making decoding mistakes, if for different reasons. Neither is correct, so neither could be used as a reference.

• As @Marco. first suggested, VLC is looking for the yuvj420p  flag, which is apparently missing, and defaulting to yuv420p, which is the equivalent of  Limited. So it is most obviously clipped.

• Vegas is getting the levels right because it sees the Full flag, but is shifting the reds 3° towards the yellow. The reason probably has nothing to do with the 601/709 primaries.

• Handbrake gets the Levels and reds right, so there is a workaround for now. You could also set the yuvj420p flag in ffmpeg.

Oh dear, more variables. 32-bit video levels does not conform the files' levels for playback or render while 8-bit full does.

As Vegas properly reads the levels from the file stick to 8-bit full as you're not working with a >8 bit depth file anyway.

Tried in 8-bit. Slightly different results, but the reds are still orange on YouTube with both Uncompressed and YUV,

@ScrapyardFilms

It turns out that both VLC and Vegas are making decoding mistakes, if for different reasons. Neither is correct, so neither could be used as a reference.

• As @Marco. first suggested, VLC is looking for the yuvj420p  flag, which is apparently missing, and defaulting to yuv420p, which is the equivalent of  Limited. So it is most obviously clipped.

• Vegas is getting the levels right because it sees the Full flag, but is shifting the reds 3° towards the yellow. The reason probably has nothing to do with the 601/709 primaries [hears hisses and boos /].

• Handbrake gets the Levels and reds right, so there is a workaround for now. You could also set the yuvj420p flag in ffmpeg.

I'm relatively new to video, what's the workaround exactly? How can I set the correct flag in the original file so that Vegas would read it properly?

FWIW:

Transcoding sss-v's footage to AVI using Bigasoft Total Video Converter (just copying streams, no actual conversion, so sorta remuxing!) and importing it to Vegas gives different results than importing his original MOV file.

Imported as AVI:

and it's Vectorscope:

Imported as MOV:

The Vec:

Media properties/General tab shows so4compoundplug being used to decode the MOV file.

Don't know what's being used to decode that AVI file, click on General tab in Media properties - crashes Vegas...😂

Obviously you're trying to go where you're not supposed to go!

@sss-v
"That's what I'm doing. Channel Blend (601 -> 709) then Levels (Studio RGB to Computer RGB)."

There is no reason to apply such a level conversion in Vegas Pro because the levels are perfectly correct without. If you apply this conversion you will introduce clipping, also it would not match the original source levels.
Except, of course, if this would happen for your very personal taste of aesthetics which then would rather be a process of grading, not correction.
But with using a 32 bit float point project and applying grading fx we would enter a quite different kind of water then which all should not be confused with the base issue.

@Marco.

I was just trying to match what I was seeing on VLC. I do get your point though.

But still no real solution, the rendered files get washed out once uploaded to YouTube. Resolve seems to be the best option so far. Can't believe this is turning out to be so difficult.

I think you try to be two steps too far. First find out what exactly is going on when using such footage in Vegas Pro and if there's something going wrong with Vegas Pro reading the file, find the one proper solution to get it right.

Rendering/Exporting is the next step. A YouTube distribution quite another. Way too many variables involved if you try to get them all in once.

@Marco.

Well, I'm happy with what I get with the 601 -> 709 conversion. it just doesn't translate to YouTube that way.

@sss-v
"That's what I'm doing. Channel Blend (601 -> 709) then Levels (Studio RGB to Computer RGB)."

There is no reason to apply such a level conversion in Vegas Pro because the levels are perfectly correct without. If you apply this conversion you will introduce clipping, also it would not match the original source levels.
Except, of course, if this would happen for your very personal taste of aesthetics which then would rather be a process of grading, not correction.
But with using a 32 bit float point project and applying grading fx we would enter a quite different kind of water then which all should not be confused with the base issue.

 

Again, @Marco. is absolutely correct. This is easily proven if I deliberately clip the Vegas output by adding the ComputerRGB  filter. As you can see, the output is identical to the VLC output, meaning wrong.

So, if for some reason one wants to use the clipped VLC output as one's reference, the ComputerRGB  filter in Vegas is the way to do it.

So, if for some reason one wants to use the clipped VLC output as one's reference, the ComputerRGB  filter in Vegas is the way to do it.

The 601/709 speculation is nonsense.

No preference really regarding levels, I'd be ok either way. I just want the colors to be correct, that is, the red shirt to be red on YouTube and not orange. The shirt in real life is deep red.

Anyway, let's get back one step before YouTube is involved. Is the rendered result fine for you viewed in Vegas Pro or viewed in the VLC player?

If it is in the VLC player, then again levels could be wrong. VLC player sorted to be a really bad reference from my experiences.

And what does MediaInfo say about the color range of your final rendered clip?

@sss-v

How's your graphics card set? Seting it wrong, with YouTube, can give level errors and color shifts as well.

And then there's the monitor settings...😀

@sss-v

How's your graphics card set? Seting it wrong, with YouTube, can give level errors and color shifts as well.

And then there's the monitor settings...😀

 

@adis-a3097, NOT FUNNY! ;-)

The TV is calibrated. Here is the GPU setting. Should I change it to NVIDIA limited?

Also @sss-v you can try using the conversion and then rendering using Voukoder and possibly get results your happy with. It has many encoding options and I personally only use this to render any videos in VEGAS.

@sss-v

How's your graphics card set? Seting it wrong, with YouTube, can give level errors and color shifts as well.

And then there's the monitor settings...😀

 

@adis-a3097, NOT FUNNY! ;-)

The TV is calibrated. Here is the GPU setting. Should I change it to NVIDIA limited?

I don't know. It's not same for different systems (different browsers etc.), try it out and see if you can match what you see in YT player vs what you get out of Vegas in your media player.

Fingers crossed! 🙂

Well guys, I'd say we have a winner!

Assuming @Musicvid is correct in that Handbrake gets both the levels and colors right, here is the solution:

Set Vegas to 8-bit (full range), apply the 601 -> 709 conversion, render AVI / Sony YUV 10-bit.

Top Left: Vegas
Bottom Left: Resolve
Right: Handbrake

Close enough for me! Thanks so much for help, I was ready to go murder someone! If there are still things regarding best practices that I'm doing wrong, please let me know. But, the current results are good enough for me. :-)

Thanks again.

YW! 😀

Probably then all you'd need to do is to check which meta data HandBrake finally used and then transfer same property to the Vegas Pro rendering, which then would save you one step in your pipeline.