To try to simplify my answer...
A- There are different ways of implementing all your levels and color space conversions.

B- There is no quality advantage and there is no quality disadvantage.

C- In terms of speed, it is debatable whether this system is faster.
If you're after real-time previews, you are stuck with 2 poor choices: Work in 32-bit, which is slow. Work in 8-bit, which has the wrong levels and therefore you're looking at the wrong color.

D- With more development time, the Vegas team could probably implement automatic color space conversions and more options to make this less confusing. e.g. DV should behave like HDV, SonyYUV, MPEG2.

You could also ask for features that would enable you to do previews in 8-bit that look similar to what your 32-bit results would be (e.g. no dramatic color shift when you flip between 8-bit and 32-bit). There could be a mode where the codecs don't change behaviour between 8-bit and 32-bit.

As for filters and transitions, I think that they should always receive gamma-corrected values. Why? I think that it's confusing that the "studio RGB to computer RGB" presets don't do what they say they do in 32-bit/1.000 compositing gamma. That's unintuitive. Also, the onus should be on the filter to do linear light processing if necessary. Not all FX benefit from linear light processing (e.g. color corrector, broadcast safe). For blurs and such, the filter should convert to linear light internally, do its thing, and then convert back to gamma corrected.

small point, here, but a niggle nevertheless....
Thanks for catching that... typo.

Yes, I would agree except that it's rather negligent to leave the Mainconcept MPEG2 codec functioning in studio RGB without very clear instructions to users about how to work around this glitch until it gets corrected, particularly since the MC codec is the path to the only currently distributable DVD format.
In my tests, the Mainconcept MPEG2 encoder behaves like the HDV and sonyYUV codecs. It moves in step with this codecs...
In 8-bit it decodes to and expects/wants to see studio RGB levels.
In 32-bit it decodes to and expects/wants to see computer RGB levels.

Thanks for the answers,
so to get back to the very original question, it's not a bug. Stay in 32 bit the whole way through the pipeline and all is well. If you mix source formats in the one project, know what you're dealing with and handle accordingly, nothing new there really either, that requirement has always been with us.
Perhaps the way Vegas lets us very easily change project settings make it a bit easier to get confused than say how PPro seems to lock you in, for a long time there's sort of been the general idea that project setting in Vegas don't really matter even though in subtle ways they always have. I suspect going forward that thinking will need to change.
The issue of monitoring when working in 32 bit should be easily addressed, Vegas has always had the ability to add a FX into just the monitor chain. I haven't tried this but I'd assume adding the Levels FX into the preview window would address the problem for those using the traditional firewire to CRT monitoring method.

Bob.

farss wrote:
"Stay in 32 bit the whole way through the pipeline and all is well."
Not necessarily so, Bob. If you're working with Mainconcept, yes. If you're going out to WMV and intend to display on an NTSC monitor(e.g.via DVD), then you'll need to convert to studio RGB before you render, since WMV outputs whatever is input without remapping.

You should probably be sending computer RGB levels to WMV? (For most applications anyways.)

