Astro3310 – Planetary Image Processing Lab 4: Topographic Analysis

Download 85.63 Kb.
Size85.63 Kb.

Astro3310 – Planetary Image Processing

Lab 4: Topographic Analysis

Due: October 8, 2015

Reading: Jankowski, D. G and Squyres, S. W. (1991) Sources of error in planetary photoclinometry, J. Geophs. Res. 96, 20907-22.

Reflectance from Planetary Surfaces (Included in Appendix to this Lab)

Resources: If you have any questions, Prof. Hayes’ office is 412 Space Sciences.

Credit: A portion of this lab was produced by Prof. Oded Aharonson for Caltech course Ge151 (Planetary Surfaces), modified by Teaching Assistants Kevin Lewis and Alex Hayes in 2007/2008 and now Prof. Alex Hayes in 2015 (Note: Kevin Lewis is now an Assistant Professor at Georgia Tech and looking for graduate students).

Instructions: Download the data package from:

Work through the lab instructions below. Comments written in bold text are questions that need to be addressed in your lab writeup. A consolidated list of the questions can be found in the the lab writeup, which can be downloaded from:


Over the course of this lab you will learn:

  • How to find, retrieve, and process raw imaging data from MOC
    (and understand the processed in general).

  • How to obtain topographic data using photoclinometry on processed images.

  • How to look at single-track altimetry data from the MOLA instrument.

  • How to use stereo topographic data from MOC

  • The benefit and limitations photocliometry, altimetry, and stereo topography.

  • Deducing some simple things about geomorphic features on Mars.

I. Image Processing:

We're going to start with pre-selected images to demonstrate basic image processing and some of the software packages that are used to do it. The filename of the image is m0806185.imq. This is an image taken in the Arabia Terra region of Mars in October 1999 by the Mars Observer Camera (MOC), part of the Mars Global Surveyor (MGS) mission, which officially ended in January 2007 (R.I.P.).

