I've just downloaded a freebie FBX from turbosquid (for reference it was this one) and imported it into Poser 11. All its textures are PNGs. When I view the imported model in the Poser preview pane, or render it, it's got a distinct blue tint. When I look at the Image_Map nodes in the material room they've all got that same blue tint. When I view the actual PNGs (Windows Paint, Irfanview, etc) they're fine, as are the Explorer thumbnails. If I convert the PNG to a JPG it looks correct in Poser.

So what's up with Poser and PNGs ?

Once again I appear to have found the answer myself - I've found that posting a problem like this on a forum often helps me clarify what the actual problem is, which makes it easier to find a solution !

Simply re-saving the PNG from Irfanview fixes the problem.

Looking at the image info before and after would seem to indicate that it's the 64-bit colour that Poser can't handle.

...but unfortunately it appears that my re-saved PNGs are overwritten with the original 64-bit blue-tint ones when I import the FBX into Poser.

These things are sent to try us... :o)

Did you clear the cache to force Poser to reload the images? I believe that Poser will hold images to save time so if you load an image with the same name it will use the first one and not the modified one.

I'm fairly sure that it's not the cache, - it appears to be something odd that happens when I import the FBX into Poser (I've never used FBX before - the only format I usually import are OBJs, because they're plain text, I more or less understand the structure, and I'm happy tinkering with them).

For the example freebie the FBX file is 'Ancient_architecture_in_Asia_and_Japan.FBX', but there's also a folder 'Ancient_architecture_in_Asia_and_Japan.fbm' containing the PNGs. All three diffuse colour ones have the problematic 64-bit colour. If I apply these to any Image_Map node in Poser they have the blue tint.

So I open each in Irfanview, and simply re-save them which gets rid of the problematic 64-bit colour.

I now apply these to any Image_Map node in Poser and they work fine (I don't think I needed to restart Poser, and I didn't clear the cache - I don't think I know how to do that ?)

I then imported the FBX into Poser expecting it to work fine now, but it's got that blue tint again.

The reason I think it's the FBX import that's doing this is that if I now look in the 'Ancient_architecture_in_Asia_and_Japan.fbm' folder the PNGs (which I had just overwritten from Irfanviw) have been replaced with the 64-bit ones again - the timestamp on them matches my FBX import

Very odd.

(translated with google translate) I opened the .fbx file in Blender and exported it as .obj. Then I opened and saved all .png files again. I opened the .obj object in Poser and all the colors were right.

That's what I ended up doing too - I imported the FBX into Blender and exported as an OBJ. I also combined everything into one object and oriented it, positioned it, and scaled it to match Poser figures, and then after export I converted all the PNGs to JPGs and manually edited the MTL file to match. I imported the OBJ into Poser and then played with the three materials a bit.

I suppose the real problem is that Poser doesn't interpret 64-bit* colour PNGs correctly ?

*From the Wikipedia PNG article I assume that 64-bit is 16-bit per channel (48-bit true colour) plus a 16-bit alpha channel ?

I get this with the substance tools, texture maps can get a blue tint. I believe this is due to using 4x16bit channels- RGB+Alpha
Below screen shot shows four figures all with white amour set in Substance - from left to right 3x8bit RGB, 3x8bit RGB+Alpha, 3x16bit RGB, 3x16bit RGB + Alpha.

The alpha value is set to zero, to me this indicates that Poser is shifting the channels when reading the PNG file so the alpha value in the PNG file is being read into the Poser blue channel.

@3dcheapskate There is a possibility that it's a game ready asset as some engines use the RGBA channels for supplementary maps, like normals. Open the original PNG in an image editor and look at the separate channels. If there are normal in the alpha slot, that would explain it looking normal when saved as jpg as jpg doesn't retain the alpha channel iirc.

I've discovered that the '{whatever}.fbm' folder containing the PNGs isn't something that I downloaded - it's created and populated by Poser when it imports a '{whatever}.fbx' file. So that explains why my resaved PNGs were overwritten with the blue-tinted ones.

ironsoul -seems to confirm that somehow the alpha channel is at the root of (or at least heavily involved with) this.

Vaskania - It doesn't say much on the download page and there's no readme, but the model's quite low-poly and is probably intended for games. But the alpha channel shows as a single flat color - black in GIMP, white in Irfanview.

I've tried shifting channels by one in GIMP (i.e. R->G, G->B, white/black->R, also B->G, G->R, white/black->B) and I get a similar sort of tinting, but definitely not the same. But I get the feeling ironsoul's on the right track - it's something to do with the wrong channels being read into the R,G,B slots from a PNG with an alpha channel.

(Come to think of it, I recall Poser having problems with PNGs from way back, Poser 9, maybe 6 ?)

Just tried swapping RGB channels within Poser and came up with this.

So it does look as if Poser could be using a fixed value for the blue channel when the image comes from a 64-bit PNG, and since the alpha channel for this particular image is a fixed value, it does look as if Poser could be reading red and green channels correctly, but reading the alpha channel as blue. Which is what ironsoul suggested.

Poser ignoring the blue channel and using a value it calculates for itself rings a bell. It's probably unrelated, but just in case - It was something to do with trying to calculate your own normal map for a hemisphere, doing it all in the material room. Simple square root of sum of squares formulae to get the R,G,B components of a unit vector for the normal, but Poser was ignoring the (correctly) calculated blue value and using it's own (incorrect) value for blue. bagginsbill was involved in the discussion, which was either here or at RDNA.