Approaching Realism in DAZ Studio and Gamma Correction Demystified

kitakoredaz

Hi thank you paris (sorry to take your time :red:)

You taught me more what I expected ^^;

I simply need to crarify, if I see 0.0
in Surface Tab > parameter (Diffuse for instance) > image icon > Image Editor… > Image Gamma

ds msut apply Anti gamma 2.2 or sometimes ds do not apply Anti gamma when ds guess it is controll map.

thank you , now I can believe, ds apply reverse gamma 2.2 when send images to render,
if I see 0.0 on the image.

(I do not know the detail the difference of image gamma, (jpeg, png, tiff etc)
usually just think, images in my HDs are applyed gamma correction 2.2 already for our monitor,
then now I feel I need studying more, these image format ^^;)

And now I udnerstand, why some image gamma added as 1.0 (no correction) already.
I thought it ds auto guess,, before,,^^; but these value have been setted by vendor?

(but sometimes, I feel the value is wrong ^^; need to apply reveres gamma 2.2,,
to talk ablut detail,, I may need to offer real cases of some product,
then not do it,,,,anyway I can change if I feel, thank you much^^)

Mustakettu85

Parris said:

If the surface doesn't have gamma defined in the preset that loaded it, DS uses file extension to guess.

This is illuminating. Thank you very much for verifying!

Parris

Mustakettu85 said:

Parris said:

If the surface doesn't have gamma defined in the preset that loaded it, DS uses file extension to guess.

This is illuminating. Thank you very much for verifying!

You're welcome. But I just found out my answer was incomplete. There is more to it than that. I did ask them to confirm, but I think DAZ misunderstood my question. So now I have more from DAZ Development:

"When a property causes an image to load for the first time it does so with the default gamma of that property. Most float properties have a default gamma of 1.0. Most image and color properties have a default gamma of 0.0. So if a float property loads an image it will most likely have a 1.0 gamma. It is best to check of course but it usually does it right. The notable exception is when an image is being used in both a color and a float property. Unless the float channel is targeting the alpha of the image for some effect or the image is calibrated for use in both this is almost always a bad idea."

For those of you who are unfamiliar, you can recognize a color property by the color bar with RGB values (Diffuse Color for example). Floats have a slider bar (Bump Strength is an example).

mjc1016

Parris said:

Mustakettu85 said:

Parris said:

If the surface doesn't have gamma defined in the preset that loaded it, DS uses file extension to guess.

This is illuminating. Thank you very much for verifying!

You're welcome. But I just found out my answer was incomplete. There is more to it than that. I did ask them to confirm, but I think DAZ misunderstood my question. So now I have more from DAZ Development:

"When a property causes an image to load for the first time it does so with the default gamma of that property. Most float properties have a default gamma of 1.0. Most image and color properties have a default gamma of 0.0. So if a float property loads an image it will most likely have a 1.0 gamma. It is best to check of course but it usually does it right. The notable exception is when an image is being used in both a color and a float property. Unless the float channel is targeting the alpha of the image for some effect or the image is calibrated for use in both this is almost always a bad idea."

For those of you who are unfamiliar, you can recognize a color property by the color bar with RGB values (Diffuse Color for example). Floats have a slider bar (Bump Strength is an example).

Which is pretty much what I was guessing the situation was...except I still think, even with the float properties, image format has something to do with it. Otherwise 'color' greyscale control maps won't end up with 'wrong' guesses.

Parris

mjc1016 said:

Parris said:

Mustakettu85 said:

Parris said:

If the surface doesn't have gamma defined in the preset that loaded it, DS uses file extension to guess.

This is illuminating. Thank you very much for verifying!

You're welcome. But I just found out my answer was incomplete. There is more to it than that. I did ask them to confirm, but I think DAZ misunderstood my question. So now I have more from DAZ Development:

"When a property causes an image to load for the first time it does so with the default gamma of that property. Most float properties have a default gamma of 1.0. Most image and color properties have a default gamma of 0.0. So if a float property loads an image it will most likely have a 1.0 gamma. It is best to check of course but it usually does it right. The notable exception is when an image is being used in both a color and a float property. Unless the float channel is targeting the alpha of the image for some effect or the image is calibrated for use in both this is almost always a bad idea."

