Background
Visual information is a critical component of surface studies in planetary science. A key component of any imaging dataset is knowing the location of an image on the body. As an extreme example, taking an image of Earth’s north polar ice cap and not knowing it is at the north pole would make any interpretation more difficult. In the modern era, placing images correctly on a surface relative to each other, and other datasets, is important not only for Earth, where extremely precise and accurate tracking of spacecraft and ground surveying is possible, but also for other solar system bodies where such information is much less well known. Inaccuracies in cartography manifest as offsets between data in a single dataset (a feature will be placed at different locations from one image to another) to offsets between data in different datasets (e.g., spectrometer data will not align with visible light camera data). This can make interpretation very difficult.
Creating a control net solves this problem by requiring the same feature (a tie point) in multiple images (tie measure) to have the same 3D location. Software can solve for how the spacecraft and data-taking instrument must have been positioned in order to force those features to project to the same location on the body. During this process, the software can solve for the latitude, longitude, and elevation (distance from the planet’s center, also referred to as “radius”) of each control point. Once this has been done, the data are now tied together, and a product such as a controlled mosaic can be produced. If one places the additional constraint that a specific tie point must be at an a priori latitude, longitude, and radius from the center of the body, it becomes a control point instead of the more generic tie point.
The U.S. Geological Survey’s (USGS) ISIS3 software is used for non-terrestrial cartography. However, it has a steep learning curve, is inefficient, and has no inherent automation. For these reasons, very few researchers in the planetary science community know how to use it well, and most believe that creating a high-quality product requires a significant amount of manual effort. We have developed an automated approach to using that software which greatly decreases the manual effort required, without sacrificing quality, and operates on a modern computer in a relatively short period of time (hours to days as opposed to months or years). This automated approach was developed under previous internal research projects.
Our automated control net process can be divided into four primary stages: (1) Data acquisition and processing, (2) candidate control point selection, (3) candidate control measure matching or registration, and (4) solving the control network for updated spacecraft and camera data.
Steps 1 and 4 are relatively straightforward and we did not address them in this project. The original code was developed to use data from the Context Camera (CTX) aboard NASA’s Mars Reconnaissance Orbiter because it is an ideal dataset for this type of work yet has been untapped, opening a good funding opportunity. However, cartographic control is poor or non-existent for numerous other datasets in the solar system (e.g., MESSENGER around Mercury or Cassini around Saturn’s satellite system) and our code can be adapted in a straightforward manner to work with those datasets and lead to additional NASA awards.
Most of the effort in this internal research project was focused on improving steps 2 and 3. We had specific improvements we wanted to implement, and upon which our time was focused, in addition to other components that we could modify to improve performance.
Approach
In general, the approach to this work effort began with benchmarking each step in the automated control net process. This benchmarking was not only for CPU time, but also disk I/O and RAM usage. For our CPU tracking, we paid special attention to any component of the process that was single-threaded because any adaptation to multi-threading can reduce the time requirements almost linearly with number of logical cores added (e.g., 8 threads can reduce the run time by ≈8×, though overhead for splitting the problem among threads and monitoring them will reduce this would-be linear efficiency). If a task was optimized by multi-threading, it was re-monitored in case new RAM requirements were untenable (e.g., if a single thread required 5 GB of RAM, a 12-thread implementation would require 60 GB of RAM which might not be available).
Specifically, we proposed to work in three aspects of the code: Faster runtime, with four specific optimizations proposed; fewer non-CPU computer resources, with two specific optimizations proposed; and adapt the code for other planetary bodies or datasets by testing the code and adjusting free parameters.
Accomplishments
We were able to accomplish all proposed optimizations, though some were incomplete at no fault to our efforts. Specifically:
- CPU optimizations: Optimize how control points are tracked and matched to reduce the efforts to match. Implemented a new Python code from USGS that allows direct manipulation of control networks, which drastically reduced the time required to manipulate them through other tools. Adjusted the Linux environment to allow the code to operate more effectively, allowing for more efficient threading. Modified several free parameters in the code to optimize its execution for CTX. Simplified some aspects of the code that had become bloated and inefficient.
- Resource optimizations: Primarily accomplished through the Python code to directly access the control network, which allowed us to manipulate it within Python and write more efficient alternatives to some common ISIS3 functions.
- Adapt to other bodies: We adapted the code to operate on Mercury and Saturnian satellite data, modifying and optimizing free parameters and adjusting the workflow as needed to increase efficiency. Compared with the code from a year prior, all optimizations benchmarked on a small region of Mercury had increased the speed by a factor of ≈50×.
Overall, this was a successfully executed project that produced significant improvements, in some cases well beyond what we had proposed.