So, I've generally been a convert to using gamma correction for a while now, but every now and again something crops up that makes me wonder if there arn't still a few issues with how it's been implemented in Poser (specifically render GC).

The thing that bothers me most is what happens to the shading at the terminator between light and shadow on a model. It seems to my eyes that GC overly sharpens that transition right at the terminator, leaving a harsh line. We've discussed this before but I couldn't track down the thread.

To illustrate, in the above test I have two primitive spheres, one low and one very high res (I thought there may have been a geometry issue but apparently not), lit very simply with one infinite light (similar occurs with spotlights) at 100 percent intensity with RT shadows enabled. The balls have a simple diffuse/specular material setup, one ball coloured blue. Each image was rendered using exactly the same settings except for the GC and TM options (the TM options were set at 2.2, although it's usually recommended to use them at lower settings). No IDL or SSS was used.

The results actually startled me a little, as not only did the non GC image have a better transition at the terminator, but the GC 2.2 image appears to have shading artifacts running along it (shows clearly on the coloured ball).

The TM renders have a much better transition to me, but since TM is a post filter it seems more difficult to work it's use into a linear workflow (or maybe I'm not understanding the functionality).

I'm considering a bug report to SM regarding the GC artifacts, but I want to run it by you guys to see if it's reproducable.

I'm running PP2012x64 SP1 for this test.

> Quote - So, I've generally been a convert to using gamma correction for a while now, but every now and again something crops up that makes me wonder if there arn't still a few issues with how it's been implemented in Poser (specifically render GC). > > The thing that bothers me most is what happens to the shading at the terminator between light and shadow on a model. It seems to my eyes that GC overly sharpens that transition right at the terminator, leaving a harsh line. We've discussed this before but I couldn't track down the thread.

I do not think it is overly sharpened at the shadow border. GC does make a rather sharp border, that is true. But this sounds reasonable to me. If you were to assign a different greyvalue (subjective measurement) to each pixel on a line along the equator of the sphere (red line in the illustration), you should get something like the curve on the right. It is essentially a cut-off circle, because if the sphere is a lambertian reflector, its brightness is the cosine between the surface normal and the lightvector, and in the special case of the circle, it is the same as distance to the light. So there must be a relatively sharp shadow border.
Of course, this does not automatically mean, that it looks good, even if it is realistic. It is only realistic for a specific material, which must be a very good diffuse reflector on one hand, on the other hand it must be perfectly smooth to be have a close to lambertian surface. If you look at the sphere and think of a plaster ball it might not look right, because in reality a plaster ball would not be smooth enough to be a good candidate for the default lambertian diffuse shader.

Quote -
To illustrate, in the above test I have two primitive spheres, one low and one very high res (I thought there may have been a geometry issue but apparently not), lit very simply with one infinite light (similar occurs with spotlights) at 100 percent intensity with RT shadows enabled. The balls have a simple diffuse/specular material setup, one ball coloured blue. Each image was rendered using exactly the same settings except for the GC and TM options (the TM options were set at 2.2, although it's usually recommended to use them at lower settings). No IDL or SSS was used.

The results actually startled me a little, as not only did the non GC image have a better transition at the terminator, but the GC 2.2 image appears to have shading artifacts running along it (shows clearly on the coloured ball).

I am not sure what shading artifacts you exactly mean, but on the dark side of the blue ball, there seems to be a zone that is not pitchblack like it should be, but has some very dark grey. It seems to have something to do with the specular shader of the sphere, as far as i can tell. I tried with Poser2010 and it has that not-quite-black area too and it disappears when i disable specular.

Quote -
The TM renders have a much better transition to me, but since TM is a post filter it seems more difficult to work it's use into a linear workflow (or maybe I'm not understanding the functionality).

In the end it is you who decides on how harsh the shadows should look in your image, so you can do anything. But you should be careful when using tonemapping (and GC too) on your image; when you have more things in your scene than just spheres, other parts of the image will be effected by the tonemapping, too, and these might be parts where you do not actually want it. Anyway, if you are using a linear workflow, it probably means that you use a compositing program or something like that to process your image after rendering, and probably tonemapping and GC is best done at that later stage (if possible).

Quote -
I'm considering a bug report to SM regarding the GC artifacts, but I want to run it by you guys to see if it's reproducable.

I'm running PP2012x64 SP1 for this test.

I have hesitated to say anything about this, but I do have a problem with GC and skin maps in Poser 2012. I was trying to develope a V4 package for the market place but I guess I'm shelving it for now because of this problem. GC 'washes out' the color of the skin map. Hmm, maybe I'm not explaining this well. I look at my V4 maps in my art program and then I look at the resulting render and the skin tone is paler on render than what I see in my art program. So I've wondered if GC should be turned off on skin maps so I tried an experiment where I set the color map to custom GC of 1.00 and something bizarre happened. The maps I did that on in the test render, well, they rendered nearly white. It was weird. And btw, I was using BB's light meter in my tests, so my lights weren't overblown, it's the render GC 'sucking the life out' of my texture. And sure I know that after a render you can do all sorts of corrections in an art program, but if you're making something for the market place, no post work is allowed in the demo images. So I do ask, shouldn't skin maps be anti-GC'ed? And if so, I don't know the nodes for doing such.

 

(running and ducking now)

 

Well, I use GC with a single point light and a white "filler" IBL with no map attached.

And the GC indeed "bleaches" the skin texture a little bit.

BUT...I simply use the EZSkin shader and set the saturation value to 1.05 in the HSV node.

For the attached demo I set the saturation value to 1.2 so you can see the difference better.

So, given that Poser diffuse gives us a realistic model for shading on a perfectly smooth surface, adding SSS and surface bump should naturally soften the terminator...and it does.

I must have been setting my bump way too low on my skin shaders lately as I was getting very harsh transitions.

 

Quote - I have hesitated to say anything about this, but I do have a problem with GC and skin maps in Poser 2012. I was trying to develope a V4 package for the market place but I guess I'm shelving it for now because of this problem. GC 'washes out' the color of the skin map. Hmm, maybe I'm not explaining this well. I look at my V4 maps in my art program and then I look at the resulting render and the skin tone is paler on render than what I see in my art program. So I've wondered if GC should be turned off on skin maps so I tried an experiment where I set the color map to custom GC of 1.00 and something bizarre happened. The maps I did that on in the test render, well, they rendered nearly white.

I do not know what Poser 2012 is doing exactly (if it is different than 2010), but if your texture looks too pale, by setting the gamma to 1 on the image-map node, things will only get worse. Think of it as render GC making everything brighter and importing images doing exactly the opposite (making everything darker). So disabling gamma on the import, but leaving it on for the renderer, makes everything brighter without making it darker first.

Also knowing what your art program actually does, might be of some help. Understanding what a renderer does with GC can be tricky sometimes, but knowing what e.g. photoshop or gimp do with GC can be almost inscrutable (at least in my opinion). If unsure, i usually try the whole process (from exporting the image to rendering it) with a simple 50%-grey image and hope that i get the 50% grey out again.

Quote - It was weird. And btw, I was using BB's light meter in my tests, so my lights weren't overblown, it's the render GC 'sucking the life out' of my texture. And sure I know that after a render you can do all sorts of corrections in an art program, but if you're making something for the market place, no post work is allowed in the demo images. So I do ask, shouldn't skin maps be anti-GC'ed? And if so, I don't know the nodes for doing such. (running and ducking now)

Most of the times they should be gamma corrected (because they contain something like a photograph of some skin). Either you enable the gamma on the image-map node (by setting it to 2.2 or 'use from render settings), or you can use the gamma node or color-math node i am sure there are various posts around here about that.

Do not forget that if your skin shader contains additionally a specular component (which is usually white), the result will get more desaturated and brighter than the image texture alone.

So the moral of this thread is that since very few (if any) surfaces in nature are perfectly smooth, it's a good reminder to always add some surface bump and scatter on materials, especially when using GC, or you'll get those harsh terminators.

Quote - I am not sure what shading artifacts you exactly mean, but on the dark side of the blue ball, there seems to be a zone that is not pitchblack like it should be, but has some very dark grey. It seems to have something to do with the specular shader of the sphere, as far as i can tell. I tried with Poser2010 and it has that not-quite-black area too and it disappears when i disable specular.

 

Yes, that was what I refered to as the shading artifact (terminology failure?). This seems to only occur with the specular on the Poser Surface and the specular node, but not when using any of the othe specular nodes. I'll be avoiding that from now on.

Quote - ...But you should be careful when using tonemapping (and GC too) on your image; when you have more things in your scene than just spheres, other parts of the image will be effected by the tonemapping, too, and these might be parts where you do not actually want it. Anyway, if you are using a linear workflow, it probably means that you use a compositing program or something like that to process your image after rendering, and probably tonemapping and GC is best done at that later stage (if possible).

Yes, I wasn't keen to use Tone Mapping for exactly that reason. I prefer to do any further exposure adjustments in post. I just noticed that the terminator on those renders loooked slightly more as I had expected.

The smoothest real object I have for reference is a polished composite resin ball (has a soft shine to it but is very smooth). The terminator on this looks a lot softer than the GC2.2 render of the basic diffuse.

> Quote - ... Yes, that was what I refered to as the shading artifact (terminology failure?). This seems to only occur with the specular on the Poser Surface and the specular node, but not when using any of the othe specular nodes. I'll be avoiding that from now on.

Terminology is o.k. i guess. I do not know if you noticed, but there are additionally two strange spots in the background of your GC2.2 image (see markers above). Those i could not reproduce btw.

Quote - So the moral of this thread is that since very few (if any) surfaces in nature are perfectly smooth, it's a good reminder to always add some surface bump and scatter on materials, especially when using GC, or you'll get those harsh terminators.

related issue may be IDL artifacts in corners (orthogonal surfaces) when using IDL pre-calc mode.  if there are no naturally-occurring orthogonal surfaces on the macroscopic scale,  they may always be rough/beveled/rounded when viewed up close, i.e. not perfect.  thus, representing a corner as the intersection of two flat planes, with no fine detail of polygons at the intersection, may be a bad idea in poser.

Quote - Terminology is o.k. i guess. I do not know if you noticed, but there are additionally two strange spots in the background of your GC2.2 image (see markers above). Those i could not reproduce btw.

 

There was a backdrop in the scene but it was way back and not recieving any light. IDL was disabled for this. They only appear on the GC render.

> Quote - > Quote - Do not forget that if your skin shader contains additionally a specular component (which is usually white), the result will get more desaturated and brighter than the image texture alone. > > Yes, yes, yes! This is my problem! Not GC at all. It was the blinn settings. I changed the reflectivity from 1.0 to .75 and did a few other tweeks to BB's Max Trick as delivered through the EZSkin Script and I like what I have now. Thank you so much for pointing me in this direction!

it has to do with the size of the light. sun have a sharp terminator. and a small spot and point light have a sharp terminator. you want an a areal light. but this is not possible.

hi all,

I'm about to finish and publish some extensive study on GC and TM in Poser, Vue, Post (Photoshop) and alike. In the meanwhile I'm willing to help but I'm not sure any more what the questions are at this stage.

In short: Poserpro - when image GC set to render GC, and ON - is not really applying a net GC to the full image but is sandwiching the linear rendering between gamma decode/encode steps. As a result, textures (and color swatches) present themselves in the result as they are feed into Poser but the effects of the lighting/shadowing are gamma-corrected, pumping up the darks and relatively reducing the brights. This indeed makes the transitions towards dark happen in a smaller space, with more contrast. TM on the other hand is a Post-effect only, mainly effecting the brights, and should be used to mimic the response of classic film response to strong lighting. 

Applying the first - gamma decode - step to color swatches and probably as well to light emitters (IBL, IDL) can have some artifacts indeed, but does have some advantages as well. Vue for instance is not doing that, which also presents some (unpleasant) surprises - and user complaints. The Poser artifacts do effect the color arithmatic as applied in shaders and materials, like the V4 materials (zombie look), and propably EZSkin as well.

In general: watch your material settings, as the sum of them should not exceed 1 (Diffuse+Specular+Alt_Diff+Alt+Spec+Reflection+...) to represent a net light-receptor. If it does exceed 1 (eg when adding Ambient or taking defaults) it turns the surface into a light emitter, as it's returning more light than it receives.

Questions welcomed.

PS: you can mimic softboxes / arealights with a multi-spot setup (middle+on each corner, set to 25/15/15/15/15%) or with an ambient white square and applying IDL. the latter translates quite nicely into LuxRender as well.

Quote - hi all,

I'm about to finish and publish some extensive study on GC and TM in Poser, Vue, Post (Photoshop) and alike. In the meanwhile I'm willing to help but I'm not sure any more what the questions are at this stage.

In short: Poserpro - when image GC set to render GC, and ON - is not really applying a net GC to the full image but is sandwiching the linear rendering between gamma decode/encode steps. ...

What do you mean by "net GC" i have never heard that expression? Any information about GC in photoshop would certainly be welcome, as i can find very little about that on the internet.

Quote -   ...

In general: watch your material settings, as the sum of them should not exceed 1 (Diffuse+Specular+Alt_Diff+Alt+Spec+Reflection+...) to represent a net light-receptor. If it does exceed 1 (eg when adding Ambient or taking defaults) it turns the surface into a light emitter, as it's returning more light than it receives. 

Questions welcomed.

I am not sure what that means. Surfaces in poser do not emit light in the way that light sources in poser do, regardless of how large the sum of the material settings is. Light in poser has neither a single model (specular, diffuse, reflections etc), nor does it have a  unit of measurement (like watts). So the sentence "returning more light than it receives" does not make sense to me.

net GC (netto Gamma Correction)

take a simple, flat surface in any color (Diffuse channel, value 1). Use the color swatch to know its RGB values. Set all other channels (Specular etc) to black/0. Apply a single, infinite, frontal light so no highlights nor shadows will occur. Render, and export the image. open with Photoshop, and use the colorpicker (and Info panel) to read the values.

Now the color swatch RGB (input) should equal the Photoshop reading (output). This should be the case for all gamma settings, and for all RGB (esp brighness) values. Hence; the gamma setting is not effecting the color result, no net effect. Note that this is different for the Exposure correction: it does have a net effect.

Now add a ball to the scene, it will show a gradually reducing brightness (because diffuse light is not diffused in all directions at the same amount) and it will (if posed properly) warp some shadow on the flat object as well. Repeat the experiment. Now you will see an effect of the various gamma settings, when reading out values in Photoshop.

Hence: the gamma setting does have effect on the effects of light (and shadow) in the scene. To study the effects of light instead of shadow: use Specular, with a large highlight setting.

conservation of energy

When you set diffuse to 80% white and the value to 70% as well, the surface will diffuse 80% x 70% = 56% of the light hitting the surface. The rest is absorbed. The channels Diffuse, Alt_Diffuse, Specular, Alt_Specular, Reflection, Refraction and Ambient are added up, to the final result (bump, diffuse and transparency do something different). So if these channels add up to >1 the will give a non-physical impression of emitting more light than they receive, the surface to light response is wrong. Whether they behave like a lamp indeed is determined by the IDL on/off settings.

It does not mean that you should do it, you make your own images. But deviating will hamper photorealism (surfaces too bright, highlights too strong, ...), IDL light balancing, LuxRender material handling etc. Note that all BB's shaders adhere to this "conservation of energy" rule.

As all material settings are ratios between input and output, they are dimensionless, except (I guess) for Ambient which should have some light-intensity per surface-unit dimension. When IDL is switched on, light from a sirface has the same units as light from a lamp.

Photoshop

GC as well as Exposure Control in Photoshop are easy: just apply the Curves adjustment with the proper curve. The formulas might be on the web but will be in my tutorial at least. Try (brightness = 0 .. 1):

• Corrected Brightness <= Original Brightness ^ ( 1/ Gamma )
• Corrected Brightness <= 1- [1- Original Brightness] ^ (Exposure)

where gamma =1 as well as Exposure = 1 yield no correction. Poser Exposure 1,2,4,8,16 are equivalent to Vue Exposure 0,1,2,3,4

have fun, questions welcome

aRtBee -would you be willing to take us through the process of calculating conservation of energy for a skin shader, for example as set up using EZskin?

I get the concept and it's importance, but the specifics largely elude me.

I have to confess that I still mostly wing it when considering even a mildly complicated shader setup (TBH it took me a while to work out how 80% x 70% could equal 56%).

How might we even evaluate the amount of light a realistic skin 'should' reflect/absorb? How does that translate to diffuse, specular and reflection values?

How do you make the calculations for nodes such as scatter and blinn, or reflection with a fresnel blend node attached?

I want to get to grips with this, I really do. I read bb's and other's posts (usually with a calculator to hand!) but it largely floats over my head. I think I understand quite well the concepts around 3d materials and lighting/rendering to simulate real world effect, it's just the maths that eludes me. I just about muddle through based on the work others do. I was one of those that chose to do art because I was useless at math.

That's what you're up against.

(bb will be slapping his forehead round about now if he's reading this).

 

Quote - it has to do with the size of the light. sun have a sharp terminator. and a small spot and point light have a sharp terminator. you want an a areal light. but this is not possible.

Yep, I've played a lot with arrays of spots grouped closely together to simulate a real spot, but with the simple diffuse without decent bump and scatter the terminator still looks very sharp.

Materials are important here as well as considering the limitations of the lighting.

Much in 3d is based on workarounds to approximate real world phenomena. In other apps I've noted a setting on lights to soften diffuse edges - it's not strictly speaking accurate but a simple way of emulating an effect.

How do we evaluate the values a skin (or other material) should have?

We know this from real life measurements, and optics laws in physics. As a result, these things come with photoreal renderers like LuxRender. And the word is spread by people like BagginsBill, SnarlyGribble (and me, and more). The more you're into photoreal the more it comes to those details. But for most artistic purposes, the good news is that the eye is not too critical. You can survive a long time on decent rules of thumb. Now we only have to make this accessible :)

How do you calculate for Blinn etc?

I hardly do, because most of these aspects have to do with the way light from an angle is handled by curved surfaces, like the difference between smooth plastic and rough clay. But in some cases things get awkward, like finding the proper balance between specular and reflection. Again, the closer one approaches photoreal...

Lighting & materials

yeah, real lights have a size, we do live in an atmosphere, undera sky, surrounded by light diffusing walls and objects do scatter etc. Without SSS and IDL, things keep looking like metal balls on the moon shot with a flash. Photoreal lighting and surfacing is more a career than an action point.

some example, this is V4 HiRes Wet skin as it comes with the package.

Diffuse value is 1 = 100%, color is white (100%) and the face itself is about 80% at its brightest point (nose), so Diffuse will count for 100% x 100% x 80% = 80%.

Specular value is 100%, color is say 18% grey and the brightest point on the greyscale specular map is about 80% (I guess they just turned the face texture into greyscale). So Specular will count for 100% x 18% x 80% = 15%.

Ambient value is 25%, color is red 45% which produces a 25% x 45% = 11% red glow from the body.

Alternate Specular is white (100%) times the Blinn effect, which appears about 20% grey.

As a result, our Wet Vicky returns 80% (Diff) + 15% (Spec) + 20% (Alt_Spec) = 115% of the captured light and will add the 11% glow to it.

This is fine if you do the same with other objects in the scene, it will then suggest just stronger lighting. but when you want to merge the render into a photograph, Vicky will stand out far too much with matching lighting levels.

Back to the original case, at the beginning of this thread: what happens when you apply gamma correction? Essentially it will reduce the effect of the darker color swatches, so the result with GC applied will show noticably far less Specular (18%) and less red glow (45%). The effect of the texture maps (80%) will be reduced slightly, and the Blinn will not be effected (no color swtch involved) at all which compensates the loss of specular a bit. Next to softened shadows and hilights you will experience some loss of color strenght and a less redder teint.

Here is the problem i have with this energy approach; in the images above, i rendered a simple square with a single infinite light from the direction of the camera. The left square has a diffuse value of 0.9 and no specular. As can be seen it is evenly lit with a pixel value of 244 which represents gc(0.9). The right square is rendered with almost the same settings, but this time with a specular value of 0.9 and no diffuse. As you can see the right image with the specular value is overall much darker than the diffuse square. In fact, the brightest pixel of the specular square has the same value as any pixel on the diffuse square, gc(0.9). However, the 90% does not mean that 90% percent of the light reaching the square gets reflected, otherwise the specular square should have been much brighter than the diffuse square, because the diffuse square reflects in all directions equally, while the specular square reflects mainly in the direction of the camera. Exactly the opposite is true; the 90% represent peak values, not energy amounts, so when you have a mixed specular/diffuse texture, it does not really make sense to sum those values up and thinking about energy preservation. The only drawback when ignoring those amounts seems to be that you get clipping when you have values higher than 100%, but that is because a jpeg or png file you use to save those images cannot represent pixel values higher than 255. But this is more a problem of the file format and has nothing to do with energy preservation.

Some good information here... I have been puzzling on how to apply the 'diffuse + specular <1' principle.  I hadn't though to take the colour swatch into account.

This may seem obvious to some... but how do I know, for instance, that the colour texture is at 80% at its brightest spot?

 

Also I'm a bit lost as to how the values apply in some of the alternate nodes as my poser surface diffuse and specular channels are usually zero

Quote - Also I'm a bit lost as to how the values apply in some of the alternate nodes as my poser surface diffuse and specular channels are usually zero

If you mean alternate_diffuse and alternate_specular, these channels simply accept whatever you plug into them. So, if you have a Diffuse() node - with a colour map plugged in the first channel and the second channel set to .8 - plugged into the alternate_diffuse channel, that's all the renderer will see.

Diffuse_Color and Diffuse_Value all have a diffuse node embedded in them for each light in the scene: these channels do a bunch of fancy maths with all this. Nice, but you lose precise control over your material. For instance, if you wanted to do CoE with Diffuse and Specular using the Diffuse_Color and Diffuse_Value channels at the top of the PoserSurface() node, you would find yourself at a bit of an impasse.

I'm not going to turn this thread into a physics class, but the basic idea is as follows

• light can be considered as a set of beams in loads of directions, beams can be considered as a stream of photons (bullets) fired towards a surface
  (yeah I know, there are wave interpretations too, and so on, I passed my Quantum Electro Dynamics exams. Not relevant here.)
• surface can be considered as a large field of microfacets, all with different directions. The more those directions are similar, the smoother the surface.
• when a photon hits a microfacet, there is a change A% it gets reflected, B% it gets diffused, C% it gets involved in translucency, D% it passes through and gets refracted, and 1- (A+B+C+D) it dies because of absorbsion (and heats the object).
  You can also say: A% of the incoming light gets reflected, and so on.
• as a consequence, A+B+C+D should be < 100% when representing real life stuff.
  unless of course you want to show response to hidden lights, or want the object to behave light a neon-sign, etc.
• The A% has to be divided over reflection and specular, the specular itself over specular and alt_specular. More of one means less of the other, they are all faces of the same medal (in nature!)
• The B% has to be divided over Diffuse and Alt_Diffuse, and so on.
• on top of that, surface / geometrical considerations have to be taken into account: light is not diffused, reflected etc in all directions evenly. Some model ("Lambert")for this is build into Diffuse and Specular, other models (Blinn, Fresnel, ...) are available through the Alt channels which is exactly the purpose of these.
• But since Alt_Diffuse etc just passes through what it gets, some shader builders create their own shading system by creating their own node tree with really everything in it, and route the result throught the Alt_Diffuse channel.
  Fine, with its own advantages and disadvantages.
  Fun test: set all channels to 0/black and just plug in a plain color node into Alt_Diffuse. Render. See what happens without handling the geometrics.
• Poser cheats in a lot of ways, as it's intended to get artistic results, not photoreal. So it lets you have 100% Diffuse + 100% Specular, or 100% Specular + 100% Reflection, and so on. Great, but not for photorealism.
  For that purpose, a first step is to ensure that the sum of values does not exceed 100%. The basic principle behind this is the law of conservation of energy. Physics-based renerers like LuxRender have this incorporated to a deep extent. Poser of course has not, but we can come close manually.
• Poser cheats even in more ways. So will specular respond to direct light only and not to environmental light (IDL), reflection responds to objects around and not to light at all, and so on. Great for render speed, not for physical accuracy
• whether lights emit and surfaced return lume, or watt per square inch or whatever is not relevant. No one knows what 100%-intensity exactly means for a Poser light.

whatever the internal details, the renderer essentially derives results per light per channel, and adds these up to the final image. You can do the same by hand, when you get images per light per channel you can add them as Photoshop layers, using the Screen blending mode. Doing this really properly requires some extra gamma magic, by the way (do have image gamma, but no render gamma. Do gamma at the end, in Photoshop).
When doing render passes, you can render shadows seperately, and use Multiply in Photoshop. Life is simple.

Since Poser-internally all lights, materials and render (sub)results are handled in 16bit colorformat, the first clipping is the result of exceeding the internal maximum value. Everything over 100% is just overlit. The extra bits create no extra room in brightness handling capacity, as white just reads RGB=(65535, 65535, 65535) instead of (255, 255, 255). Black always reads (0,0,0) and 16bit just gives more details inbetween.

The second reduction comes indeed from mapping that 16bit color to an 8bit color, required for most image formats and for showing things on screen. But as white remains white and black remains black, there will be mainly loss of detail and hardly brightness clipping involved.

How to measure the brightness of an area? It's the V (0..100%) in HSV. Open the image in Photoshop, open the Info panel, use the eyedropper / colorpicker and read out the value. Or whatever works in GIMP, Paintshop, Canvas, etc.

have fun, thanks for the attention, final extended and illustrated tutorials coming soon.

Didn't recieve any notifications for this thread. Sorry for not replying sooner.

Thanks for taking the time with all the info here. Gonna try and digest as much as I can and try to work out what my current shaders are doing.

Look forward to the tutorial.

A few points.  First, GC is an approximation, and it's very noticeably off by my eyes as soon as you get to darks.  Dark by cast shadow, dark by shading, or dark by color.  Doesn't matter.  It's why I kept posting about sRGB correction being better than GC correction in certain situations.  You get down to 10 to 1% luminosity on lights, and GC is almost glowingly bright before it goes pure black.  Render GC also messes up a lot of key calculations. Render GC affects Blender and Color_Math behavior at the very least, and probably several other types of nodes.  Neither is a huge deal most of the time, but for full dynamic range in extreme lighting conditions like you're using as your test, something to keep in mind.  On Blinn, I'm not sure if it's clear, but Blinn has Fresnel built into it already.  The Eccentricity is a sort of inverse Fresnel measure (how strong is the Fresnel effect).  If you use it with another Fresnel node, you're doubling down. 

But most important of all, it reminds me of the shading in NASA photos that aren't broadly lit by earth.  I think that's how something with no internal or external scattering is supposed to shade.  I'm pretty sure you're not supposed to get soft shading in a perfect, black vacuum with one light.  Poser definitely has some GI shortcomings,  so IDL doesn't soften shadows or shading quite like more accurate renderers do.  But that's not a GC issue. 

If you're focusing on people, then there's a big problem with treating the flesh like it's all one substance.  Shading in people is a combination of dermal and subdermal scattering in addition to diffuse, reflective, etc.  Subdermal is pretty short and deep, but dermal is very shallow yet broad along the surface.  So dermal can really soften the shading along the surface, which is the kind of shading you seem to be concerned with.  Trying to combine the two into one subsurface scattering phenomena means you get skin that's way too translucent in terms of seeing into the volume yet has too sharp of a terminator in terms of shading.

@carodan: what is the effect of GC on skin shaders?

These are the test results, in two posts. This post: Vicky in DAZ WetSkin, without GC  leftside, and with GC 2.2 right side. As stated earlier she loses her red glow and as you can see on forehead and between the breasts she loses some shininess (specular) as well.

Everything else is the effect of GC on the play of light: curved surfaces will stay brighter in a larger range, in order to drop to deep shadow more suddenly as you saw in your first ball experiment as well.

post 2: Wetskin Vicky is treated with EZSkin, without gamma (right) and with gamma (left). The nice thing to notice is that the skin looks more natural and above that: the water dropplets stand out more.

Except for the usual effect of GC on the play of light, GC apparently has no effect on EZSkins as such or it would be that EZSkin's soften shadows even more. That might be due to switching GC on for the skin-setup as well as for the render, I'll have to find out.

But as far as GC artefacts are concerned: you're far better off with EZSkin than without.

 

@kobaltkween

1. to my knowledge, sRGB is GC 2.4 except for a linear piece in the very darks (0.3%): http://en.wikipedia.org/wiki/SRGB . 0.3% is RGB=(1,0,0) or (0,1,0) or (0,0,1) in the (255,255,255) 8-bit color range. So I'm nterested in what you exactly mean when preferring sRGB over full GC.

2. Dark by cast shadow, dark by shading, or dark by color.  Doesn't matter. Yes it does, as far as PoserPro GC is concerned. When GC is on, textures and swatches are gamma'd (linearized) first, then rendered, and then the result is GC's (de-linearized). As a net result, the GC effectively works on shadows, highlights, non-uniform light diffusion etc, or: the play of light, only. Flatly lit flat objects (and so; dark colors) are not affected.

3. GC affects material nodes and color math. Yes is does, that's the linearize step before rendering: textures and swatches are affected in a non-linear way while some other nodes are not affected at all. This can really screw up some nice elaborated material setups.
   But the question is: is GC to blame for this, or should the developer gives himself a slap on the head for not taking care of the GC effects? Or neither of those: did (s)he build something nice for Poser finding out it does not work out that well in PoserPro with GC?

4. I totally agree that Poser is pretty limited in establishing high end results when lamp-sizes, atmospheric scattering and complex materials like skin translucency come around. But within those limitations we can be quite happy with it, given the price.

1.  Yes, I'm familiar with the equation.  And yeah, that linear bit is fairly important to the softness of shadows, IMHO.  I can see a pretty clear difference in results pretty early on.

2.  No, it doesn't matter, because the result is all GC'd.  I know because I've done tests.  Tests with low light, tests with dark colors, tests with dark shadows, etc.  I've seen the problem consistently when the range of rendered results is dark.  Dark areas have flatter shading,  less saturation, and higher contrast than with sRGB correction or regular workflow.  I can see the difference clearly as soon as I get to values I'd consider medium.   I'm not saying this difference should matter to everyone, but when someone (especially someone as familiar with GC specifically and realism and light in general as carodan) looks at GC shadows, and says, "That's too flat," it seems only fair to tell them they're right and why.

3.  I'm not talking about blame.  I'm talking about function.  If you're using Blender and Color Math nodes at all, you might need a non-trivial correction node combo for each one.  If you're using, say, EZSkin, you have several to implement.  Whether that makes a big enough difference to your results to be worth all the trouble is up to you.  But if you want to talk about, "Why are my materials not behaving accurately with render GC?" that's one big thing to look for.

1. Again, you're missing the point and adding value judgement that has nothing to do with my statement.   I'm not talking about happy or not.  Obviously people can be happy with Poser renders.  That's always been true since Poser came out.  I'm just talking about problems associated with the issue at hand.  When someone talks about how sharp shading is in Poser and associates that with GC, the fact that Firefly's GI doesn't soften shadows as much as other renderers is relevant and outside of render GC limitations.  Even if the color space worked absolutely correctly, the shading in a normal scene with an environment would still be too flat because of how the GI works in Firefly.

But just to say, it's a lot more than really advanced features we don't have (though I'm not sure precisely what you mean about atmosphere, since we have a couple of ways to implement that).   There's a lot of errors I've seen others demonstrate and that  I could personally demonstrate that involve basic features like GI, use of point lights, refraction, and the weird hybrid of raytracing and REYES rendering that Firefly does.  Errors I don't encounter in the free renderers I've tried.  

I don't see price as the defining issue, to be honest.  People within this community think nothing of paying for the only commercial Luxrender exporter out there, while Maya and Max users get theirs free.  A fair number of Poser users pay a pretty penny to use high end versions of Vue as their renderer.  We could talk about different free 3d tools for ages.  But none of them are as easy to use, even just at the level of how to implement a content library,  as Poser.

Given Poser's origins as a tool for 2d artists and current target audience, yeah, it's got a pretty impressive renderer that's gotten noticeably better with each implementation.  I really appreciate the innovations.  But that's completely irrelevant to a discussion on why carodan might find shading termination too harsh when using render GC and what to do about that.

1 & 2, see figure.

gamma 2.2 and the sRGB i/o translation show noticeable differences when brightness drops below 2%. The GC output values are far higher, therefor sRGB makes a slower transition from dark to bright indeed. Since - in 8-bit mode - there are only a limited number of brightness levels available due to quantisation (RGB require whole numbers 0..255) one either has to export in 16bit HDR/EXE or has to export with GC first, and put things back to sRGB in post later. From personal experience, the latter is recommended.

The slower transition from dark to bright as offered by sRGB is preferrable indeed as for compensation of: real lights not being point lights and hence make softer shadow edges, and real life atmosfere scattering light around, hence making softer / brighter shadows too. And more of the other things that make Poser a non-photoreal tool, and make firefly difer from other renderers.

On everything else: we couldn't agree more, except for the point that Poserpro GC has no final netto effect on textures (and straightforward use of swatches), thanks to its sandwiching approach. Do the test: flat object (=no shader/curvature effects), flat light (= no shadows) and the render output will be the same whatever the gamma settings, as long as image gamma=render gamma. Try again with a ball (shader/curvature effects) or with light with an angle (shadow) and notice that only those effects are affected. Vue does the same for textures, not for swatches. Hence PoserPro GC in total really differs from applying Exposure (in Poser) or sRGB / gamma correction in post, as these affect the colors too. In Poser, PoserPro and Vue (any version) textures will be corrected after rendering as much as they were before, as input, as long as input gamma = output gamma.

On the other hand, PoserPro (and Vue) really do apply the render gamma to the entire result, color included. So when - in post - the GC is taken out and sRGB (or Exposure, or else) is put in its place all is fine. Except that, especially in the darks, the swatch-colors and texture colors in the final result will differ from the original input. Whether that's desirable or not, is up to you.

Thanks so much for taking the time to create and post this information, but honestly, I don't need to "see a figure."  I've done actual render tests.  I've seen the difference between sRGB correction and GC in images.  I saw it when Bagginsbill posted his tests long ago, and I did several of my own tests.  I don't rely on theory alone.  As someone's sig says, "In theory, theory and practice are the same.  In practice they aren't."  And pretty much no one can tell a visual effect from looking at a table of numbers.  I do render tests and I do lots of just plain work with materials and lights (real use being to controlled experiments what theory is to experiments).  

I try to only post what's worth posting, but I think I have a representative enough and decent enough gallery to show something of what I've learned over the years.  As I'm sure you've done with your own gallery, which is very fun and interesting but small enough that I'm guessing it's pretty edited.

Also, I've done tests on my "studio" prop.  It's basically a cube with the normals pointed inward.  It doesn't cast shadows.  It shades completely differently with linear workflow than with regular workflow, as well as differently with sRGB and with GC.  So unless you mean no shading when you say no shadow, then I can't say I've seen the results you seems to expect.  Linear workflow means linearizing input and correcting output after calculation of the linear processes like shading (not casting shadows, just diffuse shading).   Correcting final output is what GC does.  As with any process, it doesn't matter what happened before that point, just what the results were that get fed into the new step.  So when that final conversion back to sRGB space happens, it doesn't matter how the colors that are input into that conversion were produced.

The only time there will be no change in results is when there's no calculations after linearization.  As a function, it goes Correct(Shade(Linearize(color))).  The color is only unchanged at the end of the process if the Shade(color)  = color.   My original point is that it really doesn't matter to the function Correct(y) how y was produced.  So in practice, it's not just about low light images.  The final Correct function doesn't care if y was produced by a low light on a pure white diffuse surface, a medium light on a medium grey diffuse surface on a part of the surface positioned away from the light,  a bright light casting a shadow onto a white surface, or a bright light shading a surface that has a dark diffuse color.  The relevance to this discussion being that in carodan's original examples, which seem to use a bright light and one sphere with a medium diffuse color and the other with a bright diffuse color, the difference between sRGB and GC would affect the end result as it shaded to black.  Basically, it's not just an issue when you turn down the lights, though that's when it becomes most obvious because so much of the scene is affected. 

And while I call that middle function Shade, really, it's any type of linear calculation.  Adding, subtracting, multiplying, etc. Just in my opinion, I think it would makes more sense to be able to mark inputs and images nodes for linearization rather than only being able to mark image nodes for exclusion.  I've never, in all my years of using Poser, seen a material that needed lots of colors linearized, but I know of tons that are put together assuming that color math and Blending masks are linear processes.

Testing should be done very carefully. For instance, just using the Box prop, in front of the camera, lit with an RGB=1,1,1 @ 100% infinite light or a spot with flaps full open or anything.

a) Set material to: diffuse color White, value 0,5, no specular. Render with and without gamma, and you'll find a difference on the box surface, as can be expected according to GC.

b) Set material to: diffuse color 50%Grey, value 1, no specular. Should be the same material, right? Render with and without gamma, and you'll find NO difference between those two. At least I don't. This is because color swatches (and not: Diffuse channels as a whole) are affected by the "image gamma" step before rendering.

Poser is fun, isn't it? Also try 75%grey and value 0,67, as well as 25%grey and value 2. All same material in theory, different render respons in practise. This is why just lighting a box and drawing conclusions is not good enough for me. Neither for you I guess, so please share your details, your process and your results.

c) replace the box by a ball. Since diffuse is not homogeneous in all directions but falls off at grazing angles, the ball gets darker towards the sides. This is what I called "shading" in the previous posts. Diffuse (=Lambert), Clay etc are different shaders. Set diffuse to 0/black and plug just a color into Alt_Diffuse, and you'll have homegeneous diffusion. The ball will render as a flat disk, shading gives form like shadow gives depth. 

