"I exported the quick graded clip (The footage was assigned with Slog2 Sgamut IDT) with REC709 color spaces & color range to limited."

What does is look like if you export with Rec. 709 and color range "full"?

It become more reddish after exported

@Marco. Both exported clip (Full & Limited) from ACEScc look exactly the same when I import them into VEGAS timeline.

It just that exported clip have more contrast.

I just analyzed your screenshot and you are right. While now black, white and gamma match, the color shifts a bit towards red/magenta. But maybe that's caused by the external player. They almost always add (for me) strange kind of color management.

"It just that exported clip have more contrast."

For your example in the Vegas timeline, this is the full/limited difference which I only suggested for the comparison in an external player.

But in the end, I never succeeded to gain matching results when using an ACES workflow, so meanwhile I gave up on it.

Maybe it's caused by your player's internal color management. Maybe it's caused by the ACES management in Vegas Pro. Even if it is the latter, I don't know if this is considered being a bug (I already reported something else) or a shortcoming of ACES (which I'd find strange).

Just an observation ... it's almost like pre-VP18 with not doing the global FX Levels setting Studio RGB to Computer RGB. Maybe try Levels and see if that resolves the problem.

I just analyzed your screenshot and you are right. While now black, white and gamma match, the color shifts a bit towards red/magenta. But maybe that's caused by the external player. They almost always add (for me) strange kind of color management.

"It just that exported clip have more contrast."

For your example in the Vegas timeline, this is the full/limited difference which I only suggested for the comparison in an external player.

How can I tell that what I'm seeing in the preview look exactly on the final output?

So you're saying the external player in windows causes that weird color shift, how do I solve it then? Buy a physical hardware like Blackmagic Decklink for "pure" color signals?

Maybe anyone can try reproduce this error with their system

@RogerS @set

Just an observation ... it's almost like pre-VP18 with not doing the global FX Levels setting Studio RGB to Computer RGB. Maybe try Levels and see if that resolves the problem.

Look eve more contrasty. It almost crush the black

I'm not sure what player you are using. I'm using Media Player Classic BE at the recommendation of other video experts. download

That may or may not be the problem here but I figured I'd share it.

I stopped experimenting with ACES as it isn't solving a problem I have at the moment, and introduces its own set of problems. If I do HDR footage at some point I'll revisit it.

"So you're saying the external player in windows causes that weird color shift, how do I solve it then?"

At least I see similar color shifts on various players (like VLC) and I didn't find any setting to solve it. For sure using an external calibrated hardware pro video monitor should be the best solution, but only if your audience is going to view your video on an external tv monitor.
For the wide world of web distribution I doubt there is a reliable tool to ensure everyone sees the same in the end.

Or the reverse, Levels Computer RGB to Studio RGB. If that worsens the contrast even more - which it might - then the issue may (I repeat MAY) lie with ACES. What happens if you drop ACEScc - just as an experiment?

Or the reverse, Levels Computer RGB to Studio RGB. If that worsens the contrast even more - which it might - then the issue may (I repeat MAY) lie with ACES. What happens if you drop ACEScc - just as an experiment?

Wow, it look similar now? But I cant tell if the gamma/gamut is accurate just by eye balls the look.

ACES switch back to normal 8 bit Full Range. The preview look flat

Excellent!. I must say that I've looked at your latest image comparison on 2 different displays (a basic laptop and a calibrated 4K monitor) and I prefer the image on the left as it has slightly deeper blacks/gamma. That's just my preference.

ACES switch back to normal 8 bit Full Range. The preview look flat

Yes, I agree with you.

@alifftudm95

I don't know how you set your monitor under the windows 10.

I have 2 Samsung LU28R55x Monitors and set them both in HDR modus so that the windows can manage the 10bit Color.

In vegaspro, pls set your project as following:

1, enable the HDR10 mode, you have no reason to change the other parameters else you do understand what they mean.

with this setup, you will see that the 2nd monitor also gets the HDR signal.

2, you need the HDR color scopes to see/control colors and Luminance (It's not brightness, it's nit).

3, enable the HDR-view button above the prewiew window and

4, define the color space where your source material come from (Rec709/2020, or Log-file etc.)

after finishing your job, you must again define to what color space your rendering goes to:

Apropos: it's nonsense to discuss color without value of the color scopes.

@alifftudm95

You'll have to switch to the "correct" Color space, like here:

When set to Default, it'll render to sRGB, which gives a tad more contrast than 709.

Edit:

Nevermind this post, I just saw that you did set it right.

@Yelandkeil Can you give guidance if you are not in HDR mode or attempting to grade for HDR?

@Yelandkeil I enabled HDR in windows 10 & pick HDR10 in VEGAS Pro, the output look similar. But the screenshot captured the preview in blown out look.

One thing about my monitor it can only go 300nits in brightness, so this is kinda confusing when VEGAS HDR10 by default pick the 1000nits value.

HDR is another complex color spaces, I'm not sure if its intended to work the same way as ACES workspace

The screenshot captured in the preview is likely 8 bit, so it cannot display those extra highlights that extend beyond its white point, hence the blown out look.

@RogerS I didn't copy what you mean. 
But if you're not in HDR/ACES mode, you have just one way to go: Rec709. 
All source material, no matter from which space it comes and how it looks like, can only be adjusted/graded up/down to Rec709space. 
 

@alifftudm95 I'm confused about your situation. 

1, the 1000/10000nits are peak value, has nothing to do with your monitor. The 300cd/m2 is the "mechanical" parameter of your monitor meaning it can show and know up to 300nit. Everything above this value is very bright, but it doesn't know how "very". THE video scopes know and show you the value. That's why you must use these instruments.

Don't trust your eyes. They can see particles but not molecules.

2, HDR is not color space, it's merely metadata based on WCG.

By the way, you mentioned ACEScc, please read something about ACES AP0/AP1...and SMPTE ST 2084 (PQ). Perceptual Quantizer is keyword to understand HDR. 

@Yelandkeil I see, that is helpful. Looking at this thread while the footage was shot in S-log I believe the intended output is Rec 709, so the view transform should be just Rec 709, right? If you have any other tips for ACES for a Rec 709 workflow (source and output), I'd be interested in it.

There is a S-Log view transform, so the media should be set to that, then the preview monitor and output can be set to Rec709 (or the Rec2020 ST2084 1000 nits transform for HDR) from there.

1, I don't recommend the ACESpace for Rec709 production. Reasons are simple: several FXplugins can't be used in this huge space due to their limitation and the space itself requires a real powerPC.

2, I do recommend the 32-bit floating full-mode for Rec709 production because it avoids every color banding artifact. People doubt that the final rendering just packs everything in 8-bit and where does the benefit come from. Well, algorithms for processing and packing are different. I'm not engineer.

3, materials like Log-file could be treated with LUT, but I don't have any experience and, in my opinion, the Color-Match plugin is way better. Vegaspro introduces LUT filter also very lately.

4, view transform is about hardware/equipment, not videosignal transcode.