Current Status of the Community Sensor Model Standard for the Generation of Planetary Digital Terrain Models

Abstract

The creation of accurate elevation models (topography) from stereo images are critical for a large variety of geospatial activities, including the production of digital orthomosaics, change detection, landing site analysis, geologic mapping, rover traverse planning, and spectral analysis. The United Stated Geological Survey, Astrogeology Science Center, continues to transition the supported planetary sensor models to the Community Sensor Model (CSM) standard. This paper describes the current state of use for this photogrammetric standard, supported sensor model types, and qualitatively compares derived topography between SOCET SET and SOCET GXP (^®BAE Systems) using HiRISE stereo images of Mars. Our transition to the CSM standard will ensure an uninterrupted capability to make these valuable products for Mars and many other extraterrestrial planets and moons.

1. Introduction

In this paper, we describe the USGS Astrogeology Science Center’s (ASC) multi-year adoption of the Community Sensor Model [1] standard to support a transition from BAE Systems’ stereo photogrammetric application SOCET SET^® to its successor, SOCET GXP^®. SOCET SET has allowed the ASC and other institutions to generate foundational digital terrain models (DTMs) used for general planetary research (e.g., [2,3,4,5]) and for critical data sets to evaluate safe landing sites for several Mars rover missions (e.g., [6,7,8]).

1.1. Overview of Photogrammetric Efforts at the Astrogeology Science Center

