Problem with baking displacement - zero elevation is not 50% gray

Hi

I’m having a serious problem with baking bump maps in Blender Internal. I was very impressed with the new microdisplacement feature in blender 2.78 in experimental mode. So i decided to bake some nice, “organic” bump maps from a few ornamental design meshes which i made earlier. I baked the bump maps and then started playing with displacing simple planes and cylindrical meshes. After some adjustments of dicing i was very impressed both with the render result and the performance. So everything works fine with microdisplacement but the problem appears with a much earlier feature of blender.
After first impression i realized that my mesh is bumped everywhere, not only where the ornamental pattern appears.
I tried adding a math node and substracting 0,5 from the value given by the displacemnet texture, but it also didn’t work.
So i checked how my displacement texture behaved in an old fashion way. I started a new file, deleted the cube, added a plane, uv-unwrapped it and applied my texture to it. Then added a subsurf and a displacement modifiers. So, the plane was bumped, but also started to “float” along it’s normal. After adjusting the midlevel value in the displacent modifier to about 0.740 it started to behave normally.
Finally i assumed that my textures midlevel (the value of brightness where is bump or elevation is 0) isn’t equal to 0,5. I opened the texture in Photoshop, choosed the eyedropper tool, and in the color picker checked what is the color in the no-bump area. Certainly it was much brighter, it was R188, G188, B188 (in the 0-255 range) or hue 0% saturation 0% brightness 74%. Funny that 74% is equal to the 0,740 value, which i had to set for the midlevel in the displacement modifier.
I tried adjusting values in the bake tab, and achieved many strange results, but couldn’t find a way, to make areas with elevation 0 bake as 50% gray. I also don’t understand how the bias value works.
Any help, please?

1 Like

188/255 = 0.73725490196. 0.5 in linear space is 0.7354 with gamma correction to srgb, which in turn reads 188/255 for an application using srgb and 0-255 scale.

Bias is the offset from the surface, and it bakes from that offset, distance amount to either direction.

Displacement value is data, not color. If the baked surface difference is 2 blender units, the pixel values on the image should be 2 units apart, and read as being 2 units apart. File formats such as jpg and png save values in 0-1 range so the values would need to be normalized and scaled afterwards to be able to save it, and also have enough bit depth to not lose precision.

Image formats like exr can save the actual values. Cycles true displacement won’t use those as is, and blender render texture settings has clamp (to 1) enabled by default.

1 Like

Thanks for explanation!

Until now i used 16-bit black-white tiff as a format for baked bump maps. 8-bit is not enougs, as it creates a “stairs” effect when applied on a mesh as a displacement map.
I just found another issue. When i add a new image for baking and leave the “32 bit float” box unchecked my final bump maps are always 8-bit, no matter if i set the output and saving settings to 16 or 8 bit. BUT the result has all the zero-difference areas rendered as 50% gray. When i add a new image with the “32 bit float” box checked it will be rendered and saved as 16-bit, but the zero-difference areas will be 0.7354 instead of 50%.
So the best way for baking bump maps is using an .exr format, is it?
Or is there another way to set the color space of the baked image to make the mid-level 50% gray instead of 0.7354?

1 Like

Edit: funny thing is that, when baking just a simple plane onto itself you get also an image covered with a 0.7354 gray color and when you use the python script Image:Invert-Invert image colors the inversion is… 0.7354 gray :stuck_out_tongue:
But when i created externally a 16 bit tiff covered with 50% gray and loaded it into blender, then launched the invert colors script and saved my image in blender and opened again in Photoshop i got 93% gray area.
This sRGB color space (i guess it’s an abbreviation for scrap-RGB) is very annoying, especially when you can’t turn it off when baking displacemnt map.

i use 32 bit exr output from blender in all my real world and artistic asteroid and moon landscapes

then remove the RGBA that 2.77 seams to save exr’s as, to a mono 32 bit tiff using Nip2

now seeing as the output might NOT be (0 to 1 ) but the radius of whatever, the px value could be in the thousands

like this output of the asteroid vesta ( pixel values are IN METERS!!! of the radius )
https://9-t.imgbox.com/VCA0o1bt.jpg

the values are ( +211969 to +292928 )

Just another issue: i went to scene - color management pref, and changed the display device from srgb to none. Baked displacement map of a flat plane. Then, having the UV/image editor window opened with my image, made a screenshot of it and pasted to photoshop. The result was 50% gray. So, the problem is not the baking, but saving/reading 16-bit tiffs. Blender switches from linear to srgb values whether you like it or not.

1 Like