its very hard to find answers in those long threads. and there are like 100 threads. so this thread is only for tone mapping . the new render setting in poser 8.

tone mapping was added for all the people who didnt understand gamma correction in poser pro.
its easier to turn on and you dont need to change your materials.

of course if you have no idea what you are doing then your results will suck. IMO it would be better to gave GC. but what can we do.

ok BB i think i found my first problem with tone mapping.

it makes the background images brighter. for example the reflection map from the ENsphere.

so i made tests. if i plug something in the ambient channel or alt-diffuse then the tone mapping changes it.if we can not change this then this is a big problem.

i tryed anti-GC the image with 2,2 and 2 . but it doesnt look like the original image.

We going to need visual representations for clarity.  Testing out this feature for the first time recently on an image I have been working on in PoserPro and I have found that activated IDL with tone mapping set to 2.2 gave me an identical render as Gc 2.2 in PP.  I don't have comparison images saved yet.  Maybe over the weekend.

BTW, what is the setting of your Tone Mapping?  Mine was HSV.

everything is turned of. image is plugged in the alternate diffuse

As I understand it, Tone Mapping operates on the final 2D render, not on the 3D materials.
So your pictures show exactly what we would expect... don't they?

so we need to use shaders to get rid of this? because how else can we then use the env-sphere?

You're going to need two threads.

One to show something, explain it incorrectly, we have an argument, we show another version, then we conclude how it works. Then somebody shows an exception, then we find a workaround, then we discuss the problem with that.

Then I come in and announce that I completely misunderstood the math 3 days ago, and all that stuff I said about 2.2 exposure is crap. Then we start over.

By now the thread is 18 pages long, full of misinformation.

The other thread I will post in next month, when I am not so stupid with Poser 8.

Start with the math, because our eyes and our expectations deceive us.

If you must experiment, go simple. Plug a known RGB value, such as 255, 128, 64 into Alt_Diffuse and render with various settings.

Measure the color rendered.

Make observations.

this should be the thread only to talk about tone mapping. its so hard to find your posts BB.

everyone that has a question opens a new thread. and its crazy here on the forum.

oh...I thought this was going to be about synesthesia...;) don't mind me...;)

bagginsbill - What math? I love math.

Whichway

Ok - I have tried to do as BB suggested and have run a quick test with Exponential Tone Mapping.

I started with the attached render (render settings in the next post) and saved it as a TIFF.  I checked all of the colors in the right hand column and they matched the input colors.

I then re-rendered with Exponential Tone Mapping on and saved as a TIFF.  I've checked some of the colors and here's a sample of the data:

Color                     Original
White                     (255, 255, 255)
Light Grey             (191, 191, 191)
Med. Grey             (127, 127, 127)
Dark Grey             ( 64,  64,  64)
BB's Color            (255, 128,  64)
Random Color    (109, 205,  35)

Color                    E 1.0
White                  (161, 161, 161)
Light Grey           (134, 134, 134)
Med. Grey           (100, 100, 100)
Dark Grey           ( 56,  56,  56)
BB's Color           (161, 101,  56)
Random Color    ( 89, 141,  32)

Color        E 1.5
White        (198, 198, 198)
Light Grey    (172, 172, 172)
Med. Grey    (134, 134, 134)
Dark Grey    ( 80,  80,  80)
BB's Color    (198, 135,  80)
Random Color    (121, 179,  47)

Color        E 2.0
White        (221, 221, 221)
Light Grey    (198, 198, 198)
Med. Grey    (161, 161, 161)
Dark Grey    (101, 101, 101)
BB's Color    (221, 162, 101)
Random Color    (147, 204,  61)

Color        E 2.5
White        (234, 234, 234)
Light Grey    (216, 216, 216)
Med. Grey    (182, 182, 182)
Dark Grey    (119, 119, 119)
BB's Color    (234, 183, 119)
Random Color    (168, 221,  74)

Color        E 3.0
White        (243, 243, 243)
Light Grey    (228, 228, 228)
Med. Grey    (198, 198, 198)
Dark Grey    (135, 135, 135)
BB's Color    (243, 199, 135)
Random Color    (184, 233,  86)

