I'm using the latest version of Poser 11, 11.2.319, according to the "About" dialog but this problem has happened from time to time with older versions.

I load a character and the head texture is washed out, reduced to about half the saturation it should be. It doesn't happen with every one of them, but on the ones it affects, it always affects them. My material settings aren't doing anything - that I can see - to make this happen, for example, Texture_Strength is at 1.000, Diffuse_Color is set to 1.000 also. I should point out that this is before I apply Snarly's EZ Skin. That seems to correct the fault, so I guess it's not a hugely important matter. That said, I'd love to know what causes it.

A workaround I found - for a non EZ Skin render - is to load the offending texture into Photoshop, then save it out under another name. I don't alter anything else, just the filename.

As I said, weird.

Very odd indeed. I've not seen that happen, but I wonder if maybe there's some shader work going on in the background with the original texture? That might explain why the resaved version works.

Nothing at all, Sean. Not even a case of doubled surfaces. Just a plain texture attached to the surface node. It happens even when I delete everything and load 'em in manually. Shows up like a sore thumb in Preview and renders just the same.

I don't profess to know the answer to this as I don't have enough information about the shader setups involved, but I'd like to suggest a possibility.

In older shaders, and even some new ones, the same texture is used for both diffuse colour and bump map. Now, the Poser texture manager can only have a single gamma setting for each texture, so one or the other (diffuse / bump) will have the wrong setting. Now, in such cases EZSkin resets the gamma settings for you, and although that still means that one of them will be wrong, EZSkin ensures that the diffuse colour is the one with the correct setting. perhaps it is correcting things for the colour map at the expense of the the bump map (which tends to be less noticeable, in my opinion)?

Snarly, this happens without any attached shaders, other than the original diffuse color map attached. It happens every time with the affected ones, and will render the same way, no matter what. The only thing to fix it - for non EZ Skin renders - is to change the filename, or to run your EX Skin script.

To be clear...

I can delete absolutely everything attached to the model, then reload the head tex and, even without anything else attached anywhere else, it will still load in as a washed out version. I first noticed it over a year ago, when using GND4, which had, up to then, worked without fault. I wondered if the file was corrupted but I couldn't see anything obvious. I guess it's possible the file header for the jpg got mangled somehow but in anything other than Poser, it looks correct.

On some older textures I've found a problem with gamma correction where the body is at 2.8 while the head is at 1. I think these textures were made before poser had the option of applying individual gc to textures and so somehow gets confused.

A quick correction, the figure I have found this with is Lusitania, and the head has a custom value of 1 while the body has 2.2, not 2 8. The effect disappears if you render with gc off.

Don't know if its the same problem but this can happen if there are two different texture maps that share the same base name. For example if there are two props c:\redball\red.obj + texture file c:\redball\ball.jpg and prop c:\greenball\green.obj + texture file c:\greenball\ball.jpg. Poser will pick one of the ball.jpg files and apply it to both props even though the texture files live in different directories. Clicking on the explorer file will show the correct file which can be confusing.

Nope, these are the correct textures, from the correct directories. Even applied manually - and checked for filename and path name - they show up washed out.

Have you tried forcing the gamma setting to 2.2 in the texture manager when loading the washed out textures.

Oddly if I load a figure into a scene, apply a texture and force the gamma to 1, then load another figure in to scene and apply the same mat to that figure the gamma on the original figure gets reset but only that first time, the two are not linked like the texture effect I mentioned above.

Sam, can you post a screenshot of the materials setting for this? Now I'm really curious.

It does seem like it must be something like the gamma setting. Or EZ Skin wouldn't fix it...would it?

The color texture is the only one that should be set to gamma 2.2. All others (bump, normal, opacity, height, etc) should be gamma 1.

So bagginsbill is on to something in the cases where the color texture is also used for bump. If both are set to 1, the color will be displayed incorrectly.

OOOOPS ... meant to say snarly, not bagginsbill. Apologies LOL

Snarly hereby has permission to hit me with a wet noodle. :-P

SeanMartin posted at 1:30AM Sat, 21 December 2019 - #4373972

Sam, can you post a screenshot of the materials setting for this? Now I'm really curious.

Yep, I'll do it tomorrow. Off to me bed in a bit, what with it being 1.30 am here.

Was a time I laughed at sleep but now I'm an old git, I find it to be somewhat useful now and again.

If this was a shader set-up issue don't see why just reloading a renamed texture would fix. One thought is the texture manager is picking up a system GC = 1 setting from somewhere when the mat is first loaded, by renaming and reloading the texture its forcing the system to re-evaluate the system wide GC at which point the correct value is used. Based on the strange behaviour mentioned above would be interesting to see if adding a new V4 figure and applying the same mats from the library has any impact on the washed out texture - probably won't but simple enough to try.

As promised, a couple of screenshots:

Here's preview mode:

Here is the Material Room:

Pre-empting any comments about the setup, this is before applying EZSkin, and no, unchecking Reflect_Lite_Mult and/or removing the Specular_Color attachment doesn't change anything.

