height map for normal input sharp edges So I have generated this simple height map to test my add on:


That's the node setup and the result that I am having in Blender:


What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result

Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)

and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.

A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:

len(set(bpy.data.images['My8BitImg.png'].pixels))


This has returned 256, while 

len(set(bpy.data.images['My16BitImg.png'].pixels))


has returned 42891 in my case.