HeightMapIFS as 16bit png

[lxh]

I tried to create a landscape with HeightMapIFS but 8bit grayscale wasn't enough height-resolution (only 256 steps). So I generated a 16bit heightmap (65536 steps) and saved it as png. While the 8bit map seems to be smoothed, the 16bit map looks like terraces or stairs but much less than 65536.

Has anyone experience or a workaround for that problem? Or is it how photoshop handles 16bit grayscale png's? 
Thanks for any suggestions!

[cKleinhuis]

as far as i know the problem would lie in the software that uses your heightmap, since 16 bit image formats are not really well spread, and internal rgba color values of most programms just use 8 bit as default ... photoshop is providing 16 bit images for its own quality preservance, and graphics cards slowly catch up, and many vendors do not want to include a 16 bit color resolution, but in my eyes it is a severe flaw in nowadays gfx cards because nowadays displays have resolutions much higher than 256 lines, which means that on large displays with more than 1000 vertical lines each gray gradient has to be interpolated somewhere, which leads to nasty glitches, that can be seen by most people, even if it isnt as obvious ....

[lxh]

Thanks for answering Christian. I use the benefits of 16bit-maps and -software for more than ten years now. The source is definitely 16bit resolution .. not just upscaled. But even if you use only photoshop (create a new 16bit per channel rgb or grayscale and do a black/white gradient) you'll see stairs and moire effects in m3d heightMapIFS .. while all 8bit seems to be smoothed. I think the problem is how m3d or the formula handles 16bits or how photoshop compresses png's.

[blob]

You see banding when creating gradients in 16bit images in Photoshop because no dithering is applied and the display is 8bit only. If you convert that 16bit gradient to 8bit or create a gradient in an 8bit image there will be no banding because dithering is being applied as to simulate more than 256 lightness levels.

[lxh]

Jep .. but the problem is not how photoshop displays 16bits on the monitor. And i can see the 8bit dithering in the m3d heightmap. But if i compare the same map as 8- and 16bit resolution in m3d as heightMapIFS the difference is striking ... respectively 16bits are useless.

[lxh]

OK .. i wasn't able to count the stairs but a simple test gave the answer: If i use a straight gradient map of 2000 pixels in 16bit resolution from black to white, i should get exactly 2000 steps or "stairs". That's ok. And if i use 1000px i should get 1000 stairs. But the stair-count doesn't change and seems much less than 1000. The only answer can be: m3d or heightMapIFS handles only 8bit. 

[cKleinhuis]

the answer is: 256, because 8 bit png loaders throw the lower 8 bits in the trashcan, this creates the effect of "non interpolated" because you get bands, with exactly the same color, that can not be smoothed out only on the 1 pixel size of the REAL color change blending would occur.... so, just believe that mb3d canright now just handle 256 steps of grayscale...

[lxh]

true, true, i believe ...
and i renamed it to BumpMapIFS 

[Jesse]

Yes, m3d uses currently only 8 bits for maps but i try to extend it also to 16 bits.
Saving is still not possible with 16 bits, that was one of my hopes when upgrading the compiler 

[cKleinhuis]

true, true, i believe ...
and i renamed it to BumpMapIFS  

parralax mapping would nice
http://orwellengine.blogspot.de/2011/04/hlsl-parallax-mapping-tutorial.html