Poser Pro2014 now automatically sets gamma for image maps plugged into bump, specular and displacement to 1.0, which is great. But some of my shaders get hopelessly screwed up by this and there's no way to turn it off.

I can manually reset the gamma to what I want (usually 2.2) but next time I open the scene it's back to 1.0.

Has anyone found a way to deal with this?

I think I'll open a ticket with SM....

for the sake of it, I just tested them all.

Bump and Transparent always return to an explicitely set 1.0

All other slots, including displacement and normal_map, and including an image attached to an IBL light, remain as set.

EDIT: I also noted that reopening a scene, just altering some texture / gamma settings, leaves the Save option greyed out; only Save As is possible. So I'm not sure such changed go noted.

On my machine, on my PoserPro 2014SR4, at Aug 22 2014 21:00

might be different next time ?

     The behavior isn't consistent.  Both of these image maps are similar in hue and brightness (Genetica makes them this way).  Both drive diffuse and bump.  Poser reset the gamma of one but not the other.  So, one appears noticeably brighter.

     Every.  Time.  I  Open.  The.  Scene.

Quote -      I -and others- have submitted bug reports for this.  The default of gamma:1 for a new node is fine;  it is not OK to reset image map gamma to 1 after I have specifically set it otherwise.

     The behavior isn't consistent.  Both of these image maps are similar in hue and brightness (Genetica makes them this way).  Both drive diffuse and bump.  Poser reset the gamma of one but not the other.  So, one appears noticeably brighter.

     Every.  Time.  I  Open.  The.  Scene.

This is exactly what I'm getting too.

I put in a support request to SM detailing the problem and here's their reply:

"Thank you for contacting Support. Gamma Correction is an option in the Render Settings."

Clearly they didn't read my description of the problem properly.

I was not aware of this new "smart" behavior. I was aware of you guys talking about spontaneous gamma value change but I had no idea it was tied to an intentional feature gone haywire.

Generally speaking, a connection from bump to a series of nodes that eventually leads to an image map cannot be assumed to tell us anything about the image map's gamma, if that same image map also leads to a color input.

While unusual, this sort of thing isn't completely whacky or illegal, and Poser should be reacting to it properly, which is to say that the input doesn't satisfy expected limitations for automation. I did similar in VSS, where it complains and says (approximately) "Warning: Color Map also used for Bump Map".

of course, any RE-setting of things by either Poser or Queue Manager on file opening is some sort of nightmare.

Using images in multi-purpose situations is complicated, one might want to have a gamma node before the bump-slot to cater with things, but one image migt be used for color in one material and for bump in another.

To complicate (or simplify) things even more: Poser will convert each file<.ext> to file.ext.exr in TextureCache, and assigns the gamma property to that one. Using files with the same name and type, but different paths can therefor lead to somewhat unexpected results. On Mac, without extentions, things may be worse / different.
The EXR setting for the file is as set in the latest node it's referenced, and then shown in all nodes that refer to it throughout the scene.

That is: until SR3.1. With SR4, we've got an additional challenge on top.

Quote -   Generally speaking, a connection from bump to a series of nodes that eventually leads to an image map cannot be assumed to tell us anything about the image map's gamma, if that same image map also leads to a color input. 

     Exactly.  And though some of my concoctions may indeed be whacky, there is a method to my madness.  So what I ask of Poser is to let me rise or fall on my own merits, rather than making nanny-state decisions "for my own good".  I enjoy making new content which exploits the newest Poser features.  Sometimes I misuse Poser features in innovative ways.

     In this case, I'm making a massive enviro playset, and I'm trying to be economical with both poly count and texture maps, for the benefit of those who don't have gobs of RAM.  I know the color map is not really correct for bump, but it is plenty good enough for background "filler" props.

     The use of double maps blended with the spot tile allows me to economically cover a huge area without the obvious "checkerboard" artefact common to tiling, and maintaining good resolution even in a closeup.  Note the asphalt right near Mr Chipmunk in the foreground.

     I'm also reducing the need for a myriad of Poser lights;  this scene has one infinite light (dialed down to 12%) for moonshadow, and one tiny 10-degree cone spot focused on Mr Chipmunk (otherwise he'd be lost in the dark).  The buildings and streetlights are all done automagically with unseen IDL emitters.  When actually using the playset, I'll use a few Poser lights on the focus of interest (the main doll, etc) to gain specularity.  But these background props will take care of themselves.

OK I've found a fix for this.

In the 'Poser.ini' file the second to last line reads:

MAT_WACROS_ON 1

change it to

