Hi RV:

I'm sorry I didn't answer your recent questions. Some of the questions are big, like how to automatically lay out nodes in a way that will facilitate parameter jiggling in the material room. I've been thinking about how to add that to matmatic in a standard way that is both convenient and flexible. I don't have a solution yet, and don't have a lot of time. I'm about to go on vacation for a week (leaving Saturday) and I have a lot of paid work to do first.

Regarding math node generation, it's pretty simple. Using any of the math operators, if both operands are known constants at compile time, the math is done at compile time.

For example, suppose a = RED and b = GREEN, then a + b is YELLOW, not a Color_Add(RED, GREEN).

However, when you wrap constants in a Node, such as a = SimpleColor(RED), then a + b is not YELLOW. The assumption here is you wrapped RED in a node because you want that node in the shader so people can change it. Which means we can't conclude the answer is YELLOW - the addition of the two colors must be deferred until render time.

Hope you have a great holiday (vacation), Bill!

Just real quick - you said that if I select a colour via the colour-picker, then  it needs to be linear colour-spaced (anit-gammaed) before processing, just like any jpg images coming in.
I interpret that as: anything I reference via IColor(255,0,0) is colour-picker stuff (because that's where I'm looking at a colour to select it and typing in those values based on what I see), whereas Color(1,0,0) wouldn't be? Am I on the right track?

And do have a great time! Looking forward to your safe return (and piccies, if you have any... :biggrin: )

Ummm.

IColor(255, 0, 0) and Color(1, 0, 0) are identical.

The difference is merely a unit change - like Fahrenheit versus Celsius.

0 degrees C is not different from 32 degrees F, just because one number is 0 and the other number is 32.

The reason to anti-GC or not has nothing to do with how you typed it in. It has to do with what you're trying to represent and how you'll use it.

For example, if you're trying to use a color multiplier that decreases green by half, you would NOT want to convert that. That isn't a color that has a specific appearence when you read it off as an RGB value. Rather, it is a tuple that has 3 components, each of which is to be used as a multiplier, so the correct value is Color(1, .5, 1) or IColor(255, 127.5, 255) - it doesn't matter how you say it, it matters how you arrived at it and how you'll use it.

If you arrived at a color by choosing from various values on the basis of how they look on the screen in sRGB color space representation, then you want to convert that to linear (anti-GC) before you use it.

Consider creating a gradient from pure 100% BLUE to pure 100% RED. What color would be in the middle, and how bright should it be? Intuition tells me that it should be a MAGENTA hue in the middle, but how bright?

Consider this script:

a = Color(0, 0, 1)
b = Color(1, 0, 0)

x = (U - .5) * 1.5 + .5
nonLinearGradient = Blend(a, b, x).labelled("nonLinearGradient")
linearGradient = Blend(a ** 2.2, b ** 2.2, x).labelled("linearGradient") ** (1/2.2)

combination = Blend(linearGradient, nonLinearGradient, .5 <= V)

Surface(0,0,0,0, Alternate_Diffuse = combination)

If you put that on a square, it renders the non-linear gradient on the upper half and the linear gradient on the lower half.

The linear gradient produces a bright magenta, because both of the end colors are bright. The non-linear gradient produces a very dark magenta, and the red and blue each dominate until you're nearly in the middle. The linear gradient is the correct path through the color space from blue to red. The non-linear gradient deviates towards black in the middle of the transition, because those colors with darker values for red and blue do not display with the correct luminance.

a = ORANGE
b = BLUE

a = Color(.2, .9, .7)
b = Color(.8, 0, .6)

a = SKIN
b = BLACK

The upper gradient is what Poser renders with a skin color and you don't do GC. The lower gradient is how the skin renders with GC. This is why a GC shader looks so much better for human skin.

If you force yourself to imagine the lower (linear) gradient is 3D, you can convince yourself you're looking at a cylinder, not a flat surface.