For those of you who are unfamiliar, you can recognize a color property by the color bar with RGB values (Diffuse Color for example). Floats have a slider bar (Bump Strength is an example).

Which is pretty much what I was guessing the situation was...except I still think, even with the float properties, image format has something to do with it. Otherwise 'color' greyscale control maps won't end up with 'wrong' guesses.

So, if I understand you correctly, you are saying that greyscale images that are saved as RGB sometimes get assigned a gamma value other than 1.0 when loaded by a float property. If that is the case, could it be that the creator of the preset specified the wrong value for gamma in the image editor, or is there something else going on that you have experienced? If we can make the wrong behavior repeatable, and narrow it down we may be able to get more information from the development team, or report a bug/ feature request.

Edit: Actually, come to think of it, I just experienced this myself with MacroSkin. A user reported that the skin on the torso was a different shade than the rest of the figure when Gamma Correction was turned on in Render Settings. I tracked the issue to one of my control maps which had a value of 0 in the Preset (duf). I'm pretty positive I didn't set that value, so I think it might have been assigned when the Preset was saved. So it may be that the problem doesn't happen at initial image load but rather when Material Presets are being saved out.

mjc1016

Parris said:

So, if I understand you correctly, you are saying that greyscale images that are saved as RGB sometimes get assigned a gamma value other than 1.0 when loaded by a float property. If that is the case, could it be that the creator of the preset specified the wrong value for gamma in the image editor, or is there something else going on that you have experienced? If we can make the wrong behavior repeatable, and narrow it down we may be able to get more information from the development team, or report a bug/ feature request.

Edit: Actually, come to think of it, I just experienced this myself with MacroSkin. A user reported that the skin on the torso was a different shade than the rest of the figure when Gamma Correction was turned on in Render Settings. I tracked the issue to one of my control maps which had a value of 0 in the Preset (duf). I'm pretty positive I didn't set that value, so I think it might have been assigned when the Preset was saved. So it may be that the problem doesn't happen at initial image load but rather when Material Presets are being saved out.

Ok...I've seen it happen with a bump/displacement map that is saved as an RGB jpeg, be assigned, when in the bump or displacement slot, the value you expect for a color map...0 (or guess). While changing to greyscale and resaving the jpeg it will load at 1, like you would expect a control map to load. Doesn't matter what the actual gamma is...it's just image format/location. And then, if saved as a preset, the setting becomes 'set in stone' so to speak.

My guess is that the image format 'guessing' actually over-rides the location based one. Maybe you can find out which one takes precedence?

Now, I haven't really seen it with png or tif images. Also, I haven't seen it happen with displacement maps that were baked in Blender (not sure about other ones...but none of my own baked ones had any confusion problems). My guess is that other baked maps from other modelers would be similar...and probably already correctly saved. But, with desaturated/plugin generated maps (probably because they are stuck at the original jpeg settings) it will happen.

The problems mostly seem to be with jpegs and a to a much smaller degree, pngs. I really think we need to get away from using jpegs for textures...as they seem to be the one image format with the most problems in a linear workflow.

kitakoredaz

mm,,I hope to check each case, one bye one, and most reliable way to Gamma correction,,,

eg about this hair,(the pic show default value when the hair loaded with mat preset.)

if I hope to use gamma correction, without shader gamma correction way,
DS semi-auto gamma correction ,with tdlmake(3delight texture optimizor)

how I set the, specular color, and specular strengs map gamma in image editor of DS?

As you know, both map use same image.jpg for specular strength and color.
I may need to rename, and save each exture.
then set gamma value (anti gamma, or reverse gamma) in image-editor individually for two properties?

specular color map gamma = 2.2
renamed specular strength map = 1.0 OK?

mjc1016

Why is there a map in Specular Color, anyway?

Unless you are doing something like 'glitter', there should not be a map in specular color, let alone the same one as the strength map.

kitakoredaz

Why is there a map in Specular Color, anyway?

why you ask me it :cheese: I said it is default mat preset.

====================================================
I do not think it is good plan just remove the specular color or strength map which vendor arelady added ,
without I can confirm it is just mistake.

