Create a high accuracy hillshade with shadow casting
Overview
Parameters
Example 1
Example 2
Description
This program, shadow, will create a shaded-relief cube from a digital
elevation model (DEM) and a MATCH cube.
We use the sun's position at the center of the input cube or a user-defined
observation time. By default, we factor in shadows cast by features.
This program operates much like the ISIS 'shade' program which instead requires azimuth/elevation as input.
However, with the shadow application, using the sun's position allows much
higher precision shading and enables the possibility of computing shadowed areas.
The algorithm description below is provided to help understand the
optimization settings.
User-Requirements
The user must supply an elevation model (DEM) and either an observation time or a cube
with raw camera geometry (see 'spiceinit'). If providing an observation time, the PCK and SPK SPICE kernels
associated with the DEM's target must have been downloaded and be available on the user's machine in the "base" kernels area, or their file paths must be provided as values to the PCK and SPK user parameters.
Understanding the Algorithm
The 'shade' program's algorithm is called 'hillshade' in this algorithm description.
Compute the sun's position at the center of the MATCH cube. The MATCH cube must have the
same target as the DEM.
For every pixel in the input elevation model, compute the hillshade value for the pixel, and
if the hillshade result is positive (facing towards the sun), then estimate if the pixel is
in shadow;
if the hillshade value is positive and the pixel is in shadow, then the result is an LRS;
if the hillshade value is positive and the pixel is not in shadow, then the result is the
hillshade result and
if the hillshade value is negative, the result is low resolution saturation (LRS).
The algorithm to estimate if a pixel is in shadow:
Optimization: If SHADOW, and this elevation model pixel is known to be shadowed,
consider this pixel to be shadowed and stop (no pixels are initially known to be
shadowed).
Compute the pixel's body-fixed coordinate (XYZ) position.
If SUNEDGE, adjust the sun's position to nearer the highest (on the horizon) edge of
the sun.
Subtract the sun's position from the elevation model pixel's position, providing a vector
to the center (or edge) of the sun.
Iterate until a solution is found:
Step along the 3D ray the current estimate of PRECISION pixels
Project the ray back onto the elevation model to find the equivalent radius
Update estimate of how far along the 3D ray is equivalent to the full resolution of the
elevation model.
Optimization: Multiply the step by PRECISION.
Optimization : If SKIPOVERSHADOW, while the next linearly-extrapolated elevation
model position is known to be in shadow, increase the next step size by the
estimate up to MAXSKIPOVERSHADOWSTEPS times.
Check for a solution
If the equivalent radius is higher than the ray, then the originating pixel is
shadowed.
If the ray's elevation is higher than the highest point on the elevation model,
the originating pixel is in light.
Optimization: If LIGHTCURTAIN, and the ray's elevation is higher than a previous ray
that intersected this pixel in the elevation model, consider the
originating pixel in light.
Optimize
If LIGHTCURTAIN, and the pixel was determined to be in light, record the elevations of
the ray where it projected onto the elevation model.
Optimization: If LOWERLIGHTCURTAIN, lower the elevations along the ray by
subtracting the minimum difference between the ray and the elevation model while
the ray was being walked.
Optimization: If CACHEINTERPOLATEDVALUES, linearly interpolate the points where the
ray would have intersected the elevation model to one pixel accuracy.
If SHADOWMAP, and the pixel was determined to be in shadow, record all points where
the ray projected onto the elevation model to be known shadowed points, excluding
the actual intersection point.
Optimization: If CACHEINTERPOLATEDVALUES, linearly interpolate the points where the
ray would have intersected the elevation model to one pixel accuracy.
The caches inherently cause inaccuracies (approximately 1-2 pixels if CACHEINTERPOLATEDVALUES is
off) in the output shadow positions because they record sub-pixel values as if they were the
center of the pixel.
Periodically, the caches are shrunk to lower memory usage. The light curtain cache is shrunk
to around BASELIGHTCACHESIZE entries and the shadow map cache is shrunk down to around
BASESHADOWCACHESIZE entries. Each cache entry is approximately 24 bytes for the light
cache, and 16 bytes for the shadow cache, but the caches are hash-based causing a large amount
of potential overhead. The caches are not limited to their specified sizes, only reduced
to them periodically, and larger cache sizes result in this program consuming more memory.
The larger the cache, the longer it takes to lookup a single value (which happens often).
In general, larger caches mean less CPU time for the cost of memory.
This should be a DEM with the same target as MATCH, if MATCH was entered. To create a DEM,
you must create a projected cube with radii as DN values that has been run through
the program demprep.
This is the estimated radius of the sun in solar radii. Since the unit "solar radius" is
not our best guess of the sun's radius, the default is slightly different than 1.
A larger number has the end effect of lessening shadows; a smaller number increases
shadows. The sun's radius is only used for shadow computations. Hillshade always uses the
sun's center.
This should be the time of the observer to use for the sun's position. The entered time
will be adjusted for light-time between the sun and the observer. The format should be
"YYYY-MM-DDTHH:MM:SS.SSS"; for example, "2012-01-01T14:25:15.36"
This is a list of quick settings for the other parameters in the Optimizations group. This
also includes the ability to disable the shadow computations entirely. These options are
provided for those who do not need a lot of customization or do not want to calculate
shadow positions.
Type
string
Default
BALANCED
Option List:
Option
Brief
Description
NOSHADOW
Skip the shadow calculations completely
This results in no shadow calculations being done at all; this program effectively
becomes a higher resolution version of the 'shade' program. This will significantly
lower CPU and memory requirements.
Exclusions
SHADOWMAP
BASESHADOWCACHESIZE
LIGHTCURTAIN
BASELIGHTCACHESIZE
PRECISION
CACHEINTERPOLATEDVALUES
SKIPOVERSHADOW
MAXSKIPOVERSHADOWSTEPS
LOWERLIGHTCURTAIN
BALANCED
Balance performance and accuracy
This is the equivalent of:
SHADOWMAP=true
BASESHADOWCACHESIZE=1 million
LIGHTCURTAIN=true
LOWERLIGHTCURTAIN=true
BASELIGHTCACHESIZE=1 million
PRECISION=1.0
CACHEINTERPOLATEDVALUES=false *Since precision is 1, interpolated values are
unlikely
SKIPOVERSHADOW=true
MAXSKIPOVERSHADOWSTEPS=5
Exclusions
SHADOWMAP
BASESHADOWCACHESIZE
LIGHTCURTAIN
BASELIGHTCACHESIZE
PRECISION
CACHEINTERPOLATEDVALUES
SKIPOVERSHADOW
MAXSKIPOVERSHADOWSTEPS
LOWERLIGHTCURTAIN
ACCURATE
Maximize result accuracy at the cost of performance
This doesn't guarantee perfect accuracy; however this should be more than reasonable
for any products. If you want absolute perfection, try lowering the precision to about
0.5 (two ray-DEM intersection checks per DEM pixel walked) and use the other
settings described here. This setting ought to be well within a pixel of accuracy.
These presets cause very heavy CPU usage but low memory usage.
This is the equivalent of:
SHADOWMAP=false
BASESHADOWCACHESIZE=N/A
LIGHTCURTAIN=false
BASELIGHTCACHESIZE=N/A
PRECISION=0.98 (results in a slightly higher accuracy than 1 pixel)
Exclusions
SHADOWMAP
BASESHADOWCACHESIZE
LIGHTCURTAIN
BASELIGHTCACHESIZE
PRECISION
CACHEINTERPOLATEDVALUES
SKIPOVERSHADOW
MAXSKIPOVERSHADOWSTEPS
LOWERLIGHTCURTAIN
CUSTOM
Customize optimizations
If you want detailed customizations for how the shadow estimation algorithm
runs/interpolates/caches/etc then this is what you should choose. This enables manual
inputs of all of the other optimization options.
When a ray is determined to be in shadow, every DEM pixel between the original position and
the point at which the DEM intersected the ray will be marked as in shadow. We then perform no
significant work when processing a pixel that we previously determined was in
shadow. This also helps avoid unnecessary ray-DEM intersection checks (because surfaces
are not shadowed by surfaces already in shadow).
The shadow cache is allowed to grow to an unlimited size while the shadowing algorithm is
processing. This is the approximate number of elements to shrink the
shadow cache to, as periodically the caches are shrunk. The shrinking is optimized in a way that
is mostly respected, but not guaranteed.
With this option enabled, when a ray goes above the light curtain, without interesting the
elevation model first, the pixel is considered to be in light. The light curtain is
derived from previous rays that were found to be in light.
This adjusts light curtain elevation values to their theoretical minimum (the lowest
elevation the ray could have been and still been in light) instead of using the
actual ray elevation values in the light cache. This is done by subtracting the
minimum difference found between the ray and DEM when doing ray-DEM intersection tests.
Please see the program description for more information.
The light curtain cache is allowed to grow to an unlimited size while the shadowing
algorithm is processing. This is the approximate number of elements to
shrink the light caches to, as periodically the caches are shrunk. The shrinking is optimized
in a way that this is mostly respected, but not guaranteed.
Add interpolated cache entries between actual ray-DEM intersection checks. This will not
have any significant effect if your precision is 1 or less. Please see the program
description for more information.
This is a means to lessen the number of ray-DEM intersection checks by guessing the
next ray-DEM intersection location and checking if it is in shadow. If it is, the ray
is stepped farther before the next intersection test (up to MAXSKIPOVERSHADOWSTEPS
farther).
Since the ray will not make a perfectly straight line across the DEM (DEMs are
projected onto a flat surface) a linear guess as to the next intersection point degrades
in accuracy (depending on a number of factors, such as ray elevation, projection type, and
DEM accuracy). This controls how far the algorithm can guess the next intersection point
for SKIPOVERSHADOW using linear extrapolations.
Run this program given a high resolution DEM 'localdem.cub' and the lighting
characteristics from 'ab102401.cub' to create 'shadowed.cub'
GUI Screenshot
Graphical Interface
Example of parameters in the graphical interface
Run this program using the high resolution DEM 'localdem.cub' and the lighting
characteristics from 'ab102401.cub' to create the 'shadowed.cub'
Input Images
FROM DEM
FROM DEM to do shaded relief and shadow calculations on
This is the elevation model for which the shaded relief and shadow
positions are to be computed. This is the FROM cube.
MATCH cube
MATCH image for computing the sun position
We gather the sun position from this image. In other words, we are trying
to make the DEM look like this image.
Projected MATCH image
MATCH cube projected for comparison with results
This is the MATCH cube projected into the same projection as the DEM. This is helpful
for comparing to the results of this program.
Output Images
Output Shadowed Shaded Relief
Output shaded relief with shadows
This is the result of the shadow program. This is the TO cube.
The shadows are not as big as the shadows we see in the projected MATCH image because
we have computed the fully shadowed areas in this program. Areas of the image that are
getting less light, but not fully shadowed, still appear in the shadow, but
show more detail in them. To extend the shadow computations to encompass the visible
shadow completely you can turn off SUNEDGE.
Comparable Shaded Relief
Equivalent shaded relief from shade
This is the result of the shade program with roughly equivalent input angles.
This shows how significant of a difference the shadow computations make.
Example 2
Run with TIME
Description
This example will cover running this program in balanced mode with a lunar DEM and a time.
Run this program given a global lunar DEM 'dem.cub', with the lighting
characteristics (sun's position) from midnight March 1st, 2012, and a high accuracy ray
trace to create 'shadowed_dem.cub'
GUI Screenshot
Graphical Interface
Example's parameters in the graphical interface
Run this program given the DEM 'dem.cub' and the lighting
characteristics from midnight March 1st, 2012 to create 'shadowed_dem.cub'.
Input Image
FROM DEM
FROM DEM to do shaded relief and shadow calculations on
This is the elevation model for which the shaded relief and shadow
positions are to be computed. This is the FROM cube.
Output Image
Output Shadowed Shaded Relief
Output shaded relief with shadows
This is the result of the shadow program. This is the TO cube.
This is what a mosaic of the entire moon would look like, approximately, if all
images were taken at one time.