Straight-forward enough... thanks for the samples. For my makeup, I've chosen colour from the MS colour picker - which looked bright enough on my screen. I will need to convert to linear before I manipulate it with Blenders and Spots and such (and then gamma the result - I call the node "sRGB Out") before I plug it in to PoserSurface.

Thanks for taking the time to explain that, Bill. Have a good vacation.

Some observations:

I'm doing all these gamma-correct conversions to clothing and hair and so forth, and am having some interesting times with the shaders some people have put together. For one thing - and I see this ALL the time - people are setting PoserSurface.Specular_Value and Diffuse_Value to 1. Both to 1.
Doesn't this violate the conservation of energy law?
I think I know why they do, though. If they did try to do the CoE thing using those channels, the colour in the preview pane would be shockingly dark (because they haven't converted the colours to linear colour space, for one).

Regarding node creation (and how to avoid it)... if I do this:

gcVal = Add(2.2)
clrBlue = IColor(0, 0, 255) ** gcVal

...I get a Colour_Pow node (as well as the Math_Functions(Add) one). If I do:

clrBlue = IColor(0, 0, 255) ** 2.2

...I don't. I now have a linear colour space version of the colour I wanted which I can process. If I want to use it - say - in the Diffuse_Color channel, I would just:

clrBlue = clrBlue ** (1/2.2)

...just before doing:

s = Surface(1, 0, 0 ,0)
s.Diffuse_Color = clrBlue

...and the sRGB version of the colour would display.

Am I getting this?

I'm trying to catch up on Gamma here... can someone veryfy that I'm understanding this right...
Different monitors are likely calibrated at different Gamma (is it Gamma range)?
I gather most PC monitors, out of the box, are around 2.2 gamma range? (At least when I load Gamma chart in themonitor at work, that's the value I read.

My monitor at home, which is extra bright, reads at Gamma 1.5 (at current settings, which I like). However, before I post something online, for others to view, I should adjust this image so people with your average gamma 2.2 monitors can see it, and it not being dark and muddy looking?  Photoshop has gamma adjustment, so I should be able to just tweak the gamma setting... While on my home monitor it will look a bit washed out, it'll look fine on your avearge PC monitor?

In general terms, am I understanding this right? I read parts of the thread, but I'm getting too lost in specific terminology to really follow it. I need it broken down in plain english, so I can start catching up.  Thanks :)

By the way, I'm using this to read/check/adjust gamma on my monitors and images.
http://www.photoscientia.co.uk/Gamma.htm#menu

Oh boy. So you decide to bring up the complicated scenario, heheh.

Monitors are supposed to be set so that they display sRGB content directly, which is approximately a gamma of 2.2.

Any material that is constructed while staring at the results on such a monitor (such as hand-drawing a texture color map) is encoded with the gamma level of the monitor at the time of construction. I don't mean the data is impacted in some way, I mean that the human making color choices was impacted by the gamma of her monitor. So you need to respect the monitor response curve that the author was using, not you, when dealing with her material as incoming material that requires anti-GC.

Now if you want to design an output for your extra bright gamma 1.5 monitor, then you want your outgoing GC = 1.5, but you STILL need your incoming anti-GC to be 2.2, unless the incoming material was designed while LOOKING AT YOUR MONITOR. If you judged a color combination nice on your monitor, you must assume that the linear value is anti-GC(1.5). If the incoming material was judged nice on somebody else's workstation, then you must assume they were using 2.2.

In that linked gamma discussion, the guy suggests adjusting for gamma=1.8 and says supporting stuff that will get you in trouble. Stuff such as:

"A gamma of 1.8 agrees fairly well with the output of most printers. "

Wrong. All printers today, especially photo printers, expect photos/images in sRGB color space, which is much closer to gamma=2.2 than 1.8. The only reason there are printers at all in 1.8 is because graphics work used to be the realm of Mac users and Mac used to be 1.8. Hello - that hasn't been the case for 10 years now - the Internet has changed all that. Mac is now 2.2, and far more people LOOK at images on 2.2 than 1.8. Far more. Like a factor of 10,000 to 1.

"It gives Mac users one less excuse to sneer, and they do enough unwarranted sneering as it is. "

Old news - Mac is now 2.2.

He also said this: (underline added by me)

Quote - There are a number of gamma checkers and so-called 'calibration' patterns out there on the web that will give an entirely false reading or setting of your system gamma.
They're all based on the same fallacy: That of using a dithered pattern which is too small to properly represent the correct brightness value(s). (For the technically minded; the problem is caused by the risetime of most monitor hardware not being sufficiently fast to turn from full black to full white in the space of a single pixel, or even two, in some cases.)

Hello dude it is 2009 - nobody uses scanning monitors any more. We all have LCD displays where each pixel is a real independent device and can show any color perfectly regardless of what its neighbors are showing.

Quote - Some observations:

I'm doing all these gamma-correct conversions to clothing and hair and so forth, and am having some interesting times with the shaders some people have put together. For one thing - and I see this ALL the time - people are setting PoserSurface.Specular_Value and Diffuse_Value to 1. Both to 1.
Doesn't this violate the conservation of energy law?

Yes although your interpretation of it is not correct either. This is really complicated and I don't have time to explain it. I'll summarize, and hopefully that's enough:

It sounds like DV + SV <= 1 is a good rule, but it doesn't work out. The reason is that the specular value is not the whole story - the angles have to work out as well. Further, if the DV is .8, the SV can still be 1 (100%), but it means the specular effect has stolen the opportunity for the diffuse effect. This means that where the specular is strong, the diffuse is suppressed. I do this in my shader like this:

spec = Specular(whatever)
#or
spec=Blinn(whatever)
#then
diff = Diffuse(diffColor, .8 * (1 - spec))

This is not perfectly accurate physics, but it's closer than anything else you could do with Poser, at least until I think of something better. Look at the VSS shader - it is done this way.

Quote -
Regarding node creation (and how to avoid it)... if I do this:

gcVal = Add(2.2)
clrBlue = IColor(0, 0, 255) ** gcVal

...I get a Colour_Pow node (as well as the Math_Functions(Add) one). If I do:

clrBlue = IColor(0, 0, 255) ** 2.2

...I don't. I now have a linear colour space version of the colour I wanted which I can process. If I want to use it - say - in the Diffuse_Color channel, I would just:

clrBlue = clrBlue ** (1/2.2)

...just before doing:

s = Surface(1, 0, 0 ,0)
s.Diffuse_Color = clrBlue

...and the sRGB version of the colour would display.

Am I getting this?

Yes, but perhaps you don't see the correct reason. You stopped using a variable and that isn't the difference. The difference is 2.2 versus Add(2.2). The value 2.2 is a number, while the value Add(2.2) is a Node that generates that number.

gcVal = 2.2
clrBlue = IColor(0, 0, 255) ** gcVal

is the same as:

clrBlue = iColor(0, 0, 255) ** 2.2

but not the same as:

gcVal = Add(2.2)
clrBlue = iColor(0, 0, 255) ** gcVal

Because you're asking me to clarify the rule here, I thought it necessary to make the distinction. In you example, you changed two things at once, and so it's not clear why there is a difference - either or both changes may have caused the delta. The reason is the value of the operand - doesn't matter how you typed it, either as a constant or a Python variable, if it is a number, it's dealt with at compile time. If it is a node, it's dealt with at shading time.

RV: You had the CoE stuff correct in your example CoE thread at the Node Cult.

Set up specular node

setSpec = Blinn(1,.4,.65,.4)

Set up the Diffuse node, keep it from exceeding conservation of energy with Specular

setDiff = Diffuse(linearColormap, .**7 * (1 - setSpec)).**labelled("Set Diffuse")

Quote - Oh boy. So you decide to bring up the complicated scenario, heheh.

Monitors are supposed to be set so that they display sRGB content directly, which is approximately a gamma of 2.2.

Any material that is constructed while staring at the results on such a monitor (such as hand-drawing a texture color map) is encoded with the gamma level of the monitor at the time of construction. I don't mean the data is impacted in some way, I mean that the human making color choices was impacted by the gamma of her monitor. So you need to respect the monitor response curve that the author was using, not you, when dealing with her material as incoming material that requires anti-GC.

Now if you want to design an output for your extra bright gamma 1.5 monitor, then you want your outgoing GC = 1.5, but you STILL need your incoming anti-GC to be 2.2, unless the incoming material was designed while LOOKING AT YOUR MONITOR. If you judged a color combination nice on your monitor, you must assume that the linear value is anti-GC(1.5). If the incoming material was judged nice on somebody else's workstation, then you must assume they were using 2.2.

Gotcha :)
That sounds a lot like what I've been doing...  When I make an image, I make it for a particular 'output' device... It varies from a printer to a printer, and what monitor...  So, if I want something to look as intended on the average monitor, I need to make it look a bit washed out on my main monitor (I have an older one here I can always look at)...  For the most part, after you've done it enough time, it can be done just visually, sort of winging it.

I was doing a quick little informal poll, as an extension of a thread here: http://forum.daz3d.com/viewtopic.php?p=1778953&flatnum=1 regarding how many people see the image as relatively dark, and whom sees it as acceptable. I was curious, because over time I fot the impression that in Poserdom there may be a larger then usual percentage of people with higher quality, brighter monitors then on the average....

So, I wonder if that info, or an educated guess is of any use to me, whom should I target, your usual 2.2 gamma monitor, or graphics people whom have likely tweaked it (or your graphics hobbyist whom I've seen in the past making thise tweaks to their monitor settings to what just looks good, without being fully aware of wht they're doing exactly.

Of course, if I was doing a regular graphic, for a wide audience website, I'd probably calibrate the image so it looks right at gamma 2.2... or something in between 1.8 and 2.2... actually, probably stick to lighter colored images and color schemes... they tend to be a bit more 'web safe' when it comes to monitor Gamma.

In Rendo Gallery, I posted images that looked good on my bright monitor, with no adjustments, asking people if they look too dark.... and usually more answers are that it's not, rather then it is...  But then again, I know that is highly subjective.

Anyway, when I saw you post a reminder about gamma correction, I was scratching my head wondering, what Gamma value do we optimize them for... and was reluctant to ask for a while.  I think it's sinking in now, you want people to stick to optimizing for around 2.2.

Quote - In that linked gamma discussion, the guy suggests adjusting for gamma=1.8 and says supporting stuff that will get you in trouble. Stuff such as:

"A gamma of 1.8 agrees fairly well with the output of most printers. "

Wrong. All printers today, especially photo printers, expect photos/images in sRGB color space, which is much closer to gamma=2.2 than 1.8. The only reason there are printers at all in 1.8 is because graphics work used to be the realm of Mac users and Mac used to be 1.8. Hello - that hasn't been the case for 10 years now - the Internet has changed all that. Mac is now 2.2, and far more people LOOK at images on 2.2 than 1.8. Far more. Like a factor of 10,000 to 1.

"It gives Mac users one less excuse to sneer, and they do enough unwarranted sneering as it is. "

Old news - Mac is now 2.2.

Thanks Bagginsbill :)  Good to know Macs have gone away from 1.8
I actually never worried about gamma numbers too much, but have managed to develop a visual sense for 'how it needs to look on my monitor so it pronts well on my photo printer' etc...

Thanks for the info :)