(If there is a better way to present this information, please let me know)

So now the question is, What does this tell us?

If this looks useful I can also run it for HSV Exponential Tone Mapping.

[Edited trying to get the formatting better, but it obviously didn't work]

There is not "correct setting"... every image is different. I saw from the 1st renders I did that the 2.2 setting gave over exposed renders, which might be what your looking for in a certain situation. IMO I start at a 1.6 and do test renders to see if I want to raise or lower it.

Your eyes don't decieve you...it's art people, art. 

Or did you find the make art button in poser 8?

Well, maybe thats someones request for sp1

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. )

Here are the values for the HSV series as well - I've included a couple more data points.

Color        Original
White        (255, 255, 255)
Light Grey   (191, 191, 191)
Med. Grey    (127, 127, 127)
Dark Grey    ( 64,  64,  64)
BB's Color   (255, 128,  64)
Random Color (109, 205,  35)

Color        HSV 1.0
White        (161, 161, 161)
Light Grey   (134, 134, 134)
Med. Grey    (100, 100, 100)
Dark Grey    ( 56,  56,  56)
BB's Color   (161,  81,  40)
Random Color ( 75, 141,  24)

Color        HSV 1.5
White        (198, 198, 198)
Light Grey   (172, 172, 172)
Med. Grey    (134, 134, 134)
Dark Grey    ( 80,  80,  80)
BB's Color   (198,  99,  49)
Random Color ( 95, 179,  30)

Color        HSV 2.0
White        (221, 221, 221)
Light Grey   (198, 198, 198)
Med. Grey    (161, 161, 161)
Dark Grey    (101, 101, 101)
BB's Color   (221, 111,  55)
Random Color (108, 204,  34)

Color        HSV 2.1
White        (224, 224, 224)
Light Grey   (202, 202, 202)
Med. Grey    (166, 166, 166)
Dark Grey    (104, 104, 104)
BB's Color   (224, 112,  56)
Random Color (110, 208,  35)

Color        HSV 2.2
White        (227, 227, 227)
Light Grey   (206, 206, 206)
Med. Grey    (170, 170, 170)
Dark Grey    (108, 108, 108)
BB's Color   (227, 114,  57)
Random Color (112, 212,  36)

Color        HSV 2.5
White        (234, 234, 234)
Light Grey   (216, 216, 216)
Med. Grey    (182, 182, 182)
Dark Grey    (119, 119, 119)
BB's Color   (234, 117,  58)
Random Color (117, 231,  37)

Color        HSV 3.0
White        (243, 243, 243)
Light Grey   (228, 228, 228)
Med. Grey    (198, 198, 198)
Dark Grey    (135, 135, 135)
BB's Color   (243, 122,  61)
Random Color (123, 233,  39)

Thanks!

Well, the obvious observation is that the results are identical to the simple Exponential version.

Whichway

Whichway - Not really.  They are similar for the "Pure colors" (White, greys, and anytime an RGB channel value is 255), but not for other colors.  Take a look at BB's color and my Random Color.  This is why I included the extra results at 2.1 and 2.2.

It appears that HSV Exponential is a function of all three color values (which makes since from the name - duh....) and it is stable across the values.  What I mean is - the two colors in the top row of my render are BB's color (255, 128, 64) {the orange} and the same values, just in a different order (64, 128, 255) {the blue}.  With Exponential tone mapping the channel values were consistent and independent of each other - for a given tone mapping level a channel value of 128 will always map to the same value no matter what the other color channels values are.  With HSV Exponential, that is not true.  Compare the values returned for Dark Grey with the Green Channel values from BB's color.  And while I didn't list the blue version of BB's color in the above table, it's values tracked exactly with the orange version, just with the Red and Blue channel values swapped.

Give me a few minutes and I'll get some samples from some of the other squares.  (I was only using the right hand column from my original post for these results as well).

Ah! Good, I was hoping I was wrong on that one. I suppose it was inevitable that the grey's would match since the very fact that they are grey means they only have V in HSV.

Whichway

I'm not going to post any more results from the HSV Exponential unless anyone really wants to see them.