The image has been prepared for release by the Planetary Data System (PDS; These people are responsible for providing a consistent format for all current and future planetary missions (they're slowly converting the older ones as well) known, unsurprisingly, as PDS format. PDS images typical have either an .img or an .imq suffix (.imq is simply a compressed version of .img). They have a text header with information specific to that image followed by the binary image data itself.

After downloading the data package, move into the LAB 4 directory generated when you extracted the archive.

Now we're ready to look at some images. From the DATA sub-directory, take a look at the image file either in a text editor or by typing 'less m0806185.imq' at a Mac terminal, Windows Cygwin Terminal (if you have one), of Linux / Unix prompt (type 'q' to exit). There are other files there but ignore them for now. The information contained in the header usually relates to things which won't change such as the time the image was taken, the gain state of the camera or the number of lines and samples in the image. Other information such as the position of the spacecraft relative to the planet, the longitude and latitude of the image or the size of the pixels in meters is subject to change as better solutions for the orbit of the spacecraft are developed. This other information is not part of the image file as it would be a huge effort to revise the whole dataset each time these new and improved numbers are derived.

MOC images are identified by an 8-digit name; the first 3 characters denote the mission phase m08 in this case means the ninth mapping phase. Each mapping phase lasts roughly one calendar month. Other prefixes exist such as ab1, sp2, fha and cal which stand for aerobraking phase 1, science phasing 2, full high gain antenna and calibration phase respectively. These other phases took place early in the mission and were pretty short. The remaining 5 characters represent the orbit number (first 3 characters) and the image number (last 2 characters) within that orbit. So in the case of our image m0806185, it is the 85th image taken on the 61st orbit in mapping phase 8.

MOC is a line scan camera i.e. it has one row of detectors that sweeps across the surface of the planet as the spacecraft moves in its orbit. The resolution along this line (known as cross-track resolution) is set by the height of the orbit i.e. if the spacecraft is far away from the planet each pixel sees more of the surface. The mapping orbit was planned to be ~400 km high, however there is ~30 km of relief on the planet (from the summit of Olympus Mons to the bottom of the Hellas impact basin) so the cross-track resolution can vary from place to place on the planet (by almost 10%). The down-track resolution is determined by the groundspeed of the spacecraft (~ 3 km s-1) combined with the length of time the camera exposes each line. Ideally, you want the spacecraft to move only a fraction of a pixel (to prevent smearing) in the down-track direction during an exposure, however the exposure must be long enough to collect sufficient light for a high signal to noise ratio. The camera sensitivity, cross-track resolution and mapping orbit parameters have been designed so that the pixels have roughly the same resolution in the cross and down track directions. Changes in distance to the surface and surface reflectivity mean that the pixels are not entirely square so all MOC images have some non-unity aspect ratio. Sometimes this can be quite severe and must be removed before the image makes any sense. In general it is always nicer to correct the aspect ratio when looking at images (there is something fundamentally disturbing about elliptical craters).

MOC images are always taken at the full resolution of the camera (~1.4 meters/pixel for the narrow angle) but, to cope with the voluminous amounts of data, the spacecraft computer intentionally degrades the resolution by summing and averaging pixels in both the cross and down-track directions. This summing is not necessarily the same in each direction so in addition to the inherent aspect ratio there is sometimes an induced aspect ratio due to this differential summing. Note that the HiRISE camera onboard the Mars Reconnaissance Orbiter (MRO), which is currently taking data on Mars, acquires images at ~0.1 meters/pixel!

ISIS (Integrated Software for Imagers and Spectrometers)

ISIS is a software package developed by the United States Geological Survey (USGS) for use with spacecraft data. ISIS is really a collection of stand-alone programs, which perform operations on datasets such as map-projecting of an image onto a reference ellipsoid. In this case we are going to use some of the programs in the ISIS package to calibrate our image.

ISIS has its own environment from which you can call these programs known as tae. It's possible to call them as stand alone programs as well directly from the terminal. If you use a Mac or Linux computer, you can install ISIS yourself for free. There are number of great tutorial and help files available on the ISIS website if you do (not required for the lab).

ISIS works with its own image format called 'cubes' with a .cub extension. An ISIS cube contains header information like the PDS format does. The first step will be to convert this image into the ISIS format. This is known, as level 0 processing i.e. it isn't really processing at all but just data translation. To save time and save you from having to install ISIS on your computer, we have run of all the processing for you. However, the script used to run all of the necessary ISIS programs to do this conversion is in the lab DATA sub-directory and, if you so desire, you can look at it. The filename is To be fare, this script calls perl scripts that are part of the now outdated ISIS 2 library (ISIS is now up to version 3 and working on version 4). However, it would be relatively straight forward to convert the various functions to their ISIS 3 (and soon 4) equivalents.

OK, now we can take a look at this image. ISIS has created a file called m0806185.lev0.cub; this is the raw data in ISIS 2 format There are also updated ISIS 3 format files and PNG formatted 8-bit images for ISIS 2 data file. You either view the ISIS 3 cube file (m0806185.lev0.isis3.cub) in matlab, or the PNG file (m0806185.lev0.png) in your favorite image viewer (like Photoshop, which is now free to Cornell students!). To view the file in matlab you can use our familiar friend read_isis.m, which is stored in the lab SUBROUTINES sub-directory. From you Matlab window, move into the REPORT sub-directory for the lab (if you are not already there) using the “cd” command or the graphical file toolbar. Once you are in the directory, load the matlab programs relevant to the lab by typing “addpath(genpath(‘../.’))”. This will load all of the files in the matlab subdirectory into Matllab’s memory. To load the image, type “img0 = read_isis(‘m0806185.lev0.isis3.cub’);”. Now you can display the image using the “imagesc” command by typing “figure; imagesc(img0’); colormap gray; axis equal;” or using more advanced image display and stretching routines that we went over during the Matlab Image Tutorial. If you want to open the image in an image browser, simply pick your favorite image browser and open the PNG file.

Now that we have the image up, lets discuss it. Well, its pretty ugly! It's streaky, looks like it has an aspect ratio problem and looks pretty uninspiring in general. However you can turn this into a thing of beauty and scientific worth in a few easy steps by puttning the image througha calibration pipeline (remember LAB 3?). First, however, take a moment to look over the image zooming up on the interesting stuff.

Next we will look at the level 1 cube for this image. Level one means that the image has been radiometricaly corrected i.e. the previous DN values have been converted into meaningful I/F values (see the appendix to this lab for the explanation of what I/F means). Open up the file m0806185.lev1.isis3.cub (or m0806185.lev1.png) and take a look. It should be looking a whole lot better now; the streakiness was due to different pixels on the line array having different quantum efficiencies (i.e., the bright ones were very efficient at recording light and the darker one were not). The calibration process has taken account of that and 'flattened' all the columns. You’ll also notice that the pixel values are now between 0 and 1, as opposed to 8-bit values between 0 and 255.

This is still not the ideal situation, however, as the image is still distorted because of its aspect ratio and because we have no idea of what the scale is and which way is north. What we really need to do to answer all of them is map project the image into some reference coordinate system. Level 2 images do just this. Open up m0806185.lev2.cub. The image has now been projected into a 'sinusoidal' projection. This converts lat/lon (in degrees) to x/y coordinates (in meters). The conversion is calculated roughly as y=(lat/360)*2pi*RMars, x=(lon/360)*2pi*RMars*cos(lat). As we will discuss in lecture, there are many other projections that all have their own advantages and disadvantages, but they are beyond the scope of this lab.

In the lab data directory, there is a MOC Wide-Angle image (M0806186.jpg), which corresponds to the NAC image we've been looking at. Wide Angle images are helpful for understanding the context of the very small area within a Narrow Angle image. This image can be viewed either in matlab or photoshop. To load the image in matlab type “wac=imread(‘M0806186.jpg’);” and using the same commands as before. Alternatively, simply open the image up using your favorite image browser. Describe the various forms and processes you see in the Narrow Angle image, using both it and the context MOC image. Try and figure out what you're looking at. We recognize that this is not a geology class, but photointerpretation is relevant to image processing so try and describe the context provided by the images. Label a few of the main features and save a figure in your REPORT sub-directory.

Searching for your own images

Staying with the case of MOC images, several websites are now offering various search mechanisms. Each one has its advantages and disadvantages a quick summary of the main three follow.

This site is run by the USGS. Its main benefit is that if you know the image name then you can find and download it very fast as everything is arranged by orbit number.

This is the website of the company that actually built the MOC camera. They are also interested in the science it returns and have constructed a graphical database for all the publicly released images. Its difficult to find a specific image in here but this site is great for browsing regions of the planet if you don't know exactly what you're looking for.

This site is provided by the PDS. It's an extension of a search engine from the previous major Mars mission (Viking). This allows searching graphically by zooming up on a map of the planet. However, the thing that makes this site so very useful is the ability to search the MOC dataset using forms. You can specify any number of image parameters (including latitude and longitude ranges) and get a list of all the images, which match your search. Preview thumbnails are available and each image can be viewed online and downloaded in any number of formats.

II. Altimetry and Topographic Analysis:

This section of the lab is going to make extensive use of Matlab. We've tried to write all the more complex software in advance so that we can focus on the image processing and not turn the lab into an exercise in computer programming. Note, however, that this software is not bulletproof and if its given funky data you'll get funky answers. Also the MOLA data is much more difficult to extract from its archived PDS form into useful numbers than is the MOC data you used in the first part but again, we’ll try to make this as painless as possible.

I. Photoclinometry

This section is aimed at being an introduction to the concept of photoclinometry, or if your into computer vision shape-from-shading (deriving topography from surface shading). If you've read the lab appendix by now, you should know how local slopes as well as albedo can affect the brightness of a particular patch of ground (if you haven't read it yet now would be a good time). Photoclinometry is difficult to do in any quantitative way but this exercise will illustrate some of the qualitative concepts associated with it.

In you haven’t already, you’ll need to add the path of the matlab routines for this lab by typing:


from the lab REPORT sub-directory in the Matlab window.

There is an matlab program called 'pclin.m' in the SUBROUTINES sub-directory. This is a basic photoclinometry program which will allow you to vary some input parameters and see their effects. Please look through 'pclin.m' and make sure you understand what it is doing.

This program uses the I/F values in the image m0806185.lev1.cub. Some of the program lines are reproduced below:

res = 2.95;        %Size of a pixel in meters
sunaz = 320.65;        % Solar Azimuth
inc_ang = 48.18;        % Inclination Angle

These lines set up the variables specific to this image. The solar azimuth is important, as only tracks that cut across the image parallel to the illumination direction can be used for photoclinometry.

Explain briefly why this is the case.

b = b-shadow;

b is the variable that stores the I/F values alone the sun's line of sight. Here we remove some estimate of the I/F value, which is due solely to the atmosphere (called shadow brightness because this is the only way shadows can be illuminated)

z = acos(b.*pi.*cos(inc_ang*(pi/180.0))./albedo);

z = z - (inc_ang*(pi/180.0));
z = res.*tan(z)
for i=2:length(z)
   z(i) = z(i-1)-z(i);

These few lines are the guts of the program. The first calculates the incidence angle for each pixel based on its I/F value. The second then removes the incidence angle that a flat surface would have, leaving just the local slopes for each pixel. The third line converts the slope of each pixel to the change in height of that pixel. The for loop adds up all these height changes to find the actual height of each pixel.

Notice, for example, that we have to assume some value for the albedo and that the atmosphere can have an important role, due to its ability to scatter light.

You can start the program by typing 'pclin('m0806185.lev1.cub')' at the matlab prompt. The standard case will come up i.e. the program selects an interesting part of the image, guesses an albedo and assumes no atmospheric effects. You can force it to use some particular albedo by calling it like 'pclin('m0806185.lev1.cub',0.25)' for an albedo of 25%. You can use 'pclin('m0806185.lev1.cub',.25, 3000)'to select a starting line for the section of image you want to look at (line 3000, in this case). You can also make some correction for the atmosphere by assuming some amount of I/F is due to scattering, e.g. 'pclin('m0806185.lev1.cub',.25, 3000, .02)' will assume that 0.02 needs to be subtracted from each I/F value as a first order atmospheric correction. You can choose each of these three variables, although they must be in the order: “albedo, starting line, shadow brightness”. (If you want to specify the starting line but not the albedo, for instance, a nonsensical value like -1 will cause it to choose the default albedo value. 'pclin('m0806185.lev1.cub',-1, -1, -1)' will cause the program to use the defaults for all three.) Note that the elevation here is in arbitrary units. It's easy to get relative elevations with photoclinometry, but this technique (or more specifically, our rudimentary implementation of it) isn't reliable enough to actually measure heights in meters. So in discussing these heights, don't assume some unit, it's just an arbitrary scale.

Experiment with different albedos, letting the program guess first and then trying higher and lower values. Try this for a number of areas and try to figure out what goes wrong when the albedo is far away from the real answer. Explain it as best you can in words. Do the same for the shadow illumination parameter.

Export your Matlab plots and insert them into your lab writeup. 

II. Laser Altimetry

The Mars Orbiter Laser Altimeter (MOLA) operated on the Mars Global Surveyor (MGS) spacecraft. It measured topography by pulsing a laser at the planet's surface and recording the length of time it took for that pulse to be reflected back. It was a nadir-pointing instrument and so can only see what's directly below it. The laser fired 10 shots a second while the spacecraft has a groundspeed of 3 km s-1, so each shot is separated from the next by about 300 meters. The laser illuminated a patch on the surface that's about 120 meters in size. As the spacecraft orbited the planet a track of elevation measurements was built up of the terrain that MGS had passed over. So, MOC images and topographic data were taken at the same time, which is quite useful for interpreting landforms. MOLA was shut off in June 2001, and now operates in a passive radiometry mode.

We'll look at one of the single tracks in particular that crosses over the image from part 1. Most MOC images have accompanying MOLA data through mission phase E07 or so. However, this data is only along the track of the spacecraft (the long axis of the image), and only along a small strip of the image. The whole volume of MOLA tracks has been gridded into one planet-wide map, but this map has slightly lower resolution in the low latitudes, and is not quite as reliable on small scales as the individual laser shots.

We have all the MOLA data on disks. The data structure of the MOLA files is long and complicated so to spare you the details and let you get straight to the data we have used a small program that will automatically go and get the MOLA track for any MOC image you ask for. This program returns 4 arrays, one of the longitude of each shot, one for the latitude, one for the topographic height and one for the time each shot occurred. All you need give it is the name of the MOC image you want data for. In the shell script you ran earlier, this was done by calling the program '' on line 5. We have written a program to get all this data we produced into Matlab. In MATLAB type:


Some plots will pop up, and some arrays will be spit out. In MATLAB you can find out information about arrays by typing 'whos ARRAY-NAME' if you leave off the array name and just type 'whos' you'll get information on all the variables MATLAB has stored in memory. Try things like 'y(1:10)' which will show you the first 10 elements in y (the projected y-coordinate, in meters, of the MOLA shots). Try 'max(x)' or 'min(time)' to see maximum and minimum values of some of the arrays. Note that the time is in awkward units of seconds after JD2000 (Julian date of 00:00 1/1/2000). Computers have no problem with numbers like this but humans generally do (at least I do).

The plot on the left hand side of the figure simply plots the MOC image we have been looking at, now projected, with the MOLA points on top. Note that the actual footprint of the laser beam is significantly larger than the points shown here, but I think this makes for easier viewing. But if a spot falls right on the edge of a cliff, the results may look a little funny. The plot on the right shows the elevation of the MOLA data vs. Latitude. You can now see the actual elevations of this image. Now plot the elevation on your own. For example, you can use the command:

“figure; plot(d,z);”

This will plot the topography recorded against the distance from the first point. Remember each point represents about 300 m along the ground, or 0.1 seconds. Notice in this dataset that we are dealing with absolute elevations, as opposed to unscaled and relative elevations in the photoclinometry section. This is very useful! So, what is the total relief along this track?  Because we now have absolute elevations, we can compare different parts of the image to each other. Are all of the high points in this image at the same elevation? What are the maximum slopes seen in this track, and are they consistent with loose sediment (as opposed to bedrock)? (The track isn't along the direction of maximum dip, so this will only be a lower limit on the actual maximum slopes. Too bad we don't have topographic data for the whole image...) Export your Matlab plots into your lab writeup when you're done.

III. Stereo Imagery

The third topographic technique we will employ is stereo photogrammetry (see lecture notes). It just so happens that the image we have been looking at has been imaged twice by the MOC team. After MOLA was shut off MGS was oriented, for the most part, at 17 degrees off-nadir to save fuel. Images in this later phase of operation can be combined with earlier mapping phase images to extract topographic information, as in a 3-D picture. By measuring the parallax between various features, and with precise knowledge of the camera position, good topographic data can be obtained, at near the resolution (typically ~3X) of the original MOC images. Advantages to this method are the higher resolution, and the ability to extract absolute elevations. However, the extent of MOC stereo coverage is rather limited, and it does not have quite the vertical precision of the Laser Altimeter data. We will take a look at this data, and you can see the advantages and disadvantages for yourself.

To save you time, we've made a Digital Elevation Model (DEM) beforehand: dm270_1626.grd In matlab, type 'stereoplot' This will bring up two images. The first one is our friend M0806185. Again, this is the projected version of the image. The second plot is of the stereo DEM, with the image behind it. This is really different than the other two analysis methods! We have 2-D coverage of the image...sort of. Notice that there are lots of areas where the automatic correlator couldn't find matches between the images. This is usually because the images are too featureless in these areas. But you can see that where there are slope streaks on the image, the tracker is able to find matches between the images, because of their high contrast. (On the other hand, if you look closely, there are places where new slope streaks have formed in the time between the two images, and automatic correlation fails!) Also, you can see there is some noise to the data, much more than the MOLA data. We're going to use a function called proftool3, so you can take profiles of this plot in any direction you want. It can be used in two ways. Close the second (color) plot window, or just make the black and white image the active plot. Type:


Use the mouse to select the profile in the image window (right click when you're done to exit). This function lets you click on the image for reference, but extract the corresponding topography (from the elevation matrix, z). Follow the directions that come up in the matlab workspace. A plot should pop up showing the elevation profile. Alternatively, you can type:


This usage lets you save the x, y, z, and distance values of the profile in the four output arguments, in case you want to plot them again later. You have two tasks, using this tool: 1) Determine whether the layers exposed along the edge of this cliff are roughly horizontal or not. 2) Determine the angle of the slope streaks which can be seen throughout the image Is this what you would expect for a fine dust layer on the surface? Again, export your plots to support your conclusions for these questions. Finally, type 'h=reshape(z,1,1751*501);' and “figure; hist(h,20);” to view a histogram of elevations for this DEM. What are the maximum and minimum elevations?

