Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums VEGAS Pro Vegas Pro 10 Losing Color/Contrasting With .wmv Files

  • Vegas Pro 10 Losing Color/Contrasting With .wmv Files

    Posted by Brandon Bias on March 7, 2011 at 1:44 am

    Hey everyone! I’ve come across a rather bizarre issue with Sony Vegas Pro 10. For some reason, whenever I import a .wmv file it loses some color and/or contrasting. I’ve uploaded a picture showing how my desktop looks in the .wmv file before being imported into Vegas and after being imported. To further clarify my problem, I looked at the pixels that are supposed to be 100% black and they turn out a very dark gray (approximate #101010, or RGB 16,16,16).

    Link to picture: 1718_demo.jpg.zip

    Can somebody tell me what my issue might be? Whether it’s Vegas’ fault, or whether I rendered the .wmv wrong somehow, or maybe it has something to deal with my graphics card? Thanks in advance!

    P.S. I already checked for other posts on this and didn’t come across anything noteworthy.

    John Rofrano replied 14 years, 1 month ago 9 Members · 20 Replies
  • 20 Replies
  • John Rofrano

    March 7, 2011 at 11:51 am

    [Brandon Bias] “To further clarify my problem, I looked at the pixels that are supposed to be 100% black and they turn out a very dark gray (approximate #101010, or RGB 16,16,16).”

    What you are seeing is the shift from Computer RGB to Studio RGB. If the file is rendered this way and you want to compensate for it, place the Sony Color Corrector plug-in with the Studio RGB to Computer RGB preset on the master video bus before you render. This will shift the values from the Studio RGB used by Vegas and the entire broadcast industry to Computer RGB used by the Internet and PC video.

    ~jr

    http://www.johnrofrano.com
    http://www.vasst.com

  • Danny Hays

    March 7, 2011 at 5:41 pm

    Another great tip John. I always thought wmv renders lost contrast and used color curves to get it back. I’ll try your method next time I make one. Thanks

  • Brandon Bias

    March 7, 2011 at 6:11 pm

    Thank you SOO much!! Worked like a charm =D

  • Brandon Bias

    March 7, 2011 at 6:19 pm

    Your advice has been incredibly helpful! Does this only apply to .wmv files or can it happen with .mov videos as well? Because I’ve had render issues with .mov as well, where everything looks fine in Vegas but after I render the video all the pixels get kind of.. “distorted” in a way. The picture keeps varying in quality.

  • John Rofrano

    March 7, 2011 at 7:09 pm

    [Brandon Bias] “Does this only apply to .wmv files or can it happen with .mov videos as well?”

    It is different for every codec. Some require the adjustment while others don’t. It also depends on your target device. If you were planning to play that WMV file back on a TV via a media server, you would NOT want to convert it to computer RGB because TV’s use Studio RGB. It’s only when you target PC playback that you need to convert to Computer RGB and then only for certain codecs (which makes things very confusing)

    [Brandon Bias] “Because I’ve had render issues with .mov as well, where everything looks fine in Vegas but after I render the video all the pixels get kind of.. “distorted” in a way. The picture keeps varying in quality.”

    This is a gamma bug with QuickTime. I don’t think Apple has an intention to ever fix it because it’s been going on for years now and everyone complains about it. Again, it’s only certain codecs inside of QuickTime.

    ~jr

    http://www.johnrofrano.com
    http://www.vasst.com

  • Matt Crowley

    March 7, 2011 at 8:35 pm

    Your media player and/or graphics card settings will affect how the video looks when played back on a PC. The WMV might be created with studio levels (16-235) but chances are Media Player and/or your graphics card settings will stretch this out to 0-255 (computer RGB levels) during playback.

    You can try using the Color Corrector plugin as John suggests for editing but bypass/remove it during render and compare the output video with the original footage.

  • Brandon Bias

    March 7, 2011 at 9:41 pm

    Alrighty then, thanks a lot for your help bro! Again, very helpful info.

  • Theo Van laar

    March 8, 2011 at 11:30 am

    “Re: Vegas Pro 10 Losing Color/Contrasting With .wmv Files
    by John Rofrano on Mar 7, 2011 at 12:51:22 pm

    [Brandon Bias] “To further clarify my problem, I looked at the pixels that are supposed to be 100% black and they turn out a very dark gray (approximate #101010, or RGB 16,16,16).”
    What you are seeing is the shift from Computer RGB to Studio RGB. If the file is rendered this way and you want to compensate for it, place the Sony Color Corrector plug-in with the Studio RGB to Computer RGB preset on the master video bus before you render. This will shift the values from the Studio RGB used by Vegas and the entire broadcast industry to Computer RGB used by the Internet and PC video.”

    Does this also apply for PAL? Or just for NTSC?

    Theo

  • Matt Crowley

    March 8, 2011 at 8:29 pm

    The terms PAL and NTSC really only apply to analog TV broadcasting, and the way the signals are modulated in the transmitter.

    When used in a digital video editing context they are usually taken to mean the frame size and frame rate that correspond to those used in analog broadcasts (720x576x25fps for PAL, 720x480x29.97fps for NTSC).

    Although there is a difference in the color formats for the analog systems, there is no color distinction for digital video editing.

  • David Esp

    May 25, 2011 at 5:10 pm

    As one would expect, and as in earlier versions of Vegas, WMV files are rendered over the (approximately) full (0..255) levels-range by Vegas 10. However Vegas 10 (only) reads/interprets WMV files as only over the range 16..235, hence producing a “washed-out” look. Earlier versions of Vegas instead read them back over the same 0..255 range that they were rendered at.

    Surely a bug.

    To demonstrate the cause of the issue (try it!):

    From both Vegas 9 and 10, create a project (e.g. 320×240) then insert Gradient (generated FX), and render to WMV. Then in both projects (9 & 10), insert both of the rendered WMV files in tracks below the generated FX. Finally, in each project: display the Waveform Monitor (WFM) with both of its property checkboxes clear, then use Track Solo to see each track in turn.

    In both Vegas 9 and 10, the generated media itself is shown by the WFM to cover the full “PC” luma levels range, between about 0 and 255. That’s consistent with what traditionally happens in Vegas.

    Now compare the WMV renders against this. In the case of Vegas 9, all tracks display about the same luma levels in the WFM. However in the case of Vegas 10 (sub-versions b or d, at least), both WMV tracks show luma levels linearly squeezed down into the Studio range, 16..235.

    This demonstrates that the levels-mapping error takes place only when Vegas 10 reads WMV files, not when it writes (renders) them.

    Consequence:

    Consequently, in Vegas 10 (but not earlier versions of Vegas), WMV tracks look washed-out. Sure one fix is to correct the levels by applying FX. But this kind of patching-up is ugly – the levels should be read correctly by Vegas 10 in the first place. It is also destructive – essentially the levels are getting remapped (with quantization noise) twice: once by Vegas 10’s WMV mal-read and again by the applied FX. If you kept doing it (multi-generation) you’d end up with a flat grey image.

    I have used WMV (and ASF) since 1998 and have used Vegas versions 7 to 10 for serious videography projects delivered in WMV (amongst others), so I’ve got a reasonable experience in this area, and only Version 10 of Vegas has this issue.

    The issue “bit” me when I tried to use Vegas 10’s waveform monitor for quality-checking the levels in my latest WMV. Now I know better, to only use earlier versions for that, at least until it’s fixed.

Page 1 of 2

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy