Gamma v.s. more light?

[playmesumch00ns]

You should ALWAYS render with all your input colour data in linear and then gamma appropriately for your output display (normal 2.2).

inputting linear colour data means applying an inverse gamma to your textures. Some renderers, like mental ray, support doing this automatically, tho I'm not sure about how you would go about it in gelato.

Ideally you should do this process in the shader, since once you've applied the transform to linear you'll want to have your image data in floating point, and if those textures are hanging around on disk you'll find your hdd filling up pretty quickly.

EDIT: If you're using Maya's hypergraph to build your shaders and mango supports the gamma correct node you could use that with a gamma of 0.455 in each channel to do the conversion. Otherwise you could use gelato's shading-chaining, although that would mean writing a shader that would do the conversion for you.

[billrobertson42]

I understand a little bit of what you're saying. I guess my problem is that I don't really understand what gamma is. So I'll go look for that. If anybody happens to have a good link I'd appreciate it.

Thanks

[playmesumch00ns]

I'm going to try and get something on the wiki about this. I've already put a stub there, just got to fill it in :)

For various vagaries of technology, in order to display colours properly (by "properly" I mean in a way that they look 'right' to the human eye) on a computer monitor you need to "gamma them up". For most monitors this means doing:

displayColour = pow( linearColour, 1.0 / gamma );


where pow() is the function that raises its first argument to the power of its second argument. Basically, a gamma greater than 1 will make the image brighter and more washed out, while a gamma less than one will make the image darker on more saturated.

So any image you create by a 3d render should also be gamma'd up. This is just something you should always do when you're generating linear data. Decay on lights, for instance, will look wrong if you don't gamma the image up. The funny thing is that many people have been doing it wrong for so long, they think the way light decay looks when gamma'd up is incorrect...

Now the tricky part comes with your input data. Remember that everything has to be gamma'd up to look right when displayed on a computer monitor? That means that everything that "looks right" on a monitor has an emebedded gamma curve, whether you explicitly gave it one or not. Just by painting something that looks pleasing to your eye in photoshop you're embedding that gamma in the image.

So if you render with a texture that you've painted (or donwloaded off the internet), then gamma the render, your texture will effectively have two gamma transforms applied, and will look overbright and washed out. So in order to get it to look correct you need to apply and inverse gamma to the texture data.

"So why all this jazz? I was able to render perfectly well before by just ignoring this gamma stuff and things came out looking ok", you might say. Well this is the right way to do it. Why? Because light behaves linearly. In order for lighting calculations to look correct you must feed them linear data, not data with an embedded gamma curve. Then in order to view the resulting images properly you need to view them with the proper gamma for your monitor (probably 2.2).

When you start working in this way you might find it a bit of a pain, and things won't look quite the way you expect. However once you get past this and get used to it, you'll start to notice just how much more natural your lighting looks than it did before, even just with a single light in your scene. That's because you're doing your lighting calulations according to the way it works in the real world, and looking at the result appropriately for your viewing device.

[billrobertson42]

I think what you're saying then, is in the rendering, build in correction for the gamma that you need to apply later.

Correct?

[Aneks]

Nice respsonse Playmesumchoons. It seems you are suggesting that all textures etc are run through a gamma .454 (ie negate 2.2 gamma) in order to bring source material such as textures) into what compositors refer to as a 'linear-to-light' (or linear) colour space. As a compositor I am interested in this process in a film pipeline where you are passing off 3d to be composited into scanned film plates (log) which I assume will be comped in a 'linear-to-light" colour space. Prior to linearFloat (LFP), via somehing like .exr, I was so used to doing gamma .454's on 3d source in order to unify elements I have 'de-loged'.

how does is this adressed by compositors at your facility ?!

[playmesumch00ns]

billrobertson42: Yes, that's exactly what I'm saying :)

Aneks: I won't go into how we used to do things :) Our current pipeline is to comp everything in linear (by that I mean true linear, as opposed to the "not log" sense that some people understand it to mean). All our 3d is rendered in linear, so all textures are pre-converted from sRGB (i.e. gamma 2.2) in the shader. To make things slightly more confusing, all our texture artists use a lookup while they are painting to show them what the end result will look like on film, so that if we rendered their texture on a flat-shaded plane, comped it, converted to log, then viewed it on a film screen, it would look exactly the same as it did in photoshop on their monitor.

Of course, it's not precise because of the lack of support for 3d luts almost everywhere, but it's very close indeed, and the workflow is pretty good (except in certain cases).

[billrobertson42]

Seeing as how I can barely figure out how to light a scene, I don't think I will be able to put this to use yet. However, I find the information extremely interesting.

Thanks! :bowdown:

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.