Phew! Congratulations, you're done.

III. Appendix: Reflectance from Planetary Surfaces

Reflected visible and near infrared light from planetary surfaces is arguably the most important remote sensing window available to us. Not only are most planetary images taken in the visible (where the sun provides a convenient abundant illumination source) but reflected light in the near-infrared provides important spectral information capable of distinguishing many minerals. This tutorial will cover a few basic things to make sure everybody is starting from the same level.

When dealing with reflection the first thing to consider is the spectrum of the source (the sun for planetary work). The solar luminosity is roughly 4x1026 Watts, emitted isotropically over 4pi ster-radians. The solar constant for each planet is the solar flux at that planets position (for Earth its around 1300 Watts). The solar flux dies off as an inverse square law, Jupiter at ~5 AU receives about 1/25th (~4 %) of the Earth's solar flux. The shape of the solar spectrum follows that of a 6000 K blackbody. It peaks in the visible region (not surprisingly since our eyes have evolved to take advantage of that) at about half a micron. To convert the Plank function to specific flux (flux per hertz) you have only to multiply it by the solid angle subtended by the sun. The solar constant is then just the integral of the specific flux over all frequencies

Most surface images of planetary bodies are taken with a broadband filter which covers most of the visible range. Several things affect the brightness received by each pixel in the CCD array or each element in a vidicon image (believe it or not for some bodies this is still the best we have). The flux falling on the surface is the primary factor and is the same for all pixels unless the image covers such a large fraction of the planet that the solar incidence angle varies considerably from one part of the image to another. The albedo of the surface making up that particular pixel is a measure of what fraction of the incident light is reflected, there are many types of albedo and we'll discuss some of them later. Albedo varies from pixel to pixel, e.g. sand is darker than dust (for reasons we'll also discuss later). Local slopes can also effect the incidence angle and so effect the brightness of that pixels, e.g. the sunlight side of a hill is brighter than the shadowed side. Before we go any further lets define our observational geometry to prevent any confusion.

The above figure is taken from Hapke, 'Theory of Reflectance and Emittance Spectroscopy' (Cambridge University Press, 1993). The incidence angle is denoted by i and is the angle the incident solar radiation makes with the local vertical. The emission angle is denoted by e and is the angle made by the emitted radiation toward the detector with the local vertical. Nadir pointing spacecraft observe only whats directly below them, so the emission angle is usually very small. The phase angle is denoted by g and is the angle between the incident and emitted rays. For nadir observations (where e is zero) the phase angle is equivalent to the incidence angle. When g is zero the sun is directly behind the observer this can lead to a surge in brightness known as the opposition effect, which we'll talk about later.

For a spherical planet the incidence angle on the sun is given by the following formula, where L is the latitude, H is the hour angle and D is the solar declination.

cos(i)=sin(L)·sin(D) + cos(L)·cos(D)·cos(H)

Taking into account the position of the sun, planet and spacecraft it is possible to derive an I/F value for each pixel. This is the fraction of light which hit the surface contained within the pixel that was reflected. It depends both on the albedo of the surface at that point and on the local slopes which may have effected the incidence angle. That's fine for bodies like the Moon, Mercury and the Galilean satellites but not for bodies like the Earth or Mars which have atmospheres. The atmosphere can scatter light out of the incoming solar radiation which reaches the surface providing diffuse illumination rather than collimated and it can also scatter radiation out of the outgoing beam of radiation. In short the presence of an atmosphere is bad news when trying to interpret I/F values. We'll restrict ourselves to how the surface effects the I/F values but keep in mind that any atmosphere is playing a major role.