Thanks, BagginsBill. I have that CoE expression in pretty much any shader solution replacing a shader with both diffuse and specular. Since I do move the connections from those top channels down to Alt _Diffuse and _Spec, I was hoping for a decent idea of how to go about assigning diffuse and specular values, since the usual DV = 1, SV = 1 I'd be replacing wasn't going to be much of a guide.

Just trying to do maths: what exactly sort of value would Blinn(1, .4, .65, .4) yield? IOW, which channel of Blinn would be yielding the value that:

.*7 * (1 - setSpec))
**
would be evaluating? Looking at channels, it's not like we're comparing apples with apples... both have a color channel as the first one, but whilst diffuse has value, what Blinn yields must be some sort of composite of the rest of the channels. According to your node reference, Blinn yields a colour, and since:

"You can mix Colors and numbers in your arithmetic. Whenever you use a Color and a number, Matmatic first promotes the number to a Color (using the one-number rule)"*

what does happen in that expression? Or is it so complex a calculation involving far more than I could ever get my head around that I would simply be best off just accepting that:
.7 * (1 - setSpec)
is a good default Diffuse_Value to set for Diffuse, and to use the Blinn values as outlined above for most specular-type node replacements.

Just to show my line of... um... thinking... lets say that I'm using a Blinn node where:
Blinn.Specular_Color == WHITE (as in: Color(1, 1, 1))
...does it follow that setSpec == 1?
..in which case,
.7 * (1 - 1)
... no, that can't be right. That would have a value of 0. So, Blinn must yield some other number made up of maths done internally. As would Phong or Glossy or any of the other specular nodes.
I'm probably nowhere near understanding this, as this line of thinking must suggest. And I really am trying to break down questions into single units, although I don't do real well at that.

