As one would expect, 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.
Surely a bug! Sorry if it has been reported here before (unknown - my search found nothing). But even if it has, it's so important it's worth highlighting.
To demonstrate the issue:
From both Vegas 9 and 10, create a project (e.g. 320x240) 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. Someone else noticed this - http://forums.creativecow.net/thread/24/925293 - where they were advised 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-Read and again by the applied FX. If you kept doing it (multi-generation) you'd end up with a flat grey image.
It sure wasted my time and held up delivery of a product to client (requiring WMV), because at first, when quality-checking it in a Vegas 10 review-project , I wasn't sure what was going on and thought I'd rendered the wrong levels. So I did experiments tonight (UK) and can next deliver to them in two days' time. Luckily not too embarrassing this time, but not good.
My workaround for levels-checking of WMV products (whether by WFM or by eye) is to use earlier Vegas versions instead. Maybe for editing also...
Surely a bug! Sorry if it has been reported here before (unknown - my search found nothing). But even if it has, it's so important it's worth highlighting.
To demonstrate the issue:
From both Vegas 9 and 10, create a project (e.g. 320x240) 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. Someone else noticed this - http://forums.creativecow.net/thread/24/925293 - where they were advised 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-Read and again by the applied FX. If you kept doing it (multi-generation) you'd end up with a flat grey image.
It sure wasted my time and held up delivery of a product to client (requiring WMV), because at first, when quality-checking it in a Vegas 10 review-project , I wasn't sure what was going on and thought I'd rendered the wrong levels. So I did experiments tonight (UK) and can next deliver to them in two days' time. Luckily not too embarrassing this time, but not good.
My workaround for levels-checking of WMV products (whether by WFM or by eye) is to use earlier Vegas versions instead. Maybe for editing also...