Project

General

Profile

Feature #407

shade appears to not be correctly adding shadows (ISIS v3.2.1)

Added by Trent Hare over 6 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Applications
Target version:
-
Impact:
Software Version:
Test Reviewer:

Description

Based on this discussion thread, it appears "shade" is not calculating correct shadows. The image grows brighter but shadows do not grow.

https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3223.0.html

See attached images which I ran making sure to use a topo DEM not radius.
ISIS3
shade10.cub : z=10
shade30.cub : z=30
etc.

GDALDEM
gshade10.tif : z=10
etc.

runs:
shade from=LOLA_npolar.cub to=shade10.cub zenith=10 azimuth=315
shade from=LOLA_npolar.cub to=shade30.cub zenith=30 azimuth=315
shade from=LOLA_npolar.cub to=shade50.cub zenith=50 azimuth=315
shade from=LOLA_npolar.cub to=shade70.cub zenith=70 azimuth=315
shade from=LOLA_npolar.cub to=shade90.cub zenith=89 azimuth=315

gdaldem hillshade LOLA_npolar.cub gshade10.tif -alt 10
gdaldem hillshade LOLA_npolar.cub gshade30.tif -alt 30
gdaldem hillshade LOLA_npolar.cub gshade50.tif -alt 50
gdaldem hillshade LOLA_npolar.cub gshade70.tif -alt 70
gdaldem hillshade LOLA_npolar.cub gshade90.tif -alt 90

Steps to reproduce:

run shade at various zeniths (shadows should grow).

Also a zenith=90 does not work. Seems to just stall - no errors.

Additional information:

Here is the code from GRASS/GDAL:
http://perrygeo.googlecode.com/svn/trunk/demtools/hillshade.cpp

ISIS3shade_vs_GdalDEM.jpg View (265 KB) Redmine Admin, 2011-09-09 11:08 AM

History

#1 Updated by Stuart Sides about 6 years ago

Further information from Jeff A. and Randy K. has been requested. They talked about this subject in an AIM/SSC meeting, but a resolution was not documented.

#2 Updated by Jeff Anderson about 6 years ago

Mark Robinson has requested this feature in ISIS I will ask to see if he is willing to provide any support.

Jeff

#3 Updated by Jeff Anderson about 6 years ago

We should allow the user to enter a level1 / level2 cube to read the input parameters (e.g., zenith, sun azimuth) or allow the user to enter them directly

#4 Updated by Randolph Kirk about 6 years ago

I agree with Trent's assessment that this is essentially a feature of the current implementation. As you increase the zenith angle you should see areas of shadow (zero output) appear where the local slope faces away from the Sun, but there will be no cast shadows.

It would be possible to modify the program to also compute cast shadows, and might be worth considering if there is enough interest and especially if there is funding. The new algorithm would be vastly more complex because what shade does now is a strictly local computation, but cast shadows are global.
My opinion is that modifying shade in this way is not especially useful and should not be a high priority. Shade is meant to make shaded relief maps as a way of visualizing DTM data, NOT to simulate images realistically. Cast shadows make the result more photo-realistic but they also hide parts of the data set.
Where I would like to see the effort expended is to compute cast shadows in photomet, which IS intended to simulate images realistically, so the inclusion of such shadows here has real scientific value as opposed to just aesthetic plusses and minuses.
Another alternative development that could be useful is to add a new mode to shade so that the light source can be from a fixed compass direction (e.g., west) at each point, in addition to the current option of a fixed direction on the map raster. This would let us make shaded relief maps in polar projection and for globes. (The third option, light coming from a consistent direction in relation to the bumpy ellipsoidal planet, is what photomet does already so it's not needed in shade. This also means that getting a sun vector from a Level 1 image--Jeff's second suggestion--does not make much sense for shade.)

#5 Updated by Tammy Becker over 5 years ago

Can Jeff Anderson,Randy, Trent confirm the status of this post? Can this be closed? Should a separate post be added based on Randy's notes?

#6 Updated by Stuart Sides over 5 years ago

This has been changed to a feature request and put on hold until it is funded.

#8 Updated by Anonymous over 4 years ago

  • Target version deleted (150)

#9 Updated by Trent Hare 5 months ago

  • Status changed from Acknowledged to Closed
  • Assignee set to Trent Hare

hillshading is typically a local effect and has been fixed (ticket #4326). True shadow casting was not originally needed here and thus this ticket can be closed. As Randy implies true shadow casting is better in a photometry application.

Also available in: Atom PDF