Oops sorry, I got confused with my printer's default gamma. Where I said 1.8 I meant to say 2.2. I would like to get photographic light style transitions and compositing.

But either way, are there noticeable benefit in switching the project to 32bit with 2.2 gamma for the final renders? I'm all at sea here.

Yep there can be benefits.

See this article:
Linear light processing in Vegas

I would stick with a 2.2 gamma project (things are much simpler that way). If you want want linear light dissolves, you could use the SMLuminance plugin for 2.2 gamma projects. It will work in both 8 and 32 bit projects.
If you want optically correct compositing, then I would just nest stuff into your Vegas project.

...sorry to revive an old thread. When I searched the forum this was the closest thread I found (actually...the only thread I found).

I'm reading Ron Brinkmann's "The Art and Science of Digital Compositing" 2nd Edition. Chapter 14 "Advanced and Related Topics" discusses video gamma in the context of non-linear color encoding.

After reading this information I have three questions:

1) Is there an online resource where I can look up the default gamma curves applied by various cameras? And does this vary based on the media/codecs used by a specific camera model?

2) Does Vegas automatically linearize video (i.e. reverse the capture gamma) before displaying it and performing color correction, layer composites, blurs, etc.? And is this limited to specific codecs? [I recognize that a separate gamma calibration is needed for my video card & LCD or NTSC monitor display. For now I just want to understand how gamma is handled from capture to Vegas.]

3) I'm learning node-based compositing in Blender. Does anybody know if Blender attempts to linearize video gamma by default? [Yes, I'll be asking this question on the BlenderArtists forum; but I thought one of the gurus here might know.]

1) Assume they're using 2.2, some use a so called 10bit "Log" curve which is thoroughly confusing when what then becomes linear in that jargon isn't really. The somewhat advanced cameras let you adjust the curve but you cannot represent that with a single number, you'll also find all manner of fancy names like Panalog etc.

2) Hard to know what it does internally, might leave that one for Glenn. It's certainly displaying it at 2.2, linear light looks aweful!

3) Can't answer that one, ask the Blender people. In general if anything is going to do something internally it'll do the inverse on output.

A great resource is here:
http://www.digitalpraxis.net/

"LUTs, Cubes & Curves" will give you plenty to chew on.

Bob.

Thanks Bob. That info helps a lot.

This book has been enlightening. The only real point of confusion is that one must figure out the internal workings of each software package used. [Ron mentions this several times.] It's a bit confusing to figure out how to 'test' my software when I'm still learning the concepts and terminology. ...not that the terminology is consistent anyway. :-)

I appreciate your help.
--
Mike

You might also find this:
http://library.creativecow.net/articles/oconnell_pete/cineon.php
enlightening (pun intended). Can't do that in Vegas as far as I can work out, even in AE you've got to know the trick.

What I think happens in Vegas in linear light is the 2.2 is converted to linear, compositing is done and then the result is converted back to 2.2 for output, all in FP precision. This doesn't gain you a huge amount as the best codecs I think Vegas will read are 10bit 2.2 gamma. To really gain anything major you'd need support for DPX or OpenEXR. Not to knock what we've gained, for run of the mill video getting proper 10bit support is a huge step forward and there are already a range of compositing tools available if you need them.

Bob.

Blender can work with DPX and [the subset] Cineon file formats. That's one of the formats that is given special mention in "Art & Science of Digital Compositing" [which I will henceforth refer to as "ASDC"]. Apparently DPX/Cineon [and the associated non-linear color coding] is slowly being replaced by 32-bit float OpenEXR [also supported by Blender for both import & and render/export].

That said, I still need to find out if Blender automatically linearizes data from these kinds of storage formats. Time to go bug the BlenderArtists forum folks...

Your description of the Vegas process sounds right, and it's what Ron recommends in ASDC: linearize, composite, convert back to non-linear as needed for final output format. However, I'm still running Vegas 6d, which I know is limited to 8-bit/channel color [no float]. The process may be the same; but in a non-float environment, it could often result in more data loss.

I was gonna hold out and wait for Vegas 9 to save money. [...also hoping for OpenEXR import/export.] But if I'm gonna use Vegas's layer-based compositing features to augment Blender's node-based compositing, then I need to have 32-bit float.

Thanks again for the input.