Browsing the relevant texture folder shows the file looking as it should be. It also loads into anything else without looking washed out.

I think I corrected all the other instances by changing the texture filenames, as I described above. I loaded this model (Maya Doll) last night out of curiosity, and there it was again. As I said, it's not particularly a problem, since using Snarly's script gets rid of it, but I'd love to know what causes it.

Finally, a plain vanilla Firefly render. No SSS, GC, nowt:

What does the texture manager window look like for the head texture

I think you may have nailed it. Here's the screenshot:

Yep. Changing the selection to "Use Gamma value from Render Settings" did the trick. Many thanks, ironsoul.

Now, me next questions are:

Why does this happen to some textures and not others? Why is it only ever head textures? How come resaving from Photoshop corrects it?

Part of it might just be a Poser fluke. As Nails said:

"On some older textures I've found a problem with gamma correction where the body is at 2.8 while the head is at 1. I think these textures were made before poser had the option of applying individual gc to textures and so somehow gets confused."

As for why re-saving the texture fixes it, I haven't a clue.

SamTherapy posted at 5:33PM Sat, 21 December 2019 - #4373998 ...

Why does this happen to some textures and not others? Why is it only ever head textures? How come resaving from Photoshop corrects it?

It's down to the answer I gave at the beginning of the thread, where I pointed out that the diffuse colour map is sometimes used for other purposes too, which can cause the map to 'inherit' the wrong gamma. I gave the example of the map being used for the bump channel too, but it could just as easily be used for the specular and transparency channels, with the same result.

In the example texture you have since posted, it contains the transparency map for the eyelashes, and when used for that purpose the gamma is properly set to 1.0. Each texture map can only have one gamma setting applied, thoug, so when it used for two purposes one of them will be wrong (as i previously said). EZSkin resets the gamma in those cases, so that the gamma for the diffuse channel is correct and that of the other channel is wrong instead.

Resaving the texture with a new name makes it a different texture map, so it doesn't inherit the bump/specular/transparency setting of the previous map. You can now use one map with a gamma of 1.0 for the transparency, and the other with a gamma of 2.2 for the colour.

Deecey posted at 5:44PM Sat, 21 December 2019 - #4373978

OOOOPS ... meant to say snarly, not bagginsbill. Apologies LOL

Snarly hereby has permission to hit me with a wet noodle. :-P

Very kinky, but I suppose everyone has to have a hobby! Besides… I consider being mistaken for BB to be an honour :)

SamTherapy posted at 7:10PM Sat, 21 December 2019 - #4373998

Yep. Changing the selection to "Use Gamma value from Render Settings" did the trick. Many thanks, ironsoul.

Now, me next questions are:

Why does this happen to some textures and not others? Why is it only ever head textures? How come resaving from Photoshop corrects it?

Just a idea outside all that gamma stuff. There are lots of different JPG-algorithems in the market to do the compression. And it seems that Poser does not interpret all in correct/optimal way, opposite to Photoshop. For example I have some very good chainmail images, fine to use for fishnets or such stuff. One series of these images is shown well in Windows preview and such but in Poser I get plain white image. Workaround loading in Photoshop and resaving it with "Save as new ..." even with the same old name Photoshop is rewriting the file from memory and using its main formula which is best compatible.

You could check this a little bit if opening such files in a plain text editor. That is giving a lot terible unreadable stuff but in the very first beginning the type of file is writen. For JPG-file there could stand JPG, JPEG, JIF or JJIF or such. And if I'm right before and after the resave with Photoshop there are different entries there in the beginning.

Why this happens more with head texture ... maybe those are coming from a different program for making characters.

Why gamma is correcting that, absolute no idea, but maybe gamma change has to work with the file content and so changing the compression formula.

Just a idea ...

Oddly enough, I just opened a Stephanie character - the old Steph, that is, derived from Mike 2 - and that had the same problem but this time with the body. That shares a map with the Pubic hair trans, which support's Snarly's explanation.

Snarlygribbly posted at 3:17PM Tue, 24 December 2019 - #4373942

In older shaders, and even some new ones, the same texture is used for both diffuse colour and bump map. Now, the Poser texture manager can only have a single gamma setting for each texture, so one or the other (diffuse / bump) will have the wrong setting.

Interesting! I had never considered that, although it makes sense in hindsight. Thanks @snarlygribbly for the information.

A follow-up question: I admit I sometimes connect the diffuse map to the bump input if there's nothing else available, on the grounds that it's at least better than nothing. Plainly I shouldn't do that any more, but is there a node or nodes I can put in to correct the gamma for the bump input and avoid the diffuse map's gamma being messed up?

I've seen some material set-ups where the creators had put in a maths node (set to just pass through, e.g. multiply by 1), and others use an HSV node to create a monochrome version of the diffuse map, but do either or both of those actually correct the gamma? I know enough about the material room not to take anything at face value...