hi all,

while sorting out the intricates of PoserPro (2010), and focusing on lighting rigs, camera works and FireFly (and LuxRender) settings to make Poser work like a virtual portraying studio, I cannot get my head around the real meaningful use of gamma.

From my testing with controlled inputs (Photoshop measured calibration charts in any image format for textures etc), my findings are

• that issues with render result brightness should not be resolved with gamma but with Exponential tonemapping, changing the Exposure/exponent value
• that value maps/textures like bump, transparency etc should have gamma=1.0 in all cases
• that color maps/textures best have the same value as Render Settings, otherwise texture-red behaves different from Poser-internal-red and so on
• that raising gamma from 1 up to ... favors the nuaces in the midtones at the cost of losing nuances in the darks and in the lights. This gives hard shadows, hard highlights and a dimmed color contrast - which is exactly what is to be avoided in a portraying setup.

And so I wonder: what is the practical use of gamma correction anyway?
In addition to tonemapping, I mean. I get the best results when using 1.0, or: switching it off.

The only use I can think of is when using maps/textures made on an old Mac, which had a display gamma of 1.8 instead of the 2.2 that has become the overall standard nowadays.
But PoserPro always had gamma handling as an advocated selling point. I must be missing something...

Please tell me; thanks in advance.

In a nutshell, you're doing things that compensate for gamma and turning on gamma correction. Compensation and correction can both go in the same direction. If you do both, you get overexposure.

You'll get more realism, and have an easier time, if you do everything with physical correctness.

That means less ambient lights, fewer fill lights, use IDL, use scatter. Realism lighting, based on bounced light levels, will not be executed properly unless you deal with actual light levels, instead of inflated or deflated levels, both of which occur when GC is not part of the rendering equation.

IDL and scatter are the realistic way to reduce harsh shadows. Exploiting lack of gamma correction and adding fill lights is the old way.

Other things done wrong for a long time that you must stop doing if you use GC.

Diffuse_Value = 1 - wrong. Artificially boosts light levels. Better values are .7 to .8.

Constant and high Reflection_Value (way above .04). Wrong. Actual reflection values commonly encountered in real life are .02 to .03 and vary with viewing angle. The accurate portrayal of reflections, being a subtle low-level value problem, requires that the rendering equation and true light levels be used. Boosting reflections is a gamma compensation tactic. It's totally not necessary.

BB, thanks for the reply.

IDL, SkyDomes to mimic outdoor lighting, using white/silver/gold reflection and black absorbtion panels, Poser lighting rigs to mimic fashion shoot ringflashes or portraying softboxes or lighting strips, I do understand the whole lot. The closer I stick to the physical studio way of work, the better it gets. That is why I favor tonemapping (exposure, like changing shuttertime or film sentivity) as a final brightness adjustment step.

So, that leaves me with the question: what is the practical use of gamma handling in the materials room as well as in the render settings? I can't think of any, except the one I already mentioned.

What is your opinion on this?

(agree on your 2nd post, but that is about proper material room usage and is somewhat dealt with in the Pose2Lux exporter too).

You're ignoring simple facts. The numerical light levels recorded in a digital image do not produce linear luminance changes on a monitor. All digital media devices know this. Cameras gamma correct, printers gamma correct, etc. It's not a limitation of the monitor - it's intentional. A gamma of 2.2 gives more fine-grained control of light levels. If it used a gamma of 1 (linear) then many degrees of brightness would be wasted on bright things, and very few levels of darker things would be available. This would create obvious banding in gradients, particularly in shadow areas.

So - it's not for artistic reasons. You can work around it. It's for professional reasons. You want to use real light levels, and you do not want to be messing around with hacks and compensations. Everything should just work.

Tone mapping is a different subject. Totally.

What I have is an HDR environment - actual light levels, linearly recorded, of a real place. The sky is bright but overcast, so it's a very uniform hazy light gray.

Rendering that directly, without GC, produces an image where the environment photo looks too dark - darker than it really was. Also my 3D ground, props, and figure are lit correctly according to how much light was in the real place at the time, but they don't look like it.

This is a bit like listening to a tape with Dolby noise reduction encoded in it, on a device that has no Dolby circuit, except it's the opposite. Instead of boosted highs (Dolby) we have suppressed lows (Gamma = 2.2).

Everything appears on your monitor as it should, and my 3D props are lit correctly and blend in with the environment. That's ground tiles, two props, and a figure - zero effort.

