USMale,

You got the 2.2 versus 1/2.2 backwards, and you need Color_Math, not Math.

You take the incoming image and raise it to the 2.2 Power. (This darkens it so it is no longer compensated for your monitor.)

I know that sounds strange - raising to 2.2 darkens? But think about it. Brightness is expressed in terms of  fractions, with 1.0 being the brightest possible thing you can see in a monitor.

So what is .5 ** 2.2? Bigger (brighter) or smaller (darker)? You got it - smaller and darker.

So image/color coming in - raise to 2.2 power.

Do your lighting and other shader voodoo.

Then image out, raise to the 1/2.2 power.

I tend to put the 2.2 in its own math node. I then hook up Color_Math:Pow nodes to that value, and also to a Math:Div node to make 1 over that value (the inverse).

The question of what to do with displacement actually has some terribly complicated "what if it was made like this? what if I did that first" questions that affect the answer. But the basic answer is, no you don't gamma correct those. Such images are not images in the true sense. They are data. A displacement map is a gigantic two-dimensional array of numbers. These numbers happen to be stored in an "Image" but it isn't an image and it is very unlikely that gamma correction ever took place on that data on its way to being stored. For example, a ZBrush-generated displacement map would already be linear.

On the other hand (here's where it not only gets complicated, but also stupid) you get people making displacement/bump maps out of their color textures. In my opinion, you don't need to ask if you should gamma correct those - you should just throw those away. They are garbage.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)