Quote - Yes, please do the HSV series as well. If you can, please record the HSV values of the sample pixels in both renders.

The formula for this one seems to be:

y(x) = x * (1-exp(-eta * x / 255)),  0 <= x and x <= 255

where
x = the input pixel channel value [R, G, or B],
y = corresponding output value,
eta = the "exponent" parameter, and
exp() = the exponential function for the base of natural logarithms.

This is a pretty standard saturation-type expression.

Whichway

(Of course, I realize that as soon as somebody else checks my figures, I'll be wrong. )

Close, but not quite right. I got the formula from Stefan, just in case it differes from some standard.

First, luminance is a floating point value, and is not limited to 0 <= x <= 1. It can be greater than 1 as is found in HDRI. That's the whole point of the tone mapping - to compress all values into the range 0 to 1. Of course, we can convert to/from our usual 8-bit RGB values 0 to 255 by a simple multiplication/division. But be aware that shaders work in floats, and often produce values greater than 1. The final output is, of course, clamped to the range 0..1, but on the way it can be much greater (or even negative). However, this tone mapping equation is not intended to deal with negative or imaginary colors. grin

y(x) = gain * (1 - exp(-exposure * x ))

For clarity, I changed the label eta to exposure. There is another parameter, gain, which is not presented to us as a settable parameter in render settings. But it exists inside Poser and we can get to it via Python. But unless we do that, the gain is 1.

Of course, if you really want to work in 8-bit units, then the final output color is:

y(x) = min(max(floor(255 * gain * (1 - exp(-exposure * x / 255)) + .5), 0), 1)

And you guys did correctly figure out that HSV ETM is in HSV space and operates only on V.

Basically, in RGB, the new RGB is calculated like this when using HSV ETM:

K = y(V) / V # where V is whichever component is brightest
R' = R * K
G' = G * K
B' = B  * K

That isn't how Poser actually does it, mores the pity. The way i just described is much faster than what Poser does. Poser converts the old RGB to HSV, updates V, then converts the new HSV back to RGB. Very wasteful, but it doesn't really matter, because rendering takes much longer than this less-than-optimal tone mapping step, much much longer. If I had written it, I would use the way I just described, since it skips the RGBtoHSV and HSVtoRGB.

More to come...

---

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)