Geog heightfield load vs. Geog Image map shader

[sboerner]

I've always used the Geog heightfield load/Heightfield shader combination to load DEMs. But I was curious today about the Geog image map shader and decided to take it for a spin. I loaded a DEM into it, disabled Apply colour, and enabled Apply displacement.

Quickly ran into a couple of problems.

First, it seems to use a different vertical scale. The Geog heightfield load shader produces an accurate vertical scale when Displacement amplitude is left at 1. When using the Geog image map shader, I had to increase Displacement amplitude to 100 to get something close to it.

Second, it seems to interpret the 32-bit data of the geotiff DEM file as 8-bit data, resulting in serious banding.

Finally, whenever I tried to disable Smooth disp interpolation under the Displacement tab of the Geog image map shader, Terragen crashes.

Is the Geog image map shader deprecated for loading DEM files? It would be handy to use one node for this instead of two, especially when working with large groups of DEM files.

[WAS]

Simply put, a geotiff is not a tiff. A 32bit float tiff is just float point data. So each pixel has it's amplitude, and the pixels are set in their dimension. A geotiff has a 0-1 range I believe, and then a projection system (and there are many) which define its location, area, amplitude, etc. The image map reader uses a different dll (function) than the geotiff, and thus, can't load any of that data, so it just interprets it as a basic image, or what it can see in that 0-1 range. It also doesn't know correct resolutions/size and thus probably renders smaller (hence the banding when set to a large size).

Also, the heightmap shader has it's own features to interpret heightmap data better, and apply fractalization, which makes it appear "better". Especially useful for low quality DEM/Height maps.

[sboerner]

Hmm. If you're right then the Geog Image Map Shader is just an Image Map Shader with the ability to georeference the image thrown in. If so this is too bad; if the shader's displacement tab can't handle geotiffs, then what is it supposed to be used for?

The wiki page refers to this list of supported file formats, and it seems that GeoTiff is supported, though the table organization appears to have changed since the wiki was last updated. (The wiki refers to a "Compiled by default" column in the table; there isn't one, but GTiff is listed as "Built-in by default.")

[WAS]

I know TG doesn't know all those drivers and uses one of them, or a couple, not positive. This is why people have to convert data sets on certain geotiff/dems to get them to reference correctly. 

The displacement issue could be because it is the projection system doing height? So Heightmap shaders know what to do with it cause it's in a DEM style?

[sboerner]

Yeah it seems like the two shaders are using two different methods to calculate displacement. It very well could be the DEM (geotiff) files themselves, too. When I have a chance I'll experiment with DEMs from another source, and also will try the Geog Image Map Shader with a regular 0-1 displacement map. (Geotiff pixel values appear to usually fall outside of that range, since they represent elevations in meters.)

In future posts I'm going to refer to the Geog Image Map shader as GIM and the Geog Heightfield Load shader as GHL. Tired of typing them out. 

Quiet around here today.

[sboerner]

OK, here we go.

The first file (usgs1mDem.jpg) compares the original USGS 1-meter DEM heightfield placed with the GHL shader (top) and GIM shader (middle). As before the banding is very apparent in the center image, and the displacement amplitude has to be increased to 250 to give a result similar to the (correct) displacement in the top frame.

The bottom frame uses a version of the same DEM that was normalized (using equalize histogram in Photoshop to make all values 0-1) and resaved as an RGB EXR file. Of course this destroys the file's geospatial info and the vertical scale. So even though it renders sort of OK, it's not very useful.

The second file (gmted2010.jpg) uses a much older, larger-scale geotiff from the USGS. Same banding problems.

I'm beginning to wonder if this might be a bug.

[WAS]

Hmm, I'm actually curious about this as well. I found another issue with image map shader, or something else when you have displacement. For example my 32bit voronoi maps from blender are perfectly smooth, except when I apply intersections, then I can a hard banding in the image, not the whole thing, but in the intersection fuzzy zone. Even if it's not displacement related (in the image map shader and put through displacement shader). So it's like something is done to the image map shader to produce bad data.