I have a 2-year old Intel iMac with OS X 10.4 (Tiger), and I was sure I had seen the gamma figure of 1.8 somewhere in my setup, long before I had any idea what it meant. So I just ran through the OS X 'Display Calibrator Assistant' again, now that I know a bit more about what it's doing.

It indicated that my iMac display does indeed have a NATIVE gamma response of around 2.2. In fact, my results showed just over 2.3, but of course it's quite a subjective process. It might well be 2.2 after a few refills of my Friday evening wineglass.

But my default iMac display profile specifies a TARGET gamma of 1.8. This probably means that most Mac users are still in fact using an output gamma of 1.8, unless (like me) they re-calibrated their displays and are now using a custom calibration profile with gamma 2.2.

In the 'Simple' mode of the OS X Display Calibrator Assistant there are just two options for target gamma (see screenshot). That's pretty clear. The 'Expert' mode, however, has a slider going from 1.0 to through the ceiling, and by way of guidance says "In most cases it's best to use the Mac Standard gamma of 1.8". Not very helpful.

On a Mac with the default Target gamma of 1.8, both sRGB and GC(2.2) images will appear over-corrected in comparison to what the artist intended. (Put simply, if not entirely accurately, too bright).

And images made by the artist using the same Mac will appear under-corrected when viewed on an sRGB PC display. (.. ditto ditto... too dark).

