This is to make "shaded relief" maps of a 2-byte integer bitmap. This uses the algorithm used by the USGS in making their shaded relief maps and avoids the less desireable use of simple derivatives often employed. It is primarily intended for use with TopoToAlbersFull output, but will work with any appropriate file. Simple modifications would allow the use of any format of data.
The basic idea is that you specify a source illumination (sun angle) and the input elevation file and the program generates an output binary file of brightnesses of each pixel (the exact tricks are discussed below). The output file is a binary file of short integer (2 byte) values ranging from 0 to some value less than 32768. (All slopes considered to be shaded are forced to be 0). This same algorithm can be used within Spyglass Transform, but this code is usually more convinient (and allows for larger files to be made).
You are asked for the input file and then asked to tell the code how long each input line is (namely, how many pixels wide is this image). If you saved the height x width information in the file name from TopoToAlbersFull, this is simple--use the second number (it is the same value you gave TopoToAlbersFull). The code then figures out how many lines (i.e., how high the bitmap is) and outputs this for your verification. If the output is not an integer, you may have input the wrong value for the width of the bitmap. You then name the output file and provide the illumination parameters.
The illumination parameters are mostly simple. The first number is most confusing; it is the ratio of the distance between grid points and integral increments of the function. This allows the use of non-topographic inputs. For output from TopoToAlbersFull, you should have seen an estimate of the grid spacing in meters; this is the number you want to input here. It need not be exact; in fact, you could be quite far off and still produce an acceptable looking image. Next you give the azimuth and elevation of the sun, where the azimuth is the direction, in degrees clockwise from "up" on the bitmap that the sun (source of illumination) is. In general, this should be to the left or upwards (even though this doesn't often occur on the Earth!) as this produces images usually recognizable to most people. Using illumination azimuths of 0, 90, 180, or 270 degrees runs the risk of highlighting grid edges from some databases (though the use of a projection in TopoToAlbersFull reduces this problem); if you see strange lines running across your output, you might change the sun azimuth. The sun elevation is in degrees upward from "the horizon" (flat). Moderately low values (20-30 degrees) seem to produce an acceptable amount of shading. Having the sun overhead (90 degrees) will produce a very flat image. The final value is the vertical exaggeration; you could recover from a bad estimate of the ratio here. This tends to exaggerate the difference between steep slopes of different orientations. Values of 1-2 seem to work fine. Note the range of output shading values for use in Shade32.
You then sit and wait awhile (depending mainly on the speed of your hard drive) for the code to finish.
Details. What happens in this code is that the orientation of the bitmap surface is calculated for a series of triangles, where the vertices are the point in question, the point to the right and the point below. Purists will note that this isn't really the most desireable way to figure slopes, but it is (1) fast and (2) preserves high resolution variations in slope. Because of the biases, if you were being finicky about using the output file, the output grid is really down and to the right of the input grid by about 1/3 to 1/2 of a grid spacing. At the right edge, the three points are the point, the point to the left, and the point below. At the bottom, the three points are the point, the point to the right, and the point above. Again, this is not technically legal, particularly as it means that the edges have a different offset from the original grid than the main body of the output bitmap, but in practice the results look ok. The output value (illumination) is given by the equation I = 1/(1+[cos e / cos i]), where e is the angle between observer and slope normal and i is the angle between the illumination source and the slope normal. The rest is simply algebra.
Shade_32 differs from nearly all the other codes I've made for this work in having a Mac interface. As such the details of use are not nearly so important as in the other programs, which are essentially shell-type programs. Shade_32 combines either topography or a PICT file with a releif file to make a 32-bit shaded topo map. Note that this code will not run on a system lacking 32-bit Quickdraw. It will produce the 32-bit color PICT regardless of the capability of the screen you are viewing.
It is first important to know that colors can be specified as combinations of red, green, and blue (RGB) or equally well as hue saturation and lightness (HSL). In this code, the hue and saturation at any point are derived from either the combination of the topo and palette files or from a PICT image; variations of lightness are derived from the relief file, though base values of lightness can either be fixed or derived from the topo+palette or PICT image, if desired. In essence, the hue+saturation describes most of what we view as "color" while the lightness reflects a sense of how well lit that color is.
The "Map slope to lightness using" section controls how values between "flat" and the extrema are dealt with. In a linear usage (fairly common) the lightness value is simply a linear interpolation between those assigned the flat and relevant extremum. If a square(slope) relation is added, values near the flat value are de-emphasized, and shading is concentrated in areas of high relief. If square root is chosen, the areas of low relief are increasingly emphasized. Some trial and error with these parameters should produce interesting results. Examples in the examples folder should illustrate this somewhat better.
Typical usage of this dialog might be to use palette lightness for flat values, to use lightness % from black, and to use %'s of about 85-90% for the two lightness extrema. In general, this should produce acceptable first results. A linear slope-lightness relation is usually adequate, though a small amount of square root(slope) sometimes is useful in areas of laterally strong variations in relief.
You might wish to first play with a small file to gain experience in anticipating how an image will come out before trying a large file, which can take a long time. Hopefully future versions of the code will have use of IEEE type math and will move much faster (10-20 times faster), permitting interactive changes to even large images. There is a test topo, PICT and relief file in the Shade 32 Test Files folder; these can be used with the palettes in the Raw colormaps for Shade 32 folder.
Return to C.H. Jones home page
Craig Jones, cjones@mantle.colorado.edu