Before describing the different kinds of albedo it is necessary to describe the concept of a Lambert Surface. A Lambert surface is one which appears equally bright from whatever angle you view it (any value of e). The Moon is a very good approximation of a Lambert surface, it appears equally bright at its edges and at its center making it appear almost like a two dimensional disk rather than a sphere. The flux from 1 m2 of a lambert surface is proportional to cos(e) due to the geometrical effect of foreshortening, however the same angular size includes more surface area at grazing angles and so these effects cancel out leaving the brightness independent of e. There are many kinds of albedo, all of which were defined for use with the Moon and then generalised to cover other bodies. Some of the more common ones you may come across are:

Normal Albedo: Defined as the ratio of the brightness of a surface element observed at g=0 to the brightness of a Lambert surface at the same position but illuminated and observed perpendicularly i.e.i=e=g=0.

Geometrical (Physical) Albedo: It is the weighted average of the normal albedo over the illuminated area of the body. Defined as the ratio of the brightness of a body at g=0 to to the brightness of a perfect Lambert disk (not sphere) of the same size and distance as the body illuminated and observed perpendicularly i.e. i=e=g=0.

Bond (Spherical) Albedo: Defined as the total fraction of incident irradiance scattered by a body in all directions. This quantity will be important when considering the total amount of energy absorbed by a surface for things like thermal balance etc...


