SMPTE bars don't show the entire gamut, but the red is darker.

No other filters, just Computer to Studio across all chnnels.

Any player shows the same, WMP, VLC, HTML5, Flash

It doesn't really matter about any of that, the point is that 255 red, is 240 when the video is played.

OK, and what is "spectrum test pattern?" Is that something in Vegas 15?

Have you checked your results against Belle-Nuit?

If what you are reporting is accurate, your video would look horribly cyan on playback. Is that the case?

Give us something we can replicate. Step by step, please.

• Use the Vegas Gradient test pattern
• Apply Computer>Studio Levels (or don't, it doesn't matter to this test)
• Render MP4 and play in any player
• Top right GREEN and bottom centre BLUE are 255
• Top LEFT RED is 220

This is obviously using a different colourspace from sRGB, so how can it be corrected?

Top left is Vegas preview (red is 255), window under is WMP (red is 220) 

https://www.vegascreativesoftware.info/us/forum/vegas-13-weird-color-shift--105810/#ca655085

maybe this. had issue with red. problem was the source resolution

I solved all questions. The problem was that vegas read 1280x694 as SD rec.601 and 1280x720 as HD rec.709 - players read all files as rec.709. Resizing source to 1280x720 prior import to vegas made vegas read and render it as players do.

@uk-andrew-c What version of Vegas? What encoder?

This is mp4 using Sony AVC encoder.

Since you report the same altered levels in all player grabs, it may only be your monitor profile at work. My player grabs look "something" like yours, but not as different in the reds.

Vegas (Pro 8) is behaving the way I expect; it obviously has no influence over downstream "profiling."

And here's the same grab from VLC at playback levels..

Nick: V14 MainConcept AVC.

James: There is no source video, this is purely on generated output.

MusicVid: Mine is a single screenshot, it's not about perception, I'm testing the actual red value. Your 2nd screenshot is also from Vegas ;-).

The issue is that in Vegas Red=255, Green=255, Blue=255 - in video player Red=225, Green=255, Blue=255.

This appears to be a bug with the MainConcept AVC encoder that was introduced some time between VP10 and VP12, and has been carried over into the MainConcept AVC mode of the MAGIX AVC encoder in VP15. It turns this:

Into this:

i.e. It "folds in" the extremes of the red channel, and to a lesser extent the green channel.

It only happens in with software MC encoding.

It does not happen with the QSV encode mode of the MAGIX AVC encoder.

It does not happen with the OpenCL encode mode of the MainConcept AVC encoder.

It does not happen in VP10.

It does not happen with the Sony AVC encoder.

It does not happen if a Computer RGB to Studio RGB Levels FX is applied to the gradient before rendering.

It's not a good thing to happen but if your levels are within 16-235 (which is something that's recommended for most purposes) then it doesn't seem to be an issue. This is a rendered Magix AVC file from media that had a Computer RGB to Studio RGB Levels FX is applied to it:

I'll report it.

I rendered a Belle Nuit test chart. There was no problem because it contains no red or green-only regions >235 or <16. Pure white at 255,255,255 is allowed to pass.

I'm now thinking that this might not be a bug but rather deliberate behaviour to "legalize" levels somewhat. Just a guess. Does anyone with a broadcast background know if pure red at 255,0,0 RGB is a particular problem (more than the other channels)?

It does happen with Sony AVC in Vegas Pro 8.

The Photoshop eyedropper values are identical to dragging the same screenshot into Vegas timeline, so OP can abandon that line of investigation.

I can't test this for you now, but take an uncompressed AVI of the gradient from Vegas at RGB levels, and render x264 mp4 in Handbrake. Same, or different?

Thanks Nick for your hard and diligent work. I've not seen this issue before (but not having worked for a few years, I jumped from V8 to V12 then V14).

255 Red is possible; I tested increasing the brightness, you can see a 255 red on the player. So I don't think it's trying to legalize the Red. My view is that something (renderer or player) is mapping to a different colour space and cocking it up??

Is there a way to get a 16-235 version of a 0-255 colour from RGB or HLS?

If Musicvid meant to say 'does NOT..., then is it looking like a bug?

If Vegas is correct and it's not happening on VP8 and ALL players give the same result and 255 is possible, then it possibly is the renderer on my version?

I had assumed this was some colourspace conversion issue, but assuming the transforms for that, are almost certainly correct, perhaps it is a bug?

I'll try some other formats and run an AVI through FFMPEG to see what that produces.