So I think the simple message to Mac OS X users in this community should be... run the OS X Display Calibrator Assistant in Simple mode, and set your Target gamma to 2.2.

ducks and runs for cover

hehe - agreed!

(edit) and " interested in seeing images as other artists intended"

I think that dialog is so amusing.

What the Mac calls "Standard Gamma" is not a standard at all. It is used by a handful of starving artists out of a stubborn belief that different is better. These people wear black at all times and have pieces of metal sticking through their noses and eyebrows. They wear glasses that make them look Swedish.

Meanwhile the real gamma as used by every digital camera from $10,000 pro gear to the cheapest pocket point-and-shoot, the gamma used by the display of every cell phone, the gamma found on over a billion PC's, the gamma that appears in every single live television production in the universe, that gamma that every television ever made implements, that gamma is the "non-Standard" "Television Gamma". LOL

Seriously, why would you want your image to not be set for correct display on over 10 billion devices. Why would you choose to have it look right on just a few hundred thousand? (I know there are more Mac's than that, but most are no longer running gamma 1.8)

At least in Simple setup mode they had the sense to call it "traditional" rather than "standard".

In your final parentheses you seem to be implying that at some time during the last two years (after I bought my Mac) OS X started shipping with a default display profile specifying a target gamma of 2.2, instead of the 1.8 that mine had out of the box.

I wouldn't bet on it, but I rather suspect that they are still shipping with 1.8. I'm going away to check...

From what I can determine, the default display profile is going to change to gamma 2.2 with the shipping of OS X 10.6 Snow Leopard.

So all you Rendo Mac users out there... switch your display profile to gamma 2.2. You know it makes sense, or the men in black wouldn't be doing it!

I am using a Toshiba laptop running a NVDIA GEforce Go 7300. I brought up it's control pannel and it says that my gamma is set at 1.00. If I move the gamma slider to around 2.20 (I can't imput the exact number just move the slider and the closest I can get is 2.25), then the screen is blown out too bright and washed out. So I put it back to 1.00.