I've just had my D'Oh moment - Exponential tone mapping should really be called RGB Exponential because it's mapping in the RGB color space.  HSV Exponential is mapping in the HSV Color space.  If I had used HSV tuples instead of RGB tuples in my second listing, it would have followed the exact same pattern as the first data set.  (I don't know if I can make IrfanView show HSV instead of RGB, but I'm not going to worry about it now).

Exactly!

interesting.

anything new ? 

ice-boy - Two things, in my mind. First is scarlock's point that the difference between Exponential and HSV Exponential is the color space they work in. For (RGB) Exponential, the transfer function I wrote down is applied to each of the R, G, and B axes separately, while for HSV Exponential, it is applied to the V axis only. The point of defining HSV coordinates in the first place is so that the perceptual qualities of Hue, Saturation and Value are decoupled from each other - changing one does not effect the other two. So, HSV Exponential compresses only the Value without changing the Hue or Saturation. For (RGB) Exponential, these perceptual qualities are cross-coupled; changing just R will change all three of HSV. Changing all three of RBG by the same factor will, I think, leave Hue the same, but mix Saturation and Value. Changing Value is equivalent to turning down the brightness of the lights and doing nothing else.

The second is that Tone Mapping is really quite different from Gamma Correction. The Gamma Correction transfer function is concentrated at the low end of the brightness scale; it works on the "toe" of the response curve. [For the ubertechies, the fact that the top value of the transfer function is pinned at 255 forces all the change with gamma to the low end of the transfer function.] If you look at the Tone Mapping transfer function, you'll see that is does practically nothing at the low end of the brightness scale but compresses the high end; it works on the "shoulder" of the response curve. As the Poser 8 documentation says, it is designed to simulate the saturation that happens in real film and avoid hard clipping of highlights in digital images.

My conclusion would be that Tone Mapping and Gamma Correction are very distinct things and you should not try to use one in place of the other. "Correct" usage uses both, and all the old GC discussion is still true.

Whichway