Remember - no lights here. Adding even one light would deviate from the reality of the environment.

sRGB is not the only color space - there is also Adobe RGB

And what does Adobe RGB have to say about the meaning of its levels?

Quote - As with sRGB, the RGB component values in Adobe RGB are not proportional to the luminances. Rather, a gamma of 2.2 is assumed, without the linear segment near zero that is present in sRGB. The precise gamma value is 563 / 256, or 2.19921875.

Now if you know anything about color spaces, you know it's a mistake to look at an Adobe RGB image without color management (conversion) on an sRGB device. It will look wrong.

So do Poser renders that don't do color management.

There is more than one set of color management possible, and we could ask SM to deal with incoming material in Adobe RGB and to emit results in Adobe RGB. They have not done this, but they could. And it would be different than GC 2.2 as well.

In fact, sRGB is different than GC 2.2. We see this on really really dark things - less than 1% luminance are incorreclty recorded by Poser GC 2.2. So maybe you want to drop it to 2.0 or 1.9 or 1.8 in order to de-boost the super darks.

But overall, GC 1.8 to 2.2 is a big huge more accurate result than not doing GC or doing GC = 1 (which is the same thing, and not a "correction" at all.)

Remember Gamma Correction (not arbitrary gamma) means to match the luminance of the target color space. Not matching it is the same as "incorrect".

Poser's GC is actually closer to Adobe than sRGB, if I read that info correctly.

hi BB,

I fully understand the working of gamma in imaging, printing, displaying and the like, thank you.
I do understand that Poser deploys a 1) anti-CG 2) render and tonemap 3) apply CG cycle when GC is on.
I have found that when I create a colorcalibration texture in any image format, apply it to a simple object, apply a 100% intensity full white flat lighting and no tonemapping, my render result exactly matches the input when measuring pixel values in Photoshop, whatever the Render gamma value.
I have found that texture/pixel colors and poser-internal colors assigned to objects behave exactly the same, as long as the texture gammas follow the render gamma.
I have found that when lighting the scene with various lights, with different intensities and different colors, changing Render gamma distorts the relative contributions of the individual lights while changing tonemapping / exposure does not.
I know that IDL on skydomes or alike is a good way to mimic outdoor scenes, but falls short in producing realistic shadows from explicit sunlight so you have to add an extra (say Infinite) light to deal with that.

As a result, your IDL example with a sun- and shadowless underexposed outdoor scene might illustrate your point but still does not answer my question why I should use gamma (in addition to a properly set tonemapping) in creating well exposed, shadow-ritch, indoor (artificially lit only) portraying studio conditions. I still don't know.

Dear bagginsbill, a question: often in Poser grey level images are used to encode transparency information. When gamma correction is activated I have to go thru all the shaders and selectively select a forced gamma of 1 in the specific nodes instead of using the default gamma, right? otherwise trasparency values would be significantly altered, right?

Thanks alot!

Quote - Dear bagginsbill, a question: often in Poser grey level images are used to encode transparency information. When gamma correction is activated I have to go thru all the shaders and selectively select a forced gamma of 1 in the specific nodes instead of using the default gamma, right? otherwise trasparency values would be significantly altered, right?

Thanks alot!

Based on your intent in writing, yes that's right. All non-color images (transparency, displacement, bump, any sort of control mask) should be left alone - which is accomplished by a gamma of 1. Gamma=1 means do not alter the gamma.

Based on what you actually said, no that isn't right.

You can run a script that does it. There is no need to go into all materials and manually force gamma of 1.

artBee, you raise many points. I have a lot to do at the moment, but this struck me as odd, if you know how gamma works.

Quote - I have found that when I create a colorcalibration texture in any image format, apply it to a simple object, apply a 100% intensity full white flat lighting and no tonemapping, my render result exactly matches the input when measuring pixel values in Photoshop, whatever the Render gamma value.  

This is not new information, and you present it as if it refutes something or is a surprising result.

Given some image, with the actual stored value in it of x, and GC enabled with gamma=g, the equation of what you just described is:

(x ^ g) ^ (1/g)

Work that out and it is x. In words, it means that in the scenario you described, there can be no variation in outcome, regardless of g, unless g = 0.

The first step, the anti-gamma step, is exactly matched by the final gamma correcting step.

You found no difference because you artificially set up the simplest possible rendering equation, where everything is basically a variant of input * 1 * 1 * 1 + 0 + 0  + 0.

