Mike...

If you REALLY want to warp your mind...
now try the same analysis and apply studio to computer Levels FX and visa versa.

Bob: I know what it does, that's what my test was demonstrating. My question was why the gamma change?

Bill: I found you can not go back and forth and expect each conversion to cancel out. You need to remove all FX and start again; that in its self is weird.

Some solutions:

1- Use a compositing gamma of 2.222.

2- Make new presets to get the same end result. (I believe this is possible, but haven't checked.)

3- "Sandwich" your Levels filter with other Levels filters to convert back to gamma-corrected color space.

So:
Levels filter with gamma of 2.222
Any FX here
Levels filter with gamma of 0.45

I've already written about this stuff here:
http://glennchan.info/articles/vegas/v8color/v8color.htm

A more pressing question given the nature of what's going on is if there's any color shifts. Everyone seems to be sweating over luma values, they're easy enough to wrangle, what no one is talking about or testing is what's happening to the chroma values.

Bob.

Mike...


another way of applying the LEVELS FX is to use the ColorCurve FX. By moving the endpoints of the gamma correction curve, you can duplicate the result. Be careful not to leave a "bend" in the correction curve....ie, keep it a straight line. Notice that, in effect, you've "rotated" the line. The net effect will change the colors (on an NTSC bar pattern)between the endpoints so they no longer align with the reference marks in the WFM or vectorscope.

Everyone seems to be sweating over luma values, they're easy enough to wrangle, what no one is talking about or testing is what's happening to the chroma values.
It shouldn't be an issue here... the Levels FX affects both luma and chroma (or, to look at it another way, it doesn't do transformations in Y'CbCr color space). So either luma and chroma are both right or they're both wrong.

It's not like one will be correct and the other incorrect.

Sounds reasonable. Thanks. Just worry about all these non linear transformations going on.

Bob.

I just dropped both sets of values into a Excel spreadsheet and plotted them in the one graph. I don't see any gamma change.

If there was a gamma error I'd expect to see a change in slope or more to the point a curve in one graph and a straight line in the other.

A better test would be a linear gradient.

Bob.

You see those "strange" result when working in 32bit and linear and not video mode.
I think the problem is in the scope. The scope is displaying the video output result. In Linear mode, Vegas add 2.2 Gamma for the display - so that the display is correct. You can switch between linear and video mode - and, with no effects, the display will remain the same.

The input file is gamma corrected, so vegas remove the 2.2 gamma, and store this value, when displaying it - it adds 2.2 gamma and the result is as expected (16 luma is shown as 6%)

When you convert to studio rgb - the 0 value is converted to 6% (in the internal store) and when adding 2.2 gamma for the display - theresult is 21%. Although the internal representation is 6%.

The value of 16 is 6%, and removing the 2.2 gamma - is less than 1% (the internal representation before fx).
This is converted to studio - about 7% in the internal store
and you see it in the scope after adding the 2.2 gamma - as 24%.

All shold be OK in the video (2.2 gamma) mode.

You should "apply" 0.45 gamma to the scope result in linear mode.
Maybe Sony can add this feature to the scope?

Udi

A good clear responce Udi. Thanks.

You should "apply" 0.45 gamma to the scope result in linear mode.
It already does.

What's happening is that the actual output of the filter is different.

Suppose your filter applies the function Filter(x) = constant * x + offset

In Compositing gamma of 1.000, the end result is:

F(x) = ( constant * x ^ (1/0.45) + offset ) ^ 0.45

This is why the filters are producing different output. And the scopes reflect that. The scopes are monitoring a gamma-corrected signal.

---

Solution to the original poster's problem are outlined in my first post here. The simplest solution is to use a project with compositing gamma of 2.222.

Glenn,

You mean that all F(x) are adding the 2.2 gama, applying the fx and removing the 2.2 gamma.
I assume that some filters don't do that.

The question is how is x displayed, in my understanding the displayed requires a 2.2 gamma - so vegas correct the value and the x^0.45 is send to the display. This is the value that the scope show. I like to see the x value in the scope, or better - the option to select which value I see.

Udi

You mean that all F(x) are adding the 2.2 gama, applying the fx and removing the 2.2 gamma.

The signal path is:
Gamma correction removed
first FX/filter
second FX
third FX, etc.
Gamma correction added back in

The FX themselves don't do the work of removing and adding gamma correction... it's Vegas doing those operations. (FX could apply + remove gamma correction though... the 3rd party SMLuminance transition presumably does this.)

The question is how is x displayed, in my understanding the displayed requires a 2.2 gamma - so vegas correct the value and the x^0.45 is send to the display. This is the value that the scope show. I like to see the x value in the scope, or better - the option to select which value I see.
Ah.

Photoshop and AE do something like that in that the eyedropper lets you see the floating point values (which may be in the linear light domain). It's somewhat useful for understanding what's going on and understanding HDR concepts. So you could make an argument for something like that in Vegas.

I personally couldn't picture myself using scopes that viewed linear light values... I can't picture how that would be useful to me. (But that's my personal bias!)

Thanks Glenn,

If the filters are all working on the same "gamma" - and Vegas is doing all the required conversions - than it should not matter if you are working in 1 or 2.2. All will be converted to the "correct" level before the fx and restore to the "internal" value. I think that some FX are working on the raw data and not on the converted one, those are the one that behave differenty in 1.

I agree that in most case you should work with the visualy corrected scope. But the ability to see the result "as is" without the gamma correction can explain the behaviour of the syetm, as well as the original thread issues.

It might help Bill Ravens with his issue as well???

Thanks again

Udi