Contrast of video changed after rendering to same format

[Bencuri]

I have rendered a video today from Vegas through Debugmode Frameserver and x264.exe. I did not want to change anything regarding the format and specs of the original video, only wanted to edit it and render with the same specs. The problem is that the rendered video seems to have different contrast or color settings than the original. I did not set the encoder to change these, however.

This is the command I used: x264.exe --preset "faster" --crf 18 ...source video ....trarget video

The source was the .avi, the Debugmode Frameserver output.

What do I need to add to leave the colors unchanged? The output of the Frameserver was YUY2. I have used a tmod x264.exe that has mp4 support. Maybe the modded version has a feature by default that changes the colors?

The video samples are attached.

[davexnet]

Try adding the color primaries to the x264 command line

--colormatrix "bt709" --transfer "bt709" --colorprim "bt709"

[Bencuri]

Still not okay.

[jagabo]

I haven't seen your videos but your problems is related to limited range (16-245) vs full range (0-255) luma. Try adding "--fullrange on" or "--fullrange off" flags to the x264 command line. Generally, you should always use limited range in YUV. Unfortunately, Vegas often messes up the range when it converts between YUV and RGB.

[Bencuri]

I haven't seen your videos but your problems is related to limited range (16-245) vs full range (0-255) luma. Try adding "--fullrange on" or "--fullrange off" flags to the x264 command line. Generally, you should always use limited range in YUV. Unfortunately, Vegas often messes up the range when it converts between YUV and RGB.

That parameter has been removed for a while. I tried the oldest version available at the VLC website, that one does not know the parameter either.

[davexnet]

For a frameserved video that may be full range, you can try

--input-range pc  --range tv

[Sharc]

The renderer actually compressed the levels. Depending on the source codec/format some NLEs are simply mistreating the levels. This can happen right on import.
In avisynth you can fix the rendered version with

coloryuv(levels="TV->PC")

for comparison
left=original right=rendered fixed

Note that the gaps in the histogram on the right (rendered fixed) represent missed YUV code values due to Avisynths's 8bit integer maths with rounding. Usually harmless. You can fill these gaps by dithering or by just adding a tiny bit of noise, for example. Attachment 2 is with dithering.

convertbits(16).colorYUV(levels="TV->PC").convertbits(8,dither=0)

[Bencuri]

For a frameserved video that may be full range, you can try

--input-range pc  --range tv

Does not seem to make a difference.


What makes the video look similar to the original is if I add an FX in Vegas to change Studio RGB of the video to Computer RGB. In that case the rendered looks very similar. There is a slight difference remaining, unfortunately I am not sure how to advance from there. I tried to adjust brightness, contrast, yet I cannot get over the remaining difference. You can see that difference on the red part of the ball, in the original, it is darker,. The whole image is darker a bit, and less saturated compared to the rendered. See the attachment.

[Bencuri]

The renderer actually compressed the levels. Depending on the source codec/format some NLEs are simply mistreating the levels. This can happen right on import.
In avisynth you can fix the rendered version with

coloryuv(levels="TV->PC")

for comparison
left=original right=rendered fixed

Note that the gaps in the histogram on the right (rendered fixed) represent missed YUV code values due to Avisynths's 8bit integer maths with rounding. Usually harmless. You can fill these gaps by dithering or by just adding a tiny bit of noise, for example. Attachment 2 is with dithering.

convertbits(16).colorYUV(levels="TV->PC").convertbits(8,dither=0)

I cannot test it because I get this error:


[Attachment 90762 - Click to enlarge]

[Sharc]

The renderer actually compressed the levels. Depending on the source codec/format some NLEs are simply mistreating the levels. This can happen right on import.
In avisynth you can fix the rendered version with

coloryuv(levels="TV->PC")

for comparison
left=original right=rendered fixed

Note that the gaps in the histogram on the right (rendered fixed) represent missed YUV code values due to Avisynths's 8bit integer maths with rounding. Usually harmless. You can fill these gaps by dithering or by just adding a tiny bit of noise, for example. Attachment 2 is with dithering.

convertbits(16).colorYUV(levels="TV->PC").convertbits(8,dither=0)

I cannot test it because I get this error:


[Attachment 90762 - Click to enlarge]

Your 'original.mp4' of post#1 is YV12, not YUY2.
If it's YUY2 now add ConvertToYV12() or ConvertToYV16() before Converbits(16).......

[Sharc]

What makes the video look similar to the original is if I add an FX in Vegas to change Studio RGB of the video to Computer RGB. In that case the rendered looks very similar. There is a slight difference remaining, unfortunately I am not sure how to advance from there. I tried to adjust brightness, contrast, yet I cannot get over the remaining difference. You can see that difference on the red part of the ball, in the original, it is darker,. The whole image is darker a bit, and less saturated compared to the rendered. See the attachment.