But if you actually use lights, and have surfaces turned, and have to combine diffuse and specular using addition, well things rapidly change.

What is the perpendicular (smallest) Fresnel reflection value for water?

The IOR is 1.33. The smallest reflection value is given by ((I-1) / (I+1))^2.

For water then, it is (.33 / 2.33) ^ 2  = .02.

Now render me a flat black surface with 2% reflection, showing something like a figure, with and without Gamma = 2.2. Tell me which one is horribly wrong and why.

Now make that surface also 10% diffuse white. Render again with and without gamma = 2.2 and tell me which is horribly wrong and why.

Then do 50% diffuse white. Surprise - not so horribly wrong anymore. Why? Because it's the darks that are more wrong than the lighter things, unles you use GC=2.2. Why do Poser users add light? Why do they boost colors? Because they look horribly wrong otherwise.

For those who want the answer, the one without GC=2.2 is horribly wrong. The reflection in the black surface will be almost or completely invisible - not at all like water.

hi BB

to the second (better: 4th) post: I do understand the sense of gamma correcting render results, please do stop the theory and please, if you like, do answer my question.

Poser does not apply a net gamma correction to the result (while exponential tonemapping does, about). Instead, it sandwitches the rendering etc between an anti-GC and a (pro) GC calculation. Therefore, as I have found, the result of Poser GC is not determined by texture brightness at all but by lighting and shadowing instead. And due to the sandwiching, the net effect of Poser GC has nothing to do with the GC needed to map pixel values onto output devices of any kind.

To my findings, in a setup with artificial lighting (like softboxes in a studio), raising the gamma from 1 up creates harder shadows, harder hilights and a loss of color contrast in the midtones.

PS: the difference between GC off and GC=1 is, that when off also explicitely set deviating values in the materials are ignored. For textures which are made to look good on an older Mac, this makes some difference.

at the later posts:

It might not be a surprise (to BB), but it shows that the anti-GC and the GC steps in the process do cancel out, under full flat lighting and no tonemapping. Which shows that Poser-GC is not about gamma correcting the render result, but is about the net effect of the sandwiching. Which is unrelated to colorspaces, nonlinear output devices and so on.

As I'm not that good in English, I just don't understand "...render me a flat surface... showing something like a figure..." What exactly should I create?

I do know that a single gamma correction increases the nuances (dynamic range) in the shadows at the cost of losing the nuances in the hilights. Tonemapping / Exponential exposure does exactly the same, and is in line with the working of film, camera CCD's and the human eye. And again, Poser does not perform a single gamma correction, it applies a sandwich. And I still fail to see why I need one, when tonemapping is on.

As I said, I'm really busy and can't write all that is necessary to explain what you're saying wrong.

The sandwich you are looking at is empty. So of course nothing happens.

For the moment, forget about incoming color spaces.

Just make a white prop with curves with Diffuse_Value = .8.

Place it on ground also Diffuse_Value = .8

Place an infinite light any way you like but so that you can see the shape due to angle of incidence.

The light should be white, with intensity 80%.

Enable IDL.

Render with and without GC. Observe the difference.

This scenario is pure outgoing gamma, preparing to display on a computer screen. Nothing else is going on.

Square mirror has Diffuse_Value = 0, Reflection_Color = Reflect node, and Reflection_Value = .02 (which is 2%, the reflection of water).

Infinite light is white with 80% intensity.

This is GC off.

thanks a lot, the examples are clear, I'll elaborate on them.

It's about half past midnight, I'll catch some sleep first so the next post might be over 20 hours or so.

Coming from someone that doesn't know as much about gamma as you two. Gamma correction is a big time help and it makes things easier for those with limited knowledge. I bet more people are now using better gamma or correct gamma than before there was gamma correction.

I rather have gamma correction and the image gamma script than not to have it because before then, getting the gamma correct was a big headache.  I think those involved with poser understood that not everyone out has the skills or advance level knowledge that you two have.

Poser is a much better program because of Gamma Correction

Unfortunately, I think in linear terms. Which makes concepts like Poser classes and OOP and gamma such difficult things to process. Blame my procedural programming background... it's held me back from "getting" some key things.

When we first discussed material GC, and coded for it, since the code looks like it would be processed linearly, I sort of thought Poser (Firefly) processes colours in some sort of sequence:

  x = image that has been corrected by camera or whatever: can be seen and appreciated by human vision on the monitor as correct, or any colour that isn't part of the Color(0,0,0)/Color(1,0,0)/Color(0,1,0) etc group
  gamma = 2.2

