ISIS Documentation
Conversion from ISIS 2 to ISIS 3Reasons and considerations to upgrade from ISIS 2 to ISIS 3 | Home |
Driving Force of the Conversion
The major reason for embarking on the conversion of ISIS was to modernize a nearly 15-year old software package. ISIS was prototyped in the mid-to-late 1980's. Mainstream use began when it was ported to Unix around 1990. At that time, the technologies used in the development included TAE (a text-based user interface) and Fortran and C. Later IDL and X-Windows were used to add display functionality to the system. In the mid-1990's, the Perl scripting language was used to replace TAE PDF procedures. A modernization needed to be undertaken, one that would benefit users, software developers, and ISIS system management.
User Design Considerations
Two major elements were considered, the first was replacing the TAE text-based user interface and the second was easing the users learning curve. Currently, ISIS employs a graphic user interface derived from the Qt API. A significant reason the Qt API was selected is it is available on Unix, Windows, and Macintosh platforms.
![[lowpass GUI Screenshot]](assets/lowpass.jpg)
Example of the GUI 500x666, 64KB |
In addition to replacing the user interface, several other problem areas were identified and addressed in order to make learning and using ISIS easier. They include
- Overly feature rich programs such that only the programmer or designer can fully utilize the application
- Programs names with unclear meanings
- Two or more programs with the same functionality
- Function of the program is unclear
Some examples and solutions of each if these problems are:
| Problem | Solution |
|---|---|
Overly Feature Rich
|
Multiple Programs
|
Unclear Names
|
Standard Meanings
|
Multiple Programs
|
Single Programs
|
Unclear Program Function
|
Clearer Program Function
|
![[Documentation screenshot]](assets/docshot.jpg)
Example of the Documentation 579x600, 114KB |
Programmer Design Considerations
There were many major design considerations relating to software development. They included:
- Increase code reuse
- Increase programmer productivity
- Utilize more third party APIs
- Utilize more developer tools
Increase code reuse
The ISIS API consisted of many hundreds of C and Fortran subroutines. The documentation for the routines was located in the source code, forcing application programmers to manually find and locate the desired function. Coupled with fact there was no table of contents or other front-end navigation ability meant developers often relied on word-of-mouth to determine existing capabilities. In the worst case, capabilities were sometimes re-coded because of lack of information.
The conversion process allowed for more planning in regards to the ISIS Application Programmer API. The API reference presents a full developer documentation set in a consistent, web-based interface. The following is an example of the documentation for a C++ class,
Increase programmer productivity
Another aspect of the design was to increase programmer productivity. In particular, the goal was to have the developer redirect focus from error checking, user input, and cube I/O to the algorithm. The following example of the “mirror” program clarifies the position:
| ISIS 2.1 | ISIS 3.0 |
|---|---|
|
|
The redirection of focus can be attributed to the C++ expansion of the “DOIO” concept. This concept developed in the late 1970's, significantly reduced the amount of programming overhead (errors, I/O, user interface).
Utilize more third party APIs
To further increase code reuse there was a desire to utilize third party APIs. Many of the newer APIs are restricted to C++ or Java and not available in Fortran or C. Currently the ISIS system utilizes the following APIs:
- Imagemagick (image file format library)
- Qt (multi-platform window system)
- Xerces (Xml parsing)
- TNT/JAMA (matrix and linear algebra)
- NAIF/SPICE Toolkit
Utilize more developer tools
Many of the current development tools are geared toward object-oriented languages or other new technologies (e.g., Xml, MySql, etc). Developers can use various language sensitive editors, debuggers, code profilers, code analyzers, and other tools not readily available or fine-tuned for Fortran/C.
ISIS System Management Design Considerations
The administration of ISIS is especially critical as it is being used more and more by the external USGS planetary community. In particular the following areas were addressed:
- Source maintenance
- Software verification
- Distribution
- User Support
Source Maintenance
ISIS source code maintenance is now handled through Concurrent Versions System. CVS allows for programmers to check out, modify, and commit changes to the ISIS source repository. It monitors conflicts between simultaneous access to the source code by developers, as well as providing methods for retrieving all previous versions of the source.
Software Verification
A major need for system management was the ability to verify ISIS functions properly when porting to a new operating system, upgrading operating systems, changing compilers, or modifying compiler switches. ISIS now relies on a suite of “unit tests” to verify the entire API is functioning properly. In addition, a suite of “application tests” is used to verify individual programs are operating the same.
Distribution
The distribution of ISIS on CD/DVDs to external customers became problematic due to the growing size of support files (SPICE and calibration) for current missions. To facilitate timely distribution and quick installation, a self-syncing system was constructed. The system utilizes the “rsync” software package to distribute ISIS over the Internet in time period of 2 to 10 hours.
User Support
Previously, ISIS user support was handled through an email-based mechanism. It was not centralized and therefore questions could fall through the cracks. Additionally, no uniform methods existed for collecting user information (e.g., platform, O/S level, ISIS version, etc). Currently, we utilize a web-based ticket tracking system. It can be found at http://isis-support.wr.usgs.gov/
Other Significant Design Changes
Obviously there have been significant changes already discussed including the GUI, programming, and system management. There are other changes or additions made, some subtle, worth minor discussion and some major. The following sections discuss other these changes.
User Preferences
In the past, user preferences were handled via system environment variables. For example, “setenv ISIS_SESSION_LOG myprint.prt” was the c-shell command for changing user preferences for error logging. Currently, all user preferences will be specified in a system-wide, personal-user, and/or project-specific preference file. The preference file is in Parameter Value Language (PVL) format.
Session Log File
In the previous version of ISIS, the session log files were partially PVL and then free-format as the programmer output results of the program. The current version requires all output to the session log be in PVL format. Results of the program will be stored in a RESULTS group. Additional information needed to be free-format can be written to a user specified output file. For example, the histogram program now writes either a postscript histogram or a classic histogram to a file. It is no longer output in the session log. Additionally, the programmer has some control over free-format in the session log by utilizing the PVL comment construct.
Cube Format and Compatibility
The cube format for ISIS has been upgraded. In particular, ISIS outputs a new tiled format discussed at a later point in this document. The tiled format is better suited for large spatial products and still allows for rapid access in the hyper-spectral modes. However, all programs in ISIS 3 will continue to read the band sequential format produced in ISIS 2 for backward compatibility. Support is also continued for 8-bit unsigned, 16-bit signed, and 32-bit real pixel types, along with the various special pixel values. Finally, the ISIS software will be endian-neutral. That is, programs will automatically handle LSB or MSB pixel storage order, regardless of machine architecture.
Suffix Data
[Future Option] Much effort went into the design and development of suffix data such as backplanes, sideplanes, and bottomplanes. Conceptually, the idea of suffix data was appealing in the original ISIS design. Realistically, most of the ISIS 2 application programs never dealt with them because of the complexity. In ISIS 3 we plan to continue with the ability to support suffix data, albeit in a different form and name. Suffix data will be handled through BLOBs (Binary Large OBjects). The advantage is the BLOB is a contingous chunk of data unlike suffixes which were intermixed amongst the pixel data. A BLOB will be able to represent a sideplane, bottomplane, or any other non-image data (e.g., vectors defining regions of interest, lookup tables).
SFROM, ORANGE and OTYPE Parameters
In ISIS 2.1, the SFROM, ORANGE, and OTYPE parameters were essentially qualifiers for input and output cubes, respectively. The functionality of these three parameters still exists; however, it is handled via attributes to cube files as opposed to sets of parameters. For example, TO2, ORANGE2, OTYPE2 or FROM2, SFROM2 are replaced by a file specification with attributes TO=output.cub+16bit
Display Software
Image display was handled via “qview” for cartographic (large spatial) and “cv” for hyper-spectral cubes. They were coded using X-Windows and IDL, respectively. Display capabilities for ISIS 3 are coded in the Qt API. The design for these capabilities will follow the PICS TVDO concept. That is, an image display base class is provided. This class allows for standard display functions such as zoom, roam, stretch, blink, cursor interrogation, and measurement tools. Individual display programs that perform specialized functions will be derived off the base class. Such programs include control point selection, limb-fitting, and editing.