I'd not be surprised if there were some more inconsistencies in Poser Pro's gamma handling. Eg. OpenExr Background images are not anti GCed when using GC render settings for them, while other file formats are... (Or maybe it's less of an inconsistency when reading them rather than writing the Gamma Corrected image data to the OpenExr image rather than the linear output...)

According to the specifications, OpenExr images are already linear, not sRGB. They do not need to be converted via anti-gamma correction to linear values because they already are. That's why Poser Pro sets the incoming gamma on those to 1 by default.

But if I understand you, you're saying it writes sRGB values in that format? I thought it did not. I thought it wrote linear values. (uncorrected)

Note that previewing the image shows it gamma corrected in the UI. But my understanding is that what is written is not what you see, if you save to OpenEXR format and you remembered to choose the render settings for (if I remember it right) HDR Optimiized output.

Quote - Regarding the VSS sliders, while I want to do such a thing, it doesn't change the ease of use.

In my VSS skin shader there are numbers for various control parameters. For example, there is PM:Shine. If you increase that, it's more shiny. A slider doesn't make that any more or less clear. And this doesn't involve math. How I built it involves math. How you use it is simple. You want it more shiny? Increase PM:Shine.

You want more SSS? Increase PM:SSS. Less SSS? Decrease it. It's not math. It's a numerical value, but it's not math. A slider also represents a numerical value.

Agreed. Using a slider or a numerical input make no difference to the effect. Some form of 'control panel' can help human beings to stay within the feasible input parameter space.

Naming inputs (PM:Shine for example) is a step forward. I have not yet been able to locate them in the shaders I generated with VSS. In my case all nodes there have generic names. Probably I did something wrong when setting them up. The good thing is that inputs are named in terms of the effect on the result. Again taking PhotoShop as an example. If I add a lightness&contrast correction layer, I have an input thingy to control lightess and one to control contrast. I have no idea what mathematical majick is triggered deep inside, but it allows me to decide which control to fiddle and in which direction, and then see if I like the result. In this way, I can concentrate on the scene and leave the math for what it is. 
I have a master's degree in engineering, and engineering calculus is my daily work. I have no fear for it but if I can make my life easy, especially after hours when poser-ing I do not turn away from it. 

Quote - ...I suspect that the reason results are different has more to do with IBL images being anti-GC'd when you enable render GC, and the user is unaware of this.

If you are, for example, using one of my linearized IBL images, made using my GenIBL tool, :scared: then that image is already linear when used in Poser 7 or 8. But if you plug that into Poser Pro with render GC enabled, Poser will anti-gamma that image, and it should not because you're using a linear encoded image already...

Oh! And here I was linearising the GenIBL image prior to use. Duh. Why don't I read stuff more carefully!! I'm quite certain that was the reason I'm getting the results I'm getting. No image I render these days is made without IBL and no IBL is without a GenIBL probe.

So, Starting Over. Thank you, Bill... that answered my question.

And my apologies, Dizzi... I really didn't explain my methods clearly or thoroughly enough.

Quote - and you remembered to choose the render settings for (if I remember it right) HDR Optimiized output.

Well, you're right, that helps... but for the bug I found only in 50% of the cases (it's inverting the bug) :-)
Try this:

1. use a gray background
2. render (with GC, Gamma 2.2) the background with A) HDR optimized and B) not HDR optimized and save each as OpenExr
3. then use image A) as background image, using render settings for the images gamma value
4. then set the images gamma value to custom (2.2) and render again
5. repeat steps 3 and 4 with image B)
   The resutling 4 images should all look the same (at least I think so), but only two are... :-)

At step 4, I expect it to be different. You're telling it to apply an anti-gamma of 2.2. Whereas in step 3 it used 1.0, because the default gamma for HDR images (incoming) is 1.0. I know the stupid dialog claims "Use Render Settings", but that's not what it does with HDR images. Instead, it uses 1.0, as it should. The render gamma is not correct for an incoming HDR image, so it doesn't use that.

The first choice "Use Gamma value from Render Settings" has the wrong name. It should be called "Use appropriate value automatically." For HDR images that is 1, regardless of what the render gamma is. When the render gamma is 2.2, and the incoming image is a JPEG, the correct default value is 2.2, which happens to be the same.

It turns out, however, that when the render gamma is anything other than 2.2, such as 1.8, but the incoming image is a JPEG in sRGB color space, the incoming gamma should be 2.2.

In other words, choosing to use incoming gamma = outgoing gamma is only the right choice when the outgoing gamma actually is the gamma of the incoming image. Any other time, it's the wrong value.

Poser assumes the incoming gamma of HDR and EXR images is 1, and you don't really want to match the render gamma of 2.2. The point of the image gamma is to linearize it.

Note - after choosing an image, if the first radio button is active, the value shown in the second ("Custom Gamma") actually reveals what is being used. Choose an HDR or EXR and it says 1.0. Choose a JPG and it says 2.2.

Quote - At step 4, I expect it to be different. You're telling it to apply an anti-gamma of 2.2. Whereas in step 3 it used 1.0, because the default gamma for HDR images (incoming) is 1.0. I know the stupid dialog claims "Use Render Settings", but that's not what it does with HDR images. Instead, it uses 1.0, as it should. The render gamma is not correct for an incoming HDR image, so it doesn't use that.

Yes, thanks, you're right, step 4 should look different, I corrected the value to 1.0 and it worked.

Now only the non-HDRI OpenExr renders wrong when "Use custom value from render settings" is checked (or custom value is 1.0). It renders too bright, so the exported OpenEXR (and the one in the temp folder) is saved with gamma correction applied and on import Poser thinks it's without GC as it should be. 
So the conclusion for me: never export as OpenEXR when not rendering with "HDRI optimized output" checked.