Do you use a full level or video level floatpoint project?

bug appears in any mode

Mmh, I'd say this works as expected here. Which build of VP16 do you use?

Mmh, I'd say this works as expected here. Which build of VP16 do you use?

I faced that bug for many years really... from when I worked in VP14 till latest build of VP16. And VP13 affected too (tested today).

In your test - checkbox "Invert mask" and try again.

Mmh, I'd say this works as expected here. Which build of VP16 do you use?

I checked - you are looking to wrong frame with cyan not saturated enough. Just scroll to 6,19 or 5,25.

"In your test - checkbox "Invert mask" and try again."

If I do this it works same, just in the oposite direction.

"I checked - you are looking to wrong frame with cyan not saturated enough. Just scroll to 6,19 or 5,25."

I'll check again at these points, thanks.

I've been at 6:06 in the screenrecordings above. At this point the saturation of cyan is higher as at 6:19 or 5:25. Actually I used the point with the highest cyan saturation I could find.

6:06 (the frame I used)

6:19

5:25

Anyway – I also tried at 5:25 and 6:19 and this also works fine here. I can't find a frame in this video clip which doesn't work.

I've been at 6:06 in the screenrecordings above. At this point the saturation of cyan is higher as at 6:19 or 5:25. Actually I used the point with the highest cyan saturation I could find.

6:06 (the frame I used)

6:19

5:25

May be it is not the most saturated but some range of saturation, that have that bug. I may be wrong at technical nuances.

I just corrected my post above another time. Even at 5:25 and 6:19 it works fine here. Can't find a non-working frame in this clip.

Did you try disabling your GPU acceleration?

I just corrected my post above another time. Even at 5:25 and 6:19 it works fine here. Can't find a non-working frame in this clip.

Did you try disabling your GPU acceleration?

Checked with disabled GPU - same bug.
Also checked both Nvidia GPU and Intel GPU - all are same bad.

I got interesting finding: if I put "ColorCurve" FX before "ColorCorrector(Secondary)", even if it is "default" curve without any changes - bug goes away.

I guess I now can repro the issue you describe.

@Rush 
After I had a repro of the issue I now try to set up a simple demo project more suitable for a bug report. Thus I tried to transfer this particular cyan color into a solid color event, but then I cannot repro the issue no more, and same is when I use same cyan as centre of a color gradient.

Do you succeed in reproing same issue when using any kind of Vegas Generated Media instead of your real video?

@Rush 
After I had a repro of the issue I now try to set up a simple demo project more suitable for a bug report. Thus I tried to transfer this particular cyan color into a solid color event, but then I cannot repro the issue no more, and same is when I use same cyan as centre of a color gradient.

Do you succeed in reproing same issue when using any kind of Vegas Generated Media instead of your real video?

Can it be related to some kind of wrong YUV decoding?
What "ColorCurve" FX do when you apply it? If it fixes colors of source video even if it is straight default line - may "ColorCurve" do some kind of YUV-RGB conversion, which "ColorCorrector(Sec)" don't do?

The only special property of Color Curves I'm aware of is in floint point projects it will strictly clip levels which exceed the range from 0-1 (though float point would allow levels to exceed this range). So dependend on where in the process pipeline you apply Color Curves (even with default values which you'd expect to do nothing) you will lose one of the very advantages of the float point math.

You said you faced this problem since years – is it always cyan only or did it ever happen to different colors, too?

I think I know what the cause is.

In the video there are cyan parts which strongly exceeds legal color ranges (actually it is the blue channel of R'G'B' and I guess this is because of LED stage lighting). If you use Color Corrector Secondary it will only affect the legal ranges of R'G'B' (the same ranges which are affected in 8 bit mode) but ignores ranges beyond.
And, by the way, this is the reason the issue cannot be reproduced by any of the Generated Color Media because they will never have colors which exceed R'G'B' ranges in such way. That's a very nature of LED light and it may be it would not affect all colors.
If you apply Color Curves before, it will clip the blue channel back to the legal range and Color Corrector Secondary now affects everything. Same will happen if you apply any filter which will bring back a "burst" color channel before using Color Corrector Secondary.

I'm not sure if this is a bug in a technical sense but at least it throws results a user would not expect. I will send a report.

For now I think to most simple way to overcome is what you already found and do: Using Color Curves with default settings in first place. You may save Color Curves and Color Corrector Secondary as FX Package to have a faster access to this FX pair.
You could also pre-render such stage footage with a pre-processing to avoid extrem burst colors but this would take a lot more time.