vendor offer the hair with preset and maps to show what she planned ( adjust them for ds render)
then used same map for specular color and strength , after all it work well with non gamma correction render.

I do not think, it is only this hair. , added specular strength map which used specular color map.
as same as some vendor use same texture for bump and diffuse color map.

though,these are not good idea for gamma correction render, but most of them not suppose it.
and if it work with daz default setting render, it is not vendor mistake.

then about these case, if I hope to use each map, as same as vendor planned ,but with gamma corecttion render,
how I can do? so that I asked here with actual case.

Parris

kitakoredaz said:

mm,,I hope to check each case, one bye one, and most reliable way to Gamma correction,,,

eg about this hair,(the pic show default value when the hair loaded with mat preset.)

if I hope to use gamma correction, without shader gamma correction way,
DS semi-auto gamma correction ,with tdlmake(3delight texture optimizor)

how I set the, specular color, and specular strengs map gamma in image editor of DS?

As you know, both map use same image.jpg for specular strength and color.
I may need to rename, and save each exture.
then set gamma value (anti gamma, or reverse gamma) in image-editor individually for two properties?

specular color map gamma = 2.2
renamed specular strength map = 1.0 OK?

Your guess about what you should do is correct. Ideally, for use with Render Settings Gamma Correction, a surface should not use the same exact map for both color and control maps, because there can only be one gamma setting per image.

kitakoredaz

Paris thank you .

yes I think it is not good idea, for gamma correction render, and daz image editor,
but actually we should see these product often ,with many complex case.

(and it is not vendor mistake, I believe, though
I hope,, most of vendor take care if user hope gamma correction render too)

Mustakettu85

kitakoredaz said:

As you know, both map use same image.jpg for specular strength and color.
I may need to rename, and save each exture.

You don't have to resave. Try using the Multi Layered Image Editor in DS. Just rename the image in there and set a new gamma. Then DS will automatically create a copy of your texture for you.

But all in all, using maps this way is very "oldschool". It is not much better than painted specular on the diffuse map. These days we have anisotropic specular in UberSurface, which is free with DS. It will react to light in your scene naturally, not being forcibly limited to a narrow band in a specific place. UberSurface also has two layers of specular which allows for a more realistic simulation of hair.

Here is a basic setup I use for UberSurface on hair, feel free to expand and tweak. Make one highlight wider (glossiness about 70%), use bump map for strength and the same map as diffuse for specular colour. Make the second highlight narrow (glossiness 90%), use bump map for strength, and a lighter colour texture for specular colour. Enable anisotropy on both speculars - if hair goes vertically on the texture, then in the U direction. Adjust specular strengths in the range of 30...60% to taste.

Why bump map: because it should not have a painted "band", just the hair relief.

Unfortunately some products will come with unsuitable bump maps and even diffuse maps - where there is a highlight band right in the texture image. These you will have to edit or swap for others.

prixat

I don't know specifically if DS does this, but generally one of the "guessing" rules is not the file extension but the presence of a profile.
That might be enough trigger the anti-gamma even when the image is meant to be greyscale.

Though artistically you might want some control maps like AO and Specularity to be treated as gamma 2.2, they look better that way, but that's a whole other discussion...

mjc1016

prixat said:

I don't know specifically if DS does this, but generally one of the "guessing" rules is not the file extension but the presence of a profile.
That might be enough trigger the anti-gamma even when the image is meant to be greyscale.

Though artistically you might want some control maps like AO and Specularity to be treated as gamma 2.2, they look better that way, but that's a whole other discussion...

Not really extension...format. The actual image format info is included inside the file, in the header. And yeah, embedded profiles probably play into it, too...

prixat

I vaguely remember reading something in the 3Delight manual about testing if a file is 32bit float or half-float (and therefore is an HDR), (and therefore must be linear)
That's the only format checking I think.

mjc1016

prixat said:

I vaguely remember reading something in the 3Delight manual about testing if a file is 32bit float or half-float (and therefore is an HDR), (and therefore must be linear)
That's the only format checking I think.

