Quote - i'm probably not thinking about this right, but that sounds kind of needlessly complex. i mean, it's not just the colors you're anti-correcting in your lights.  it's their luminance, too. 

Yes that's true and it's also the right thing to do. Suppose you photograph (with a mirror ball) walls and a ceiling and the ceiling is RGB(240, 240, 240) and twice the luminance of the walls. Do you think the walls are RGB(120, 120, 120) in the photo? Because they won't be. In the photo, which is sRGB corrected, those half-bright walls will be RGB(175, 175, 175). In sRGB color space, 175 is half of 240. If you use that for lighting, the amount of light from the walls will be stronger than it is supposed to be, and your IBL will have incorrect ratios of lighting from above versus from the sides. If you anti-GC that image, the ceiling will become 223 and the walls become 111.  This is why IBL lighting seems to lack contrast. The ratio of 240/175 is only 1.37, but the lighting ratio is supposed to be 2. That's a huge difference. Huge.

Similarly, if we were looking at a wall color where the amount of red is 240 and the green and blue is 175, that represents a saturation ratio of 2 in linear color space, but converted to sRGB the ratio is only 1.37. That means the light from that area is not as red as it should be, because you're using an sRGB value as if it were a linear value, and that means the luminance is wrong and the hue is wrong and the saturation is wrong.

Perhaps you're not aware how lighting works. Given any point on a surface, a loop is performed. For each light, the loop calculates an effective RGB value for that light source, regardless of whether it is IBL or spotlight or infinite or point. Each of those uses a different technique for finding that value, but it's a simple lookup and a little math. Based on angles, the color you entered (or came from the photo in an IBL) and the intensity multiplier, this value for illumination is arrived at by linear multiplication of several factors. In the case of an infinite light, one of the factors is the cosine of the angle between the normal and the light vector. At 0 degrees (straight into the surface) a light will deliver its full intensity. At all other angles, the fraction will be less than 1. At 60 degrees it is exactly half. In any case, if we let that value be called L, then the calculated linear diffuse color of the surface is Diffuse_Color * Diffuse_Value * L. I'll shorten that to C for Diffuse_Color and V for Diffuse_Value, so the product is C * V * L.

Now think about what happens if  you're doing that multiplication, but L is an sRGB value, not a linear value. You're multiplying apples and oranges now. Gamma correcting that will result in the product of those things raised to the 1/2.2 power.

(C * V * L ) ^ (1/2.2)

re-arranging we get:

(C * V) ^ (1/2.2) * (L ^ (1/2.2)).

But remember that L is already gamma corrected, which means you're gamma correcting L without first having anti-gamma corrected it. This results in double gamma correction. The net effect is too much light, undersaturated, and with the wrong hue.

Quote - which means you're anti-correcting the light to be darker, then applying anti-correction to the surface input to make it darker, then correcting the surface to make it lighter. 

Sorry but that is the math. It's a simple result of this rule for exponentation.

(AB)^P = (A^P) * (B^P)

The power of a product is the product of the powers.

This means that if you're going to gamma correct a product, you have to anti-gamma correct each factor in that product.

Quote - i mean, you could try to do something with then correcting the light's color, but then you're back making the color wrong.  so you'd have to do something wacky with the lights to correct the color but keep the luminance.

No you're not making the color wrong. It was wrong to begin with. The colors in a photograph look right, but the numbers the photo contains are not linear values. It is wrong to use them as if they were linear. The results will be wrong.

Quote - it seems more sensible just to keep the lights in correct plain colors/photos.  i mean, an IBL doesn't have any other calculations it's making about it's colors and luminance, right?

Actually it has a huge calculation right at the start. It does a calculation called convolution. This calculation is to pre-calculate the value of L for every possible direction a surface could be facing. When you do this calculation with sRGB values, you're getting nonsense. That calculation has to be done with linear values. Otherwise, you're adding things together that are not representing the true RGB values as numbers. The resulting sum is way off.

Quote -
and the other types of lights are pretty much the same, right?  no transforms within the base?  like, i could see needing to correct the inverse square falloff output, but that's just luminance.

No it isn't just luminance. Each value of the original color drops by an equal ratio for any given distance. But if you calculate a ratio of the starting color based on the sRGB values, then the saturation changes as you move farther from the light. If the light is gray, no big deal. But if the light actually has a visible hue, then the inverse square falloff calculates completely wrong colors as you get farther and farther from the light. Also, as I said earlier, even an infinite light modulates the illumination color L with the angle to the light. So at 60 degrees, the value of L should be half what it was at 90 degrees. And the components within L should keep their same ratios. If you start with an sRGB color and you vary the luminance with viewing angle, or distance, or anything at all that represents lighting, then there is a multiplication involved, and the only sensible way to do it is with linear values.

Quote - and what you do with the GenIBL might explain the problems i had when using Synthetic's iterative rendering techniques with your GenIBL.  i kept having to tweak the image to make it brighter, and couldn't figure out why i was loosing so much luminance with each iteration.  now i know.

I'm not sure what you did, but there are many other ways you could end up with it getting darker on each iteration. Also, that technique is of very limited use. It is not an accurate substitute for GI. When you have four walls, ceiling, and floor, with one point light inside, you calculate an IBL value for the ceiling area. Now that gets used for the entire floor, not just the center or the corner, but the entire floor, because all of the floor is pointing straight up. IBL only produces graduated lighting for curved things. For large flat things, it's completely and totally incorrect, meaningless gobbledygook.

Quote - it's much simpler just to keep the hue and saturation shift out of the shader, and use your technique to affect only the luminance.  is there any reason this would be less accurate?  is there a hue and saturation shift i actually want to preserve?

All of the above.

---

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)