In OP Slack @mariodamore recently asked, “I am wondering how I can add support for an instrument in ISIS3.” and also “how to implement a new camera model for ISIS3.”
Unfortunately, there is a lot to digest there as ISIS evolves (based on community needs, e.g., Beyer, et al.) and simply as technology marches forward (awesome 3rd party libraries, hardware, and cloud capabilities). You can see some over-arching goals here which many are still in the works. As most folks know, trying to maintain a 20+ year-old software package while dragging it into the future is challenging.
While we have written most of the camera models and source code available in ISIS (via instrument team funding or other funding), we are an “open source” project and thus we do accept code pull requests. Although there will be some needed rigor to get any code approve (good code practices, tests, documentation, …). A little intro here.
Now that is out of the way, I will try to give a very high-level overview to try to answer the original questions above. This is my take at this too (not being a hard-core developer).
I see two main avenues to head down (similar but each path can meet different needs):
1. The newer Community Sensor Model (CSM) environment
- In brief, requires an ALE driver and SPICE kernels. Assumes any image calibration has already happened and image format is supported in the SET (see below). Camera model implementation will have support in NASA Ames Stereo Pipeline (ASP), SOCET GXP, Knoten test environment, and pretty good ISIS support.
2. The original ISIS environment
- In brief, requires ingest to an ISIS3+ cube format, calibration application (if needed), specific camera model implementation using ISIS API, SPICE loaded into ISIS, DEM loaded into ISIS (if needed). Camera model implementation has full ISIS support (obviously), but also ASP support.
A very short functional listing per application or Sensor Exploitation Tool (SET):
-
ASP (ISIS or CSM camera model): Map projection (or orthorectification via topography), topography generation (stereo or shape-from-shading), bundle adjustment, mosaic/blending, …
-
GXP (CSM camera model): Topography from stereo, bundle adjustment, orthorectification, mosaics, unique: heads-up topographic editing in stereo.
-
Knoten (CSM camera model): Python-based test environment for usgscsm/ALE.
-
ISIS (ISIS and decent CSM camera model support): Map projection (or orthorectification via given topography), bundle adjustment (lots of control networking tools), photometry, calibration (instrument specific), lots of other capabilities and GUI applications.
Now a little deeper dive:
1. The Astrogeology Community Sensor Model usgscsm (Laura, et. al., , Hare, et. al.,) is:
-
A stand-alone library based on the CSM standardize API. For planetary, support for the CSM API is available under NASA’s Ames Stereo Pipeline (ASP), SOCET GXP, Knoten testing environment, and pretty good support under ISIS itself (see csminit).
-
4 types of “generic” camera model implementations have been made available in the usgscsm library and are available to use (frame, push-broom/line scanner, push-frame, and an example SAR driver).
-
For instrument particulars (aka the camera model: focal length, distortion model, boresight, …) and the pointing/SPICE, CSM requires an Image Support Data (ISD) file. Our stand-alone ALE library can help demonstrate how to generate this ISD file (using a unique instrument driver and SPICE). See ALE on GitHub and the Step by Step ALE Driver Creation.
-
As Hare, et. al., describes, any CSM implementation requires a SET. In contrast, ISIS has the camera model and is the SET. Other applications that have stated support for CSM include Hexagon Geospatial, Esri ArcGIS Pro, OSSIM, and others, but they are all untested for planetary.
2. Original ISIS environment
-
Instrument camera model fits into the unique ISIS API. There is sort-of the concept of a “generic” camera model type (e.g., frame, pushbroom) since ISIS does have a lot of code reuse. For example, here is the the camera model implentation the MRO CTX pushbroom instrument.
-
ISIS currently requires the use of its own format – the ISIS3+ cube. Thus one would need an “ingest” application to convert from PDS (or other) to an ISIS3+ cube (e.g., mroctx2isis, and the keyword translation mapping MroCtxInstrument.trn). ISIS has limited support for PDS4 labels (e.g., tgocassis2isis).
-
Calibration (and related code) is typically unique per instrument (e.g., ctxcal, ctxevenodd).
-
SPICE kernels will need to be loaded into the ISIS environment (we can likely help with that if they are freely available).
-
DEMs can be loaded into the ISIS “Data” area after demprep is run.