Stay in 32 bit the whole way through the pipeline and all is well. If you mix source formats in the one project
Yep. (But the performance in 32-bit is not as good as 8-bit... I'd prefer to preview a lot of stuff in 8-bit.)

So Glenn..

If I send computer RGB to WMV, I get computer RGB out.Now, I burn this to a SD- DVD and play hi-def on a AvelPlayer, which will decode WMV. (The only viable HD available to most people these days) Now, what happens to the color mapping when displayed on both NTSC SD and hi def monitor?

Now, what happens to the color mapping when displayed on both NTSC SD and hi def monitor?
It depends on the signal chain. There might be multiple conversions going on there.

But generally speaking you should encode WMVs with computer RGB levels, assuming that everything else in the chain will do things correctly.

The link at the end of this post is to a simple informative video tutorial explaining further about 32-bit, in particular that it preserves values below 0 and above 1, and why this is so useful (hence why it is also useful to preserve broadcast-illegal values from a camcorder etc, apart from avoiding compression of representation-space).

Having seen the video tutorial, I take "below 0" to imply that 0 doesn't mean "no light" it's just a reference-threshold, which in the case of an arbitrarily exposed image is an arbitrary threshold in terms of real-world meaning. It's not intuitively obvious to me why any subzero-preserving FX algorithms (the only kind that would preserve this benefit of 32-bit space) would need this threshold to be at any particular level. Only at the Render or Preview stage do the levels finally get mapped to black and white absolutes (broadcast-legal or broadcast-illegal, according to preference).

The video at the link below also shows the AE Preview being switched between 8 and 32 bit without any contrast change effect. I would guess that in general (for any editor), the appearance (in Preview and Render) does not need to be limited to an exact copy of the representation space - and for the reasons stated earlier ("subzero" etc), not all 32-bit values can be faithfully depicted (in Preview and Render) in any case, so why not map them to something consistent?

Ideally, to please all people, there should perhaps be a big Studio/PC switch in Tools>Options overridden by Project Settings overridden by Render. Then we could have the best of both worlds.

The promised link:

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=564839&Replies=2

which links to:

http://movielibrary.lynda.com/html/player/?id={8880019E-0549-4D08-BCFF-24BA57BAC6D0}

Bill,

You put the compression/requantization issue very succinctly. Along with information loss (clipping), that issue has always nagged me. Ideally, whatever the processing bitspace, there ought to be a Project Setting or Media Setting etc. to allow the user to determine how each source should be interpreted and what kind of space is required (depending on the envisaged display device).

Ideally, whatever the processing bitspace, there ought to be a Project Setting or Media Setting etc. to allow the user to determine how each source should be interpreted and what kind of space is required (depending on the envisaged display device).
Something like that would be nice.

Glen,

You say you repeated the test and obtained the same results. That is reassuring. I accept that the interpretation requires some careful thought, which I will address, including reading again your pages. It will take time!

In the meantime, to hopefully remove a doubt cast earlier by some, would you also agree that the Vegas WFM scope, while not as refined as a calibrated monitor, is sufficently accurate to confirm that my benchmark example covers or at least approximates the full Computer range of values (0..255) as opposed to the Studio range (16..235)? Good enough to distinguish between them I mean, as opposed to exact gamut differences etc.

Behind this question is not the interpretation or correctness of what happens in Vegas but to establish some test instruments sufficient in quality for performing certain kinds of "rough" (but, within their limits, reliable) science to prove (or disprove) and illustrate the "big picture" of what is happening in Vegas. Regardless of arguments about right/wrong etc, just to see what "is", sufficient to understand more clearly the broad issue about what Vegas and its FX etc. do with different kinds of level ranges.

The goal: reduction in confusion through sufficient (acceptably imperfect) instrumentation that anyone can apply.

I have found the combination of this benchmark and Vegas WFM extremely useful to illustrating exactly what the various Levels FX (Broadcast Levels, Auto Levels etc) and their adjustments do.

So, assuming we're not mixing sources (I'm working solely with HDV and in the near future, the 35Mbps XDCAM EX), sticking to the 32bit pipeline should be ideal, right?

Now, two things that should probably go to the 8.0b wishlist would be:

1. Optimize 32bit rendering so that it can use 100% of a Quad CPU resources. As of now, the 32bit rendering is much more time consuming than 8bit not just because there is simply much more number crunching to be done, but also because the CPU usage hardly ever exceeds 40-50% on my QX6700

2. Optimize preview fps in 32bit, or at least provide an option to preview in 8bit while keeping the 32bit workflow.

Do you agree, or am I missing something?

Aha, it seems that in 32-bit space, "clipped" levels can indeed be recovered. So it's not just for avoiding banding artefacts then.

I imported my m2t full (illegal) range ramp benchmark, set Project to 32-bit (gamma 1.0) and as before the Vegas WFM showed it it clipped at the top and bottom of the range. Then I applied Sony Levels FX as an Event FX, and by experimentation found that setting Output Start to 0.017 and Output End to 0.821 (other settings default) had the effect of "un-clipping" i.e. avoiding the clipping, the 32-bit representation having preserved the pre-clip levels.

Can anyone calculate what precisely these values should be in principle? I guessed 16/255=0.06 and (235-16)/255=0.86 which obviously don't quite match. And in this context I do accept that the Vegas WFM is not likely to be a good basis for determining the correct levels to decimal point accuracy.

I found HD test media, including 1-254 steps and ramps, at http://www.w6rz.net.

I downloaded the .iso file, burnt a CD, extracted the .EVO file, confirmed via GSpot that it was Mpeg2, renamed it as .mpg and dragged it to the Vegas timeline.

Once there, I viewed it in WFM. Its 1..254 Ramp test image gave a WFM plot consistent with my m2t benchmark file. The only difference was that it included steps superimposed on the ramp and that it went in both directions (right<->left), giving a dual ramp (i.e. an X) plot.

This bears out the Vegas-7 generated benchmark.

OK now I understand more about 32-bit, the suggestions given towards the beginning of this thread, about using Level FX, finally make sense. The information is not lost, and LevelsFX indeed recovers it like you said. Sorry I misconstrued.

BUT, applying a ramp test and looking at the Vegas WFM, its clear that for HDV (m2t) in 32-bit mode, the preset "Computer to Studio", which maps (0..1) input to (0.063..0.922) output, only works as expected (restoring the full linear ramp) when the 32-bit gamma mode is 2.222.