def antiCorrection(clr): return clr ** gamma
def Correction(clr): return clr ** (1 / gamma)

processColour = antiCorrection(Diffuse(x, .8))

shader = Correction(processColour)

So, whilst this looks like one could say: "we start with a colour here, anti-correct it, process it then correct it again", where and how this all happens can't be clearly identified as specific locations. I know this sound very difficult to understand, but that is the bane of linear thinking: I still do try to identify steps in a process (this happens in the POW node, this happens in the Diffuse node, now we give back to a POW node so that PoserSurface has the right information to give to Firefly to paint with) as opposed to just accepting that it's all sort of a finished product.

Which makes renderer GC and what all happens so obscure. Unless I stop thinking linearly. Then it makes sense.

Aaaannnnnd...

Cue ********* <--- Name removed to protect the guilty.

;) 

I wonder ...

Quote - Unfortunately, I think in linear terms. Which makes concepts like Poser classes and OOP and gamma such difficult things to process.

You should take a look at gamma correction from the eyes of a traditional artist medium (pencils, paint, and in some cases crayon).  Gamma correction while in that line of thought makes everything that you said sound like Kingon radio garble and static(I can probably learn that faster LOL).  The only way I can understand Gamma at all is to use it in a similar way that I use it in editing digital photos.  Beyond that, all of that math is just way beyond me.  I guess it's one of those things that a formal education in would be helpful.

Gamma correction should only be applied,if wanted, on the final render image. Applying GC in internal rendering stages produces unreal and not physically correct results.

For example, if you combine two textures t1^g + t2^g is not the same as (t1 + t2)^g or (t1^g + t2^g)^1/g will not give t1 + t2

Dumb question. 

If .8 is supposed to be the correct value for diffuse, why not going forward reset what is currently .8 to be the new one?  IE do a reset.

If you should have GC on.  If you should have diffuse for a typical object set to .8.  Then why not make those the defaults from now on and let people who know what they are  doing change them? Wouldn't that make sense?  

If you need backwards compatibility you can always create a macro or a check box or let poser tweak the incoming material based on which version it was created in.

Can you produce some renders, Kawecki, with settings to substantiate your views?

I brought popcorn... 

Quote - Can you produce some renders, Kawecki, with settings to substantiate your views?

Renders are subjective and anyone can manipulate to prove anything. For example, the renderings posted in the gallery using GC for me looks washed, dull and without life, but other people find them excellent.

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

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.

Instead of a bunch of theory, just look at the images I posted. The reflection coefficient of water, when viewed perpendicular to the surface, is 2%. You can see things reflected in water. Do you see anything reflected in that non-GC render? No you don't. Therefore since you should be able to see something, yet you cannot see anything, it follows that it's wrong.

The GC one is right. It shows the reflected objects at 2% of the luminance the original object has.

It's as simple as that.

If you have a texture gamma corrected 2.2 and you view it in a typical old CRT monitor that has a gamma 1.4 and not 2.2 you will not see the right colors

(x^1/2.2)^1.4 = x^0.8 and not x^1 = 1

CRT tubes has not a gamma 2.2 !!!!, the theorical value is 1.5, in practice due to the anode voltage are a little more linear and so, the value 1.4 is used.

You must use a texture corrected with gamma 1.4 or use a normal texture without GC and then correct the final image with a gamma 1.4

In modern LCD/LED monitors the gamma is 1.0, so they need no gamma correction. You can verify this very easily, take the same image and look it in an old CRT monitor and then look it in a LCD/LED monitor, you will see the clear difference in the dark areas of the image. You must use an old CRT monitor or a cheap one because many modern CRT monitors have built-in gamma correction electronics

Errata:  (x^1/2.2)^1.4 = x^0.63

I give up. Just so you people know, I am able to produce more realistic materials than anybody here, so I would expect I would get some respect. Kawecki is spewing nonsense, and I am once again done with a thread without having succeeded in communicating the simplest thing.

Kawecki does not believe anything on the Internet, so showing him how to use Google to look up gamma, sRGB, Adobe RGB, or any of a thousand other things will do not good. He's a denier - one of those guys who believes that saying the opposite of what everybody else knows or believes makes him an iconoclast, instead of a crackpot.

He also believes relativity is wrong.