1) Is there an online resource where I can look up the default gamma curves applied by various cameras? And does this vary based on the media/codecs used by a specific camera model?
In 32-bit mode with a 1.000 compositing gamma, Vegas probably assumes that the source has a transfer function of 0.45. I don't believe Vegas has any log->lin conversion capability, though that would likely be fairly easy to do in a plugin.

2) Does Vegas automatically linearize video (i.e. reverse the capture gamma) before displaying it and performing color correction, layer composites, blurs, etc.?
It depends what mode you are in.

I suggest working in the way outlined in this article:
http://www.glennchan.info/articles/vegas/linlight/linlight.htm

I would generally avoid the 1.000 compositing gamma mode (it's explained in the article why I would do this).

---

Storage and processing are two different things.

On the processing side, Vegas is capable of 32-bit floating point precision and capable of linear light processing. If you setup Vegas to do linear light processing, there are some very noticeable changes in the image.

On the storage side, ideally you want your codec to not throw away precision (or throw away as little information as possible). Vegas is limited to 8-bit for most formats (Sony's 10-bit YUV codec is an exception). The differences here usually aren't visible/noticeable.

Thanks for all the info GlennChan. The pieces are starting to fit together now.

Some questions about your answers:

1) What do you mean by "transfer function"? Is this a process built into the codec, a gamma correction setting/value, or what?

2) Just so I understand, when you say "log>lin conversion" that is the same process that Ron calls "linearizing" in ASDC, correct? [My understanding is that gamma correction is based on a logarithmic function. ...right or wrong?]

3) Based on your "Linear Light Processing in Vegas 8" article, do I understand correctly that Vegas's VideoFX plugins are designed to work "correctly" with a compositing gamma of 2.222? Compensating behind the scenes [within a plugin] for video gamma would make sense, given that Vegas is primarily a video EDITING app, not a compositing app. But Ron explicitly cautioned: "In general, always linearize your images before manipulating or combining them" to avoid "undesireable, unpredictable or incorrect results". So I want to be extra clear on this.

Also, what happens if you import video source into Vegas that has already been linearized outside of Vegas? Do the VideoFX plugins produce unexpected results? Maybe this is what you addressed in method #2 in your article - "Manually convert values to linear light values before processing"; but I wasn't quite sure.

I'm almost certain that Blender's nodes do NOT compensate for gamma behind the scenes. So Ron's advice should be manually applied in that app. Best case scenario, I would like to set things up in Vegas & Blender so that color curves, blurs, and other FX/nodes operate essentially the same way with similar results in both apps.


As for storage, it seems to me that OpenEXR is the most straight-forward solution to storing linear 32-bit float 4:4:4 images. So I guess that Vegas will need to implement OpenEXR before we can take full advantage of all of the benefits that 32-bit, 4:4:4 RBG, linear-light, HDRI, etc. offer for compositing.

Transfer function is the function/formula used to map/convert/transfer the linear light signal into a coded signal (e.g. video signal).
(Ok, perhaps not the greatest explanation.)

Gamma correction is like the same thing... you can take a linear light signal and apply a transfer function to it to make a gamma-corrected signal... and then you can apply the opposite transfer function to convert it back to linear light.

2- There are different transfer functions. A "log" signal would be something that had a logarithmic function applied to it. Also note that there are different numbers used in these log formulas.

Linearizing would presumably mean converting a signal to linear light. (Though be careful that some other people refer to gamma-corrected signals as "linear"... even though it is not linear compared to light / doesn't have a 1:1 relationship with photons of light.)

Also, what happens if you import video source into Vegas that has already been linearized outside of Vegas?
It would look very "dark" and the results would probably look like crap. 8-bit is not sufficient to store linear light signals.

"Manually convert values to linear light values before processing"
Do this by adding a Levels FX filter and putting in... 2.222 under gamma (or 0.45, can't remember). You'll want to "sandwich" your FX with these levels FX on both sides.

Based on your "Linear Light Processing in Vegas 8" article, do I understand correctly that Vegas's VideoFX plugins are designed to work "correctly" with a compositing gamma of 2.222?
Hmm ok technically that isn't really true. Some plugins will deliver totally incorrect results in a 1.000 mode project, and all plugins will deliver reasonable though not necessarily correct results in a 2.222 project. In any case, not a big deal.