Sigh. The images you bring into the renderer, those that are going into the shader, such as a texture of blue jeans, are in sRGB color space, to begin with. This means they are already NOT linear. Given the true value of a color is x, the value in the image is x ^ (1/g). That is to say, they are gamma corrected, so that when you look at them on the monitor, you see x.

This is, for the thousandth time, because the monitor has a gamma of g. It's not subjective, except to the extent that the monitor is incorrectly calibrated. But regardless of minor calibration details, the gamma of a monitor is nowhere near 1. It may be 2.1 or 2.3, and somebody hand-painting a texture may skew the numbers a little, but not by much. And photographic material is gamma = 2.2, no subjectivity allowed.

Your picture, when viewed, which consists of x ^ (1/g) values, is then

(x ^ (1/g)) ^ g

is the same as

x ^ (1/g * g)

which is

x ^ (g/g)

and that is

x ^ 1

which is

x <<<<< It's just x - got it?

The result is the actual desired value, x, is what comes shooting out of your screen pixel.

When we want to use the colors found in these textures for rendering, we want x, not x ^ (1/g). But x ^ (1/g) is what is in the file. That's how they are written. They are gamma corrected images. It's not complicated.

So you do want to anti-gamma correct the incoming material, so that the number you use is x, the actual luminance value.

That means you take the incoming texture and do the same as a monitor would before you use it.

x ^ (1/g) ^ g = x

Then you do things like adding, multiplying, blending (which is multiplying and adding) and so on.

Then you get the final value and you gamma correct it, preparing to encode it for display.

The math then is simply this:

Given two gamma correct images, recorded in sRGB color space, the actual luminance values being called t1 and t2, the values recorded in the files are t1 ^ (1/g) and t2 ^ (1/g).

If you add these together, you do not get (t1 + t2) ^ (1/g), which is what should be in the rendered file. Instead you get

t1 ^ (1/g) + t2 ^ (1/g)

If you enable Poser GC, you get

(t1 ^ (1/g) ^ g + t2 ^ (1/g) ^ g) ^ (1/g)

Recall that x ^ (1/g) ^ g = x

Therefore the inner part collapses and you have:

(t1 + t2) ^ (1/g)

This is what you're supposed to have in the rendered file to represent the sum of the two textures in such a way that when shown on your screen, it looks exactly like t1 + t2.

Of course nobody will understand this because Kawecki started with the premise that the math is absolute, but gave the wrong math, and once again I'm fighting an uphill battle. The math is simple, but Kawecki gets it backwards. He's like a guy looking through the wrong end of a telescope and telling everybody that it's broken and does not magnify things.

Quote - But math are not subjective and t1^g + t2^g is not the same as (t1 + t2)^g where g is not 1.0

That's correct that t1^g + t2^g != (t1 + t2)^g. But it's no more relevant than proclaiming that 3 + 4 != 11.

The incoming texture data is not t1, it's t1^(1/g). And the correct outgoing value is not (t1 + t2)^g, it is (t1 + t2)^(1/g).

The inputs are not linear. Summing the non-linear values is not desirable. And, like looking into the wrong end of the telescope, the final gamma correction is (1/g), not g.

---

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)