The map file contained in your downloadable .zip file reveals some interesting detail:
-
It’s in rgb format having 16 bit Integer values per RGBA channel. So some “steps” are inevitable already.
-
While a 16 bit integer value in theory allows for some 65k distinct values per channel, you are artificially limiting yourself to a very narrow band of light blue shades only.
What I’m trying to say is, that a more than inevitable amount of banding is innate to this particular map file right from the start. The slight color gradients across the map which appear to be smooth are not continuous at all.
I then proceeded to apply a posterization effect to the map file in GIMP, with from left to right increasing even numbers of posterization steps [2 .. 10]:
Note, how the boundaries between different colors remain fixed in place. Even though I would allow for more distinct colors during less aggressive posterization, there aren’t any more distinct colors around!
Final test in Three.js Editor:
I applied the map as a Normal Map onto a sphere geometry. When the map file is mapped (pun intended) to the range [0.0 .. 1.0], there appears to be no visible banding:
If you crank up the upper boundary of the mapping range, very significant banding gets introduced:
By cranking up the upper bound of the mapping range, you effectively amplify the contrast between adjacent areas of different color, making the contrast more visible. By extension, without such amplification a contrast must have been present already, albeit hardly perceivable.
I would have liked to attach the project.json for loading into the Three.js editor, but due to size limit that wasn’t allowed - the map file has 8.4 MB already.
P.S.: my suggestion would be to switch to an RGB map file having floating point values per channel, which also utilizes the full range of intensities as much as possible.