When 32-bit gamma mode is 1.0 (linear), this preset does not give the right result. Instead, as I report in a separate reply elsewhere in this topic, the mapping has to be set to something more like (0..1) input to (0.017..0.821) output. The difference is so gross that any small errors in the WFM are immaterial.

The above behaviours can be demonstrated by using my Vegas-7 generated m2t ramp benchmark (described in the very first post) or, equivalently, a test image such as the 1..254 ramps in W6RZ's collection (http://www.w6rz.net).

Filters behave differently with a compositing gamma of 1.000. I point this out in my articles I believe.

The Vegas 6 info in my article is correct as far as I know. I checked the recorded bars against real hardware scopes.
From there I can figure out how to calibrate my monitor correct and be able to generate test patterns that will show differences in levels. e.g. Suppose you have correct color bars sent to your monitor, and calibrate it. If you send incorrect color bars to the monitor (with black level too high or low), then you'll be able to tell from the PLUGE bars whether the black level is too high/low.
From there you can figure out 32-bit.

If you're interested in making correct output for computer formats like still images, WMV, etc. then you can just output that type of file and open it in a known-good media player. There are ways to check those levels.

I've gotten in the habit of always including colorbars and pluge in every rendering I do, just to be sure I haven't clipped somewhere in the path. When all is finished, it doesn't take much to trim the colorbars off. I've caught a few "errors" in mapping that way with several codecs I don't use much.

Finally found some time to do a simple test. All values in Studio RGB.

Track 2 grad 0 to 100IRE
Track 1 white at 100IRE.
Track compositing mode Add.
Apply Levels FX to Video Bus.

In 8 bit mode my grad is toast. Turn the Output End down on the levels filter and all I get is gray.

Switch to 32 bit Gamma 2.222. Turning the output end down in the levels FX I can get back some of my grad.

Conclusion in 8 bit mode 1+1 = 1, in 32 bit 1+1 = 1.2 (roughly). Pretty much the same as what the AE tut was sayin should happen.
Switching to gamma =1 was interesting, can't quite determine whats happening there. The scopes indicate that the gamma is wrong, at first I thought I was getting true linear light output but using the levels FX to straighten the curve back using gamma = 2.222 didn't quite do it. Need to experiment some more.

One things I've learned from reading all this and then some and listening to the guys from the pointy end. There's really only one way to know where you are. Feed the output down a SMPTE standard interface into an external monitor that's calibrated to that standard, preferably one with scopes. Then record from that same interface to tape. Doing that for HD is expensive and I used to think this a nuts idea. Why interpose all the expensive hardware between the bits in my PC and the monitor. I think I now know why.

Bob.

Poor man's solution:
I keep a Sign Video proc amp in the line to my external monitor. The proc amp has an LED histogram to monitor IRE level.

Bob, I think the math goes like this:

8-bit:
1+1 = 2. Clipping occurs at 255 and 0.
If you add solid colors and look at their resulting value (with add compositing mode), that is what I see.

32-bit, 2.222:
Same as above except no clipping.

32-bit, 1.000:
All values get converted to linear light, assuming a power function of 1/0.45 (or 2.222... not sure; 1/0.45 = 2.222222222222222222222222repeating). The range gets converted from 0-255 to 0-1.

Then the math gets applied.

Then the values get converted back to gamma corrected domain.

So...

The answer = ( (1/255)^0.45 + (1/255)^0.45 )^1/0.45

2- If you really look into it, the rounding might be weird depending on what rounding mode the processor is set to (truncate, round to even number if .5, and a bunch of other modes) and due to floating point rounding errors. The latter might be different between SSE2 instructions and FPU math on x86... I'm not sure there.

I haven't figured out exactly what Vegas does in this regard. In practice, I don't think you really ever need to figure this out.

3- In 32-bit / 1.000 mode:

Your values get converted to linear light values with a range of 0.0 - 1.0 right off the bat.
Then mediaFX, event FX, pan/Crop, event FX (default), track FX+motion, etc. get applied. *Things are different if FX or transitions only accept 8-bit input.
Then the values are converted back to gamma-corrected values.

Because the values are converted to linear light before going into FX, FX may give very different results. IMO this is confusing and therefore not desirable... e.g. some filter presets don't do what they say.

Thanks Glenn,
I wasn't initially trying to be too scientific. Just wanted to see if it worked the same in Vegas as it was shown to work in AE in the referenced AE tutorial and it does.

I'm not certain about gamma = 1.00, from what you're saying it should all come out OK in the end but that's not what I saw however I had the levels FX in the chain on the video buss so that could be where the problem was. What I saw come out in 32bit gamma = 2.22 was still a linear slope. Switching to gamma = 1.00 I got a curve.

Bob.