We've already mentioned that local slope can serve to increase or decrease the apparent brightness of a patch of ground. If we assume an albedo for each pixel then we can figure out what the solar incidence angle is for each pixel based on the I/F value. We can subtract the incidence angle for a flat piece of ground at that time,latitude and season, we are left with the slope of each pixel but only in one direction! This procedure is known as photoclinometry, it works best when you can remove the albedo easily e.g. if the surface is covered with some uniform albedo material like frost or dust. This can only tell you what the slopes toward and away from the sun are, if you want to reconstruct the entire topographic surface then you need at least two observations illuminated from different directions. Again the atmosphere wreaks havoc with this sort of technique and make it difficult to get quantitative results however if you could constrain the answer with other methods such as a laser altimeter in the case of Mars then you can generate very high resolution topography maps for small areas.


Photometric and Phase Functions: Surfaces behave differently when viewed under different geometries. The phase function gives the brightness of the surface viewed under some arbitrary phase angle divided by the brightness expected if the surface were viewed at zero phase. The photometric function is the ratio of surface brightness at fixed e but varying i and g to its value at g=0. For a Lambert surface the photometric function is given by cos(e).

Grainsize Effects: Scattering from a particulate medium in the visible and near infrared tends to be dominated by multiply scattered light i.e. photons that have been scattered within the surface more than once. Photons pass through grains getting absorbed along the way, they get scattered by imperfections within the grains and by grain surfaces. The more surface area there is the more scattering there is and the bigger the grains (more volume) the more absorption there is. The surface area to volume ratio of the grains therefore has an effect on the amount of light scattered by the surface. The surface area to volume ratio scales linearly with the grain size so for the same material surfaces with larger grain sizes will in general be darker. The most familiar example of this is probably sand on the beach, dry sand is bright but when sand get wet it clumps into larger grains and turns darker. In reflection spectra larger grains produce broader, deeper absorption bands.

Opposition Effect: When observed at zero phase surfaces experience a sharp increase in brightness known as the opposition effect (also known as: opposition surge, heiligenschein, hot spot and bright shadow). The pictures below show the opposition surge in the case of the moon, look at the edges of the astronauts shadow (which is at zero phase angle), can you see the extra brightness compared to the surrounding regolith. The plot shows the same effect but in a more quantitative way.

The physical explanation offered for the opposition effect is that of shadow hiding. If the illumination source is directly behind you then you cannot see any of shadows cast by surface grains (since they're all hinding behind the grains themselves), whereas if you were looking toward the illumination source then you can see all the shadows cast by the surface making it appear darker. Coherent backscatter is another mechanism offered as an explanation and it is likely that both mechanisms play some role although from recent work on Clementine data it looks like shadow hiding is the dominant mechanism at least in the case of the Moon.

Reflection from particulate mediums is an area of research in its own right, which has been largely pioneered by Bruce Hapke in recent years. This is only meant as a taste of what is really out there. Anyone wishing to go deeper into the (gruelling) mathematical modeling of reflection can come to either Jamie or Alex for references and/or help.

Download 85.63 Kb.

Share with your friends:

The database is protected by copyright © 2020
send message

    Main page