MAT_WACROS_ON 0

and it turns off the 'smart' gamma behaviour.

EDIT: or maybe not - I need to figure out if the texture cache remembers the wrong gamma settings or not, or if the 'smart' gamma is hopelessly inconsistent.

I can't see anything in this shader that would suggest gamma = 1.0 for the colour map, but it keeps applying it time and time again.

I've been opening up scene files created before the SR4 update and this feature does more harm than good, the way it changes gamma settings seems to be completely arbitrary.

If anyone from Smith Micro reads this, please tell us where the switch is to turn it off! And if there isn't one, what were you thinking?

This has completely screwed up my workflow and needs to be addressed FAST.

It won't magically fix existing scenes where values have already been changed, but any future saved scenes will retain their proper settings when next loaded.

Note that this version only retains the settings for image map nodes. If there are other nodetypes that you need this to work for then let me know and if I have time I'll add support for them.

CAVEAT:
I saw this thread and threw the code together quickly, so it MAY contain bugs. In other words, use with caution and let me know if anything needs fixing :-)

Because it analyses the scene on saving and loading, and stores some extra data in the scene file, it may have a very small impact on saving/loading times. Scene file sizes may increase ever so slightly too.

NOTES:
Remove the '.txt' extension from the attached file and it will be a zip file with the addon inside.

Snarly, saving the day for lots of people. Thanks...

     Bravo, snarlygribbly, and thank you! :D

Snarly, thanks very much for this, it is greatly appreciated.

You're very welcome.

It'd be good if somebody could confirm that it is all working correctly. My own testing was minimal.

Please let me know if you think it is working well enough for me to upload it to my freebies site?

     I'll try to get some testing done.  Query:  Does this modify the pz3?  What happens if I get my materials set for gamma, then run the script, re-save the scene, then send a batch of test renders off to network remotes via Queue?   Essentially, the master sends a scene file to the remote, and the remote opens that scene and renders it.

     Of course, I can test that also, but at the moment I'm waiting for my workstation Cameron to finish a material test render for another Tink's Cafe' neighborhood building.  Once that's done, I can fire up the blades (rack-mount servers), and do some network tests.

     I just replaced the processors in the two oldest blades yesterday, so now all of them have the same processor kit (two H/T hex-core Xeons, model X5650).  So now I have four Xeon L5639 processors (HyperThreaded hex-core, 2.13GHz) and a core i7-965 HyperThreaded quad-core (3.2GHz, w/3.46GHz turbo) sitting on my parts shelf, surplus.  All are LGA1366 socket, triple channel.

     Let's see, after unzipping, I put the gammafixer folder in C:Program FilesSmith MicroPoser Pro 2014RuntimePythonaddons, methinks?

Quote -      Let's see, after unzipping, I put the gammafixer folder in C:Program FilesSmith MicroPoser Pro 2014RuntimePythonaddons, methinks?

Yes :-)

Quote -      I'll try to get some testing done.  Query:  Does this modify the pz3?  What happens if I get my materials set for gamma, then run the script, re-save the scene, then send a batch of test renders off to network remotes via Queue?   Essentially, the master sends a scene file to the remote, and the remote opens that scene and renders it.

Hm .. interesting pont!

What I do is find all the maps in the scene, grab the gamma settings for each one and store my findings as extra data in the scene file. When the scene file is re-opened the addon checks that extra data and updates the scene's nodes accordingly. That step won't occur when using the queue renderer.

So it will depend on at what point the bug manifests: at time of saving scene, or at time of loading scene ...

I'll be interested in your findings

  Nike!  First test, it works!  You've done a yeoman's work, good Sir Snarls!

     Work flow is to open a scene, set the gamma of every image map in every material zone of every prop.  Run the magical Snarly script.  Re-save the scene.  Close Poser.

     Re-open the scene.  Note that gamma settings remain unmolested.  Rejoice as is your wont.

.

     Snarly,  I'm going to check what happens when render jobs are sent to remotes on a network via Queue, but give me time.  On my primary network, one workstation is currently disassembled, and the other is already busy.  On my smaller network, the remotes have a different build number than my laptop Valkyrie, and a recent update to Avast! IS flags a false positive when running the Poser/Queue update, so I'll have to disconnect from web, shut down Avast! IS, run the Poser update, then turn Avast! IS back on and re-connect to web.  I have a report filed to Avast! on this issue.

thx fr script, snarly.  I haven't yet applied SR4.

one can check if it reverts "on save" by examining pz3 file (pre-script) in text editor.  at bottom of node list it may say:

nodeInput "Filtering"
{
name "Filtering"
value 3 0 0
parmR NO_PARM
parmG NO_PARM
parmB NO_PARM
node NO_NODE
file NO_MAP
}
gamma 5.000000
}
}
}
locked 0
backfaceCull 0
visibleInReflections 1
visibleInRender 1
visibleInCamera 1

I'm guessing it will revert "on save" (without using snarly's script) or "on open" even if locked = 1.

     I'm dead in the water on queueing on my smaller network, Snarly (the problem has nothing to do with your script).  I'll need to revert back and re-install before this network will queue again.  The larger network is offline for modification work at present.

     So it may be awhile before I can get the network function of the script tested.

Quote -      So it may be awhile before I can get the network function of the script tested.

Have you had a chance to test the network queueing?

(c567591) 

Quote -   Have you had a chance to test the network queueing?

       Mea culpa;  I have been preoccupied with family obligations lately, and forgot.  I'll try to get to this.

     My #2 workstation Galadriel is still offline, but my remotes Cortana and Terpsichore are back online - with a pair of faster H/T hex core Xeons each!

Very nice!  Reminds me of my own (overly ambitious?) city project from last year before my HD died. :(

Anxious to see how this turns out, good luck!

     I remember seeing wip shots of that, moogal.  Looks honkin' big.  That looks like a viaduct in the foreground.  I like the sky bridges.

     I recently added three private homes to the cafe' neighborhood, and just finished modeling a commercial building which still needs UV and MAT.  Then, position everything in Poser, set door origins, save props, strip out the geometries, and I'll be ready to start posting zips.

I take it that this problem has not been addressed? I've downloaded the serial update but I have NOT installed it. I supposed that I'm not going to install it.

     SR4 has the gamma changing issue.  It has been reported.

I had somehow missed this thread; Thanx, Snarly!  :biggrin:

I've had a ticket open with SM for weeks now regarding the gamma problem. They are adamant that "there is no 'Auto Gamma' in Poser" and have seemed determined to blame third party sets, props or shader setups.

My last message was to get them to do the check described below and they've not replied as quickly as they normally do.

Open the 'Office' PZZ scene file that has been part of Poser's included content for a while. Find the prop 'E_Carpet_S_1' and material 'E_Carpet_M', and check the gamma setting for the diffuse image map (by clicking on the file name).

Since SR4 it's been setting itself to 1.0 on my system, presumably because it also plugs into transparency, but it should be determined by render settings (typically gamma = 2.2).

     Oh, now I remember why I never got results back on queueing Snarly's script;  SR4 broke Queue, and my network has been unuseable (for Poser) since.  That's been reported.  Coincidentally the Avast! issue started, so I initially thought Avast! was the only problem.  But once Avast! solved their bug, I realized that there was a Queue issue with Poser.  I can network Vue and Lux, but not Poser.

CSpear:  The auto-changing gamma has been reported, and I believe that SM have acknowledged the issue. 

     My advice is to use Snarly's script until the next SR is released.  Queue behavior is irrelevant because the queue runs only occasionally anyway.  But if someone does get Queue to run and complete a test, please post results!

I hate to say it, but Bump maps, trans maps, displacement maps and, especially, normal maps should always have a gamma of 1. 

Now if you intend to use those images for something else, that is different, but those channels should never be gamma corrected and if there is gamma correction on the images it should be reversed out by the software. 

@bhoins...

Noone is questioning that.

The problem comes in now that Poser or QueueManager auto correct things where they did not before.

If there is an image plugged into diffuse AND one of the other channels now it gets auto corrected to 1.0 for us where it did not change before.  Thats the problem... so a scene that worked ok before this update gets thrashed and requires a lot of work to fix it which then ultimately gets ignored next reload.

If there was an option to use it or not i think most of us wouldn't have an issue.  Because it happens automatically is the real problem.

Many products do this wrong and thus many scenes get changed dramatically.

I will try reinstalling 2014 Game Dev and try Snarly's script and see if it helps in QM perhaps this weekend.

Quote - f there is an image plugged into diffuse AND one of the other channels now it gets auto corrected to 1.0 for us where it did not change before.

It's not quite that simple unfortunately: that behaviour is inconsistent. I have a scene where two materials are set up in exactly the same way, but use different diffuse colour maps. One switches to Gamma = 1.0, the other stays put. Unless you send the render to Queue Manager, in which case it does change the gamma. All in all, a real pig's breakfast.

And lo, as I've been typing this, a message from SM: "The issue is resolved in the upcoming update."