Making Controlled Mosaics of Cassini Images

1. Introduction

This document explains how to make a controlled mosaic with images from Cassini using the ISIS Geodesy Software for Geometric Control.

More information on the ISIS Geodesy Software, including a brief history, can be seen in the Introduction to Geodesy Software.

2. Prerequisites

Before you begin the controlled mosaicing process described in this document, you need to have a set of overlapping Level 1 ISIS CUB images. Most of the images are currently (2005-06-13) available only to mission participants. Some early images are available from the Planetary Data System. There is no tutorial on gathering and processing Cassini images through level 1, but some related documentation can be found by browsing the ISIS Program Documentation.

3. Collecting Tie Points

A tie point, or match point, is the measurement of the location of single feature across two overlapping images, with the purpose of tying two or more images together. Tie points are created first by image processors using qmatch to make their measurements in pixels on digital images. Before running the program randlsq, which is the geodetic solver at the center of the controlled mosaicing process, the pixel measurements on the digital images must be converted to millimeters on the camera's focal plane. This is a step that is used in making vector projections from an image to the target body; unfortunately it is not transparent to users at this time.

With the different types of tie point data, it helps to adopt some terminology. From here on out, "Match Point" will always refer to the pixel variety, "Millimeter Measurement" will refer to the millimeter variety, and "Tie Point" will be used as a generic term to describe either.

There are many thousands of tie points that have already been measured, and getting a good map sometimes involves simply adding to the tie points. All tie points used in map generation at USGS are available in millimeter measurement form. Some are also available in pixel match point form, which is preferable, because pixel match points can easily be remeasured. A web page containing USGS tie point data, along with other control network data, is under construction at the Solar System Control Networks web page. Currently (2005-06-10) there are only millimeter measurements for Viking on that page. Pixel measurements can be obtained by contacting Brent Archinal.

The next three subsections explain (a) how to make new measurements, (b) how to convert them to pixels, and (c) how to merge them with existing data.

3.1. Making Pixel Measurements

New measurements are made in qmatch, which reads and writes Matchpoint files. Matchpoint files have one record per line, with a Point ID, an FSC, a line and sample for the measurement, a flag, and a radius. A Point ID identifies a specific point on the planet or moon. For each point, there must be at least two records, which give the position of the same point on two or more different images. The FSC tells which image it is. QMatch finds the image in a list of files by examining the image's labels.

The QMatch GUI is started by typing "qmatch" in the command shell or in TAE. It will ask for two files, a matchpoint file and an image list. If the file being worked on is brand new, it should contain records with the unmeasured (U) flag. These can be generated manually through an editor, with the combination of a spreadsheet program and an editor, or using a script. It will contain "point sets" showing where two or more images overlap. The records will be sorted first by point ID, and inside groups with the same point ID, by picture ID. An example file is given below:

Matchpoint total = 6
Point ID                                FSC    LINE    SAMP CLASS         DIAMETER
A3687                              35729677  201.50 1134.50   T             0.0000
A3687                              35729720  608.00  318.00   M             0.0000
L1240                              52532686  709.64  750.69   T            10.5880
L1240                              53564310  379.26  474.23   M            10.6459
L1250                              52532686  709.64  750.69   U            10.5880
L1250                              53564310  379.26  474.23   U            10.6459

The second file is a list of images. It can be made using ls, e. g. "ls *.cub >file.lis". After making the measurements, save the file, and your matchpoint file is complete.

3.2. Converting Measurements to Pixels

Match point measurements from the qmatch program are in pixel units. For randlsq to create the model, they need to be converted to millimeters. There are conversion programs for each mission that use scaling factors specific to the mission's camera(s). The programs also correct for camera distortion. Some even take reseaux data into account, or look up the focal length for each image.

A script is provided that will automatically run the appropriate program(s). The script pix2mm.pl can be run as follows:

  > pix2mm.pl matfile=titan05.mat fromlist=file.lis randto=titan05.mm target=TITAN

This will place the converted measurements into mea.dat.

3.3. Merging Measurement Data

If you are using existing millimeter measurements, such as those available at the Solar System Control Networks web page, you can use mea_replace to merge new and existing measurements together. If global.mm contains the existing measurements and titan05.mm is the file created in the last step, you can combine them together with this command:

  > mea_replace.pl from=global.mm replace=titan05.mm to=combined.mm

4. Preparing a priori Data

The solution program (randlsq) reads in a priori information in a special format called the RAND Pole, Point, and Picture format. The output data is given in the same format as the a priori data, and can be used as a priori data for another solution.

As with tie points, there are instructions for generating new data and merging new and existing data together.

4.1. Generating new a priori data

The a priori information includes the following:

1. Pole data for the target (planet or moon)
2. Ground point data for each match point ID
3. Picture data for each picture