Quote - I am using a Toshiba laptop running a NVDIA GEforce Go 7300. I brought up it's control pannel and it says that my gamma is set at 1.00. If I move the gamma slider to around 2.20 (I can't imput the exact number just move the slider and the closest I can get is 2.25), then the screen is blown out too bright and washed out. So I put it back to 1.00.

And thus the confusion rises, unabated. Not your fault, but NVidia.

The gamma control they are showing you is how much correction you want to put onto your system gamma.

The system gamma is the total gamma built into your system - which includes operating system GUI software, graphics driver software, graphics driver hardware, your monitor hardware settings, and the monitor pixels themselves.

Monitor's actually have a physical gamma of 2.5. The system gamma brings the remaining gamma to 2.2, which is the standard. But you can force it to lower. The gamma you're looking at is your NVidia driver gamma correction. You can adjust that and alter your system gamma. For example if you set your NVidia driver gamma to 1.4 then your system gamma will become 2.2 / 1.4 = 1.57, which means your monitor would start to behave like ConnieKat8' monitor.

What, if anything should I adjust? Because when I try to follow your advise and gamma correct my Poser render to 2.20, then the resulting render is blown out too bright. The most I gamma correct my renders is 1.00. 

1.0 stands for no gamma correction. So if the most you correct is 1 = no correction, you don't correct. :) And I know you GC your renders because you're using VSS right, like your avatar? VSS has GC 2.2 built in by default. You don't need to do anything but use it and you are gamma correcting by 2.2, which is why it looks good on your monitor and my monitor.

You should not adjust anything unless you believe you work doesn't look good. I see it as excellent - so I think you're all set.

Let's be clear:

We keep making these two phrases "my gamma is" versus "my gamma correction is" - these are two different things.

Your monitor gamma is 2.2. You NVidia gamma correction is 1.0. That means you need/want a 2.2 correction in the render.

If you were to change your NVidia driver gamma correction to 2.2, nothing the rest of the world publishes would look right to you. Just leave it alone. Gamma correction in the driver is only to bring your monitor gamma back to 2.2, not to make the monitor gamma 1.0. You do NOT want your monitor gamma at 1.0, you want it at 2.2. If it looks like 2.2, then you should leave hardware gamma correction turned off - i.e. leave the NVidia setting at 1.0.

Thank you, I was beginning to get very frustrated because from what I read it looked like I was going about my rendering process all wrong. Yes, I use VSS now almost exclusively on my figures. I had bought and used the Realskin system by face_off. It's good and gives good render results. However it is light dependant. I have to run the script every time I change my light set up, which I might do several times before I get what I want. VSS only needs to be run once, unless I completely switch texture maps. Thank you so much for clarifying this for me! I will feel less frustrated now as I follow the VSS discussion thread.

Just so you know, you can run, for each texture, run VSS once and never run it again, even if you switch textures.

When you have a texture set that has been VSS'd and you're happy with it, save the figure's materials as a material collection. Then in the future, you just load that collection again. You never have to use VSS again with that texture.

Okay, I 've heard of people saving material collections, but I haven't figured out how to do that. If you've a minutes, could you explain that?