Another thing: the "do nothing" setting of the Exposure is 0.0, not 1.0. [This should be checked to make sure I'm not talking through my hat again.]

Whichway

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...

The bold line is Exposure=1.6, the default.

The bottom is Exposure = 1.0.

The top is Exposure = 2.2.

There is no such thing as a "do nothing" Exposure value.

This function never reaches 1, no matter how big x is.

The purpose of it is to map all values from 0 to infinity into the range 0 to 1. You can adjust the curve up or down, but you cannot change its shape.

An interesting observation, then, is that with ETM enabled, you cannot make a pure white pixel (RGB 255 255 255), unless you have a shader produce a luminance value in the thousands.

None of the ETM curves are at all similar to the GC curve.

ETM with gain = 1.0 cannot reproduce an outcome that is similar to GC with any value of Exposure.

Black is what we used to see when we just rendered straight out.
Red is the GC curve - perfectly linear luminance.
Blue is the ETM curve with exposure at 2.2. Not even close to the effective luminance of GC. In fact, it's really bad. Low contrast, darker than it should be everywhere.

Here Exposure is 2.3, Gain is 1.11.

Here is a scene rendered with:

exposure = 2
gain = 1

exposure = 2.3
gain = 1.1

Exposure 1.68
Gain 1.23

I like the HSV 1.68 render best, so far.  on my monitor (1.8 gamma).

but wasnt the point of TM that it would be easier to understand then GC?

this is a lot of info again. and if they need to read this now and learn it all then what is the point? i dont want to complain. i just ask. yes i understand that its easier that they dont need to change GC on every transparency map.
but look now i have TM and i can not use a reflection map . because TM changes it.

its not a problem to me. because i am reading and learning. but others dont want to.

You are right that it messes up the rendition of a photo, such as used on an EnvSphere. To get the photo directly out as is, you would have to anti-ETM the photo!!! LOL Nobody but us will do that.

But outside of the EnvSphere or reflection map issue, ETM is easier for an "artist" to deal with. Too dark? Increase exposure. Too light? Decrease exposure. Artists will not ponder the math. They will tweak and test render for days. I, on the other hand, will compute the right formula and produce an accurately lit render in the first try. I will also use that formula over and over, because I do not make inconsistent shaders. My components all behave as much as possible to the standards set by reality, which means I'm not having to guess-and-test very much as different element of fhe scene appear out of whack.

Only reason I'm posting these details, is so that people who do not want to waste time can benefit from the experiments, and learn from them, and because I was asked to do so in a couple PMs. For the artists, they should skip the formulas, and just look at the test renders, see which they like best, and copy the two numbers I used, and move on. Copying two numbers does not require a PhD in math.

Some people are actually insulted/irritated by my technical postings and have said so. They can go fuck themselves.

if they don't like 'em don't read 'em

those of us that want to know, thank you.

i agree with your post.

anti-TMN will also be used on materials with reflection? 

If you are using ETM and have a photo for a background or for reflections, the ETM will alter the photo. You would need to anti-ETM the photo, just like you need to anti-GC the photo if the last step is to apply GC. Anti-GC + GC = no change. Anti-ETM + ETM = no change.

Quote - You are right that it messes up the rendition of a photo, such as used on an EnvSphere. To get the photo directly out as is, you would have to anti-ETM the photo!!! LOL Nobody but us will do that.

But outside of the EnvSphere or reflection map issue, ETM is easier for an "artist" to deal with. Too dark? Increase exposure. Too light? Decrease exposure. Artists will not ponder the math. They will tweak and test render for days. I, on the other hand, will compute the right formula and produce an accurately lit render in the first try. I will also use that formula over and over, because I do not make inconsistent shaders. My components all behave as much as possible to the standards set by reality, which means I'm not having to guess-and-test very much as different element of fhe scene appear out of whack.

Only reason I'm posting these details, is so that people who do not want to waste time can benefit from the experiments, and learn from them, and because I was asked to do so in a couple PMs. For the artists, they should skip the formulas, and just look at the test renders, see which they like best, and copy the two numbers I used, and move on. Copying two numbers does not require a PhD in math.

Some people are actually insulted/irritated by my technical postings and have said so. They can go fuck themselves.

I like the "Quick and Easy" approach of just copying your numbers, it gives me a base to start from, so learning from your examples is in the words of VIsa Ads "Priceless" , after initial settings then I experiment  so I understand WHAT the parameter settings actually do.... 

I find no irritation in being offered Free Education  via someone else's examples and explanations.

I find your Tech posts, at times make me feel like I should not have slept so much through math class ;), but VERY informative non the less. 

Keep it coming! Tech or layman makes no difference to me. :)

"Appreciative Reader"

For example, have you seen SemiDieu's Postwork Manager? It is interactive ETM on steroids, and includes GC, too!

Menu Scripts/Partners/ShaderWorks/Postwork Manager

Screen shot above shows me applying GC and brightness, contrast, saturation, etc to a render all within Poser.

Thanks, people, for affirming the interest in my posts. I appreciate it.

Quote - If you are using ETM and have a photo for a background or for reflections, the ETM will alter the photo. You would need to anti-ETM the photo, just like you need to anti-GC the photo if the last step is to apply GC. Anti-GC + GC = no change. Anti-ETM + ETM = no change.

i understand.

did you  got the formula for tone mapping from stewart?is TM also the function POW ?

Quote - As I've said before, one of the awesome new features of P8 is the wxPython interface. P8 comes with some fantastic plugins enabled by this API, and you will see more over time. These add so much to Poser's capabilities.

For example, have you seen SemiDieu's Postwork Manager? It is interactive ETM on steroids, and includes GC, too!

Menu Scripts/Partners/ShaderWorks/Postwork Manager

Screen shot above shows me applying GC and brightness, contrast, saturation, etc to a render all within Poser.

i saw this. its very good.

Yes from stewer (Stefan Werner). ETM is not just pow. I gave the formula earlier in this thread. If you have not changed posts per page, it is page 1, 3rd from the bottom.

aha i see. i dont understand all those words. i will whait until someone posts a screenshot from the material room.  :) 

Quote - Thanks, people, for affirming the interest in my posts. I appreciate it.

I await with anticipation any wisdom you choose to impart to the rest of us....lol.

Laurie