Shading is affected by GC, it's not shadow because you'll have the effect too when Cast Shadows is switched off when rendering. When an object or part of it blockes the light onto another object or part of it, that's (what I call) shadow. It's affected by CG too. In rendering it's affected by Cast Shadows or Render Shadows Only. As a result, both effects can be seperated and recombined in post. This way, one can soften the shadows more than the shading fall-off, if desired.

What you seem to be saying is that I should do an elaborate and oddly specific test to prove what I already said: that color with no shading or other processing is unaffected by the linearization/correction process.  That is what,  "The color is only unchanged at the end of the process if the Shade(color)  = color," means.  By the inherent nature of linearization and correction functions, Correct(Linearize(color)) = color. 

To be precise, you didn't say "shading."  You said "flat object (=no shader/curvature effects), flat light (= no shadows) and the render output will be the same whatever the gamma settings, as long as image gamma=render gamma."  Which seemed to say that a flat object with diffuse shading, no curvature effects, and  no cast shadows wouldn't be affected by gamma correction changes, and it will.   If what you're saying is a completely unaltered color won't be affected by gamma correction, that was exactly the clarification I was making.  So we seem to be talking at cross purposes about the same thing.

You don't need to do very specific test to prove this.   All you need to do is feed a color or image into a channel that's unaltered, like Ambient Color, and make sure it has a value of 1, like setting Ambient Value to 1, and set all other colors/values to 0.   If you want to take shading out of the equation, just take it out.  You don't need a specific light, mesh, and light position for that.