If you completed the previous steps, you should have an image list (ending in .lis) and a pixel measurement file (ending in .mat). These will be used to generate the point and image data. Another file, a target definition file, will be used to generate the pole data. Target definition files for most targets are available on ISIS systems in /targets. If one for the target you're working on is not available, the information needed to make one may be found in IAU Working Group or Cartographic Coordinate reports.

To create the a priori data file using this information, use genapdat.pl. Here is an example of how to run it from the command-line:

  > genapdat.pl MATFROM=titan05.mat FROMLIST=file.lis OUTFILE=titan05.ppp 
                   TARGDEF=/targets/titan.def.1

This will make estimated latitude/longitudes based on the match point coordinates and the camera pointing in the image labels, and will output the pole and picture data from the target definition file and image labels, respectively.

4.2. Merging Pole, Point, and Picture (PPP) Files Together

If you merged an old and new millimeter file together, you will need to run ppp_replace.pl on both a new data set and an old data set corresponding to the old millimeter measurement file.

  > ppp_replace.pl from=global.ppp replace=titan05.ppp to=combined.ppp

5. Building a Solution

Before running the solution, a PVL parameter file needs to be created. Some parameters are simple, but need to be set correctly for the solution to work. These include the name of the TARGET and the location of the TARGDEF file. Other parameters are more complicated. These are what points to solve for and what points to fix. Getting good parameters is sometimes a matter of trial and error.

Things that can be solved for include all of the information passed into randlsq (See Section 4.1). Usually when starting out, you will want to do a simple stitching together of the images. To do this, solve for Latitude, Longitude, Radius, Alpha_Angle, Delta_Angle, and Kappa_Angle. When something is being "solved for", the numbers are free to change between iterations. Anything not being solved for is fixed.

When solving for all of these variables, it is usually best that one or two individual points are held fixed so the solution doesn't diverge. This can be good if there are points that are known to be good, and it also may be a good first try. If the camera angles are off, however, it may make work better if no points are fixed, For example, we may fix the Latitude the Longitude for point "A0005". To do this, we write the SOLVE_FOR in the PVL file as follows:

SOLVE_FOR = { LATITUDE, LONGITUDE, ALPHA_ANGLE, DELTA_ANGLE, KAPPA_ANGLE }

FIX_LATITUDE  = { A005 }
FIX_LONGITUDE = { A005 }

FIX_ALPHA_ANGLE = { }
FIX_DELTA_ANGLE = { }
FIX_KAPPA_ANGLE = { }

This translates to "Allow Latitude, Longitude, Alpha Angle, Delta Angle, and Kappa Angle to move freely during the photogrammetric adjustment, but keep the Latitude and Longitude for point A005 point held firm (but not fixed)". To hold Alpha Angle, Delta Angle, and Kappa Angle firm for an image whose FSC is 2344421, the following could be used:

SOLVE_FOR = { LATITUDE, LONGITUDE, ALPHA_ANGLE, DELTA_ANGLE, KAPPA_ANGLE }

FIX_LATITUDE  = { }
FIX_LONGITUDE = { }

FIX_ALPHA_ANGLE = { 2344421 }
FIX_DELTA_ANGLE = { 2344421 }
FIX_KAPPA_ANGLE = { 2344421 }

For the solution parameters, the values in the sample file are good most of the time. For large solutions (over 20,000 measurements), however, conjugate gradients should be used, as the standard method (matrix inversion) will use more space than is available on most computers today (2005).

Once the parameters are set up to your liking, randlsq can be run using runrandlsq.pl. Here is an example command line:

> runrandlsq.pl inpfile=titan.ppp mmfile=titan.mm gptfile=titan.gpt outfile=titan-new.ppp 
     pvlfile=titan.pvl

The program will output three files, soln.dat (the output data), soln.che (the raw residual information), and soln.rms (the sorted residuals). The file soln.dat has the data that can be brought into ISIS and used to generate a controlled mosaic. The file soln.rms is a list of residuals, with the worst errors appearing at the top.

If errors are high (above 10 pixels), it probably means that there is a bad measurement between the pictures. Fixing the problem involves looking it up and fixing it in qmatch, and repeating steps 3-5.

The final step is to create a controlled mosaic with the new information. The basic outline of this process is as follows:

1. Run the ISIS program rand2ck1 to generate new kernels containing the camera angles from randlsq
2. Copy the kernel list file pointed to in the image label (KERNLST) and edit it to include the new kernels.
3. Run the geom and mosaic programs. This is covered in the tutorial for creating uncontrolled mosaics on the ISIS website.
4. View the mosaic in qview!

This concludes the tutorial. Please contact Brent Archinal for help, or if you have any corrections or suggestions.

7. Additional Information

1. ISIS Website - Online documentation and download information for our ISIS image processing package.
2. Solar System Control Networks - Control network data that has been used in creating mosaics. Provides an excellent basis for future solutions. Also contains detailed descriptions of the file formats used in RUPG programs.
3. Astrogeology Website - Contains general information on planets, missions, and our astrogeology program.