aRtBee opened this issue on Oct 17, 2011 · 76 posts
aRtBee posted Mon, 17 October 2011 at 2:18 PM
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
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.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bagginsbill posted Mon, 17 October 2011 at 2:43 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 2:47 PM
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.
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)
aRtBee posted Mon, 17 October 2011 at 2:58 PM
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).
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bagginsbill posted Mon, 17 October 2011 at 3:19 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 3:22 PM
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).
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)
bagginsbill posted Mon, 17 October 2011 at 3:23 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 3:32 PM
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.
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)
aRtBee posted Mon, 17 October 2011 at 4:05 PM
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.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
alexcoppo posted Mon, 17 October 2011 at 4:07 PM
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!
GIMP 2.7.4, Inkscape 0.48, Genetica 3.6 Basic, FilterForge 3 Professional, Blender 2.61, SketchUp 8, PoserPro 2012, Vue 10 Infinite, World Machine 2.3, GeoControl 2
bagginsbill posted Mon, 17 October 2011 at 4:09 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 4:14 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 4:22 PM
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.
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)
aRtBee posted Mon, 17 October 2011 at 4:28 PM
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.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
aRtBee posted Mon, 17 October 2011 at 4:47 PM
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.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bagginsbill posted Mon, 17 October 2011 at 5:05 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 5:15 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 5:16 PM
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)
aRtBee posted Mon, 17 October 2011 at 5:25 PM
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.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
FightingWolf posted Mon, 17 October 2011 at 6:00 PM
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
RobynsVeil posted Mon, 17 October 2011 at 6:32 PM
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.
Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2
Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand]
SamTherapy posted Mon, 17 October 2011 at 7:02 PM
Aaaannnnnd...
Cue ********* <--- Name removed to protect the guilty.
;)
Coppula eam se non posit acceptera jocularum.
bagginsbill posted Mon, 17 October 2011 at 8:18 PM
I wonder ...
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)
FightingWolf posted Mon, 17 October 2011 at 8:22 PM
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.
kawecki posted Mon, 17 October 2011 at 8:23 PM
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
Stupidity also evolves!
Winterclaw posted Mon, 17 October 2011 at 8:24 PM
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.
WARK!
Thus Spoketh Winterclaw: a blog about a Winterclaw who speaks from time to time.
(using Poser Pro 2014 SR3, on 64 bit Win 7, poser units are inches.)
RobynsVeil posted Mon, 17 October 2011 at 8:41 PM
Can you produce some renders, Kawecki, with settings to substantiate your views?
Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2
Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand]
WandW posted Mon, 17 October 2011 at 8:53 PM
I brought popcorn... 
----------------------------------------------------------------------------------------
The Wisdom of bagginsbill:
"Oh - the manual says that? I have never read the manual - this must be why."
kawecki posted Mon, 17 October 2011 at 9:02 PM
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
Stupidity also evolves!
bagginsbill posted Mon, 17 October 2011 at 10:44 PM
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.
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)
bagginsbill posted Mon, 17 October 2011 at 10:56 PM
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.
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)
kawecki posted Mon, 17 October 2011 at 11:33 PM
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
Stupidity also evolves!
kawecki posted Tue, 18 October 2011 at 12:01 AM
Errata: (x^1/2.2)^1.4 = x^0.63
Stupidity also evolves!
bagginsbill posted Tue, 18 October 2011 at 12:09 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 12:12 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 12:18 AM
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.
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)
LaurieA posted Tue, 18 October 2011 at 12:27 AM
Quote - I brought popcorn...
Good, I'll bring the soda.... This should be entertaining ;).
Laurie
bagginsbill posted Tue, 18 October 2011 at 12:29 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 12:33 AM
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.
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)
BDDesign posted Tue, 18 October 2011 at 12:51 AM
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?
bagginsbill posted Tue, 18 October 2011 at 12:54 AM
Kawecki:
Quote - My new LED monitor has three gammas, gamma1, gamma2 and gamma3, which one have I to use ?
=====
Kawecki:
Quote - My new LED monitor has three gammas, gamma 1, gamma 2 and gamma3, which one have I to use?
=====
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
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)
kawecki posted Tue, 18 October 2011 at 1:06 AM
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 ?
Stupidity also evolves!
kawecki posted Tue, 18 October 2011 at 1:17 AM
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."
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.
Stupidity also evolves!
bagginsbill posted Tue, 18 October 2011 at 1:26 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 1:29 AM
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."
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.
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)
aRtBee posted Tue, 18 October 2011 at 2:46 AM
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...
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bagginsbill posted Tue, 18 October 2011 at 3:22 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 3:34 AM
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)
bagginsbill posted Tue, 18 October 2011 at 3:35 AM
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)
bagginsbill posted Tue, 18 October 2011 at 3:41 AM
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.
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)
bagginsbill posted Tue, 18 October 2011 at 3:49 AM
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.
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)
bantha posted Tue, 18 October 2011 at 3:52 AM
Pretty please. We've had that discussion over and over again. I use Posers Gamma Correction and it gives much better results than using GC afterwards.
I've removed some postings here, and if this isn't going well soon, I'll lock this thread.
A ship in port is safe;
but that is not what ships are built for.
Sail out to sea and do new things.
-"Amazing
Grace" Hopper
Avatar image of me done by Chidori.
bagginsbill posted Tue, 18 October 2011 at 3:55 AM
After several attempts to position and adjust intensity, I get a pretty nice portrait. Great. Yes it can be done without using GC. But it took many steps, and lots of test renders.
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)
RobynsVeil posted Tue, 18 October 2011 at 4:03 AM
Much as I adore your explanations of the mathematics of the render engine - and studying this has shed a fair bit of light on my earlier questions and misunderstandings - I'm pretty sure that the convinced of error cannot be unconvinced even with irrefutable logic and sound explanations. I have read Kawecki's explanations, but they don't reflect an understanding on how the Poser Firefly render engine works. He keeps looking at his monitor as opposed to looking at colour-space.
I'm afraid it's a waste of time, except for the fact that I learn something every time you explain it, Bagginsbill. And I'm of fairly mean intelligence. But I am able to follow. Thank you for taking the time, once again!
The phrase: "none are so blind as those that do not wish to see" appears to apply here.
Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2
Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand]
bagginsbill posted Tue, 18 October 2011 at 4:10 AM
Now here's where the wheels fall off for many people trying GC for the first time.
They start with a scene in which they manually compensated for gamma by adding lights and increasing light levels.
Then they flip on GC and don't do anything else. What happens?
This.
This is not because GC is on. It is because GC is on with overlighting, and all the numbers now mean something different, and the results are crazy bright. There is no dark side anymore.
Even this is not nearly so bright and zapped as many users experience. I'm starting with quality shaders that do not have Diffuse_Value = 1. I'm starting with specular that was set up correctly for the GC (accurate response) situation.
If I had started with no bias towards any of the best practices in CG, and was living in the Poserverse of 2003, turning on GC would seem like a horrible thing to do.
It's not. Rendering like it's 2003 is horrible. It's really limiting. You can't change things and just render. You have to tweak all over the place, and test and test and test.
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)
bagginsbill posted Tue, 18 October 2011 at 4:14 AM
I use one inifinite or spot. I turn on IDL. All the fill lighting that I worked so hard to create earlier, to give the appearance of being indoors, is now totally automatic.
How do I light my scenes? I use one light. Or no light. Lighting is so easy it's stupid. You want to know why I use IDL + GC + Scatter? Because everything works right with zero effort. That's why.
It's not a unique result. It's a uniquely easy means to the same end.
You can prepare your image for 10 hours and still not produce the results I get instantly.
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)
bagginsbill posted Tue, 18 October 2011 at 4:21 AM
This has GC off and tonemapping at 1.6. It's not the same, but it's better than nothing.
I once posted a graph showing how a combination of tone mapping and shader GC at gamme = 1.3 could get you closer to accurate luminance results. I don't remember where that is anymore.
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)
cspear posted Tue, 18 October 2011 at 11:11 AM
Folks, please don't fart about with your (LCD) monitor's gamma setting. It was calibrated at the factory to be correct, and will take many years to significantly deviate from that ideal, if at all.
Your monitor's gamma settings may be labelled as 'Gamma 1', 'Gamma 2' etc. but these are just labels and have nothing to do with the actual gamma values they invoke. Somewhere in your monitor's user guide it will tell you what values the labels signify. You want the one that selects gamma = 2.2.
Monitors that can work in a truly linear fashion - i.e. where gamma = 1 - are pretty rare, and since I'm lucky enough to have one, I can tell you that the linear mode is useless for normal work. It's only used for hardware calibration.
When I see another gamma question posted here my heart always sinks because all the usual guff will come to the surface. Over-complicated explanations and formulae, which may or may not contain useful facts, will be thrown around and pretty soon the answer to the original question is lost in a mire of gibberish.
Unfortunately, artbee, "why do I need gamma?" is a question that invites complicated answers.
Better to ask, "Why would I want to use Gamma Correction?". The simple answer is that, as BB says, it takes the hard slog out of so many things. It makes things you do with lighting and shaders produce predictable, consistent, accurate results. You have to understand what it does and learn a few things, make some changes to your workflow, and that's about it.
Look at BB's images over the last few posts and you should be able to see why it's a good idea. That should motivate you to figure it out and use it properly.
Windows 10 x64 Pro - Intel Xeon E5450 @ 3.00GHz (x2)
PoserPro 11 - Units: Metres
Adobe CC 2017
SamTherapy posted Tue, 18 October 2011 at 11:26 AM
Quote - Look at BB's images over the last few posts and you should be able to see why it's a good idea. That should motivate you to figure it out and use it properly.
^^^^^^
This. 
Coppula eam se non posit acceptera jocularum.
aRtBee posted Tue, 18 October 2011 at 4:07 PM
thanks for the support. I got the answer doing some measurements, with just Gamma=1 (red) and gamma=2.2 (teal), and also exponential tonemapping added to them, with expo=1.6 (default) or 3.2 (double exposure). Measurements were made in all six cases, in three rounds with varying lighting conditions, and 9 points per round.
My conclusions:
when you want to post process the image, especially when exporting to HDR or PSD or working with render passes in any other way, tonemapping as well as gamma should best be off. This matches Robynsveil's linear way of work. you might take the teal curve (is about [0,0] [20,50] [50,75] [80,90] [100,100] ) for curve adjustment in Photoshop.
when you want the image just to look good without that much postwork, gamma is fine and 2.2 does the job by pumping more dynamics into the dark areas as shown in the mirror-example by BB in this thread (teal curve). However, no gamma but a serious exponential tonemapping does a similar job (green curve).
applying exponential tonemapping with 1.6 leaves the overall luminance of the image at the same level, but adds some detail to the darks while taking out some from the hilights. This is great for fashion shoots where usually the model is mildly overexposed to shift the attention to the clothes. It works just on top of the gamma effect (orange and blue curves).
tonemapping and gamma add on to each other, both pump up the darks at the cost of losing detail in the hilights. Gamma is stronger on increasing the nuances in the darks and handling underexposure, while tonemapping is stronger in reducing detail in the hilights and handling overexposure.
So, do I need gamma, and are there alternatives? Well, the final result will profit from a "serious and non linear brightness correction", that's for sure. This can be done in post, in Poser GC and in Poser tonemapping, in any combination. Doing none of them is a shame. Poser GC is a convenient way, but not the only one.
When I consider more detail in the darks the most relevant improvement to make the result look good without detailed postwork like curve adjustment and render passes, Poser GC is the way to go. Postwork instead requires the right adjustment curve and more, but is the most flexible, and the most efficient way to find the proper settings interactively. Tonemapping is an alternative that makes reducing the hilights as the most relevant improvement instead.
Take your pick.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bagginsbill posted Tue, 18 October 2011 at 4:40 PM
You should have drawn all those with the final monitor gamma applied. Then only one is a straight line - the GC 2.2. Linear is a big bow down and looks bad. The others are reasonable as artistic choices as they deviate mildly from a stright line in useful ways.
In fact, I have been experimenting with a half dozen new color spaces that can be used before and after, the way gamma/antigamma is used. Some are nonsense, but some do interesting things that you cannot get with these.
The principle is that diffuse + reflection happens in the middle, and can be skewed to do non-linear (and sometimes useful) things by twisting and bending the color space first, doing something that is normally a straight line, and then restoring it afterward, imposing a curve on what you did.
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)
aRtBee posted Tue, 18 October 2011 at 5:19 PM
When the monitor gamma is applied then indeed the G=2.2 curve becomes a straight line and the G=1.0 curve becomes a bow down, that's correct.
The G=1.0 image looks bad, that's correct too. But on the other hand, it's the best thing for input to serious post processing which of course requires the gamma correction embedding at some other point in the workflow.
Hence, whether G=1 or G=2.2 is the norm is just a matter of choice. I choose to confirm to your own (and wikipedia, and standard) graph where G=1 is a straight line, alike the photoshop 'do nothing' adjustment curve.
Happy Posing.
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
bantha posted Tue, 18 October 2011 at 5:47 PM
But if you use G=1.0 and export as non-HDR file, arent you're lacking the information to do a good GC in postwork? If you export as HDR or EXF you still have the nessesary information in the image, but these files are gamma corrected when you cut them down to a viewable dynamic range.
Am I wrong here?
A ship in port is safe;
but that is not what ships are built for.
Sail out to sea and do new things.
-"Amazing
Grace" Hopper
Avatar image of me done by Chidori.
Winterclaw posted Tue, 18 October 2011 at 7:42 PM
Why do you need gamma?
So you don't lose image information in a render and it displays properly.
WARK!
Thus Spoketh Winterclaw: a blog about a Winterclaw who speaks from time to time.
(using Poser Pro 2014 SR3, on 64 bit Win 7, poser units are inches.)
bagginsbill posted Tue, 18 October 2011 at 9:17 PM
Quote - But if you use G=1.0 and export as non-HDR file, arent you're lacking the information to do a good GC in postwork? If you export as HDR or EXF you still have the nessesary information in the image, but these files are gamma corrected when you cut them down to a viewable dynamic range.
Am I wrong here?
I was hoping this would become clear that you're right without me having to do it. It seems I'm always being argumentative. But you're right. And I discussed this twice before in GC threads. I'm sorry but truth is truth.
There is the zero-data problem. A lot of your data maps to 0 - you cannot pull out anything from a pile of pixels full of zero. This is not just black - many colors have a component so close to 0 before gamma correction that they never come out right in postwork. And then there is banding - where many slightly different levels end up in the same integer.
Basically, the rule is you want to get the levels as close to their final values as possible before you export to 8-bit for postwork levels adjustment.
That usually means that the linear, uncorrected version is exactly not what you should tell people to use, artbee.
Demonstrations of zero data and banding are here:
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)
bagginsbill posted Tue, 18 October 2011 at 9:24 PM
Specifically...
Quote - The G=1.0 image looks bad, that's correct too. But on the other hand, it's the best thing for input to serious post processing which of course requires the gamma correction embedding at some other point in the workflow.
This is the part that is exactly dead wrong. It's the opposite of the correct advice.
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)
bagginsbill posted Tue, 18 October 2011 at 9:40 PM
There is another type of adjustment that I posted called HSV GC.
For those that don't have Poser Pro, and also do not want to deal with shader GC, and also recognize that postworked 8-bit GC leads to trouble, the artistic lens and HSV GC setup can give good results.
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)
bagginsbill posted Tue, 18 October 2011 at 9:56 PM
Here is a V4 portrait in original 8-bit uncorrected form, and then postwork corrected using HSV GC.
The banding and zero data problems are really easy to see here. (Click for full size)
HSV GC is an excellent way to change the fill lighting without washing out the colors. But it cannot do magic with the data lost in the original saved render.
Please note, however, that applying HSV GC in the render itself, using my artistic lens, does not suffer the data loss at all.
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)
bagginsbill posted Tue, 18 October 2011 at 10:19 PM
Note, however, that HDR and EXR file formats do not suffer the 8-bit data loss banding problem, and by definition are supposed to be gamma = 1.
So -
Quote - when you want to post process the image, especially when exporting to HDR or PSD or working with render passes in any other way, tonemapping as well as gamma should best be off
This is almost correct. It should say:
when you want to post process the image, only when exporting to HDR or 16-bit PSD or working with render passes in any other way using floating point or large integer formats, tonemapping as well as gamma should best be off
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)
bagginsbill posted Tue, 18 October 2011 at 10:26 PM
This article is excellent.
http://www.cambridgeincolour.com/tutorials/gamma-correction.htm
Especially read section 2. Look for the gradient showing 5-bit (32 level) encodings. By using a reduced bit depth, it easily demonstrates why gamma encoding your image results in more detail preserved for postwork.
Quote - Notice how the linear encoding uses insufficient levels to describe the dark tones — even though this leads to an excess of levels to describe the bright tones. On the other hand, the gamma encoded gradient distributes the tones roughly evenly across the entire range ("perceptually uniform"). This also ensures that subsequent image editing, color and histograms are all based on natural, perceptually uniform tones.
Also, what I was calling banding, they refer to as posterization. Read this.
http://www.cambridgeincolour.com/tutorials/posterization.htm
Quote - Any process which "stretches" the histogram has the potential to cause posterization. Stretching can be caused by techniques such as levels and curves in Photoshop, or by converting an image from one color space into another as part of color management. The best way to ward off posterization is to keep any histogram manipulation to a minimum.
Which is why I said that you should save an image as close to the final levels as possible. That's how you keep histogram manipulation to a minimum.
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)
Eric Walters posted Tue, 18 October 2011 at 10:46 PM
That was me! I did exactly that. For whatever reason- these explanations and examples "clicked"- much appreciated BB and ArtBee for asking the question. I'm revisiting some previous renders. I was using a BB envirosphere and HDRI, GC OFF and trying to FIX things in the way you described. Blame 13 years of Poser Lighting compensation
Quote - Thanks Robyn.
Now here's where the wheels fall off for many people trying GC for the first time.
They start with a scene in which they manually compensated for gamma by adding lights and increasing light levels.
Then they flip on GC and don't do anything else. What happens?
This.
This is not because GC is on. It is because GC is on with overlighting, and all the numbers now mean something different, and the results are crazy bright. There is no dark side anymore.
Even this is not nearly so bright and zapped as many users experience. I'm starting with quality shaders that do not have Diffuse_Value = 1. I'm starting with specular that was set up correctly for the GC (accurate response) situation.
If I had started with no bias towards any of the best practices in CG, and was living in the Poserverse of 2003, turning on GC would seem like a horrible thing to do.
It's not. Rendering like it's 2003 is horrible. It's really limiting. You can't change things and just render. You have to tweak all over the place, and test and test and test.
232bird posted Tue, 18 October 2011 at 11:55 PM
Sorry I'm late to the thread and this won't contribute, but, I have been through all the gamma threads I have come across during my time here, and was able to understand and use GC so long as the contributing materials and textures weren't too messed up. However it did not fully click for me until I read this post and specifically this paragraph (bagginsbill, Posted Tue, Oct 18, 2011 3:22 am):
Quote - 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.
Thank you, bagginsbill.
BDDesign posted Wed, 19 October 2011 at 1:14 AM
I don't understand why it would ever be suggested that adding gamma correction in post would ever be more "flexible" or whatever. Flat out common sense tells you that the more information you have in your image in the initial render, the better it is to work with in post. I don't need to have mastered the intricacies of GC to recognize that.
bantha posted Wed, 19 October 2011 at 2:10 AM
I would not say that adding gamma correction in post is more flexible, but working with HDR images in post is. HDR do have gc=1, so if you want to profit from the high number of light levels there, you have to do gc in postwork. The profit is in the HDR, not in GC postwork.
A ship in port is safe;
but that is not what ships are built for.
Sail out to sea and do new things.
-"Amazing
Grace" Hopper
Avatar image of me done by Chidori.
aRtBee posted Wed, 19 October 2011 at 2:17 AM
lots of fun, and anyone is right.
Gamma correction itself does not lead to any information loss, but exporting to 8 bit formats does. And indeed, if your interest is in the darker areas of the images, it's a good idea to boost these first before they fall into the zero/low-value-trap where the rounding has a large relative impact. Gamma first, export later.
On the other hand, exactly the opposite holds when you're doing cloudshapes in Vue: loosing the brightness details is the last thing you want. Export first, gamma later.
When combining Poser and Vue (or anything) in post, you have to color-match (aka: linearize) both components first, then work them, then decide on sacrificing either the darker or the lighter details. Also, importing the Poser results into other imaging programs require or favor linearized inputs, like Poser itself. Of course one can decide to gamma, to export, then to import and to anti-gamma as a serious way of work, but I suggest to keep up the resolution instead: 32 or 16 bits per color instead of 8, and no JPG.
And yes, exporting render passes to seperate diffuse, shadow, specular and eventually per-light and other layers into Photoshop enables me to manage (brighten, contrast, ...) each aspect seperately. Semi-dieu's Advanced Renderer (available at RDNA) offers a lot in this but just exporting to PSD with the proper layers tickers serve as a decent first step.
happy Posing, I'm out (I think)
- - - - -
Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.
visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though
alexcoppo posted Fri, 21 October 2011 at 4:50 AM
I have uploaded an image to DeviantArt which I hope explains what is happening w.r.t. gamma correction.
The image shows only one part of the whole process (linear space -> sRGB) so it should easier to understand that the usual explanations which merge together both sides of the gamma correction process; in addition, graphs show what is happening in the linear color space.
Bye!!!
GIMP 2.7.4, Inkscape 0.48, Genetica 3.6 Basic, FilterForge 3 Professional, Blender 2.61, SketchUp 8, PoserPro 2012, Vue 10 Infinite, World Machine 2.3, GeoControl 2