Kawecki - go read something for once. Just once.

Quote - A common misconception is that gamma encoding was developed to compensate for the input–output characteristic of cathode ray tube (CRT) displays.[2] In CRT displays the electron-gun current, and thus light intensity, varies nonlinearly with the applied anode voltage. Altering the input signal by gamma compression can cancel this nonlinearity, such that the output picture has the intended luminance. But in fact, the gamma characteristics of the display device do not play a factor in the gamma encoding of images and video—they need gamma encoding to maximize the visual quality of the signal, regardless of the gamma characteristics of the display device.[1][2] The similarity of CRT physics to the inverse of gamma encoding needed for video transmission was a combination of luck and engineering which simplified the electronics in early television sets.

http://en.wikipedia.org/wiki/Gamma_correction

You are so tiresome it is mind numbing.

If you people do not POUND him into shutting up, I'm leaving.

I do not understand why constantly spewing falsehoods about a topic over and over, and ruining every single discussion about this topic, is not a TOS violation.

It's not like the disputed facts are hard to find. It seems willful to me.

Quote - I brought popcorn... 

Good, I'll bring the soda.... This should be entertaining ;).

Laurie

This is not my diagram. It's from Wikipedia.

What does this diagram say, people? Does it say CRT gamma 1.4? No? Does it say LCD gamma 2.2? No?

What does it say?

CRT Gamma 2.2

There are these things called tubes, transistors, resistors, capacitors, diodes, and inductors and they can be combined in interesting ways to make mathematical functions out of voltages. Any mathematical function. They can make a CRT that computes the amount of air in your head, although there might not be enough power to run such a device.

Quote - > Quote - I brought popcorn... 

Good, I'll bring the soda.... This should be entertaining ;).

Laurie

Ha. I'm not the least bit entertained. This is like the 10th time. Enough. I've sent a message to bantha. If Kawecki can just get away with such obsessive interference, spewing falsehoods that are easily refuted by a 10 year old, and that's not a TOS violation, a variation of trolling, then I'm totally done here.

Quote - > Quote - Can you produce some renders, Kawecki, with settings to substantiate your views?

Renders are subjective and anyone can manipulate to prove anything. For example, the renderings posted in the gallery using GC for me looks washed, dull and without life, but other people find them excellent.

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

So you're saying that you're not only ignorant, but blind also?

Kawecki:

Quote - My new LED monitor has three gammas, gamma1, gamma2 and gamma3, which one have I to use ?

from: http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3846306&ebot_calc_page#message_3846306

=====

Kawecki:

Quote - My new LED monitor has three gammas, gamma 1, gamma 2 and gamma3, which one have I to use?

from: http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3847377&ebot_calc_page#message_3847377

=====

Kawecki (up above):

Quote - In modern LCD/LED monitors the gamma is 1.0, so they need no gamma correction.

=====

Samsung HD Tech support:

Quote - The correct gamma levels for our LCD monitors is as follows: Mode 1: 2.2 Mode 2: 2.0 Mode 3: 2.4
--HDTech

from: http://forums.cnet.com/7723-13973_102-333170.html 

=====

Wikipedia:

Quote -  If images are not gamma encoded, they allocate too many bits or too much bandwidth to highlights that humans cannot differentiate, and too few bits/bandwidth to shadow values that humans are sensitive to and would require more bits/bandwidth to maintain the same visual quality.

  http://en.wikipedia.org/wiki/Gamma_correction

Quote - Kawecki - go read something for once. Just once.

Quote - A common misconception is that gamma encoding was developed to compensate for the input–output characteristic of cathode ray tube (CRT) displays.[2] In CRT displays the electron-gun current, and thus light intensity, varies nonlinearly with the applied anode voltage. Altering the input signal by gamma compression can cancel this nonlinearity, such that the output picture has the intended luminance. But in fact, the gamma characteristics of the display device do not play a factor in the gamma encoding of images and video—they need gamma encoding to maximize the visual quality of the signal, regardless of the gamma characteristics of the display device.[1][2] The similarity of CRT physics to the inverse of gamma encoding needed for video transmission was a combination of luck and engineering which simplified the electronics in early television sets.

http://en.wikipedia.org/wiki/Gamma_correction

You are so tiresome it is mind numbing.

If you people do not POUND him into shutting up, I'm leaving.

You continue to post articles from Wikipedia, this help you nothing, because Wikipedia, even it can be useful for referrences, is full of mistakes and written by anyone many time lacking the knowledge on the subject.