It's NOT 3DL doing the format checking/image gamma setting...it is Studio running a script to do it then passing the parameters off to tdlmake (or Iray, probably). And that's where the problems start...the script that is doing the checking is what is guessing based on format/extension/location. Tdlmake is just using what it's been told to use. Just like with the LIE...internal scripting is done on the layers, to composite as a single image, before passing it off to tdlmake.

Without being given any parameters, tdlmake will assume that a jpeg is 2.2, and HDR is 1.0 and so on...but it can be passed other parameters...

Usage: tdlmake [options]  
  -envlatl         : build a latitude-longitude envmap
  -envcube         : build a cube envmap, needs six input images
  -twofish         : build a cube envmap from two fisheye images
  -lightprobe      : build a cube envmap from a lightprobe
  -skymap %s       : build a skymap using the given space/time coordinates
  -shadow          : build a shadow map from a zfile
  -dirtex          : create a "directory texture"
  -fov %f          : sets field of view for cubic envmaps (in degrees)
  -lzw             : compress texture data using LZW algorithm (on by default)
  -zip, -deflate   : compress texture data using Deflate algorithm
  -packbits        : compress texture data using Apple's PackBits algorithm
  -logluv          : compress texture data using 'logluv' algorithm (only valid with -float)
  -c-              : do not compress texture data
  -separateplanes  : write output file with separate color planes
  -smode %s        : s wrapping mode: black|clamp|periodic
  -tmode %s        : t wrapping mode: black|clamp|periodic
  -mode %s         : wrapping mode in both s & t
  -filter %s       : specify the downsampling filter (see -hh)
  -window %s       : specify filter's windowing function (see -hh)
  -quality %s      : quality mode: low|medium|high, default is medium
  -sfilterwidth %f : filter support in s (filter's diameter)
  -tfilterwidth %f : filter support in t (filter's diameter)
  -filterwidth %f  : filter support in both s & t
  -blur %f         : blur factor (>1 is blurry, <1 is sharper)
  -scale %f        : scaling down factor (must be <=1)
  -preview %f      : add a preview image with given scale or size
  -preview8 %f     : add an 8-bit preview image with given scale or size
  -flips           : flip texture in s
  -flipt           : flip texture in t
  -flipst          : flip texture in both s & t
  -mirrorx         : mirror x axis of latitude-longitude envmap
  -forcecolor      : cause greyscale input to be expanded to RGB
  -gamma %f        : gamma of input data
  -rgbagamma %f %f %f %f
                   : gamma of input data (one value for each channel)
  -colorspace %s   : input color space : linear|srgb|BT.709, default is linear                                         
  -bakeres %d      : specifies the output resolution for bake files                                                    
  -byte, -ubyte    : output 8-bit unsigned data                                                                        
  -sbyte           : output 8-bit signed data                                                                          
  -ushort          : output 16-bit unsigned data                                                                       
  -short, -sshort  : output 16-bit signed data                                                                         
  -float           : output floating point data                                                                        
  -pixelaspectratio %f                                                                                                 
                   : set the aspect ratio of pixels                                                                    
  -imageaspectratio %f                                                                                                 
                   : specifies the image aspect ratio, to set pixel aspect ratio                                       
  -newer           : only generate output if input texture(s) is(are) newer                                            
  -nomipmap        : do not create mipmapped textures (not recommended)                                                
  -progress        : display progress status                                                                           
  -v               : print version number                                                                              
  -h               : print this help                                                                                   
  -hh              : print more detailed help about some options                                                       

'tdlmake' converts TIFF, JPEG, Radiance, OpenEXR, GIF, IFF, SGI, PIC, PSD, TGA
and bake files to 3Delight's texture format (multi-image tiled TIFFs).

kitakoredaz

Hi alls I really appreciate, and now days feel very thank you, you are in here,,:)

becaues, today I get answer? from daz suport team, but actually they perfeclty miss understand
what I ask, and what I hope^^;

I send ticket as question for support,about the 0.0 gamma,
almost same thing (with more detail) as I asked here to get direct answer from daz.
but the answer was,,

Great question! (Edited , because she said so)

The Gamma correction button and the Gamma slider and the Layered Image Editor Gamma are all separate functions. The Layered Image Editor manually adjusts the gamma of a map and saves it to the map. The Gamma slider applies gamma change to the whole scene. The Gamma correction button checks the maps you have used in your scene and if they have a different gamma then your scene the Gamma correction button adjusts the gamma of the maps to match that of your scene.

I have not asked such things at all^^;
if someone reply me this answer, with my first question, I think, may better to stop ask again.

but yes I feel it is useful for some users too, and I think it is related to gamma correction of DS,
then put it . (I do not hope to say, support is not useful, but just show the fact, and
hope others udnerstand why I need forum and yours, though there is already official support)

Yes, I know maybe my english is too bad, or they are too busy, then they think I do not understand usage, then reply such.
anyway thanks all, who adivice or reply answer, even though my english is bad and, my quesiton is not clear^^;

DollyGirl

I want to thank Parris and all the other contributors to this thread for their insights, instructions, and knowledge. I learned a lot from the thread. So when I found the thread I was making some promo images for the freebie wiki and I ended up with this as my end result image in experimenting with GC. I only worked with the render option. Added in the gamma values to all of the images. Boy that took some time. I have a three spot on the figures with uberenvironment2 as the ambient. All with Parris' recommendations for light levels. Victoria is default textures but I used the V4 standard res texture secularity and bump images. I used ProjectEYEris for her eyes. She has SSS applied to her. I used uberhair and used Kettu's suggestions for how to tweek the values to get that nice soft shine on the hair. Thoughts?

Mustakettu85

Dollygirl said:

I want to thank Parris and all the other contributors to this thread for their insights, instructions, and knowledge. I learned a lot from the thread. So when I found the thread I was making some promo images for the freebie wiki and I ended up with this as my end result image in experimenting with GC.
...
Thoughts?

It looks very nice, but what I would try is increasing the specular and bump strengths a little, and softening the spotlight shadows. Actually, if you are using UE2, you don't really need a fill spotlight; UE2 will provide a soft 360 degree fill. If you are using an HDRI in it, you can rotate UE2 to see which direction you like best.

If you have a back/rim spotlight there, you could try enabling translucency channel in the hair. You can use the colour map from the second specular as the translucency colour, and add a tint.

What is the shader you are using for the skin?

DollyGirl

Mustakettu85 said:

It looks very nice, but what I would try is increasing the specular and bump strengths a little, and softening the spotlight shadows. Actually, if you are using UE2, you don't really need a fill spotlight; UE2 will provide a soft 360 degree fill. If you are using an HDRI in it, you can rotate UE2 to see which direction you like best.

If you have a back/rim spotlight there, you could try enabling translucency channel in the hair. You can use the colour map from the second specular as the translucency colour, and add a tint.

What is the shader you are using for the skin?

Thank you Kettu. It is just a practice piece. Nothing to be really proud of except to say hey I got it to work and to try and understand how things work.

I did soften the spotlight shadows. Changed the color to a mid grey 121, 121, 121. Dropped the intensity to 70%, increased the softness to 100% and bumped the bias up to 3.15.

So I upped the spec on both Victoria and the hair. I also added in more bump. It shifted the color back to more red when I did that. I had Translucency set at 50% so I pushed it up to 100%. I could not see any difference in the hair. I can only guess at why there was nothing. Something that I have configure is all I can say for sure. My back light is only at 30%.

The shader for the skin is the SSS shader that comes with Studio. I then took the directions in AoA's video and applied them to the shader. I am using a shading scale of 0.2 and a rate of 6.0, Skin B scatter defaults. I also did not use quite as strong a blue in the diffuse color but given that the bump shifted things to the red side I think I could have used his blue as well. Diffuse is applied Post SSS. AoA does not talk about the settings for Velvet, specularity or bump so I used what you talked about doing with hair and what ominfreaker recommends for his Elite Human Surface Shader, I did have to create some of the bump and spec maps.

So I might not have gotten things correct but I do see the effects, although subtle. I want to again thank you all for providing understanding in 3Delight. It is so fun to be able to do both real stuff and stuff never seen before all in one renderer.

Mustakettu85

Dollygirl said:

I did soften the spotlight shadows. Changed the color to a mid grey 121, 121, 121. Dropped the intensity to 70%, increased the softness to 100% and bumped the bias up to 3.15.

Did you have to increase the bias because of self-shadowing artefacts in DSM (look like "dirt flecks" or "scales")? If that's the case, you could try switching to raytraced shadows and enabling the "progressive" mode in the render settings tab, which calls the raytrace hider of 3Delight, the one that will be faster with raytracing through transparency. Raytraced shadows are less susceptible to self-shadowing artefacts, so you should be able to lower the bias to a more natural value like 0.1.

Dollygirl said:

I had Translucency set at 50% so I pushed it up to 100%. I could not see any difference in the hair. I can only guess at why there was nothing. My back light is only at 30%..

That may be too low indeed to notice anything, and then the actual angle is important for backlighting, like IRL. It may take a few attempts to get it right. You could try the IPR window to see the changes in real time.

Dollygirl said:

I also did not use quite as strong a blue in the diffuse color but given that the bump shifted things to the red side I think I could have used his blue as well. Diffuse is applied Post SSS.

Yes generally the red in the diffuse multiplier should be dialed down, making it more like cyan.
I personally preferred the look of Pre SSS in AoA's shader because it's softer (again, it's purely personal; there are people who like their character's skin "crisp"); but then, the eyebrows will get "smudged" by the scatter, so generally it means extra effort to overlay them (one of the reasons V4 actually has that rarely used eyebrow geometry node).

I do see the effects, although subtle.

Subtlety is key =) I'm glad I was able to help!

