This software consists of a set of application programs that support ground-based image processing for in situ missions. These programs represent a collection of utility routines that perform miscellaneous functions in the context of the ground data system. Each one fulfills some specific need as determined via operational experience. The most unique aspect to these programs is that they are integrated into the large, in situ image processing system via the PIG (Planetary Image Geometry) library. They work directly with space in situ data, understanding the appropriate image meta-data fields and updating them properly. The programs themselves are completely multimission; all mission dependencies are handled by PIG.
This suite of programs consists of:
• marscahv: Generates a linearized, epipolar aligned image given a stereo pair of images. These images are optimized for 1-D stereo correlations.
• marscheckcm: Compares the camera model in an image label with one derived via kinematics modeling on the ground.
• marschkovl: Checks the overlaps between a list of images in order to determine which might be stereo pairs. This is useful for non-traditional stereo images like long-baseline or those from an articulating arm camera.
• marscoordtrans: Translates mosaic coordinates from one form into another.
• marsdispcompare: Checks a Left→Right stereo disparity image against a Right→Left disparity image to ensure they are consistent with each other.
• marsdispwarp: Takes one image of a stereo pair and warps it through a disparity map to create a synthetic opposite- eye image. For example, a right eye image could be transformed to look like it was taken from the left eye via this program.
• marsfidfinder: Finds fiducial markers in an image by projecting their approximate location and then using correlation to locate the markers to subpixel accuracy. These fiducial markets are small targets attached to the spacecraft surface. This helps verify, or improve, the pointing of in situ cameras.
• marsinvrange: Inverse of marsrange — given a range file, re-computes an XYZ file that closely matches the original.
• marsproj: Projects an XYZ coordinate through the camera model, and reports the line/sample coordinates of the point in the image.
• marsprojfid: Given the output of marsfidfinder, projects the XYZ locations and compares them to the found locations, creating a report showing the fiducial errors in each image.
• marsrad: Radiometrically corrects an image.
• marsrelabel: Updates coordinate system or camera model labels in an image.
• marstiexyz: Given a stereo pair, allows the user to interactively pick a point in each image and reports the XYZ value corresponding to that pair of locations.
• marsunmosaic: Extracts a single frame from a mosaic, which will be created such that it could have been an input to the original mosaic. Useful for creating simulated input frames using different camera models than the original mosaic used.
• merinverter: Uses an inverse lookup table to convert 8-bit telemetered data to its 12-bit original form. Can be used in other missions despite the name.
This work was done by Robert G. Deen, Oleg Pariser, Mathew C. Yeates, Hyun H. Lee, and Jean Lorre of Caltech for NASA’s Jet Propulsion Laboratory.
This software is available for commercial licensing. Please contact Dan Broderick at
This Brief includes a Technical Support Package (TSP).
Support Routines for In Situ Image Processing
(reference NPO-47728) is currently available for download from the TSP library.
Don't have an account?
Overview
The document is a Technical Support Package from NASA's Jet Propulsion Laboratory (JPL), specifically focusing on the Multimission Instrument Processing Laboratory (MIPL) and its experiences in software reuse and development for planetary missions, particularly Mars missions. It outlines key lessons learned and best practices derived from the implementation of software systems across multiple missions.
One of the primary takeaways is the success of a multimission design approach, which emphasizes the importance of identifying commonalities across different missions. The document highlights that a thorough understanding of the problem domain is crucial for effective software development. It suggests that developing algorithms first, before creating reusable components, can lead to better mission frameworks and more efficient software libraries.
The document warns against the temptation to take shortcuts during development, especially under tight deadlines. It stresses that creating an abstraction layer for new features is more beneficial than introducing mission dependencies, as the latter can lead to complications in the long run. Consistency with previous mission designs is also emphasized, as changes without good reason can lead to increased implementation time and costs.
The document discusses the benefits of software reuse, noting that it can significantly reduce development costs, allowing savings to be redirected towards new capabilities or returned to sponsors. It also mentions that operator training is simplified when personnel can transition easily between missions due to familiar software systems.
Further lessons include the importance of documentation, advocating for extensive comments within the code to clarify the application programming interface (API) and the intended use of mission subclasses. The document encourages flexibility and extensibility in design, suggesting that libraries should be built as simple building blocks rather than monolithic structures.
Additionally, it recommends involving developers in operational roles to enhance their understanding of how their software is utilized, which can lead to improvements in both software design and operational efficiency.
In conclusion, the document serves as a guide for software developers and project managers in the aerospace field, emphasizing the value of thorough planning, consistency, and collaboration in the development of software for planetary missions.