It's simple. With the figure selected and any material from it in the material room, click the + button in the library.

The dialog pops up to ask for the Set Name. Before saving, change the radio choice from "Single Material" to "Material Collection", then save. All the materials of the figure will be combined into one item in your library.

In the future, select a figure, open material folder, navigate to that collection and double click it. All materials of the figure will be restored.

Save as many of these as you like with different settings.

Duh! figuratively slapping forehead Thanks BB!

Hi all, juste a little stupid question, now i have migrated to poserpro, when i load a texture do i need to to load it with the gamma render setup or with a specified gamma value ?

Thx

As I understand it, the gamma-correction shader is not necessary for Poser Pro users. You simply enable GC and Poser Pro does the process internally.
This thread is addressed to Poser users who do not have that feature in their version of Poser: Poser 5, Poser 6 and Poser 7.

Quote - Hi all, juste a little stupid question, now i have migrated to poserpro, when i load a texture do i need to to load it with the gamma render setup or with a specified gamma value ?

Thx

Whether you use render Gamma Correction built into Poser Pro or material Gamma Correction as I've been distributing, you have Gamma Correction in either. The important thing is not to have double GC by running GC in both.

Poser Pro's built-in GC will have the advantage of fixing up nearly every material you have that was not designed with GC in mind. However, it will a couple of small disadvantages as well.

* It will anti-GC incoming material such as images, even if those images are data not colors we look at. For example, transparency maps and displacement maps are linear data already. You must instruct Poser not to anti-GC these data sources. However, you don't need to do it for every occurence - just once per source file. It will remember your choices even after starting a new scene. And there is a Python script to help with that, disabling GC on all transmaps and displacement maps in your scene.

• To avoid doubling the GC, you'll have to go into any materials from me (Bagginsbill) and set the GC value to 1.0 because everything I distribute now is a GC material. This includes all VSS shaders. As time goes by and everybody moves onto versions of Poser with built-in GC, I'll stop distributing GC materials.

I suggest you use the Poser Pro built-in GC at 2.2. I do it all the time now and find it very convenient.

Thx for the answer !

Personally, in today's economic times, I don't think people are going to spend the requisite US$100 (which for me in Oz equates to more like AUD$160... far too dear!) to upgrade to Poser Pro for only that reason. Unless SM - or whoever markets Poser in the future - applies some really aggressive marketing scheme to upgrade to Poser 8, I don't see myself upgrading: can't afford it.

So, this solution you've offered, Bill, is one that will continue to be valid and important for thousands of Poser artists for some time to come.

bump.

start using gamma correction. if you have poser pro you have it in render settings. if you dont have poser pro use GC in the material room.

here is a mini tutorial
www.renderosity.com/mod/forumpro/showthread.php

I've written a quick-and-dirty "How-I-Do-It"... would someone that knows please check for accuracy?

tightbytes.com/wordpress/

The best way to learn is to attempt to teach.

this is BB's GC shader

why is it wrong? did they do a mistake?

 The setting may depend on the monitor display setting which is 1.  Essentially 1 is equal to 2.2!  Open your video card display program for your calibrated monitor and notice the Gc setting.

@hborre
I'm confused, if it had to do with his monitor why would his images look different?

@iceboy
By your third image it looks like you GC'd your BB GC image, or am I missing something?

Unfortunately, the newer version of DAZ Studio and Poser's Post Manager take their Gc settings from the Video Card programs.  To test this, activate your VidCard program and slide your Gc setting from 1 to 2.2 and observe the results.  The monitor image will become increasingly brighter, not darker.  Repeat the Gc changes within each 3D app and you will get the same.  Basically, changing the Gc in this manner is not the same as other ways of correction.  I did come across an article offering a more technical explanation which I will need to find again.

Quote - why is it wrong? did they do a mistake?

Strange ... What is the better ? Using a GC shader, using postwork or setting the gamma of the screen to 2.2 and render always with gamma 1 ?

Now we have HSV tone, too many confusion i think !