I want to again thank you all for providing understanding in 3Delight. It is so fun to be able to do both real stuff and stuff never seen before all in one renderer.

Now this is one of the reasons 3Delight has devoted fans. Versatility. No need to resort to compositing if you want something in the style of Who Framed Roger Rabbit in a single render =)

JStryder

Thanks to all who posted information and links here. Intriguing. The bit about linear work flow seems logical enough - the ray tracing math should not be fed a distorted input curve. On the other hand, programmers of render engines and interfaces know this or have run into it and built mechanisms to cope for the expected application.

So what does it all mean in practical terms, rendering ready-made models in DAZ Studio using the 3Delight engine? Only one way to find out: render at different settings and compare. I did that (as have others above) and concluded that turning on CG in Studio/3Delight is not mandatory for realistic renders unless you are aiming for the effect it produces, at least for some set-ups. One might obtain equally realistic effects without CG by tweaking other things. Results will depend of course on numerous settings and the scene being rendered.

Anyhow, here are the conditions used to render my comparison images:

1. Bellatrix on G2 with V5 Bree texture (don't ask) at default settings (50% subsurface strength in skin surface) wearing some lace. Lights are Uberenvironment 2 base at 90% intensity, AoA spotlight for the key light and an AoA distant light for the rim light. No GC. The only tweaked render setting is samples at 8, 64 in shadows to reduce granularity. Progressive rendering and depth of field on. 3Delight.

2. Exactly the same as (1) but with GC on at 2.2 in the render settings, and all skin textures (not hair or lace/cloth) image gammas adjusted to 2.2 in the diffuse channel only, per the initial posts in this thread. Note the loss of contrast and the washing out of the lace, caused by turning on GC. (I also tried reducing the subsurface strength to 5%, but that had absolutely no effect I could see with this light set-up, so I did not post the result)

3. Exactly the same as (2), but with the hair and lace/cloth diffuse channels also set to gamma 2.2 and UE2 set to 50% to try and improve contrast a bit. The lace appears unaffected but the hair looks a bit different, not just darker. Maybe even more realistic (slightly). In general, turning on GC reduced contrast and specularity, and brightened the skin, but at least for this set-up the improvement in realism is not striking.

4. Just a random set of actual eyes from a photograph. Not rendered from "Actual Eyes" in the DAZ store, that does pretty well at least on the eye itself (certainly better than these test images using the default Bree eyes) but can't supply all the tiny hairs and other tiny details around the eye that scream "real thing!" Also, note the high specularity of the skin on the photo. I digress, but the point is that realism in close-ups depends on a very carefully constructed and detailed model. Bellatrix is a wonderful model, but not lifelike in all those tiny details, just like every model I have seen for sale. I suppose it is something for modelers to aim for.

Hope this rambling is of some use. I have got this out of my system at least, maybe.

mjc1016

JStryder said:

Thanks to all who posted information and links here. Intriguing. The bit about linear work flow seems logical enough - the ray tracing math should not be fed a distorted input curve. On the other hand, programmers of render engines and interfaces know this or have run into it and built mechanisms to cope for the expected application.

So what does it all mean in practical terms, rendering ready-made models in DAZ Studio using the 3Delight engine? Only one way to find out: render at different settings and compare. I did that (as have others above) and concluded that turning on CG in Studio/3Delight is not mandatory for realistic renders unless you are aiming for the effect it produces, at least for some set-ups. One might obtain equally realistic effects without CG by tweaking other things. Results will depend of course on numerous settings and the scene being rendered.

Anyhow, here are the conditions used to render my comparison images:

1. Bellatrix on G2 with V5 Bree texture (don't ask) at default settings (50% subsurface strength in skin surface) wearing some lace. Lights are Uberenvironment 2 base at 90% intensity, AoA spotlight for the key light and an AoA distant light for the rim light. No GC. The only tweaked render setting is samples at 8, 64 in shadows to reduce granularity. Progressive rendering and depth of field on. 3Delight.

2. Exactly the same as (1) but with GC on at 2.2 in the render settings, and all skin textures (not hair or lace/cloth) image gammas adjusted to 2.2 in the diffuse channel only, per the initial posts in this thread. Note the loss of contrast and the washing out of the lace, caused by turning on GC. (I also tried reducing the subsurface strength to 5%, but that had absolutely no effect I could see with this light set-up, so I did not post the result)

3. Exactly the same as (2), but with the hair and lace/cloth diffuse channels also set to gamma 2.2 and UE2 set to 50% to try and improve contrast a bit. The lace appears unaffected but the hair looks a bit different, not just darker. Maybe even more realistic (slightly). In general, turning on GC reduced contrast and specularity, and brightened the skin, but at least for this set-up the improvement in realism is not striking.

4. Just a random set of actual eyes from a photograph. Not rendered from "Actual Eyes" in the DAZ store, that does pretty well at least on the eye itself (certainly better than these test images using the default Bree eyes) but can't supply all the tiny hairs and other tiny details around the eye that scream "real thing!" Also, note the high specularity of the skin on the photo. I digress, but the point is that realism in close-ups depends on a very carefully constructed and detailed model. Bellatrix is a wonderful model, but not lifelike in all those tiny details, just like every model I have seen for sale. I suppose it is something for modelers to aim for.

Hope this rambling is of some use. I have got this out of my system at least, maybe.

Did you check if the control maps (transparency, bump, etc) were being correctly handled?

JStryder

mjc1016 said:

Did you check if the control maps (transparency, bump, etc) were being correctly handled?

Nope. I might have been asleep for that part of the lesson. I made no adjustments to bump or transparency of any surface. To me, the bump looks about the same and pretty good on all the images, just using the default Bree settings. Wouldn't know how to adjust transparencies. Any pointers would be appreciated.

DollyGirl

JStryder said:

mjc1016 said:

Did you check if the control maps (transparency, bump, etc) were being correctly handled?

Nope. I might have been asleep for that part of the lesson. I made no adjustments to bump or transparency of any surface. To me, the bump looks about the same and pretty good on all the images, just using the default Bree settings. Wouldn't know how to adjust transparencies. Any pointers would be appreciated.

They should be set to 1.0

RAMWolff

Great thread.  Will have to bookmark this for more thorough reading! 

wowie

Something I've been working on. :)

10 minutes 20.76 seconds Core i7 4770, because I need to raise the pixel samples to 6 for the DOF.

The HDRI is just being used as a background. LIght is a mix of linear point lights, distant light and UE2 (AO only).

RAMWolff

WOWIE Wowie!    That's an awesome render! 

wowie

Got some nice examples from Luc Bégin's thread at CGTalk. A lot of tweaks here and there. Haven't gotten the teeth right though.

 

Mustakettu85

Which thread would it be, Wowie? Google doesn't like me tonight =)