In your refference there are two big mistakes:

"varies nonlinearly with the applied anode voltage" It is non-linear with the grid voltage and not the anode. Is the grid voltage that controls the intensity and not the anode that is kept more or less constant at 30,000 Volts

"they need gamma encoding to maximize the visual quality of the signal" Gamma correction has nothing to do visual quality and has no effect on signal to noise ratio. The signal is transmited inverted where the hyper-black levels have the biggest amplitude.

Do you know what is transmited in the TV signal, do you think that is RGB ? and do you know what is gamma corrected ?

More Wikipedia links

Quote - Wikipedia:

Quote - " If images are not gamma encoded, they allocate too many bits or too much bandwidth to highlights that humans cannot differentiate, and too few bits/bandwidth to shadow values that humans are sensitive to and would require more bits/bandwidth to maintain the same visual quality."

 

http://en.wikipedia.org/wiki/Gamma_correction

Normal images have RGB with 8 bits and always use 8 bits, gamma encoding will not make it use 5 bits and without GC it will not be 10 bits. It always are 8 bits and always consume the same bandwidth, no matter if is gamma encoded or not or is black or pink color, always are used 8 bits.

Why do you keep talking about television. We're talking about digital images, not television. You keep talking about CRT and equating that with television. They are different topics. On a CRT, the gamma is 2.2. Doesn't matter whether that is grid voltage or whatever - the point is that the nonlinear response to the numbers 0 to 255 is on purpose, and its got nothing to do with the crap you keep saying.

Quote - Gamma correction has nothing to do visual quality and has no effect on signal to noise ratio. The signal is transmited inverted where the hyper-black levels have the biggest amplitude.

Why are you talking about television transmission again? You're just being uselessly argumentative. Regarless of the encoding of television signals, analog or digital, it is a fact that digital images are supposed to be encoded with gamma = 2.2.

You have more than once claimed that wikipedia information is suspect because you have spotted errors in it. Well first of all the "errors" you seem to find are not errors at all. It's your misunderstanding that is in error. Second, editors of wikipedia do not allow original research. Everything they say has to be referenced by a reputable source in a separate publication.

In case of your mistaken belief about why we use gamma at all, you claim the article is in error. No, you are in error. The article cites its source. You never cite sources - you just make stuff up.

The sources cited on this matter are:

http://books.google.com/books?id=ra1lcAwgvq4C&pg=RA1-PA630&dq=gamma-encoding#v=onepage&q&f=false

and

http://www.poynton.com/notes/color/GammaFQA.html

I quote from Poynton. Note that the first fallacy is what you keep saying, as if saying it over and over does not make you look stupid. 

Quote - Fallacy: The main purpose of gamma correction is to compensate the nonlinearity of the CRT.

Fact: The main purpose of gamma correction in video, desktop graphics, prepress, JPEG, and MPEG is to code light power into a perceptually-uniform domain, so as to obtain the best perceptual performance from a limited number of bits in each of the R, G, and B (or C, M, Y, and K) components.

Fallacy: Ideally, linear-light representations should be used to represent image data.

Fact: If linear-light coding is used to represent image data, then from 12 to 14 bits are necessary in each component to achieve high-quality image reproduction. With nonlinear (gamma-corrected) coding, 8 or 10 bits suffice.

Fallacy: A CRT is characterized by a power function that relates luminance to voltage:L  =  V*[gamma]* .

Fact: A CRT is characterized by a power function, but including a black-level offset term: L  =  (V  +  epsilon )  gamma

Fallacy: The exponent gamma varies anywhere from about 1.4 to 3.5.

Fact: In studio video, the exponent itself varies over a rather narrow range, about 2.35 to 2.45. In consumer use, the range is somewhat wider, say 2.0 to 2.3. Digital cinema is standardized at 2.6. The alleged wide variation comes from variation in offset term of the equation, not the exponent: Wide variation is due to failure to correctly set the black level.

These are direct refutations of nonsense you have written many times.

Further, in this paper: http://www.poynton.com/PDFs/Rehabilitation_of_gamma.pdf

Poynton introduces the topic this way:

Quote - Gamma characterizes the reproduction of tone scale in an imaging system. Gamma summarizes, in a single numerical parameter, the nonlinear relationship between code value – in an 8-bit system, from 0 through 255 – and luminance. Nearly all image coding systems are nonlinear, and so involve values of gamma different from unity. Owing to poor understanding of tone scale reproduction, and to misconceptions about nonlinear coding, gamma has acquired a terrible reputation in computer graphics and image processing. In addition, the world-wide web suffers from poor reproduction of grayscale and color images, due to poor handling of nonlinear image coding. This paper aims to make gamma respectable again.

See that part I bolded - about poor handling of nonlinear image coding. That "poor handling" is what I am trying to teach people to stop doing. Converting gamma at the beginning and ending of image processing and rendering is the first step in doing accurate and realistic lighting and color management.

Quote - More Wikipedia links

Quote - Wikipedia:

Quote - " If images are not gamma encoded, they allocate too many bits or too much bandwidth to highlights that humans cannot differentiate, and too few bits/bandwidth to shadow values that humans are sensitive to and would require more bits/bandwidth to maintain the same visual quality."

 

http://en.wikipedia.org/wiki/Gamma_correction

Normal images have RGB with 8 bits and always use 8 bits, gamma encoding will not make it use 5 bits and without GC it will not be 10 bits. It always are 8 bits and always consume the same bandwidth, no matter if is gamma encoded or not or is black or pink color, always are used 8 bits.

You don't understand what it says. It doesn't say anything at all about the total bandwidth. You display a singular lack of ability to track a technical argument.

It is talking about the distribution of that bandwidth. How much is given to values near maximum versus minimum. If linear encoding is used, we have many fine-grained steps near white, and hardly any steps near black. This means that the full range of luminance is starved for bandwidth at the low end, and has bandwidth to spare at the high end.

Gamma encoding rearranges that distribution so that perceptual changes in luminance are equally spaced throughout the numeric range of 256 values.

You are beyond tiresome. Learn to read. You claimed to understand relativity at 14. I think you understand only about 1/3rd of what you read. The rest you make up. Practically every technical accusation you make involves carefully rearranging words, or leaving out important words, so as to subtlely change the meaning. Most people cannot tell you for the faker you are, but I am not easily befuddled by techno-speak. I can understand every mistake you make, and explain how you made it. You're not used to that, and what I don't understand is how you keep coming back without once ever acknowledging any refutations. You keep making new points instead of recognizing all the bad ones you made so far.

It doesn't work. You're like an infinite supply of balloons and I'm a pin. It's no contest, but you keep coming back anyway.

Pop pop pop.

hi all,

with due respect to each contribution, I sadly see my serious, honest and humble question hijacked by posts which do not address the question at hand, and tend to get personal / insulting in cases. So:

• please respond to me, and not to each other. Consider me chairing the threat, or something like that. And please do not suppose on peoples equipment, skills, knowledge etc which you can't back up and which does not contribute to answering the question

• please stick to the topic.

So the question is NOT:

• what is the use of gamma / curved brightness corrections when sending images to print or displays, and why do those output devices need it, and why do JPG and MPG have embedded profiles, and everything about color spaces. I know it all, thanks, and it has nothing to do with the net effect of the Poser GC process.
  In addition, I like to know to what extent a red input (texture, color) is turned into red output (render result) by RGB/HSV-measuring both in Photoshop or alike. I don't care if an image red shows purple on my display due to whatever colorcrisis is going on. I do care whether input and output shows same or different purples, and why (my monitors are spiderpro calibrated every quarter btw). 

• can Poser GC be (ab)used for brightness corrections to get more detail in the darks, and to make it look good / better. Yes it can, it has some disadvantages, and in my opinion Exponential Tonemapping is a better way to go. Perhaps Photoshop Levels / Curves adjustment is a good alternative too.

Again, the question is:

since Poser GC is a sandwiching process, which darkens a color (gamma curve as in earlier BB post), then renders (usually darkens again thanks to shadowing) and applies tonemapping if requested, and then brightens the final image ( 1 / gamma curve), what is the practical use (in addition to tonemapping) in scenes which mimic indoor portraying studio conditions (= without IDL/SkyDomes but with lighting rigs for key/fill/... lighting)?

and a minor second question is: if you think Poser GC is to be preferred over exponential tonemapping / adjustment in post for image dynamic range correction, then why so?

Preferrably to be illustrated with renders and measurement result to stimulate further investigation.

Thanks in advance, to be continued...

The purpose is so you see what the renderer is trying to show you. I can't understand how to explain it in words any better. The purpose is so you use all the information consistently and introduce as few errors as possible.

