Contrast of video changed after rendering to same format

[Bencuri]

Very old version.
In newer versions, range management is automatic; in older versions, you had to manually enable the Computer RGB <-> Studio RGB filter. I recommend upgrading to version 22; it's on sale for a few USD.

The problem is I have an old laptop, and it runs fine with version 12. I assume in case I install the latest, it wouldn't run that smooth. And I am on Win7.

I will try to add a new drive and will see how the new version runs in the near future. But I am not very happy to install Windows 10, originally that was on my machine, but it was slower.

[Alwyn]

The latest version of Vegas requires 64bit Windows 11.

[rgr]

The latest version of Vegas requires 64bit Windows 11.

Maybe, but I don't recommend it until they fix the bugs in v23. v22 runs on W10.

Edit: From support: "So, is it incompatible? No. Is it recommended? It is not."

[rgr]

I don't use Vegas. But just in case: as I understand it, you right click on the clip in the asset window (not the timeline) and select properties or something like that. Be sure you checked that for levels, colorspace, etc settings.

Here is a video of my screen showing what options are there.

I don't see an option to choose full range/limited range with 8 bits. I'm 99% sure it's limited. Try "32bit full range".

[Bencuri]

I don't use Vegas. But just in case: as I understand it, you right click on the clip in the asset window (not the timeline) and select properties or something like that. Be sure you checked that for levels, colorspace, etc settings.

Here is a video of my screen showing what options are there.

I don't see an option to choose full range/limited range with 8 bits. I'm 99% sure it's limited. Try "32bit full range".

That seems to be the native solution in Vegas. If I select 32 bit floating point and export with RGB32 in the frameserver, the output seems to respect the original colors. See the attachments.

When selecting the 32bit floating point option, the menu automatically jumps to a view transform selection, I need to set it back to none, else the colors looks weird in the preview. See the attachment too.

[rgr]

Transformation set to none. Also, render quality to best (same with audio). Gamma should probably be set to 2.2, not linear, but I'm not sure.

[Bencuri]

Transformation set to none. Also, render quality to best (same with audio). Gamma should probably be set to 2.2, not linear, but I'm not sure.

Thanks for the advice!

[rgr]

When selecting the 32bit floating point option, the menu automatically jumps to a view transform selection, I need to set it back to none, else the colors looks weird in the preview. See the attachment too.

Colors look OK, better than before. Contrast can be off in preview (older Vegases always displayed the preview as limited or full range—I don't remember), and sometimes it would be bad in preview, but OK after rendering. This was fixed with a plugin.

[Bencuri]

When selecting the 32bit floating point option, the menu automatically jumps to a view transform selection, I need to set it back to none, else the colors looks weird in the preview. See the attachment too.

Colors look OK, better than before. Contrast can be off in preview (older Vegases always displayed the preview as limited or full range—I don't remember), and sometimes it would be bad in preview, but OK after rendering. This was fixed with a plugin.

Yes it looks good because for the photo I set the View Transform to none. By default it is on another value when you select 32 bit, and the colors look weird. It needs to be set to none for the colors to return to normal.

[Bencuri]

Just to update about the conclusions:

Changing the project to 32bit full range is definately a solution inside Vegas, but not very practical in my case. It slows down the rendering process quite much. So at the moment with the recent machine I have to stick to the code that Sharc recommended:

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

It's much faster to use this instead when rendering.

[Sharc]

Just to update about the conclusions:

Changing the project to 32bit full range is definately a solution inside Vegas, but not very practical in my case. It slows down the rendering process quite much. So at the moment with the recent machine I have to stick to the code that Sharc recommended:

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

It's much faster to use this instead when rendering.

You may replace the fcc by the more common 601 in the colorpspace_op. I tried both and kept the fcc because I thought it gives a tiny bit better results, but perhaps it was in my imagination only rather than facts.

[Bencuri]

Just to update about the conclusions:

Changing the project to 32bit full range is definately a solution inside Vegas, but not very practical in my case. It slows down the rendering process quite much. So at the moment with the recent machine I have to stick to the code that Sharc recommended:

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

It's much faster to use this instead when rendering.

You may replace the fcc by the more common 601 in the colorpspace_op. I tried both and kept the fcc because I thought it gives a tiny bit better results, but perhaps it was in my imagination only rather than facts.

I have tested the script, it seemed identical to me regarding colors. However when I zoomed into the original and converted image, with large magnification you could see that as if the details were a tiny bit blurred in the converted. When fitted to screen, I didn't notice anything in the video. Is this because of the converter settings or the dithering? My command was:

x264.exe --preset "fast" --CRF 18

I mention this because I want to know if I choose bad command parameters, or this will remain like that as described even if I choose medium or slow for the preset. With fast preset, the rendering time is still acceptable for me, with medium, it would be, but not very convenient. I don't want to make things go slower if the mentioned "problem" is not due to the converter. But let me emphasize again this is a minor problem, I am just trying to understand what causes it.

[Sharc]

I don't know, but you can try dither_type="none".

[rgr]

Just to update about the conclusions:

Changing the project to 32bit full range is definately a solution inside Vegas, but not very practical in my case. It slows down the rendering process quite much. So at the moment with the recent machine I have to stick to the code that Sharc recommended:

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

It's much faster to use this instead when rendering.

1. Check colorspace. But Vegas always outputs Rec709.
2. Double recompression = lower output file quality.
3. Old Vegas, unfortunately, do not have full 8-bit range.

4. You can outputs as, for example, UT Video RGB and use ffmpeg to converts to MP4.

[Bencuri]

Okay, might be funny, but there is another twist in the story: setting 32 bit in Vegas will do as well. I noticed that only the conversion of the intro of the film is going slow. After it finishes with the intro, the conversion of the rest of the film is going at an acceptable speed. I don't know why the intro takes that big effort. It contains static images, maybe the problem is that the aspect ratio is different than that of the target, while the aspect ratio of the rest of the film matches. Anyhow, I will be able to do it under this circumstance with selecting 32 bit now. Takes somewhat longer than with 8bit, but still in the okay zone.