What is multidirectional hillshade and how does it differ from standard hillshade?

Standard hillshade simulates illumination from one sun azimuth, so slopes facing away fall into flat shadow. Multidirectional hillshade combines illumination from several azimuths (the GDAL/Imhof implementation uses 225, 270, 315 and 360 degrees) and weights them, revealing landforms on all aspects without one dark side.

How do I create multidirectional hillshade in GDAL or QGIS?

Run gdaldem hillshade dem.tif hs.tif -multidirectional -z 1.0. In QGIS use Raster terrain analysis or the GDAL hillshade tool with the multidirectional option. Ensure the DEM is in a projected CRS with metres and set -z for vertical exaggeration only if needed.

Why does single-azimuth hillshade hide terrain on shadowed slopes?

With one light source (commonly azimuth 315 degrees, altitude 45 degrees), slopes facing away from that azimuth receive little light and render near-black, so valleys, gullies, or faults on those aspects disappear. Multidirectional lighting fills those shadows.

Should hillshade be used as an analytical or measurement layer?

No. Hillshade is a visualization derived from slope and aspect for one or more illumination angles; it is excellent for interpretation but is not a measurement. For analysis use slope, aspect, curvature, or roughness rasters with explicit units.

Multidirectional Hillshade for Relief Maps

Short answer

Multidirectional hillshade is a shaded-relief image computed by illuminating a DEM from several azimuths at once and blending the results, rather than from a single simulated sun. It exists to fix a specific weakness of standard hillshade: with one light source, slopes facing away fall into near-black shadow and any landform on that aspect vanishes. By lighting from multiple directions, terrain reads clearly on every aspect. The canonical implementation in GDAL (after Imhof) combines azimuths of 225°, 270°, 315° and 360° with aspect-dependent weights.

It is a visualisation layer. It helps the eye read ridges, valleys, faults, terraces and landslide scars, but it is not a measured quantity. For analysis use slope, aspect, curvature, or roughness, each with explicit units.

Why single-azimuth hillshade fails

Standard hillshade models a single sun at an azimuth (compass direction, default 315° = NW) and altitude (angle above horizon, default 45°). The brightness of a cell is the cosine of the angle between the surface normal and the light vector, so cells whose aspect faces the light are bright and cells facing away are dark. The problem is twofold:

Aspect bias. A NE-trending fault scarp lit from the NW is rendered, but a parallel feature on a NW-facing slope is washed into shadow. Whichever azimuth you pick, some structures are favoured and others are lost.
Azimuth illusion. The human visual system assumes light comes from the upper-left; lighting from the "wrong" azimuth can make valleys look like ridges (relief inversion). That is why 315° is the conventional default.

Single-azimuth shading is still the right choice when you want to emphasise structures of one orientation — for example, picking out NE-trending lineaments by lighting perpendicular to them. But for a general relief base map, it throws away half the terrain.

How multidirectional hillshade works

The Imhof / GDAL method computes hillshade from multiple azimuths and combines them with weights that depend on each cell's aspect, so every slope is lit by at least one favourable direction while avoiding a flat, washed-out look. The result is a single grey raster where landforms of all orientations are legible and there is no dominant dark side. It deliberately trades the strong directional "drama" of single-azimuth shading for even, interpretable relief — which is usually what you want under a geological or topographic map.

Creating it: GDAL and QGIS

First, get the DEM right. It must be elevation data, not a coloured picture of elevation, and it should be in a projected CRS in metres so that horizontal and vertical units are consistent. A DEM in geographic degrees will produce a distorted, over-steep shade because the slope calculation treats degrees as if they were the same unit as the elevation.

GDAL:

gdaldem hillshade input_dem.tif hillshade_multi.tif \
  -multidirectional -z 1.0 -alg Horn -compute_edges

-multidirectional selects the multi-azimuth algorithm (it ignores -az, since direction is no longer a single value).
-z is vertical exaggeration; keep it at 1.0 for honest relief and raise it only to reveal subtle terrain, noting it on the output.
-alg Horn is the standard 3×3 slope estimator; Horn is generally preferred over ZevenbergenThorne for shaded relief.
-compute_edges avoids a black one-pixel border at the DEM edge.

If the DEM is in degrees and you cannot reproject, -s (scale) can convert units (e.g. -s 111120 for degrees-to-metres at the equator), but reprojecting with gdalwarp -t_srs EPSG:326xx first is cleaner and more accurate.

In QGIS, Raster → Analysis → Hillshade (GDAL) exposes a Multidirectional checkbox; the Raster terrain analysis provider also offers hillshade. To stack it under map units, render the hillshade with ~50% opacity or use a multiply blend mode over a hypsometric (elevation-coloured) layer, a combination that reads far better than either alone.

Resolution: more is not always better

A 1 m LiDAR DEM resolves individual terraces, ditches, and tree-throw mounds; a 30 m SRTM DEM gives broad landform shape. Higher resolution is not automatically better:

High-resolution DEMs amplify noise — sensor speckle, vegetation returns, building edges — into busy, distracting shade. Smoothing the DEM (a low-pass filter or gdalwarp -r cubic to a coarser grid) before shading often produces a cleaner relief for regional interpretation.
The right resolution matches the question. Mapping a fault trace at 1:50,000 does not benefit from 1 m detail and may be hurt by it.

When comparing two relief images, match cell size, extent, vertical exaggeration, and algorithm; otherwise differences in the picture are processing artefacts, not terrain.

Common pitfalls and why they happen

Treating hillshade as a hazard or measurement layer. It is a rendering of slope and aspect under chosen lighting; it has no units and should never be classified as if it measured something. The grey values depend on the illumination settings, not on a physical property.
Shading a DEM in geographic degrees, which mismatches horizontal and vertical units and exaggerates slopes everywhere.
Confusing a DEM with a DSM. Shading a Digital Surface Model (which includes trees and buildings) when you wanted bare-earth relief produces a canopy texture, not landforms.
Over-cranking -z, which makes a striking image but misleads anyone reading relative relief.
Ignoring DEM artefacts — striping, voids, edge-of-tile seams — which hillshade makes painfully visible; inspect and patch the DEM first.

QA and validation

Before publishing: confirm the source is a bare-earth DEM with known vertical units and a projected CRS; check the shade against a known feature (a mapped ridge, a road cut) to confirm relief is not inverted; scan for striping, voids, and tile seams that betray DEM problems; and record resolution, source DEM, algorithm, vertical exaggeration, and that the layer is multidirectional in the map notes. Generate slope or aspect separately for any quantitative claim, rather than reading numbers off the hillshade.

Bathyl perspective

We use multidirectional hillshade as a relief base that lets every landform read clearly, then keep the analytical work — slope, aspect, curvature — in separate, unit-tagged rasters. The shade is for the eye; the measurements are for the analysis. Stating which is which, plus the DEM source and resolution, is what makes a relief map trustworthy rather than merely attractive.