Your statement about diffuse color and diffuse value seems to be based on an expectations that seem to me personally very odd.  The relationship you seem to expect (but not find) would require two things to be true:  Diffuse (color, value) = color * Diffuse(1, value) and Diffuse (color, value) = value * Diffuse(color, 1).   I would never have assumed one of those things, let alone both, about Diffuse or almost any other node, shading or otherwise.  But I'm kind of weird, and I totally get why you or any other normal person might have made that assumption.   Combining how color value is generally described (75% grey is usually how white * 0.75 is described, even if that's not correct in sRGB space), and that both terms are called "value," does make it seem like both statements would be logical.  And I've certainly made much less logical assumptions about functional relationships.

In terms of testing and process, I suggest you ask RobynsVeil how relevant and clear my writing about my work is to the general population.  I wrote tons to her that she found opaque (to be generous to myself about their effect on her), and she codes her own shaders like I do and follows all this stuff just as well as I do.  So she's not the average artist in terms of this stuff.  If I had time, which I so don't (I really shouldn't be engaging in this discussion at all, and wouldn't have posted if I didn't admire carodan's work so much and know that he's very conversant on issues surrounding GC), I still greatly doubt that posting the details of the many, many, many tests (easily thousands of hours) I've done with lighting and shading would help anyone.  I'm not even sure this discussion will be at all relevant to carodan, and he's really up on all this stuff and this discussion isn't nearly as in depth as what you're talking about would be.  I'm sure my long posts make it seem like I just want to impress people, but really I only post to try to clear things up.  In my experience, going on about my own work doesn't clear things up for anyone.  I already post too much when I post at all. 

And on that note, I'm going to bow out of this thread and stop derailing it.  I appreciate the conversation and the time it took you.  It's been an enjoyable discussion.  If you, or anyone else for that matter, has any questions for me, please PM me (I'll be unsubscribing).   I think I've posted much, much more than my fair share here, and I appreciate people's patience so far.

I am reading but too busy to respond as this is a very complex topic. I would suggest that English is failing and the language of math would be more useful.

In the parlance of matmatic, we linearize (anti-gamma correct) using AGC(image or color) and we do final gamma correction using GC(color).

We all know that:

GC(AGC(color)) = color

not a surprise.

You also know:

GC(Diffuse(AGC(color))) != Diffuse(color)

This is very succinctly saying what required a ton of words.

Here, I think you will find a surprise:

color * GC(Diffuse(WHITE)) = GC(Diffuse(AGC(color))

I will let you ponder the implications of that for a while. It fascinated me when I understood the implications.

BB, can you explain your Diffuse() function?

I might guess that you're referring to the Lambert / Clay / etc like effects of non-homogenous distribution of diffused light which become apparent on surfaces non-perpendicular to camera and light (eg curved objects and skewed planes). In that case, Diffuse() is an empty input=output function for the "flat viewing of a flat surface in the case of flat lighting". And of course, non-empty in all other cases.
But perhaps you're referring to something else, we both feel the same about guessing :)

I do know that

AGC(colorvalue) = AGC(color)AGC(value)
{same for GC, and extendable to pixel=colorswatchcolor_texturevalue*value_map for the Diffuse channel as a whole}

as far as the math is concerned. But unfortunately, as far as I can reconstruct, PoserPro is only performing the first part (e.g. on the Diffuse_color swatch, using render GC) and not the second (e.g. on the Diffuse_value). This gives a new PoserPro-AGC:

PPAGC(color) = AGC(color), but PPAGC(value)=value instead.

Since GC is performed on the render result as a whole, then in the simplified case of the 'empty' Diffuse(), we'll have

GC( PPAGC(color)*PPAGC(value) ) |= GC( AGC(color)AGC(value) )  {= colorvalue}

but = color * CG(value) instead.

The other way around, as far as I can reconstruct: Poserpro performs the AGC on the elements before assembling them to a final shader, is does PPAGC(color)PPAGC(value) instead of PPAGC(colorvalue), which yields a different result - while the AGC itself does not.

Poser is fun.

And... which implications are you referring to? I love surprises. To me it says that you can leave all your lights and materials white and multiply the result - in Photoshop, with a color layer. Which is exactly the way the "Max and Milton" image was created!

http://www.3dtotal.com/index_tutorial_detailed.php?id=1408&catDisplay=1&roPos=1&page=1

In the meanwhile, we've hijacked Carodans thread. Sorry for that.

Quote - GC(Diffuse(AGC(color))) != Diffuse(color)

 

I take it the exclaimation point is for emphasis, and is not indicating a factorial?

I interpreted |= as: not equal.

To me it says that the AGC/GC-sandwich is actually doing something, provided that the Diffuse() is doing something. Which is exactly my point, when Diffuse() is not doing something and turns input=>output as 1:1 than the sandwich is not doing anything as well.

Quote - I interpreted |= as: not equal.

Ahh-that makes much more sense ...

 

Edit: Here it is in case it comes up again... ≠

While I have only a rough grasp of the specifics being talked about here, I do think it's a relevant discussion and anything that can help to clarify the notion of GC and it's use in Poser can only be a good thing.

I suspect I may require the glove-puppet explanation, despite my being reasonably adept at crafting 3d renders with reference to other images and RW observation.

Do continue.

carodan; thanks. GC is an animal, and Poser GC is a beast.
We'll have to eat it slice by slice (as in: once you've shot the elephant, how do you cook it properly).

I just noticed the scatter colour on the scatter node works on the material option (apple, skin1 etc) regardless of whether you've ticked the 'use material colour' or not.

Is this supposed to be how it works? I always assumed when 'use material colour' box was unticked it meant it was using whatever was hooked up to the 'colour' for it's scatter colour.

The above were rendered without 'use material colour' ticked, but rendered the same when ticked. (ketchup and apple were left selected in the material dropdown)

While not directly related to GC, it does affect part of the soloution for softening the terminator.