Short answer

Hillshade is a synthetic, directional rendering of a surface, not a measurement of it. Its pixel values are the cosine of the angle between an imaginary light ray and the local surface normal, so the same DEM can produce wildly different relief depending on the sun azimuth, sun altitude, and vertical exaggeration you choose. The classic failure is azimuth bias: linear features aligned with the light direction vanish, and features perpendicular to it look like real, mappable structures. If you trace lineaments, faults, or terraces from a single hillshade, you are partly mapping the lighting, not the ground.

What hillshade actually computes

Standard analytical hillshade (the Lambertian model used by gdaldem hillshade, the QGIS Hillshade algorithm, and the ArcGIS Hillshade tool) assigns each cell a value from 0 to 255:

hillshade = 255 * ((cos(zenith) * cos(slope)) +
            (sin(zenith) * sin(slope) * cos(azimuth - aspect)))

where zenith = 90 - sun altitude, azimuth is the sun direction clockwise from north, and slope/aspect come from a 3x3 neighborhood. The default parameters in almost every tool are azimuth 315 (NW) and altitude 45 degrees. That single equation has three knobs that quietly rewrite interpretation:

  • Azimuth decides which slopes are lit and which are in shadow. A north-south scarp is invisible under a 0/180 azimuth and crisp under a 090/270 one.
  • Altitude (sun angle) controls contrast. Low angles (15-25 degrees) dramatize subtle relief but blow out high-relief terrain into solid black shadow; high angles (60+) flatten everything.
  • Z-factor / vertical exaggeration multiplies the elevation before the slope is computed. A z-factor of 1 is geometrically honest; anything above that invents relief that does not exist at that ratio.

Because the output is a cosine, it is also non-linear: equal elevation changes do not map to equal brightness changes, so your eye reads gradients that the terrain does not contain.

The azimuth trap

This is the single biggest source of bad structural interpretation from DEMs. The human visual system reads relief best when illumination comes from the upper left, which is exactly why 315 became the default. But it creates a directional filter:

  • Features striking parallel to the azimuth (e.g. NW-SE features under a 315 light) lie along the illumination, receive uniform shading, and effectively disappear.
  • Features striking perpendicular (NE-SW under a 315 light) catch maximum light-and-shadow contrast and look strongly emphasized.

A geologist mapping fracture sets from a NW-lit hillshade will systematically over-count NE-SW lineaments and under-count NW-SE ones. Published structural rose diagrams have been biased this way. The fix is not a better azimuth but multiple azimuths: render at least two contrasting directions (a common pair is 315 and 045, or a full set at 000/045/090/135), or use a multidirectional hillshade that combines several light sources. In GDAL:

gdaldem hillshade dem.tif hs_315.tif -az 315 -alt 45 -z 1
gdaldem hillshade dem.tif hs_multi.tif -multidirectional -z 1

The -multidirectional flag implements the Mark (1992) weighted combination of light from several azimuths, which suppresses the directional artifact at the cost of some crispness. QGIS exposes the same options in the Hillshade processing algorithm and in the layer styling (Hillshade renderer with multidirectional toggle).

Vertical exaggeration: invented relief

When horizontal cell size and vertical units differ, or when an analyst cranks z-factor for "clarity," the hillshade reports a steepness that is not physical. Two situations cause silent errors:

  1. Geographic CRS DEMs. A DEM in EPSG:4326 has cells measured in degrees horizontally but meters vertically. gdaldem partly compensates with the -s (scale) parameter (-s 111120 for degrees-to-meters at the equator), but that scale is only correct at one latitude. At 60 degrees north, a degree of longitude is about half a degree of latitude, so the east-west relief is exaggerated. Reproject to a metric CRS (UTM, a national grid) with gdalwarp -t_srs EPSG:32633 before generating relief.
  2. Deliberate exaggeration for visuals. A z-factor of 2-3 makes gentle plains look like badlands. This is fine for a communication graphic if labeled, but it is poison if a colleague later traces "steep" features or compares it against a true-scale dataset.

Resampling, cell size, and noise artifacts

Hillshade is computed from slope and aspect, which are computed from a 3x3 window, so it inherits every defect of the input DEM and the resampling history:

  • Bilinear or cubic resampling during a warp smooths elevation and softens relief; nearest-neighbour preserves values but leaves blocky stair-steps that hillshade turns into false terraces. For continuous elevation, resample with -r bilinear or -r cubic, never nearest.
  • LiDAR-derived DEMs at 0.5-1 m expose microtopography, but also vegetation removal artifacts, building footprints, and interpolation pits. These render as crisp, geometric-looking features that an unwary interpreter reads as anthropogenic structures or scarps.
  • Striping from sensor or tiling seams (common in SRTM, some photogrammetric DEMs) appears as regular linear relief at the tile pitch. Diagonal striping at exactly 45 degrees to the grid is almost always an artifact, not geology.

Worked example: validating a suspected fault scarp

Suppose a NW-lit 1 m LiDAR hillshade shows a sharp 800 m linear break that looks like a fault scarp.

  1. Re-light it. Render at 045 and at multidirectional. If the feature is real terrain, it persists (with changed contrast) across azimuths. If it weakens drastically or flips polarity, suspect azimuth bias or a tiling seam.
  2. Check it against slope. gdaldem slope dem.tif slope.tif -p (percent) or - (degrees). A genuine scarp shows a coherent slope anomaly; a rendering artifact does not.
  3. Profile the raw DEM. Use the QGIS Profile Tool or Terrain Profile plugin, or sample with gdallocationinfo, across the feature. A real scarp has a monotonic elevation step of a measurable height; an artifact often shows no consistent elevation change.
  4. Check orientation against the grid. If the feature is exactly parallel to the DEM rows/columns or at a clean 45 degrees, treat it as a likely processing artifact until proven otherwise.

Only after the feature survives all four checks should it be digitized as a structural element.

Common pitfalls and why they happen

  • Mapping from one azimuth. Happens because the default 315 is convenient and looks good; it systematically biases orientation statistics.
  • Measuring on the hillshade. Analysts sometimes classify or threshold hillshade values as if they were slope. The 0-255 values are illumination cosines and carry no physical units.
  • Mixing z-factors across layers. Comparing an exaggerated visual hillshade with a true-scale derivative makes relief appear to change between datasets when only the rendering changed.
  • Ignoring CRS units. A geographic-CRS hillshade without latitude-aware scaling exaggerates east-west relief, worst near the poles.

QA checklist

  • Confirm the DEM is in a metric, projected CRS before generating relief, or apply a latitude-correct scale.
  • Record the exact azimuth, altitude, and z-factor used, in the layer name or metadata.
  • Render at two or more azimuths (or multidirectional) for any structural interpretation.
  • Cross-validate suspected features against slope, curvature, and a raw DEM profile.
  • Keep z-factor at 1 for any layer that will be measured or compared; label any exaggerated visual layer clearly.

Bathyl perspective

We treat hillshade as a reading aid and never as evidence on its own. Every structural feature we deliver is illuminated from several directions and confirmed against slope, curvature, and raw elevation profiles, so the interpretation reflects the ground rather than the lighting choice. The rendering parameters travel with the layer, so a reviewer can reproduce exactly what they are looking at.

Related reading

Sources