YUV->RGB->YUV .... colorspace conversions are lossy and do not exactly reproduce colors in round trips, plus 8 bit integer maths introduce rounding errors.
Your source is YUV, then converted to sRGB, then level stretched to computer RGB, then converted back to YUV for the .mp4, and finally converted to RGB for displaying the .mp4 on a monitor. Also, make sure not to switch the matrix 601<->709. (I don't know what matrix Vegas and your renderer is using for YUV<->RGB conversions)

[Bencuri]

What makes the video look similar to the original is if I add an FX in Vegas to change Studio RGB of the video to Computer RGB. In that case the rendered looks very similar. There is a slight difference remaining, unfortunately I am not sure how to advance from there. I tried to adjust brightness, contrast, yet I cannot get over the remaining difference. You can see that difference on the red part of the ball, in the original, it is darker,. The whole image is darker a bit, and less saturated compared to the rendered. See the attachment.

YUV->RGB->YUV .... colorspace conversions are lossy and not exactly reproducible colors in round trips, plus 8 bit integer maths introduce rounding errors.
Your source is YUV, then converted to sRGB, then level stretched to RGB, then converted back to YUV for the .mp4, and finally converted to RGB for displaying the .mp4 on a monitor. Also, make sure not to switch the matrix 601<->709. (I don't know what matrix Vegas and your renderer is using for YUV<->RGB conversions)

But the problem is that all this that you write is the situation that are beyond my control. I need to edit the video, so it has to be feeded to Vegas, I need to match it to the overdubbed speech and the local video version, and this needs to be done by dropping or doubling frames. And adding multiple videos the the project. I need to use what comes out of it. But even so if I use x264.exe to render, I get better results than rendering even at higher bitrate with Vegas. So the situation is not that bad as you describe. Qualitywise it is still a better way, only the colors should be matched to keep it similar to the source. What comes out without that is just too different.

[Bencuri]

The renderer actually compressed the levels. Depending on the source codec/format some NLEs are simply mistreating the levels. This can happen right on import.
In avisynth you can fix the rendered version with

coloryuv(levels="TV->PC")

for comparison
left=original right=rendered fixed

Note that the gaps in the histogram on the right (rendered fixed) represent missed YUV code values due to Avisynths's 8bit integer maths with rounding. Usually harmless. You can fill these gaps by dithering or by just adding a tiny bit of noise, for example. Attachment 2 is with dithering.

convertbits(16).colorYUV(levels="TV->PC").convertbits(8,dither=0)

I cannot test it because I get this error:


[Attachment 90762 - Click to enlarge]

Your 'original.mp4' of post#1 is YV12, not YUY2.
If it's YUY2 now add ConvertToYV12() or ConvertToYV16() before Converbits(16).......

This is because Debugmode Framserver delivers the video in YUY2 from Vegas. I can also select RGB32 or 24, not sure if it does any improvement though. I tried RGB32, the color is still different than the original, so that alone is not a solution.

The output is 709 anyway.

[Sharc]

Try this:

z_ConvertFormat(pixel_type="YUV420P8",colorspace_op="fcc:709:709:l=>709:709:709:f",dither_type="ordered")

The difference to the original is almost nil.

See
http://avisynth.nl/index.php/Avsresize

[jagabo]

Your source is limited range (16-235), rec.709 and flagged as such. Your rendered video has no flags but has an inappropriate additional contrast compression (~32-215). When you import your source into Vegas set the source properties to limited range (16-235), rec.709. That should stop it from applying the additional contrast compression.

[Bencuri]

Try this:

z_ConvertFormat(pixel_type="YUV420P8",colorspace_op="fcc:709:709:l=>709:709:709:f",dither_type="ordered")

The difference is almost nil.

See
http://avisynth.nl/index.php/Avsresize

This is the best approach so far. It's almost the same, I can use this.

Referring back to what you mentioned about loosing quality on color conversions, what shall I set for the Debugmode Framserver output colorspace? There is RGB24 RGB32 and YUY2. Sony Vegas is said to use RGB, I have selected 8bit for pixel type, and no alpha channel. I guess my selection is what is called RGB24, so that should be the output choice, shouldn't it?

Your source is limited range (16-235), rec.709 and flagged as such. Your rendered video has no flags but has an inappropriate additional contrast compression (~32-215). When you import your source into Vegas set the source properties to limited range (16-235), rec.709. That should stop it from applying the additional contrast compression.

Unfortunately you cannot make such adjustments, not in my version at least. The only selectable is Pixel type, alpha channel and there is an option: Color space for the individual clips, but it enlists types I am unfamiliar with, not YUV or RGB. They must be industry standard names (ACES, ADS, SONY, Arri, Log)

[Sharc]

Try this:

z_ConvertFormat(pixel_type="YUV420P8",colorspace_op="fcc:709:709:l=>709:709:709:f",dither_type="ordered")

The difference is almost nil.

See
http://avisynth.nl/index.php/Avsresize

This is the best approach so far. It's almost the same, I can use this.

Referring back to what you mentioned about loosing quality on color conversions, what shall I set for the Debugmode Framserver output colorspace? There is RGB24 RGB32 and YUY2. Sony Vegas is said to use RGB, I have selected 8bit for pixel type, and no alpha channel. I guess my selection is what is called RGB24, so that should be the output choice, shouldn't it?

I don't know Vegas and the Debugmode Frameserver and how and when these "silently" convert something under the hood. But as a general rule try to keep the number of colorspace conversions YUV<->RGB to a minimum, and keep the 601 <-> 709 and limited <-> full levels range under control, simply speaking. Avsresize (i.e. z_ConvertFormat(....)) can usually help if something went wrong.
Maybe someone familiar with Vegas may chime in .....