PDS_VERSION_ID = PDS3 LABEL_REVISION_NOTE = "M. CAPLINGER, 2002-04-01" RECORD_TYPE = STREAM SPACECRAFT_NAME = "MARS GLOBAL SURVEYOR" TARGET_NAME = MARS OBJECT = DATA_SET DATA_SET_ID = "MGS-M-MOC-NA/WA-2-SDP-L0-V1.0" OBJECT = DATA_SET_INFORMATION DATA_SET_NAME = "MOC SDP ARCHIVE" DATA_SET_COLLECTION_MEMBER_FLG = "N" START_TIME = 2003-12-06 STOP_TIME = 2003-12-09 DATA_SET_RELEASE_DATE = 1999-10-01 PRODUCER_FULL_NAME = "MALIN SPACE SCIENCE SYSTEMS" DETAILED_CATALOG_FLAG = "N" DATA_OBJECT_TYPE = "IMAGE" DATA_SET_TERSE_DESC = "MOC COMPRESSED IMAGES" DATA_SET_DESC = " Data Set Overview ================= This CD contains portions of the MOC Standard Data Product (SDP) Archive, a collection of compressed image data from the Mars Orbiter Camera on the Mars Global Surveyor spacecraft. Image data are stored with PDS labels, but are otherwise unprocessed and uncalibrated. This CD contains also ancillary data files, an index file ('imgindex.tab') that tabulates the contents of the CD, and documentation files. For more information on the contents and organization of the CD volume set refer to the 'CD CONTENTS, DIRECTORY, AND FILE NAMING CONVENTIONS' section of the aareadme.txt file located in the root directory of the data volumes. Parameters ========== Although this dataset has not been calibrated, and the algorithms for calibration are still being developed, we here describe some of the relevant calibration parameters. The MOC uses programmable gain and offset states, commanded on the ground prior to image acquisition, to condition the CCD output signal prior to its digitization to 8 bits. The very wide potential dynamic range of MOC images has required a large number of gain states (16 for the NA and 20 for the WA) and offset states (256 possible) compared to, for example, the Viking cameras, which had only two gain and two offset states. This leads to the operational complexity of predicting the scene brightness in advance and selecting appropriate parameters. The GAIN_MODE_ID and OFFSET_MODE_ID fields in the image headers describe the gain/offset selection. The GAIN_MODE_ID is a two-digit hexadecimal number which is the value of the MOC hardware register that selects the gain. The allowable flight values are Narrow Angle gain hex gain hex ---- --- ---- --- 1 F2 7.968 EA 1.465 D2 11.673 CA 2.076 B2 16.542 AA 2.935 92 23.386 8A 4.150 72 33.067 6A 5.866 52 46.740 4A 8.292 32 66.071 2A 11.73 12 93.465 0A Wide Angle gain hex gain hex ---- --- ---- --- 1.000 9A 16.030 96 1.412 8A 22.634 86 2.002 7A 32.092 76 2.832 6A 45.397 66 4.006 5A 64.216 56 5.666 4A 90.826 46 8.014 3A 128.464 36 11.34 2A 181.780 26 16.03 1A 256.961 16 22.67 0A 363.400 06 where the gain value given is the nomimal multiplicative factor from the lowest gain state. Many of the longer-duration WA images actually span multiple gain-offset states, although their labels and ancillary table entries only contain the state in effect at the beginning of data acquisition. For some applications, it is useful to know the time of the gain-offset state changes so that calibration can account for them. Refer to the wago.tab file for this information. The OFFSET_MODE_ID is the value of the MOC hardware register that selects the offset. Offsets are commanded in units of 5 (five) Data Numbers (DN), so an OFFSET_MODE_ID of '1' would correspond to a DN offset of 5. All offsets are positive. The simplified MOC response equation (without pixel-to-pixel variation terms) is as follows: dn = a*(r*ex+dc*ex+g)+(z-off) where r is the average signal level being generated at the focal plane (in DN/msec at minimum gain), z is the fixed zero offset, off is the commanded variable offset in DN (note that the offset is subtracted), dc is the dark-current term (in DN/msec at minimum gain), g is the gain-dependent offset (in DN at minimum gain), a is the system gain (where minimum gain is 1 and all other gains are >1, as given in the above tables), and ex is the exposure time (given in the image headers as the LINE_EXPOSURE_DURATION.) In-flight values for the fixed parameters in the above equation are still being derived from flight data. The values from ground testing at ambient conditions are system z dc g NA prime 25.5767 -0.0529099 0.381963 NA spare 28.934 -0.0099495 0.371922 WA red 27.5633 0.0013369 0.196468 WA blue 27.9424 0.0008232 0.264303 The significance of the negative dark-current terms for the NA systems is suspected to be due to other system noise sources in ground testing; the NA systems should have negligible dark current, even at room temperature, because of the short exposure times. The calibration algorithm will consist of two independent parts: removal of the pixel-to-pixel variation, which causes the visually apparent 'streaking' in the downtrack direction in MOC images, and conversion to either relative or absolute flux units (for purposes of mosaic construction, photometry, etc.) Work is ongoing to define these algorithms. Future volumes will include more information. Processing ========== Processing included packet decommutation, removal of the MOC communications protocol headers, reformatting, and addition of PDS label information. No additional geometric or radiometric processing was done. For most of the pre-mapping phase of the MGS mission, data quality did not allow error-free transmission of the instrument data to Earth. The MOC protocols (in particular, the formats for compressed image data) were designed for the bit error rates expected in mapping. As a result, considerable data losses were incurred in the image data. The majority of processing for pre-mapping data was done to minimize the effects of this data loss. This processing is too labor-intensive to process the much larger volume of mapping data. Unfortunately, data quality continues to be poorer than expected during the mapping phase of the mission. The decompression software provided on this volume makes some attempt to correct for errors, and each image file contains a field, DATA_QUALITY_DESC, that indicates if errors were detected in transmission. Enhanced, automated algorithms for correction of data errors is being developed on an ongoing basis. MOC image data are broken up into 'packets' of approximately 1000 bytes. A typical data loss is that of one or two packets, due to uncorrectable bit errors caused by noise in the space-to-Earth communications path, momentary loss of receiver lock caused by a transition between the one-way and two-way tracking modes, or loss in the Earth segment of the Deep Space Network. For uncompressed images, a packet loss leads to loss of 'line sync' in the image. Since the amount of actual image data in a packet is variable and cannot be determined precisely without the packet, such errors must be corrected by hand. This has been done for as many images as practical. The majority of NA images were acquired using the lossless predictive compression mode of the MOC. However, when a packet is lost from this compressed data stream, the decompression algorithm cannot realign itself to the compressed pixel boundaries, and must skip ahead to the next sync marker, which occurs only every 128 lines in the image. The effect of decompressing the data between the site of packet loss and the next sync marker is unpredictable, but usually results in either semi-random variations in pixel brightness (with the general morphology of the original image still visible) or essentially random noise patterns. When data rates from the spacecraft are low due to large Mars-Earth range, the MOC's lossy transform compressor was used to increase the number of images returned. This compressor is similar to the JPEG compressor in common use, although it uses 16x16 transform (DCT) blocks followed by quantization, zero truncation, and Huffman encoding of the remaining coefficients from a fixed set of encoding tables. The compressed data are sent in column order by block. As data loss was assumed to be rare, no sync markers were included in the data stream. Thus, packet loss or corruption within the compressed stream results in the incorrect decompression of the remaining transform blocks in that image fragment. Depending on the size and form of the loss, the blocks will either contain random or 'test pattern' noise, or, if the decompressor happens to realign to a block boundary, the remaining image data will appear normal but be shifted by some amount within the fragment. As noted above, work to improve these results is ongoing. Another type of loss is that of tens or hundreds of packets caused by bad weather, hardware failure, or operator error at the DSN stations, or miscommanding of the telemetry playback on the spacecraft. For these errors in a compressed data stream, over 128 lines of the image were lost, making it impossible to recover even the original downtrack size of the image. Media/Format ============ The MOC SDP archive is delivered to the Planetary Data System using CD media. Formats are based on standards for such products established by the Planetary Data System (PDS) [PDSSR1992]." CONFIDENCE_LEVEL_NOTE = " Geometric Accuracy ------------------ Latitude and longitude coordinates for the images given in the imgindex.tab file were computed using the best-available spacecraft position and orientation information, in the form of SPK and CK kernel files for the NAIF SPICELIB software. The versions used were constructed operationally by MOC personnel from deliveries by the MGS Project. While these should be equivalent to those retrievable from the NAIF FTP server (naif.jpl.nasa.gov), there may be small discrepancies and the NAIF versions are to be preferred for all further processing. Latitude is given in areographic form using the IAU 1994 definition of the Martian equatorial and polar radii (3397.0 and 3375.0 km, respectively). Coordinates are computed using the 1994 IAU spin vector values. Because of uncertainty in the MOC-to-S/C frame offset and limitations of the processing software, the MOC offset ('I kernel') was not applied; this should make a difference no more than 1/2 MOC NA FOV, probably less. It has been observed by MSSS that the USGS MDIM images were constructed based upon a definition of Mars' orientation from the Viking period. It can be shown that this results in a systematic shift between the 'old' and 'new' systems of 0.213 degrees in longitude. To place an image footprint onto the MDIM, one should subtract 0.213 degrees from the longitudes tabulated on this data volume. Any residual error in the location of the image is caused by further uncertainties in the MDIM and/or in the position and orientation information of the MGS spacecraft. Obviously, the best available SPICE information should be used for geometric calculations. In cases where only a portion of the lines of the image were actually recovered on the ground due to the data loss described above, the lat/lon coordinates given in the table are those of the center and corners of the image as commanded. In a few cases, spacecraft pointing information was not available for an image. In these cases, a nominal nadir pointing attitude has been assumed. This may lead to large errors in the footprint information, which should be considered advisory only. Map Projections of Images ------------------------- High-precision map projections of the images may be generated using the parameters given in the image header and/or the imgindex.tab file, the appropriate SPICE kernels, and map-projection software capable of processing line-scan imagery. Lacking such software, however, a first-order map projection may be produced by using the lat/lon coordinates of the image corners given in the imgindex.tab file, transforming these four points from rectangular image space to the essentially arbitrary quadrilateral in map-projection space using the desired map-projection equations, and then performing a four-point bilinear warp. Such a warp can be done in commercial packages such as Photoshop, as well as software specifically for planetary image analysis (PICS, ISIS, VICAR, etc.) Users wishing simply to correct for the effects of imaging flipping, non-square pixel aspect ratio and image skew may also find the USAGE_NOTE, PIXEL_ASPECT_RATIO and IMAGE_SKEW_ANGLE fields in the imgindex.tab file useful. The USAGE_NOTE indicates if the image should be flipped left-for-right prior to additional processing. If IMAGE_SKEW_ANGLE is not too far from 90 degrees, the image can be rectified to square-pixel form by expanding it in the vertical axis by a factor of PIXEL_ASPECT_RATIO (noting that values less than 1 result in shrinking rather than expansion.) Skew angles far from 90 degrees can be corrected by skewing the image from a rectangle to a rhomboid with a base angle of the given skew angle." END_OBJECT = DATA_SET_INFORMATION OBJECT = DATA_SET_TARGET TARGET_NAME = MARS END_OBJECT = DATA_SET_TARGET OBJECT = DATA_SET_HOST INSTRUMENT_HOST_ID = "MGS" INSTRUMENT_ID = "MOC" END_OBJECT = DATA_SET_HOST OBJECT = DATA_SET_REFERENCE_INFORMATION REFERENCE_KEY_ID = "MALINETAL1991" END_OBJECT = DATA_SET_REFERENCE_INFORMATION OBJECT = DATA_SET_REFERENCE_INFORMATION REFERENCE_KEY_ID = "MALINETAL1992" END_OBJECT = DATA_SET_REFERENCE_INFORMATION OBJECT = DATA_SET_REFERENCE_INFORMATION REFERENCE_KEY_ID = "MALINETAL1998" END_OBJECT = DATA_SET_REFERENCE_INFORMATION END_OBJECT = DATA_SET END