Lab - Imaging & Altimetry

Ge151: Spring 2011

This lab requires that you use certain programs on the gps computers. You may use the computers in the lab in the basement of S. Mudd, or your own computer if you are on the GPS network. Login with 'ge151' and use the password given out in class.

Alternatively, you can remotely log into the ge151 account from your own computer if you have one with the appropriate programs. From the UNIX prompt use:

ssh -X ge151@machinename.gps.caltech.edu

Ask your TA for a list of Linux machines that you can use, if they haven't already given them to you.

Source the .cshrc file once logged in with:

source ~/.cshrc

Imaging Techniques & Analysis

During this section of the lab you will work through:

• How to find, retrieve and process raw imaging data.

We're going to start with a pre-selected image to demonstrate some software packages and how they're used. The image which we'll be working with is stored in the /home/ge151/lab3 directory, the filename 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 ongoing Mars Global Surveyor (MGS) mission.

Introduction and Background

This 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 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.

Log on to the ge151 account with the password given out in class. First, you need to create a folder to keep all of our source files and the output files you'll be creating. (This is where I'll look to grade your assignments). Move into the lab3 directory and use the 'mkdir command to create your own subdirectory (mkdir directoryname). Copy each of the following files in /home/ge151/lab3 to your directory: m0806185.imq, m0806186.jpg and prepare_mocmola.sh (cp filename directoryname). Now change to your directory by typing 'cd directoryname

Now we're ready to look at some images. From your subdirectory, take a look at the image file either in a text editor or by typing 'less m0806185.imq' at the 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 85^th image taken on the 61^st 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 crosstrack 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 crosstrack resolution can vary from place to place on the planet (by almost 10%). The downtrack 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 downtrack 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, crosstrack 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.

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 an image onto a sphere. 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. Log on to the ge151 account and make sure you are in the correct directory.

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. There is a script called moclev0 that will run all the necessary ISIS programs to do this conversion.

Type

'csh prepare_mocmola.sh m0806185'

This is a unix script that will run several programs to prepare data that will be used later on. Various programs should whirl seamlessly into action. Text messages will scroll past, as these programs run, letting you know what's going on. These programs will create several new files in your directory.

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 format. Run the program 'qview' (just type the program name at the unix prompt and press enter). Qview is a cube-viewing program; after it loads use it to open the new cube file, which you just made (File -> Open Display), just click the 'ok' button for the load options.

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.

You can use the magnifying glass to zoom in (left button), zoom to image resolution (middle button) and zoom out (right button). Take a moment to look over the image zooming up on the interesting stuff. The world button on the upper right will bring you back to the state you started in if you need it.

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 tutorial 1 for the explanation of what I/F means). Open up the file m0806185.lev1.cub in qview 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 efficiencies. 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. Press the button on the top right marked with the 'paw' symbol. This turns on the information display at the bottom left, pan the mouse cursor around the image and watch the numbers in the bottom left.

This is still not the ideal situation 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 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*R_Mars, x=(lon/360)*2pi*R_Mars*cos(lat). There are many other projections that all have their own advantages and disadvantages, but they are beyond the scope of this lab.

In the /ge151/lab3 directory, I have placed the MOC Wide-Angle image which corresponds to the one 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 by typing 'xv M0806186.jpg'. Describe the various forms and processes you see in the Narrow Angle image, using both it and the context image. Try and figure out what you're looking at.

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.

http://ida.wr.usgs.gov

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.

http://www.msss.com

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.

http://www-pdsimage.jpl.nasa.gov/PDS/public/Atlas/Atlas.html

This site has recently been finished and 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.

Altimetry and Topographic Analysis

During this section of the lab you will work through:

• Obtaining topographic data from photoclinometry of the image processed in part one
• Looking at single-track data from the MOLA instrument.
• Using stereo topographic data from MOC
• Deducing some simple things about geomorphic features on Mars.

Introduction and Background

This lab is going to make extensive use of MATLAB (interactive data language). You may have used it briefly in lab 2 for the thermal inertia programs. I've tried to write all the software in advance so that this doesn't turn into a class on 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 I'll try to make this as painless as possible.

For the second part of this lab you'll probably need to use a computer thats better than average, otherwise programs may be kind of slow. Any of the linux machines should be able to handle it, although ssh-ing from a laptop may be slow.

I. Photoclinometry

This section is aimed at being an introduction to the concept of photoclinometry (deriving topography from surface shading).If you've read tutorial one 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 your directory start matlab by typing

'matlab'

You need to add the path of the matlab routines for this lab by typing:

addpath /home/ge151/matlab

This program uses the I/F values in the image m0806185.lev1.cub (stored in the lab3 directory). 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.

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);
end

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.

This isn't a programming class so you don't need to learn this, only notice what important. 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 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.

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.

Startup MATLAB in your directory by typing 'matlab' at the UNIX prompt. We have all the MOLA data on disks in the gps computer system. 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 'mocmola.pl' on line 5. I have written a program to get all this data we produced into MATLAB. In MATLAB type:

[time,y,x,z,d]=mocmolaplot('m0806185');

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; you can use the command:

plot(d,z)

This will plot the topography recorded against the distance from the first point. (You can open a new figure for plotting data with the convenient command 'figure'.) Remember each point represents about 300m 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? This is comparable to some of the mountains within view of Caltech, from base to peak. 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 as .jpg's to your directory when you're done, using File -> Export on the plot window.

III. Stereo Imagery

The third topographic technique we will employ is stereo imagery. It just so happens that the image we have been looking at has been imaged twice by the MOC team. Since MOLA was shut off, as mentioned above, MGS has been 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 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.

Okay, now we're going to exit MATLAB and go back to the unix prompt. Type 'exit'. In your directory, type 'mkdir stereo' and then 'cd stereo'. This is where we'll be doing all the stereo stuff.

To save you time, I've made a Digital Elevation Model (DEM) beforehand. Copy the DEM to your stereo directory by typing 'cp ~ge151/lab3/dm270_1626.grd .' Now, go back into matlab, and 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:

proftool3(z)

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:

[xx,yy,zz,dd]=proftool3(z);

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 hist(h,20) to view a histogram of elevations for this DEM. What are the maximum and minimum elevations?

Phew! Congratulations, you're done.

Please let me know if you find errors or problems with the text of the lab, or with the programs.

That's it, good luck.

-Kevin

PS. Getting Help

You can come and see me whenever you like at 158 South Mudd. If you email in advance we can fix a time or you could just try and catch me there.

matlab help is available by typing 'help [function name]' at the matlab prompt.

ISIS can provide help for any routine or any parameter when in tutor mode (type 't [function name]'). In addition, the USGS web-site at http://wwwflag.wr.usgs.gov/isis-bin/isis.cgi, documents all ISIS programs very well.

Finally, Rich Chomko has built a very impressive guide to almost everything at the Caltech GPS Mars Archive. This webpage has everything from linux/IDL/ISIS help, to a vast glossary of planetary science terms. You should check it out, even if you don't need help!

GPS homepage - Home - General Info - Schedule - Assignments - Labs - Field Trip - Reading - Projects - References - Feedback

Back to top

These pages are currently maintained by Oded Aharonson