As described in Laura and Beyer [9], there are three classes of geospatial foundational planetary data products which include geodetic coordinate reference frames, topography, and orthoimages. The creation of these data requires software and an instrument’s sensor model. A sensor model defines the mathematical transformation between an image (line, sample) and the target body or ground coordinates (longitude, latitude, elevation). The ASC supports dozens of instrument sensor models across NASA’s planetary missions, including instruments onboard the orbital-based missions Mars Global Survey (MGS), the Mars Reconnaissance Orbiter (MRO) and the Lunar Reconnaissance Orbiter (LRO) among others (

Table 1. USGS ASC currently supported instruments with the usgscsm and ALE libraries. Supported instruments are usable in any CSM-supported application or SET. Example Jupiter Notebooks for most instruments are available here: https://github.com/DOI-USGS/knoten, accessed on 6 February 2024.

Mission	Instrument Name	Sensor Type	Reference
Cassini Orbiter	ISS-NAC (Narrow Angle Camera)	Framing Camera	[13]
Cassini Orbiter	ISS-WAC (Wide Angle Camera)	Framing Camera	[13]
Chandrayaan 1	Miniature Radio-Frequency instrument (Mini-RF)	SAR	[14]
Clementine	Ultraviolet/Visible Camera (UVVIS)	Framing Camera	[15]
Dawn	Framing Camera (FC) Instrument	Framing Camera	[16]
ExoMars Trace Gas Orbiter	Colour and Stereo Surface Imaging System (CaSSIS)	Push Frame Sensor	[17]
Galileo	Solid State Imaging System (SSI)	Framing Camera	[18]
Hayabusa	Telescopic Camera (AMICA)	Framing Camera	[19]
Hayabusa	Near Infrared Spectrometer (NIRS)	Framing Camera	[19]
Juno	JunoCam	Line Scan Sensor	[20]
Lunar Reconnaissance Orbiter	LROC-NAC (Narrow Angle Camera)	Line Scan Sensors	[21]
Mariner 10	VIDICON_A/B	Framing Camera	[22]
Mars Express	High Resolution Stereo Camera (HRSC)	Line Scan Sensors	[23]
Mars Global Surveyor	MOC-NAC (Narrow Angle Camera)	Line Scan Sensors	[24]
Mars Global Surveyor	MOC-WAC (Wide Angle Camera)	Line Scan Sensor	[24]
Mars Odyssey	Thermal Emission Imaging System (THEMIS-IR)	Line Scan Sensors	[25]
Mars Odyssey	Thermal Emission Imaging System (THEMIS-VIS)	Push Frame Sensor	[25]
Mars Reconnaissance Orbiter	Context Camera (CTX)	Line Scan Sensor	[26]
Mars Reconnaissance Orbiter	High Resolution Imaging Science Experiment (HiRISE)	Line Scan Sensor	[27]
Mars Science Laboratory	Mast Camera (left, right)	CAHVOR/Framing	[28]
Messenger	MDIS-NAC (Narrow Angle Camera)	Framing Camera	[29]
Messenger	MDIS-WAC (Wide Angle Camera)	Framing Camera	[29]
Near Earth Asteroid Rendezvous	Multispectral Imager (MI)	Framing Camera	[30]
New Horizons	Long Range Reconnaissance Imager (LORRI)	Framing Camera	[31]
New Horizons	Multispectral Visible Imaging Camera (MVIC)	Framing Camera	[31]
New Horizons	Linear Etalon Imaging Spectral Array (LEISA)	Line Scan Sensor	[31]
Osiris-Rex	PolyCam, MapCam, SamCam (OCAMS)	Framing Camera	[32]
Kaguya (SELENE)	Kaguya Terrain Camera (TC)	Line Scan Sensors	[33]
Kaguya (SELENE)	Multiband Imager (Mi)	Line Scan Sensor	[33]
Viking Orbiter 1/2	Visual Imaging Subsystem Camera A/B	Framing Camera	[34]
Voyager 1/2	ISS-NAC (Narrow Angle Camera)	Framing Camera	[35]
Voyager 1/2	ISS-WAC (Wide Angle Camera)	Framing Camera	[35]

). These sensor models were originally developed for use within the ASC’s Planetary Image Cartographic System (PICS) and then its successor called the Integrated Software for Imagers and Spectrometers (ISIS v3+, https://doi.org/10.5281/zenodo.7644616, accessed on 6 February 2024). Within ISIS, the use of these sensor models has enabled the orthorectification of single images, photogrammetrically bundle adjusted multi-image mosaics, and globally controlled image networks used to define the shape of a target body and to make regional or global controlled orthomosaics. Since the mid-1990s, in collaboration with BAE Systems, the ASC has also adapted several of these sensor models for use within BAE’s SOCET SET stereo photogrammetry software suite [10,11]. NASA Ames Stereo Pipeline (ASP; [12]) also adopted these ISIS-based sensor models and now more recently, also adopted the CSM-based sensor models.

1.2. Brief History with SOCET SET

The BAE’s SOCET SET has been used by the ASC and others in the planetary community for more than two decades [2,36]). While other photogrammetric applications exist, SOCET SET (and now SOCET GXP) provide the ability for the end-user to validate and manually edit DTMs using a heads-up stereo-based display. Over a thousand elevation models and paired orthoimages have been released by the planetary community using SOCET SET from stereo images of Mars, the Moon, Venus, Europa, Titan, asteroids, and terrestrial analogs of Earth [37,38,39]. Beyond its use by the ASC, there have been several other groups across the planetary community who have also relied on SOCET SET for the creation of elevation data and ortho-images from stereo images. The most prolific teams include the University of Arizona’s HiRISE Team (and their collaborators), having released products for more than a thousand individual sites [5,27] (https://www.uahirise.org/dtm/, accessed on 6 February 2024) and the Arizona State University’s LROC Team (and their collaborators) releasing data for more than 600 sites [3,21] (https://wms.lroc.asu.edu/lroc/rdr_product_select, accessed on 6 February 2024). All these SOCET SET-produced products are openly archived and made freely available by NASA’s Planetary Data System (PDS; HiRISE DOI: 10.17189/1520227 and LROC DOI: 10.17189/1520341).

1.3. SOCET GXP and the CSM Standard

SOCET GXP (by BAE Systems) is the successor to their SOCET SET [10]. While there are many updates to SOCET GXP, described more in Section 3, the most impactful update for the ASC was the transition to the CSM standard to support external third-party sensor models. The CSM is a standardized Application Programming Interface (API) developed by the U.S. Air Force and the National Geospatial-Intelligence Agency (NGA) and now supported by the CSM Working Group [1,40]. The CSM API functions as a C++ plug-in library that is dynamically loaded at run time when a compliant Sensor Exploitation Tool (SET), such as SOCET GXP, is started. While the SOCET GXP is indeed built for the Microsoft Windows operating system, a CSM-based library can be built for most all operating systems.

1.4. Goals

The goal of this paper is to describe the effort and software the ASC has implemented to transition to SOCET GXP using the CSM API for DTM production. Section 2 describes the steps and software needed to begin this transition. Section 3 provides a qualitative review comparing SOCET SET and SOCET GXP. Lastly, Section 4 describes how one can use and take advantage of the usgscsm library for SOCET GXP and other CSM-compatible tools.

2. Steps Required to Support the CSM and SOCET GXP

Initially, the CSM standard and SOCET GXP were not completely planetary body agnostic, making it difficult for the ASC, which focuses on non-terrestrial bodies, to transition away from SOCET SET. However, with the needed updates made in 2018 to the CSM API, the ASC released the CSM-based usgscsm library specifically to support planetary sensor models within SOCET GXP, but also for ASP, ISIS, and a stand-alone Python environment. In short, the usgscsm software library provides CSM-compliant sensor models created and/or maintained by the ASC [40]. The usgscsm library currently contains four different types of sensor models including a framing, push-broom, push-frame, and a synthetic-aperture radar (SAR) sensor model. The remainder of this section describes the software modifications and development that were needed to make the transition to SOCET GXP for planetary mapping possible.

2.1. Community Sensor Model API Updates

During our initial assessment for the CSM API (version 3.0.2), the ASC noted an unfortunate lock-in to the Earth-based World Geodetic System (WGS84) reference ellipsoid. This meant that there was no valid method to redefine the size of the target body’s semi-major and semi-minor radii without breaking the existing API. In 2016, during a CSM Working Group meeting, the ASC presented our planetary use case for the CSM standard. Over the next year, several members of the working group implemented simple set and get ellipsoid functions to allow the API to support variable radii. If these two functions are not used, the size of the body still defaults to the WGS84 reference ellipsoid, which allows the API to maintain backwards compatibility. In 2018, the CSM API version 3.0.3, with the new settable radii functions, was released by the CSM Working Group and soon after implemented by BAE within SOCET GXP. This capability was also immediately updated within ASC’s usgscsm library. Note that, while some planetary bodies are defined as a triaxial (3 defined radii), the CSM API allows at most an elliptical definition (semi-major and semi-minor radii). Fortunately, for bodies defined as a triaxial body, it is typical to use the best-fit mean radius as a reference sphere. A list of planetary body parameters, including any defined best-fit mean radius, are recommended and maintained by the International Astronomical Union Working Group on Cartographic Coordinates and Rotational Elements [41].

2.2. CSM for Planetary Sensors

Currently, ASC’s usgscsm library contains four types of sensor model implementations which in turn have supported dozens of flown instruments (Table 1). These types include a (1) generic framing sensor model, (2) a generic push-broom (line scan) sensor model, (3) a generic push-frame sensor model, (4) and a recently added synthetic-aperture radar (SAR) sensor model. For a full discussion on the generic framing and push-broom sensor models, see Laura et al. (2020). The ASC, in collaboration with NASA Ames Research Center, has also started testing stereo capabilities for non-orbital sensors found on rovers and landers using an adaptation of the frame sensor model. This is essentially an implementation of a CAVHOR sensor model [42]. CAVHOR has been widely used in NASA’s Mars rover missions and is described in Xu et al. [43].

It is important to emphasize the constrained role that the usgscsm library plays within a larger software ecosystem. Alone, it cannot process data; its capabilities only become available when it is paired with a SET. SETs wrap the CSM API and the defined sensor model to provide fundamental photogrammetry capabilities. Examples of planetary-capable SETs are ISIS, NASA Ames Stereo Pipeline (ASP; [12]), SOCET SET and SOCET GXP. The revolutionary aspect for implementing the CSM API is that it allows disparate SETs the ability to share the same sensor model implementation. If a new sensor is added or updates are provided, all applications which support the CSM API benefit. Moreover, this API can allow these diverse SETs to interoperate. For example, a collection of SOCET GXP bundle-adjusted images can now be shared with ISIS or ASP. This capability is built into the CSM API using a method to export what is called “camera state” and allows one to easily share optimized camera model parameters, including any updates to pointing, from one SET to another. In the past, we have used complicated and often indirect methods to achieve this by sharing tie and ground-control points. While the ASC currently targets the listed 3 SETs (ISIS, ASP, and SOCET GXP), we are eager to see other CSM-capable open source and commercially available SETs to include support for the usgscsm library.

Mini-RF Radar

Although the ASC uses a “generic” tag for its SAR sensor model implementation, most SAR sensor model implementations will be very tied to the specific instrument and how the data and metadata are formatted. The ASC chose the Mini-RF instrument as an initial SAR sensor model to implement within the usgscsm library because it was previously implemented for topographic production and those data were released in a usable and comparatively simple form [44]. Versions of the Mini-RF instrument were flown on both the Indian Space Research Organization’s (ISRO’s) Chandrayaan-1 spacecraft [45] and on NASA’s Lunar Reconnaissance Orbiter (LRO; [14]). Both missions utilized the radar capabilities to help globally map the Moon, but the images were specifically useful for mapping the persistently shadowed regions at the lunar poles. Using radar data for topographic generation is usually called stereo-radargrammetry and is analogous to typical stereo-photogrammetry but taking account of the principles by which radar images are formed, as described in Kirk et al. [44].

The ASC has also used stereo-radargrammetric methods for other SAR instruments to help map Venus using data from NASA’s Magellan beginning in the 1990s, as well as Saturn’s moon Titan using data from the Cassini-Huygens mission to Saturn beginning in 2005. While there are eventual plans to implement them, neither the Magellan nor Cassini SAR instruments have been implemented in the usgscsm library, as these data and metadata as released are more complicated. For more detailed information about these sensor model implementations see Kirk and Howington-Kraus [39].

2.3. The ALE and Knoten Libraries

To support the CSM-based usgscsm library, two additional libraries were also created by the ASC. The first library is called the Abstraction Layer for Ephemerides (ALE), and the second library is a test suite called knoten, which ties together the ALE and the usgscsm library. While the usgscsm library is meant to be a generic implementation for specific sensor types (e.g., framing, push broom), the ALE library was created to instantiate the unique parameters for individual instruments. The ALE merges two CSM-required information streams into a single detached file called the Image Support Data (ISD, [40]). The first stream defines the instrument metadata (interior orientation parameters or intrinsics) and the second consists of the spacecraft position and pointing data (exterior orientation or extrinsics). Detaching this information from the image is beneficial because it allows alternative formats (beyond the ISIS-cube format) to be used. Note that for Earth, it is common to see the ISD and image combined into the National Imagery Transmission Format (NITF). While the NITF was researched for the usgscsm library and planetary data, it was quickly discovered that most applications which supported the NTIF format assume an Earth-based WGS84 reference ellipsoid. Depending on the instrument, the ALE can independently query the image’s spacecraft, pointing to information from available mission data (kernels), or it can also load the same information directly from an ISIS cube, if the cube has been initialized using the ISIS spiceinit application. These independent query capabilities allow new instruments to be more easily supported within the ALE (and thus, the usgscsm library) as developed outside of the ASC.

The knoten library is Python-based and provided as a sensor model testing environment. Given the image, the ALE-generated ISD, and the usgscsm library, knoten can run various tests looping over the core CSM functions “image to ground” and “ground to image”. Knoten also has ties into the original ISIS sensor model implementations and can compare the ISIS calculations against the new CSM-based calculations. This has been critical to test new CSM implementations in contrast to well-established and trusted ISIS-based sensor model implementations.

2.4. TIN Editing Enhancement

The ability not only to visualize stereo images in 3D, but also to manually edit collected DTMs is an immense benefit of both the SOCET SET and SOCET GXP. This allows operators to validate the alignment of DTMs and stereo images and manually update the tie and control points of a network and posts of a DTM or the vertices of a Triangulated Irregular Network (TIN). These capabilities have been critical to support detailed elevation models for researching and validating terrain models for the Mars landing sites. Low-contrast areas (e.g., dark dune fields or ice) or shadowed areas often do not correlate well during the topographic collection and require manual intervention to remediate the blunders or flaws in the initial DTM. Editing methods allow for single-point editing, break-line edits for changes in slope, or manually digitized area-edits to filter over poorly correlated surfaces. It is worth noting that any area manually updated by an operator will be tagged within GXP’s Figure of Merit (FOM) file. A FOM file stores a value for every pixel (or TIN vertex) which defines the original calculated correlation strength or whether it was manually updated by a human operator.

While the SOCET GXP contains very similar editing capabilities to SOCET SET, including many new tools, it missed an important method which was critical to the ASC personnel. This method allowed editors to modify small regions of post-based DTMs using the more powerful set of tools provided for editing TINs. In particular, TIN-based tools allow the user to quickly modify large regions, a capability that is useful for shadowed regions or low-contrast features like dark dunes, which are generally poorly matched. TIN editing was a vital part of the ASC workflow, and its absence hindered our ability to transition to GXP. In 2021, the ASC contracted BAE to support the creation of the tool called “Grid as TIN” within GXP (Figure 1). The addition of this tool restores the capability to convert portions of a post- or pixel-based DTM to a TIN, edit it using TIN-based tools, and then convert it back to posts. The tool has been made available in SOCET GXP (version 4.4) since 2022 for all users.

2.5. Ready for the Transition to SOCET GXP

BAE started the transition from their SOCET SET application to SOCET GXP in 2008 [10]. The final release of the SOCET SET (v 5.6) was in 2011. While still available even in 2024, SOCET SET no longer receives updates. Reliance on software that has been unsupported for more than a decade is clearly unacceptable. Fortunately, with the efforts described in Section 2.1, Section 2.2, Section 2.3 and Section 2.4 completed, the needed transition could begin.

SOCET SET and the updated SOCET GXP as stereo photogrammetric applications have very similar capabilities including support for rigorous sensor models, terrain extraction and editing, multi-sensor triangulation, orthorectification, and visualization of stereo images using stereo monitors (Figure 2). These attributes are what the planetary community largely relies on for its derived data creation needs. GXP also adds new functions like LiDAR visualization and exploration, video exploitation, and feature extraction that we have yet to utilize.

3. Comparison of HiRISE-Derived Stereo Results for SOCET GXP and SOCET SET

SOCET GXP is not a simple reimplementation of its predecessor SOCET SET. The SOCET GXP includes many advancements, including support for a CSM plug-in environment, updated matching algorithms, and advanced support for hardware acceleration using modern graphics processing units (GPUs), to name a few. But because the transition is a complete overhaul for our sensor model implementation and processing environment, we have performed tests to verify that SOCET GXP can not only replace our current SOCET SET workflow but also accurately replicate the results when used in an equivalent way. For SOCET SET, we used our typical “USGS-based” workflow [46], which uses Next Generation Automatic Terrain Extraction (NGATE) and then a single pass of the area-based Adaptive Automatic Terrain Extraction (AATE, [47]) algorithm. The NGATE algorithm combines area- and feature-based correlators and can match features over all combinations of overlapping imagery. Within a single stereopair, NGATE will match both left image to right image and vice versa, calculating all match types at every image pixel [2,48]. The addition of a final AATE step was added to reduce the appearance of blocky artifacts. However, as described in Kirk et al. [46], the AATE pass is fundamentally equivalent to a lowpass filter (5 × 5 mean kernel). Thus, for this comparison, within SOCET GXP we still ran NGATE, but for the smoothing step we replaced the AATE single pass with the same lowpass filter. Lastly, we purposely did not exercise the newer Automatic Spatial Modeler matcher (ASM; [47]) which is only available in SOCET GXP.

Fortunately, within SOCET GXP, while the interface has been renovated, the overall processing workflow is very similar to SOCET SET including initial data ingestion, image registration, tie point editing, triangulation, and eventual DTM extraction. For SOCET SET, this process is well described by Kirk et al. [2] and Sutton et al. [5]. To stage the comparison, we loaded the same stereo-images and defined the same adjustable line-scanner parameters during image triangulation including cross-track, in-track, radial positional and velocity biases and mounting angle bias. Because the line-scanner sensor model implementations are distinct, we cannot use the same metadata file (or ISD). During the NGATE extraction, both applications used the same custom “strategy” file called ngate_HIRISE.strategy, which is largely based on the built-in ngate_urban.strategy file but is optimized for HiRISE images. Strategy files allow for dozens of adjustable parameters (e.g., window sizes or slope constraints) which can be updated by the user [48]. In practice, this file only defines the initial parameter values, and the application will adapt the parameters based on the input images. Finally, DTMs were collected at the same grid spacing of 1 m in both systems and using similar smoothing methods as described above. No manual or operator editing was attempted on either DTM.

The main difference in the HiRISE workflows is that before DTM creation within SOCET SET, the user must export intermediate epipolar rectified images. The impact of this step is a forced single rectified transformation across the entire left/right image pair (and an extra resampling). We have never fully understood the need to do this in SOCET SET, but it has been required for HiRISE images prior to DTM extraction. Fortunately, in SOCET GXP, this intermediate step is no longer required and during DTM extraction rectification coefficients are automatically updated when they change significantly across the image.

In this paper, we only present a qualitative comparison of DTMs produced in the two systems, focusing on properties such as apparent sharpness, noise level, and artifacts. Overall, the DTMs were found to be very similar, which is not surprising since the same matching method and stereo-model parametrization were used in both applications. Interpreting the small quantitative differences between DTMs would be difficult, because we lack a reference dataset of superior precision and accuracy against which to evaluate the models. A possible objective for future research would be to make DTMs in the two systems from images of lower resolution and evaluate each against a DTM made from full-resolution HiRISE images. Such an approach, described in Kirk et al. [47], can be used to quantify both the horizontal resolution and vertical error of each product. The low-resolution stereopair to be evaluated could come from a different camera such as the MRO Context Camera (CTX; [24]) or could be simulated by down-sampling HiRISE images [47].

3.1. Comparison HiRISE Pair 1

Figure 3 shows the first DTM stereo-image extraction comparing SOCET SET and SOCET GXP. The HiRISE stereo images, located in the floor of Jezero crater, Mars (77.69°E, 18.41°N), were ESP_037330_1990 and ESP_037818_1990 (red channels). The colorized hillshade and zoomed-in grayscale hillshades are derived from a 1 m/pixel SOCET SET-generated DTM (left) and a SOCET GXP-generated DTM (right). These images were selected to show a relatively flat area.

Panel A shows the SOCET SET colorized hillshade and panel F shows the SOCET GXP colorized hillshade (the scalebar for A and F is at the top right of the figure). At this scale, both A and F colorized hillshades appear to be identical, highlighting the consistency between the applications. Panels B–E and G–H cover the two zoom-in locations shown by the red outlined boxes. These two zoomed-in regions were selected to contrast the matching results in a very flat dune field and a steep mesa-like feature. All six zoom-in panels are shown at the same scale (the scalebar for all six panels is at the bottom right of figure). Panels B and G show the first zoom-in of the hillshaded DTMs for SOCET SET and SOCET GXP, respectively. Panels C and H show the second zoom-in of the hillshaded DTMs for SOCET SET and SOCET GXP, respectively. Lastly, Panel D is the orthoimage of the same area as B and G and panel E is the orthoimage of the same area as C and H showing the SOCET GXP-created orthorectified ESP_037818_1990 image. The resulting orthorectified images, as generated from SOCET GXP and SOCET SET, were nearly identical, so they are not compared here.

Within the SOCET SET extraction, the hillshade does contain several distinct, undesirable linear artifacts as shown in panel C (45-degree angle across the lower part of the hillshade). We are uncertain about the cause of these artifacts, but they could be from the necessary intermediate epipolar rectification step or that the updated CSM-based senor model has mitigated a potential “pixel-locking” issue.

3.2. Comparison HiRISE Pair 2

Figure 4 shows the second stereo-extraction comparison using HiRISE images ESP_011969_1425, ESP_047190_1425 (red channels) from the rim of Triolet crater, Mars (191.98°E, 37.09°S). The colorized hillshade and zoomed-in grayscale hillshades are derived from a 1 m/pixel SOCET SET-generated DTM (left) and a SOCET GXP-generated DTM (right). These images were selected to show an extremely steep area.

Panel A shows the SOCET SET colorized hillshade and panel F shows the SOCET GXP colorized hillshade (the scalebar for A and F is at the top right of the figure). As in Figure 3, the colorized hillshades A and F are almost indistinguishable. Panels B–E and G–H cover the two zoom-in locations shown by the red outlined boxes. All six zoom-in panels are shown at the same scale (the scalebar for all six panels is at the bottom right of figure). Panels B and G show the first zoom-in of the hillshaded DTMs for SOCET SET and SOCET GXP, respectively, and cover a section of the Triolet crater rim. Panels C and H show the second zoom-in of the hillshaded DTMs for SOCET SET and SOCET GXP, respectively, and highlight a V-shaped gully-like feature. Lastly, Panel D is the orthoimage of the same area as B and G, and panel E is the orthoimage of the same area as C and H showing the SOCET GXP created orthorectified ESP_011969_1425 image.

In SOCET SET panel B, shown are one undesirable vertical and one horizontal linear artifacts. SOCET SET panel C also shows another more subtle horizontal linear artifact. In the top middle of SOCET GXP panel G we do find subtle flat polygonal or “faceted” artifacts (red arrow). This is common for very bland areas and is seen in DTMs from both SOCET GXP and SOCET SET. Filtering, as applied to both DTMs, has helped to mitigate these artifacts but they are unfortunately still visible.

3.3. Comparison Summary

Figure 3 and Figure 4 highlight the resulting DTM extraction across SOCET SET and SOCET GXP are very similar, which is one of the main goals of this paper. While not shown, and due to the similarity of the DTMs, the derived orthoimages were also nearly indistinguishable. The subtle differences in the DTM could be attributed to either advances in the SOCET GXP application itself (e.g., being able to dynamically epi-polar rectify the images during matching) or actual updates to the CSM-based line-scanner sensor model implementation [40].

Although we realize more testing is needed across other instruments (e.g., LROC, CTX), we have shown that the development described herein (addition of a settable reference ellipsoid radii to the CSM API, successful transition of ASC’s sensor models to the usgscsm library, and updated editing capabilities), and the unique capabilities available in SOCET SET, can now be accomplished by SOCET GXP. This will allow the ASC, and others in the planetary community, to transition to SOCET GXP; a move necessitated by the deprecation of BAE’s support for SOCET SET. While not discussed, it is worth noting that SOCET GXP offers much faster DTM extractions and image orthorectifications due to the use of multi-threading and/or Graphics Processing Unit (GPU) acceleration.

4. Access to the ASC Community Sensor Model usgscsm Library

The transition to the CSM API-based usgscsm library was ultimately based on the need to transition away from SOCET SET to SOCET GXP. This library, again while originally created for SOCET GXP, can now function as a standalone library or as a plug-in for NASA Ames Stereo Pipeline (ASP, v3) and the ISIS software suite (v3+). Any application that conforms to the CSM API, including the ability to set custom radii using the API, can also take advantage of the photogrammetric capabilities the usgscsm library offers.

As part of our NASA-supported community efforts, the source code for the usgscsm library can be found at the USGS GitHub repository (https://github.com/DOI-USGS/usgscsm, accessed on 6 February 2024). The ASC has also released the related ALE and knoten libraries (https://github.com/DOI-USGS/ALE, accessed on 6 February 2024, https://github.com/DOI-USGS/knoten, accessed on 6 February 2024). All three libraries are in the public domain and the code is licensed using a Creative Commons Zero (CC0 1.0), unless stated otherwise. Each site has their own GitHub issues and community discussion boards. Documentation for each site, is also available. Linked from the usgscsm wiki, sample data sets for testing in SOCET GXP, ASP and the Python-based knoten environment have been made available (https://github.com/DOI-USGS/usgscsm/wiki, accessed on 6 February 2024). Lastly, pre-built binaries for the usgscsm, ALE, and knoten libraries are also offered, including installation instructions.

As part of our Astrogeology Photogrammetry and Processing Lab (APPL), we have prepared a Standard Operating Procedure (SOP) manual that describes how a user can process their own data in SOCET GXP. The use of the usgscsm library is also already well described in ASP’s documentation [12]. Detailed workflow steps are provided in the SOP and will be posted to the usgscsm GitHub wiki (currently in review). For the most recent version of this SOP, please contact the lead author.

5. Summary

We have shown that the usgscsm library is ready for DTM production in SOCET GXP with the generic push-broom sensor model using HiRISE images. Because the usgscsm library is used in SOCET GXP, ASP, and ISIS, it also greatly facilitates sharing data between these applications. Examples of useful workflows that would exploit such interoperability include creating a DTM in ASP and editing it interactively in SOCET GXP, or sharing orientation data for a set of images controlled in SOCET GXP so that they can be processed in ISIS.

Testing the new capabilities of SOCET GXP, such as the ASM image-matching module, additional editing tools, and enhanced hardware support is a logical and valuable extension of the work reported here. This would also include utilizing the methodology of Kirk et al. [46] to quantify the resolution and precision of SOCET GXP DTMs as compared to SOCET SET. The community-supported usgscsm GitHub repository (e.g., the GitHub Discussion site and Wiki) is a mechanism to communicate the results of such tests.

Lastly, as new planetary instruments are supported by the ASC, we are adopting a policy to first implement a CSM-based sensor model over an ISIS-based sensor model to support the three applications discussed here (SOCET GXP, ASP, and ISIS). We are hopeful that more applications which natively support the CSM API may also implement the usgscsm library, broadening planetary data processing across the community, especially as efforts increase with the Artemis missions to the Moon.