Thanks for your help guys, was feeling a bit lost until now ;-)

No I spoke correctly.

What I notice from the Sony AVC render in Vegas Pro 8 that shows the behavior (!) is that the color primary and matrix (BT.709) information is missing from my MediaInfo dump.

Therefore, if the flag is truly missing, players may be defaulting to something else (but obviously not BT.601, because those red primaries are identical).

MusicVid: Sorry, then not sure what you meant by getting identical values?

Photoshop and Vegas each read identical values from my one and only screenshot from VLC, which clearly shows the behavior you describe.

That effectively rules out Vegas' decode engine as a contributer to any aspect of your investigation. It displays input values correctly in RGB space, as it has from day one.

You said my second screen grab, the one that shows the behavior, came from Vegas. That observation is irrelevant.

I'll check back later in the week.

MusicVid: I see, you loaded your screenshots into Vegas

Nick: Thanks, tried this in handbrake and FFMPEG, and it is OK, so I'll use that for now and report this to Magix.

Just need to get Frameserving into Handbrake working now!!

Nick, in your test encodes that show the behavior described, does the BT.709 color primary and matrix information show up in MediaInfo?

Nick, in your test encodes that show the behavior described, does the BT.709 color primary and matrix information show up in MediaInfo?

That info doesn't show up in the MediaInfo for any of those MAGIX/MainConcept/Sony AVC tests. I don't think this is just a straightforward 601-vs-709 error. The symptoms aren't typical of that, and I tried switching 601-709 when rendering x264 in VirtualDub Filtermod and I couldn't replicate this behviour.

Here's a test chart I made with RGB 255/255/255 and a 0-255 black>white gradient:

None of the AVC encoders/modes I tried will pass this through without shifting the levels, but MainConcept particularly freaks out over the red and blue, to the point that it brings their level even lower than if I put a computer-rgb-to-studio-rgb Levels FX on the project before rendering, which makes no sense at all. Red comes down to 225 and blue comes right down to 220!

As I said above, it's OK if everything in Vegas is delivered to the encoder between 16-235, so keep saturated colours within that range before rendering. If for some reason you want to render a video with pure primaries above 235-240 then don't use MainConcept.

Haven't reported this yet.

Is there a way to get a 16-235 version of a 0-255 colour from RGB or HLS?

You can use the following on all channels or just one channel:

Map 0-255 to 16-235 (all levels in-between change):

Clip to 16-235 (hard limiter. intermediate levels are unchanged):

Clip to 16-240. This is highly debatable, but it's possible that individual channels can go up to 240 and still be "Rec-709-legal" as long as the overall luminance remains below 235. I got the idea years ago from here. Worth a try, but might be nonsense:

You're getting slightly different to me because Blue and Green are always 255. It's only Red, that as you say comes down to 220-225 (I do apply Computer to Studio).

I have reported this, but really surprised that it's not been noticed before, especially for red/green mixes because it makes a huge difference. e.g. Gold comes out a much brighter Yellow.

Sorry Nick, I meant before you put it into Vegas, I'm getting RGB colour values from corporate colours, then using them for colour and text generators. Mind you, even if I did that, I don't think it would work, because it still won't force the encoder Red above 225.

While I'm here, do many use FFMPEG for encoding, because I'm thinking of writing an extension that would use the FrameServer to go straight to FFMPEG?

You're getting slightly different to me because Blue and Green are always 255. It's only Red, that as you say comes down to 220-225 (I do apply Computer to Studio).

Please download that png chart I posted above, render it with MAGIX AVC (Mainconcept mode) and let me know where R, G and B end up on your Vegas scopes when you put the rendered file back on your timeline.

Then also do it with a computer-to-studio levels filter on.

It would be very strange if our systems differ in that respect.

I can see why it's critical to get corporate colours exactly right.

While I'm here, do many use FFMPEG for encoding, because I'm thinking of writing an extension that would use the FrameServer to go straight to FFMPEG?

Quite a few are using x264 one way or another including FFmpeg (as well as MeGUI, Handbrake (via Vegas2Handbrake - see part 4 of this), VirtualDub Flitermod, Ripbot etc.). I frameserved to VirtualDub Filtermod in my investigation of this issue and it worked pretty well with x264.

ffmpeg rendering with frameserving from Vegas doesn't solve the issue (seen from Vegas preview with x264 encoding).

• Red becomes 250,1,1
• Blue becomes 0,0,248
• Green becomes 5,252,6

It seems that converting RGB to YV12 causing this error.