Photoshop showing 32bit Normal maps from Marmoset washed out

Sidney Eliot

I've gone through quite a lot of threads on polycount that seemed very promising but none of them anwsered one of the seemingly most important questions in regards to washed out normal maps.

My goal summary: 32bit normal map in Photoshop should not be washed out

In Marmoset 4, baking a 16bit normal map as a PSD file, will open normally in Photoshop. When baking a 32bit normal map as a PSD however, it's a lot brighter when opened in Photoshop.

I'm aware that this does not affect the file and when loading the normal map into Substance Painter or other 3D software one simply disables sRGB or sets it to linear/ non-color, which will give it that nice blue again. But how do I have the 32b and 16b normal map look the same in Photoshop. I tried using different ICC profiles and I do think that using the correct ICC profile is the key to fixing this, but until now I've had no luck in finding what the correct profile would be. I downloaded this Rec 709 ICC profile (https://www.color.org/rec709.xalter) which Blender uses for it's linear color profile, but in Photoshop it didnt't make the 32b normal map look like the 16b.

These two images are are the same normal map in Photoshop, the left one baked with 16bit and the left one with 32bit.

gnoop

Add exposure adjustment layer  and set gamma slider to 0.45   to cancel sRGB gamma Photoshop apply to the exrs.    if you want  to convert to 16 bit mode hit "don't merge" while have the image as layer / not background .       

Sidney Eliot

gnoop said:

Add exposure adjustment layer  and set gamma slider to 0.45   to cancel sRGB gamma Photoshop apply to the exrs.    if you want  to convert to 16 bit mode hit "don't merge" while have the image as layer / not background .       

Thanks, that's a great help. Initially I was not that convinced of inserting a gamma adjustment layer that might have to be enabled and disabled based on the situation, but after thinking bout it a bit more I think, the best approach might actually be to just leave the gamma adjustment permanently turned on in the PSD file. That would then allow me to keep the correct normal color without having to worry about switching between bit depths (making sure to use "don't merge") and exporting with sRGB on or off would also not matter anymore.  
 
The text below I wrote before coming to this realization, but I'll keep it for those that come here with the same issue and need some extra explanation / context.  
 
---------  
---------  
 
Adding an adjustment layer isn't a great solution as I have to add it to every file I work on, and it makes the Photoshop files themselves not usable anymore as I would constantly have to disable this gamma over correction layer for when a software is still using that PSD file. (And yes 0,45 is the correct value, thanks for that.)  
 

I also had tried converting the PSD file to 16bit but then when I used "Export As" PNG with "convert to sRGB" off, all of a sudden it did not fix the normal map that was exported, and it was washed out. I tried changing the bit depth with "don't merge" initially which resulted in the issue I just mentioned.

I then tried "merge" (which is the default option if one has no other layers in the photoshop file and the base layer is locked). But that had the same issue, I assume this is due to the fact that I have to change the gamma adjustment slider in the-pop up window that appears when lowering the bit depth of a PSD file.

Using the 0.45 from before did not work here however, do you perhaps by any chance know the Expusre and Gamma values for the 32 to 16bit conversion when using "merge"?

(image of pop up window when converting from 32b to 16b with "merge" option)

poopipe

you can disable color space manipulation when opening files in the color settings 

 I'd advise that if you're doing anything with normals or other 'maths' textures (roughness etc) as photoshop will apply (and save) transforms, you won't know about it and suddenly what you thought was a value of 127,127,127 will actually be 141,141,141 


photoshop isn't doing anything objectively wrong apart from not warning you about it  - its just not aimed at working on images that want to be manipulated in linear space . 

Sidney Eliot

Thanks, these settings will help a lot with identifying issues before they become issues.

gnoop

As far as I know  you can't disable color managment in Photoshop .      0.45 works fine on files not having embedded iCC color profiles  like exr , tga and png maybe . Not sure about the last one although, it still could  I think.    

     When you open a psd  WITH  embedded ICC profile  like what photoshop always do when you save a psd file   it may do certain color transform according to the file  profile first  before you applying 0.45 gamma  on top of it and as poppie said it may turn 141 instead of 128 .  But to be honest I am not sure .        Although I doubt Marmoset embeds ICC profile  to psd files.      Still the safe option is saving exr  when you want 32-bit   or saving 16bit integer  when you do PSD.

in all honesty I am not sure why you may need  32 bit  normal maps . 16 bit integer is perfectly enough.   Besides Photoshop doesn't have enough tools in 32-bit mode  so why  bother with 32 ?    

Also about 128 turns 141.  In Photoshop it happens  when you copy gray looking  color layer in alpha channel.  To prevent it set gray in "working space"  to sGRAY   and   check in "blend RGB colors using gamma: 1"   but it's unrelated to your  normal map issue.     

ps.  Never used that HDR tonning  . it does some undocumented  crap  math wise nobody knows  whats exactly .  Just ask chatGPT to write you  Photoshop  script that do what you need and  make a hotkey.   Photoshop could be extremely automated   by help of the chat. 

poopipe

preserving the embedded profile on an image with no profile 'should' leave the values alone and that's what you want.

If marmoset is applying an sRGB transform to the values at export (this is unlikely) you need to resolve the issue there, not in photoshop
to determine whether that's the case or not, open the file in something like substance designer or an image viewer other than the default windows one

Sidney Eliot

gnoop said:

in all honesty I am not sure why you may need  32 bit  normal maps . 16 bit integer is perfectly enough.   Besides Photoshop doesn't have enough tools in 32-bit mode  so why  bother with 32 ?    

Obviously 32 is total overkill for the final result (in game engine or render). But as you might know, when baking especially with normal and AO maps, one often gets nasty bading artifacts which are most visible on flat surfaces. Baking the images at 32bit will most of the time fully remove banding and other such artifacts. After baking one can then change the bit depth back to 16bit.  
 
I was trying to postpone the conversion to 16bit to the last possible moment as working on a file with more data doesn't hurt (the entire purpose of EXR files), but as you mentioned Photoshops tools are quite limited in 32b mode, things like heal brush and even fill buckets just don't work.  
 
Another theoretical reason why switching the bit depth at the last possible moment (for most people that's probably during Substance Painter's texture export) is better, is because one should try not to switch between bit depths to often (the same goes for switching between file formats). Switching from 32 to 16 and the deciding one wants 8 might yield worse results than doing one single conversion from 32 to 8.  
 
But working with 32bit files is as of 2024 just not very comfortable, so in conclusion I would say the fix is to bake in 32bit and then immediately convert it to 16bit.

gnoop

Sidney Eliot    I have never seen any banding on16 bit normal maps. But I tend to avoid any big gradients in my normal maps.  Only time I bake 32 bit normal map is when it's a world space normal map I want to re-bake into tangent one later   and mostly because it's usually a part of multilayered exr file  3d renderers output.   If you are using Painter or Designer  it can convert 32bit to 16 bit  on its own just fine . No Photoshop involved is necessary.    I still pay Photoshop subscription and honestly  can't figure out why I do it. Hardly use it nowadays. Just out of curiosity what AI could do and so far noting that is helpful for me.

Sidney Eliot

gnoop said:

Sidney Eliot    I have never seen any banding on16 bit normal maps. But I tend to avoid any big gradients in my normal maps.  Only time I bake 32 bit normal map is when it's a world space normal map I want to re-bake into tangent one later   and mostly because it's usually a part of multilayered exr file  3d renderers output.   If you are using Painter or Designer  it can convert 32bit to 16 bit  on its own just fine . No Photoshop involved is necessary.    I still pay Photoshop subscription and honestly  can't figure out why I do it. Hardly use it nowadays. Just out of curiosity what AI could do and so far noting that is helpful for me.

I like photoshop or now Affinity Photo for fixing mistakes in the AO maps. I always frist try to sort out issues with topology and shading frist, but at some point it's just small little things that can easily be fixed in a image editing software. Also if you have ever had the topology grid pattern appear in the AO map due to the low being too low, then a good fix (that doesn't involve editing the low) is to render to AO maps one with the grid fixed (by adding a temp SubD) and one without and then fix both of them together, to remove the grid pattern, but preserve the correct AO map arround the edgeds of the model.