Examples:

Subsurface scattering leaks light through an ear, and decides that despite the fact that no direct light is striking the front of the ear, there should be a small amount of red showing on the unlit side. Assume this part of the ear would otherwise be simply black. Suppose that the amount of red scattering out the ear here should be red 10% of max. Max is, of course, 255 in 8-bit integer (I8) format. In unit format, internal to the render, it is .1. So how should .1 red, or 10% red be sent to the image?

The old way is you assume 10% of 255, so the value stored is 26. What is the luminance of 26? Is it .1? No. Because of gamma, the luminance of this value when you see it on your screen is (26/255)^2.2. This effective luminance in percentage is .63%. This is extremely dark and not even close to the 10% that was intended.

The correct value to emit to the render is .1^(1/2.2) * 255, which when rounded is 89. That is the meaning of the number 89 red - it means "monitor, please shoot 10% of your maximum red here". The number 26 does not mean 10%. It means .63%.

Now suppose you have a texture in which you have, using Photoshop, drawn a certain amount of red. As you made your drawing, you decided to use 89 red, because it looked right to you. Internally, you were making a decision to add more red until it looked right. What you were looking at was 10% red. What we want the renderer to use in its calculations involving this texture is that here it is 10% red. The way to do that is to "decode" the image. The image values are not linear. The value 89 means literally 10%. It does not mean 89/255 or 35% - it does not mean that at all. But if you ignore gamma, that's what you're using.

Now ignoring gamma means that you overestimate colors on input, and you underestimate them on output. The two "errors" seem to cancel out, and in general they do, so long as you stay near the upper third of brightness. If the incoming and outgoing colors are in the same part of the luminance range, then the cancellation is pretty good. If they are in different parts, then the cancellation is pretty bad.

As you get into darker things, where the incoming value is high but the surface is turned 88 degrees to a light source, the errors do not quite cancel out, and in fact become exceedingly obvious.

The render I did of the ball, ground, and 2% mirror shows this clearly. The input is white, which has no overestimation. Why? Because no matter what gamma you're assuming, 1 is 1 and 0 is 0. Maximum and minimum values are not affected by gamma. It's the gradient between them that is affected by gamma. So when you try to calculate 80% light level, at an angle that reduces light source intensity to half (now 40%), and the material only reflects 80% of that (32%) and the mirror only reflects 2% of that (.64%) what is the value that should be written into the file? Why, it is none other than our old friend, # 26. The # 26 represents this particular case, which I carefully used to illustrate in my render.

Now do a flip test. The parts that are relatively bright don't look too bad without GC.

But the darker parts - those things down around 20% and below, are very wrong.

The terminator on the cylinder is too gradual. That's not how things look with a point light source. That's because as we get closer to black, the pixels are darker than they should be - they approach black in a hurry, so the terminator is more gradual. The reality is that the luminance does not drop to 10% until you are 84 degrees out of line with the light source. That means that the last 10% of luminance (down to no contribution from the main light) happens in just six degrees of rotation.

Without GC, the 10% level is reached at 69 degrees out of line with the light source. The last 10% of luminance is spread over a rotation of 21 degrees. That's more than twice as wide as it should be, and when I see that, I notice. Many Poser users don't - in fact they have conditioned themselves to think that is normal. It is not.

When I show my wife the non-GC renders that people make, she always asks why are they so muddy? Why do they look like they are shaped funny?

It's because the dropoff in luminance with rotation away from light sources is skewed. It's because this skewing makes the curves and shapes of organic things look different than what they are supposed to be.

In my early days of Poser, I thought there was something wrong with its Diffuse light calculation. I photographed cylinders lit only by flashlight and compared the luminance gradients with renders. They were really off by a lot. I never understood why, until I discovered gamma. Then it all made sense.

Like this. I increased the luminance of my IBL from 5% to 40%. That is 8 times more ambient light.

I have filled in the shadows a bit, but I've lost something on the lit side. It doesn't look so real. It looks - washed out!

So now you might think - oh I should boost the specularity on the skin. But why? Just because there is more light, there should be more specularity added to the shader? Isn't that counterintuitive? Should we not expect that there is more specularity when there is more light?

The naive would say that Poser lighting is "hard".

It's not hard at all if you enable GC. Lighting just works the way you expect it to. Even better, you can look things up and expect the simulation parameters for shaders and lights to make sense - to correspond with the real world.